Re: [Xen-devel] [PATCH 0/8] x86/EPT: various adjustments

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.03.14 at 16:23, <JBeulich@xxxxxxxx> wrote:
> 1: p2m: make p2m_change_type() behavior match p2m_change_entry_type_global()'s
> 2: EPT: simplification and cleanup
> 3: EPT: also dump permissions and memory types
> 4: EPT: relax treatment of APIC MFN
> 5: vMTRR: pass domain to mtrr_*_msr_set()
> 6: EPT: force re-evaluation of memory type as necessary
> 7: EPT: split super pages upon mismatching memory types
> 8: EPT: IOMMU snoop capability should not affect memory type selection

Beyond this series comes the question of how to further leverage
this: One aspect (re-doing the XSA-60 fix) was already mentioned
in one of the patches. The other is that of avoiding the long running
nature of ept_change_entry_type_global(). That function is being
used for log dirty {en,dis}abling and as a safeguard in the PCI MSI-X
handling code. Whether to do so depends on the answers to a
couple of questions:

1) There's a behavioral discrepancy between shared EPT/IOMMU page
tables and separate ones. This was to some degree already discussed
in the context of what became commit 077fc1c0 ("When enabling log
dirty mode, it sets all guest's memory to readonly", see
http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg00756.html)
with the promise to work on a better solution
(http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01230.html)
not having seen any action so far.

When the tables are shared, a switch to log-dirty mode will result in
IOMMU faults on DMA writes, whereas with separate tables no faults
would occur, but the log-dirty logic wouldn't know of the dirtied pages.
In the discussion above it was being said that migration with passed
through devices isn't supported anyway, but it seems to me that this
shouldn't be a long term statement of ours.

The question is whether it would be tolerable to make this more
"undefined" by also using the EPT_MISCONFIG VM exit here: From
the IOMMU perspective, some (initially all) of the pages would remain
writable, while with the propagation logic in the VM exit handler some
could then become readonly.

2) The other discrepancy is that of which pages get entered into the
page tables in the first place: Obviously for the CPU side (EPT) all
guest visible memory must be mapped. Otoh in the separate IOMMU
page tables case only p2m_ram_rw pages would ever get mapped
into those page tables, resulting in IOMMU faults should a device be
programmed to do DMA to/from any other region.

This particularly matters for the MSI-X fallback code, which gets into
action only when running with a Dom0 not [properly] making use of
PHYSDEVOP_prepare_msix. Considering that a first option might be
to rip that fallback out altogether, and kill the affected guest (even
if it's innocent) instead.

The other alternative, keeping the code, could again entertain the
EPT_MISCONFIG VM exit: Considering that in the separate tables
case DMA to p2m_mmio_direct pages faults anyway, IOMMU faults
due to the write protection that's being enforced here wouldn't
matter much. The problem, however, is that the EPT_MISCONFIG
approach specifically leaves the pages accessible by the IOMMU until
a particular page gets its memory type (and for the purpose here
then also access permissions) fixed up. Which imo is another
argument for doing away with the shared page tables.

3) As validly pointed out by Tim already, all this only deals with the
long-runningness on Intel systems, yet to fully address the issue
we'd also need some solution on the AMD side. So the question
regarding possible solutions there goes to AMD.

Jan



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