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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.08.18 at 03:00, <tamas.k.lengyel@xxxxxxxxx> wrote:
> On Wed, Aug 8, 2018 at 3:54 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>
>> >>> 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.
> 
> I checked and this kernel option is not enabled. Are you suggesting to
> try booting just Linux with this option enabled to see what happens?

Well, you don't need to rebuild the kernel with the config option
enabled, you can use what you have and add "intel_iommu=on"
to the kernel command line. In case this works without any faults,
changing to "intel_iommu=on,igfx_off" may or may not provide
further insight.

>> > 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.
>>
> 
> The mfn is not always the same but seems to be at least on some
> occasion.

I expect that's because many things early at boot go pretty
deterministically.

> I managed to reboot with the right rmrr= option set but I'm
> still getting the same faults over and over for that mfn I set in the
> rmrr= option.

Hmm, and the faults still show non-present entries for these? This
options is at risk of getting misspelled - did you check that the
option you've specified actually took effect?

Jan



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