Received-SPF: pass (google.com: domain of linux-kernel+bounces-84058-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: <20240227192451.3792233-1-seanjc@google.com>
In-Reply-To: <20240227192451.3792233-1-seanjc@google.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Tue, 27 Feb 2024 22:35:39 +0100
Message-ID: <CABgObfakhde_Xwhj1Q5LLkD-TxMCWoAMfz40HC_Nr6y5hDLBYA@mail.gmail.com>
Subject: Re: [GIT PULL] KVM: x86: SVM changes for 6.9
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 27, 2024 at 8:24=E2=80=AFPM Sean Christopherson <seanjc@google.=
com> wrote:
> Please pull a single series that allows KVM to play nice with systems tha=
t have
> all ASIDs binned to SEV-ES+ guests, which makes SEV unusuable despite bei=
ng
> enabled.

Ok, will do so tomorrow.

> This is the main source of conflicts between kvm/next and your "allow
> customizing VMSA features".  guest_memfd_fixes also has a minor conflict =
in
> kvm_is_vm_type_supported(), but you should already have that pull request=
 for
> 6.8[1].
>
> There is one more trivial conflict in my "misc" branch, in
> kvm_vcpu_ioctl_x86_set_debugregs(), but I am going to hold off one sendin=
g a
> pull request for that branch until next week.  The main reason is because=
 I
> screwed up and forgot to push a pile of commits from my local tree to kvm=
-x86,
> and sending a pull request for ~3 commits, and then another for the remai=
ning
> 16 or so commits seemed rather silly.  The other reason is that I am hopi=
ng we
> can avoid that conflict entirely, by adding a common choke point in
> kvm_arch_vcpu_ioctl()[2].

Yes, I'll do that. I have to respin anyway to get the SEV test
infrastructure. I'll keep posting against kvm-x86/next, though.

Paolo