Comment 143 for bug 2034477

#62

> See above, this may not be an AMD bug, but if the magic enable sequence is
> AMD specific then IMHO it should still be guarded by some AMD check.

No; it is not an AMD specific sequence. No magic here, this behaves like a standard PIC. If anything; "the magic base address" is specific to Lenovo's BIOS.

It's setting the 8259 vector base to 0x68 and then configuring it to run in 8086 mode. You can see some similar code examples here:

https://wiki.osdev.org/8259_PIC#Code_Examples

>Which presumably really don't have anything at the PIC io addresses in the
>specific VM config which triggers this.

I think we need the author of this commit to confirm. When we agree on a patch we need them in the "To" line.
e179f6914152 ("x86, irq, pic: Probe for legacy PIC and set legacy_pic appropriately")

>Also note that such configs really should set the acpi-reduced-hw flag at
>which point probe_8259A() will not be called at all, because the legacy_pic
>pointer is already set to the NULL PIC early on then.

ACPI hardware reduced has lots of other non-obvious implications.
As you noticed from the above testing suspend/resume got broken by using ACPI hardware reduced.

> This is non AMD specific and should be harmless in the case where there
> really is no PIC:

So the problem with this approach is that it's attempting to program a vector base that might not work for all systems. It /happens/ to work on these Lenovo ones, but I don't know about others.

#63

OK then there is a secondary issue with the BIOS configuration and usage of the IOMMU.
Let's treat it separately from this issue.