Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <161188083424.28787.9510741752032213167.stgit@bmoger-ubuntu>
 <161188100955.28787.11816849358413330720.stgit@bmoger-ubuntu>
 <CALMp9eTU5h4juDyGePnuDN39FudYUqyAnnQdALZM8KfiMo93YA@mail.gmail.com>
 <5d380b11-079f-e941-25cf-747f66310695@amd.com> <CALMp9eRnC1RgRwj64TJcXdhhL6g835N_-E8FbeHVre6aX=18-A@mail.gmail.com>
 <17a3d97e-3087-e79a-120d-b4a45f6c4fba@amd.com>
In-Reply-To: <17a3d97e-3087-e79a-120d-b4a45f6c4fba@amd.com>
From:   Jim Mattson <jmattson@google.com>
Date:   Mon, 13 Jun 2022 13:28:13 -0700
Message-ID: <CALMp9eT1_G1yp30K=DqEUsV=yK_w9KoU_ANnSPq4ueqzBTkLZw@mail.gmail.com>
Subject: Re: [PATCH v4 2/2] KVM: SVM: Add support for Virtual SPEC_CTRL
To:     Tom Lendacky <thomas.lendacky@amd.com>
Cc:     Babu Moger <babu.moger@amd.com>, pbonzini@redhat.com,
        tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        fenghua.yu@intel.com, tony.luck@intel.com, wanpengli@tencent.com,
        kvm@vger.kernel.org, peterz@infradead.org, seanjc@google.com,
        joro@8bytes.org, x86@kernel.org, kyung.min.park@intel.com,
        linux-kernel@vger.kernel.org, krish.sadhukhan@oracle.com,
        hpa@zytor.com, mgross@linux.intel.com, vkuznets@redhat.com,
        kim.phillips@amd.com, wei.huang2@amd.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jun 13, 2022 at 1:16 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:

> Ah, yes, I get it now. I wasn't picking up on the aspect of running older
> KVM versions on the newer hardware, sorry.
>
> I understand what you're driving at, now. We do tell the hardware teams
> that add this type of feature that we need a VMCB enable bit, e.g. make it
> an opt in feature. I'll be sure to communicate that to them again so that
> this type of issue can be avoided in the future.

Thank you so much. Might I also ask that new features get promptly
documented in the APM?

It took us an incredibly long time to figure out why just one vCPU
thread would run slow on every GCE AMD instance. It wasn't always the
same thread, but the slow vCPU thread would still be slow even after
live migration. On a guest reboot, the slowness might migrate to a
different vCPU thread. How bizarre, right?

It turns out that, on UEFI-enabled images, one vCPU makes an EFI
firmware call, which sets IBRS. You can't see that IBRS is on from
within the guest, but it is, because of the sticky first non-zero
write behavior induced by virtual SPEC_CTRL.