From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: PVH cleanups after 4.5 Date: Fri, 5 Dec 2014 11:27:04 -0500 Message-ID: <20141205162704.GG472@laptop.dumpdata.com> References: <20141204172511.GF43116@deinos.phlegethon.org> <54818706020000780004D07D@mail.emea.novell.com> <20141205094914.GC25082@deinos.phlegethon.org> <1417773296.22808.50.camel@citrix.com> <54818C13.8020207@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xwvis-0006pI-U6 for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 16:27:15 +0000 Content-Disposition: inline In-Reply-To: <54818C13.8020207@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: xen-devel@lists.xenproject.org, Tim Deegan , Ian Campbell , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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, 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