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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.10.18 at 15:20, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/10/18 11:45, Jan Beulich wrote:
>>>>> On 03.10.18 at 13:56, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> 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.
> 
> I don't think you should draw any implication between the two.
> 
> The APIC bit is a hardware fast-forward, so can already be cleared on
> hardware with IO-APICs.  The ACPI tables describe the IO-APICs, and that
> is the only way any software has of finding them.

But without knowing there is an LAPIC on each CPU there's no way
to use any IO-APIC. IOW with LAPIC present bus disabled, IO-APICs
wouldn't be usable either.

> Furthermore, for a system which sets all the relevent "no legacy
> hardware" bits in ACPI, there is no need to have an IO-APIC at all. 
> There is provision in the latest PCI spec to have devices which are not
> capable of generating legacy interrupts.

That's fine, as being the opposite case.

>> 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?
> 
> From the cpumask work:
> 
> "Must expose hosts HTT and X2APIC value so a guest using native
> CPUID can correctly interpret other leaves which cannot be
> masked."
> 
> although to be perfectly honest, I don't remember exactly why.  It might
> be to do with the visibility of leaf 0xb.

;-)

I'm not aware of leaf 0xb being tied to any particular other CPUID
output bit. And any (hardware) APIC ID in whatever leaf is
meaningless to PV anyway.

> Furthermore, hiding the x2APIC feature but allowing APICBASE to be read
> will cause extra confusion to the guest if it finds EXTD set.

Well, it would be easy enough to provide the default value here
for PV guests, instead of letting the physical register value
shine through.

Jan



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