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?
