Re: [Xen-devel] [RFC] utilizing EPT_MISCONFIG VM exit

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2014-02-24:
> Attached draft patch (still having debugging code in it, and assuming
> other adjustments having happened before) demonstrates that we
> should evaluate whether - not only for dealing with the memory type
> adjustments here, but for basically everything currently done through
> ->change_entry_type_global() - utilizing the EPT_MISCONFIG VM exit
> would be an architecturally clean approach. The fundamental idea
> here is to defer updates to the page tables until the respective
> entries actually get used, instead of iterating through all page tables
> when the change is being requested, thus
> - avoiding (here) or eliminating (elsewhere) long lasting operations
>   without having to introduce expensive/fragile preemption handling -
>   leaving unaffected the sharing of the page tables with the IOMMU
>   (since the EPT memory type field is available to the programmer on the
>   IOMMU side; we obviously can't use the read/write bits without
>   affecting the IOMMU)
> The main question obviously is whether it is architecturally safe to use
> any particular, presently invalid memory type (right now the patches use
> type 7, i.e. the value defined for UC- in the PAT MSR only), or whether
> such an invalid type could be determined at run time.
> 
> Obviously if on EPT we can go this route, the goal ought to be to
> eliminate ->change_entry_type_global() altogether (i.e. also from
> the generic P2M code) by using on-access adjustments instead of
> on-request ones. Quite likely that would involved adding an address
> range to ->memory_type_changed().
> 

Nice idea. Yes, the only concern is the reserved bit in EPT. I will forward 
this to internal to look for help.

> Jan


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel