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

[David Woodhouse <dwmw2@infradead.org>]

On Thu, 2006-12-14 at 02:16 +0000, Jamie Lokier wrote:
> David Woodhouse wrote:
> > - sys_futex():
> > 
> > We have to translate these into calls to the host's sys_futex() anyway.
> 
> I don't think it's necessary to translate to the host's sys_futex(),
> unless the guest will be doing futex operations on memory which the
> host _also_ does futex operations on.

Yes, that observation makes sense. We just need proper locking against
other qemu guest threads within the same process; nothing more.

> CLONE_CHILD_CLEARTID is one of those, if it's simply relayed to the host.
> So are locks in shared memory, if they are to work between host and
> guest processes.  But I guess they are not expected to work.

Right. Those would be robust futexes -- and for the moment we can ignore
them because we haven't implemented sys_set_robust_list() anyway. That
would make life a whole lot more complicated, but I think we can do
without it for now.

> The atomicity, queueing etc. semantics, provided they are only among
> threads of a single qemu process, can be guaranteed using normal
> pthreads locking and atomic operations, analogous to the way the host
> kernel maps futex calls to its own waitqueues, semaphores, and atomic
> ops.

Yes. We might also be able to cheat in a way inspired by the 'Big Kernel
Lock' -- by pinning all threads to the same host CPU to help eliminate
some of the locking issues. 

> 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.

> 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.

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.

-- 
dwmw2