Re: [Xen-devel] Xen-unstable boot panic due to changeset 26517 AMD, IOMMU: Clean up old entries in remapping tables when creating new one

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.02.13 at 12:24, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
> Hmm with the patch it does boot, but disables the I/O virtualization.

Good. While, as said before, I still don't understand why it didn't
crash earlier without that patch, I'm glad it's fixed. Will post the
patch for inclusion momentarily.

> Output of xl-dmesg attached, do you still need a xen-sums of the situation 
> without the debug patch (where it does crash) ?

And you can't expect much else with broken ACPI tables:

(XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7
(XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0

This is a HPET entry.

(XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0
(XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x7

And this is an entry for IO-APIC #2 (ID 7), whereas FADT says

(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55

so the IOMMU table is lacking an entry for the first IO-APIC, and
without that we can't set up per-device interrupt remapping (in
which case we choose to disable the IOMMU altogether, albeit it
had been questioned whether that isn't making a bad situation
worse in some cases).

If you want the IOMMU back (at the price of re-opening the
security issue described in XSA-36), you'd have to pass
"iommu=amd-iommu-perdev-intremap" to the hypervisor.

Jan


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