Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.08.17 at 17:16, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 24/08/17 16:01, Juergen Gross wrote:
>> On 24/08/17 16:50, Andrew Cooper wrote:
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -868,6 +868,19 @@ Controls EPT related features.
>>>  
>>>  Specify which console gdbstub should use. See **console**.
>>>  
>>> +### gnttab
>>> +> `= List of [ max_ver:<integer>, transitive ]`
>>> +
>>> +> Default: `gnttab=max_ver:2,transitive`
>>> +
>>> +Control various aspects of the grant table behaviour available to guests.
>>> +
>>> +* `max_ver` Select the maximum grant table version to offer to guests.  
>>> Valid
>>> +version are 1 and 2.
>>> +* `transitive` Permit or disallow the use of transitive grants.  Note that 
>>> the
>>> +use of grant table v2 without transitive grants is an ABI breakage from the
>>> +guests point of view.
>> So shouldn't there be a way for the guest to query the support of
>> transient grants?
> 
> Ideally yes, but how do you suggest doing this in a compatible way?
> 
> All Xen downstreams which haven't backported the eventual transitive
> fixes will have this clobber in place, without any query-ability.

That workaround should not be used as an argument to not
provide a way to query the capability. It was put in place knowing
that it would cause problems for (hypothetical) guests using
transitive grants.

I'm not sure Jürgen's ELF note suggestion would be very useful
though: I don't see how Xen knowing a guest kernel can deal with
the situation would change anything - I don't think we should
fail the loading of a kernel without such a note when transitive
grants are disabled, not the least because we know of no kernels
using them, and hence we'd pointlessly prevent the use of older
kernels in such a case.

What about a negative XENFEAT_*? New code could query it,
and existing code is hosed anyway if run on such a system.

Jan

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