On Wed, Jul 01, 2026, Xiaoyao Li wrote: > On 7/1/2026 1:30 AM, Sean Christopherson wrote: > > On Tue, Jun 30, 2026, Xiaoyao Li wrote: > > > On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote: > > > > -bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, > > > > gfn_t end, > > > > - unsigned long mask, unsigned long > > > > attrs); > > > > +bool kvm_range_has_vm_memory_attributes(struct kvm *kvm, gfn_t start, > > > > gfn_t end, > > > > + unsigned long mask, unsigned > > > > long attrs); > > > > bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm, > > > > struct kvm_gfn_range *range); > > > > bool kvm_arch_post_set_memory_attributes(struct kvm *kvm, > > > > > > We have > > > > > > - kvm_pre_set_memory_attributes() > > > - kvm_arch_pre_set_memory_attributes() > > > - kvm_arch_post_set_memory_attributes() > > > > Yeah, that's probably for the best. > > > > > left, do they need to be renamed as well? > > > > > > then the interesting one is kvm_vm_set_mem_attributes(), which contains > > > "vm" > > > already while it means "vm ioctl". Do we need to rename it to > > > kvm_vm_set_vm_mem_attributes()? > > > > I say "no" on this last one, the fact that the function is scoped to a VM > > ioctl > > is enough to communicate that it applies to per-VM attributes. > > > > Actually, since it's a local helper, we could go with > > kvm_set_vm_mem_attributes() > > to be consistent with the other functions. That just leaves > > kvm_vm_ioctl_set_mem_attributes(), which I think it appropriately scoped. > > If we finally choose to rename kvm_vm_set_mem_attributes() to > kvm_set_vm_mem_attributes(), I think the trace > trace_kvm_vm_set_mem_attributes() needs to be renamed to keep it consistent?
Ya, good catch!
