Re: [PATCH 06/29] KVM: move mem_attr_array to kvm_plane

[Sean Christopherson]

On Tue, Apr 01, 2025, Paolo Bonzini wrote:
> Another aspect of the VM that is now different for separate planes is
> memory attributes, in order to support RWX permissions in the future.
> The existing vm-level ioctls apply to plane 0 and the underlying
> functionality operates on struct kvm_plane, which now hosts the
> mem_attr_array xarray.

...

> -bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
> +bool kvm_arch_post_set_memory_attributes(struct kvm_plane *plane,
>  					 struct kvm_gfn_range *range)
>  {
> +	struct kvm *kvm = plane->kvm;
>  	unsigned long attrs = range->arg.attributes;
>  	struct kvm_memory_slot *slot = range->slot;
>  	int level;
> @@ -7767,7 +7770,7 @@ bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
>  			 */
>  			if (gfn >= slot->base_gfn &&
>  			    gfn + nr_pages <= slot->base_gfn + slot->npages) {
> -				if (hugepage_has_attrs(kvm, slot, gfn, level, attrs))
> +				if (hugepage_has_attrs(plane, slot, gfn, level, attrs))
>  					hugepage_clear_mixed(slot, gfn, level);
>  				else
>  					hugepage_set_mixed(slot, gfn, level);

I don't see how this can possibly work.  Memslots are still per-VM, and so
setting/clearing KVM_LPAGE_MIXED_FLAG based on a givne plane's attributes will
clobber the state of the previous plane.

I think we could make this work by having a per-plane KVM_LPAGE_MIXED_FLAG?  I'm
99% certain we can use disallow_lpage[31:28], and _probably_ bits 31:16?  But I'd
rather

Note, to handle shared/private, we could make planes mutually exclusive with
tracking that state per-VM (see the many guest_memfd discussions), but unless I'm
missing something, we'll need the same logic for mixed RWX attributes, so...

Also, as mentioned in a later respone, planes need to be keyed in kvm_mmu_page_role
for this to work.