Re: [Xen-devel] PV guests and APIC interaction

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.10.18 at 13:56, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

This is the crucial point, imo. It is one of the downsides of the pv-ops
approach (allowing a single kernel binary to be used both without and
with Xen) that code like that dealing with the LAPIC can't simply be
compiled out to make sure it can't possibly be reached.

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

Hiding the APIC bits is not an options, afaict, as that would also
imply absence of any IO-APICs. What I don't understand is why
we surface X2APIC to PV guests. Wouldn't hiding that bit alone
address the specific issue above, even if the more general (xAPIC
related) one can't reasonably be addressed?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel