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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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:
> Guest/Domain-Types
>
> 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.

> Stubdoms:
>
> 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.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel