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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> 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+).

This is all bit confusing: How does the Dom0 type matter when Dom0 doesn't
even get started?

>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.

>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?

>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?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel