From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps Date: Fri, 23 May 2014 17:35:00 +0200 Message-ID: <537F6AA4.9020501@citrix.com> References: <1400856933-1424-1-git-send-email-boris.ostrovsky@oracle.com> <537F6287.5070705@citrix.com> <537F6471.40000@oracle.com> <537F675B.8080603@citrix.com> <537F69F5.7060309@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <537F69F5.7060309@oracle.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: Boris Ostrovsky , Andrew Cooper Cc: keir@xen.org, Tim Deegan , jbeulich@suse.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 23/05/14 17:32, Boris Ostrovsky wrote: > On 05/23/2014 11:20 AM, Andrew Cooper 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. >>> >>> -boris >> 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. > > Yes, that's true. > > The problem that we have now is that if we have 'pvh=1' in the config > file the guest will fail to start if PVH is not on. Can we, for example, > revert (with a warning) to pure PV if that's the case? Won't this option go away once PVH is stable, so the toolstack can detect if the kernel supports PVH and start the guest in this mode by default? (of course falling back to PV if PVH is not supported). Roger.