All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	 Xiaoyao Li <xiaoyao.li@intel.com>,
	Alexandre Chartre <alexandre.chartre@oracle.com>,
	 qemu-devel@nongnu.org, pbonzini@redhat.com,
	qemu-stable@nongnu.org,  boris.ostrovsky@oracle.com,
	maciej.szmigiero@oracle.com, kvm@vger.kernel.org
Subject: Re: [PATCH] i386/cpu: ARCH_CAPABILITIES should not be advertised on AMD
Date: Mon, 7 Jul 2025 12:05:53 -0700	[thread overview]
Message-ID: <aGwakUTUQ7ZxYlUe@google.com> (raw)
In-Reply-To: <aGQ-ke-pZhzLnr8t@char.us.oracle.com>

On Tue, Jul 01, 2025, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 01, 2025 at 03:05:00PM +0200, Igor Mammedov wrote:
> > On Tue, 1 Jul 2025 20:36:43 +0800
> > Zhao Liu <zhao1.liu@intel.com> wrote:
> > 
> > > On Tue, Jul 01, 2025 at 07:12:44PM +0800, Xiaoyao Li wrote:
> > > > Date: Tue, 1 Jul 2025 19:12:44 +0800
> > > > From: Xiaoyao Li <xiaoyao.li@intel.com>
> > > > Subject: Re: [PATCH] i386/cpu: ARCH_CAPABILITIES should not be advertised
> > > >  on AMD
> > > > 
> > > > On 7/1/2025 6:26 PM, Zhao Liu wrote:  
> > > > > > unless it was explicitly requested by the user.  
> > > > > But this could still break Windows, just like issue #3001, which enables
> > > > > arch-capabilities for EPYC-Genoa. This fact shows that even explicitly
> > > > > turning on arch-capabilities in AMD Guest and utilizing KVM's emulated
> > > > > value would even break something.
> > > > > 
> > > > > So even for named CPUs, arch-capabilities=on doesn't reflect the fact
> > > > > that it is purely emulated, and is (maybe?) harmful.  
> > > > 
> > > > It is because Windows adds wrong code. So it breaks itself and it's just the
> > > > regression of Windows.  
> > > 
> > > Could you please tell me what the Windows's wrong code is? And what's
> > > wrong when someone is following the hardware spec?
> > 
> > the reason is that it's reserved on AMD hence software shouldn't even try
> > to use it or make any decisions based on that.
> > 
> > 
> > PS:
> > on contrary, doing such ad-hoc 'cleanups' for the sake of misbehaving
> > guest would actually complicate QEMU for no big reason.
> 
> The guest is not misbehaving. It is following the spec.
> > 
> > Also
> > KVM does do have plenty of such code, and it's not actively preventing guests from using it.
> > Given that KVM is not welcoming such change, I think QEMU shouldn't do that either.
> 
> Because KVM maintainer does not want to touch the guest ABI. He agrees
> this is a bug.

No, I agreed that KVM's behavior is pointless, annoying, and odd[*].  I do not
agree that KVM's behavior is an outright bug.

[*] https://lore.kernel.org/all/aF1S2EIJWN47zLDG@google.com

  parent reply	other threads:[~2025-07-07 19:05 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
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 [this message]
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=aGwakUTUQ7ZxYlUe@google.com \
    --to=seanjc@google.com \
    --cc=alexandre.chartre@oracle.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=imammedo@redhat.com \
    --cc=konrad.wilk@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=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.