All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Tim Wiederhake <twiederh@redhat.com>
Cc: qemu-devel@nongnu.org,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v2 00/10] Generate x86 cpu features
Date: Fri, 8 Sep 2023 16:48:46 +0200	[thread overview]
Message-ID: <20230908164846.184aba1c@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <20230908124534.25027-1-twiederh@redhat.com>

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.

QEMU does provides QMP interface for introspection of CPU models and it
should be used as a mean to discover new CPU models as well as new
feature names. If something is missing there we should fix it up
to make it usable for libvirt.

> This is a flawed, tedious and error-prone procedure. Ideally, qemu
> and libvirt would query a common source for cpu feature and model
> related information. Meanwhile, converting this information into an easier
> to parse format would help libvirt a lot.
> 
> This patch series converts the cpu feature information present in
> target/i386/cpu.c (`feature_word_info`) into a yaml file and adds a
> script to generate the c code from this data.

 
> A patch set to convert the cpu model data (`builtin_x86_defs`) in the
> same way will follow.

while theoretically you can parse feature_word_info with some sort of reliability,
you can't do that reliably with CPU model definitions in builtin_x86_defs
as the later is just a skeleton. Actual CPU models definitions are
a function of used machine type, accelerator and host kernel. 

> 
> v1: https://lists.nongnu.org/archive/html/qemu-devel/2023-08/msg02005.html
> 
> Changes since v1:
> * Incorporated changes from
>   https://lists.nongnu.org/archive/html/qemu-devel/2023-08/msg04241.html.
> * Changed data format from xml to yaml, as proposed in
>   https://lists.nongnu.org/archive/html/qemu-devel/2023-09/msg01033.html.
>   Using json has some drawbacks, see
>   https://lists.nongnu.org/archive/html/qemu-devel/2023-08/msg03384.html.
> * Rebased on top of current master. Features added in the meantime:
>   amx-complex and vmx-enable-user-wait-pause
> * Split up the reformatting of feature_word_info.c.inc to make it easier
>   to review. These patches could be squashed together before merging.
> 
> Tim Wiederhake (10):
>   target/i386: Add missing feature names in FEAT_VMX_EPT_VPID_CAPS
>   target/i386: Fix feature names in FEAT_VMX_EPT_VPID_CAPS
>   target/i386: Fix duplicated feature name in FEAT_KVM
>   target/i386: Split out feature_word_info
>   target/i386: Translate feature_word_info to yaml
>   target/i386: Format feature_word_info.c.inc: Remove comments
>   target/i386: Format feature_word_info.c.inc: feat_names
>   target/i386: Format feature_word_info.c.inc: Unfold cpuid member
>   target/i386: Format feature_word_info.c.inc: Whitespaces and trailing
>     commas
>   target/i386: Autogenerate feature_word_info.c.inc
> 
>  target/i386/cpu.c                   |  677 +-----------------
>  target/i386/feature_word_info.c.inc | 1030 +++++++++++++++++++++++++++
>  target/i386/feature_word_info.py    |   62 ++
>  target/i386/feature_word_info.yaml  |  697 ++++++++++++++++++
>  4 files changed, 1790 insertions(+), 676 deletions(-)
>  create mode 100644 target/i386/feature_word_info.c.inc
>  create mode 100755 target/i386/feature_word_info.py
>  create mode 100644 target/i386/feature_word_info.yaml
> 




  parent reply	other threads:[~2023-09-08 14:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-08 12:45 [PATCH v2 00/10] Generate x86 cpu features Tim Wiederhake
2023-09-08 12:45 ` [PATCH v2 01/10] target/i386: Add missing feature names in FEAT_VMX_EPT_VPID_CAPS Tim Wiederhake
2023-09-08 14:06   ` Igor Mammedov
2023-09-08 12:45 ` [PATCH v2 02/10] target/i386: Fix " Tim Wiederhake
2023-09-08 14:17   ` Igor Mammedov
2023-09-08 14:26     ` Igor Mammedov
2023-09-08 12:45 ` [PATCH v2 03/10] target/i386: Fix duplicated feature name in FEAT_KVM Tim Wiederhake
2023-09-08 14:21   ` Igor Mammedov
2023-09-15 15:53     ` Tim Wiederhake
2023-09-08 12:45 ` [PATCH v2 04/10] target/i386: Split out feature_word_info Tim Wiederhake
2023-09-08 12:45 ` [PATCH v2 05/10] target/i386: Translate feature_word_info to yaml Tim Wiederhake
2023-09-08 12:45 ` [PATCH v2 06/10] target/i386: Format feature_word_info.c.inc: Remove comments Tim Wiederhake
2023-09-08 12:45 ` [PATCH v2 07/10] target/i386: Format feature_word_info.c.inc: Fill out feat_names Tim Wiederhake
2023-09-08 12:45 ` [PATCH v2 08/10] target/i386: Format feature_word_info.c.inc: Unfold cpuid member Tim Wiederhake
2023-09-08 12:45 ` [PATCH v2 09/10] target/i386: Format feature_word_info.c.inc: Whitespaces and trailing commas Tim Wiederhake
2023-09-08 12:45 ` [PATCH v2 10/10] target/i386: Autogenerate feature_word_info.c.inc Tim Wiederhake
2023-09-09 23:42   ` Richard Henderson
2023-09-08 14:48 ` Igor Mammedov [this message]
2023-09-08 16:55   ` [PATCH v2 00/10] Generate x86 cpu features Daniel P. Berrangé
2023-09-11 11:26     ` Igor Mammedov
2023-09-15 15:53       ` Tim Wiederhake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230908164846.184aba1c@imammedo.users.ipa.redhat.com \
    --to=imammedo@redhat.com \
    --cc=berrange@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=twiederh@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.