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

Re: [Xen-devel] [PATCH RFC v13 03/20] Introduce pv guest type and has_hvm_container macros

On 26/09/13 12:53, Tim Deegan wrote:

At 17:49 +0100 on 23 Sep (1379958583), George Dunlap wrote:
The goal of this patch is to classify conditionals more clearly, as to
whether they relate to pv guests, hvm-only guests, or guests with an
"hvm container" (which will eventually include PVH).
  - speculative wombling begins -

Reading this for the (apparently) 13th time, it strikes me that this
distinction feels wrong, like entities are being multiplied beyond

A PVH guest is basically a HVM guest that starts with paging enabled and
uses event channel instead of virtual APIC.

I'm not sure this needs any special treatment from Xen.  We can supply a
PVH guest with an APIC and if it never uses it, fine.  And we can supply
all HVM guests with any extra hypercalls that PVH needs (for vcpu
bringup &c).  Things like not having a qemu process to serve ioreqs can
be arranged by the toolstack.

This is from a position of ignorance, of course, and I'm happy to be
corrected by the people who've actually been hacking on the code.

As I've been putting the series together, I've wondered the same myself.

There's more to not having a qemu than just not starting qemu, of course; a lot of the HVM codepaths assume that there is one and will dereference structures which will be empty. But that should be fairly easy to fix.

Having the PV e820 map makes sense, but you can file that under "make available to hvm guests as well".

The main things left are the PV paths for cpuid, PIO, and forced emulated ops. I haven't taken a close look at how these differ, or what benefit is gained from using the PV version over the HVM version.

The other big thing is being able to set up more state when bringing up a vcpu.

One reason to disable unneeded things is the security angle: there is a risk, no matter how small, that there is somehow an exploitable bug in our emulated APIC / PIT code; so running with the code entirely disabled is more secure than running with it enabled but just not used.

But it's possible that we could just add a few options to the existing "HVM mode" that would implement all of this.


Xen-devel mailing list



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