[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Threading Qemu
From: |
Jamie Lokier |
Subject: |
Re: [Qemu-devel] Threading Qemu |
Date: |
Wed, 28 May 2008 13:28:50 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Izik Eidus wrote:
> it isn't about just give thread for each virtual CPU,
> you will need to take care that atomic operations will translate
> from one architecture to another architecture as atomic
That's a bit work, but should be ok provided the host architecture has
equivalent atomic ops, or equal-or-larger-width compare-and-swap
instructions (from which you can make all atomic ops).
Don't forget that simple write ops are atomic on most architectures.
If you have to translate e.g. an 8-byte write to two 4-byte writes on
a 32-bit host, that loses the atomic write property, which many
programs depend on.
> plus you will need to take care for memory barriers, and many more things
> (it looks very complex)
Don't forget _implied_ memory write barrier after every write op on
x86 target. With x86 target on hosts where writes are not
processor-ordered like x86, you need to put a write-write barrier after
every write - except when you can prove it's not needed. But that's
really hard.
You can relax this, if you emulate particular x86 targets which have a
"weak write mode". Some Linux guests, at least, will enable weak
write mode on those - in that mode you can translate to faster code
for the non-x86 host.
Both atomiciy and ordering don't have to be solved if instead you use
"software scheduled" threads on any architecture - e.g. see GNU Pth.
Then you won't get real parallelism on a multiprocessor host, but you
can simulate any multiprocessor target correctly.
-- Jamie