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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/08/18 15:45, Tamas K Lengyel wrote:
> On Tue, Aug 7, 2018 at 8:37 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> 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@xxxxxxxxxx> 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.

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index a911958..9c1ee0a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -81,7 +81,7 @@ custom_runtime_param("console_timestamps",
parse_console_timestamps);
 static uint32_t __initdata opt_conring_size;
 size_param("conring_size", opt_conring_size);
 
-#define _CONRING_SIZE 16384
+#define _CONRING_SIZE KB(512)
 #define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
 static char __initdata _conring[_CONRING_SIZE];
 static char *__read_mostly conring = _conring;

Sadly, the conring_size= option is almost completely useless, because
the smaller ring tends to truncate before it gets realloc()'d to be larger.

~Andrew

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