On Mon, Aug 28, 2017 at 06:14:45AM +0000, Tian, Kevin wrote: > > From: Jan Beulich [mailto:jbeul...@suse.com] > > Sent: Wednesday, August 23, 2017 4:19 PM > > To: Roger Pau Monne <roger....@citrix.com> > > Cc: Tian, Kevin <kevin.t...@intel.com>; xen-de...@lists.xenproject.org > > Subject: Re: [Xen-devel] [PATCH v2 3/4] x86/vtd: introduce a PVH > > implementation of iommu_inclusive_mapping > > > > >>> On 22.08.17 at 16:01, <roger....@citrix.com> wrote: > > > On Tue, Aug 22, 2017 at 06:31:27AM -0600, Jan Beulich wrote: > > >> >>> On 11.08.17 at 18:43, <roger....@citrix.com> wrote: > > >> > On certain Intel systems, as far as I can tell almost all pre-Haswell > > >> > ones, > > >> > trying to boot a PVH Dom0 will freeze the box completely, up to the > > point that > > >> > not even the watchdog works. The freeze happens exactly when > > enabling the DMA > > >> > remapping in the IOMMU, the last line seen is: > > >> > > > >> > (XEN) [VT-D]iommu_enable_translation: iommu->reg = > > ffff82c00021b000 > > >> > > > >> > In order to workaround this (which seems to be a lack of proper RMRR > > entries, > > >> > plus the IOMMU being unable to generate faults and freezing the > > entire system) > > >> > add a PVH specific implementation of iommu_inclusive_mapping, that > > maps > > >> > non-RAM, non-unusable regions into Dom0 p2m. Note that care is > > taken to not map > > >> > device MMIO regions that Xen is emulating, like the local APIC or the > > >> > IO > > APIC. > > >> > > > >> > Signed-off-by: Roger Pau Monné <roger....@citrix.com> > > >> > > >> I don't mean to object to the patch, but it certainly would be helpful > > >> to understand the behavior a little better, in particular also to > > >> perhaps be able to derive what RMRRs are missing (which could > > >> then be added via command line option instead of this all-or-norhing > > >> approach). Kevin, could you perhaps help here? > > > > > > I tied that, but since the system freezes completely I have no idea > > > what's missing. It's quite clear to me that it's related to the IOMMU > > > and it's inability to properly generate a fault, but further than that > > > I have no other clue. > > > > Hence my request for Kevin to help (perhaps indirectly by pulling > > in other Intel folks). Someone being able to check what the chipset > > actually does or being able to observe what's going on in a logic > > analyzer should be able to explain the observed behavior. > > > > We don't have logic analyzer specifically to examine VTd, but yes > we can help have a try whether it's reproducible in our side and > then do some analysis. > > what's the hardware configuration?
It's a Dell Precision T3600 with Xeon(R) CPU E5-1607 0 @ 3.00GHz, a C600/X79 chipset and BIOS version A14. Just trying to boot a Xen kernel with dom0=pvh will show the issue (ie: you won't be able to reach the panic at the end of the Dom0 builder because the box will get stuck in the iommu_hwdom_init call). Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
