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

[Tim Deegan <tim@xxxxxxx>]

At 13:05 +0000 on 24 Feb (1393243536), Jan Beulich wrote:
> 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)

Looks like a pretty good plan to me. :)

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

Another question is whether we can easily do the same on AMD.  The AMD
nested pagetable fault will flag reserved-bit errors in EXITINFO1,
which looks good enough, but the AMD IOMMU spec lists all the PTE's
reserved bits as reserved in IOMMU too. :|

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

Sure, that makes sense.

Tim.

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