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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, March 27, 2014 12:26 AM
> 
> >>> 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:

join this thread late. will spend some time to understanding the whole
story first, before giving my comments.

Thanks
Kevin

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