[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h h
Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)
Fri, 27 Jul 2007 23:03:15 +0100
> >> how close is thread safey?
> > In a useful form: a fair way off.
> > It's relatively simple to hack something together than runs. Making it
> > work correctly and go fast is much harder though. My current prototype
> > (running on 2 cores) runs about a quarter the speed of normal qemu, and
> > dies shortly after booting because the guest atomic synchronisation
> > primitives don't work right.
> This later problem seems like the hardest to solve to me. Did you have
> any ideas here that don't involve hand coding the translation for atomic
Yes. I do exclusive access locking at the TLB level. i.e. creating a TLB entry
for a writable page forces that page to be flushed from all the other CPU
There's some wiggle room in the definition of a "writable" page. If other
critera are met it should be sufficient to just do this exclusion for atomic
If necessary the same technique can be used to avoid write ordering and
coherency problems without having to accurately map guest barriers onto the
equivalent host operations. This is handy when most of the guest barriers are
implicit, e.g. when emulating a strictly ordered guest on a weakly ordered
In theory this could be taken to extremes and used to split emulation of a
single machine over multiple address spaces/nodes. In practice the
contention on a normal SMP operating system is high enough that this is not