Re: [Xen-devel] [PATCH] xen: make sure stop_machine_run() is always called in a tasklet
On 14.02.20 18:34, Igor Druzhinin wrote: On 14/02/2020 16:39, Jürgen Groß wrote: On 14.02.20 15:06, Igor Druzhinin wrote: On 11/02/2020 09:35, Juergen Gross wrote: With core scheduling active it is mandatory for stop_machine_run() to be called in a tasklet only, as otherwise a scheduling deadlock would occur: stop_machine_run() does a cpu rendezvous by activating a tasklet on all other cpus. In case stop_machine_run() was not called in an idle vcpu it would block scheduling the idle vcpu on its siblings with core scheduling being active, resulting in a hang. I suppose rcu_barrier() is fine due to process_pending_softirqs() being called inside? I'm a little concerned by imposing is_vcpu_idle() restriction in that case as rcu_barrier() could be technically called from a non-tasklet context. No, stop_machine_run() with core scheduling active can only work when called in an idle vcpu. OTOH it would be fairly easy to add another softirq for a similar purpose and have a sync_machine_run() using that instead of tasklets. This could be used for ucode loading, too. stop_machine_run() and sync_machine_run() could use a common main function. The patch should be rather simple. Thoughts? I have a patch on the list (which I was planning to send a v2 for) that fixes another issue with rcu_barrier(): https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg02273.html As I understand it now that wouldn't work with core-scheduling. Do you think it's possible to synchronously wait for tasklets to finish in non-tasklet context (because that's what the purpose of rcu_barrier() is)? No, won't work, unless we add preemption (basically would need per-vcpu stacks instead of per-pcpu ones). What might work IMO would be to do rcu_process_callbacks() no longer during idle, but to have a specific softirq for that purpose. This would remove the need to involve scheduling for rcu_barrier(). A brief check of process_pending_softirqs() callers seems to allow that, but I'd like to have a second opinion from someone having more rcu knowledge than me. Single problematic users of process_pending_softirqs() could still be switched to a variant not allowing the new rcu softirq. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.19 test] 147024: regressions - FAIL
flight 147024 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/147024/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 13 guest-start.2 fail in 146901 REGR. vs. 142932 Tests which are failing intermittently (not blocking): test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 146901 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 146901 like 142880 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 142932 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux357668399cf70ccdc0ee8967bff3448d0f4f9ae1 baseline version: linuxc3038e718a19fc596f7b1baba0f83d5146dc7784 Last test of basis 142932 2019-10-19 23:17:10 Z 118 days Failing since143326 2019-10-29 08:49:29 Z 108 days9 attempts Testing same since
[Xen-devel] [xen-unstable test] 147022: tolerable FAIL
flight 147022 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/147022/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 146896 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 146936 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 146936 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 146936 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 146936 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 146936 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 146936 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 146936 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 146936 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 146936 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 146936 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 146936 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 147022 2020-02-13 18:17:13 Z1 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass
Re: [Xen-devel] [RFC PATCH v3 00/12] Enable PM hibernation on guest VMs
I did resend them today. Apologies for delay https://lkml.org/lkml/2020/2/14/2789 Thanks, Anchal Ancha, Anchal Agarwal writes: > Hello, > I am sending out a v3 version of series of patches that implements guest > PM hibernation. can you pretty please thread your patch series so that the 1-n/n mails have a References: in the headers? git-send-email does that proper as do other tools. Collecting the individual mails is painful. Thanks, tglx ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 12/12] PM / hibernate: update the resume offset on SNAPSHOT_SET_SWAP_AREA
From: Aleksei Besogonov
The SNAPSHOT_SET_SWAP_AREA is supposed to be used to set the hibernation
offset on a running kernel to enable hibernating to a swap file.
However, it doesn't actually update the swsusp_resume_block variable. As
a result, the hibernation fails at the last step (after all the data is
written out) in the validation of the swap signature in
mark_swapfiles().
Before this patch, the command line processing was the only place where
swsusp_resume_block was set.
Signed-off-by: Aleksei Besogonov
Signed-off-by: Munehisa Kamata
Signed-off-by: Anchal Agarwal
---
kernel/power/user.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/power/user.c b/kernel/power/user.c
index 77438954cc2b..d396e313cb7b 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -374,8 +374,12 @@ static long snapshot_ioctl(struct file *filp, unsigned int
cmd,
if (swdev) {
offset = swap_area.offset;
data->swap = swap_type_of(swdev, offset, NULL);
- if (data->swap < 0)
+ if (data->swap < 0) {
error = -ENODEV;
+ } else {
+ swsusp_resume_device = swdev;
+ swsusp_resume_block = offset;
+ }
} else {
data->swap = -1;
error = -EINVAL;
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 10/12] xen: Introduce wrapper for save/restore sched clock offset
Introduce wrappers for save/restore xen_sched_clock_offset to be
used by PM hibernation code to avoid system instability during resume.
Signed-off-by: Anchal Agarwal
---
arch/x86/xen/time.c| 15 +--
arch/x86/xen/xen-ops.h | 2 ++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 8cf632dda605..eeb6d3d2eaab 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -379,12 +379,23 @@ static const struct pv_time_ops xen_time_ops __initconst
= {
static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
static u64 xen_clock_value_saved;
+/*This is needed to maintain a monotonic clock value during PM hibernation */
+void xen_save_sched_clock_offset(void)
+{
+ xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
+}
+
+void xen_restore_sched_clock_offset(void)
+{
+ xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved;
+}
+
void xen_save_time_memory_area(void)
{
struct vcpu_register_time_memory_area t;
int ret;
- xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
+ xen_save_sched_clock_offset();
if (!xen_clock)
return;
@@ -426,7 +437,7 @@ void xen_restore_time_memory_area(void)
out:
/* Need pvclock_resume() before using xen_clocksource_read(). */
pvclock_resume();
- xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved;
+ xen_restore_sched_clock_offset();
}
static void xen_setup_vsyscall_time_info(void)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index d84c357994bd..9f49124df033 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -72,6 +72,8 @@ void xen_save_time_memory_area(void);
void xen_restore_time_memory_area(void);
void xen_init_time_ops(void);
void xen_hvm_init_time_ops(void);
+void xen_save_sched_clock_offset(void);
+void xen_restore_sched_clock_offset(void);
irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 11/12] xen: Update sched clock offset to avoid system instability in hibernation
Save/restore xen_sched_clock_offset in syscore suspend/resume during PM
hibernation. Commit '867cefb4cb1012: ("xen: Fix x86 sched_clock() interface
for xen")' fixes xen guest time handling during migration. A similar issue
is seen during PM hibernation when system runs CPU intensive workload.
Post resume pvclock resets the value to 0 however, xen sched_clock_offset
is never updated. System instability is seen during resume from hibernation
when system is under heavy CPU load. Since xen_sched_clock_offset is not
updated, system does not see the monotonic clock value and the scheduler
would then think that heavy CPU hog tasks need more time in CPU, causing
the system to freeze
Signed-off-by: Anchal Agarwal
---
arch/x86/xen/suspend.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index dae0f74f5390..7e5275944810 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -105,6 +105,8 @@ static int xen_syscore_suspend(void)
xen_save_steal_clock(cpu);
}
+ xen_save_sched_clock_offset();
+
xrfp.domid = DOMID_SELF;
xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
@@ -126,6 +128,12 @@ static void xen_syscore_resume(void)
pvclock_resume();
+ /*
+* Restore xen_sched_clock_offset during resume to maintain
+* monotonic clock value
+*/
+ xen_restore_sched_clock_offset();
+
/* Nonboot CPUs will be resumed when they're brought up */
xen_restore_steal_clock(smp_processor_id());
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 09/12] x86/xen: save and restore steal clock
From: Munehisa Kamata
Save steal clock values of all present CPUs in the system core ops
suspend callbacks. Also, restore a boot CPU's steal clock in the system
core resume callback. For non-boot CPUs, restore after they're brought
up, because runstate info for non-boot CPUs are not active until then.
Signed-off-by: Munehisa Kamata
Signed-off-by: Anchal Agarwal
---
arch/x86/xen/suspend.c | 13 -
arch/x86/xen/time.c| 3 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 784c4484100b..dae0f74f5390 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -91,12 +91,20 @@ void xen_arch_suspend(void)
static int xen_syscore_suspend(void)
{
struct xen_remove_from_physmap xrfp;
- int ret;
+ int cpu, ret;
/* Xen suspend does similar stuffs in its own logic */
if (xen_suspend_mode_is_xen_suspend())
return 0;
+ for_each_present_cpu(cpu) {
+ /*
+* Nonboot CPUs are already offline, but the last copy of
+* runstate info is still accessible.
+*/
+ xen_save_steal_clock(cpu);
+ }
+
xrfp.domid = DOMID_SELF;
xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
@@ -118,6 +126,9 @@ static void xen_syscore_resume(void)
pvclock_resume();
+ /* Nonboot CPUs will be resumed when they're brought up */
+ xen_restore_steal_clock(smp_processor_id());
+
gnttab_resume();
}
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index befbdd8b17f0..8cf632dda605 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -537,6 +537,9 @@ static void xen_hvm_setup_cpu_clockevents(void)
{
int cpu = smp_processor_id();
xen_setup_runstate_info(cpu);
+ if (cpu)
+ xen_restore_steal_clock(cpu);
+
/*
* xen_setup_timer(cpu) - snprintf is bad in atomic context. Hence
* doing it xen_hvm_cpu_notify (which gets called by smp_init during
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 07/12] genirq: Shutdown irq chips in suspend/resume during hibernation
There are no pm handlers for the legacy devices, so during tear down
stale event channel <> IRQ mapping may still remain in the image and
resume may fail. To avoid adding much code by implementing handlers for
legacy devices, add a new irq_chip flag IRQCHIP_SHUTDOWN_ON_SUSPEND which
when enabled on an irq-chip e.g xen-pirq, it will let core suspend/resume
irq code to shutdown and restart the active irqs. PM suspend/hibernation
code will rely on this.
Without this, in PM hibernation, information about the event channel
remains in hibernation image, but there is no guarantee that the same
event channel numbers are assigned to the devices when restoring the
system. This may cause conflict like the following and prevent some
devices from being restored correctly.
Signed-off-by: Anchal Agarwal
Suggested-by: Thomas Gleixner
---
drivers/xen/events/events_base.c | 1 +
include/linux/irq.h | 2 ++
kernel/irq/chip.c| 2 +-
kernel/irq/internals.h | 1 +
kernel/irq/pm.c | 31 ++-
5 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 6c8843968a52..e44f27b45bef 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1620,6 +1620,7 @@ static struct irq_chip xen_pirq_chip __read_mostly = {
.irq_set_affinity = set_affinity_irq,
.irq_retrigger = retrigger_dynirq,
+ .flags = IRQCHIP_SHUTDOWN_ON_SUSPEND,
};
static struct irq_chip xen_percpu_chip __read_mostly = {
diff --git a/include/linux/irq.h b/include/linux/irq.h
index fb301cf29148..2873a579fd9d 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -511,6 +511,7 @@ struct irq_chip {
* IRQCHIP_EOI_THREADED: Chip requires eoi() on unmask in threaded mode
* IRQCHIP_SUPPORTS_LEVEL_MSI Chip can provide two doorbells for Level MSIs
* IRQCHIP_SUPPORTS_NMI: Chip can deliver NMIs, only for root irqchips
+ * IRQCHIP_SHUTDOWN_ON_SUSPEND: Shutdown non wake irqs in the suspend path
*/
enum {
IRQCHIP_SET_TYPE_MASKED = (1 << 0),
@@ -522,6 +523,7 @@ enum {
IRQCHIP_EOI_THREADED= (1 << 6),
IRQCHIP_SUPPORTS_LEVEL_MSI = (1 << 7),
IRQCHIP_SUPPORTS_NMI= (1 << 8),
+ IRQCHIP_SHUTDOWN_ON_SUSPEND = (1 << 9),
};
#include
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index b76703b2c0af..a1e8df5193ba 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -233,7 +233,7 @@ __irq_startup_managed(struct irq_desc *desc, struct cpumask
*aff, bool force)
}
#endif
-static int __irq_startup(struct irq_desc *desc)
+int __irq_startup(struct irq_desc *desc)
{
struct irq_data *d = irq_desc_get_irq_data(desc);
int ret = 0;
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index 3924fbe829d4..11c7c55bda63 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -80,6 +80,7 @@ extern void __enable_irq(struct irq_desc *desc);
extern int irq_activate(struct irq_desc *desc);
extern int irq_activate_and_startup(struct irq_desc *desc, bool resend);
extern int irq_startup(struct irq_desc *desc, bool resend, bool force);
+extern int __irq_startup(struct irq_desc *desc);
extern void irq_shutdown(struct irq_desc *desc);
extern void irq_shutdown_and_deactivate(struct irq_desc *desc);
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 8f557fa1f4fe..dc48a25f1756 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -85,16 +85,25 @@ static bool suspend_device_irq(struct irq_desc *desc)
}
desc->istate |= IRQS_SUSPENDED;
- __disable_irq(desc);
-
/*
-* Hardware which has no wakeup source configuration facility
-* requires that the non wakeup interrupts are masked at the
-* chip level. The chip implementation indicates that with
-* IRQCHIP_MASK_ON_SUSPEND.
+* Some irq chips (e.g. XEN PIRQ) require a full shutdown on suspend
+* as some of the legacy drivers(e.g. floppy) do nothing during the
+* suspend path
*/
- if (irq_desc_get_chip(desc)->flags & IRQCHIP_MASK_ON_SUSPEND)
- mask_irq(desc);
+ if (irq_desc_get_chip(desc)->flags & IRQCHIP_SHUTDOWN_ON_SUSPEND) {
+ irq_shutdown(desc);
+ } else {
+ __disable_irq(desc);
+
+ /*
+ * Hardware which has no wakeup source configuration facility
+ * requires that the non wakeup interrupts are masked at the
+ * chip level. The chip implementation indicates that with
+ * IRQCHIP_MASK_ON_SUSPEND.
+ */
+ if (irq_desc_get_chip(desc)->flags & IRQCHIP_MASK_ON_SUSPEND)
+ mask_irq(desc);
+ }
return true;
}
@@ -152,7 +161,11 @@ static void resume_irq(struct irq_desc *desc)
[Xen-devel] [RFC PATCH v3 08/12] xen/time: introduce xen_{save, restore}_steal_clock
From: Munehisa Kamata
Currently, steal time accounting code in scheduler expects steal clock
callback to provide monotonically increasing value. If the accounting
code receives a smaller value than previous one, it uses a negative
value to calculate steal time and results in incorrectly updated idle
and steal time accounting. This breaks userspace tools which read
/proc/stat.
top - 08:05:35 up 2:12, 3 users, load average: 0.00, 0.07, 0.23
Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,30100.0%id, 0.0%wa, 0.0%hi,
0.0%si,-1253874204672.0%st
This can actually happen when a Xen PVHVM guest gets restored from
hibernation, because such a restored guest is just a fresh domain from
Xen perspective and the time information in runstate info starts over
from scratch.
This patch introduces xen_save_steal_clock() which saves current values
in runstate info into per-cpu variables. Its couterpart,
xen_restore_steal_clock(), sets offset if it found the current values in
runstate info are smaller than previous ones. xen_steal_clock() is also
modified to use the offset to ensure that scheduler only sees
monotonically increasing number.
Signed-off-by: Munehisa Kamata
Signed-off-by: Anchal Agarwal
---
drivers/xen/time.c| 29 -
include/xen/xen-ops.h | 2 ++
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 0968859c29d0..3560222cc0dd 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -23,6 +23,9 @@ static DEFINE_PER_CPU(struct vcpu_runstate_info,
xen_runstate);
static DEFINE_PER_CPU(u64[4], old_runstate_time);
+static DEFINE_PER_CPU(u64, xen_prev_steal_clock);
+static DEFINE_PER_CPU(u64, xen_steal_clock_offset);
+
/* return an consistent snapshot of 64-bit time/counter value */
static u64 get64(const u64 *p)
{
@@ -149,7 +152,7 @@ bool xen_vcpu_stolen(int vcpu)
return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
}
-u64 xen_steal_clock(int cpu)
+static u64 __xen_steal_clock(int cpu)
{
struct vcpu_runstate_info state;
@@ -157,6 +160,30 @@ u64 xen_steal_clock(int cpu)
return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
}
+u64 xen_steal_clock(int cpu)
+{
+ return __xen_steal_clock(cpu) + per_cpu(xen_steal_clock_offset, cpu);
+}
+
+void xen_save_steal_clock(int cpu)
+{
+ per_cpu(xen_prev_steal_clock, cpu) = xen_steal_clock(cpu);
+}
+
+void xen_restore_steal_clock(int cpu)
+{
+ u64 steal_clock = __xen_steal_clock(cpu);
+
+ if (per_cpu(xen_prev_steal_clock, cpu) > steal_clock) {
+ /* Need to update the offset */
+ per_cpu(xen_steal_clock_offset, cpu) =
+ per_cpu(xen_prev_steal_clock, cpu) - steal_clock;
+ } else {
+ /* Avoid unnecessary steal clock warp */
+ per_cpu(xen_steal_clock_offset, cpu) = 0;
+ }
+}
+
void xen_setup_runstate_info(int cpu)
{
struct vcpu_register_runstate_memory_area area;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 3b3992b5b0c2..12b3f4474a05 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -37,6 +37,8 @@ void xen_time_setup_guest(void);
void xen_manage_runstate_time(int action);
void xen_get_runstate_snapshot(struct vcpu_runstate_info *res);
u64 xen_steal_clock(int cpu);
+void xen_save_steal_clock(int cpu);
+void xen_restore_steal_clock(int cpu);
int xen_setup_shutdown_event(void);
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Munehisa Kamata
Signed-off-by: Munehisa Kamata
---
drivers/block/xen-blkfront.c | 119 ---
1 file changed, 112 insertions(+), 7 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 478120233750..d715ed3cb69a 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -47,6 +47,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -79,6 +81,8 @@ enum blkif_state {
BLKIF_STATE_DISCONNECTED,
BLKIF_STATE_CONNECTED,
BLKIF_STATE_SUSPENDED,
+ BLKIF_STATE_FREEZING,
+ BLKIF_STATE_FROZEN
};
struct grant {
@@ -220,6 +224,7 @@ struct blkfront_info
struct list_head requests;
struct bio_list bio_list;
struct list_head info_list;
+ struct completion wait_backend_disconnected;
};
static unsigned int nr_minors;
@@ -261,6 +266,7 @@ static DEFINE_SPINLOCK(minor_lock);
static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo);
static void blkfront_gather_backend_features(struct blkfront_info *info);
static int negotiate_mq(struct blkfront_info *info);
+static void __blkif_free(struct blkfront_info *info);
static int get_id_from_freelist(struct blkfront_ring_info *rinfo)
{
@@ -995,6 +1001,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16
sector_size,
info->sector_size = sector_size;
info->physical_sector_size = physical_sector_size;
blkif_set_queue_limits(info);
+ init_completion(>wait_backend_disconnected);
return 0;
}
@@ -1218,6 +1225,8 @@ static void xlvbd_release_gendisk(struct blkfront_info
*info)
/* Already hold rinfo->ring_lock. */
static inline void kick_pending_request_queues_locked(struct
blkfront_ring_info *rinfo)
{
+ if (unlikely(rinfo->dev_info->connected == BLKIF_STATE_FREEZING))
+ return;
if (!RING_FULL(>ring))
blk_mq_start_stopped_hw_queues(rinfo->dev_info->rq, true);
}
@@ -1341,8 +1350,6 @@ static void blkif_free_ring(struct blkfront_ring_info
*rinfo)
static void blkif_free(struct blkfront_info *info, int suspend)
{
- unsigned int i;
-
/* Prevent new requests being issued until we fix things up. */
info->connected = suspend ?
BLKIF_STATE_SUSPENDED : BLKIF_STATE_DISCONNECTED;
@@ -1350,6 +1357,13 @@ static void blkif_free(struct blkfront_info *info, int
suspend)
if (info->rq)
blk_mq_stop_hw_queues(info->rq);
+ __blkif_free(info);
+}
+
+static void __blkif_free(struct blkfront_info *info)
+{
+ unsigned int i;
+
for (i = 0; i < info->nr_rings; i++)
blkif_free_ring(>rinfo[i]);
@@ -1553,8 +1567,10 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
struct blkfront_ring_info *rinfo = (struct blkfront_ring_info *)dev_id;
struct blkfront_info *info = rinfo->dev_info;
- if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
- return IRQ_HANDLED;
+ if (unlikely(info->connected != BLKIF_STATE_CONNECTED)) {
+ if (info->connected != BLKIF_STATE_FREEZING)
+ return IRQ_HANDLED;
+ }
spin_lock_irqsave(>ring_lock, flags);
again:
@@ -2020,6 +2036,7 @@ static int blkif_recover(struct blkfront_info *info)
struct bio *bio;
unsigned int segs;
+ bool frozen = info->connected == BLKIF_STATE_FROZEN;
blkfront_gather_backend_features(info);
/* Reset limits changed by blk_mq_update_nr_hw_queues(). */
blkif_set_queue_limits(info);
@@ -2046,6 +2063,9 @@ static int blkif_recover(struct blkfront_info *info)
kick_pending_request_queues(rinfo);
}
+ if (frozen)
+ return 0;
+
list_for_each_entry_safe(req, n, >requests, queuelist) {
/* Requeue pending requests (flush or discard) */
list_del_init(>queuelist);
@@ -2359,6 +2379,7 @@ static void blkfront_connect(struct blkfront_info *info)
return;
case BLKIF_STATE_SUSPENDED:
+ case BLKIF_STATE_FROZEN:
/*
* If we are recovering from suspension, we need to wait
* for the backend to announce it's features before
@@ -2476,12 +2497,37 @@ static void blkback_changed(struct xenbus_device *dev,
break;
case XenbusStateClosed:
- if (dev->state == XenbusStateClosed)
+ if (dev->state == XenbusStateClosed) {
+ if (info->connected == BLKIF_STATE_FREEZING) {
+ __blkif_free(info);
+ info->connected = BLKIF_STATE_FROZEN;
+ complete(>wait_backend_disconnected);
+ break;
+ }
+
break;
+ }
+
+ /*
+
[Xen-devel] [RFC PATCH v3 05/12] xen-netfront: add callbacks for PM suspend and hibernation support
From: Munehisa Kamata
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. The freeze handler simply disconnects the frotnend from the
backend and frees resources associated with queues after disabling the
net_device from the system. The restore handler just changes the
frontend state and let the xenbus handler to re-allocate the resources
and re-connect to the backend. This can be performed transparently to
the rest of the system. The handlers are used for both PM suspend and
hibernation so that we can keep the existing suspend/resume callbacks
for Xen suspend without modification. Freezing netfront devices is
normally expected to finish within a few hundred milliseconds, but it
can rarely take more than 5 seconds and hit the hard coded timeout,
it would depend on backend state which may be congested and/or have
complex configuration. While it's rare case, longer default timeout
seems a bit more reasonable here to avoid hitting the timeout.
Also, make it configurable via module parameter so that we can cover
broader setups than what we know currently.
[Anchal changelog: Variable name fix and checkpatch.pl fixes]
Signed-off-by: Anchal Agarwal
Signed-off-by: Munehisa Kamata
---
drivers/net/xen-netfront.c | 98 +-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 482c6c8b0fb7..65edcdd6e05f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -56,6 +57,12 @@
#include
#include
+enum netif_freeze_state {
+ NETIF_FREEZE_STATE_UNFROZEN,
+ NETIF_FREEZE_STATE_FREEZING,
+ NETIF_FREEZE_STATE_FROZEN,
+};
+
/* Module parameters */
#define MAX_QUEUES_DEFAULT 8
static unsigned int xennet_max_queues;
@@ -63,6 +70,12 @@ module_param_named(max_queues, xennet_max_queues, uint,
0644);
MODULE_PARM_DESC(max_queues,
"Maximum number of queues per virtual interface");
+static unsigned int netfront_freeze_timeout_secs = 10;
+module_param_named(freeze_timeout_secs,
+ netfront_freeze_timeout_secs, uint, 0644);
+MODULE_PARM_DESC(freeze_timeout_secs,
+"timeout when freezing netfront device in seconds");
+
static const struct ethtool_ops xennet_ethtool_ops;
struct netfront_cb {
@@ -160,6 +173,10 @@ struct netfront_info {
struct netfront_stats __percpu *tx_stats;
atomic_t rx_gso_checksum_fixup;
+
+ int freeze_state;
+
+ struct completion wait_backend_disconnected;
};
struct netfront_rx_info {
@@ -721,6 +738,21 @@ static int xennet_close(struct net_device *dev)
return 0;
}
+static int xennet_disable_interrupts(struct net_device *dev)
+{
+ struct netfront_info *np = netdev_priv(dev);
+ unsigned int num_queues = dev->real_num_tx_queues;
+ unsigned int queue_index;
+ struct netfront_queue *queue;
+
+ for (queue_index = 0; queue_index < num_queues; ++queue_index) {
+ queue = >queues[queue_index];
+ disable_irq(queue->tx_irq);
+ disable_irq(queue->rx_irq);
+ }
+ return 0;
+}
+
static void xennet_move_rx_slot(struct netfront_queue *queue, struct sk_buff
*skb,
grant_ref_t ref)
{
@@ -1301,6 +1333,8 @@ static struct net_device *xennet_create_dev(struct
xenbus_device *dev)
np->queues = NULL;
+ init_completion(>wait_backend_disconnected);
+
err = -ENOMEM;
np->rx_stats = netdev_alloc_pcpu_stats(struct netfront_stats);
if (np->rx_stats == NULL)
@@ -1794,6 +1828,50 @@ static int xennet_create_queues(struct netfront_info
*info,
return 0;
}
+static int netfront_freeze(struct xenbus_device *dev)
+{
+ struct netfront_info *info = dev_get_drvdata(>dev);
+ unsigned long timeout = netfront_freeze_timeout_secs * HZ;
+ int err = 0;
+
+ xennet_disable_interrupts(info->netdev);
+
+ netif_device_detach(info->netdev);
+
+ info->freeze_state = NETIF_FREEZE_STATE_FREEZING;
+
+ /* Kick the backend to disconnect */
+ xenbus_switch_state(dev, XenbusStateClosing);
+
+ /* We don't want to move forward before the frontend is diconnected
+* from the backend cleanly.
+*/
+ timeout = wait_for_completion_timeout(>wait_backend_disconnected,
+ timeout);
+ if (!timeout) {
+ err = -EBUSY;
+ xenbus_dev_error(dev, err, "Freezing timed out;"
+"the device may become inconsistent state");
+ return err;
+ }
+
+ /* Tear down queues */
+ xennet_disconnect_backend(info);
+ xennet_destroy_queues(info);
+
+ info->freeze_state = NETIF_FREEZE_STATE_FROZEN;
+
+ return err;
+}
+
+static int netfront_restore(struct
[Xen-devel] [RFC PATCH v3 04/12] x86/xen: add system core suspend and resume callbacks
From: Munehisa Kamata
Add Xen PVHVM specific system core callbacks for PM suspend and
hibernation support. The callbacks suspend and resume Xen
primitives,like shared_info, pvclock and grant table. Note that
Xen suspend can handle them in a different manner, but system
core callbacks are called from the context. So if the callbacks
are called from Xen suspend context, return immediately.
Signed-off-by: Agarwal Anchal
Signed-off-by: Munehisa Kamata
---
arch/x86/xen/enlighten_hvm.c | 1 +
arch/x86/xen/suspend.c | 53
include/xen/xen-ops.h| 3 ++
3 files changed, 57 insertions(+)
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 75b1ec7a0fcd..138e71786e03 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -204,6 +204,7 @@ static void __init xen_hvm_guest_init(void)
if (xen_feature(XENFEAT_hvm_callback_vector))
xen_have_vector_callback = 1;
+ xen_setup_syscore_ops();
xen_hvm_smp_init();
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_hvm, xen_cpu_dead_hvm));
xen_unplug_emulated_devices();
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 1d83152c761b..784c4484100b 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -2,17 +2,22 @@
#include
#include
#include
+#include
+#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include "xen-ops.h"
#include "mmu.h"
@@ -82,3 +87,51 @@ void xen_arch_suspend(void)
on_each_cpu(xen_vcpu_notify_suspend, NULL, 1);
}
+
+static int xen_syscore_suspend(void)
+{
+ struct xen_remove_from_physmap xrfp;
+ int ret;
+
+ /* Xen suspend does similar stuffs in its own logic */
+ if (xen_suspend_mode_is_xen_suspend())
+ return 0;
+
+ xrfp.domid = DOMID_SELF;
+ xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
+
+ ret = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, );
+ if (!ret)
+ HYPERVISOR_shared_info = _dummy_shared_info;
+
+ return ret;
+}
+
+static void xen_syscore_resume(void)
+{
+ /* Xen suspend does similar stuffs in its own logic */
+ if (xen_suspend_mode_is_xen_suspend())
+ return;
+
+ /* No need to setup vcpu_info as it's already moved off */
+ xen_hvm_map_shared_info();
+
+ pvclock_resume();
+
+ gnttab_resume();
+}
+
+/*
+ * These callbacks will be called with interrupts disabled and when having only
+ * one CPU online.
+ */
+static struct syscore_ops xen_hvm_syscore_ops = {
+ .suspend = xen_syscore_suspend,
+ .resume = xen_syscore_resume
+};
+
+void __init xen_setup_syscore_ops(void)
+{
+ if (xen_hvm_domain())
+ register_syscore_ops(_hvm_syscore_ops);
+}
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6c36e161dfd1..3b3992b5b0c2 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -43,6 +43,9 @@ int xen_setup_shutdown_event(void);
bool xen_suspend_mode_is_xen_suspend(void);
bool xen_suspend_mode_is_pm_suspend(void);
bool xen_suspend_mode_is_pm_hibernation(void);
+
+void xen_setup_syscore_ops(void);
+
extern unsigned long *xen_contiguous_bitmap;
#if defined(CONFIG_XEN_PV) || defined(CONFIG_ARM) || defined(CONFIG_ARM64)
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 03/12] x86/xen: Introduce new function to map HYPERVISOR_shared_info on Resume
Introduce a small function which re-uses shared page's PA allocated
during guest initialization time in reserve_shared_info() and not
allocate new page during resume flow.
It also does the mapping of shared_info_page by calling
xen_hvm_init_shared_info() to use the function.
Signed-off-by: Anchal Agarwal
---
arch/x86/xen/enlighten_hvm.c | 7 +++
arch/x86/xen/xen-ops.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index e138f7de52d2..75b1ec7a0fcd 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -27,6 +27,13 @@
static unsigned long shared_info_pfn;
+void xen_hvm_map_shared_info(void)
+{
+ xen_hvm_init_shared_info();
+ if (shared_info_pfn)
+ HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
+}
+
void xen_hvm_init_shared_info(void)
{
struct xen_add_to_physmap xatp;
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 45a441c33d6d..d84c357994bd 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -56,6 +56,7 @@ void xen_enable_syscall(void);
void xen_vcpu_restore(void);
void xen_callback_vector(void);
+void xen_hvm_map_shared_info(void);
void xen_hvm_init_shared_info(void);
void xen_unplug_emulated_devices(void);
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 02/12] xenbus: add freeze/thaw/restore callbacks support
From: Munehisa Kamata
Since commit b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for
suspend/resume/chkpt"), xenbus uses PMSG_FREEZE, PMSG_THAW and
PMSG_RESTORE events for Xen suspend. However, they're actually assigned
to xenbus_dev_suspend(), xenbus_dev_cancel() and xenbus_dev_resume()
respectively, and only suspend and resume callbacks are supported at
driver level. To support PM suspend and PM hibernation, modify the bus
level PM callbacks to invoke not only device driver's suspend/resume but
also freeze/thaw/restore.
Note that we'll use freeze/restore callbacks even for PM suspend whereas
suspend/resume callbacks are normally used in the case, becausae the
existing xenbus device drivers already have suspend/resume callbacks
specifically designed for Xen suspend. So we can allow the device
drivers to keep the existing callbacks wihtout modification.
[Anchal Changelog: Refactored the callbacks code]
Signed-off-by: Agarwal Anchal
Signed-off-by: Munehisa Kamata
---
drivers/xen/xenbus/xenbus_probe.c | 99 +--
include/xen/xenbus.h | 3 +
2 files changed, 84 insertions(+), 18 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 5b471889d723..0fa868c2 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
@@ -597,27 +598,44 @@ int xenbus_dev_suspend(struct device *dev)
struct xenbus_driver *drv;
struct xenbus_device *xdev
= container_of(dev, struct xenbus_device, dev);
-
+ bool xen_suspend = xen_suspend_mode_is_xen_suspend();
DPRINTK("%s", xdev->nodename);
if (dev->driver == NULL)
return 0;
drv = to_xenbus_driver(dev->driver);
- if (drv->suspend)
- err = drv->suspend(xdev);
- if (err)
- pr_warn("suspend %s failed: %i\n", dev_name(dev), err);
+
+ if (xen_suspend) {
+ if (drv->suspend)
+ err = drv->suspend(xdev);
+ } else {
+ if (drv->freeze) {
+ err = drv->freeze(xdev);
+ if (!err) {
+ free_otherend_watch(xdev);
+ free_otherend_details(xdev);
+ return 0;
+ }
+ }
+ }
+
+ if (err) {
+ pr_warn("%s %s failed: %i\n", xen_suspend ?
+ "suspend" : "freeze", dev_name(dev), err);
+ return err;
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(xenbus_dev_suspend);
int xenbus_dev_resume(struct device *dev)
{
- int err;
+ int err = 0;
struct xenbus_driver *drv;
struct xenbus_device *xdev
= container_of(dev, struct xenbus_device, dev);
-
+ bool xen_suspend = xen_suspend_mode_is_xen_suspend();
DPRINTK("%s", xdev->nodename);
if (dev->driver == NULL)
@@ -625,24 +643,32 @@ int xenbus_dev_resume(struct device *dev)
drv = to_xenbus_driver(dev->driver);
err = talk_to_otherend(xdev);
if (err) {
- pr_warn("resume (talk_to_otherend) %s failed: %i\n",
+ pr_warn("%s (talk_to_otherend) %s failed: %i\n",
+ xen_suspend ? "resume" : "restore",
dev_name(dev), err);
return err;
}
- xdev->state = XenbusStateInitialising;
+ if (xen_suspend) {
+ xdev->state = XenbusStateInitialising;
+ if (drv->resume)
+ err = drv->resume(xdev);
+ } else {
+ if (drv->restore)
+ err = drv->restore(xdev);
+ }
- if (drv->resume) {
- err = drv->resume(xdev);
- if (err) {
- pr_warn("resume %s failed: %i\n", dev_name(dev), err);
- return err;
- }
+ if (err) {
+ pr_warn("%s %s failed: %i\n",
+ xen_suspend ? "resume" : "restore",
+ dev_name(dev), err);
+ return err;
}
err = watch_otherend(xdev);
if (err) {
- pr_warn("resume (watch_otherend) %s failed: %d.\n",
+ pr_warn("%s (watch_otherend) %s failed: %d.\n",
+ xen_suspend ? "resume" : "restore",
dev_name(dev), err);
return err;
}
@@ -653,8 +679,45 @@ EXPORT_SYMBOL_GPL(xenbus_dev_resume);
int xenbus_dev_cancel(struct device *dev)
{
- /* Do nothing */
- DPRINTK("cancel");
+ int err = 0;
+ struct xenbus_driver *drv;
+ struct xenbus_device *xdev
+ = container_of(dev, struct xenbus_device, dev);
+ bool xen_suspend =
[Xen-devel] [RFC PATCH v3 01/12] xen/manage: keep track of the on-going suspend mode
From: Munehisa Kamata
Guest hibernation is different from xen suspend/resume/live migration.
Xen save/restore does not use pm_ops as is needed by guest hibernation.
Hibernation in guest follows ACPI path and is guest inititated , the
hibernation image is saved within guest as compared to later modes
which are xen toolstack assisted and image creation/storage is in
control of hypervisor/host machine.
To differentiate between Xen suspend and PM hibernation, keep track
of the on-going suspend mode by mainly using a new PM notifier.
Introduce simple functions which help to know the on-going suspend mode
so that other Xen-related code can behave differently according to the
current suspend mode.
Since Xen suspend doesn't have corresponding PM event, its main logic
is modfied to acquire pm_mutex and set the current mode.
Though, acquirng pm_mutex is still right thing to do, we may
see deadlock if PM hibernation is interrupted by Xen suspend.
PM hibernation depends on xenwatch thread to process xenbus state
transactions, but the thread will sleep to wait pm_mutex which is
already held by PM hibernation context in the scenario. Xen shutdown
code may need some changes to avoid the issue.
[Anchal Changelog: Merged patch xen/manage: introduce helper function
to know the on-going suspend mode into this one for better readability]
Signed-off-by: Anchal Agarwal
Signed-off-by: Munehisa Kamata
---
drivers/xen/manage.c | 73 +++
include/xen/xen-ops.h | 3 ++
2 files changed, 76 insertions(+)
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index cd046684e0d1..0b30ab522b77 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,6 +41,31 @@ enum shutdown_state {
/* Ignore multiple shutdown requests. */
static enum shutdown_state shutting_down = SHUTDOWN_INVALID;
+enum suspend_modes {
+ NO_SUSPEND = 0,
+ XEN_SUSPEND,
+ PM_SUSPEND,
+ PM_HIBERNATION,
+};
+
+/* Protected by pm_mutex */
+static enum suspend_modes suspend_mode = NO_SUSPEND;
+
+bool xen_suspend_mode_is_xen_suspend(void)
+{
+ return suspend_mode == XEN_SUSPEND;
+}
+
+bool xen_suspend_mode_is_pm_suspend(void)
+{
+ return suspend_mode == PM_SUSPEND;
+}
+
+bool xen_suspend_mode_is_pm_hibernation(void)
+{
+ return suspend_mode == PM_HIBERNATION;
+}
+
struct suspend_info {
int cancelled;
};
@@ -99,6 +125,10 @@ static void do_suspend(void)
int err;
struct suspend_info si;
+ lock_system_sleep();
+
+ suspend_mode = XEN_SUSPEND;
+
shutting_down = SHUTDOWN_SUSPEND;
err = freeze_processes();
@@ -162,6 +192,10 @@ static void do_suspend(void)
thaw_processes();
out:
shutting_down = SHUTDOWN_INVALID;
+
+ suspend_mode = NO_SUSPEND;
+
+ unlock_system_sleep();
}
#endif /* CONFIG_HIBERNATE_CALLBACKS */
@@ -387,3 +421,42 @@ int xen_setup_shutdown_event(void)
EXPORT_SYMBOL_GPL(xen_setup_shutdown_event);
subsys_initcall(xen_setup_shutdown_event);
+
+static int xen_pm_notifier(struct notifier_block *notifier,
+ unsigned long pm_event, void *unused)
+{
+ switch (pm_event) {
+ case PM_SUSPEND_PREPARE:
+ suspend_mode = PM_SUSPEND;
+ break;
+ case PM_HIBERNATION_PREPARE:
+ case PM_RESTORE_PREPARE:
+ suspend_mode = PM_HIBERNATION;
+ break;
+ case PM_POST_SUSPEND:
+ case PM_POST_RESTORE:
+ case PM_POST_HIBERNATION:
+ /* Set back to the default */
+ suspend_mode = NO_SUSPEND;
+ break;
+ default:
+ pr_warn("Receive unknown PM event 0x%lx\n", pm_event);
+ return -EINVAL;
+ }
+
+ return 0;
+};
+
+static struct notifier_block xen_pm_notifier_block = {
+ .notifier_call = xen_pm_notifier
+};
+
+static int xen_setup_pm_notifier(void)
+{
+ if (!xen_hvm_domain())
+ return -ENODEV;
+
+ return register_pm_notifier(_pm_notifier_block);
+}
+
+subsys_initcall(xen_setup_pm_notifier);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index d89969aa9942..6c36e161dfd1 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -40,6 +40,9 @@ u64 xen_steal_clock(int cpu);
int xen_setup_shutdown_event(void);
+bool xen_suspend_mode_is_xen_suspend(void);
+bool xen_suspend_mode_is_pm_suspend(void);
+bool xen_suspend_mode_is_pm_hibernation(void);
extern unsigned long *xen_contiguous_bitmap;
#if defined(CONFIG_XEN_PV) || defined(CONFIG_ARM) || defined(CONFIG_ARM64)
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC RESEND PATCH v3 00/12] Enable PM hibernation on guest VMs
Resending this in a more threaded format.
Hello,
I am sending out a v3 version of series of patches that implements guest
PM hibernation.
These guests are running on xen hypervisor. The patches had been tested
against mainstream kernel. EC2 instance hibernation feature is provided
to the AWS EC2 customers. PM hibernation uses swap space carved out within
the guest[or can be a separate partition], where hibernation image is
stored and restored from.
Doing guest hibernation does not involve any support from hypervisor and
this way guest has complete control over its state. Infrastructure
restrictions for saving up guest state can be overcome by guest initiated
hibernation.
This series includes some improvements over RFC series sent last year:
https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg00823.html
Changelog v3:
1. Feedback from V2
2. Introduced 2 new patches for xen sched clock offset fix
3. Fixed pirq shutdown/restore in generic irq subsystem
4. Split save/restore steal clock patches into 2 for better readability
Changelog v2:
1. Removed timeout/request present on the ring in xen-blkfront during blkfront
freeze
2. Fixed restoring of PIRQs which was apparently working for 4.9 kernels but
not for
newer kernel. [Legacy irqs were no longer restored after hibernation introduced
with
this commit "020db9d3c1dc0"]
3. Merged couple of related patches to make the code more coherent and readable
4. Code refactoring
5. Sched clock fix when hibernating guest is under heavy CPU load
Note: Under very rare circumstances we see resume failures with KASLR enabled
only
on xen instances. We are roughly seeing 3% failures [>1000 runs] when testing
with
various instance sizes and some workload running on each instance. I am
currently
investigating the issue as to confirm if its a xen issue or kernel issue.
However, it should not hold back anyone from reviewing/accepting these patches.
Testing done:
All testing is done for multiple hibernation cycle for 5.4 kernel on EC2.
Testing How to:
---
Example:
Set up a file-backed swap space. Swap file size>=Total memory on the system
sudo dd if=/dev/zero of=/swap bs=$(( 1024 * 1024 )) count=4096 # 4096MiB
sudo chmod 600 /swap
sudo mkswap /swap
sudo swapon /swap
Update resume device/resume offset in grub if using swap file:
resume=/dev/xvda1 resume_offset=200704
Execute:
sudo pm-hibernate
OR
echo disk > /sys/power/state && echo reboot > /sys/power/disk
Compute resume offset code:
"
#!/usr/bin/env python
import sys
import array
import fcntl
#swap file
f = open(sys.argv[1], 'r')
buf = array.array('L', [0])
#FIBMAP
ret = fcntl.ioctl(f.fileno(), 0x01, buf)
print buf[0]
"
Aleksei Besogonov (1):
PM / hibernate: update the resume offset on SNAPSHOT_SET_SWAP_AREA
Anchal Agarwal (4):
x86/xen: Introduce new function to map HYPERVISOR_shared_info on
Resume
genirq: Shutdown irq chips in suspend/resume during hibernation
xen: Introduce wrapper for save/restore sched clock offset
xen: Update sched clock offset to avoid system instability in
hibernation
Munehisa Kamata (7):
xen/manage: keep track of the on-going suspend mode
xenbus: add freeze/thaw/restore callbacks support
x86/xen: add system core suspend and resume callbacks
xen-netfront: add callbacks for PM suspend and hibernation support
xen-blkfront: add callbacks for PM suspend and hibernation
xen/time: introduce xen_{save,restore}_steal_clock
x86/xen: save and restore steal clock
arch/x86/xen/enlighten_hvm.c | 8 ++
arch/x86/xen/suspend.c| 72 ++
arch/x86/xen/time.c | 18 -
arch/x86/xen/xen-ops.h| 3 +
drivers/block/xen-blkfront.c | 119 --
drivers/net/xen-netfront.c| 98 +++-
drivers/xen/events/events_base.c | 1 +
drivers/xen/manage.c | 73 ++
drivers/xen/time.c| 29 +++-
drivers/xen/xenbus/xenbus_probe.c | 99 -
include/linux/irq.h | 2 +
include/xen/xen-ops.h | 8 ++
include/xen/xenbus.h | 3 +
kernel/irq/chip.c | 2 +-
kernel/irq/internals.h| 1 +
kernel/irq/pm.c | 31 +---
kernel/power/user.c | 6 +-
17 files changed, 533 insertions(+), 40 deletions(-)
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 147063: tolerable all pass - PUSHED
flight 147063 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/147063/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 707db77a380b96025bae8bc4322da0b64819d3b7 baseline version: xen ea3daabff5f2be6f5dd5c3f4d6890746c4ec5378 Last test of basis 147057 2020-02-14 18:01:04 Z0 days Testing same since 147063 2020-02-14 21:10:52 Z0 days1 attempts People who touched revisions under test: Andrew Cooper David Woodhouse Igor Druzhinin Jan Beulich jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git ea3daabff5..707db77a38 707db77a380b96025bae8bc4322da0b64819d3b7 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 14/30] x86/xen: Add missing annotation for xen_pte_lock()
On 2/14/20 3:47 PM, Jules Irenge wrote: > Sparse reports warning at xen_pte_lock() > > warning: context imbalance in xen_pte_lock() - wrong count at exit > > The root cause is the missing annotation at xen_pte_lock() > Add the missing __acquires(ptl) annotation > > Signed-off-by: Jules Irenge Reviewed-by: Boris Ostrovsky although I'd prefer this and the next patch to be merged into a single one. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 147057: tolerable all pass - PUSHED
flight 147057 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/147057/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen ea3daabff5f2be6f5dd5c3f4d6890746c4ec5378 baseline version: xen ad1d3db985249c64d65d8f73a4c49e2204ddf4e1 Last test of basis 147052 2020-02-14 14:00:43 Z0 days Testing same since 147057 2020-02-14 18:01:04 Z0 days1 attempts People who touched revisions under test: George Dunlap Julien Grall Paul Durrant Tim Deegan jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git ad1d3db985..ea3daabff5 ea3daabff5f2be6f5dd5c3f4d6890746c4ec5378 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 14/30] x86/xen: Add missing annotation for xen_pte_lock()
Sparse reports warning at xen_pte_lock()
warning: context imbalance in xen_pte_lock() - wrong count at exit
The root cause is the missing annotation at xen_pte_lock()
Add the missing __acquires(ptl) annotation
Signed-off-by: Jules Irenge
---
arch/x86/xen/mmu_pv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index bbba8b17829a..352f0c80cfcf 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -695,6 +695,7 @@ static int xen_pgd_walk(struct mm_struct *mm,
/* If we're using split pte locks, then take the page's lock and
return a pointer to it. Otherwise return NULL. */
static spinlock_t *xen_pte_lock(struct page *page, struct mm_struct *mm)
+ __acquires(ptl)
{
spinlock_t *ptl = NULL;
--
2.24.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 15/30] x86/xen: Add missing annotation for xen_pte_unlock()
Sparse reports warning at xen_pte_unlock()
warning: context imbalance in xen_pte_unlock() - unexpected unlock
The root cause is the missing annotation at xen_pte_unlock()
Add the missing __releases(ptl) annotation
Signed-off-by: Jules Irenge
---
arch/x86/xen/mmu_pv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 352f0c80cfcf..777008f8c668 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -707,7 +707,7 @@ static spinlock_t *xen_pte_lock(struct page *page, struct
mm_struct *mm)
return ptl;
}
-static void xen_pte_unlock(void *v)
+static void xen_pte_unlock(void *v) __releases(ptl)
{
spinlock_t *ptl = v;
spin_unlock(ptl);
--
2.24.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/msr: Virtualise MSR_PLATFORM_ID properly
This is an Intel-only, read-only MSR related to microcode loading. Expose it
in similar circumstances as the PATCHLEVEL MSR.
This should have been alongside c/s 013896cb8b2 "x86/msr: Fix handling of
MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV"
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
Turns out I wrote this nearly a year ago and didn't send it. It obviously got
dropped in the leadup to MDS.
---
xen/arch/x86/msr.c | 8
1 file changed, 8 insertions(+)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 785574de67..1cea777680 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -143,6 +143,13 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
*val)
/* Not offered to guests. */
goto gp_fault;
+case MSR_IA32_PLATFORM_ID:
+if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ||
+ !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) )
+goto gp_fault;
+rdmsrl(MSR_IA32_PLATFORM_ID, *val);
+break;
+
case MSR_AMD_PATCHLEVEL:
BUILD_BUG_ON(MSR_IA32_UCODE_REV != MSR_AMD_PATCHLEVEL);
/*
@@ -275,6 +282,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
{
uint64_t rsvd;
+case MSR_IA32_PLATFORM_ID:
case MSR_INTEL_CORE_THREAD_COUNT:
case MSR_INTEL_PLATFORM_INFO:
case MSR_ARCH_CAPABILITIES:
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-5.4 test] 147001: regressions - FAIL
flight 147001 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/147001/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 146121 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linuxd6591ea2dd1a44b1c72c5a3e3b6555d7585acdae baseline version: linux122179cb7d648a6f36b20dd6bf34f953cb384c30 Last test of basis 146121 2020-01-15 17:42:04 Z 30 days Failing
[Xen-devel] [PATCH] AMD/IOMMU: Common the #732/#733 errata handling in iommu_read_log()
There is no need to have both helpers implement the same workaround. The size
and layout of the the Event and PPR logs (and others for that matter) share a
lot of commonality.
Use MASK_EXTR() to locate the code field, and use ACCESS_ONCE() rather than
barrier() to prevent hoisting of the repeated read.
Avoid unnecessary zeroing by only clobbering the 'code' field - this alone is
sufficient to spot the errata when the rings wrap.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/drivers/passthrough/amd/iommu_init.c | 80
1 file changed, 29 insertions(+), 51 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_init.c
b/xen/drivers/passthrough/amd/iommu_init.c
index c42b608f07..5de5315d8b 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -300,7 +300,7 @@ static int iommu_read_log(struct amd_iommu *iommu,
unsigned int entry_size,
void (*parse_func)(struct amd_iommu *, u32 *))
{
-u32 tail, *entry, tail_offest, head_offset;
+unsigned int tail, tail_offest, head_offset;
BUG_ON(!iommu || ((log != >event_log) && (log != >ppr_log)));
@@ -319,11 +319,36 @@ static int iommu_read_log(struct amd_iommu *iommu,
while ( tail != log->head )
{
-/* read event log entry */
-entry = log->buffer + log->head;
+uint32_t *entry = log->buffer + log->head;
+unsigned int count = 0;
+
+/* Event and PPR logs have their code field in the same position. */
+unsigned int code = MASK_EXTR(entry[1], IOMMU_EVENT_CODE_MASK);
+
+/*
+ * Workaround for errata #732, #733:
+ *
+ * It can happen that the tail pointer is updated before the actual
+ * entry got written. As suggested by RevGuide, we initialize the
+ * buffer to all zeros and clear entries after processing them.
+ */
+while ( unlikely(code == 0) )
+{
+if ( unlikely(++count == IOMMU_LOG_ENTRY_TIMEOUT) )
+{
+AMD_IOMMU_DEBUG("AMD-Vi: No entry written to %s Log\n",
+log == >event_log ? "Event" : "PPR");
+return 0;
+}
+udelay(1);
+code = MASK_EXTR(ACCESS_ONCE(entry[1]), IOMMU_EVENT_CODE_MASK);
+}
parse_func(iommu, entry);
+/* Clear 'code' to be able to spot the erratum when the ring wraps. */
+ACCESS_ONCE(entry[1]) = 0;
+
log->head += entry_size;
if ( log->head == log->size )
log->head = 0;
@@ -503,7 +528,6 @@ static hw_irq_controller iommu_x2apic_type = {
static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
{
u32 code;
-int count = 0;
static const char *const event_str[] = {
#define EVENT_STR(name) [IOMMU_EVENT_##name - 1] = #name
EVENT_STR(ILLEGAL_DEV_TABLE_ENTRY),
@@ -521,25 +545,6 @@ static void parse_event_log_entry(struct amd_iommu *iommu,
u32 entry[])
code = get_field_from_reg_u32(entry[1], IOMMU_EVENT_CODE_MASK,
IOMMU_EVENT_CODE_SHIFT);
-/*
- * Workaround for erratum 732:
- * It can happen that the tail pointer is updated before the actual entry
- * got written. As suggested by RevGuide, we initialize the event log
- * buffer to all zeros and clear event log entries after processing them.
- */
-while ( code == 0 )
-{
-if ( unlikely(++count == IOMMU_LOG_ENTRY_TIMEOUT) )
-{
-AMD_IOMMU_DEBUG("AMD-Vi: No event written to log\n");
-return;
-}
-udelay(1);
-barrier(); /* Prevent hoisting of the entry[] read. */
-code = get_field_from_reg_u32(entry[1], IOMMU_EVENT_CODE_MASK,
- IOMMU_EVENT_CODE_SHIFT);
-}
-
/* Look up the symbolic name for code. */
if ( code <= ARRAY_SIZE(event_str) )
code_str = event_str[code - 1];
@@ -575,8 +580,6 @@ static void parse_event_log_entry(struct amd_iommu *iommu,
u32 entry[])
else
printk(XENLOG_ERR "%s %08x %08x %08x %08x\n",
code_str, entry[0], entry[1], entry[2], entry[3]);
-
-memset(entry, 0, IOMMU_EVENT_LOG_ENTRY_SIZE);
}
static void iommu_check_event_log(struct amd_iommu *iommu)
@@ -627,31 +630,8 @@ void parse_ppr_log_entry(struct amd_iommu *iommu, u32
entry[])
{
u16 device_id;
-u8 bus, devfn, code;
+u8 bus, devfn;
struct pci_dev *pdev;
-int count = 0;
-
-code = get_field_from_reg_u32(entry[1], IOMMU_PPR_LOG_CODE_MASK,
- IOMMU_PPR_LOG_CODE_SHIFT);
-
-/*
- * Workaround for erratum 733:
- * It can happen that the tail pointer is updated before the actual entry
- * got written. As suggested by RevGuide, we initialize the event log
- * buffer to all
Re: [Xen-devel] [PATCH] x86/apic: Improve current_local_apic_mode()
On 28/01/2020 14:10, Jan Beulich wrote:
> On 28.01.2020 13:52, Andrew Cooper wrote:
>> boot_cpu_has(X86_FEATURE_X2APIC) doesn't need checking to interpret
>> APIC_BASE_EXTD.
> Hmm, the comment you remove ...
>
>> --- a/xen/arch/x86/apic.c
>> +++ b/xen/arch/x86/apic.c
>> @@ -1534,18 +1534,14 @@ void __init record_boot_APIC_mode(void)
>> /* Look at the bits in MSR_APIC_BASE and work out which APIC mode we are in
>> */
>> enum apic_mode current_local_apic_mode(void)
>> {
>> -u64 msr_contents;
>> +uint32_t high, low;
>>
>> -rdmsrl(MSR_APIC_BASE, msr_contents);
>> +rdmsr(MSR_APIC_BASE, low, high);
>>
>> -/* Reading EXTD bit from the MSR is only valid if CPUID
>> - * says so, else reserved */
> ... states the situation correctly, I think. I guess there's no hardware
> allowing the bit to be set without the feature being there, but a virtual
> or emulated environment could go and set the bit without violating any
> specification, as long as the CPUID bit is clear.
It is unrealistic to expect that some emulated environment supports
preserving of a reserved bit when real hardware uses #GP.
> (Afaict we still allow
> PV guests to see the host MSR_APIC_BASE contents, yet such guests
> wouldn't see the CPUID flag set.
I tried an experiment a few years ago to properly reject access to
MSR_APIC_BASE for PV guests. Suffice it to say that Linux doesn't boot.
This is ultimately a bug in Linux, stemming from broken MSR handling in
Xen, and inappropriate leakage of state which shouldn't ever have been
available to PV guests.
PV guests cannot interact with the LAPIC at all. Their only interrupt
controller is the event channel interface.
> We've had a customer inferring from the
> set bit in the MSR that the other x2APIC [host] MSRs can also be read.
Right, but that is bugs stacked on top of bugs. Its not surprising
there is a cascade set of failures.
Also remember that PV guests get to see the host's x2apic setting,
seemingly for topology reasons. I'm not convinced this is actually a
clever idea, but given that noone has actually fixed guest topology
handling yet, I've also gone out of my way not to make changes in this
area while adjusting other aspects of CPUID handling.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH V2] build: fix configuration of libvirt
Jim Fehlig writes ("[OSSTEST PATCH V2] build: fix configuration of libvirt"):
> libvirt.git commit 2621d48f00 removed the last traces of gnulib, which
> also removed the '--no-git' option from autogen.sh. Unknown options are
> now passed to the configure script, which quickly fails with
>
> configure: error: unrecognized option: `--no-git'
>
> Remove the gnulib handling from ts-libvirt-build, including the '--no-git'
> option to autogen.sh. While at it remove configure options no longer
> supported by the libvirt configure script.
Harmf. Thanks for looking into this and trying to fix this mess.
I think there is a problem with your patch, which is that 2621d48f00
is recent enough that we might want still to be able to build with
earlier versions.
Is there an easy way to tell (by looking at the tree after checkout,
maybe) whether to do the old or the new thing ?
Your perl code looks good to me for what it is trying to do.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: make sure stop_machine_run() is always called in a tasklet
On 14/02/2020 16:39, Jürgen Groß wrote: > On 14.02.20 15:06, Igor Druzhinin wrote: >> On 11/02/2020 09:35, Juergen Gross wrote: >>> With core scheduling active it is mandatory for stop_machine_run() to >>> be called in a tasklet only, as otherwise a scheduling deadlock would >>> occur: stop_machine_run() does a cpu rendezvous by activating a tasklet >>> on all other cpus. In case stop_machine_run() was not called in an idle >>> vcpu it would block scheduling the idle vcpu on its siblings with core >>> scheduling being active, resulting in a hang. >> >> I suppose rcu_barrier() is fine due to process_pending_softirqs() being >> called inside? I'm a little concerned by imposing is_vcpu_idle() restriction >> in that case as rcu_barrier() could be technically called from a non-tasklet >> context. > > No, stop_machine_run() with core scheduling active can only work when > called in an idle vcpu. > > OTOH it would be fairly easy to add another softirq for a similar > purpose and have a sync_machine_run() using that instead of tasklets. > This could be used for ucode loading, too. > > stop_machine_run() and sync_machine_run() could use a common main > function. The patch should be rather simple. > > Thoughts? I have a patch on the list (which I was planning to send a v2 for) that fixes another issue with rcu_barrier(): https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg02273.html As I understand it now that wouldn't work with core-scheduling. Do you think it's possible to synchronously wait for tasklets to finish in non-tasklet context (because that's what the purpose of rcu_barrier() is)? Igor ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 147052: tolerable all pass - PUSHED
flight 147052 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/147052/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen ad1d3db985249c64d65d8f73a4c49e2204ddf4e1 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z3 days Failing since146893 2020-02-11 20:01:02 Z2 days 28 attempts Testing same since 147052 2020-02-14 14:00:43 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 6c47c37b9b..ad1d3db985 ad1d3db985249c64d65d8f73a4c49e2204ddf4e1 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/hyperv: skeleton for L0 assisted TLB flush
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 14 February 2020 13:34
> To: Xen Development List
> Cc: Michael Kelley ; Durrant, Paul
> ; Wei Liu ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
> ; Roger Pau Monné
> Subject: [PATCH v2 2/3] x86/hyperv: skeleton for L0 assisted TLB flush
>
> Implement a basic hook for L0 assisted TLB flush. The hook needs to
> check if prerequisites are met. If they are not met, it returns an error
> number to fall back to native flushes.
>
> Introduce a new variable to indicate if hypercall page is ready.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/guest/hyperv/Makefile | 1 +
> xen/arch/x86/guest/hyperv/hyperv.c | 17
> xen/arch/x86/guest/hyperv/private.h | 4 +++
> xen/arch/x86/guest/hyperv/tlb.c | 41 +
> 4 files changed, 63 insertions(+)
> create mode 100644 xen/arch/x86/guest/hyperv/tlb.c
>
> diff --git a/xen/arch/x86/guest/hyperv/Makefile
> b/xen/arch/x86/guest/hyperv/Makefile
> index 68170109a9..18902c33e9 100644
> --- a/xen/arch/x86/guest/hyperv/Makefile
> +++ b/xen/arch/x86/guest/hyperv/Makefile
> @@ -1 +1,2 @@
> obj-y += hyperv.o
> +obj-y += tlb.o
> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
> b/xen/arch/x86/guest/hyperv/hyperv.c
> index 70f4cd5ae0..f9d1f11ae3 100644
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -33,6 +33,8 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
> DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
> DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
>
> +static bool __read_mostly hv_hcall_page_ready;
> +
> static uint64_t generate_guest_id(void)
> {
> union hv_guest_os_id id = {};
> @@ -119,6 +121,8 @@ static void __init setup_hypercall_page(void)
> BUG_ON(!hypercall_msr.enable);
>
> set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
Shouldn't this have at least a compiler barrier here?
Paul
> +
> +hv_hcall_page_ready = true;
> }
>
> static int setup_hypercall_pcpu_arg(void)
> @@ -199,11 +203,24 @@ static void __init e820_fixup(struct e820map *e820)
> panic("Unable to reserve Hyper-V hypercall range\n");
> }
>
> +static int flush_tlb(const cpumask_t *mask, const void *va,
> + unsigned int flags)
> +{
> +if ( !(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED) )
> +return -EOPNOTSUPP;
> +
> +if ( !hv_hcall_page_ready || !this_cpu(hv_input_page) )
> +return -ENXIO;
> +
> +return hyperv_flush_tlb(mask, va, flags);
> +}
> +
> static const struct hypervisor_ops __initdata ops = {
> .name = "Hyper-V",
> .setup = setup,
> .ap_setup = ap_setup,
> .e820_fixup = e820_fixup,
> +.flush_tlb = flush_tlb,
> };
>
> /*
> diff --git a/xen/arch/x86/guest/hyperv/private.h
> b/xen/arch/x86/guest/hyperv/private.h
> index 956eff831f..509bedaafa 100644
> --- a/xen/arch/x86/guest/hyperv/private.h
> +++ b/xen/arch/x86/guest/hyperv/private.h
> @@ -22,10 +22,14 @@
> #ifndef __XEN_HYPERV_PRIVIATE_H__
> #define __XEN_HYPERV_PRIVIATE_H__
>
> +#include
> #include
>
> DECLARE_PER_CPU(void *, hv_input_page);
> DECLARE_PER_CPU(void *, hv_vp_assist);
> DECLARE_PER_CPU(unsigned int, hv_vp_index);
>
> +int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
> + unsigned int flags);
> +
> #endif /* __XEN_HYPERV_PRIVIATE_H__ */
> diff --git a/xen/arch/x86/guest/hyperv/tlb.c
> b/xen/arch/x86/guest/hyperv/tlb.c
> new file mode 100644
> index 00..48f527229e
> --- /dev/null
> +++ b/xen/arch/x86/guest/hyperv/tlb.c
> @@ -0,0 +1,41 @@
> +/
> **
> + * arch/x86/guest/hyperv/tlb.c
> + *
> + * Support for TLB management using hypercalls
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see
Re: [Xen-devel] [PATCH v2 1/3] x86/hypervisor: pass flags to hypervisor_flush_tlb
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 14 February 2020 13:34
> To: Xen Development List
> Cc: Michael Kelley ; Durrant, Paul
> ; Wei Liu ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau Monné
> Subject: [PATCH v2 1/3] x86/hypervisor: pass flags to hypervisor_flush_tlb
>
> Hyper-V's L0 assisted flush has fine-grained control over what gets
> flushed. We need all the flags available to make the best decisions
> possible.
>
> No functional change because Xen's implementation doesn't care about
> what is passed to it.
>
> Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
> ---
> v2:
> 1. Introduce FLUSH_TLB_FLAGS_MASK
> ---
> xen/arch/x86/guest/hypervisor.c| 7 +--
> xen/arch/x86/guest/xen/xen.c | 2 +-
> xen/arch/x86/smp.c | 5 ++---
> xen/include/asm-x86/flushtlb.h | 3 +++
> xen/include/asm-x86/guest/hypervisor.h | 10 +-
> 5 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/xen/arch/x86/guest/hypervisor.c
> b/xen/arch/x86/guest/hypervisor.c
> index 47e938e287..6ee28c9df1 100644
> --- a/xen/arch/x86/guest/hypervisor.c
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -75,10 +75,13 @@ void __init hypervisor_e820_fixup(struct e820map
> *e820)
> }
>
> int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
> - unsigned int order)
> + unsigned int flags)
> {
> +if ( flags & ~FLUSH_TLB_FLAGS_MASK )
> +return -EINVAL;
> +
> if ( ops.flush_tlb )
> -return alternative_call(ops.flush_tlb, mask, va, order);
> +return alternative_call(ops.flush_tlb, mask, va, flags);
>
> return -ENOSYS;
> }
> diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
> index 5d3427a713..0eb1115c4d 100644
> --- a/xen/arch/x86/guest/xen/xen.c
> +++ b/xen/arch/x86/guest/xen/xen.c
> @@ -324,7 +324,7 @@ static void __init e820_fixup(struct e820map *e820)
> pv_shim_fixup_e820(e820);
> }
>
> -static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int
> order)
> +static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int
> flags)
> {
> return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
> }
> diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
> index 9bc925616a..2ab0e30eef 100644
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -258,9 +258,8 @@ void flush_area_mask(const cpumask_t *mask, const void
> *va, unsigned int flags)
> !cpumask_subset(mask, cpumask_of(cpu)) )
> {
> if ( cpu_has_hypervisor &&
> - !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID |
> - FLUSH_ORDER_MASK)) &&
> - !hypervisor_flush_tlb(mask, va, flags & FLUSH_ORDER_MASK) )
> + !(flags & ~FLUSH_TLB_FLAGS_MASK) &&
> + !hypervisor_flush_tlb(mask, va, flags) )
> {
> if ( tlb_clk_enabled )
> tlb_clk_enabled = false;
> diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-
> x86/flushtlb.h
> index 9773014320..a4de317452 100644
> --- a/xen/include/asm-x86/flushtlb.h
> +++ b/xen/include/asm-x86/flushtlb.h
> @@ -123,6 +123,9 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long
> cr4);
> /* Flush all HVM guests linear TLB (using ASID/VPID) */
> #define FLUSH_GUESTS_TLB 0x4000
>
> +#define FLUSH_TLB_FLAGS_MASK (FLUSH_TLB | FLUSH_TLB_GLOBAL |
> FLUSH_VA_VALID | \
> + FLUSH_ORDER_MASK)
> +
> /* Flush local TLBs/caches. */
> unsigned int flush_area_local(const void *va, unsigned int flags);
> #define flush_local(flags) flush_area_local(NULL, flags)
> diff --git a/xen/include/asm-x86/guest/hypervisor.h b/xen/include/asm-
> x86/guest/hypervisor.h
> index 432e57c2a0..48d54735d2 100644
> --- a/xen/include/asm-x86/guest/hypervisor.h
> +++ b/xen/include/asm-x86/guest/hypervisor.h
> @@ -35,7 +35,7 @@ struct hypervisor_ops {
> /* Fix up e820 map */
> void (*e820_fixup)(struct e820map *e820);
> /* L0 assisted TLB flush */
> -int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int
> order);
> +int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int
> flags);
> };
>
> #ifdef CONFIG_GUEST
> @@ -48,11 +48,11 @@ void hypervisor_e820_fixup(struct e820map *e820);
> /*
> * L0 assisted TLB flush.
> * mask: cpumask of the dirty vCPUs that should be flushed.
> - * va: linear address to flush, or NULL for global flushes.
> - * order: order of the linear address pointed by va.
> + * va: linear address to flush, or NULL for entire address space.
> + * flags: flags for flushing, including the order of va.
> */
> int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
> - unsigned int order);
> + unsigned int flags);
>
> #else
>
> @@ -65,7 +65,7 @@ static inline int hypervisor_ap_setup(void) { return 0;
> }
>
Re: [Xen-devel] [PATCH v2 3/3] x86/hyperv: L0 assisted TLB flush
From: Wei Liu On Behalf Of Wei Liu Sent: Friday,
February 14, 2020 4:35 AM
>
> Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
> of several hypercalls:
>
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
>
> Pick the most efficient hypercalls available.
>
> Signed-off-by: Wei Liu
> ---
> v2:
> 1. Address Roger and Jan's comments re types etc.
> 2. Fix pointer arithmetic.
> 3. Misc improvement to code.
> ---
> xen/arch/x86/guest/hyperv/Makefile | 1 +
> xen/arch/x86/guest/hyperv/private.h | 9 ++
> xen/arch/x86/guest/hyperv/tlb.c | 172 +++-
> xen/arch/x86/guest/hyperv/util.c| 74
> 4 files changed, 255 insertions(+), 1 deletion(-)
> create mode 100644 xen/arch/x86/guest/hyperv/util.c
>
> diff --git a/xen/arch/x86/guest/hyperv/Makefile
> b/xen/arch/x86/guest/hyperv/Makefile
> index 18902c33e9..0e39410968 100644
> --- a/xen/arch/x86/guest/hyperv/Makefile
> +++ b/xen/arch/x86/guest/hyperv/Makefile
> @@ -1,2 +1,3 @@
> obj-y += hyperv.o
> obj-y += tlb.o
> +obj-y += util.o
> diff --git a/xen/arch/x86/guest/hyperv/private.h
> b/xen/arch/x86/guest/hyperv/private.h
> index 509bedaafa..79a77930a0 100644
> --- a/xen/arch/x86/guest/hyperv/private.h
> +++ b/xen/arch/x86/guest/hyperv/private.h
> @@ -24,12 +24,21 @@
>
> #include
> #include
> +#include
>
> DECLARE_PER_CPU(void *, hv_input_page);
> DECLARE_PER_CPU(void *, hv_vp_assist);
> DECLARE_PER_CPU(unsigned int, hv_vp_index);
>
> +static inline unsigned int hv_vp_index(unsigned int cpu)
> +{
> +return per_cpu(hv_vp_index, cpu);
> +}
> +
> int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
> unsigned int flags);
>
> +/* Returns number of banks, -ev if error */
> +int cpumask_to_vpset(struct hv_vpset *vpset, const cpumask_t *mask);
> +
> #endif /* __XEN_HYPERV_PRIVIATE_H__ */
> diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
> index 48f527229e..f68e14f151 100644
> --- a/xen/arch/x86/guest/hyperv/tlb.c
> +++ b/xen/arch/x86/guest/hyperv/tlb.c
> @@ -19,15 +19,185 @@
> * Copyright (c) 2020 Microsoft.
> */
>
> +#include
> #include
> #include
>
> +#include
> +#include
> +#include
> +
> #include "private.h"
>
> +/*
> + * It is possible to encode up to 4096 pages using the lower 12 bits
> + * in an element of gva_list
> + */
> +#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
> +
> +static unsigned int fill_gva_list(uint64_t *gva_list, const void *va,
> + unsigned int order)
> +{
> +unsigned long start = (unsigned long)va;
> +unsigned long end = start + (PAGE_SIZE << order) - 1;
> +unsigned int n = 0;
> +
> +do {
> +unsigned long remain = end - start;
The calculated value here isn't actually the remaining bytes in the
range to flush -- it's one less than the remaining bytes in the range
to flush because of the -1 in the calculation of 'end'. That difference
will mess up the comparison below against HV_TLB_FLUSH_UNIT
in the case that there are exactly 4096 page remaining to be
flushed. It should take the "=" case, but won't. Also, the
'-1' in 'remain - 1' in the else clause becomes unneeded, and
the 'start = end' assignment then propagates the error.
In the parallel code in Linux, if you follow the call sequence to get to
fill_gav_list(), the 'end' argument is really the address of the first byte
of the first page that isn't in the flush range (i.e., one beyond the true
'end') and so is a bit misnamed.
I think the calculation of 'end' should drop the -1, and perhaps 'end'
should be renamed.
Michael
> +
> +gva_list[n] = start & PAGE_MASK;
> +
> +/*
> + * Use lower 12 bits to encode the number of additional pages
> + * to flush
> + */
> +if ( remain >= HV_TLB_FLUSH_UNIT )
> +{
> +gva_list[n] |= ~PAGE_MASK;
> +start += HV_TLB_FLUSH_UNIT;
> +}
> +else if ( remain )
> +{
> +gva_list[n] |= (remain - 1) >> PAGE_SHIFT;
> +start = end;
> +}
> +
> +n++;
> +} while ( start < end );
> +
> +return n;
> +}
> +
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: make sure stop_machine_run() is always called in a tasklet
On 14.02.20 15:06, Igor Druzhinin wrote: On 11/02/2020 09:35, Juergen Gross wrote: With core scheduling active it is mandatory for stop_machine_run() to be called in a tasklet only, as otherwise a scheduling deadlock would occur: stop_machine_run() does a cpu rendezvous by activating a tasklet on all other cpus. In case stop_machine_run() was not called in an idle vcpu it would block scheduling the idle vcpu on its siblings with core scheduling being active, resulting in a hang. I suppose rcu_barrier() is fine due to process_pending_softirqs() being called inside? I'm a little concerned by imposing is_vcpu_idle() restriction in that case as rcu_barrier() could be technically called from a non-tasklet context. No, stop_machine_run() with core scheduling active can only work when called in an idle vcpu. OTOH it would be fairly easy to add another softirq for a similar purpose and have a sync_machine_run() using that instead of tasklets. This could be used for ucode loading, too. stop_machine_run() and sync_machine_run() could use a common main function. The patch should be rather simple. Thoughts? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH V2] build: fix configuration of libvirt
libvirt.git commit 2621d48f00 removed the last traces of gnulib, which
also removed the '--no-git' option from autogen.sh. Unknown options are
now passed to the configure script, which quickly fails with
configure: error: unrecognized option: `--no-git'
Remove the gnulib handling from ts-libvirt-build, including the '--no-git'
option to autogen.sh. While at it remove configure options no longer
supported by the libvirt configure script.
Signed-off-by: Jim Fehlig
---
The only change from V1 is adding Ian to cc.
I have poor perl skills, but hopefully this fixes the latest build
failures of the libvirt test project, e.g.
http://logs.test-lab.xenproject.org/osstest/logs/146921/build-amd64-libvirt/6.ts-libvirt-build.log
ts-libvirt-build | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/ts-libvirt-build b/ts-libvirt-build
index e799f003..ac5afcf2 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -26,8 +26,7 @@ tsreadconfig();
selectbuildhost(\@ARGV);
builddirsprops();
-our %submodmap = qw(gnulib gnulib
-keycodemapdb keycodemapdb);
+our %submodmap = qw(keycodemapdb keycodemapdb);
our $submodules;
sub libvirtd_init ();
@@ -50,12 +49,6 @@ sub config() {
}
die "no xen prefix" unless $xenprefix;
-# Uses --no-git because otherwise autogen.sh will undo
-# submodulefixup's attempts to honour
-# revision_libvirt_gnulib. This in turn requires that we specify
-# --gnulib-srcdir, but ./autogen.sh doesn't propagate
-# --gnulib-srcdir to ./bootstap so we use GNULIB_SRCDIR directly.
-my $gnulib = submodule_find($submodules, "gnulib");
target_cmd_build($ho, 3600, $builddir, <{Path} \\
-../autogen.sh --no-git \\
- --with-libxl --without-xen --without-xenapi
--without-selinux \\
- --without-lxc --without-vbox --without-uml \\
+../autogen.sh \\
+ --with-libxl --without-selinux \\
+ --without-lxc --without-vbox \\
--without-qemu --without-openvz --without-vmware \\
--sysconfdir=/etc --localstatedir=/var #/
END
--
2.25.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/hyperv: L0 assisted TLB flush
On Fri, Feb 14, 2020 at 03:42:17PM +0100, Roger Pau Monné wrote:
[...]
> > #endif /* __XEN_HYPERV_PRIVIATE_H__ */
> > diff --git a/xen/arch/x86/guest/hyperv/tlb.c
> > b/xen/arch/x86/guest/hyperv/tlb.c
> > index 48f527229e..f68e14f151 100644
> > --- a/xen/arch/x86/guest/hyperv/tlb.c
> > +++ b/xen/arch/x86/guest/hyperv/tlb.c
> > @@ -19,15 +19,185 @@
> > * Copyright (c) 2020 Microsoft.
> > */
> >
> > +#include
> > #include
> > #include
> >
> > +#include
> > +#include
> > +#include
> > +
> > #include "private.h"
> >
> > +/*
> > + * It is possible to encode up to 4096 pages using the lower 12 bits
> > + * in an element of gva_list
> > + */
> > +#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
> > +
> > +static unsigned int fill_gva_list(uint64_t *gva_list, const void *va,
> > + unsigned int order)
> > +{
> > +unsigned long start = (unsigned long)va;
> > +unsigned long end = start + (PAGE_SIZE << order) - 1;
> > +unsigned int n = 0;
> > +
> > +do {
> > +unsigned long remain = end - start;
> > +
> > +gva_list[n] = start & PAGE_MASK;
> > +
> > +/*
> > + * Use lower 12 bits to encode the number of additional pages
> > + * to flush
> > + */
> > +if ( remain >= HV_TLB_FLUSH_UNIT )
> > +{
> > +gva_list[n] |= ~PAGE_MASK;
> > +start += HV_TLB_FLUSH_UNIT;
> > +}
> > +else if ( remain )
>
> remain is always going to be > 0, since the loop condition is end >
> start, and hence this can be a plain else.
Ack.
>
> > +{
> > +gva_list[n] |= (remain - 1) >> PAGE_SHIFT;
> > +start = end;
> > +}
> > +
> > +n++;
> > +} while ( start < end );
> > +
> > +return n;
> > +}
> > +
> > +static uint64_t flush_tlb_ex(const cpumask_t *mask, const void *va,
> > + unsigned int flags)
> > +{
> > +struct hv_tlb_flush_ex *flush = this_cpu(hv_input_page);
> > +int nr_banks;
> > +unsigned int max_gvas, order = flags & FLUSH_ORDER_MASK;
> > +uint64_t ret;
> > +
> > +if ( !flush || local_irq_is_enabled() )
> > +{
> > +ASSERT_UNREACHABLE();
> > +return ~0ULL;
> > +}
> > +
> > +if ( !(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED) )
> > +return ~0ULL;
> > +
> > +flush->address_space = 0;
> > +flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
> > +if ( !(flags & FLUSH_TLB_GLOBAL) )
> > +flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
> > +
> > +nr_banks = cpumask_to_vpset(>hv_vp_set, mask);
> > +if ( nr_banks < 0 )
> > +return ~0ULL;
>
> It would be nice to propagate the error code from cpumask_to_vpset,
> but since the function can also return HyperV error codes this doesn't
> make much sense.
>
> > +
> > +max_gvas =
> > +(PAGE_SIZE - sizeof(*flush) - nr_banks *
> > + sizeof(flush->hv_vp_set.bank_contents[0])) /
> > +sizeof(uint64_t); /* gva is represented as uint64_t */
> > +
> > +/*
> > + * Flush the entire address space if va is NULL or if there is not
> > + * enough space for gva_list.
> > + */
> > +if ( !va || (PAGE_SIZE << order) / HV_TLB_FLUSH_UNIT > max_gvas )
> > +ret = hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX, 0,
> > + nr_banks, virt_to_maddr(flush), 0);
>
> You could just return hv_do_rep_hypercall(...); here, which will avoid
> the else branch below and the indentation.
Ack.
>
> > +else
> > +{
> > +uint64_t *gva_list =
> > +(uint64_t *)flush + sizeof(*flush) / sizeof(uint64_t) +
> > nr_banks;
> > +unsigned int gvas = fill_gva_list(gva_list, va, order);
> > +
> > +BUILD_BUG_ON(sizeof(*flush) % sizeof(uint64_t));
> > +
> > +ret = hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX,
> > + gvas, nr_banks, virt_to_maddr(flush), 0);
> > +}
> > +
> > +return ret;
> > +}
> > +
> > int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
> > unsigned int flags)
> > {
> > -return -EOPNOTSUPP;
> > +unsigned long irq_flags;
> > +struct hv_tlb_flush *flush = this_cpu(hv_input_page);
> > +unsigned int max_gvas, order = flags & FLUSH_ORDER_MASK;
> > +uint64_t ret;
> > +
> > +ASSERT(flush);
> > +ASSERT(!cpumask_empty(mask));
>
> I would also turn this into an if ( ... ) { ASSERT; return -EFOO; }
Ack.
>
> > +
> > +local_irq_save(irq_flags);
> > +
> > +flush->address_space = 0;
> > +flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
> > +flush->processor_mask = 0;
> > +if ( !(flags & FLUSH_TLB_GLOBAL) )
> > +flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
> > +
> > +if ( cpumask_equal(mask, _online_map) )
> > +flush->flags |= HV_FLUSH_ALL_PROCESSORS;
> > +else
> > +{
> > +
[Xen-devel] [linux-4.4 test] 146992: regressions - FAIL
flight 146992 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146992/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 139698 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt 18 guest-start/debian.repeat fail in 146915 pass in 146992 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 146915 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 139698 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linuxd6ccbff9be43dbb6113a6a3f107c3d066052097e baseline version: linuxdc16a7e5f36d65b25a1b66ade14356773ed52875 Last test of basis 139698 2019-08-04 07:48:30 Z 194 days Failing since139773 2019-08-06 16:40:26 Z 191 days 106 attempts Testing same since 146860 2020-02-11 11:18:03 Z3 days3 attempts 1072 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass
Re: [Xen-devel] [PATCH v2 2/3] x86/hyperv: skeleton for L0 assisted TLB flush
On Fri, Feb 14, 2020 at 12:34:29PM +, Wei Liu wrote: > Implement a basic hook for L0 assisted TLB flush. The hook needs to > check if prerequisites are met. If they are not met, it returns an error > number to fall back to native flushes. > > Introduce a new variable to indicate if hypercall page is ready. > > Signed-off-by: Wei Liu Reviewed-by: Roger Pau Monné Just one comment below. > --- > xen/arch/x86/guest/hyperv/Makefile | 1 + > xen/arch/x86/guest/hyperv/hyperv.c | 17 > xen/arch/x86/guest/hyperv/private.h | 4 +++ > xen/arch/x86/guest/hyperv/tlb.c | 41 + > 4 files changed, 63 insertions(+) > create mode 100644 xen/arch/x86/guest/hyperv/tlb.c > > diff --git a/xen/arch/x86/guest/hyperv/Makefile > b/xen/arch/x86/guest/hyperv/Makefile > index 68170109a9..18902c33e9 100644 > --- a/xen/arch/x86/guest/hyperv/Makefile > +++ b/xen/arch/x86/guest/hyperv/Makefile > @@ -1 +1,2 @@ > obj-y += hyperv.o > +obj-y += tlb.o > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c > b/xen/arch/x86/guest/hyperv/hyperv.c > index 70f4cd5ae0..f9d1f11ae3 100644 > --- a/xen/arch/x86/guest/hyperv/hyperv.c > +++ b/xen/arch/x86/guest/hyperv/hyperv.c > @@ -33,6 +33,8 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page); > DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist); > DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index); > > +static bool __read_mostly hv_hcall_page_ready; Since this is static, I would drop the hv_ prefix. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/3] x86/hypervisor: pass flags to hypervisor_flush_tlb
On Fri, Feb 14, 2020 at 12:34:28PM +, Wei Liu wrote:
> Hyper-V's L0 assisted flush has fine-grained control over what gets
> flushed. We need all the flags available to make the best decisions
> possible.
>
> No functional change because Xen's implementation doesn't care about
> what is passed to it.
>
> Signed-off-by: Wei Liu
LGTM:
Reviewed-by: Roger Pau Monné
Just one comment below.
> ---
> v2:
> 1. Introduce FLUSH_TLB_FLAGS_MASK
> ---
> xen/arch/x86/guest/hypervisor.c| 7 +--
> xen/arch/x86/guest/xen/xen.c | 2 +-
> xen/arch/x86/smp.c | 5 ++---
> xen/include/asm-x86/flushtlb.h | 3 +++
> xen/include/asm-x86/guest/hypervisor.h | 10 +-
> 5 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
> index 47e938e287..6ee28c9df1 100644
> --- a/xen/arch/x86/guest/hypervisor.c
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -75,10 +75,13 @@ void __init hypervisor_e820_fixup(struct e820map *e820)
> }
>
> int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
> - unsigned int order)
> + unsigned int flags)
> {
> +if ( flags & ~FLUSH_TLB_FLAGS_MASK )
I think an ASSERT_UNREACHABLE() would be good here, since you are not
supposed to call hypervisor_flush_tlb with non TLB related flags.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/hyperv: L0 assisted TLB flush
On Fri, Feb 14, 2020 at 12:34:30PM +, Wei Liu wrote:
> Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
> of several hypercalls:
>
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
>
> Pick the most efficient hypercalls available.
>
> Signed-off-by: Wei Liu
Thanks! LGTM, I've just got a couple of comments below.
> ---
> v2:
> 1. Address Roger and Jan's comments re types etc.
> 2. Fix pointer arithmetic.
> 3. Misc improvement to code.
> ---
> xen/arch/x86/guest/hyperv/Makefile | 1 +
> xen/arch/x86/guest/hyperv/private.h | 9 ++
> xen/arch/x86/guest/hyperv/tlb.c | 172 +++-
> xen/arch/x86/guest/hyperv/util.c| 74
> 4 files changed, 255 insertions(+), 1 deletion(-)
> create mode 100644 xen/arch/x86/guest/hyperv/util.c
>
> diff --git a/xen/arch/x86/guest/hyperv/Makefile
> b/xen/arch/x86/guest/hyperv/Makefile
> index 18902c33e9..0e39410968 100644
> --- a/xen/arch/x86/guest/hyperv/Makefile
> +++ b/xen/arch/x86/guest/hyperv/Makefile
> @@ -1,2 +1,3 @@
> obj-y += hyperv.o
> obj-y += tlb.o
> +obj-y += util.o
> diff --git a/xen/arch/x86/guest/hyperv/private.h
> b/xen/arch/x86/guest/hyperv/private.h
> index 509bedaafa..79a77930a0 100644
> --- a/xen/arch/x86/guest/hyperv/private.h
> +++ b/xen/arch/x86/guest/hyperv/private.h
> @@ -24,12 +24,21 @@
>
> #include
> #include
> +#include
>
> DECLARE_PER_CPU(void *, hv_input_page);
> DECLARE_PER_CPU(void *, hv_vp_assist);
> DECLARE_PER_CPU(unsigned int, hv_vp_index);
>
> +static inline unsigned int hv_vp_index(unsigned int cpu)
> +{
> +return per_cpu(hv_vp_index, cpu);
> +}
> +
> int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
> unsigned int flags);
>
> +/* Returns number of banks, -ev if error */
> +int cpumask_to_vpset(struct hv_vpset *vpset, const cpumask_t *mask);
> +
> #endif /* __XEN_HYPERV_PRIVIATE_H__ */
> diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
> index 48f527229e..f68e14f151 100644
> --- a/xen/arch/x86/guest/hyperv/tlb.c
> +++ b/xen/arch/x86/guest/hyperv/tlb.c
> @@ -19,15 +19,185 @@
> * Copyright (c) 2020 Microsoft.
> */
>
> +#include
> #include
> #include
>
> +#include
> +#include
> +#include
> +
> #include "private.h"
>
> +/*
> + * It is possible to encode up to 4096 pages using the lower 12 bits
> + * in an element of gva_list
> + */
> +#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
> +
> +static unsigned int fill_gva_list(uint64_t *gva_list, const void *va,
> + unsigned int order)
> +{
> +unsigned long start = (unsigned long)va;
> +unsigned long end = start + (PAGE_SIZE << order) - 1;
> +unsigned int n = 0;
> +
> +do {
> +unsigned long remain = end - start;
> +
> +gva_list[n] = start & PAGE_MASK;
> +
> +/*
> + * Use lower 12 bits to encode the number of additional pages
> + * to flush
> + */
> +if ( remain >= HV_TLB_FLUSH_UNIT )
> +{
> +gva_list[n] |= ~PAGE_MASK;
> +start += HV_TLB_FLUSH_UNIT;
> +}
> +else if ( remain )
remain is always going to be > 0, since the loop condition is end >
start, and hence this can be a plain else.
> +{
> +gva_list[n] |= (remain - 1) >> PAGE_SHIFT;
> +start = end;
> +}
> +
> +n++;
> +} while ( start < end );
> +
> +return n;
> +}
> +
> +static uint64_t flush_tlb_ex(const cpumask_t *mask, const void *va,
> + unsigned int flags)
> +{
> +struct hv_tlb_flush_ex *flush = this_cpu(hv_input_page);
> +int nr_banks;
> +unsigned int max_gvas, order = flags & FLUSH_ORDER_MASK;
> +uint64_t ret;
> +
> +if ( !flush || local_irq_is_enabled() )
> +{
> +ASSERT_UNREACHABLE();
> +return ~0ULL;
> +}
> +
> +if ( !(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED) )
> +return ~0ULL;
> +
> +flush->address_space = 0;
> +flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
> +if ( !(flags & FLUSH_TLB_GLOBAL) )
> +flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
> +
> +nr_banks = cpumask_to_vpset(>hv_vp_set, mask);
> +if ( nr_banks < 0 )
> +return ~0ULL;
It would be nice to propagate the error code from cpumask_to_vpset,
but since the function can also return HyperV error codes this doesn't
make much sense.
> +
> +max_gvas =
> +(PAGE_SIZE - sizeof(*flush) - nr_banks *
> + sizeof(flush->hv_vp_set.bank_contents[0])) /
> +sizeof(uint64_t); /* gva is represented as uint64_t */
> +
> +/*
> + * Flush the entire address space if va is NULL or if there is not
> + * enough space for gva_list.
> + */
> +if ( !va || (PAGE_SIZE << order) / HV_TLB_FLUSH_UNIT > max_gvas )
Re: [Xen-devel] [PATCH] xen: make sure stop_machine_run() is always called in a tasklet
On 11/02/2020 09:35, Juergen Gross wrote: > With core scheduling active it is mandatory for stop_machine_run() to > be called in a tasklet only, as otherwise a scheduling deadlock would > occur: stop_machine_run() does a cpu rendezvous by activating a tasklet > on all other cpus. In case stop_machine_run() was not called in an idle > vcpu it would block scheduling the idle vcpu on its siblings with core > scheduling being active, resulting in a hang. I suppose rcu_barrier() is fine due to process_pending_softirqs() being called inside? I'm a little concerned by imposing is_vcpu_idle() restriction in that case as rcu_barrier() could be technically called from a non-tasklet context. Igor ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 147046: regressions - FAIL
flight 147046 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147046/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
version targeted for testing:
xen 2a03e7875837eae6ac9da375af4954780e36e448
baseline version:
xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c
Last test of basis 146882 2020-02-11 16:00:54 Z2 days
Failing since146893 2020-02-11 20:01:02 Z2 days 27 attempts
Testing same since 147030 2020-02-14 02:00:54 Z0 days4 attempts
People who touched revisions under test:
Andrew Cooper
Anthony PERARD
Ian Jackson
Jan Beulich
Juergen Gross
Julien Grall
Roger Pau Monné
Wei Liu
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt fail
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 2a03e7875837eae6ac9da375af4954780e36e448
Author: Julien Grall
Date: Thu Feb 13 12:39:06 2020 +
xen/arm: Use asm/ rather than asm-arm/ when including header
All the arch headers (i.e under asm-arm) are included using "asm/*.h".
To stay consistent, remove the only instance where "asm-arm/*.h" is
used.
Take the opportunity to move the inclusion with the rest of the asm/
include.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
commit d3cec8e1f230750a5d1b83412e8f86d0c95fcab6
Author: Wei Liu
Date: Thu Feb 13 15:27:51 2020 +
libxl: fix libxl__cpuid_legacy in libxl_nocpuid.c
Its last parameter should be libxl_domain_build_info.
Fixes: 1b3cec69 ("tools/libxl: Combine legacy CPUID handling logic")
Signed-off-by: Wei Liu
Acked-by: Anthony PERARD
commit c968e3ada478e5c9a11ba13a0f90d56323872693
Author: Anthony PERARD
Date: Thu Feb 13 13:42:00 2020 +
automation: update debian:unstable-arm64v8 to have python3-config
The Arm container wasn't updated in the original patch.
Fixes: 1a3673da6482 ("automation: updating container to have python3-config
binary")
Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
commit 1fb9a8bd8c7158eed26acb5ecd3210b82f1c31d4
Author: Juergen Gross
Date: Wed Feb 12 08:41:54 2020 +0100
xenstore: remove not applicable control commands in stubdom
When run in a stubdom environment Xenstore can't select a logfile or
emit memory statistics to a specific file.
So remove or modify those control commands accordingly.
Signed-off-by: Juergen Gross
Acked-by: Andrew Cooper
Acked-by: Wei Liu
commit a9594631b645be862857e3debbd1f04e932eb197
Author: Juergen Gross
Date: Wed Feb 12 08:41:53 2020 +0100
xenstore: add console xenstore entries for xenstore stubdom
In order to be able to connect to the console of Xenstore stubdom we
need to create the appropriate entries in Xenstore.
For the moment we don't support xenconsoled living in another domain
than dom0, as this information isn't available other then via
Xenstore which we are just setting up.
Signed-off-by: Juergen Gross
Acked-by: Andrew Cooper
Acked-by: Wei Liu
commit 5d1f9cd27eae7338bd149cc98edcf2a55468d1d3
Author: Juergen Gross
Date: Wed Feb 12 08:41:52 2020 +0100
Re: [Xen-devel] [PATCH RFC] docs: move xen-command-line.pandoc under admin-guide
On Fri, Feb 14, 2020 at 12:50:36PM +, Andrew Cooper wrote: > On 14/02/2020 12:46, Wei Liu wrote: > > That directory would be the first place I look if I need to know xen > > command line options. > > > > Signed-off-by: Wei Liu > > Please not quite yet. This breaks the (defacto common) URL on > xenbits.xen.org/docs/ and I've got an in-progress series to convert it > to RST. > > Also, there is some GPLv2 => CC-BY licensing to figure out. > > Longterm, I absolutely want it to live there. How about we put a stub file there to point to the real file for now? Wei. > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] docs: move xen-command-line.pandoc under admin-guide
On 14/02/2020 12:46, Wei Liu wrote: > That directory would be the first place I look if I need to know xen > command line options. > > Signed-off-by: Wei Liu Please not quite yet. This breaks the (defacto common) URL on xenbits.xen.org/docs/ and I've got an in-progress series to convert it to RST. Also, there is some GPLv2 => CC-BY licensing to figure out. Longterm, I absolutely want it to live there. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RFC] docs: move xen-command-line.pandoc under admin-guide
That directory would be the first place I look if I need to know xen
command line options.
Signed-off-by: Wei Liu
---
docs/{misc => admin-guide}/xen-command-line.pandoc | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename docs/{misc => admin-guide}/xen-command-line.pandoc (100%)
diff --git a/docs/misc/xen-command-line.pandoc
b/docs/admin-guide/xen-command-line.pandoc
similarity index 100%
rename from docs/misc/xen-command-line.pandoc
rename to docs/admin-guide/xen-command-line.pandoc
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/3] Xen on Hyper-V: Implement L0 assisted TLB flush
Hi all This seris is based on Roger's L0 assisted flush series. I have done some testing against a Linux on Hyper-V in a 32-vcpu VM. All builds were done with -j32. Building Xen on Linux: real0m45.376s user2m28.156s sys 0m51.672s Building Xen on Linux on Xen on Hyper-V, no assisted flush: real3m8.762s user10m46.787s sys 30m14.492s Building Xen on Linux on Xen on Hyper-V, with assisted flush: real0m44.369s user3m16.231s sys 3m3.330s Building Linux x86_64_defconfig on Linux: real0m59.698s user21m14.014s sys 2m58.742s Building Linux x86_64_defconfig on Linux on Xen on Hyper-V, no assisted flush: real2m6.284s user31m18.706s sys 20m31.106s Building Linux x86_64_defconfig on Linux on Xen on Hyper-V, with assisted flush: real1m38.968s user28m40.398s sys 11m20.151s There are various degrees of improvement depending on the workload. Xen can perhaps be optmised a bit more because it currently doesn't pass the address space id (cr3) to Hyper-V, but that requires reworking TLB flush APIs within Xen. Wei. Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: Roger Pau Monné Cc: Michael Kelley Cc: Paul Durrant Wei Liu (3): x86/hypervisor: pass flags to hypervisor_flush_tlb x86/hyperv: skeleton for L0 assisted TLB flush x86/hyperv: L0 assisted TLB flush xen/arch/x86/guest/hyperv/Makefile | 2 + xen/arch/x86/guest/hyperv/hyperv.c | 17 ++ xen/arch/x86/guest/hyperv/private.h| 13 ++ xen/arch/x86/guest/hyperv/tlb.c| 211 + xen/arch/x86/guest/hyperv/util.c | 74 + xen/arch/x86/guest/hypervisor.c| 7 +- xen/arch/x86/guest/xen/xen.c | 2 +- xen/arch/x86/smp.c | 5 +- xen/include/asm-x86/flushtlb.h | 3 + xen/include/asm-x86/guest/hypervisor.h | 10 +- 10 files changed, 333 insertions(+), 11 deletions(-) create mode 100644 xen/arch/x86/guest/hyperv/tlb.c create mode 100644 xen/arch/x86/guest/hyperv/util.c -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/3] x86/hyperv: skeleton for L0 assisted TLB flush
Implement a basic hook for L0 assisted TLB flush. The hook needs to
check if prerequisites are met. If they are not met, it returns an error
number to fall back to native flushes.
Introduce a new variable to indicate if hypercall page is ready.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/Makefile | 1 +
xen/arch/x86/guest/hyperv/hyperv.c | 17
xen/arch/x86/guest/hyperv/private.h | 4 +++
xen/arch/x86/guest/hyperv/tlb.c | 41 +
4 files changed, 63 insertions(+)
create mode 100644 xen/arch/x86/guest/hyperv/tlb.c
diff --git a/xen/arch/x86/guest/hyperv/Makefile
b/xen/arch/x86/guest/hyperv/Makefile
index 68170109a9..18902c33e9 100644
--- a/xen/arch/x86/guest/hyperv/Makefile
+++ b/xen/arch/x86/guest/hyperv/Makefile
@@ -1 +1,2 @@
obj-y += hyperv.o
+obj-y += tlb.o
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
b/xen/arch/x86/guest/hyperv/hyperv.c
index 70f4cd5ae0..f9d1f11ae3 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -33,6 +33,8 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
+static bool __read_mostly hv_hcall_page_ready;
+
static uint64_t generate_guest_id(void)
{
union hv_guest_os_id id = {};
@@ -119,6 +121,8 @@ static void __init setup_hypercall_page(void)
BUG_ON(!hypercall_msr.enable);
set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
+
+hv_hcall_page_ready = true;
}
static int setup_hypercall_pcpu_arg(void)
@@ -199,11 +203,24 @@ static void __init e820_fixup(struct e820map *e820)
panic("Unable to reserve Hyper-V hypercall range\n");
}
+static int flush_tlb(const cpumask_t *mask, const void *va,
+ unsigned int flags)
+{
+if ( !(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED) )
+return -EOPNOTSUPP;
+
+if ( !hv_hcall_page_ready || !this_cpu(hv_input_page) )
+return -ENXIO;
+
+return hyperv_flush_tlb(mask, va, flags);
+}
+
static const struct hypervisor_ops __initdata ops = {
.name = "Hyper-V",
.setup = setup,
.ap_setup = ap_setup,
.e820_fixup = e820_fixup,
+.flush_tlb = flush_tlb,
};
/*
diff --git a/xen/arch/x86/guest/hyperv/private.h
b/xen/arch/x86/guest/hyperv/private.h
index 956eff831f..509bedaafa 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -22,10 +22,14 @@
#ifndef __XEN_HYPERV_PRIVIATE_H__
#define __XEN_HYPERV_PRIVIATE_H__
+#include
#include
DECLARE_PER_CPU(void *, hv_input_page);
DECLARE_PER_CPU(void *, hv_vp_assist);
DECLARE_PER_CPU(unsigned int, hv_vp_index);
+int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
+ unsigned int flags);
+
#endif /* __XEN_HYPERV_PRIVIATE_H__ */
diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
new file mode 100644
index 00..48f527229e
--- /dev/null
+++ b/xen/arch/x86/guest/hyperv/tlb.c
@@ -0,0 +1,41 @@
+/**
+ * arch/x86/guest/hyperv/tlb.c
+ *
+ * Support for TLB management using hypercalls
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see
[Xen-devel] [PATCH v2 3/3] x86/hyperv: L0 assisted TLB flush
Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
of several hypercalls:
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
Pick the most efficient hypercalls available.
Signed-off-by: Wei Liu
---
v2:
1. Address Roger and Jan's comments re types etc.
2. Fix pointer arithmetic.
3. Misc improvement to code.
---
xen/arch/x86/guest/hyperv/Makefile | 1 +
xen/arch/x86/guest/hyperv/private.h | 9 ++
xen/arch/x86/guest/hyperv/tlb.c | 172 +++-
xen/arch/x86/guest/hyperv/util.c| 74
4 files changed, 255 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/x86/guest/hyperv/util.c
diff --git a/xen/arch/x86/guest/hyperv/Makefile
b/xen/arch/x86/guest/hyperv/Makefile
index 18902c33e9..0e39410968 100644
--- a/xen/arch/x86/guest/hyperv/Makefile
+++ b/xen/arch/x86/guest/hyperv/Makefile
@@ -1,2 +1,3 @@
obj-y += hyperv.o
obj-y += tlb.o
+obj-y += util.o
diff --git a/xen/arch/x86/guest/hyperv/private.h
b/xen/arch/x86/guest/hyperv/private.h
index 509bedaafa..79a77930a0 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -24,12 +24,21 @@
#include
#include
+#include
DECLARE_PER_CPU(void *, hv_input_page);
DECLARE_PER_CPU(void *, hv_vp_assist);
DECLARE_PER_CPU(unsigned int, hv_vp_index);
+static inline unsigned int hv_vp_index(unsigned int cpu)
+{
+return per_cpu(hv_vp_index, cpu);
+}
+
int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
unsigned int flags);
+/* Returns number of banks, -ev if error */
+int cpumask_to_vpset(struct hv_vpset *vpset, const cpumask_t *mask);
+
#endif /* __XEN_HYPERV_PRIVIATE_H__ */
diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
index 48f527229e..f68e14f151 100644
--- a/xen/arch/x86/guest/hyperv/tlb.c
+++ b/xen/arch/x86/guest/hyperv/tlb.c
@@ -19,15 +19,185 @@
* Copyright (c) 2020 Microsoft.
*/
+#include
#include
#include
+#include
+#include
+#include
+
#include "private.h"
+/*
+ * It is possible to encode up to 4096 pages using the lower 12 bits
+ * in an element of gva_list
+ */
+#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
+
+static unsigned int fill_gva_list(uint64_t *gva_list, const void *va,
+ unsigned int order)
+{
+unsigned long start = (unsigned long)va;
+unsigned long end = start + (PAGE_SIZE << order) - 1;
+unsigned int n = 0;
+
+do {
+unsigned long remain = end - start;
+
+gva_list[n] = start & PAGE_MASK;
+
+/*
+ * Use lower 12 bits to encode the number of additional pages
+ * to flush
+ */
+if ( remain >= HV_TLB_FLUSH_UNIT )
+{
+gva_list[n] |= ~PAGE_MASK;
+start += HV_TLB_FLUSH_UNIT;
+}
+else if ( remain )
+{
+gva_list[n] |= (remain - 1) >> PAGE_SHIFT;
+start = end;
+}
+
+n++;
+} while ( start < end );
+
+return n;
+}
+
+static uint64_t flush_tlb_ex(const cpumask_t *mask, const void *va,
+ unsigned int flags)
+{
+struct hv_tlb_flush_ex *flush = this_cpu(hv_input_page);
+int nr_banks;
+unsigned int max_gvas, order = flags & FLUSH_ORDER_MASK;
+uint64_t ret;
+
+if ( !flush || local_irq_is_enabled() )
+{
+ASSERT_UNREACHABLE();
+return ~0ULL;
+}
+
+if ( !(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED) )
+return ~0ULL;
+
+flush->address_space = 0;
+flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
+if ( !(flags & FLUSH_TLB_GLOBAL) )
+flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
+
+nr_banks = cpumask_to_vpset(>hv_vp_set, mask);
+if ( nr_banks < 0 )
+return ~0ULL;
+
+max_gvas =
+(PAGE_SIZE - sizeof(*flush) - nr_banks *
+ sizeof(flush->hv_vp_set.bank_contents[0])) /
+sizeof(uint64_t); /* gva is represented as uint64_t */
+
+/*
+ * Flush the entire address space if va is NULL or if there is not
+ * enough space for gva_list.
+ */
+if ( !va || (PAGE_SIZE << order) / HV_TLB_FLUSH_UNIT > max_gvas )
+ret = hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX, 0,
+ nr_banks, virt_to_maddr(flush), 0);
+else
+{
+uint64_t *gva_list =
+(uint64_t *)flush + sizeof(*flush) / sizeof(uint64_t) + nr_banks;
+unsigned int gvas = fill_gva_list(gva_list, va, order);
+
+BUILD_BUG_ON(sizeof(*flush) % sizeof(uint64_t));
+
+ret = hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX,
+ gvas, nr_banks, virt_to_maddr(flush), 0);
+}
+
+return ret;
+}
+
int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
unsigned int flags)
{
-
[Xen-devel] [PATCH v2 1/3] x86/hypervisor: pass flags to hypervisor_flush_tlb
Hyper-V's L0 assisted flush has fine-grained control over what gets
flushed. We need all the flags available to make the best decisions
possible.
No functional change because Xen's implementation doesn't care about
what is passed to it.
Signed-off-by: Wei Liu
---
v2:
1. Introduce FLUSH_TLB_FLAGS_MASK
---
xen/arch/x86/guest/hypervisor.c| 7 +--
xen/arch/x86/guest/xen/xen.c | 2 +-
xen/arch/x86/smp.c | 5 ++---
xen/include/asm-x86/flushtlb.h | 3 +++
xen/include/asm-x86/guest/hypervisor.h | 10 +-
5 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 47e938e287..6ee28c9df1 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -75,10 +75,13 @@ void __init hypervisor_e820_fixup(struct e820map *e820)
}
int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
- unsigned int order)
+ unsigned int flags)
{
+if ( flags & ~FLUSH_TLB_FLAGS_MASK )
+return -EINVAL;
+
if ( ops.flush_tlb )
-return alternative_call(ops.flush_tlb, mask, va, order);
+return alternative_call(ops.flush_tlb, mask, va, flags);
return -ENOSYS;
}
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 5d3427a713..0eb1115c4d 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -324,7 +324,7 @@ static void __init e820_fixup(struct e820map *e820)
pv_shim_fixup_e820(e820);
}
-static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int order)
+static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int flags)
{
return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
}
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 9bc925616a..2ab0e30eef 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -258,9 +258,8 @@ void flush_area_mask(const cpumask_t *mask, const void *va,
unsigned int flags)
!cpumask_subset(mask, cpumask_of(cpu)) )
{
if ( cpu_has_hypervisor &&
- !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID |
- FLUSH_ORDER_MASK)) &&
- !hypervisor_flush_tlb(mask, va, flags & FLUSH_ORDER_MASK) )
+ !(flags & ~FLUSH_TLB_FLAGS_MASK) &&
+ !hypervisor_flush_tlb(mask, va, flags) )
{
if ( tlb_clk_enabled )
tlb_clk_enabled = false;
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 9773014320..a4de317452 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -123,6 +123,9 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4);
/* Flush all HVM guests linear TLB (using ASID/VPID) */
#define FLUSH_GUESTS_TLB 0x4000
+#define FLUSH_TLB_FLAGS_MASK (FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID | \
+ FLUSH_ORDER_MASK)
+
/* Flush local TLBs/caches. */
unsigned int flush_area_local(const void *va, unsigned int flags);
#define flush_local(flags) flush_area_local(NULL, flags)
diff --git a/xen/include/asm-x86/guest/hypervisor.h
b/xen/include/asm-x86/guest/hypervisor.h
index 432e57c2a0..48d54735d2 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -35,7 +35,7 @@ struct hypervisor_ops {
/* Fix up e820 map */
void (*e820_fixup)(struct e820map *e820);
/* L0 assisted TLB flush */
-int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int
order);
+int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int
flags);
};
#ifdef CONFIG_GUEST
@@ -48,11 +48,11 @@ void hypervisor_e820_fixup(struct e820map *e820);
/*
* L0 assisted TLB flush.
* mask: cpumask of the dirty vCPUs that should be flushed.
- * va: linear address to flush, or NULL for global flushes.
- * order: order of the linear address pointed by va.
+ * va: linear address to flush, or NULL for entire address space.
+ * flags: flags for flushing, including the order of va.
*/
int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
- unsigned int order);
+ unsigned int flags);
#else
@@ -65,7 +65,7 @@ static inline int hypervisor_ap_setup(void) { return 0; }
static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
static inline void hypervisor_e820_fixup(struct e820map *e820) {}
static inline int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
- unsigned int order)
+ unsigned int flags)
{
return -ENOSYS;
}
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/3] bitmap: import bitmap_{set/clear} from Linux 5.5
On 14.02.2020 11:40, Roger Pau Monné wrote:
> On Mon, Feb 10, 2020 at 12:54:04PM +, Julien Grall wrote:
>>
>>
>> On 10/02/2020 12:32, Jan Beulich wrote:
>>> On 10.02.2020 13:21, Julien Grall wrote:
Hi,
On 10/02/2020 11:59, Jan Beulich wrote:
> On 10.02.2020 12:00, Julien Grall wrote:
>> On 10/02/2020 10:28, Jan Beulich wrote:
>>> On 10.02.2020 10:45, Julien Grall wrote:
Please suggest a new name for BIT_WORD() and we can repurpose it. So
far, I have no idea how to rename it.
>>>
>>> _BIT_WORD() if you/we were to accept the name space violation, or
>>> BITMAP_WORD()?
>>
>> BITMAP_WORD() is misleading as bitmap are using unsigned long. So my
>> preference is _BIT_WORD().
>>
>> Another alternative would be ATOMIC_WORD().
>
> Except that there are also non-atomic bitmap operations, I don't really
> care about the name as long as it's not BIT_WORD() (or anything else
> that's likely to collide with other stuff.
I am afraid we are disagreing on what is colliding with what here. The
naming on Arm has been like that for the past few years. While this may
not have been the best choice, this is your suggestion colliding with
what is existing.
>>>
>>> It is a plain import from Linux which has turned out impossible
>>> because of the change that was done at some point to Arm code
>>> which, I guess, also originally came from Linux. There's no new
>>> naming I've been suggesting here at all.
>>
>> We never claimed we would be fully compatible with Linux and I don't think
>> we could every claim it. Particularly, the bitop operations are different
>> given Linux bitops are based on unsigned long.
>>
>> The bitop did indeed came from Linux originally, however we had to adapt
>> them because Linux Armv8 bitop was expecting 8-byte aligned. This does not
>> hold on Xen.
>>
>>>
I am not entirely fussed about the namespace violation, although I think
the name is potentially misleading. Yet, I would be happy to use
_BIT_WORD() as this is the best of it so far.
While this is code falls under Arm maintainership, I am still happy to
consider other naming. But at this point, you should be the one suggesting.
>>>
>>> BIT_UNIT() or BITOP_UNIT() or BITOP_WORD()?
>>
>> BITOP_WORD().
>
> So I assume you would like me to import bitmap_{set/clear} and use it
> in the x2APIC MSR patch?
Well, it's really up to you. I've put this as an item on my own todo
list already, assuming there may be more places where the two functions
might turn out useful.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 146988: regressions - FAIL
flight 146988 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146988/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 142947 test-amd64-i386-xl-xsm 20 guest-start/debian.repeat fail REGR. vs. 142947 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail pass in 146910 test-amd64-i386-xl-raw 22 leak-check/check fail pass in 146910 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 146910 like 142947 test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 142893 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 142893 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142947 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142947 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142947 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142947 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142947 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux0e96b1eb0ea5e4e8cdcdde6f0c68f89dc1d08be7 baseline version: linux364ef83db0273acc89c6ba8ae1aebee70a133056 Last test of basis 142947 2019-10-20 03:26:28 Z 117 days Failing since143328 2019-10-29 08:51:20 Z 108 days8 attempts Testing same since 146858 2020-02-11 11:11:29 Z3 days3 attempts 1047 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf
Re: [Xen-devel] [PATCH] libxl: mark parameters in stub functions as unused
Wei Liu writes ("Re: [PATCH] libxl: mark parameters in stub functions as
unused"):
> I have actually successfully compiled a C file written in a similar way
> and tried with / without -Wunused-paremeter. After adding the unused
> attribute gcc stopped spitting out a warning.
That sounds like a sufficient test to me.
> I don't have libvirt lying around though. That's what I didn't test.
>
> > Acked-by: Ian Jackson
>
> Thanks. I will push it shortly.
Great, thanks.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxl: mark parameters in stub functions as unused
On Fri, Feb 14, 2020 at 11:00:44AM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] libxl: mark parameters in stub functions as unused"):
> > Hopefully this can fix issues like:
> >
> > In file included from ../../src/libxl/xen_xl.c:24:0:
> > /home/osstest/build.147035.build-amd64-libvirt/xendist/usr/local/include/libxl.h:
> > In function 'libxl_cpuid_apply_policy':
> > /home/osstest/build.147035.build-amd64-libvirt/xendist/usr/local/include/libxl.h:2345:56:
> > error: unused parameter 'ctx' [-Werror=unused-parameter]
> > static inline void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t
> > domid) {}
> >
> > Fixes: dacb80f9 ("tools/libxl: Remove libxl_cpuid_{set,apply_policy}() from
> > the API")
> > Signed-off-by: Wei Liu
> > ---
> > Not able to test this locally, please review carefully...
>
> The syntax looks good to me. I haven't compiled it.
>
I have actually successfully compiled a C file written in a similar way
and tried with / without -Wunused-paremeter. After adding the unused
attribute gcc stopped spitting out a warning.
I don't have libvirt lying around though. That's what I didn't test.
> Acked-by: Ian Jackson
Thanks. I will push it shortly.
Wei.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxl: mark parameters in stub functions as unused
Wei Liu writes ("[PATCH] libxl: mark parameters in stub functions as unused"):
> Hopefully this can fix issues like:
>
> In file included from ../../src/libxl/xen_xl.c:24:0:
> /home/osstest/build.147035.build-amd64-libvirt/xendist/usr/local/include/libxl.h:
> In function 'libxl_cpuid_apply_policy':
> /home/osstest/build.147035.build-amd64-libvirt/xendist/usr/local/include/libxl.h:2345:56:
> error: unused parameter 'ctx' [-Werror=unused-parameter]
> static inline void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid)
> {}
>
> Fixes: dacb80f9 ("tools/libxl: Remove libxl_cpuid_{set,apply_policy}() from
> the API")
> Signed-off-by: Wei Liu
> ---
> Not able to test this locally, please review carefully...
The syntax looks good to me. I haven't compiled it.
Acked-by: Ian Jackson
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 147042: regressions - FAIL
flight 147042 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
version targeted for testing:
xen 2a03e7875837eae6ac9da375af4954780e36e448
baseline version:
xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c
Last test of basis 146882 2020-02-11 16:00:54 Z2 days
Failing since146893 2020-02-11 20:01:02 Z2 days 26 attempts
Testing same since 147030 2020-02-14 02:00:54 Z0 days3 attempts
People who touched revisions under test:
Andrew Cooper
Anthony PERARD
Ian Jackson
Jan Beulich
Juergen Gross
Julien Grall
Roger Pau Monné
Wei Liu
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt fail
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 2a03e7875837eae6ac9da375af4954780e36e448
Author: Julien Grall
Date: Thu Feb 13 12:39:06 2020 +
xen/arm: Use asm/ rather than asm-arm/ when including header
All the arch headers (i.e under asm-arm) are included using "asm/*.h".
To stay consistent, remove the only instance where "asm-arm/*.h" is
used.
Take the opportunity to move the inclusion with the rest of the asm/
include.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
commit d3cec8e1f230750a5d1b83412e8f86d0c95fcab6
Author: Wei Liu
Date: Thu Feb 13 15:27:51 2020 +
libxl: fix libxl__cpuid_legacy in libxl_nocpuid.c
Its last parameter should be libxl_domain_build_info.
Fixes: 1b3cec69 ("tools/libxl: Combine legacy CPUID handling logic")
Signed-off-by: Wei Liu
Acked-by: Anthony PERARD
commit c968e3ada478e5c9a11ba13a0f90d56323872693
Author: Anthony PERARD
Date: Thu Feb 13 13:42:00 2020 +
automation: update debian:unstable-arm64v8 to have python3-config
The Arm container wasn't updated in the original patch.
Fixes: 1a3673da6482 ("automation: updating container to have python3-config
binary")
Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
commit 1fb9a8bd8c7158eed26acb5ecd3210b82f1c31d4
Author: Juergen Gross
Date: Wed Feb 12 08:41:54 2020 +0100
xenstore: remove not applicable control commands in stubdom
When run in a stubdom environment Xenstore can't select a logfile or
emit memory statistics to a specific file.
So remove or modify those control commands accordingly.
Signed-off-by: Juergen Gross
Acked-by: Andrew Cooper
Acked-by: Wei Liu
commit a9594631b645be862857e3debbd1f04e932eb197
Author: Juergen Gross
Date: Wed Feb 12 08:41:53 2020 +0100
xenstore: add console xenstore entries for xenstore stubdom
In order to be able to connect to the console of Xenstore stubdom we
need to create the appropriate entries in Xenstore.
For the moment we don't support xenconsoled living in another domain
than dom0, as this information isn't available other then via
Xenstore which we are just setting up.
Signed-off-by: Juergen Gross
Acked-by: Andrew Cooper
Acked-by: Wei Liu
commit 5d1f9cd27eae7338bd149cc98edcf2a55468d1d3
Author: Juergen Gross
Date: Wed Feb 12 08:41:52 2020 +0100
Re: [Xen-devel] [PATCH 4/4] x86/hyperv: L0 assisted TLB flush
On Thu, Feb 13, 2020 at 01:41:27PM +0100, Roger Pau Monné wrote:
> On Thu, Feb 13, 2020 at 12:20:33PM +, Wei Liu wrote:
> > On Wed, Feb 12, 2020 at 06:43:47PM +0100, Roger Pau Monné wrote:
> > > On Wed, Feb 12, 2020 at 04:09:18PM +, Wei Liu wrote:
> > > > +static uint64_t flush_tlb_ex(const cpumask_t *mask, const void *va,
> > > > + unsigned int flags)
> > > > +{
> > > > +struct hv_tlb_flush_ex *flush = this_cpu(hv_input_page);
> > > > +int nr_banks;
> > > > +unsigned int max_gvas;
> > > > +unsigned int order = flags & FLUSH_ORDER_MASK;
> > > > +uint64_t ret;
> > > > +
> > > > +ASSERT(flush);
> > > > +ASSERT(!local_irq_is_enabled());
> > >
> > > Can you turn this into an if condition with ASSERT_UNREACHABLE and
> > > return ~0ULL? (as I think that signals an error).
> > >
> >
> > There is no need for that. This function will always be internal to
> > Hyper-V in the foreseeable future. If it is ever called with IRQ enabled
> > something is wrong with the code.
>
> But iff it ever manages to be called violating one of those conditions
> things will go badly I assume?
>
> It would be better to stay on the safe side and simply return an error
> when the conditions are no meet, and assert in the debug build.
OK.
>
> >
> > > > +
> > > > +if ( !(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED) )
> > > > +return ~0ULL;
> > > > +
> > > > +flush->address_space = 0;
> > > > +flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
> > > > +if ( !(flags & FLUSH_TLB_GLOBAL) )
> > > > +flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
> > > > +
> > > > +flush->hv_vp_set.valid_bank_mask = 0;
> > > > +flush->hv_vp_set.format = HV_GENERIC_SET_SPARSE_4K;
> > > > +
> > > > +nr_banks = cpumask_to_vpset(>hv_vp_set, mask);
> > > > +if ( nr_banks < 0 )
> > > > +return ~0ULL;
> > > > +
> > > > +max_gvas =
> > > > +(PAGE_SIZE - sizeof(*flush) - nr_banks *
> > > > + sizeof(flush->hv_vp_set.bank_contents[0])) /
> > > > +sizeof(uint64_t); /* gva is represented as uint64_t */
> > > > +
> > > > +/*
> > > > + * Flush the entire address space if va is NULL or if there is not
> > > > + * enough space for gva_list.
> > > > + */
> > > > +if ( !va || (ORDER_TO_BYTES(order) / HV_TLB_FLUSH_UNIT) > max_gvas
> > > > )
> > > > +ret =
> > > > hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX, 0,
> > > > + nr_banks, virt_to_maddr(flush), 0);
> > > > +else
> > > > +{
> > > > +uint64_t *gva_list = (uint64_t *)flush + sizeof(*flush) +
> > > > nr_banks;
> > >
> > > Don't you need nr_banks * sizeof(flush->hv_vp_set.bank_contents) in
> > > order to calculate the position of the gva_list?
> > >
> >
> > The pointer arithmetic is done on uint64_t pointers so it already takes
> > into account sizeof(bank_contents[0]).
>
> Oh, then the sizeof(*flush) should be divided by sizeof(uint64_t)?
>
Yes. I think so. Thanks for catching this.
[...]
> > > > + do_ex_hypercall:
> > > > +ret = flush_tlb_ex(mask, va, flags);
> > > > +
> > > > + done:
> > > > +local_irq_restore(irq_flags);
> > > > +
> > > > +return ret & HV_HYPERCALL_RESULT_MASK;
> > >
> > > Will this return an error code that uses the same space as Xen's errno
> > > values?
> > >
> >
> > No, it won't. It returns Hyper-V's status code (0 still means success).
> >
> > I didn't think that was a big deal because non-zero values meant errors.
> > And the upper layer didn't care about the exact error values (yet).
>
> Hm, I would rather have this return an error value in the errno.h
> range. ie:
>
> return ret & HV_HYPERCALL_RESULT_MASK ? -EINVAL : 0;
>
Sure this can be done. I would use ENXIO rather than EINVAL though.
> Or something along this lines, but long term you will need some kind
> of mapping between HyperV and Xen error codes IMO.
>
Yes. When we need more sophisticated handling of error codes.
Wei.
> Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/3] bitmap: import bitmap_{set/clear} from Linux 5.5
On Mon, Feb 10, 2020 at 12:54:04PM +, Julien Grall wrote:
>
>
> On 10/02/2020 12:32, Jan Beulich wrote:
> > On 10.02.2020 13:21, Julien Grall wrote:
> > > Hi,
> > >
> > > On 10/02/2020 11:59, Jan Beulich wrote:
> > > > On 10.02.2020 12:00, Julien Grall wrote:
> > > > > On 10/02/2020 10:28, Jan Beulich wrote:
> > > > > > On 10.02.2020 10:45, Julien Grall wrote:
> > > > > > > Please suggest a new name for BIT_WORD() and we can repurpose it.
> > > > > > > So
> > > > > > > far, I have no idea how to rename it.
> > > > > >
> > > > > > _BIT_WORD() if you/we were to accept the name space violation, or
> > > > > > BITMAP_WORD()?
> > > > >
> > > > > BITMAP_WORD() is misleading as bitmap are using unsigned long. So my
> > > > > preference is _BIT_WORD().
> > > > >
> > > > > Another alternative would be ATOMIC_WORD().
> > > >
> > > > Except that there are also non-atomic bitmap operations, I don't really
> > > > care about the name as long as it's not BIT_WORD() (or anything else
> > > > that's likely to collide with other stuff.
> > >
> > > I am afraid we are disagreing on what is colliding with what here. The
> > > naming on Arm has been like that for the past few years. While this may
> > > not have been the best choice, this is your suggestion colliding with
> > > what is existing.
> >
> > It is a plain import from Linux which has turned out impossible
> > because of the change that was done at some point to Arm code
> > which, I guess, also originally came from Linux. There's no new
> > naming I've been suggesting here at all.
>
> We never claimed we would be fully compatible with Linux and I don't think
> we could every claim it. Particularly, the bitop operations are different
> given Linux bitops are based on unsigned long.
>
> The bitop did indeed came from Linux originally, however we had to adapt
> them because Linux Armv8 bitop was expecting 8-byte aligned. This does not
> hold on Xen.
>
> >
> > > I am not entirely fussed about the namespace violation, although I think
> > > the name is potentially misleading. Yet, I would be happy to use
> > > _BIT_WORD() as this is the best of it so far.
> > >
> > > While this is code falls under Arm maintainership, I am still happy to
> > > consider other naming. But at this point, you should be the one
> > > suggesting.
> >
> > BIT_UNIT() or BITOP_UNIT() or BITOP_WORD()?
>
> BITOP_WORD().
So I assume you would like me to import bitmap_{set/clear} and use it
in the x2APIC MSR patch?
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] libxl: mark parameters in stub functions as unused
Hopefully this can fix issues like:
In file included from ../../src/libxl/xen_xl.c:24:0:
/home/osstest/build.147035.build-amd64-libvirt/xendist/usr/local/include/libxl.h:
In function 'libxl_cpuid_apply_policy':
/home/osstest/build.147035.build-amd64-libvirt/xendist/usr/local/include/libxl.h:2345:56:
error: unused parameter 'ctx' [-Werror=unused-parameter]
static inline void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid) {}
Fixes: dacb80f9 ("tools/libxl: Remove libxl_cpuid_{set,apply_policy}() from the
API")
Signed-off-by: Wei Liu
---
Not able to test this locally, please review carefully...
---
tools/libxl/libxl.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index d1d31b1e67..fde8548847 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2342,9 +2342,13 @@ int
libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list *cpuid,
* change in some cases for existing software, but there is 0 of that in
* practice.
*/
-static inline void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid) {}
-static inline void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
- libxl_cpuid_policy_list cpuid) {}
+static inline void libxl_cpuid_apply_policy(libxl_ctx *ctx
__attribute__((unused)),
+uint32_t domid
__attribute__((unused)))
+{}
+static inline void libxl_cpuid_set(libxl_ctx *ctx __attribute__((unused)),
+ uint32_t domid __attribute__((unused)),
+ libxl_cpuid_policy_list cpuid
__attribute__((unused)))
+{}
#endif
/*
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/8] xen: don't let keyhandlers block indefinitely on locks
On 13.02.2020 19:38, Andrew Cooper wrote: > On 13/02/2020 12:54, Juergen Gross wrote: >> Keyhandlers dumping hypervisor information to the console often need >> to take locks while accessing data. In order to not block in case of >> system inconsistencies it is convenient to use trylock variants when >> obtaining the locks. On the other hand a busy system might easily >> encounter held locks, so this patch series is adding special trylock >> variants with a timeout used by keyhandlers. > > This is a backwards step. > > Keyhandlers are for debugging purposes. When debugging it is far more > important to get the requested data, than almost anything else. > > The system will cope with a multi-second outage occurring approximately > never. A person debugging who can't get the data has no chance of > fixing whatever problem they are looking for. > > This series seems to be breaking the one critical usecase for > keyhandlers, to fix what - not let debugging get in the way of the > smooth running of the system? A system in need of debugging in the > first place has bigger problems than needing to run smoothly. I certainly accept what you say further up, but I don't think this last statement is universally true. There may be a single guest in trouble, which - to find out about its state - some debugging keys may want issuing. Disturbing the host and all other guests for this is not a good idea imo. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
