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

[Tim Deegan <tim@xxxxxxx>]

At 15:43 +0000 on 27 Mar (1395931432), Jan Beulich wrote:
> >>> On 27.03.14 at 16:25, <tim@xxxxxxx> wrote:
> > At 16:25 +0000 on 26 Mar (1395847547), Jan Beulich wrote:
> >> 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?
> 
> No, with separate tables we're fine because only p2m_ram_rw pages
> ever get entered into the IOMMU ones. I.e. in that case DMA accesses
> to that range would always fault. The problem is that if we were to
> use the EPT_MISCONFIG approach here, that wouldn't - in the shared
> tables case - affect the IOMMU until the respective page got a CPU side
> access, causing its entry's flags to be corrected.

Right, I see.  So, as you say, another reason to go back to having
separate tables.

> > But ISTR that on the AMD side, only p2m_ram_rw memory is visible via
> > the IOMMU even with shared tables.
> 
> That would be good; is that because of using bits that the IOMMU treats
> as reserved (the basic reason for p2m_ram_rw needing to be number 0)?

Yep.

Tim.

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