I'll pitch in, seeing as I created the GitLab ticket. On Tue Jul 9, 2024 at 7:40 AM BST, Jan Beulich wrote: > On 08.07.2024 17:42, Matthew Barnes wrote: > > Currently, OVMF is hard-coded to set up a maximum of 64 vCPUs on > > startup. > > > > There are efforts to support a maximum of 128 vCPUs, which would involve > > bumping the OVMF constant from 64 to 128. > > > > However, it would be more future-proof for OVMF to access the maximum > > number of vCPUs for a domain and set itself up appropriately at > > run-time. > > > > For OVMF to access the maximum vCPU count, Xen will have to expose this > > property via cpuid. > > Why "have to"? The information is available from xenstore, isn't it?
That would create an avoidable dependency between OVMF and xenstore, precluding xenstoreless UEFI-enabled domUs. > > > This patch exposes the max_vcpus field via cpuid on the HVM hypervisor > > leaf in edx. > > If exposing via CPUID, why only for HVM? > > > --- a/xen/include/public/arch-x86/cpuid.h > > +++ b/xen/include/public/arch-x86/cpuid.h > > @@ -87,6 +87,7 @@ > > * Sub-leaf 0: EAX: Features > > * Sub-leaf 0: EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT > > flag) > > * Sub-leaf 0: ECX: domain id (iff EAX has XEN_HVM_CPUID_DOMID_PRESENT > > flag) > > + * Sub-leaf 0: EDX: max vcpus (iff EAX has XEN_HVM_CPUID_MAX_VCPUS_PRESENT > > flag) > > */ > > Unlike EBX and ECX, the proposed value for EDX cannot be zero. I'm therefore > not entirely convinced that we need a qualifying flag. Things would be > different if the field was "highest possible vCPU ID", which certainly would > be the better approach if the field wasn't occupying the entire register. > Even with it being 32 bits, I'd still suggest switching its meaning this way. > > Jan Using max_vcpu_id instead of max_vcpus is also fine, but the flag is important as otherwise it's impossible to retroactively change the meaning of EDX (i.e: to stop advertising this datum, or repurpose EDX altogether) We could also reserve only the lower 16bits of EDX rather than the whole thing; but we have plenty of subleafs for growth, so I'm not sure it's worth it. Cheers, Alejandro
