From ea9e57d06e48239e19f67769703aa48554f6648b Mon Sep 17 00:00:00 2001 From: Jason Andryuk Date: Tue, 25 Sep 2018 07:36:55 -0400 Subject: [PATCH 01/10] xen: Make XEN_BACKEND selectable by DomU XEN_BACKEND doesn't actually depend on XEN_DOM0. DomUs can serve backends to other DomUs. One example is a service VM providing network backends. The original Kconfig defaulted Dom0 to y and it could be disabled. DomU could not select the option. With the new Kconfig, we default y for Dom0 and n for DomU. Either can then toggle the selection. Signed-off-by: Jason Andryuk Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross --- drivers/xen/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 90d387b50ab7..5ac319b5c880 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -105,8 +105,7 @@ config XEN_DEV_EVTCHN config XEN_BACKEND bool "Backend driver support" - depends on XEN_DOM0 - default y + default XEN_DOM0 help Support for backend device drivers that provide I/O services to other virtual machines. From af320de90ec864bb78fdbc9c0c3e99f28d1aab0f Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 26 Sep 2018 10:43:13 +0200 Subject: [PATCH 02/10] xen/balloon: Grammar s/Is it/It is/ Signed-off-by: Geert Uytterhoeven Signed-off-by: Juergen Gross --- drivers/xen/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 5ac319b5c880..60c0d1c85613 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -86,7 +86,7 @@ config XEN_SCRUB_PAGES_DEFAULT help Scrub pages before returning them to the system for reuse by other domains. This makes sure that any confidential data - is not accidentally visible to other domains. Is it more + is not accidentally visible to other domains. It is more secure, but slightly less efficient. This can be controlled with xen_scrub_pages=0 parameter and /sys/devices/system/xen_memory/xen_memory0/scrub_pages. From 2ac2a7d4d9ff4e01e36f9c3d116582f6f655ab47 Mon Sep 17 00:00:00 2001 From: Juergen Gross Date: Mon, 1 Oct 2018 07:57:42 +0200 Subject: [PATCH 03/10] xen: fix race in xen_qlock_wait() In the following situation a vcpu waiting for a lock might not be woken up from xen_poll_irq(): CPU 1: CPU 2: CPU 3: takes a spinlock tries to get lock -> xen_qlock_wait() frees the lock -> xen_qlock_kick(cpu2) -> xen_clear_irq_pending() takes lock again tries to get lock -> *lock = _Q_SLOW_VAL -> *lock == _Q_SLOW_VAL ? -> xen_poll_irq() frees the lock -> xen_qlock_kick(cpu3) And cpu 2 will sleep forever. This can be avoided easily by modifying xen_qlock_wait() to call xen_poll_irq() only if the related irq was not pending and to call xen_clear_irq_pending() only if it was pending. Cc: stable@vger.kernel.org Cc: Waiman.Long@hp.com Cc: peterz@infradead.org Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Juergen Gross --- arch/x86/xen/spinlock.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 23f6793af88a..290a69ec7d4d 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -45,17 +45,12 @@ static void xen_qlock_wait(u8 *byte, u8 val) if (irq == -1) return; - /* clear pending */ - xen_clear_irq_pending(irq); - barrier(); + /* If irq pending already clear it and return. */ + if (xen_test_irq_pending(irq)) { + xen_clear_irq_pending(irq); + return; + } - /* - * We check the byte value after clearing pending IRQ to make sure - * that we won't miss a wakeup event because of the clearing. - * - * The sync_clear_bit() call in xen_clear_irq_pending() is atomic. - * So it is effectively a memory barrier for x86. - */ if (READ_ONCE(*byte) != val) return; From a856531951dc8094359dfdac21d59cee5969c18e Mon Sep 17 00:00:00 2001 From: Juergen Gross Date: Mon, 1 Oct 2018 07:57:42 +0200 Subject: [PATCH 04/10] xen: make xen_qlock_wait() nestable xen_qlock_wait() isn't safe for nested calls due to interrupts. A call of xen_qlock_kick() might be ignored in case a deeper nesting level was active right before the call of xen_poll_irq(): CPU 1: CPU 2: spin_lock(lock1) spin_lock(lock1) -> xen_qlock_wait() -> xen_clear_irq_pending() Interrupt happens spin_unlock(lock1) -> xen_qlock_kick(CPU 2) spin_lock_irqsave(lock2) spin_lock_irqsave(lock2) -> xen_qlock_wait() -> xen_clear_irq_pending() clears kick for lock1 -> xen_poll_irq() spin_unlock_irq_restore(lock2) -> xen_qlock_kick(CPU 2) wakes up spin_unlock_irq_restore(lock2) IRET resumes in xen_qlock_wait() -> xen_poll_irq() never wakes up The solution is to disable interrupts in xen_qlock_wait() and not to poll for the irq in case xen_qlock_wait() is called in nmi context. Cc: stable@vger.kernel.org Cc: Waiman.Long@hp.com Cc: peterz@infradead.org Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Juergen Gross --- arch/x86/xen/spinlock.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c index 290a69ec7d4d..441c88262169 100644 --- a/arch/x86/xen/spinlock.c +++ b/arch/x86/xen/spinlock.c @@ -39,29 +39,25 @@ static void xen_qlock_kick(int cpu) */ static void xen_qlock_wait(u8 *byte, u8 val) { + unsigned long flags; int irq = __this_cpu_read(lock_kicker_irq); /* If kicker interrupts not initialized yet, just spin */ - if (irq == -1) + if (irq == -1 || in_nmi()) return; - /* If irq pending already clear it and return. */ + /* Guard against reentry. */ + local_irq_save(flags); + + /* If irq pending already clear it. */ if (xen_test_irq_pending(irq)) { xen_clear_irq_pending(irq); - return; + } else if (READ_ONCE(*byte) == val) { + /* Block until irq becomes pending (or a spurious wakeup) */ + xen_poll_irq(irq); } - if (READ_ONCE(*byte) != val) - return; - - /* - * If an interrupt happens here, it will leave the wakeup irq - * pending, which will cause xen_poll_irq() to return - * immediately. - */ - - /* Block until irq becomes pending (or perhaps a spurious wakeup) */ - xen_poll_irq(irq); + local_irq_restore(flags); } static irqreturn_t dummy_handler(int irq, void *dev_id) From 7deecbda3026f5e2a8cc095d7ef7261a920efcf2 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Tue, 9 Oct 2018 12:32:37 +0200 Subject: [PATCH 05/10] xen/pvh: increase early stack size MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit While booting on an AMD EPYC box the stack canary would detect stack overflows when using the current PVH early stack size (256). Switch to using the value defined by BOOT_STACK_SIZE, which prevents the stack overflow. Cc: # 4.11 Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross --- arch/x86/xen/xen-pvh.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S index b0e471506cd8..1f8825bbaffb 100644 --- a/arch/x86/xen/xen-pvh.S +++ b/arch/x86/xen/xen-pvh.S @@ -170,7 +170,7 @@ canary: .fill 48, 1, 0 early_stack: - .fill 256, 1, 0 + .fill BOOT_STACK_SIZE, 1, 0 early_stack_end: ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, From 3aa6c19d2f38be9c6e9a8ad5fa8e3c9d29ee3c35 Mon Sep 17 00:00:00 2001 From: Boris Ostrovsky Date: Sun, 7 Oct 2018 16:05:38 -0400 Subject: [PATCH 06/10] xen/balloon: Support xend-based toolstack Xend-based toolstacks don't have static-max entry in xenstore. The equivalent node for those toolstacks is memory_static_max. Fixes: 5266b8e4445c (xen: fix booting ballooned down hvm guest) Signed-off-by: Boris Ostrovsky Cc: # 4.13 Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross --- drivers/xen/xen-balloon.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c index 63c1494a8d73..2acbfe104e46 100644 --- a/drivers/xen/xen-balloon.c +++ b/drivers/xen/xen-balloon.c @@ -76,12 +76,15 @@ static void watch_target(struct xenbus_watch *watch, if (!watch_fired) { watch_fired = true; - err = xenbus_scanf(XBT_NIL, "memory", "static-max", "%llu", - &static_max); - if (err != 1) - static_max = new_target; - else + + if ((xenbus_scanf(XBT_NIL, "memory", "static-max", + "%llu", &static_max) == 1) || + (xenbus_scanf(XBT_NIL, "memory", "memory_static_max", + "%llu", &static_max) == 1)) static_max >>= PAGE_SHIFT - 10; + else + static_max = new_target; + target_diff = (xen_pv_domain() || xen_initial_domain()) ? 0 : static_max - balloon_stats.target_pages; } From f1db0050483cd3d63bb7b2e8c8a772501d52031b Mon Sep 17 00:00:00 2001 From: Bartlomiej Zolnierkiewicz Date: Tue, 16 Oct 2018 16:33:58 +0200 Subject: [PATCH 07/10] xen: remove redundant 'default n' from Kconfig 'default n' is the default value for any bool or tristate Kconfig setting so there is no need to write it explicitly. Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO is not set' for visible symbols") the Kconfig behavior is the same regardless of 'default n' being present or not: ... One side effect of (and the main motivation for) this change is making the following two definitions behave exactly the same: config FOO bool config FOO bool default n With this change, neither of these will generate a '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied). That might make it clearer to people that a bare 'default n' is redundant. ... Signed-off-by: Bartlomiej Zolnierkiewicz Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross --- drivers/xen/Kconfig | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 60c0d1c85613..815b9e9bb975 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -12,7 +12,6 @@ config XEN_BALLOON config XEN_SELFBALLOONING bool "Dynamically self-balloon kernel memory to target" depends on XEN && XEN_BALLOON && CLEANCACHE && SWAP && XEN_TMEM - default n help Self-ballooning dynamically balloons available kernel memory driven by the current usage of anonymous memory ("committed AS") and @@ -27,7 +26,6 @@ config XEN_SELFBALLOONING config XEN_BALLOON_MEMORY_HOTPLUG bool "Memory hotplug support for Xen balloon driver" - default n depends on XEN_BALLOON && MEMORY_HOTPLUG help Memory hotplug support for Xen balloon driver allows expanding memory @@ -226,7 +224,6 @@ config XEN_PCIDEV_BACKEND config XEN_PVCALLS_FRONTEND tristate "XEN PV Calls frontend driver" depends on INET && XEN - default n select XEN_XENBUS_FRONTEND help Experimental frontend for the Xen PV Calls protocol @@ -237,7 +234,6 @@ config XEN_PVCALLS_FRONTEND config XEN_PVCALLS_BACKEND bool "XEN PV Calls backend driver" depends on INET && XEN && XEN_BACKEND - default n help Experimental backend for the Xen PV Calls protocol (https://xenbits.xen.org/docs/unstable/misc/pvcalls.html). It @@ -263,7 +259,6 @@ config XEN_PRIVCMD config XEN_STUB bool "Xen stub drivers" depends on XEN && X86_64 && BROKEN - default n help Allow kernel to install stub drivers, to reserve space for Xen drivers, i.e. memory hotplug and cpu hotplug, and to block native drivers loaded, @@ -274,7 +269,6 @@ config XEN_STUB config XEN_ACPI_HOTPLUG_MEMORY tristate "Xen ACPI memory hotplug" depends on XEN_DOM0 && XEN_STUB && ACPI - default n help This is Xen ACPI memory hotplug. @@ -286,7 +280,6 @@ config XEN_ACPI_HOTPLUG_CPU tristate "Xen ACPI cpu hotplug" depends on XEN_DOM0 && XEN_STUB && ACPI select ACPI_CONTAINER - default n help Xen ACPI cpu enumerating and hotplugging @@ -315,7 +308,6 @@ config XEN_ACPI_PROCESSOR config XEN_MCE_LOG bool "Xen platform mcelog" depends on XEN_DOM0 && X86_64 && X86_MCE - default n help Allow kernel fetching MCE error from Xen platform and converting it into Linux mcelog format for mcelog tools From 769d6bfc74c1f02333dd5f9a438df3346aded56f Mon Sep 17 00:00:00 2001 From: Stefano Stabellini Date: Wed, 17 Oct 2018 21:44:45 +0800 Subject: [PATCH 08/10] add myself as reviewer for Xen support in Linux It would be good for me to keep an eye on the patches that touch Xen support in Linux to try to spot changes that break Xen on ARM early on. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index af2a61a31a8e..748c3dd3ca09 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16120,6 +16120,7 @@ F: arch/arm64/include/asm/xen/ XEN HYPERVISOR INTERFACE M: Boris Ostrovsky M: Juergen Gross +R: Stefano Stabellini L: xen-devel@lists.xenproject.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git S: Supported From e6111161c0a02d58919d776eec94b313bb57911f Mon Sep 17 00:00:00 2001 From: Juergen Gross Date: Thu, 25 Oct 2018 09:54:15 +0200 Subject: [PATCH 09/10] xen/pvh: don't try to unplug emulated devices A Xen PVH guest has no associated qemu device model, so trying to unplug any emulated devices is making no sense at all. Bail out early from xen_unplug_emulated_devices() when running as PVH guest. This will avoid issuing the boot message: [ 0.000000] Xen Platform PCI: unrecognised magic value Cc: # 4.11 Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross --- arch/x86/xen/platform-pci-unplug.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c index 66ab96a4e2b3..96d7f7d39cb9 100644 --- a/arch/x86/xen/platform-pci-unplug.c +++ b/arch/x86/xen/platform-pci-unplug.c @@ -134,6 +134,10 @@ void xen_unplug_emulated_devices(void) { int r; + /* PVH guests don't have emulated devices. */ + if (xen_pvh_domain()) + return; + /* user explicitly requested no unplug */ if (xen_emul_unplug & XEN_UNPLUG_NEVER) return; From 7a048cec598e1761cdcd63eb3a3c6e390b7661c7 Mon Sep 17 00:00:00 2001 From: Juergen Gross Date: Tue, 9 Oct 2018 18:09:59 +0200 Subject: [PATCH 10/10] xen: drop writing error messages to xenstore xenbus_va_dev_error() will try to write error messages to Xenstore under the error//error node (with something like "device/vbd/51872"). This will fail normally and another message about this failure is added to dmesg. I believe this is a remnant from very ancient times, as it was added in the first pvops rush of commits in 2007. So remove the additional message when writing to Xenstore failed as a minimum step. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross --- drivers/xen/xenbus/xenbus_client.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index a1c17000129b..e17ca8156171 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -278,10 +278,8 @@ static void xenbus_va_dev_error(struct xenbus_device *dev, int err, dev_err(&dev->dev, "%s\n", printf_buffer); path_buffer = kasprintf(GFP_KERNEL, "error/%s", dev->nodename); - if (!path_buffer || - xenbus_write(XBT_NIL, path_buffer, "error", printf_buffer)) - dev_err(&dev->dev, "failed to write error node for %s (%s)\n", - dev->nodename, printf_buffer); + if (path_buffer) + xenbus_write(XBT_NIL, path_buffer, "error", printf_buffer); kfree(printf_buffer); kfree(path_buffer);