[Top][All Lists]

[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

From: Paul Brook
Subject: Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)
Date: Fri, 27 Jul 2007 23:03:15 +0100
User-agent: KMail/1.9.7

> >> 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
> instructions?

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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]