[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Questions about PVH in Xen 4.3 unstable

On 30/01/13 12:04, tech mailinglists wrote:
I read the blog posts and watched the video of Mukesh's prasentation. And now I want to try to summer up the existing guest/domain-types and stubdom-types to verify I understood them:


PV: A PV guest is a guest where the kernel is so modified that it knows that it is a virtualized system (no priviliged instructions, special drivers and so on).

HVM: This guests are guest which can not be modified or need to run because of other reasons with the original code base. This guests run with the VT-x/AMD-V implementations in the modern CPUs. They need QEmu and can use ioemu stubdoms

PVHVM: This guests are HVM guests for which special drivers exists for the qemu devices, which makes it possible to shrink the need of emulation because the guest knows that the devices are virtual.

Not quite. "PVHVM" is where the guest knows about more of the PV interfaces provided by Xen and uses those instead of the emulated ones. It doesn't necessarily have to do with things provided by qemu.

For example, one of the big things in PVHVM is the use the event channel interface for interrupts, rather than emulated APICs. APICs are emulated in Xen, not in qemu, so they're pretty fast. Still, each interrupt requires the guest to go into the hypervisor 3 times when using a virtual APIC (because you have to do 3 MMIO writes), but only once when using event channels.

But PVHVM guests still use qemu for emulated mouse, motherboard, cd-roms, and so on, because there's not really a performance problem there.

PVH: This guests are PV guests which can use the hardware virtualization technologies of the CPUs to do special things. About this I have still two questions: I found out that a few tasks are faster in HVM Mode so is it a try to make PV guests faster?

This is covered in the blogs, I think. There are sometimes performance advantages to using the HVM extensions, and that's a big reason to have this mode. The other big thing is to get rid of the MMU hooks in the pvops kernel, which is the source of a lot of unhappiness and stress.

And does PVH makes it easier to implement PV in an operating system kernels?

Probably, yes.


PV-GRUB: This is a stubdom where GRUB is compiled against Mini-OS to get all features of GRUB and doesn't need to use PyGRUB within Dom0.

Yes -- although I'm not sure I would call this a stubdom technically, since it runs inside the guest domain itself and goes a way once it starts. It's basically the equivalent of BIOS+grub for HVM domains.

ioemu: This stubdom is a QEmu version which is compiled against Mini-OS and it isolates the qemu process of a HVM DomU.

xenstore: This stubdom contains the xenstore service which holds a database about resources and domains. So it stores informations about which resource is attached to which domain and so on.

Would this description be right or does I think wrong?

Everything else sounds about right.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.