Re: [Xen-devel] [PATCH v3 1/7] docs: Improve documentation for dom0= and dom0-iommu=

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.01.19 at 20:51, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/01/2019 11:52, Jan Beulich wrote:
>>>>> On 16.01.19 at 10:00, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -636,61 +636,83 @@ trace feature is only enabled in debugging builds of 
>>> Xen.
>>>  
>>>  Specify the bit width of the DMA heap.
>>>  
>>> -### dom0 (x86)
>>> -> `= List of [ pvh | shadow | verbose ]`
>>> +### dom0
>>> +    = List of [ pvh=<bool>, shadow=<bool>, verbose=<bool> ]
>>>  
>>> -> Sub-options:
>>> +    Applicability: x86
>>>  
>>> -> `pvh`
>>> +Controls for how dom0 is constructed on x86 systems.
>>>  
>>> -> Default: `false`
>>> +*   The `pvh` boolean controls whether dom0 is constructed as a PV or a PVH
>>> +    guest.  The default is PV.  In addition, the following requirements 
>>> must
>>> +    be met:
>>>  
>>> -Flag that makes a dom0 boot in PVHv2 mode.
>>> +    *   The dom0 kernel selected by the boot loader must be capable of the
>>> +        selected mode.
>>> +    *   For a PV dom0, Xen must have been compiled with `CONFIG_PV` 
>>> enabled.
>>> +    *   For a PVH dom0, Xen must have been compiled with `CONFIG_HVM` 
>>> enabled,
>>> +        and the hardware must have VT-x/SVM extensions available.
>>>  
>>> -> `shadow`
>>> +*   The `shadow` boolean is only applicable when dom0 is constructed as a 
>>> PVH
>>> +    guest, and controls whether dom0 uses hardware assisted paging, or 
>>> shadow
>>> +    paging.  The default is HAP when available, and shadow otherwise.
>>>  
>>> -> Default: `false`
>>> +    This option is unavailable when `CONFIG_SHADOW_PAGING` is compiled 
>>> out.  A
>>> +    PVH dom0 cannot be used if `CONFIG_SHADOW_PAGING` is compiled out, and 
>>> the
>>> +    hardware is not HAP-capable.
>> As mentioned elsewhere, I object to adding CONFIG_* into this doc,
>> which is intended to be meaningful to non-developers. But not to the
>> degree of NAK-ing the whole thing, if everyone else disagrees with me.
> 
> I'm not sure what else to say.  I object to purposefully omitting
> relevant information from our documentation.

But I'm not asking to omit the information. I'm asking to present it
in a way understandable to anyone, irrespective of their Kconfig
knowledge.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel