On Mon, 2022-10-10 at 13:30 -0400, Michael S. Tsirkin wrote: > From: Peter Xu < > pet...@redhat.com > > > > It's true that when vcpus<=255 we don't require the length of 32bit APIC > IDs. However here since we already have EIM=ON it means the hypervisor > will declare the VM as x2apic supported (e.g. VT-d ECAP register will have > EIM bit 4 set), so the guest should assume the APIC IDs are 32bits width > even if vcpus<=255. In short, commit 77250171bdc breaks any simple cmdline > that wants to boot a VM with >=9 but <=255 vcpus with:
I find that paragraph really hard to parse. What does it even mean that "guest should assume the APIC IDs are 32bits"? In practice, all the EIM bit does is *allow* 32 bits of APIC ID in the tables. Which is perfectly fine if there are only 254 CPUs anyway, and we never need to use a higher value. I *think* the actual problem here is when logical addressing is used, which puts the APIC cluster ID into higher bits? But it's kind of weird that the message doesn't mention that at all? That's fixable by just setting the X2APIC_PHYSICAL bit in the ACPI FADT, isn't it? Then the only values that a guest may put into those fields — 32-bit fields or not — are lower than 0xff anyway.
smime.p7s
Description: S/MIME cryptographic signature
