From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps Date: Mon, 26 May 2014 23:03:34 -0400 Message-ID: <53840086.7050602@oracle.com> References: <1400856933-1424-1-git-send-email-boris.ostrovsky@oracle.com> <537F6287.5070705@citrix.com> <537F6471.40000@oracle.com> <537F675B.8080603@citrix.com> <5383267B0200007800015A2D@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5383267B0200007800015A2D@mail.emea.novell.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: Jan Beulich Cc: Andrew Cooper , Tim Deegan , keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 05/26/2014 05:33 AM, Jan Beulich wrote: >>>> On 23.05.14 at 17:20, wrote: >> On 23/05/14 16:08, Boris Ostrovsky wrote: >>> On 05/23/2014 11:00 AM, Andrew Cooper wrote: >>>> On 23/05/14 15:55, Boris Ostrovsky wrote: >>>>> Signed-off-by: Boris Ostrovsky >>>>> --- >>>>> xen/arch/x86/setup.c | 5 +++++ >>>>> 1 file changed, 5 insertions(+) >>>> If the plan is to try and PVH and HVM back into one mode as far as Xen >>>> is concerned, doesn't this become redundant? >>> Yes, I was thinking about this but we currently don't have (or, >>> rather, I can't think of) a good way to determine whether we can start >>> a PVH guest. We can grep the log but that doesn't feel like a >>> particularly good solution. >>> >>> One option could be to postpone this patch until 4.5 freezes and see >>> whether we indeed followed up on the plan and if we didn't then >>> integrate it. > I don't see what 4.5 has to do with this - 4.4 already has PVH > support (it being experimental and DomU only imo doesn't matter > as far as feature reporting is concerned). > >> My concern here is that if this patch gets accepted, it will have to say >> forever more as the cap strings are a very public API. > Depends how you view it - if this becomes indistinguishable from > PVH for the tools stack, it could also get dropped again. Otoh I > don't think it will (or even should) become indistinguishable, and > hence I'm not sure its functional folding with (most of) HVM would > actually be a valid reason to drop this indication again (or, if it > has to remain, to consider it deprecated and pointless). Currently PVH requires, for example, VMX's secondary exec controls. I don't know whether the plan is to drop this requirement eventually but if not then some processors might not be able to run PVH. -boris