On 02/13/2011 10:07 AM, Benjamin Herrenschmidt wrote:
On Sun, 2011-02-13 at 10:08 +0200, Blue Swirl wrote:
This is a bit of a special case, much like semihosting modes for m68k
or ARM, or like MOL hacks which were removed recently. From QEMU point
of view, the most natural way of handling this would be hypervisor
implemented in the guest side (for example BIOS). Then the hypervisor
would use normal IO (or virtio) to communicate with the host. If
inside QEMU, the interface of the hypervisor to the devices needs some
thought. We'd like to avoid ugly interfaces like vmmouse where a
device probes CPU registers directly or spaghetti interfaces like
APIC.
I'm not sure I understand your point. We are emulating a guest running
under pHyp, ie, qemu in that case is the hypervisor, and provides the
same interfaces as pHyp does (the IBM proprietary hypervisor, aka
sPAPR). This is how we enable booting existing kernels and distributions
inside qemu/kvm.
Is the interface new design, or are you implementing what is used also
on real HW?
We are implementing a subset of the interfaces implemented by pHyp today
on "real HW". In the long run, when you throw KVM into the picture, on
machines (hypothetical machines at this stage) where one can run a KVM
has a hypervisor (currently you can only run pHyp on all released IBM
machines), this will give you an environment that is compatible with
pHyp and thus supports existing distributions and kernels.
We try very, very hard to make our paravirtualization look like real
hardware.
When the paravirtualization interfaces are already defined, we have no
choice in supporting those interfaces although sometimes we try to push
that to firmware (like with Xenner). It's better from a security PoV.
But in this case, we have no choice but to implement the
paravirtualization interfaces in QEMU because of the way the hardware
works and because these interfaces are already well defined.
Regards,
Anthony Liguori
We -will- add support for the "real" virtio on top of that, but those
will require modified guest kernels (and will provide better
performances than the sPAPR emulation). But the sPAPR emulation is a
necessary step to enable existing stuff to run.
Cheers,
Ben.
