From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: PVH cleanups after 4.5 Date: Fri, 5 Dec 2014 10:42:27 +0000 Message-ID: <54818C13.8020207@citrix.com> References: <20141204172511.GF43116@deinos.phlegethon.org> <54818706020000780004D07D@mail.emea.novell.com> <20141205094914.GC25082@deinos.phlegethon.org> <1417773296.22808.50.camel@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 1XwqLK-0001Vk-8Y for xen-devel@lists.xenproject.org; Fri, 05 Dec 2014 10:42:34 +0000 In-Reply-To: <1417773296.22808.50.camel@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: Ian Campbell , Tim Deegan Cc: xen-devel@lists.xenproject.org, Jan Beulich List-Id: xen-devel@lists.xenproject.org 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. ~Andrew