Re: [Xen-devel] [PATCH v3 0/4] x86/iommu: PVH Dom0 workarounds for missing RMRR entries

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.08.18 at 10:25, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, Aug 07, 2018 at 10:45:32AM -0600, Tamas K Lengyel wrote:
>> On Tue, Aug 7, 2018 at 10:04 AM Tamas K Lengyel
>> <tamas.k.lengyel@xxxxxxxxx> wrote:
>> (XEN) [VT-D]iommu.c:919: iommu_fault_status: Fault Overflow
>> (XEN) [VT-D]iommu.c:921: iommu_fault_status: Primary Pending Fault
>> (XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr
>> 428f926000, iommu reg = ffff82c000a0c000
>> (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
>> (XEN) print_vtd_entries: iommu #0 dev 0000:00:02.0 gmfn 428f926
>> (XEN)     root_entry[00] = 43aaae001
>> (XEN)     context[10] = 2_43cf92001
>> (XEN)     l4[000] = 9c0000043cf91107
>> (XEN)     l3[10a] = 8000000000000000
>> (XEN)     l3[10a] not present
>> 
>> The fault is repeated a million times per second and the system is
>> pretty much stalled.
> 
> As Jan says, this page is outside of any range in the memory map. I
> wonder however what's in there.
> 
> I think (also seeing the PV issues) you should bring this up with the
> driver maintainers, it might actually be a bug that the driver is
> trying to access such address.

Right, especially considering that the address does not appear to be
invariant, I suspect the driver sets up some I/O from (presumably)
uninitialized data. This goes unnoticed until DMA translation comes
into play. Tamas - did you try enabling DMA translation in Linux
when not running on top of Xen? Depending on the
CONFIG_INTEL_IOMMU_DEFAULT_ON setting this may not be the
default.

> In the meantime, you can try to add to the command line:
> 
> rmrr=0x428f926=0:0:2.0
> 
> In order to force an iommu mapping of this address.

I suspect this won't help much.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel