From: Fiona Ebner <f.ebner@proxmox.com>
To: Arthur Bied-Charreton <a.bied-charreton@proxmox.com>,
pve-devel@lists.proxmox.com
Subject: Re: [PATCH pve-qemu 2/3] build: query Hyper-V enlightenment flags for CPU flags list
Date: Thu, 28 May 2026 15:38:43 +0200 [thread overview]
Message-ID: <9d6b0d73-1a43-4590-84b7-65b7517abac5@proxmox.com> (raw)
In-Reply-To: <20260522132122.712794-3-a.bied-charreton@proxmox.com>
Am 22.05.26 um 3:21 PM schrieb Arthur Bied-Charreton:
> The recognized CPU flags list shipped with pve-qemu-kvm must include
> Hyper-V enlightenment flags so the custom CPU models API can offer them.
>
> Query them from the 'host-x86_64-cpu' type via QMP (qom-list-properties)
> in parse-cpu-flags.pl, filtering for properties with the 'hv-' prefix,
> and include them in the recognized flags list.
>
> Filter out non-boolean enlightenments, since the custom CPU model config
> only supports enable/disable.
>
> Suggested-by: Fiona Ebner <f.ebner@proxmox.com>
> Signed-off-by: Arthur Bied-Charreton <a.bied-charreton@proxmox.com>
> ---
> debian/parse-cpu-flags.pl | 42 +++++++++++++++++++++++++++++++++++++++
> debian/rules | 2 +-
> 2 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/debian/parse-cpu-flags.pl b/debian/parse-cpu-flags.pl
> index 1847b3e..2b5d32a 100755
> --- a/debian/parse-cpu-flags.pl
> +++ b/debian/parse-cpu-flags.pl
> @@ -2,7 +2,10 @@
>
> use warnings;
> use strict;
Style nit: please add a blank line here.
You could go ahead and use v5.36 and function signatures while at it.
> +use IPC::Open2;
> +use JSON;
>
> +my ($qemu_bin) = @ARGV;
> my @flags = ();
> my $got_flags_section;
>
> @@ -20,4 +23,43 @@ while (<STDIN>) {
>
> die "no QEMU/KVM CPU flags detected from STDIN input" if scalar (@flags) <= 0;
>
> +my $pid = open2(
> + my $out,
> + my $in,
> + $qemu_bin,
> + '-machine',
> + 'none',
> + '-display',
> + 'none',
> + '-S',
> + '-qmp',
> + 'stdio',
I'd add a -nodefaults for good measure
> +);
> +
> +sub qmp {
> + my ($cmd, %args) = @_;
> + print $in encode_json({ execute => $cmd, %args ? (arguments => \%args) : () }), "\n";
> + while (my $line = <$out>) {
> + my $msg = decode_json($line);
> + next if $msg->{event};
> + return $msg->{return} if exists $msg->{return};
Style nit: use parentheses for exists()
> + die "QMP error: " . encode_json($msg->{error}) if $msg->{error};
> + }
> +}
> +
> +<$out>;
> +qmp('qmp_capabilities');
> +my $props = qmp('qom-list-properties', typename => 'host-x86_64-cpu');
Nice!
> +for my $qo ($props->@*) {
> + # Filter out non-boolean flags, our custom CPU model config only supports
> + # enable/disable.
> + if (index($qo->{name}, 'hv-') == 0 && $qo->{type} eq 'bool') {
> + push @flags, $qo->{name};
> + }
> +}
> +qmp('quit');
> +waitpid($pid, 0);
> +
> +@flags = sort @flags;
> +
> print join("\n", @flags) or die "$!\n";
> diff --git a/debian/rules b/debian/rules
> index c90db29..e3eebe8 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -123,7 +123,7 @@ install: build
> rm -f $(destdir)/usr/lib/kvm/virtfs-proxy-helper
>
> # CPU flags are static for QEMU version, allows avoiding more costly checks
> - $(destdir)/usr/bin/qemu-system-x86_64 -cpu help | ./debian/parse-cpu-flags.pl > $(flagfile)
> + $(destdir)/usr/bin/qemu-system-x86_64 -cpu help | ./debian/parse-cpu-flags.pl $(destdir)/usr/bin/qemu-system-x86_64 > $(flagfile)
Should we rather also do the call to -cpu help inside the script then?
It feels strange to mix things like this (half way via STDIN, half way
execute command with passed-in binary).
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?
>
> # Supported machine versions are static for a given QEMU binary.
> $(destdir)/usr/bin/qemu-system-x86_64 -machine help | ./debian/parse-machines.pl > $(machine_file_x86_64)
next prev parent reply other threads:[~2026-05-28 13:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 13:21 [PATCH qemu/qemu-server 0/3] include Hyper-V enlightenment flags in CPU flags lists Arthur Bied-Charreton
2026-05-22 13:21 ` [PATCH qemu-server 1/3] cpu flags: include Hyper-V enlightenment flags in supported flags Arthur Bied-Charreton
2026-05-26 8:43 ` applied: " Fiona Ebner
2026-05-22 13:21 ` [PATCH pve-qemu 2/3] build: query Hyper-V enlightenment flags for CPU flags list Arthur Bied-Charreton
2026-05-28 13:38 ` Fiona Ebner [this message]
2026-05-28 15:30 ` Arthur Bied-Charreton
2026-05-28 15:43 ` Fiona Ebner
2026-05-29 5:53 ` Arthur Bied-Charreton
2026-05-22 13:21 ` [PATCH pve-qemu 3/3] build: fail when recognized CPU flags list changes Arthur Bied-Charreton
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=9d6b0d73-1a43-4590-84b7-65b7517abac5@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=a.bied-charreton@proxmox.com \
--cc=pve-devel@lists.proxmox.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.