[PATCH] x86: Expose hypervisor's PVH support via xen_caps

[PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/setup.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index b2a808a..59b31b1 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1462,6 +1462,11 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
         safe_strcat(*info, s);
         snprintf(s, sizeof(s), "hvm-%d.%d-x86_64 ", major, minor);
         safe_strcat(*info, s);
+        if ( hvm_funcs.pvh_supported )
+        {
+            snprintf(s, sizeof(s), "pvh-%d.%d-x86_64 ", major, minor);
+            safe_strcat(*info, s);
+        }
     }
 }
 
-- 
1.8.1.4

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Andrew Cooper]

On 23/05/14 15:55, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  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?

~Andrew

>
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index b2a808a..59b31b1 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1462,6 +1462,11 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
>          safe_strcat(*info, s);
>          snprintf(s, sizeof(s), "hvm-%d.%d-x86_64 ", major, minor);
>          safe_strcat(*info, s);
> +        if ( hvm_funcs.pvh_supported )
> +        {
> +            snprintf(s, sizeof(s), "pvh-%d.%d-x86_64 ", major, minor);
> +            safe_strcat(*info, s);
> +        }
>      }
>  }
>  

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Boris Ostrovsky]

On 05/23/2014 11:00 AM, Andrew Cooper wrote:
> On 23/05/14 15:55, Boris Ostrovsky wrote:
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   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

>
> ~Andrew
>
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index b2a808a..59b31b1 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1462,6 +1462,11 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
>>           safe_strcat(*info, s);
>>           snprintf(s, sizeof(s), "hvm-%d.%d-x86_64 ", major, minor);
>>           safe_strcat(*info, s);
>> +        if ( hvm_funcs.pvh_supported )
>> +        {
>> +            snprintf(s, sizeof(s), "pvh-%d.%d-x86_64 ", major, minor);
>> +            safe_strcat(*info, s);
>> +        }
>>       }
>>   }
>>   

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Andrew Cooper]

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 <boris.ostrovsky@oracle.com>
>>> ---
>>>   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.

~Andrew

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Boris Ostrovsky]

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 <boris.ostrovsky@oracle.com>
>>>> ---
>>>>    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?

-boris

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Roger Pau Monné]

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 <boris.ostrovsky@oracle.com>
>>>>> ---
>>>>>    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.

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Boris Ostrovsky]

On 05/23/2014 11:35 AM, Roger Pau Monné wrote:
> 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 <boris.ostrovsky@oracle.com>
>>>>>> ---
>>>>>>     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).

Yes, it will, by virtue of hypervisor never having to take this action 
(reverting to PV) since PVH would be stable and always supported.

I just don't know whether ignoring pvh=1 directive on systems where PVH 
is not supported is acceptable. (Your "of course" seems to indicate that 
you think it is.)

-boris

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Ian Campbell]

On Fri, 2014-05-23 at 11:53 -0400, Boris Ostrovsky wrote:
> On 05/23/2014 11:35 AM, Roger Pau Monné wrote:
> > 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 <boris.ostrovsky@oracle.com>
> >>>>>> ---
> >>>>>>     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).
> 
> Yes, it will, by virtue of hypervisor never having to take this action 
> (reverting to PV) since PVH would be stable and always supported.

This ignores hardware which cannot support pvh and guest kernels which
are lacking the support for it.

> I just don't know whether ignoring pvh=1 directive on systems where PVH 
> is not supported is acceptable. (Your "of course" seems to indicate that 
> you think it is.)

The ideal case would be that you don't say pvh=anything and the
toolstack will automatically use pvh if the h/w and kernel both support
it, otherwise it will use pv.

If you say pvh=1 then the toolstack should unconditionally attempt to
create a pvh guest, and if the hypervisor rejects an attempt to create
such a domain then it should fail, because this is what you have asked
for with pvh=1.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[boris ostrovsky]

On 5/28/2014 5:42 AM, Ian Campbell wrote:
> On Fri, 2014-05-23 at 11:53 -0400, Boris Ostrovsky wrote:
>> On 05/23/2014 11:35 AM, Roger Pau Monné wrote:
>>> 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 <boris.ostrovsky@oracle.com>
>>>>>>>> ---
>>>>>>>>      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).
>> Yes, it will, by virtue of hypervisor never having to take this action
>> (reverting to PV) since PVH would be stable and always supported.
> This ignores hardware which cannot support pvh and guest kernels which
> are lacking the support for it.
>
>> I just don't know whether ignoring pvh=1 directive on systems where PVH
>> is not supported is acceptable. (Your "of course" seems to indicate that
>> you think it is.)
> The ideal case would be that you don't say pvh=anything and the
> toolstack will automatically use pvh if the h/w and kernel both support
> it, otherwise it will use pv.

But don't we want to let the user now whether PVH is supported? Could it 
be that they may only want to start a guest in PVH mode? (I realize that 
I am contradicting my own suggestion to ignore pvh=1).

-boris

>
> If you say pvh=1 then the toolstack should unconditionally attempt to
> create a pvh guest, and if the hypervisor rejects an attempt to create
> such a domain then it should fail, because this is what you have asked
> for with pvh=1.


Then we need some sort of indication of PVH is support so that users 
know whether they can supply pvh=1.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Mukesh Rathor]

On Wed, 28 May 2014 10:42:37 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2014-05-23 at 11:53 -0400, Boris Ostrovsky wrote:
> > On 05/23/2014 11:35 AM, Roger Pau Monné wrote:
> > > 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 <boris.ostrovsky@oracle.com>
> > >>>>>> ---
...
> > >> 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).
> > 
> > Yes, it will, by virtue of hypervisor never having to take this
> > action (reverting to PV) since PVH would be stable and always
> > supported.
> 
> This ignores hardware which cannot support pvh and guest kernels which
> are lacking the support for it.
> 
> > I just don't know whether ignoring pvh=1 directive on systems where
> > PVH is not supported is acceptable. (Your "of course" seems to
> > indicate that you think it is.)
> 
> The ideal case would be that you don't say pvh=anything and the
> toolstack will automatically use pvh if the h/w and kernel both
> support it, otherwise it will use pv.

Correct, thats how I visualized it would be some day when the pending
work including performance, is all done.

> If you say pvh=1 then the toolstack should unconditionally attempt to
> create a pvh guest, and if the hypervisor rejects an attempt to create
> such a domain then it should fail, because this is what you have asked
> for with pvh=1.

Concur again. That would somewhat enforce/encourage problems to be 
reported/caught IMO.

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Jan Beulich]

>>> On 23.05.14 at 17:20, <andrew.cooper3@citrix.com> 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 <boris.ostrovsky@oracle.com>
>>>> ---
>>>>   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).

Jan

Re: [PATCH] x86: Expose hypervisor's PVH support via xen_caps

[Boris Ostrovsky]

On 05/26/2014 05:33 AM, Jan Beulich wrote:
>>>> On 23.05.14 at 17:20, <andrew.cooper3@citrix.com> 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 <boris.ostrovsky@oracle.com>
>>>>> ---
>>>>>    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