| Message ID | 20170418073445.tk7ukhnbl4ns7r33@dhcp-3-128.uk.xensource.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 18.04.17 at 09:34, <roger.pau@citrix.com> wrote: > (XEN) Before DMA_GCMD_TE > ( > > The hang seems to happen when writing DMA_GCMD_TE to the global command > register, which enables the DMA remapping. After that the box is completely > unresponsive, not even the watchdog is working. How sure are you that this is pre-Haswell specific vs e.g. chipset or firmware (think of RMRRs [or their lack] for the latter) dependent? Iirc Elena's command line specifiable RMRR patch series was motivated by similar behavior she had observed on some system. Another odd aspect is - why would IOMMU enabling cause the hang only when intending to use a PVH Dom0? The IOMMU is being enabled in either case, which again might point at differences in use of memory. Jan
On Tue, Apr 18, 2017 at 02:48:31AM -0600, Jan Beulich wrote: > >>> On 18.04.17 at 09:34, <roger.pau@citrix.com> wrote: > > (XEN) Before DMA_GCMD_TE > > ( > > > > The hang seems to happen when writing DMA_GCMD_TE to the global command > > register, which enables the DMA remapping. After that the box is completely > > unresponsive, not even the watchdog is working. > > How sure are you that this is pre-Haswell specific vs e.g. chipset or > firmware (think of RMRRs [or their lack] for the latter) dependent? > Iirc Elena's command line specifiable RMRR patch series was > motivated by similar behavior she had observed on some system. This is mostly from trial/error. I don't think it's strictly CPU related, but rather chipset related (ie: chipsets that come with pre-haswell CPUs). Elena IIRC was at least getting IOMMU faults, which I don't even get in my case, and I think that's the issue itself. > Another odd aspect is - why would IOMMU enabling cause the hang > only when intending to use a PVH Dom0? The IOMMU is being > enabled in either case, which again might point at differences in use > of memory. Not sure, for PVH Dom0 the IOMMU is enabled quite early in the domain build process (before populating the domain p2m), which seems to be fine on other systems. I've done that (initializing the IOMMU so early) to avoid having to iterate over the list of domain pages afterwards when the IOMMU is initialized with the p2m already populated. FWIW, moving the iommu_hwdom_init call to the end of the PVH Dom0 build process doesn't solve the issue. I've also tried with and without shared pt, and the result is the same. Roger.
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c index a5c61c6e21..cb039d74e7 100644 --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -765,7 +765,9 @@ static void iommu_enable_translation(struct acpi_drhd_unit *drhd) iommu->reg); spin_lock_irqsave(&iommu->register_lock, flags); sts = dmar_readl(iommu->reg, DMAR_GSTS_REG); + printk("Before DMA_GCMD_TE\n"); dmar_writel(iommu->reg, DMAR_GCMD_REG, sts | DMA_GCMD_TE); + printk("After DMA_GCMD_TE\n"); /* Make sure hardware complete it */ IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG, dmar_readl,