On 16.07.2024 17:03, Matthew Barnes wrote: > On Tue, Jul 09, 2024 at 08:40:18AM +0200, 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? > > I shall reword the commit message in patch v2 to avoid the wording "have > to". > >>> This patch exposes the max_vcpus field via cpuid on the HVM hypervisor >>> leaf in edx. >> >> If exposing via CPUID, why only for HVM? > > Other related cpuid fields are also exposed in the HVM hypervisor leaf, > such as the vcpu id and the domain id. > > Having said that, I wouldn't mind moving this field (or other fields, in > a separate patch) to a location meant for HVM *and* PV guests. Do you > have any suggestions?
I don't think we can literally move anything. We could duplicate things into shared fields, but would that gain us anything? Therefore I think going forward we should limit type-specific fields to cases where type really matters, and otherwise expose in a type-independent way. Jan
