Defaults differ for Arm and x86, not the least because of v2 not even
being security supported on Arm.

Also drop a bogus sentence from gnttab_max_maptrack_frames, which was
presumably mistakenly cloned from gnttab_max_frames (albeit even there
what is being said is neither very precise nor very useful imo).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1177,7 +1177,8 @@ Specify which console gdbstub should use
 ### gnttab
 > `= List of [ max-ver:<integer>, transitive=<bool>, transfer=<bool> ]`
 
-> Default: `gnttab=max-ver:2,transitive,transfer`
+> Default (Arm): `gnttab=max-ver:1`
+> Default (x86): `gnttab=max-ver:2,transitive,transfer`
 
 Control various aspects of the grant table behaviour available to guests.
 
@@ -1217,8 +1218,6 @@ Specify the maximum number of frames to
 maptrack array. This value is an upper boundary of the per-domain
 value settable via Xen tools.
 
-Dom0 is using this value for sizing its maptrack table.
-
 ### global-pages
     = <boolean>

Hi Jan,

On 28/02/2022 10:19, Jan Beulich wrote:
> Defaults differ for Arm and x86, not the least because of v2 not even
> being security supported on Arm.
> 
> Also drop a bogus sentence from gnttab_max_maptrack_frames, which was
> presumably mistakenly cloned from gnttab_max_frames (albeit even there
> what is being said is neither very precise nor very useful imo).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1177,7 +1177,8 @@ Specify which console gdbstub should use
>   ### gnttab
>   > `= List of [ max-ver:<integer>, transitive=<bool>, transfer=<bool> ]`
>   
> -> Default: `gnttab=max-ver:2,transitive,transfer`
> +> Default (Arm): `gnttab=max-ver:1`
> +> Default (x86): `gnttab=max-ver:2,transitive,transfer`

AFAICT, the default would not be correct on x86 when CONFIG_PV=n because 
transfer is not available.

Cheers,

-- 
Julien Grall

On 28.02.2022 15:02, Julien Grall wrote:
> On 28/02/2022 10:19, Jan Beulich wrote:
>> Defaults differ for Arm and x86, not the least because of v2 not even
>> being security supported on Arm.
>>
>> Also drop a bogus sentence from gnttab_max_maptrack_frames, which was
>> presumably mistakenly cloned from gnttab_max_frames (albeit even there
>> what is being said is neither very precise nor very useful imo).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -1177,7 +1177,8 @@ Specify which console gdbstub should use
>>   ### gnttab
>>   > `= List of [ max-ver:<integer>, transitive=<bool>, transfer=<bool> ]`
>>   
>> -> Default: `gnttab=max-ver:2,transitive,transfer`
>> +> Default (Arm): `gnttab=max-ver:1`
>> +> Default (x86): `gnttab=max-ver:2,transitive,transfer`
> 
> AFAICT, the default would not be correct on x86 when CONFIG_PV=n because 
> transfer is not available.

I can certainly split it in two x86 lines, one for PV and one for HVM.
I would not have thought I need to go that far, though.

Jan

Hi Jan,

On 28/02/2022 14:32, Jan Beulich wrote:
> On 28.02.2022 15:02, Julien Grall wrote:
>> On 28/02/2022 10:19, Jan Beulich wrote:
>>> Defaults differ for Arm and x86, not the least because of v2 not even
>>> being security supported on Arm.
>>>
>>> Also drop a bogus sentence from gnttab_max_maptrack_frames, which was
>>> presumably mistakenly cloned from gnttab_max_frames (albeit even there
>>> what is being said is neither very precise nor very useful imo).
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -1177,7 +1177,8 @@ Specify which console gdbstub should use
>>>    ### gnttab
>>>    > `= List of [ max-ver:<integer>, transitive=<bool>, transfer=<bool> ]`
>>>    
>>> -> Default: `gnttab=max-ver:2,transitive,transfer`
>>> +> Default (Arm): `gnttab=max-ver:1`
>>> +> Default (x86): `gnttab=max-ver:2,transitive,transfer`
>>
>> AFAICT, the default would not be correct on x86 when CONFIG_PV=n because
>> transfer is not available.
> 
> I can certainly split it in two x86 lines, one for PV and one for HVM.
> I would not have thought I need to go that far, though.

I thought I would mention it because to me it feels odd to correct the 
default on Arm but keep the x86 one potentially inacurrate.

Anyway, I am ok if you prefer to keep it like that. This is already an 
improvement for Arm:

Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall