linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jim Mattson <jmattson@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>, kvm list <kvm@vger.kernel.org>
Subject: Re: [PATCH 1/2] KVM: x86: fix reporting of AMD speculation bug CPUID leaf
Date: Mon, 19 Aug 2019 11:30:25 -0700	[thread overview]
Message-ID: <CALMp9eT2uo+_tbV=Z3-pyzjU76kaEU-BNvVriEHU6yGMsiy5Dw@mail.gmail.com> (raw)
In-Reply-To: <0e29f624-10f5-7ab5-1823-280f32732b68@redhat.com>

On Mon, Aug 19, 2019 at 8:18 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 16/08/19 23:45, Jim Mattson wrote:
> > On Thu, Aug 15, 2019 at 12:41 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
> >>
> >> The AMD_* bits have to be set from the vendor-independent
> >> feature and bug flags, because KVM_GET_SUPPORTED_CPUID does not care
> >> about the vendor and they should be set on Intel processors as well.
> >> On top of this, SSBD, STIBP and AMD_SSB_NO bit were not set, and
> >> VIRT_SSBD does not have to be added manually because it is a
> >> cpufeature that comes directly from the host's CPUID bit.
> >>
> >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >
> > On AMD systems, aren't AMD_SSBD, AMD_STIBP, and AMD_SSB_NO set by
> > inheritance from the host:
> >
> > /* cpuid 0x80000008.ebx */
> > const u32 kvm_cpuid_8000_0008_ebx_x86_features =
> >         F(WBNOINVD) | F(AMD_IBPB) | F(AMD_IBRS) | F(AMD_SSBD) | F(VIRT_SSBD) |
> >         F(AMD_SSB_NO) | F(AMD_STIBP) | F(AMD_STIBP_ALWAYS_ON);
> >
> > I am curious why the cross-vendor settings go only one way. For
> > example, you set AMD_STIBP on Intel processors that have STIBP, but
> > you do not set INTEL_STIBP on AMD processors that have STIBP?
> > Similarly, you set AMD_SSB_NO for Intel processors that are immune to
> > SSB, but you do not set IA32_ARCH_CAPABILITIES.SSB_NO for AMD
> > processors that are immune to SSB?
> >
> > Perhaps there is another patch coming for reporting Intel bits on AMD?
>
> I wasn't going to work on it but yes, they should be.  This patch just
> fixed what was half-implemented.

I'm not sure that the original intent was to enumerate the AMD
features on Intel hosts, but it seems reasonable to do so.

Should we also populate the AMD cache topology leaf (0x8000001d) on
Intel hosts? And so on? :-)

Reviewed-by: Jim Mattson <jmattson@google.com>

  reply	other threads:[~2019-08-19 18:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15  7:41 [PATCH 0/2] KVM: x86: fixes for AMD speculation bug CPUID leaf Paolo Bonzini
2019-08-15  7:41 ` [PATCH 1/2] KVM: x86: fix reporting of " Paolo Bonzini
2019-08-16 21:45   ` Jim Mattson
2019-08-19 15:18     ` Paolo Bonzini
2019-08-19 18:30       ` Jim Mattson [this message]
2019-08-19 18:33         ` Paolo Bonzini
2019-08-15  7:41 ` [PATCH 2/2] KVM: x86: always expose VIRT_SSBD to guests Paolo Bonzini
2019-08-15 17:14   ` Eduardo Habkost
2019-08-19 15:41     ` Paolo Bonzini

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='CALMp9eT2uo+_tbV=Z3-pyzjU76kaEU-BNvVriEHU6yGMsiy5Dw@mail.gmail.com' \
    --to=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).