* [Qemu-devel] Threading Qemu
@ 2008-05-28 6:31 mixado
2008-05-28 7:40 ` Izik Eidus
0 siblings, 1 reply; 7+ messages in thread
From: mixado @ 2008-05-28 6:31 UTC (permalink / raw)
To: qemu-devel
<html><body>Hi,<br><br>To make use of all the host CPU cores I'm thinking of adding thread support to Qemu. <br>The idea so far is to create one thread for each virtual CPU, and then run a modified main_loop in each of these threads. <br>The first step would be to rewrite all the global variables like first_cpu etc to make it more thread friendly, and make that run in the current non-threaded version. <br><br>Any hints or tips that I should keep in mind when attempting this? Has thread support been worked on before but not completed?<br><br></body></html>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Threading Qemu
2008-05-28 6:31 [Qemu-devel] Threading Qemu mixado
@ 2008-05-28 7:40 ` Izik Eidus
2008-05-28 12:27 ` Fabrice Bellard
2008-05-28 12:28 ` Jamie Lokier
0 siblings, 2 replies; 7+ messages in thread
From: Izik Eidus @ 2008-05-28 7:40 UTC (permalink / raw)
To: qemu-devel
mixado@mod-x.com wrote:
> Hi,
>
> To make use of all the host CPU cores I'm thinking of adding thread
> support to Qemu.
> The idea so far is to create one thread for each virtual CPU, and then
> run a modified main_loop in each of these threads.
> The first step would be to rewrite all the global variables like
> first_cpu etc to make it more thread friendly, and make that run in the
> current non-threaded version.
>
> Any hints or tips that I should keep in mind when attempting this? Has
> thread support been worked on before but not completed?
>
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
plus you will need to take care for memory barriers, and many more things
(it looks very complex)
--
woof.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Threading Qemu
2008-05-28 7:40 ` Izik Eidus
@ 2008-05-28 12:27 ` Fabrice Bellard
2008-05-28 12:39 ` Jamie Lokier
2008-05-28 12:28 ` Jamie Lokier
1 sibling, 1 reply; 7+ messages in thread
From: Fabrice Bellard @ 2008-05-28 12:27 UTC (permalink / raw)
To: qemu-devel
Izik Eidus wrote:
> mixado@mod-x.com wrote:
>> Hi,
>>
>> To make use of all the host CPU cores I'm thinking of adding thread
>> support to Qemu.
>> The idea so far is to create one thread for each virtual CPU, and then
>> run a modified main_loop in each of these threads.
>> The first step would be to rewrite all the global variables like
>> first_cpu etc to make it more thread friendly, and make that run in the
>> current non-threaded version.
>>
>> Any hints or tips that I should keep in mind when attempting this? Has
>> thread support been worked on before but not completed?
>>
> 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
> plus you will need to take care for memory barriers, and many more things
> (it looks very complex)
I confirm, the general case is quite complicated. It is simpler to begin
with an implementation where the host and guest CPUs have the same
memory ordering constraints (e.g. x86 on x86 case).
Fabrice.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Threading Qemu
2008-05-28 12:27 ` Fabrice Bellard
@ 2008-05-28 12:39 ` Jamie Lokier
0 siblings, 0 replies; 7+ messages in thread
From: Jamie Lokier @ 2008-05-28 12:39 UTC (permalink / raw)
To: qemu-devel
Fabrice Bellard wrote:
> I confirm, the general case is quite complicated. It is simpler to begin
> with an implementation where the host and guest CPUs have the same
> memory ordering constraints (e.g. x86 on x86 case).
I have just realised it is not _always_ correct even for x86 on x86,
for some flavours of x86 host CPU.
Qemu emulates a standard x86 with writes fully ordered. Guest code
will assume that.
But a few types of x86 host don't fully order writes. See
CONFIG_X86_OOSTORE and CONFIG_X86_PPRO_FENCE in Linux kernels - look
in linux/arch/x86/Kconfig.cpu.
On those, running multiple target CPUs as host threads on a
multiprocessor host may not be correct.
I'm not sure if the "sfence" instruction means this could apply to
some modern, mainstream x86 hosts too.
-- Jamie
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Threading Qemu
2008-05-28 7:40 ` Izik Eidus
2008-05-28 12:27 ` Fabrice Bellard
@ 2008-05-28 12:28 ` Jamie Lokier
2008-05-28 13:31 ` Paul Brook
1 sibling, 1 reply; 7+ messages in thread
From: Jamie Lokier @ 2008-05-28 12:28 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Threading Qemu
2008-05-28 12:28 ` Jamie Lokier
@ 2008-05-28 13:31 ` Paul Brook
0 siblings, 0 replies; 7+ messages in thread
From: Paul Brook @ 2008-05-28 13:31 UTC (permalink / raw)
To: qemu-devel
> > 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.
Yup. I had a proof of concept implementation that used the TLB to enforce
per-page exclusive access. This worked, but the locking overhead to achieve
this was fairly horrible, particularly when you have pages that bounce
between CPUs frequently (e.g. kernel locks). The nice thing about this is
that you don't need to do anything special to ensure atomicity, it just
works.
> 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.
That's what qemu currently does.
Paul
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [Qemu-devel] Threading Qemu
@ 2008-05-28 10:40 Mikael Regnell
0 siblings, 0 replies; 7+ messages in thread
From: Mikael Regnell @ 2008-05-28 10:40 UTC (permalink / raw)
To: qemu-devel; +Cc: paul
<html><body>The current idea is to use mutexes at TB level, to avoid problems with atomic operations. Perhaps this won't give enough benefit, but it is the current plan. With this approach it's possible to go down to atomic level operation in the future.<br><br>I read in another thread that Paul Brook is planning to implement multithreading. <br>Paul: Do you have any more information on your approach?<br><br>BR,<br>/Micke<br><br>
<blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px;">
-------- Original Message --------<br>
Subject: Re: [Qemu-devel] Threading Qemu<br>
From: Izik Eidus <izike@qumranet.com><br>
Date: Wed, May 28, 2008 12:40 am<br>
To: <a href="mailto:qemu-devel@nongnu.org">qemu-devel@nongnu.org</a><br>
<br>
<a href="http://email.secureserver.net/pcompose.php#Compose" onclick="Popup.composeWindow('pcompose.php?sendto=mixado%40mod-x.com'); return false;">mixado<b></b>@mod-x.com</a> wrote:<br>
> Hi,<br>
> <br>
> To make use of all the host CPU cores I'm thinking of adding thread<br>
> support to Qemu.<br>
> The idea so far is to create one thread for each virtual CPU, and then<br>
> run a modified main_loop in each of these threads.<br>
> The first step would be to rewrite all the global variables like<br>
> first_cpu etc to make it more thread friendly, and make that run in the<br>
> current non-threaded version.<br>
> <br>
> Any hints or tips that I should keep in mind when attempting this? Has<br>
> thread support been worked on before but not completed?<br>
> <br>
it isn't about just give thread for each virtual CPU, you will need to take care that<br>
atomic operations will translate from one architecture to another architecture as atomic<br>
plus you will need to take care for memory barriers, and many more things<br>
(it looks very complex)<br>
<br>
<br>
-- <br>
woof.<br>
<br>
<br>
</blockquote></body></html>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-05-28 13:31 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-28 6:31 [Qemu-devel] Threading Qemu mixado
2008-05-28 7:40 ` Izik Eidus
2008-05-28 12:27 ` Fabrice Bellard
2008-05-28 12:39 ` Jamie Lokier
2008-05-28 12:28 ` Jamie Lokier
2008-05-28 13:31 ` Paul Brook
-- strict thread matches above, loose matches on Subject: below --
2008-05-28 10:40 Mikael Regnell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).