Re: [GIT PULL] KVM: GUEST_MEMFD fixes for 6.8

[Paolo Bonzini]

On Fri, Feb 23, 2024 at 10:32 PM Sean Christopherson <seanjc@googlecom> wrote:
>
> On Fri, Feb 23, 2024, Sean Christopherson wrote:
> > Minor fixes related GUEST_MEMFD.  I _just_ posted these, and they've only
> > been in -next for one night, but I am sending this now to ensure you see it
> > asap, as patch 1 in particular affects KVM's ABI, i.e. really should land
> > in 6.8 before GUEST_MEMFD support is officially released.
> >
> > The following changes since commit c48617fbbe831d4c80fe84056033f17b70a31136:
> >
> >   Merge tag 'kvmarm-fixes-6.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD (2024-02-21 05:18:56 -0500)
> >
> > are available in the Git repository at:
> >
> >   https://github.com/kvm-x86/linux.git tags/kvm-x86-guest_memfd_fixes-68
> >
> > for you to fetch changes up to 2dfd2383034421101300a3b7325cf339a182d218:
> >
> >   KVM: selftests: Add a testcase to verify GUEST_MEMFD and READONLY are exclusive (2024-02-22 17:07:06 -0800)
> >
> > ----------------------------------------------------------------
> > KVM GUEST_MEMFD fixes for 6.8:
> >
> >  - Make KVM_MEM_GUEST_MEMFD mutually exclusive with KVM_MEM_READONLY to
> >    avoid creating ABI that KVM can't sanely support.
> >
> >  - Update documentation for KVM_SW_PROTECTED_VM to make it abundantly
> >    clear that such VMs are purely a development and testing vehicle, and
> >    come with zero guarantees.
> >
> >  - Limit KVM_SW_PROTECTED_VM guests to the TDP MMU, as the long term plan
> >    is to support confidential VMs with deterministic private memory (SNP
> >    and TDX) only in the TDP MMU.
> >
> >  - Fix a bug in a GUEST_MEMFD negative test that resulted in false passes
> >    when verifying that KVM_MEM_GUEST_MEMFD memslots can't be dirty logged.
> >
> > ----------------------------------------------------------------
> > Sean Christopherson (5):
> >       KVM: Make KVM_MEM_GUEST_MEMFD mutually exclusive with KVM_MEM_READONLY
>
> Almost forgot, just as an FYI, this has a minor conflict with your kvm/kvm-uapi
> branch.  I've been fixing it up in kvm-x86/next, and IIUC you don't feed kvm/master
> into -next, so I don't think Stephen will see a conflict?

I do feed it in linux-next, so he would, but it's not a big deal. I'll
pull it into kvm-next as well.

Paolo