Xen project Mailing List

On Fri, Jan 2, 2015 at 12:04 PM, Jan Beulich <jbeulich@xxxxxxxx> wrote:

>>> Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

Elena

Re: [Xen-devel] dom0 as pvh boot problem