Re: PVH dom0 creation fails - the system freezes

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf
> Of Roger Pau Monné
> Sent: 25 July 2018 15:12
> To: bercarug@amazon.com
> Cc: xen-devel <xen-devel@lists.xenproject.org>; David Woodhouse
> <dwmw2@infradead.org>; Jan Beulich <JBeulich@suse.com>;
> abelgun@amazon.com
> Subject: Re: [Xen-devel] PVH dom0 creation fails - the system freezes
> 
> On Wed, Jul 25, 2018 at 04:57:23PM +0300, bercarug@amazon.com wrote:
> > On 07/25/2018 04:35 PM, Roger Pau Monné wrote:
> > > On Wed, Jul 25, 2018 at 01:06:43PM +0300, bercarug@amazon.com
> wrote:
> > > > On 07/24/2018 12:54 PM, Jan Beulich wrote:
> > > > > > > > On 23.07.18 at 13:50, <bercarug@amazon.com> wrote:
> > > > > > For the last few days, I have been trying to get a PVH dom0 running,
> > > > > > however I encountered the following problem: the system seems
> to
> > > > > > freeze after the hypervisor boots, the screen goes black. I have
> tried to
> > > > > > debug it via a serial console (using Minicom) and managed to get
> some
> > > > > > more Xen output, after the screen turns black.
> > > > > >
> > > > > > I mention that I have tried to boot the PVH dom0 using different
> kernel
> > > > > > images (from 4.9.0 to 4.18-rc3), different Xen  versions (4.10, 4.11,
> 4.12).
> > > > > >
> > > > > > Below I attached my system / hypervisor configuration, as well as
> the
> > > > > > output captured through the serial console, corresponding to the
> latest
> > > > > > versions for Xen and the Linux Kernel (Xen staging and Kernel from
> the
> > > > > > xen/tip tree).
> > > > > > [...]
> > > > > > (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 Write] Request device [0000:00:14.0] fault
> addr 8deb3000, iommu reg = ffff82c00021b000
> > > Can you figure out which PCI device is 00:14.0?
> > This is the output of lspci -vvv for device 00:14.0:
> >
> > 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI
> > Controller (rev 31) (prog-if 30 [XHCI])
> >         Subsystem: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller
> >         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+
> > Stepping- SERR+ FastB2B- DisINTx+
> >         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> > <TAbort- <MAbort+ >SERR- <PERR- INTx-
> >         Latency: 0
> >         Interrupt: pin A routed to IRQ 178
> >         Region 0: Memory at a2e00000 (64-bit, non-prefetchable) [size=64K]
> >         Capabilities: [70] Power Management version 2
> >                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
> > PME(D0-,D1-,D2-,D3hot+,D3cold+)
> >                 Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> >         Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
> >                 Address: 00000000fee0e000  Data: 4021
> >         Kernel driver in use: xhci_hcd
> >         Kernel modules: xhci_pci
> 
> I'm afraid your USB controller is missing RMRR entries in the DMAR
> ACPI tables, thus causing the IOMMU faults and not working properly.
> 
> You could try to manually add some extra rmrr regions by appending:
> 
> rmrr=0x8deb3=0:0:14.0
> 
> To the Xen command line, and keep adding any address that pops up in
> the iommu faults. This is of course quite cumbersome, but there's no
> way to get the required memory addresses if the data in RMRR is
> wrong/incomplete.
> 

You could just add all E820 reserved regions in there. That will almost certainly cover it.

  Paul

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