But how often will the virtual CPUs need the same page and is there any
other shared resource other than memory? I don't know how independent
each CPU is. Though in side discussions, everyone agrees with you, I
haven't seen numbers to convince my gut. If page only needs to be
faulted back
Quoting Fabrice Bellard [EMAIL PROTECTED] :
SMP est definitely possible in QEMU - a few days of work are
necessary to add the missing generic support and an x86
implementation...
ok.
but currently I prefer to work an other topics.
ok.
So, perhaps in the next releases?
Hi,
The architecture used in sparc target (sun4m) supports SMP up to a maximum
of 16 CPUs. At hardware emulation level (hw/*, target-sparc/*), it would be
easy to add the missing interprocessor interrupts, per-CPU counters and
atomic instructions. It would also be simple to add the prom
Blue Swirl wrote:
Hi,
The architecture used in sparc target (sun4m) supports SMP up to a
maximum of 16 CPUs. At hardware emulation level (hw/*, target-sparc/*),
it would be easy to add the missing interprocessor interrupts, per-CPU
counters and atomic instructions. It would also be simple to
SMP est definitely possible in QEMU - a few days of work are necessary to
add the missing generic support and an x86 implementation... but currently
I prefer to work an other topics.
Just for your information, some choices need to be made:
1) Do the CPUs share the same translation cache ?
This
I guess you'd really want to simulate multiple CPUs with multiple host
threads. One of the additional problems could then be memory/cache
coherency.
I'm not sure how much of a problem this would be in practice. If both host
and guest require the same (or no) explicit SMP memory barriert it's not
On Sat, 2005-05-14 at 14:16 +0200, Fabrice Bellard wrote:
...
2) The first implementation would use a cycle counter to schedule
between CPUs. Is it interesting to go further and to use a host thread
for each guest CPU at the expense of more locking overhead ?
What inter processor
