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

[Tim Deegan <tim@xxxxxxx>]

At 16:25 +0000 on 26 Mar (1395847547), Jan Beulich wrote:
> >>> 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.

Well, there are other problems with migration with passed-through
devices.   Until we support restartable DMA on IOMMU faults, we can't
even begin to go near that.  And once we do, we should just feed those
IOMMU faults through the same path as CPU pagefaults and everything will
just come out in the wash.

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

The proposed uses of EPT_MISCONFIG seem OK to me -- they're entirely
to enforce correct emulation of CPU/MMU behaviour, which has no
equivalent in DMA anyway.

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

So with the current fallback code, if we use shared tables it works OK
but with separate tables it doesn't (and never has) because the
mapping's not propagated?

But ISTR that on the AMD side, only p2m_ram_rw memory is visible via
the IOMMU even with shared tables.

I suspect that I don't understand the problem properly yet. :)

Tim.

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

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