Re: [RFC XEN PATCH v2] x86/cpuid: Expose max_vcpus field in HVM hypervisor leaf

["Alejandro Vallejo" <alejandro.vallejo@cloud.com>]

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.barnes@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