On Fri, Jan 2, 2015 at 12:04 PM, Jan Beulich <jbeul...@suse.com> wrote:
> >>> Elena Ufimtseva <elena.ufimts...@oracle.com> 12/22/14 3:45 PM >>> > >There is a problem with booting dom0 as pvh (xen-4.5rc3, kernel 3.18.0+). > > Hi Jan. This is all bit confusing: How does the Dom0 type matter when Dom0 doesn't > even get started? > I guess I used misleading wording and wanted to make obvious that this happens only if dom0pvh is set. > >After digging a bit into this it seems that the booting gets stuck upon > enabling second IOMMU by writing to DMAR_GCMD_REG (See the attaches debug > log). > > I'm afraid the log doesn't tell too much, namely without knowing where > exactly > you added your debugging code. > I will send another console log, with debugging. The last successful command is the reading status register of second IOMMU unit: <snip from iommu_enable_translation() in ./xen/drivers/passthrough/vtd/iommu.c> 746: sts = dmar_readl(iommu->reg, DMAR_GSTS_REG); 747: dmar_writel(iommu->reg, DMAR_GCMD_REG, sts | DMA_GCMD_TE); </snip> After dmar_writel for second iommu the machine hangs. > >The boot process passes this stage if second iommu was not enabled. > >I tried multiple iommu options on boot, but it did not help. > >There is no problem booting baremetal linux with IOMMU enabled. > > Good to know, but what's more important - did any version of Xen ever boot > on that box with the IOMMU enabled? If so, what are the differences to the > non-working case? > Yes, I tried to boot it as pv dom0 and it booted just fine, taking the same codepath for enabling two iommu units. What was different is dom0pvh=1 for sure, I will have to double check if iommu info is the same. > > >The difference I have noticed its the version of microcode that is shown > in baremetal and Xen. > >Baremetal linux shows microcode version as 0x710, Xen as 0x70d, not sure > if its relevant. > > Microcode is a CPU thing, while the IOMMU is a chipset component. An > unfixed CPU erratum of course can cause all kinds of problems, but a > connection seems unlikely here. Nevertheless - why don't you just have > Xen load the newer microcode during boot? > Does not seem to be relevant now. I was hoping for some advises on magic debugging techniques I could use in this case! I will collect more data and will re-send. > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > -- Elena
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
