qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Igor Mammedov
Subject: Re: [PATCH v2 00/10] Generate x86 cpu features
Date: Mon, 11 Sep 2023 13:26:18 +0200

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)?

> 
> 
> With regards,
> Daniel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]