Re: [Qemu-devel] [PATCH]ish NPTL support.

[Jamie Lokier]

David Woodhouse wrote:
> > However, it is probably easier to use the host's, than to write the
> > equivalent (basically duplicating the kernel's futex code in qemu, the
> > hashed locks and wait queues etc.).
> 
> The kernel's implementation is a _whole_ lot more complicated than ours
> needs to be in qemu, because of the security implications of dealing
> with arbitrary pointers in userspace. I think it's reasonable enough for
> qemu to do its own.

Although there are security issues, things like page table walking and
address hashing would need to be implemented in qemu too, if the
emulated program is allowed to fork.

> > On the other hand, using the host's makes it hard to run Linux guest
> > binaries on non-Linux hosts (those which don't have futex), or newer
> > Linux guest binaries on older Linux hosts which have fewer futex ops,
> > or none at all.
> 
> I don't think we care. You can't run qemu-i386 on a non-Linux box
> _anyway_, can you? And having some syscalls return -ENOSYS if you run on
> a prehistoric kernel is perfectly normal.

If we want non-Linux hosts to behave as prehistoric kernels, that's
fine.  If you want non-Linux hosts to run current Linux binaries, I
guess that's not enough.

> I did briefly think about implementing threading entirely within qemu
> _without_ using threads on the host -- having the qemu process itself
> schedule between the different CPU contexts. That would make the GDB
> stub a whole lot saner for debugging multi-threaded guest programs. But
> I don't think it's workable -- the whole point in NPTL was that you
> _can't_ emulate proper POSIX-compliant threading with hacks in
> userspace; especially the details of signal delivery.

NPTL is a number of changes from LinuxThreads, some for performance
and some for POSIXness.

What you can't sanely do is implement POSIX-thread signals when using
the old style of clone()'d kernel threads which LinuxThreads uses.
That was due to a kernel limitation.

But you can implement POSIX-thread signals them when all threads run
within a single POSIX process, and are all scheduled in userspace.
AFAIK, POSIX thread signals are specified the way they are
specifically to allow that kind of implementation.

See GNU Pth for a fairly portable implementation of POSIX threads
entirely in a userspace library, using a single kernel thread.

You might be able to adapt Pth to implement your single process idea
for Qemu.

What's much more difficult is providing Linux thread semantics for
non-POSIX things, particularly blocking operations on devices and
files, and tid-specific things like queued SIGIO delivery.

But any emulation which doesn't simply map those things to the host
Linux kernel will have trouble getting those right.

-- Jamie