Re: [PATCH pve-qemu 2/3] build: query Hyper-V enlightenment flags for CPU flags list

[Arthur Bied-Charreton <a.bied-charreton@proxmox.com>]

On Thu, May 28, 2026 at 05:43:26PM +0200, Fiona Ebner wrote:
> Am 28.05.26 um 5:29 PM schrieb Arthur Bied-Charreton:
> > On Thu, May 28, 2026 at 03:38:43PM +0200, Fiona Ebner wrote:
> >> I'm also thinking about whether we should go ahead and use just the QOM
> >> CPU properties rather than relying on the -cpu help output. We would
> >> then need a hardcoded blacklist of boolean properties that are not to be
> >> expose as flags (and also the aliases to avoid duplication). It's not
> >> that long of a list, but going forward, we'll need to be slightly more
> >> careful not to add anything as a flag that we don't want. In practice,
> >> after patch 3/3, every new boolean option needs to be looked at anyways
> >> and then the person doing the rebase needs to check if it is actually a
> >> flag. I'm not fully sure, but it would avoid the mixing info from
> >> different sources altogether. What do you think?
> >>
> > From a quick diff the only flag present in -cpu help that is not also in
> > qom-list-properties is kvmclock (on 11.0.0). In the other direction it's
> > 62 (I guess 58 after resolving QEMU aliases) properties, without 
> > counting the Hyper-V enlightenments, since we want to include those.
> > 
> > Some thoughts:
> > 
> > QEMU accepts all flags that would be added with qom-list-properties 
> > (just successfully booted a VM with a custom CPU model that had all of 
> > them set), so on that front we would be okay AFAICT.
> > 
> > The blocker is query_supported_cpu_flags, it reports a lot of the new 
> > flags I checked as unsupported. There is likely a way to make the 
> > temporary VM we query for flag support advertise those as well, like 
> > there was for the Hyper-V enlightenments, but I think that should be 
> > figured out before we start including those flags. 
> > 
> > I would suggest keeping '-cpu help' as the base set for now and just 
> > moving the qom-list-properties call for hv-* into the script so we stop 
> > mixing STDIN and a passed-in binary. At least until we have a good way 
> > to query support for the new flags. This way we avoid recreating the 
> > Hyper-V enlightenments issue at a larger scale.
> > 
> > I might still be missing a piece though, will definitely look into the
> > support-query path with fresh eyes tomorrow. 
> 
> I didn't mean to include all boolean properties of the QOM CPU object as
> new flags. Many are not proper CPUID flags and I don't think we want to
> expose them in the same way. That's why I wrote we'd need a hard-coded
> list to filter out non-flag boolean properties. Those non-flag
> properties should rather be additional properties in our CPU model
> schema, if we ever choose to add one of them.
> 
I see, I will look into this and update v2 accordingly.
> That said, I'm fine with keeping -cpu help as the basis too if you prefer.
I don't have a strong opinion on this, just misunderstood you - sorry
about that.