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

[Paul Brook <paul@codesourcery.com>]

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

Not out the box, not. However It's not all that hard to make it work. 
Certainly on any sane unix host It should be feasible. Most of the syscalls we 
currently translate in C library calls or implement ourselves, we don't use 
host syscalls directly. I've even had a fair amount of success successfully 
run linux applications on windows hosts via qemu.

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

I'm fairly sure some of the BSDs have multiple userspace threads per kernel 
context. There was at least 1 proposed linux implementation like this as 
well. IIRC we only ended up with the current 1:1 mapping because it was 
simpler.

One possibility is to use host threads (to get PID/TID mappings right), but 
still explicitly schedule from userspace. ie. have qemu ensure no more than 
one thread is active at any time.

Paul