On Mon, Feb 01, 2021 at 02:38:05PM +0100, Paolo Bonzini wrote: > On 01/02/21 14:31, Marc Zyngier wrote: > > commit 139bc8a6146d92822c866cf2fd410159c56b3648 upstream. > > > > The use of a tagged address could be pretty confusing for the > > whole memslot infrastructure as well as the MMU notifiers. > > > > Forbid it altogether, as it never quite worked the first place. > > > > Cc: stable@xxxxxxxxxxxxxxx > > Reported-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> > > Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx> > > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx> > > --- > > Documentation/virt/kvm/api.txt | 3 +++ > > virt/kvm/kvm_main.c | 1 + > > 2 files changed, 4 insertions(+) > > > > diff --git a/Documentation/virt/kvm/api.txt b/Documentation/virt/kvm/api.txt > > index a18e996fa54b..7064efd3b5ea 100644 > > --- a/Documentation/virt/kvm/api.txt > > +++ b/Documentation/virt/kvm/api.txt > > @@ -1132,6 +1132,9 @@ field userspace_addr, which must point at user addressable memory for > > the entire memory slot size. Any object may back this memory, including > > anonymous memory, ordinary files, and hugetlbfs. > > +On architectures that support a form of address tagging, userspace_addr must > > +be an untagged address. > > + > > It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr > > be identical. This allows large pages in the guest to be backed by large > > pages in the host. > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 8f3b40ec02b7..f25b5043cbca 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -1017,6 +1017,7 @@ int __kvm_set_memory_region(struct kvm *kvm, > > /* We can read the guest memory with __xxx_user() later on. */ > > if ((id < KVM_USER_MEM_SLOTS) && > > ((mem->userspace_addr & (PAGE_SIZE - 1)) || > > + (mem->userspace_addr != untagged_addr(mem->userspace_addr)) || > > !access_ok((void __user *)(unsigned long)mem->userspace_addr, > > mem->memory_size))) > > goto out; > > > > Indeed untagged_addr was added in 5.3. > > Acked-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> Now queued up, thanks. greg k-h
