On 21/12/2018 11:13, Jan Beulich wrote:
>>>> On 20.12.18 at 18:16, <[email protected]> wrote:
>> Switch parse_ept_param() to use the parse_boolean() infrastructure for more
>> consistency with related command line parameters. Rename opt_pml_enabled to
>> opt_ept_pml for consistency with opt_ept_ad, and switch it to being bool
>>
>> Drop the comment leading comment for parse_ept_param(). It is stale, and
>> just
> Nit: There's one "comment" to many here.
Oops - will fix.
>
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -841,29 +841,37 @@ effect the inverse meaning.
>> >> Allows mapping of RuntimeServices which have no cachability attribute
>> >> set as UC.
>>
>> -### ept (Intel)
>> -> `= List of ( {no-}pml | {no-}ad )`
>> +### ept
>> +> `= List of [ ad=<bool>, pml=<bool> ]`
>>
>> -Controls EPT related features.
>> +> Applicability: Intel
>>
>> -> Sub-options:
>> -
>> -> `pml`
>> +Extended Page Tables are a feature of Intel's VT-x technology, whereby
>> +hardware manages the virtualisation of HVM guest pagetables. EPT was
>> +introduced with the Nehalem architecture.
>>
>> -> Default: `true`
>> +* The `ad` boolean controls hardware tracking of Access and Dirty bits in
>> the
>> + EPT pagetables, and was first introduced in Broadwell Server.
>>
>> ->> PML is a new hardware feature in Intel's Broadwell Server and further
>> ->> platforms which reduces hypervisor overhead of log-dirty mechanism by
>> ->> automatically recording GPAs (guest physical addresses) when guest memory
>> ->> gets dirty, and therefore significantly reducing number of EPT violation
>> ->> caused by write protection of guest memory, which is a necessity to
>> ->> implement log-dirty mechanism before PML.
>> + By default, Xen will use A/D tracking when available in hardware, except
>> + on Avoton processors affected by erratum AVR41. Explicitly choosing
>> + `ad=0` will disable the use of A/D tracking on capable hardware, whereas
>> + choosing `ad=1` will cause tracking to be used even on AVR41-affected
>> + hardware.
> Is there any reason for this special casing of the one erratum?
> Earlier this week I've gone through some spec updates for other
> purposes, and I've seen some rather frightening EPT A/D errata.
Which, out of interest? There are a few, particularly on Skylake, but
all the problematic ones I'm aware of are fixed in microcode.
~Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
