Re: [Xen-devel] [PATCH] x86/vtx: Improvements to ept= command line handling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.12.18 at 18:16, <andrew.cooper3@xxxxxxxxxx> 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.

> --- 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.

Anyway, this is a question unrelated to the patch here, so
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan



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