From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
Connor Davis <davisc@ainfosec.com>
Subject: Re: [PATCH v3 0/4] x86/iommu: PVH Dom0 workarounds for missing RMRR entries
Date: Tue, 7 Aug 2018 08:45:07 -0600 [thread overview]
Message-ID: <CABfawhmQ557uduVUJjTMbZ3u5FWswPvbVYSUBY785Vx=qbitfA@mail.gmail.com> (raw)
In-Reply-To: <20180807143715.kscihz3wuj6mcnfi@mac>
On Tue, Aug 7, 2018 at 8:37 AM Roger Pau Monné <roger.pau@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.pau@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
next prev parent reply other threads:[~2018-08-07 14:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 14:02 [PATCH v3 0/4] x86/iommu: PVH Dom0 workarounds for missing RMRR entries Roger Pau Monne
2018-08-07 14:02 ` [PATCH v3 1/4] iommu: introduce dom0-iommu option Roger Pau Monne
2018-08-07 14:02 ` [PATCH v3 2/4] iommu: make iommu_inclusive_mapping a suboption of dom0-iommu Roger Pau Monne
2018-08-07 14:20 ` Paul Durrant
2018-08-07 14:02 ` [PATCH v3 3/4] dom0/pvh: change the order of the MMCFG initialization Roger Pau Monne
2018-08-07 14:02 ` [PATCH v3 4/4] x86/iommu: add reserved dom0-iommu option to map reserved memory ranges Roger Pau Monne
2018-08-07 14:35 ` Paul Durrant
2018-08-08 9:53 ` Roger Pau Monné
2018-08-08 9:55 ` Jan Beulich
2018-08-07 14:29 ` [PATCH v3 0/4] x86/iommu: PVH Dom0 workarounds for missing RMRR entries Tamas K Lengyel
2018-08-07 14:37 ` Roger Pau Monné
2018-08-07 14:45 ` Tamas K Lengyel [this message]
2018-08-07 15:08 ` Roger Pau Monné
2018-08-07 16:04 ` Tamas K Lengyel
2018-08-07 16:14 ` Jan Beulich
2018-08-07 16:45 ` Tamas K Lengyel
2018-08-07 16:55 ` Tamas K Lengyel
2018-08-08 8:25 ` Roger Pau Monné
2018-08-08 9:54 ` Jan Beulich
2018-08-15 1:00 ` Tamas K Lengyel
2018-08-15 6:40 ` Jan Beulich
2018-08-16 16:43 ` Tamas K Lengyel
2018-08-17 8:10 ` Jan Beulich
2018-08-17 8:53 ` Roger Pau Monné
2018-08-07 15:20 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABfawhmQ557uduVUJjTMbZ3u5FWswPvbVYSUBY785Vx=qbitfA@mail.gmail.com' \
--to=tamas.k.lengyel@gmail.com \
--cc=davisc@ainfosec.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).