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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Sep 26, 2013 at 02:46:04PM +0100, George Dunlap wrote:
> 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".

Which I think Mr. Gordon (sp?) had been doing for some of the PCI
NVidia passthrough stuff. Basically making e820_host work for HVM
guests.
> 
> 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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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