On 07/08/18 15:45, Tamas K Lengyel wrote:
> 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.
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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
