Re: [PATCH v2 00/10] Generate x86 cpu features

[Tim Wiederhake]

On Mon, 2023-09-11 at 13:26 +0200, Igor Mammedov wrote:
> On Fri, 8 Sep 2023 17:55:12 +0100
> Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> > On Fri, Sep 08, 2023 at 04:48:46PM +0200, Igor Mammedov wrote:
> > > On Fri,  8 Sep 2023 14:45:24 +0200
> > > Tim Wiederhake <twiederh@redhat.com> wrote:
> > >   
> > > > Synchronizing the list of cpu features and models with qemu is
> > > > a recurring
> > > > task in libvirt. For x86, this is done by reading qom-list-
> > > > properties for
> > > > max-x86_64-cpu and manually filtering out everthing that does
> > > > not look like
> > > > a feature name, as well as parsing target/i386/cpu.c for cpu
> > > > models.  
> > > 
> > > modulo fixing typos/name conflicts in 1st 3 patches,
> > > 
> > > I don't think it's a great idea for libvirt (or any other user)
> > > to parse
> > > QEMU source (whether it's C code or yaml) or other way around for
> > > users
> > > to influence QEMU internals.  
> > 
> > NB It isn't for libvirt to parse at runtime, rather it is for
> > libvirt
> > maintainers to consume during dev, so libvirt keeps in sync with
> > QEMU
> > features.
> 
> As QEMU dev, I'm not fond of code generators as sometimes they make
> difficult for me to read, and on to of that inventing new 'language'
> to describe features that works on some cases only (not everything
> is described in feature array, and for non x86 properties mostly
> coded in initfn/realizefn).
> (I'd dislike it less if it were part of QMP schema as it gets us
> closer to processing '-device' with QMP machinery).
> 
> why not use existing QMP interface there as well (or alter it if
> it's not sufficient)?
> 
> 
I understand your concern regarding the legibility of generated code.
If you have a look at patches 6 - 9, you will see that the only changes
introduced are white space changes, harmonizing the usage of trailing
commas, breaking lines, and filling the "feat_names" field fully. That,
if anything, makes the code more readable in my opinion.

The format of the yaml file is chosen to mimic struct FeatureWordInfo
as closely as possible, it is effectively a 1:1 mapping.

Regarding using the QMP interface: That is what libvirt is currently
doing, see [1] if you are interested. The problem with that approach is
that the response to

    {
        "execute": "qom-list-properties",
        "arguments": { "typename": "max-x86_64-cpu"}
    }

does not distinguish between cpu features and other information about
that cpu model, thus forcing libvirt to maintain a list of non-
features. Examples of such items are "check", "enforce", "start-
powered-off", or "migratable".

Additionally, the response does not include information about the cpuid
leaf, register and bit, or msr register respectively. This has to be
supplemented manually.

If there is a way to query for this information that I am not aware of,
please let me know.

Ultimately I would love to see libvirt stop querying qemu for x86 cpu
feature information but instead have both qemu and libvirt query a
common source / database for this kind of information, for all
architectures, not only x86.

Regards,
Tim

[1]
https://gitlab.com/libvirt/libvirt/-/blob/master/src/cpu_map/sync_qemu_features_i386.py