From: "Doru Blânzeanu" <dblanzeanu@linux.microsoft.com>
To: Magnus Kulke <magnuskulke@linux.microsoft.com>
Cc: qemu-devel@nongnu.org, "Magnus Kulke" <magnuskulke@microsoft.com>,
"Doru Blânzeanu" <doru.blanzeanu@microsoft.com>,
"Wei Liu" <liuwe@microsoft.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Wei Liu" <wei.liu@kernel.org>
Subject: Re: [PATCH] target/i386/mshv: Fix cpu feature-leak from host
Date: Thu, 2 Jul 2026 17:04:37 +0300 [thread overview]
Message-ID: <akZv9QeXxHwbFT21@linux.microsoft.com> (raw)
In-Reply-To: <20260702125309.450767-1-magnuskulke@linux.microsoft.com>
On Thu, Jul 02, 2026 at 02:53:09PM +0200, Magnus Kulke wrote:
> In the current implementation there are subtle bugs that have to do with
> the termination of subleaves, resulting in features reported on the
> guest that it should not have according to the model.
>
> If a guest model has fewer valid subleaves stopping too early leaves
> unspecified gaps that are filled by the host, resulting in potentially
> invalid feature combinations, for example:
>
> The host reports features:
>
> CPUID[EAX=01H].ECX.AVX [bit 28] and
> CPUID[EAX=07H,ECX=01H].EAX.AVX_VNNI [bit 4]
>
> In the current implementation we would skip over 7.1 completely, not
> registering CPUID responses for the subleaf, resulting in a guest with
> qemu64 model (which does not feature AVX), reporting AVX_VNNI as
> available (passthrough from host).
>
> We need to walk through the max subleaves of leaf 7 and register them
> explicitly (also if they're 0).
>
> A second bug was about the propagation of "terminator" subleaves,
> all-zero responses that signal the end. We also want to register this
> terminator response , so the guest stops enumerating. In the current
> implementation we weren't doing that.
>
> Fixes: 4fa04dd1621
> Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
> ---
> target/i386/mshv/mshv-cpu.c | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/target/i386/mshv/mshv-cpu.c b/target/i386/mshv/mshv-cpu.c
> index 126ca40b48..a3b5f4474f 100644
> --- a/target/i386/mshv/mshv-cpu.c
> +++ b/target/i386/mshv/mshv-cpu.c
> @@ -997,7 +997,7 @@ static void collect_cpuid_entries(const CPUState *cpu, GList **cpuid_entries)
> CPUX86State *env = &x86_cpu->env;
> uint32_t eax, ebx, ecx, edx;
> uint32_t leaf, subleaf;
> - uint32_t max_basic_leaf, max_extended_leaf;
> + uint32_t max_basic_leaf, max_extended_leaf, max_subleaf_7;
> uint32_t max_subleaf = 0x20;
> uint32_t leaves_with_subleaves[] = {0x04, 0x07, 0x0d, 0x0f, 0x10};
> int n_subleaf_leaves = ARRAY_SIZE(leaves_with_subleaves);
> @@ -1035,14 +1035,31 @@ static void collect_cpuid_entries(const CPUState *cpu, GList **cpuid_entries)
> continue;
> }
>
> + /*
> + * Valid subleaves for are reported in 7.0:EAX. We need to register all
I think there's an additional "for" word above.
Reviewed-by: Doru Blânzeanu <dblanzeanu@linux.microsoft.com>
> + * subleaves to the maximum subleaf, even if they are 0. Otherwise the
> + * host will supply its own values for a unregistered subleaf, which
> + * can result in an inconsistent feature set.
> + */
> + if (leaf == 0x07) {
> + cpu_x86_cpuid(env, leaf, 0, &max_subleaf_7, &ebx, &ecx, &edx);
> + for (subleaf = 0; subleaf <= max_subleaf_7; subleaf++) {
> + cpu_x86_cpuid(env, leaf, subleaf, &eax, &ebx, &ecx, &edx);
> + add_cpuid_entry(cpuid_entries, leaf, subleaf,
> + eax, ebx, ecx, edx);
> + }
> + continue;
> + }
> +
> subleaf = 0;
> while (subleaf < max_subleaf) {
> cpu_x86_cpuid(env, leaf, subleaf, &eax, &ebx, &ecx, &edx);
>
> + /* register the "terminator" to the guest, before breaking */
> + add_cpuid_entry(cpuid_entries, leaf, subleaf, eax, ebx, ecx, edx);
> if (eax == 0 && ebx == 0 && ecx == 0 && edx == 0) {
> break;
> }
> - add_cpuid_entry(cpuid_entries, leaf, subleaf, eax, ebx, ecx, edx);
> subleaf++;
> }
> }
> --
> 2.34.1
prev parent reply other threads:[~2026-07-02 14:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 12:53 [PATCH] target/i386/mshv: Fix cpu feature-leak from host Magnus Kulke
2026-07-02 14:04 ` Doru Blânzeanu [this message]
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=akZv9QeXxHwbFT21@linux.microsoft.com \
--to=dblanzeanu@linux.microsoft.com \
--cc=doru.blanzeanu@microsoft.com \
--cc=liuwe@microsoft.com \
--cc=magnuskulke@linux.microsoft.com \
--cc=magnuskulke@microsoft.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wei.liu@kernel.org \
/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.