Hello, A bug has recently been discovered internally, where a 4.14 dom0 was observed to be doing this:
(XEN) [ 16.035377] emul-priv-op.c:1166:d0v0 Domain attempted WRMSR 0000001b from 0x00000000fee00d00 to 0x00000000fee00100 (XEN) [ 16.035392] emul-priv-op.c:1166:d0v0 Domain attempted WRMSR 0000001b from 0x00000000fee00d00 to 0x00000000fee00900 ... (XEN) [ 18.798336] emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 0000001b from 0x00000000fee00c00 to 0x00000000fee00000 (XEN) [ 18.798350] emul-priv-op.c:1166:d0v1 Domain attempted WRMSR 0000001b from 0x00000000fee00c00 to 0x00000000fee00800 This is dom0 finding x2apic enabled in the APIC, and trying to cycle it around to xapic mode, and raises multiple issues. First and foremost, PV guests don't have an APIC and shouldn't be playing with it at all. It turns out that Xen advertise the hardware APIC bit to PV guests, which isn't necessarily always set. On top of that, the default read/write-ignore behaviour of MSR lets Linux get into a position where it thinks it is actually making real changes to the APIC mode. Architecturally speaking, if we offer the APIC bit, we should honour read/write requests correctly. Obviously, this isn't a viable option - hiding the APIC bit and raising #GP's is the only architecturally-correct way to do this. Given that we've already played "how much does Linux explode if it thinks there is no APIC", does anyone have any suggestions for how to resolve this without breaking Linux? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
