[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/grants: repurpose command line max options


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 14 Mar 2023 11:31:40 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ivOHoHI7tK6g1BR7xw9Fn2WaRzfToSvO/HB7IxNts1A=; b=AQ3uiHpCQ6pAzOGHKUdEwMR6jYXOHoSuQEUiht37o3lJBq7GXHwFiEAQzvsTRkDD3Q5OLCZW8L3SAWvJHZuq4MNvHpXSgQpvZgFHJu/Lb5cRSsEvDF5a9BQcRla2iglUMFR9vD9W4KdtmRQr/QBYeoQ4SVPnxgB2wZgb35wUvlVqpmuGtnb58YTbZ4Cm5BthCuQJOSRyo5KRHmfQimrE+Ex37m2MkNDejw55rensAReJ0x+IpbmtJwuv7I5g9LLsKmPZ3SixZtgdsbW+5JCQZRzexGHkTIP95hLqmMNTgjmqdnlERyOWIoDiENlonnawirGAhw4ewKElHdVe7gZJPQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eP7tSMex5/JKFmwunC9Q/t/DzexNIIi1eEicKwlUhpT4Lm5Ffd7nql9TA41hZ960ZJdBUIoA78q2gTqPAi7VOk4ovgIxbFgTw2tDJhp4Wm5oZ4qqovbAXQM4ruTkEpkEh4X4b56cbR62tYytaECiL7UvhdQi1m9hkCQ+GEPJhP21q3bFAMTvw0DdpG37p+ixw4vGsfseL/1Jml6YiBYRhpPII5touPd3hc4KCOHBCsgJ4quATW4qe0i6489WBRyH7yuVpnvVsw/zf3k7RWPGoQXSssOTLWaGp+enFdoiTzgsAk0ecSHSe+j6yWtPhF1wFMoamvDdrW5QTknX/muzew==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 14 Mar 2023 10:31:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 14.03.2023 11:25, Roger Pau Monné wrote:
> On Tue, Mar 14, 2023 at 11:04:21AM +0100, Jan Beulich wrote:
>> On 14.03.2023 10:22, Roger Pau Monné wrote:
>>> On Mon, Mar 13, 2023 at 05:55:09PM +0100, Jan Beulich wrote:
>>>> On 13.03.2023 13:16, Roger Pau Monne wrote:
>>>>> --- a/docs/misc/xen-command-line.pandoc
>>>>> +++ b/docs/misc/xen-command-line.pandoc
>>>>> @@ -1232,9 +1232,8 @@ The usage of gnttab v2 is not security supported on 
>>>>> ARM platforms.
>>>>>  
>>>>>  > Can be modified at runtime
>>>>>  
>>>>> -Specify the maximum number of frames which any domain may use as part
>>>>> -of its grant table. This value is an upper boundary of the per-domain
>>>>> -value settable via Xen tools.
>>>>> +Specify the default maximum number of frames which any domain may use as 
>>>>> part
>>>>> +of its grant table unless a different value is specified at domain 
>>>>> creation.
>>>>>  
>>>>>  Dom0 is using this value for sizing its grant table.
>>>>
>>>> dom0less DomU-s do as well, at the very least, also ...
>>>>
>>>>> @@ -1245,9 +1244,10 @@ Dom0 is using this value for sizing its grant 
>>>>> table.
>>>>>  
>>>>>  > Can be modified at runtime
>>>>>  
>>>>> -Specify the maximum number of frames to use as part of a domains
>>>>> -maptrack array. This value is an upper boundary of the per-domain
>>>>> -value settable via Xen tools.
>>>>> +Specify the default maximum number of frames to use as part of a domains
>>>>> +maptrack array unless a different value is specified at domain creation.
>>>>> +
>>>>> +Dom0 is using this value for sizing its maptrack array.
>>>>
>>>> ... here. And even ordinary DomU-s appear to default to that in the
>>>> absence of a specific value in the guest config. IOW at the very least
>>>> the info you add should not be misleading. Better would be if the pre-
>>>> existing info was adjusted at the same time.
>>>
>>> Aren't domUs already clearly covered by the sentence:
>>>
>>> "Specify the default maximum number of frames to use as part of a 
>>> domains..."
>>
>> Hmm, yes, my attention was caught too much by the Dom0 statement. While ...
>>
>>> IMO dom0 needs to be explicitly mentioned because in that case the
>>> value provided is not the one used by default, but rather the one that
>>> gets used.
>>
>> ... explicitly mentioning Dom0 is fine, I still think this needs wording
>> differently here, because Dom0 doesn't actively do anything with this
>> value (and, as said, it can't even obtain it other than by probing how
>> many mappings it can create).
>>
>>>> I also wonder about the specific wording down here: While the max grant
>>>> table size can indeed be queried, this isn't the case for the maptrack
>>>> array. A domain also doesn't need to know its size, so maybe "This value
>>>> is used to size all domains' maptrack arrays, unless overridden by their
>>>> guest config"?
>>>
>>> I think the wording I've added already conveys this meaning:
>>>
>>> "Specify the default maximum number of frames to use as part of a domains
>>> maptrack array unless a different value is specified at domain creation."
>>
>> Well, I mean specifically the Dom0 related statement.
>>
>> Also to me "default maximum" reads odd (and slightly ambiguous). Would
>> "default upper bound on the number of ..." perhaps be a little better?
> 
> So what about using:
> 
> "Specify the default upper bound on the number of frames which any
> domain may use as part of its grant table unless a different value is
> specified at domain creation.
> 
> Note this value is the enforced upper bound for dom0."
> 
> And similar for the maptrack option.

SGTM. (Maybe soften a little by using "effective" instead of "enforced",
but only if you don't mean to emphasize the "enforce" aspect.)

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.