On Tue, Aug 7, 2018 at 8:37 AM Roger Pau Monné <roger....@citrix.com> wrote: > > On Tue, Aug 07, 2018 at 08:29:49AM -0600, Tamas K Lengyel wrote: > > On Tue, Aug 7, 2018 at 8:04 AM Roger Pau Monne <roger....@citrix.com> wrote: > > > > > > Hello, > > > > > > The following series implement a workaround for missing RMRR > > > entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd > > > option. > > > > > > The PVH workaround identity maps all regions marked as reserved in the > > > memory map. > > > > > > Note that this workaround is enabled by default on Intel hardware. It's > > > also available to AMD hardware, although it's disabled by default in > > > that case. > > > > > > The series can be found at: > > > > > > git://xenbits.xen.org/people/royger/xen.git iommu_inclusive_v3 > > > > > > Thanks, Roger. > > > Roger Pau Monne (4): > > > iommu: introduce dom0-iommu option > > > iommu: make iommu_inclusive_mapping a suboption of dom0-iommu > > > dom0/pvh: change the order of the MMCFG initialization > > > x86/iommu: add reserved dom0-iommu option to map reserved memory > > > ranges > > > > > > docs/misc/xen-command-line.markdown | 47 +++++++++++ > > > xen/arch/x86/hvm/dom0_build.c | 9 ++- > > > xen/arch/x86/hvm/io.c | 5 ++ > > > xen/arch/x86/x86_64/mm.c | 3 +- > > > xen/drivers/passthrough/amd/iommu_init.c | 2 +- > > > xen/drivers/passthrough/amd/pci_amd_iommu.c | 11 ++- > > > xen/drivers/passthrough/arm/iommu.c | 4 + > > > xen/drivers/passthrough/iommu.c | 62 +++++++++++++-- > > > xen/drivers/passthrough/vtd/extern.h | 2 - > > > xen/drivers/passthrough/vtd/iommu.c | 25 +++--- > > > xen/drivers/passthrough/vtd/x86/vtd.c | 58 +------------- > > > xen/drivers/passthrough/x86/iommu.c | 87 +++++++++++++++++++++ > > > xen/include/asm-x86/hvm/io.h | 3 + > > > xen/include/xen/iommu.h | 8 +- > > > 14 files changed, 240 insertions(+), 86 deletions(-) > > > > > > -- > > > > Hi Roger, > > I gave this branch a spin on a Dell XPS laptop booting UEFI with Linux > > 4.18-rc8. I was able to get dom0 to boot with PVH but the physical > > keyboard of the laptop stopped working, it works no problem with just > > Linux 4.18-rc8 or PV dom0, so I had to plug in a USB keyboard. After > > running for a minute or two the system starts to slow down to the > > point where it becomes unresponsive. The xl dmesg log is filled with > > this error: > > > > (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 > > 4625f3a000, iommu reg = ffff82c00181c000 > > (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set > > (XEN) print_vtd_entries: iommu #0 dev 0000:00:02.0 gmfn 4625f3a > > Is the gmfn always the same (0x4625f3a)? > > > (XEN) root_entry[00] = 273a18001 > > (XEN) context[10] = 2_27ba35001 > > (XEN) l4[000] = 9c0000027ba34107 > > (XEN) l3[118] = 8000000000000000 > > (XEN) l3[118] not present > > Can you also paste the full xl dmesg log? I'm specially interested in > the memory map of the machine which is printed quite early during Xen > boot. >
Unfortunately I don't have serial access on this laptop and "xl dmesg" gets completely filled with that error so the beginning of the log is lost by the time I get a terminal in dom0. I'll try it on another laptop later today for which I have serial access. Across reboots the gmfn changes: (XEN) [VT-D]DMAR:[DMA Read] Request device [0000:00:02.0] fault addr 23c251000, iommu reg = ffff82c00181c000 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set (XEN) print_vtd_entries: iommu #0 dev 0000:00:02.0 gmfn 23c251 (XEN) root_entry[00] = 273a18001 (XEN) context[10] = 2_27ba35001 (XEN) l4[000] = 9c0000027ba34107 (XEN) l3[008] = 8000000000000000 (XEN) l3[008] not present Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel