On Wed Jul 24, 2024 at 2:01 PM BST, Jan Beulich wrote: > On 24.07.2024 14:51, Matthew Barnes wrote: > > On Wed, Jul 24, 2024 at 07:42:19AM +0200, Jan Beulich wrote: > >> (re-adding xen-devel@) > >> > >> On 23.07.2024 14:57, Matthew Barnes wrote: > >>> On Mon, Jul 22, 2024 at 01:37:11PM +0200, Jan Beulich wrote: > >>>> On 19.07.2024 16:21, 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. > >>>>> > >>>>> GitLab ticket: https://gitlab.com/xen-project/xen/-/issues/191 > >>>>> > >>>>> For OVMF to access the maximum vCPU count, this patch has Xen expose > >>>>> the maximum vCPU ID via cpuid on the HVM hypervisor leaf in edx. > >>>>> > >>>>> Signed-off-by: Matthew Barnes <matthew.bar...@cloud.com> > >>>>> --- > >>>>> Changes in v2: > >>>>> - Tweak value from "maximum vcpu count" to "maximum vcpu id" > >>>>> - Reword commit message to avoid "have to" wording > >>>>> - Fix vpcus -> vcpus typo > >>>>> --- > >>>> > >>>> Yet still HVM-only? > >>> > >>> This field is only used when the guest is HVM, so I decided it should > >>> only be present to HVM guests. > >>> > >>> If not, where else would you suggest to put this field? > >> > >> In a presently unused leaf? Or one of the unused registers of leaf x01 > >> (with the gating flag in leaf x02 ECX)? > > > > I could establish leaf x06 as a 'domain info' leaf for both HVM and PV, > > have EAX as a features bitmap, and EBX as the max_vcpu_id field. > > > > Is this satisfactory? > > Hmm. Personally I think that all new leaves would better permit for multiple > sub-leaves. Hence EAX is already unavailable. Additionally I'm told that > there are internal discussions (supposed to be) going on at your end, which > makes me wonder whether the above is the outcome of those discussions (in > particular having at least tentative buy-off by Andrew). > > For the particular data to expose here, I would prefer the indicated re-use > of an existing leaf. I haven't seen counter-arguments to that so far. > > Jan
I recommended Matt originally to expose it on the HVM leaf for semantic cohesion with the other domain-related data and because it's strictly just needed for HVM, at least for the time being. It is true though that it's not HVM-specific and could go elsewhere. There's a fiction of choice, but not so much in practice, I think. Re-using leaf 1 would overload it semantically, as it's already used for version reporting (just like other architectural CPUID groups). Leaf 2 could be an option, but it's somewhat annoying because it leaves (pun intended) no room for expansion. A potential new leaf 6 would indeed need to ensure only subleaf0 is implemented (as do leaves 4 and 5), but otherwise should be pretty harmless. Andrew might very well have wildly different views. Cheers, Alejandro
