On 8/6/18 1:40 am, Alex Williamson wrote: > On Fri, 8 Jun 2018 01:19:07 +1000 > Alexey Kardashevskiy <aik@xxxxxxxxx> wrote: > >> Hi Alex, >> >> I got a dell x86 machine with Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz and I >> am passing one of two EHCI hosts - 00:1a.0 - to a guest, and at first it >> worked but now it would not start the guest at all and all I see in dmesg >> related to the thing is: >> >> [ 338.331640] vfio-pci 0000:00:1a.0: enabling device (0000 -> 0002) >> [ 338.433717] vfio_cap_init: 0000:00:1a.0 hiding cap 0xa >> [ 352.296443] perf: interrupt took too long (8678 > 8277), lowering >> kernel.perf_event_max_sample_rate to 23000 >> [ 381.438215] perf: interrupt took too long (11304 > 10847), lowering >> kernel.perf_event_max_sample_rate to 17000 >> [ 417.441806] DMAR: DRHD: handling fault status reg 3 >> [ 417.441813] DMAR: [DMA Read] Request device [00:1a.0] fault addr eb000 >> [fault reason 06] PTE Read access is not set >> >> >> Does this look any familiar? Thanks. > > Chances are the fault address falls within an RMRR, which is a VT-d > specific abomination onto IOMMUs. The short version, aiui, is that the > onboard USB controller provides PS/2 mouse and keyboard emulation for > legacy OSes via memory ranges configured by the BIOS and the RMRR is > used to request that the range be identity mapped for the device when > the IOMMU is enabled. As Linux is not a legacy OS, we ignore the RMRR > when the device is assigned, but it's still not uncommon to get these > stray reads that are usually benign. As such, it's probably not > causing the issue. More likely, given the works-once behavior, is that > we probably have no means to reset the device between uses and someone > left it in a state that we're not recovering from. Turns out I was too impatient, the reset takes up to a minute but seems always working. > For root complex > integrated endpoints, if there's no FLR or even PM reset available, > you're out of luck unless you can come up with a device specific > reset. With a plugin card, we'd probably at least be able to perform a > secondary bus reset. The plugin card I got is a pcie nec d720101 which does not have msi/msix and shares intx and does not support intx masking via the command register => no vfio, so it is arguable :) -- Alexey
