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

[George Dunlap <george.dunlap@eu.citrix.com>]

On 26/09/13 12:53, Tim Deegan wrote:
> Hi,
>
> 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
> necessity.
>
> 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.

  -George