On Fri, Feb 23, 2024 at 10:32 PM Sean Christopherson <seanjc@xxxxxxxxxx> 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-6.8 > > > > 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
