[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PVH cleanups after 4.5
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@xxxxxxx> 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@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |