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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

Jan


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