Received-SPF: pass (google.com: domain of linux-kernel+bounces-141369-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240405235603.1173076-1-seanjc@google.com>
In-Reply-To: <20240405235603.1173076-1-seanjc@google.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Thu, 11 Apr 2024 19:03:00 +0200
Message-ID: <CABgObfZoj1zqwnZ8FbZar7aT+AjrhFWbDUu_Vu-rmLfB3FPvaQ@mail.gmail.com>
Subject: Re: [PATCH 00/10] KVM: x86: Fix LVTPC masking on AMD CPUs
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, 
	Sandipan Das <sandipan.das@amd.com>, Jim Mattson <jmattson@google.com>, 
	Like Xu <like.xu.linux@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 6, 2024 at 1:56=E2=80=AFAM Sean Christopherson <seanjc@google.c=
om> wrote:
>
> This is kinda sorta v2 of Sandipan's fix for KVM's incorrect setting of
> the MASK bit when delivering PMIs through the LVTPC.
>
> It's a bit rushed, as I want to get Sandipan's fix applied early next
> week so that it can make its way to Linus' tree for -rc4.  And I didn't
> want to apply Sandipan's patch as-is, because I'm a little paranoid that
> the guest CPUID check could be noticeable slow, and it's easy to avoid.
>
> My plan is to grab patches 1-2 for 6.9 asap, and let the rest simmer for
> much, much longer (they are *very* lightly tested).

Oops---I missed your queuing message and pushed the same to kvm/master.

Is it okay if you use commit 49ff3b4aec51e as the basis for any 6.10
topic branches that may conflict (or that build open the first two
patches)?

Paolo


Paolo

>
> As for why this looks wildy different than Sandipan's compat_vendor idea,
> when I started looking at KVM's various AMD vs. Intel checks, I realized
> it makes no sense to support an "unknown" vendor.  KVM can't do *nothing*=
,
> and so practically speaking, an "unknown" vendor vCPU would actually end
> up with a weird mix of AMD *and* Intel behavior, not AMD *or* Intel
> behavior.
>
> Sandipan Das (1):
>   KVM: x86/pmu: Do not mask LVTPC when handling a PMI on AMD platforms
>
> Sean Christopherson (9):
>   KVM: x86: Snapshot if a vCPU's vendor model is AMD vs. Intel
>     compatible
>   KVM: x86/pmu: Squash period for checkpointed events based on host
>     HLE/RTM
>   KVM: x86: Apply Intel's TSC_AUX reserved-bit behavior to Intel compat
>     vCPUs
>   KVM: x86: Inhibit code #DBs in MOV-SS shadow for all Intel compat
>     vCPUs
>   KVM: x86: Use "is Intel compatible" helper to emulate SYSCALL in
>     !64-bit
>   KVM: SVM: Emulate SYSENTER RIP/RSP behavior for all Intel compat vCPUs
>   KVM: x86: Allow SYSENTER in Compatibility Mode for all Intel compat
>     vCPUs
>   KVM: x86: Open code vendor_intel() in string_registers_quirk()
>   KVM: x86: Bury guest_cpuid_is_amd_or_hygon() in cpuid.c
>
>  arch/x86/include/asm/kvm_host.h |  1 +
>  arch/x86/kvm/cpuid.c            | 13 ++++++
>  arch/x86/kvm/cpuid.h            | 16 ++------
>  arch/x86/kvm/emulate.c          | 71 ++++++++++-----------------------
>  arch/x86/kvm/kvm_emulate.h      |  1 +
>  arch/x86/kvm/lapic.c            |  3 +-
>  arch/x86/kvm/mmu/mmu.c          |  2 +-
>  arch/x86/kvm/pmu.c              |  2 +-
>  arch/x86/kvm/svm/svm.c          | 14 +++----
>  arch/x86/kvm/x86.c              | 30 ++++++++------
>  10 files changed, 68 insertions(+), 85 deletions(-)
>
>
> base-commit: 8cb4a9a82b21623dbb4b3051dd30d98356cf95bc
> --
> 2.44.0.478.gd926399ef9-goog
>