On Tue, 2007-09-04 at 23:27 +0100, Thiemo Seufer wrote:
Brian Johnson wrote:
[snip]
My initial thought is to make the libraries at the individual device
level.
It would be good to have a general mechanism for bus providers, interrupts,
APICs, chipsets, etc. as well, so we could emulate fancier architectures
than a simple PC (or simple Sparc/MIPS/ARM/etc. box.) For instance, I'd
like to emulate multiple PCIe host bridges, each with an APIC and multiple
cards, which might contain PCI-to-PCI bridges. And I'd like to emulate
NUMA systems with many memory controllers and a complex memory map, with
multiple sets of chipset registers. I don't expect qemu to do this off the
shelf,
Why not? I would like to see better abstracted and more capable device
emulations in Qemu.
but I'd like to avoid hardcoding PC assumptions into the device
libraries, so I can code the fancy machines myself and use the I/O as-is.
Then, what does a librar-ized Qemu device with its hardcoded PC
assumptions help you?
Let me give a very pragmatic answer. Right now, KVM has it's own main
loop which uses a thread per-vcpu. Device IO is handled in the context
of the VCPU that originated the IO. I think there's some desire to move
to an N+1 threading model where the extra thread does things like VGA
scanning, VNC, etc.
Xen, on the other hand, uses a single thread for everything and doesn't
attempt to model multiple VCPUs within the QEMU process. All IO is
delivered via the same channel. QEMU is strictly used for devices.
Merging either of these with QEMU's current model would be challenging,
merging both would be extremely challenging b/c the two main loop models
are mutually exclusive.
However, there's no real trouble merging any of the device emulation
back. KVM doesn't maintain any changes to things like device emulation
(other than some KVM-specific APIC stuff). Xen, on the other hand,
mostly has fixes for some of the devices that haven't been submitted
back to QEMU. Other devices are completely unmodified but are severely
lagging behind the QEMU versions.
VirtualBox is way different than QEMU of course. A bunch of their
device emulation is pretty close to QEMU though.
I think device emulation is an independent enough problem that there's a
good chance everyone can agree on a single implementation. While it's a
little more work in QEMU to keep these things as libraries and maintain
an interface, I suspect the benefits outweigh the extra cost in that
it's much more likely we'll see more patches.
There are useful bits of QEMU that could be widely consumed. Their
nature is such that their interfaces are unlikely to change dramatically
in the future. To me, this just screams "library" :-)