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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan

Attachment: EPT-sync-mem-types.patch
Description: Text document

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