> > 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 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
