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
