From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>,
Zhao Liu <zhao1.liu@intel.com>,
qemu-devel@nongnu.org, pbonzini@redhat.com,
qemu-stable@nongnu.org, boris.ostrovsky@oracle.com,
maciej.szmigiero@oracle.com,
Sean Christopherson <seanjc@google.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH] i386/cpu: ARCH_CAPABILITIES should not be advertised on AMD
Date: Tue, 1 Jul 2025 15:59:12 -0400 [thread overview]
Message-ID: <aGQ-EGmkVkHOZcnn@char.us.oracle.com> (raw)
In-Reply-To: <e19644ed-3e32-42f7-8d46-70f744ffe33b@intel.com>
..snip..
> OK, back to the original question "what should the code do?"
>
> My answer is, it can behave with any of below option:
>
> - Be vendor agnostic and stick to x86 architecture. If CPUID enumerates a
> feature, then the feature is available architecturally.
Exactly. That is what we believe Windows does.
By this logic KVM is at fault for exposing this irregardless of the
platform (when using -cpu host). And Sean (the KVM maintainer) agrees it is
a bug. But he does not want it in the kernel due to guest ABI and hence
the ask is to put this in QEMU.
>
> - Based on AMD spec. Ignore the bit since it's a reserved bit. (Expect a
> reserved bit to be zero if not explicitly state by spec is totally wrong!)
Which may change in the future as AMD may expose this CPUID in say X
years. And at that point the first option you enumerated is the more
safer one.
next prev parent reply other threads:[~2025-07-01 19:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-30 13:30 [PATCH] i386/cpu: ARCH_CAPABILITIES should not be advertised on AMD Alexandre Chartre
2025-07-01 8:23 ` Xiaoyao Li
2025-07-01 9:22 ` Alexandre Chartre
2025-07-01 9:47 ` Xiaoyao Li
2025-07-01 19:47 ` Konrad Rzeszutek Wilk
2025-07-02 1:06 ` Xiaoyao Li
2025-07-01 9:25 ` Maciej S. Szmigiero
2025-07-07 19:36 ` Daniel P. Berrangé
2025-07-01 10:26 ` Zhao Liu
2025-07-01 11:12 ` Xiaoyao Li
2025-07-01 12:12 ` Alexandre Chartre
2025-07-01 15:13 ` Xiaoyao Li
2025-07-01 19:59 ` Konrad Rzeszutek Wilk [this message]
2025-07-07 19:31 ` Daniel P. Berrangé
2025-07-07 20:03 ` Sean Christopherson
2025-07-01 12:36 ` Zhao Liu
2025-07-01 13:05 ` Igor Mammedov
2025-07-01 20:01 ` Konrad Rzeszutek Wilk
2025-07-02 5:01 ` Zhao Liu
2025-07-02 5:19 ` Zhao Liu
2025-07-02 5:30 ` Xiaoyao Li
2025-07-02 8:34 ` Zhao Liu
2025-07-07 19:20 ` Sean Christopherson
2025-07-02 9:27 ` Alexandre Chartre
2025-07-02 11:23 ` Igor Mammedov
2025-07-07 19:54 ` Sean Christopherson
2025-07-07 19:05 ` Sean Christopherson
2025-07-01 12:19 ` Alexandre Chartre
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=aGQ-EGmkVkHOZcnn@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=alexandre.chartre@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=maciej.szmigiero@oracle.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=seanjc@google.com \
--cc=xiaoyao.li@intel.com \
--cc=zhao1.liu@intel.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.