Re: [PATCH v2 3/4] x86/vtd: introduce a PVH implementation of iommu_inclusive_mapping

["Tian, Kevin" <kevin.tian@intel.com>]

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, August 23, 2017 4:19 PM
> To: Roger Pau Monne <roger.pau@citrix.com>
> Cc: Tian, Kevin <kevin.tian@intel.com>; xen-devel@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.pau@citrix.com> wrote:
> > On Tue, Aug 22, 2017 at 06:31:27AM -0600, Jan Beulich wrote:
> >> >>> On 11.08.17 at 18:43, <roger.pau@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.pau@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?

Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel