[buildd-tools-devel] Bug#604268: Bug#604268: Bug#604268: Bug#604268: Bug#604268: QEMU linux-user support

[Roger Leigh]

On Sat, Jan 22, 2011 at 11:26:41PM +0100, Loïc Minier wrote:
> On Sat, Jan 22, 2011, Roger Leigh wrote:

>  One thing I pondered recently is if it would be best to ask the host
>  environment's binfmt-support database about the interpreter to copy,
>  based on an executable from the chroot.  IOW, match
>  /var/lib/binfmts/qemu-* against some executable from the chroot, and
>  then find out the qemu binary to use from that file.  Or perhaps binfmt
>  could tell us with a new interface, or we could find out by running a
>  static binary and looking at its interpreter:
>     CHROOT=/var/lib/schroot/mount/natty-armel-f3e92a7f-f1a5-472e-8c0b-3e2c6f8f70cf/chroot-autobuild
>     $CHROOT/lib/ld-linux.* --library-path $CHROOT/lib $CHROOT/bin/cat /proc/self/cmdline
> 
>  this outputs:
>     /usr/bin/qemu-arm-static\0<chroot>/lib/ld-linux.so.3\0 ...
>  (the above form might not be terribly portable, but note how we avoid
>  the whole dance of running "file", or the name of qemu architectures;
>  heck, we don't even need to know it's qemu!!)

This should be sufficiently portable for Linux usage.  I am a little
concerned that it might be fragile though.  How does the binfmt-misc
code know which file to pick?  Can't we use the same mechanism and
avoid this?

Note that we don't need to use file or this mechanism.  We are a
compiled binary, so we can simply use libbfd or libelf directly.  We
can then get the architecture identifier /directly/.  We would need to
map numbers to names for qemu (and additional maps for other
interpreters with different naming schemes, but that's not important
for now).  OTOH, your method guarantees that we pick the correct
interpreter.

> > If you're unhappy with any of the names used, that's also trivial to
> > change if you like.  (I'm fairly rubbish at naming things!)
> 
>  That's probably as good as what I would think of; qemu syscall
>  emulation is usually named "CPU transparency" because it's basically a
>  mapping of a flow of CPU instruction to another one, with syscall
>  translation.  This is different from qemu machine emulation which
>  emulates hardware; this is sometimes called simulation.  Upstream, the
>  syscall emulation stuff is called "qemu-user emulation".

Would it be better to use "emulation=qemu-user" rather than just
"qemu"?  It would allow addition of "qemu-system" at a later point,
and also makes the distinction between the two.

[Typos and corrections]
Thanks, I've fixed those.

>  Ah it's actually qemu-kvm-extras-static in Ubuntu, not qemu-kvm-extras;
>  I can see I'm at the origin of this bug
> 
> > +# Depends: file, qemu-user-static | qemu-kvm-extras
> 
>  Should be | qemu-kvm-extras-static

If the package is not in Debian, maybe this one should be patched
in when put in Ubuntu?

> > +Currently, qemu is the sole method for supporting machine emulation.  If one
> > +wishes for example to emulate an ARM machine, schroot will copy the static
> > +\fIqemu-arm-static\fP binary from the host system to the chroot in order to
> > +allow the emulation to work transparently.
> 
>  This reminds me that there's an inherent bug in the current approach:
>  if you install qemu-user-static in the chroot, you're screwed
>  (the x86 qemu-arm-static which you copied into the chroot gets replaced
>  by an ARM one).  A quick and dirty way around this would be
>  dpkg-divert (run in the chroot just after copying qemu-arm-static), a
>  long-term elegant way might be multiarch.

Yes, this is a definite problem.  Even if we divert the binary, we
would be breaking things for the user who wanted that package
installing.  Diverting means we can delete the copied binary and
undivert on session end, so this would be good to do in any case.
I guess this is what update-binfmts creates:

[/var/lib/binfmts/qemu-ppc]
qemu-user-static
magic
0
\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x14
\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff
/usr/bin/qemu-ppc-static

Which is hardcoding the path.  If the path wasn't hardcoded, we could
have put it into /usr/local or even some non-standard name or location
if we could adjust the interpreter.  It's a shame it's looking inside
the chroot, rather than the main root, but that's probably the only
sane thing to do now a system can have multiple namespaces.

I think that clearly documenting this limitation is the most
pragmatic approach here.  I think the chance of installing and
using the same qemu-$arch-static binary inside the chroot is small,
but using a diversion will be a good improvement.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110123/1300a270/attachment.pgp>