Re: [PATCH] x86/cpu-policy: Hide x2APIC from PV guests

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/03/2024 8:33 am, Jan Beulich wrote:
> On 29.02.2024 23:14, Andrew Cooper wrote:
>> PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they
>> access any of the x2APIC MSR range.  Therefore they mustn't see the x2APIC
>> CPUID bit saying that they can.
> This argumentation could then be used equally for the APIC bit. Why is it
> correct to hide x2APIC, but not APIC?

In an ideal world we'd hide APIC too.

But Linux pvops doesn't tolerate it, and I'm not sure classic dom0 did
either.

>> Right now, the host x2APIC flag filters into PV guests, meaning that PV 
>> guests
>> generally see x2APIC except on Zen1-and-older AMD systems.
>>
>> Linux works around this by explicitly hiding the bit itself, and filtering
>> EXTD out of MSR_APIC_BASE reads.  NetBSD behaves more in the spirit of PV
>> guests, and entirely ignores the APIC when built as a PV guest.
>>
>> Change the annotation from !A to !S.  This has a consequence of stripping it
>> out of both PV featuremasks.  However, as existing guests may have seen the
>> bit, set it back into the PV Max policy; a VM which saw the bit and is alive
>> enough to migrate will have ignored it one way or another.
>>
>> Hiding x2APIC does also change the contents of leaf 0xb, but as the
>> information is nonsense to begin with, this is likely an improvement on the
>> status quo.  The blind reporting of APIC_ID = vCPU_ID * 2 isn't interlinked
>> with the host's topology structure, and the APIC_IDs are useless without an
>> MADT to start with.  Dom0 is the only PV VM to get an MADT but it's the host
>> one, meaning the two sets of APIC_IDs are from different address spaces.
> Aiui the field will now be seen as zero on all CPUs. Is all CPUs having the
> same APIC ID there really better than them all having different ones?

Again - we're taking something that was conditionally like this, and
making it unconditionally like this.

When x2APIC is hidden, so is the precondition for the data in this leaf
being valid.

> Also while I agree that logically CPUID leaf 0xb EDX is tied to x2APIC being
> available as a feature, nothing is said in this regard in the documentation
> of that leaf. This in particular leaves open whether on a system with x2APIC
> disabled in/by firmware the value would actually be zero. Yet that case could
> be considered somewhat similar to the PV case here.

I'm not aware of there being a capability to disable x2APIC in firmware.

The only choices you got were which mode to default to, and
(occasionally) whether to set the x2APIC opt-out in DMAR.

~Andrew