--- /dev/null
+From 139bc8a6146d92822c866cf2fd410159c56b3648 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Thu, 21 Jan 2021 12:08:15 +0000
+Subject: KVM: Forbid the use of tagged userspace addresses for memslots
+
+From: Marc Zyngier <maz@kernel.org>
+
+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@vger.kernel.org
+Reported-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Acked-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ Documentation/virt/kvm/api.txt | 3 +++
+ virt/kvm/kvm_main.c | 1 +
+ 2 files changed, 4 insertions(+)
+
+--- a/Documentation/virt/kvm/api.txt
++++ b/Documentation/virt/kvm/api.txt
+@@ -1132,6 +1132,9 @@ field userspace_addr, which must point a
+ 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.
+--- a/virt/kvm/kvm_main.c
++++ b/virt/kvm/kvm_main.c
+@@ -1017,6 +1017,7 @@ int __kvm_set_memory_region(struct 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;
--- /dev/null
+From 5f46400f7a6a4fad635d5a79e2aa5a04a30ffea1 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+Date: Tue, 26 Jan 2021 17:01:49 +0000
+Subject: xen: Fix XenStore initialisation for XS_LOCAL
+
+From: David Woodhouse <dwmw@amazon.co.uk>
+
+commit 5f46400f7a6a4fad635d5a79e2aa5a04a30ffea1 upstream.
+
+In commit 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI")
+I reworked the triggering of xenbus_probe().
+
+I tried to simplify things by taking out the workqueue based startup
+triggered from wake_waiting(); the somewhat poorly named xenbus IRQ
+handler.
+
+I missed the fact that in the XS_LOCAL case (Dom0 starting its own
+xenstored or xenstore-stubdom, which happens after the kernel is booted
+completely), that IRQ-based trigger is still actually needed.
+
+So... put it back, except more cleanly. By just spawning a xenbus_probe
+thread which waits on xb_waitq and runs the probe the first time it
+gets woken, just as the workqueue-based hack did.
+
+This is actually a nicer approach for *all* the back ends with different
+interrupt methods, and we can switch them all over to that without the
+complex conditions for when to trigger it. But not in -rc6. This is
+the minimal fix for the regression, although it's a step in the right
+direction instead of doing a partial revert and actually putting the
+workqueue back. It's also simpler than the workqueue.
+
+Fixes: 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI")
+Reported-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Link: https://lore.kernel.org/r/4c9af052a6e0f6485d1de43f2c38b1461996db99.camel@infradead.org
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Cc: Salvatore Bonaccorso <carnil@debian.org>
+Cc: Jason Andryuk <jandryuk@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/xenbus/xenbus_probe.c | 31 +++++++++++++++++++++++++++++++
+ 1 file changed, 31 insertions(+)
+
+--- a/drivers/xen/xenbus/xenbus_probe.c
++++ b/drivers/xen/xenbus/xenbus_probe.c
+@@ -714,6 +714,23 @@ static bool xs_hvm_defer_init_for_callba
+ #endif
+ }
+
++static int xenbus_probe_thread(void *unused)
++{
++ DEFINE_WAIT(w);
++
++ /*
++ * We actually just want to wait for *any* trigger of xb_waitq,
++ * and run xenbus_probe() the moment it occurs.
++ */
++ prepare_to_wait(&xb_waitq, &w, TASK_INTERRUPTIBLE);
++ schedule();
++ finish_wait(&xb_waitq, &w);
++
++ DPRINTK("probing");
++ xenbus_probe();
++ return 0;
++}
++
+ static int __init xenbus_probe_initcall(void)
+ {
+ /*
+@@ -725,6 +742,20 @@ static int __init xenbus_probe_initcall(
+ !xs_hvm_defer_init_for_callback()))
+ xenbus_probe();
+
++ /*
++ * For XS_LOCAL, spawn a thread which will wait for xenstored
++ * or a xenstore-stubdom to be started, then probe. It will be
++ * triggered when communication starts happening, by waiting
++ * on xb_waitq.
++ */
++ if (xen_store_domain_type == XS_LOCAL) {
++ struct task_struct *probe_task;
++
++ probe_task = kthread_run(xenbus_probe_thread, NULL,
++ "xenbus_probe");
++ if (IS_ERR(probe_task))
++ return PTR_ERR(probe_task);
++ }
+ return 0;
+ }
+ device_initcall(xenbus_probe_initcall);
projects / thirdparty / kernel / stable-queue.git / commitdiff
