Re: PVH cleanups after 4.5

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Dec 05, 2014 at 10:42:27AM +0000, Andrew Cooper wrote:
> On 05/12/14 09:54, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 10:49 +0100, Tim Deegan wrote:
> >> At 09:20 +0000 on 05 Dec (1417767654), Jan Beulich wrote:
> >>>>>> On 04.12.14 at 18:25, <tim@xen.org> wrote:
> >>>> Potential feature flags, based on whiteboard notes at the session.
> >>>> Things that are 'Yes' in both columns might not need actual flags :)
> >>>>
> >>>>                      'HVM'       'PVH'
> >>>> 64bit hypercalls      Yes         Yes
> >>>> 32bit hypercalls      Yes         No
> >>> Iiuc the lack of support of 32-bit hypercalls is simply because PVH
> >>> guests aren't expected to use them as being always 64-bit right
> >>> now. I.e. I can't really see why we couldn't just enable them once
> >>> the 64-bit hypercall tables got combined, in which case we wouldn't
> >>> need a feature flag here either.
> >> Agreed -- I think the same will apply to a few other things, like shadow
> >> pagetables and some of the other MM tricks.  
> > Might we want to constrain a given PVH domain to only make 32- or 64-bit
> > hypercalls?
> >
> > Or do we consider already having crossed that bridge with HVM enough
> > reason to allow it for PVH? I'm wonder if that, even if it is
> > technically possible to support not, doing so might mitigate some
> > potential security issues down the line. There's obviously a tradeoff
> > against in-guest flexibility though.
> 
> Madating a 32/64bit split serves only to cause booting issues; you need
> to know a-priori what the eventual kernel is going to be before you
> build the domain. This is an awkward issue with PV domains which
> *really* wants not to apply to PVH as well.
> 
> PVH guests with the plan of "HVM - qemu" should be able to fully choose
> their operating mode, and allow for in-guest bootstrapping which is far
> superior from a security/isolation point of view than toolstack
> bootstrapping.

Or another use-case: kexec-ing from within an 64-bit PVH guest to an
32-bit PVH or vice-versa.

> 
> ~Andrew
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel