On Tue, 23 Jun 2026 at 01:22, Sean Christopherson <[email protected]> wrote: > > On Fri, Jun 19, 2026, Fuad Tabba wrote: > > On Fri, 19 Jun 2026 at 01:31, Ackerley Tng via B4 Relay > > <[email protected]> wrote: > > > > > > From: Ackerley Tng <[email protected]> > > > > > > Introduce base support for KVM_SET_MEMORY_ATTRIBUTES2 in guest_memfd, > > > which > > > just updates attributes tracked by guest_memfd. > > > > > > Validate input fields in general. Guard usage of > > > KVM_SET_MEMORY_ATTRIBUTES2 > > > by making sure requested attributes are supported for this instance of > > > kvm. > > > > > > A new KVM_SET_MEMORY_ATTRIBUTES2 is defined to support writes (unlike > > > KVM_SET_MEMORY_ATTRIBUTES) in addition to reads so it can provide error > > > details to userspace. This will be used in a later patch. > > > > > > The two ioctls use their corresponding structs with no overlap, but > > > backward compatibility is baked in for future support of > > > KVM_SET_MEMORY_ATTRIBUTES2 and struct kvm_memory_attributes2 in the VM > > > ioctl. > > > > > > The process of setting memory attributes is set up such that the later > > > half > > > will not fail due to allocation. Any necessary checks are performed before > > > the point of no return. > > > > > > Co-developed-by: Vishal Annapurve <[email protected]> > > > Signed-off-by: Vishal Annapurve <[email protected]> > > > Co-developed-by: Sean Christoperson <[email protected]> > > > Signed-off-by: Sean Christoperson <[email protected]> > > > Reviewed-by: Fuad Tabba <[email protected]> > > > Signed-off-by: Ackerley Tng <[email protected]> > > > > Note sure if it's user error on my part, if I'm applying this to the > > wrong base, but I found a build break here on patch 13: > > kvm_gmem_invalidate_start() doesn't exist in the base tree. The > > function is kvm_gmem_invalidate_begin() here. The rename > > (190cc5370a8b6) landed via a different merge path and isn't an > > ancestor of the stated base. > > > > Patches 19 and 20 have the same mismatch. Fix for all three is > > s/kvm_gmem_invalidate_start/kvm_gmem_invalidate_begin/. > > Ya, Ackerley used a slightly older kvm/next to send the patches. I at least > was > testing against kvm-x86/next, which does have the rename. > > Other than noting that this should be applied against the current kvm/next, I > don't think there's anything else to be done?
Agree. Sorry, didn't mean to be nit-picky, but this really threw me off :) Cheers, /fuad
