[Xen-devel] [linux-3.16 test] 88669: regressions - FAIL
flight 88669 linux-3.16 real [real] http://logs.test-lab.xenproject.org/osstest/logs/88669/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 85048 Tests which are failing intermittently (not blocking): test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail in 88561 pass in 88669 test-amd64-amd64-i386-pvgrub 9 debian-di-install fail pass in 88561 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 20 leak-check/check fail blocked in 85048 test-amd64-i386-xl-qemuu-win7-amd64 20 leak-check/check fail in 88561 blocked in 85048 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 88561 like 85048 build-i386-rumpuserxen6 xen-buildfail like 85048 build-amd64-rumpuserxen 6 xen-buildfail like 85048 test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail like 85048 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85048 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 85048 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 85048 test-armhf-armhf-xl-rtds 11 guest-start fail like 85048 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10 fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: linux3a96c6601b6fc47baa6d296f9111ba7be4dad6fc baseline version: linux7f2a8840d127c8d5c59a5d79235e1205aba2e102 Last test of basis85048 2016-03-02 10:56:10 Z 33 days Testing same since87897 2016-03-29 14:28:05 Z6 days7 attempts People who touched revisions under test: Akshay Bhat Al Viro Alex Deucher Alex Williamson Alexander Deucher Amir Vadai Andreas Schwab Andrey Skvortsov Andy Lutomirski Andy Shevchenko Anton Protopopov Arnd Bergmann Avery Pennarun Ben Hutchings
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
Thanks, Tim.
On 4/4/2016 4:25 PM, Tim Deegan wrote:
At 18:53 +0800 on 31 Mar (1459450418), Yu Zhang wrote:
A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
of this HVMOP can specify whether the p2m_ioreq_server is supposed
to handle write accesses or read ones or both in a parameter named
flags. For now, we only support one ioreq server for this p2m type,
so once an ioreq server has claimed its ownership, subsequent calls
of the HVMOP_map_mem_type_to_ioreq_server will fail. Users can also
disclaim the ownership of guest ram pages with this p2m type, by
triggering this new HVMOP, with ioreq server id set to the current
owner's and flags parameter set to 0.
For now, both HVMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server
are only supported for HVMs with HAP enabled.
"For now", meaning you intend to make this work on shadow pagetables? :P
If not, please just say it's HAP-only.
Well, I have no clear plan in the near future to support this on shadow
mode, and I'll change the commit message in next version. :)
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index c81302a..2e0d258 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3224,8 +3224,7 @@ static int sh_page_fault(struct vcpu *v,
}
/* Need to hand off device-model MMIO to the device model */
-if ( p2mt == p2m_mmio_dm
- || (p2mt == p2m_ioreq_server && ft == ft_demand_write) )
+if ( p2mt == p2m_mmio_dm )
{
gpa = guest_walk_to_gpa(&gw);
goto mmio;
Acked-by: Tim Deegan
Regards.
Yu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V7 1/3] x86/xsaves: fix overwriting between non-lazy/lazy xsaves
On Mon, Apr 04, 2016 at 09:51:56AM -0600, Jan Beulich wrote: > >>> On 31.03.16 at 10:57, wrote: > > xsaves will not be used until supervised state is introduced in hypervisor. > > And XSTATE_XSAVES_ONLY (indicates supervised state is understood in xen) > > is instroduced, the use of xsaves depend on whether XSTATE_XSAVES_ONLY > > There's still a spelling mistake here, despite me having pointed it out > before (you fixed one instance, but not the other). This could be > dealt with upon commit, though. Oh . "instroduced" :( > > > is set in xcr0_accum. > > Btw, I think this shouldn't be a #define, as it can - afaict - be derived > from CPUID output. Ok. >But this can easily be a follow-up patch, even one > that doesn't make it into 4.7. I do not understand your meaning clearly. Do you mean the follow-up patch ( XSTATE_XSAVES_ONLY derived from cpuid) will not into 4.7 ? If so, when is best/proper time to send out the follow-up patch ? I am not sure whether add the follow-up patch in this patchset or in a sperate patch which one is ok ? In either case I will keep working on this. > Reviewed-by: Jan Beulich > Thanks. I will send out V8 soon. > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/5] COLO fixes
On 04/05/2016 01:34 AM, Wei Liu wrote: Wei Liu (5): libxc: colo: don't leak pfns and iov in send_checkpoint_dirty_pfn_list libxl: colo: simplify colo_proxy_async_wait_for_checkpoint libxl: colo: add missing break in qemu_disk_scsi_drive_string libxl: colo: fix indentation of abort() libxl: colo: remove dead code in colo_save_setup_script_cb tools/libxc/xc_sr_restore.c | 2 ++ tools/libxl/libxl_colo_nic.c | 5 - tools/libxl/libxl_colo_save.c | 8 tools/libxl/libxl_dm.c| 3 ++- 4 files changed, 8 insertions(+), 10 deletions(-) All looks good to me. Thanks for your fix. Thanks -Xie ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/6] virt, sched: add generic vcpu pinning support
Add generic virtualization support for pinning the current vcpu to a
specified physical cpu. As this operation isn't performance critical
(a very limited set of operations like BIOS calls and SMIs is expected
to need this) just add a hypervisor specific indirection.
Signed-off-by: Juergen Gross
---
V4: move this patch some places up in the series
WARN_ONCE in case platform doesn't support pinning as requested by
Peter Zijlstra
V3: use getc_cpu()/put_cpu() as suggested by David Vrabel
V2: adapt to using workqueues
add include/linux/hypervisor.h to hide architecture specific stuff
from generic kernel code
In case paravirt maintainers don't want to be responsible for
include/linux/hypervisor.h I could take it.
---
MAINTAINERS | 1 +
arch/x86/include/asm/hypervisor.h | 4
arch/x86/kernel/cpu/hypervisor.c | 11 +++
include/linux/hypervisor.h| 17 +
kernel/smp.c | 1 +
kernel/up.c | 1 +
6 files changed, 35 insertions(+)
create mode 100644 include/linux/hypervisor.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 2ec5079..959173e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8330,6 +8330,7 @@ S:Supported
F: Documentation/virtual/paravirt_ops.txt
F: arch/*/kernel/paravirt*
F: arch/*/include/asm/paravirt.h
+F: include/linux/hypervisor.h
PARIDE DRIVERS FOR PARALLEL PORT IDE DEVICES
M: Tim Waugh
diff --git a/arch/x86/include/asm/hypervisor.h
b/arch/x86/include/asm/hypervisor.h
index 055ea99..67942b6 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -43,6 +43,9 @@ struct hypervisor_x86 {
/* X2APIC detection (run once per boot) */
bool(*x2apic_available)(void);
+
+ /* pin current vcpu to specified physical cpu (run rarely) */
+ void(*pin_vcpu)(int);
};
extern const struct hypervisor_x86 *x86_hyper;
@@ -56,6 +59,7 @@ extern const struct hypervisor_x86 x86_hyper_kvm;
extern void init_hypervisor(struct cpuinfo_x86 *c);
extern void init_hypervisor_platform(void);
extern bool hypervisor_x2apic_available(void);
+extern void hypervisor_pin_vcpu(int cpu);
#else
static inline void init_hypervisor(struct cpuinfo_x86 *c) { }
static inline void init_hypervisor_platform(void) { }
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 73d391a..ff108f8 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -85,3 +85,14 @@ bool __init hypervisor_x2apic_available(void)
x86_hyper->x2apic_available &&
x86_hyper->x2apic_available();
}
+
+void hypervisor_pin_vcpu(int cpu)
+{
+ if (!x86_hyper)
+ return;
+
+ if (x86_hyper->pin_vcpu)
+ x86_hyper->pin_vcpu(cpu);
+ else
+ WARN_ONCE(1, "vcpu pinning requested but not supported!\n");
+}
diff --git a/include/linux/hypervisor.h b/include/linux/hypervisor.h
new file mode 100644
index 000..3fa5ef2
--- /dev/null
+++ b/include/linux/hypervisor.h
@@ -0,0 +1,17 @@
+#ifndef __LINUX_HYPEVISOR_H
+#define __LINUX_HYPEVISOR_H
+
+/*
+ * Generic Hypervisor support
+ * Juergen Gross
+ */
+
+#ifdef CONFIG_HYPERVISOR_GUEST
+#include
+#else
+static inline void hypervisor_pin_vcpu(int cpu)
+{
+}
+#endif
+
+#endif /* __LINUX_HYPEVISOR_H */
diff --git a/kernel/smp.c b/kernel/smp.c
index 7416544..9388064 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "smpboot.h"
diff --git a/kernel/up.c b/kernel/up.c
index 1760bf3..3ccee2b 100644
--- a/kernel/up.c
+++ b/kernel/up.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
int wait)
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 4/6] xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu
Some hardware models (e.g. Dell Studio 1555 laptops) require calls to
the firmware to be issued on cpu 0 only. As Dom0 might have to use
these calls, add xen_pin_vcpu() to achieve this functionality.
In case either the domain doesn't have the privilege to make the
related hypercall or the hypervisor isn't supporting it, issue a
warning once and disable further pinning attempts.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten.c | 40
1 file changed, 40 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 880862c..7907bcf8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1885,6 +1885,45 @@ static void xen_set_cpu_features(struct cpuinfo_x86 *c)
}
}
+static void xen_pin_vcpu(int cpu)
+{
+ static bool disable_pinning;
+ struct sched_pin_override pin_override;
+ int ret;
+
+ if (disable_pinning)
+ return;
+
+ pin_override.pcpu = cpu;
+ ret = HYPERVISOR_sched_op(SCHEDOP_pin_override, &pin_override);
+ if (cpu < 0)
+ return;
+
+ switch (ret) {
+ case -ENOSYS:
+ pr_warn("The kernel tried to call a function on physical cpu
%d, but Xen isn't\n"
+ "supporting this. In case of problems you might
consider vcpu pinning.\n",
+ cpu);
+ disable_pinning = true;
+ break;
+ case -EPERM:
+ WARN(1, "Trying to pin vcpu without having privilege to do
so\n");
+ disable_pinning = true;
+ break;
+ case -EINVAL:
+ case -EBUSY:
+ pr_warn("The kernel tried to call a function on physical cpu
%d, but this cpu\n"
+ "seems not to be available. Please check your Xen cpu
configuration.\n",
+ cpu);
+ break;
+ case 0:
+ break;
+ default:
+ WARN(1, "rc %d while trying to pin vcpu\n", ret);
+ disable_pinning = true;
+ }
+}
+
const struct hypervisor_x86 x86_hyper_xen = {
.name = "Xen",
.detect = xen_platform,
@@ -1893,6 +1932,7 @@ const struct hypervisor_x86 x86_hyper_xen = {
#endif
.x2apic_available = xen_x2apic_para_available,
.set_cpu_features = xen_set_cpu_features,
+ .pin_vcpu = xen_pin_vcpu,
};
EXPORT_SYMBOL(x86_hyper_xen);
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k
Use the smp_call_on_cpu() function to call system management
mode on cpu 0.
Make call secure by adding get_online_cpus() to avoid e.g. suspend
resume cycles in between.
Signed-off-by: Juergen Gross
---
V4: add call to get_online_cpus()
---
drivers/hwmon/dell-smm-hwmon.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
index c43318d..643f3a1 100644
--- a/drivers/hwmon/dell-smm-hwmon.c
+++ b/drivers/hwmon/dell-smm-hwmon.c
@@ -21,6 +21,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
#include
#include
#include
@@ -35,6 +36,7 @@
#include
#include
#include
+#include
#include
@@ -130,23 +132,15 @@ static inline const char *i8k_get_dmi_data(int field)
/*
* Call the System Management Mode BIOS. Code provided by Jonathan Buzzard.
*/
-static int i8k_smm(struct smm_regs *regs)
+static int i8k_smm_func(void *par)
{
int rc;
+ struct smm_regs *regs = par;
int eax = regs->eax;
- cpumask_var_t old_mask;
/* SMM requires CPU 0 */
- if (!alloc_cpumask_var(&old_mask, GFP_KERNEL))
- return -ENOMEM;
- cpumask_copy(old_mask, ¤t->cpus_allowed);
- rc = set_cpus_allowed_ptr(current, cpumask_of(0));
- if (rc)
- goto out;
- if (smp_processor_id() != 0) {
- rc = -EBUSY;
- goto out;
- }
+ if (smp_processor_id() != 0)
+ return -EBUSY;
#if defined(CONFIG_X86_64)
asm volatile("pushq %%rax\n\t"
@@ -204,13 +198,24 @@ static int i8k_smm(struct smm_regs *regs)
if (rc != 0 || (regs->eax & 0x) == 0x || regs->eax == eax)
rc = -EINVAL;
-out:
- set_cpus_allowed_ptr(current, old_mask);
- free_cpumask_var(old_mask);
return rc;
}
/*
+ * Call the System Management Mode BIOS.
+ */
+static int i8k_smm(struct smm_regs *regs)
+{
+ int ret;
+
+ get_online_cpus();
+ ret = smp_call_on_cpu(0, true, i8k_smm_func, regs);
+ put_online_cpus();
+
+ return ret;
+}
+
+/*
* Read the fan status.
*/
static int i8k_get_fan_status(int fan)
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 0/6] Support calling functions on dedicated physical cpu
Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This patch series is adding a generic function to be able to temporarily pin a (virtual) cpu to a dedicated physical cpu for executing above mentioned functions on that specific cpu. The drivers (dcdbas and i8k) requiring this functionality are modified accordingly. Changes in V4: - move patches 5 and 6 further up in the series - patch 2 (was 5): WARN_ONCE in case platform doesn't support pinning as requested by Peter Zijlstra - patch 3 (was 2): change return value in case of illegal cpu as requested by Peter Zijlstra - patch 3 (was 2): make pinning of vcpu an option as suggested by Peter Zijlstra - patches 5 and 6 (were 3 and 4): add call to get_online_cpus() Changes in V3: - use get_cpu()/put_cpu() as suggested by David Vrabel Changes in V2: - instead of manipulating the allowed set of cpus use cpu specific workqueue as requested by Peter Zijlstra - add include/linux/hypervisor.h to hide architecture specific stuff from generic kernel code Juergen Gross (6): xen: sync xen header virt, sched: add generic vcpu pinning support smp: add function to execute a function synchronously on a cpu xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu dcdbas: make use of smp_call_on_cpu() hwmon: use smp_call_on_cpu() for dell-smm i8k MAINTAINERS | 1 + arch/x86/include/asm/hypervisor.h | 4 ++ arch/x86/kernel/cpu/hypervisor.c | 11 + arch/x86/xen/enlighten.c | 40 +++ drivers/firmware/dcdbas.c | 51 +-- drivers/hwmon/dell-smm-hwmon.c| 35 +++-- include/linux/hypervisor.h| 17 +++ include/linux/smp.h | 2 + include/xen/interface/sched.h | 100 +++--- kernel/smp.c | 51 +++ kernel/up.c | 18 +++ 11 files changed, 272 insertions(+), 58 deletions(-) create mode 100644 include/linux/hypervisor.h -- 2.6.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/6] smp: add function to execute a function synchronously on a cpu
On some hardware models (e.g. Dell Studio 1555 laptop) some hardware
related functions (e.g. SMIs) are to be executed on physical cpu 0
only. Instead of open coding such a functionality multiple times in
the kernel add a service function for this purpose. This will enable
the possibility to take special measures in virtualized environments
like Xen, too.
Signed-off-by: Juergen Gross
---
V4: change return value in case of illegal cpu as requested by Peter Zijlstra
make pinning of vcpu an option as suggested by Peter Zijlstra
V2: instead of manipulating the allowed set of cpus use cpu specific
workqueue as requested by Peter Zijlstra
---
include/linux/smp.h | 2 ++
kernel/smp.c| 50 ++
kernel/up.c | 17 +
3 files changed, 69 insertions(+)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index c441407..3b5813b 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -196,4 +196,6 @@ extern void arch_enable_nonboot_cpus_end(void);
void smp_setup_processor_id(void);
+int smp_call_on_cpu(unsigned int cpu, bool pin, int (*func)(void *), void
*par);
+
#endif /* __LINUX_SMP_H */
diff --git a/kernel/smp.c b/kernel/smp.c
index 9388064..357458b 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -740,3 +740,53 @@ void wake_up_all_idle_cpus(void)
preempt_enable();
}
EXPORT_SYMBOL_GPL(wake_up_all_idle_cpus);
+
+/**
+ * smp_call_on_cpu - Call a function on a specific cpu
+ *
+ * Used to call a function on a specific cpu and wait for it to return.
+ * Optionally make sure the call is done on a specified physical cpu via vcpu
+ * pinning in order to support virtualized environments.
+ */
+struct smp_call_on_cpu_struct {
+ struct work_struct work;
+ struct completion done;
+ int (*func)(void *);
+ void*data;
+ int ret;
+ int cpu;
+};
+
+static void smp_call_on_cpu_callback(struct work_struct *work)
+{
+ struct smp_call_on_cpu_struct *sscs;
+
+ sscs = container_of(work, struct smp_call_on_cpu_struct, work);
+ if (sscs->cpu >= 0)
+ hypervisor_pin_vcpu(sscs->cpu);
+ sscs->ret = sscs->func(sscs->data);
+ if (sscs->cpu >= 0)
+ hypervisor_pin_vcpu(-1);
+
+ complete(&sscs->done);
+}
+
+int smp_call_on_cpu(unsigned int cpu, bool pin, int (*func)(void *), void *par)
+{
+ struct smp_call_on_cpu_struct sscs = {
+ .work = __WORK_INITIALIZER(sscs.work, smp_call_on_cpu_callback),
+ .done = COMPLETION_INITIALIZER_ONSTACK(sscs.done),
+ .func = func,
+ .data = par,
+ .cpu = pin ? cpu : -1,
+ };
+
+ if (cpu >= nr_cpu_ids)
+ return -ENXIO;
+
+ queue_work_on(cpu, system_wq, &sscs.work);
+ wait_for_completion(&sscs.done);
+
+ return sscs.ret;
+}
+EXPORT_SYMBOL_GPL(smp_call_on_cpu);
diff --git a/kernel/up.c b/kernel/up.c
index 3ccee2b..8266810b 100644
--- a/kernel/up.c
+++ b/kernel/up.c
@@ -83,3 +83,20 @@ void on_each_cpu_cond(bool (*cond_func)(int cpu, void *info),
preempt_enable();
}
EXPORT_SYMBOL(on_each_cpu_cond);
+
+int smp_call_on_cpu(unsigned int cpu, bool pin, int (*func)(void *), void *par)
+{
+ int ret;
+
+ if (cpu != 0)
+ return -ENXIO;
+
+ if (pin)
+ hypervisor_pin_vcpu(0);
+ ret = func(par);
+ if (pin)
+ hypervisor_pin_vcpu(-1);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(smp_call_on_cpu);
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 5/6] dcdbas: make use of smp_call_on_cpu()
Use smp_call_on_cpu() to raise SMI on cpu 0.
Make call secure by adding get_online_cpus() to avoid e.g. suspend
resume cycles in between.
Signed-off-by: Juergen Gross
---
V4: add call to get_online_cpus()
---
drivers/firmware/dcdbas.c | 51 ---
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 829eec8..68e1d38 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -238,33 +239,14 @@ static ssize_t host_control_on_shutdown_store(struct
device *dev,
return count;
}
-/**
- * dcdbas_smi_request: generate SMI request
- *
- * Called with smi_data_lock.
- */
-int dcdbas_smi_request(struct smi_cmd *smi_cmd)
+static int raise_smi(void *par)
{
- cpumask_var_t old_mask;
- int ret = 0;
+ struct smi_cmd *smi_cmd = par;
- if (smi_cmd->magic != SMI_CMD_MAGIC) {
- dev_info(&dcdbas_pdev->dev, "%s: invalid magic value\n",
-__func__);
- return -EBADR;
- }
-
- /* SMI requires CPU 0 */
- if (!alloc_cpumask_var(&old_mask, GFP_KERNEL))
- return -ENOMEM;
-
- cpumask_copy(old_mask, ¤t->cpus_allowed);
- set_cpus_allowed_ptr(current, cpumask_of(0));
if (smp_processor_id() != 0) {
dev_dbg(&dcdbas_pdev->dev, "%s: failed to get CPU 0\n",
__func__);
- ret = -EBUSY;
- goto out;
+ return -EBUSY;
}
/* generate SMI */
@@ -280,9 +262,28 @@ int dcdbas_smi_request(struct smi_cmd *smi_cmd)
: "memory"
);
-out:
- set_cpus_allowed_ptr(current, old_mask);
- free_cpumask_var(old_mask);
+ return 0;
+}
+/**
+ * dcdbas_smi_request: generate SMI request
+ *
+ * Called with smi_data_lock.
+ */
+int dcdbas_smi_request(struct smi_cmd *smi_cmd)
+{
+ int ret;
+
+ if (smi_cmd->magic != SMI_CMD_MAGIC) {
+ dev_info(&dcdbas_pdev->dev, "%s: invalid magic value\n",
+__func__);
+ return -EBADR;
+ }
+
+ /* SMI requires CPU 0 */
+ get_online_cpus();
+ ret = smp_call_on_cpu(0, true, raise_smi, smi_cmd);
+ put_online_cpus();
+
return ret;
}
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/6] xen: sync xen header
Import the actual version of include/xen/interface/sched.h from Xen.
Signed-off-by: Juergen Gross
---
include/xen/interface/sched.h | 100 ++
1 file changed, 82 insertions(+), 18 deletions(-)
diff --git a/include/xen/interface/sched.h b/include/xen/interface/sched.h
index f184909..a4c4d73 100644
--- a/include/xen/interface/sched.h
+++ b/include/xen/interface/sched.h
@@ -3,6 +3,24 @@
*
* Scheduler state interactions
*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
* Copyright (c) 2005, Keir Fraser
*/
@@ -12,18 +30,30 @@
#include
/*
+ * Guest Scheduler Operations
+ *
+ * The SCHEDOP interface provides mechanisms for a guest to interact
+ * with the scheduler, including yield, blocking and shutting itself
+ * down.
+ */
+
+/*
* The prototype for this hypercall is:
- * long sched_op_new(int cmd, void *arg)
+ * long HYPERVISOR_sched_op(enum sched_op cmd, void *arg, ...)
+ *
* @cmd == SCHEDOP_??? (scheduler operation).
* @arg == Operation-specific extra argument(s), as described below.
+ * ... == Additional Operation-specific extra arguments, described below.
*
- * **NOTE**:
- * Versions of Xen prior to 3.0.2 provide only the following legacy version
+ * Versions of Xen prior to 3.0.2 provided only the following legacy version
* of this hypercall, supporting only the commands yield, block and shutdown:
* long sched_op(int cmd, unsigned long arg)
* @cmd == SCHEDOP_??? (scheduler operation).
* @arg == 0 (SCHEDOP_yield and SCHEDOP_block)
* == SHUTDOWN_* code (SCHEDOP_shutdown)
+ *
+ * This legacy version is available to new guests as:
+ * long HYPERVISOR_sched_op_compat(enum sched_op cmd, unsigned long arg)
*/
/*
@@ -44,12 +74,17 @@
/*
* Halt execution of this domain (all VCPUs) and notify the system controller.
* @arg == pointer to sched_shutdown structure.
+ *
+ * If the sched_shutdown_t reason is SHUTDOWN_suspend then
+ * x86 PV guests must also set RDX (EDX for 32-bit guests) to the MFN
+ * of the guest's start info page. RDX/EDX is the third hypercall
+ * argument.
+ *
+ * In addition, which reason is SHUTDOWN_suspend this hypercall
+ * returns 1 if suspend was cancelled or the domain was merely
+ * checkpointed, and 0 if it is resuming in a new domain.
*/
#define SCHEDOP_shutdown2
-struct sched_shutdown {
-unsigned int reason; /* SHUTDOWN_* */
-};
-DEFINE_GUEST_HANDLE_STRUCT(sched_shutdown);
/*
* Poll a set of event-channel ports. Return when one or more are pending. An
@@ -57,12 +92,6 @@ DEFINE_GUEST_HANDLE_STRUCT(sched_shutdown);
* @arg == pointer to sched_poll structure.
*/
#define SCHEDOP_poll3
-struct sched_poll {
-GUEST_HANDLE(evtchn_port_t) ports;
-unsigned int nr_ports;
-uint64_t timeout;
-};
-DEFINE_GUEST_HANDLE_STRUCT(sched_poll);
/*
* Declare a shutdown for another domain. The main use of this function is
@@ -71,15 +100,11 @@ DEFINE_GUEST_HANDLE_STRUCT(sched_poll);
* @arg == pointer to sched_remote_shutdown structure.
*/
#define SCHEDOP_remote_shutdown4
-struct sched_remote_shutdown {
-domid_t domain_id; /* Remote domain ID */
-unsigned int reason; /* SHUTDOWN_xxx reason */
-};
/*
* Latch a shutdown code, so that when the domain later shuts down it
* reports this code to the control tools.
- * @arg == as for SCHEDOP_shutdown.
+ * @arg == sched_shutdown, as for SCHEDOP_shutdown.
*/
#define SCHEDOP_shutdown_code 5
@@ -92,10 +117,47 @@ struct sched_remote_shutdown {
* With id != 0 and timeout != 0, poke watchdog timer and set new timeout.
*/
#define SCHEDOP_watchdog6
+
+/*
+ * Override the current vcpu affinity by pinning it to one physical cpu or
+ * undo this override restoring the previous affinity.
+ * @arg == pointer to sched_pin_override structure.
+ *
+ * A negative pcpu value will undo a previous pin override and restore the
+ * previous cpu affinity.
+ * T
[Xen-devel] [qemu-mainline test] 88667: regressions - FAIL
flight 88667 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/88667/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 86454 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 86454 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 86454 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-installfail REGR. vs. 86454 test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-qemuu-rhel6hvm-amd 9 redhat-install fail REGR. vs. 86454 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 86454 test-armhf-armhf-libvirt-qcow2 6 xen-bootfail REGR. vs. 86454 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86454 test-armhf-armhf-xl-rtds 11 guest-start fail like 86454 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 86454 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuu9d227f194dc7d3f9c8fee48444e7a1db38b33500 baseline version: qemuud1f8764099022bc1173f2413331b26d4ff609a0c Last test of basis86454 2016-03-17 06:01:30 Z 18 days Failing since 86547 2016-03-18 07:12:41 Z 17 days 20 attempts Testing same since88667 2016-04-04 13:30:21 Z0 days1 attempts People who touched revisions under test: Alberto Garcia Alex Bennée Alex Williamson Alexey Kardashevskiy Andrew Baumann Anthony Perard Bandan Das Bastian Koppelmann Benjamin Herrenschmidt Christophe Fergeau Cornelia Huck Cédric Le Goater Daniel P. Berrange David Gibson Denis V. Lunev Dr. David Alan Gilbert Eduardo Habkost Eric Blake Eugene (jno
Re: [Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions
On 04/04/16 18:48, Boris Ostrovsky wrote: > On 04/04/2016 12:30 PM, David Vrabel wrote: >> On 04/04/16 17:21, Julien Grall wrote: >>> (CC Stefano new e-mail address) >>> >>> Hello Anna-Maria, >>> >>> On 04/04/2016 13:32, Anna-Maria Gleixner wrote: Xen guests do not offline/online CPUs during suspend/resume and therefore FROZEN notifier transitions are not required. Add this explanation as a comment in the code to get not confused why CPU_TASKS_FROZEN masked transitions are not considered. >> Alternatively, these could be added even if they are not encountered. >> This might be more future-proof but the documentation might be clearer. >> >> Boris, Juergen, any opinion? I'd rather do more than a comment: Either mask CPU_TASKS_FROZEN from action if it really doesn't matter whether the flag is set or not (which IMHO is the case here), or BUG_ON(action & CPU_TASKS_FROZEN) if this really should never happen. > Wouldn't the same comment need to be added to xen_hvm_cpu_notify()? The patch of Anna-Maria does that. Juergen > > > -boris > > >> >> David>> --- a/drivers/xen/events/events_fifo.c +++ b/drivers/xen/events/events_fifo.c @@ -425,6 +425,12 @@ static int evtchn_fifo_cpu_notification( int cpu = (long)hcpu; int ret = 0; +/* + * Xen guests do not offline/online CPUs during + * suspend/resume, thus CPU_TASKS_FROZEN masked transitions + * are not considered. +*/ >>> NIT: The '*' is not aligned with the others. >> If this doesn't need any other changes, I'll fix this on commit. >> >> David > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Adding Xen to the kbuild bot?
On Wed, Feb 17, 2016 at 12:46 PM, Andy Lutomirski wrote: > On Fri, Feb 5, 2016 at 5:17 PM, Fengguang Wu wrote: >> On Fri, Feb 05, 2016 at 12:10:56PM -0800, Andy Lutomirski wrote: >>> On Feb 4, 2016 7:11 PM, "Fengguang Wu" wrote: >>> > >>> > Hi Andy, >>> > >>> > CC more people on Xen testing -- in case OSStest already (or plans to) >>> > cover such test case. >>> > >>> > On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote: >>> > > Hi all- >>> > > >>> > > Would it make sense to add some basic Xen PV testing to the kbuild bot? >>> > >>> > Do you mean to run basic Xen testing on the various kernel trees that >>> > 0day robot covers? That is, to catch kernel regressions when running >>> > under Xen. >>> > >>> >>> Yes, exactly. I've personally broken Linux as a Xen guest at least twice. >>> >>> > If the intention is to catch Xen regressions, the OSStest >>> > infrastructure may be a better option: >>> > >>> > git://xenbits.xen.org/osstest.git >>> >>> No, I think that 0day should pick one Xen version and stick with it >>> for a while rather than trying to track the latest version. >> >> OK, got it. So it's suitable to run in 0day. >> >>> > > qemu can boot Xen like this: >>> > > >>> > > qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage >>> > > kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg' >>> > > >>> > > This should work with any kernel image for x86 or x86_64 with >>> > > CONFIG_XEN=y. >>> > >>> > Got it. If you have simple working test scripts to illustrate test >>> > details, it'd be a great help for integrating into OSStest or 0day. >>> >>> I have a script that will boot to a command prompt, but I don't know >>> if that's the right way to do it. I'm not really sure how 0day works >>> under the hood, but treating Xen as a different configuration or arch >>> instead of treating it as a different test case might make more sense. >> >> We can check the script first, then determine the most suitable way to >> integrate it into 0day. My guess is, it might be suitable to run as a >> new kind of VM host, like this >> >> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/hosts/vm-kbuild-1G >> >> model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap >> nr_vm: 12 >> nr_cpu: 2 >> memory: 1G >> disk_type: virtio-scsi >> rootfs: debian-x86_64.cgz >> hdd_partitions: /dev/sda /dev/sdb /dev/sdc /dev/sdd >> swap_partitions: /dev/sde > > This makes sense to me, but I think it would need an extension to the > configuration language. > > The guest virtio code should be in the next -next release. > FWIW, 4.6-rc1 works when booted via Xen on QEMU/KVM with virtio out of the box. --Andy ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] kernel-parameters: document earlycon=xenboot
Add earlycon=xenboot option to Documentation/kernel-parameters.txt. Signed-off-by: Chris Patterson --- Documentation/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index ecc74fa..e01ec39 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1078,6 +1078,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. address. The serial port must already be setup and configured. Options are not yet supported. + xenboot Use Xen hypervisor console for early console. + earlyprintk=[X86,SH,BLACKFIN,ARM,M68k] earlyprintk=vga earlyprintk=efi -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 88655: regressions - FAIL
flight 88655 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/88655/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 59254 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-i386-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 59254 test-amd64-i386-xl 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 11 guest-start fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254 test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 59254 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-armhf-armhf-xl-vhd 9 debian-di-install fail baseline untested test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass version targeted for testing: linux9735a22799b9214d17d3c231fe377fc852f042e9 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 270 days F
Re: [Xen-devel] [PATCH v5 10/28] xsplice: Implement payload loading
On Mon, Apr 04, 2016 at 03:44:44PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 01, 2016 at 03:18:45AM -0600, Jan Beulich wrote:
> > >>> On 31.03.16 at 23:26, wrote:
> > >> Also - how well will this O(n^2) lookup work once there are enough
> > >> payloads? I think this calls for the alternative vmap() extension I've
> > >> been suggesting earlier.
> > >
> > > Could you elaborate on the vmap extension a bit please?
> > >
> > > Your earlier email seems to say: drop the vmap API and just
> > > allocate the underlaying pages yourself.
> >
> > Actually I had also said in that earlier mail: "If, otoh, you left that
> > VA management to (an extended version of) vmap(), by e.g.
> > allowing the caller to request allocation from a different VA range
> > (much like iirc x86-64 Linux handles its modules address range
> > allocation), things would be different. After all the VA
> > management is the important part here, while the backing
> > memory allocation is just a trivial auxiliary operation."
> >
> > I.e. elaboration here really just consists of the referral to the
> > respective Linux approach.
>
> I am in need here of guidance I am afraid.
>
> Let me explain (did this in IRC but this will have a broader scope):
>
> In Linux we have the 'struct vm_area' which internally contains the start
> and end address (amongst other things). The callers usually use
> __vmalloc_node_range
> to an provide those addresses. Internally the vmalloc API allocates the
> 'struct vm_area' from the normal SLAB allocator. Vmalloc API also has an
> vmap block area (allocated within vmalloc area) which is a red and black tree
> for all the users of its API. When vm_size() is called this tree is searched
> to find the 'vm_area' for the provided virtual address. There is a lot
> of code in this. Copying it and jamming does not look easy so it would be
> better to take concepts of this an implement this..
>
>
> On Xen we setup a bitmap that covers the full vmalloc area (128MB on my
> 4GB box, but can go up to 64GB) - the 128MB vmalloc area requires about
> 32K bits.
>
> For every allocation we "waste" an page (and a bit) so that there is a gap.
> This gap is needed when trying to to determine the size of the allocated
> region - when scanning the bitmap we can easily figure out the cleared
> bit which is akin to a fencepost.
>
>
> To make Xen's vmalloc API be generic I need to wholesale make it able
> to deal with virtual addresses that are not part of its space (as in
> not in VMAP_VIRT_START to vm_top). At the start I the input to vm_size()
> needs to get the size of the virtual address (either the ones from
> the vmalloc areas or the ones provided earlier by vmalloc_cb).
>
> One easy mechanism is to embedded an array of simplified 'struct vm_area'
> structure:
>
> struct vm_area {
> unsigned long va;
> }
>
> for every slot in the VMAP_VIRT_START area (that is have 32K entries).
> The vm_size and all the rest can check for this array if the virtual
> address provided is not within the vmalloc virtual addresses. If there
> is a match we just need to consult the vm_bitmap at the same index and
> figure out where the empty bit is set.
> The downside is that I've to walk the full array (32K entries).
>
> But when you think about it - most of the time we use normal vmalloc addresses
> and only in exceptional cases do we need the alternate ones. And the only
> reason
> to keep track of it is to know the size.
>
> The easier way would be to track them via a linked list:
>
> struct vm_area {
> struct list_head list;
> unsigned long va;
> size_t nr;
> }
>
> And vm_size, vm_index, etc would consult this list for the virtual address and
> could get the proper information. (See inline patch)
>
> But if we are doing that this, then why even put it in the vmalloc API? Why
> not
> track all of this with the user of this? (like it was done in v4 of this
> patch series?)
>
> Please advise.
I re-read your previous email and I think you were leaning
towards not even having a callback but rather supplying
the virtual address to the vmalloc APIs and it tracking
it afterwards. Like this:
From 738ed247bf214a061c6822ad183c365a4f5731b9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Mon, 14 Mar 2016 12:02:05 -0400
Subject: [PATCH] vmap: Add vmalloc_range
For those users who want to supply their own virtual
address for which to allocate the underlaying pages.
The vmap API also keeps track of this virtual address (along
with the size) so that vunmap, vm_size, and vm_free can operate
on these virtual addresses.
This allows users (such as xSplice) to provide their own
mechanism to change the the page flags, and also use virtual
addresses closer to the hypervisor virtual addresses (at least
on x86) while not having to deal with the allocation of
pages.
For example of users, see patch titled "xsplice: Implement payload
loading".
Note that the displacement of the hypervisor virtual addresses
Re: [Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS
On Mon, Apr 4, 2016 at 9:07 PM, Chong Li wrote:
> Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced
> a bug: it made it possible, in Credit and Credit2, when doing domain
> or vcpu parameters' manipulation, to leave the hypervisor with a
> spinlock held and interrupts disabled.
>
> Fix it.
>
> Signed-off-by: Chong Li
>
> Acked-by: Dario Faggioli
I'm wondering if the title "xen: enable per-VCPU parameter for RTDS"
is suitable for this patch, although I don't have a better title.
The title in my mind is: xen: fix incorrect lock for credit and credit2
I won't fight for this title, though. :-)
Probably no need to resend...
Thanks,
Meng
--
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] pv-grub guest booting fail with recent qemu-xen
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Konrad
> Rzeszutek Wilk
> Sent: Friday, April 1, 2016 11:55 PM
> To: Hao, Xudong
> Cc: samuel.thiba...@ens-lyon.org; xen-devel@lists.xen.org; Wei Liu
> ; stefano.stabell...@eu.citrix.com
> Subject: Re: [Xen-devel] pv-grub guest booting fail with recent qemu-xen
>
> On Wed, Mar 30, 2016 at 02:05:28AM +, Hao, Xudong wrote:
> > > -Original Message-
> > > From: Wei Liu [mailto:wei.l...@citrix.com]
> > > Sent: Wednesday, March 30, 2016 12:58 AM
> > > To: Konrad Rzeszutek Wilk
> > > Cc: Hao, Xudong ; wei.l...@citrix.com;
> > > samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com; xen-
> > > de...@lists.xen.org
> > > Subject: Re: [Xen-devel] pv-grub guest booting fail with recent
> > > qemu-xen
> > >
> > > On Mon, Mar 28, 2016 at 09:21:14AM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Mar 28, 2016 at 02:03:35AM +, Hao, Xudong wrote:
> > > > > > -Original Message-
> > > > > > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On
> > > > > > Behalf Of Konrad Rzeszutek Wilk
> > > > > > Sent: Saturday, March 26, 2016 2:58 AM
> > > > > > To: Hao, Xudong
> > > > > > Cc: stefano.stabell...@eu.citrix.com; xen-devel@lists.xen.org
> > > > > > Subject: Re: [Xen-devel] pv-grub guest booting fail with
> > > > > > recent qemu-xen
> > > > > >
> > > > > > On Wed, Mar 02, 2016 at 07:16:40AM +, Hao, Xudong wrote:
> > > > > > > Hi,
> > > > > > > For Xen upstream master branch with commit 1949868d, After
> > > > > > > updating qemu-
> > > > > > xen version from fcf6ac57 to 2ce1d30e, booting a pv-grub guest will
> fail.
> > > >
> > >
> > > pv-grub should be using qemu-traditional, not qemu-xen
> > >
> >
> > Never hear this limitation.
> >
> > > The log message you posted in your original post doesn't seem to reveal
> much.
> > > Can you have a look at relevant QEMU logs under /var/log/xen?
> >
> > There is not valuable qemu log, only one line: "qemu: terminating on signal
> > 1
> from pid 36642".
> >
> > Bisect and the bad commit of qemu-xen is:
>
> If you use PV-grub without the framebuffer does it boot?
How to disable framebuffer when VM booting.
Reverted this patch, PV-grub guest boot successfully.
>
>
> >
> > commit 2ce1d30ef2858dfed72a281872579e5a26b090dd
> > Author: Stefano Stabellini
> > Date: Wed Jan 6 16:32:22 2016 +
> >
> > xenfb.c: avoid expensive loops when prod <= out_cons
> >
> > If the frontend sets out_cons to a value higher than out_prod, it will
> > cause xenfb_handle_events to loop about 2^32 times. Avoid that by using
> > better checks at the beginning of the function.
> >
> > upstream-commit-id: ac0487e1d2ae811cd4d035741a109a4ecfb013f1
> >
> > Signed-off-by: Stefano Stabellini
> > Reported-by: Ling Liu
> >
> > diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c index
> > 4e2a27a..8eb3046 100644
> > --- a/hw/display/xenfb.c
> > +++ b/hw/display/xenfb.c
> > @@ -789,8 +789,9 @@ static void xenfb_handle_events(struct XenFB
> > *xenfb)
> >
> > prod = page->out_prod;
> > out_cons = page->out_cons;
> > -if (prod == out_cons)
> > - return;
> > +if (prod - out_cons >= XENFB_OUT_RING_LEN) {
> > +return;
> > +}
> > xen_rmb(); /* ensure we see ring contents up to prod */
> > for (cons = out_cons; cons != prod; cons++) {
> > union xenfb_out_event *event = &XENFB_OUT_RING_REF(page,
> > cons);
> >
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS
Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced
a bug: it made it possible, in Credit and Credit2, when doing domain
or vcpu parameters' manipulation, to leave the hypervisor with a
spinlock held and interrupts disabled.
Fix it.
Signed-off-by: Chong Li
Acked-by: Dario Faggioli
---
CC:
CC:
CC:
CC:
CC:
CC:
---
xen/common/sched_credit.c | 6 --
xen/common/sched_credit2.c | 6 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index e5d15d8..4c4927f 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1075,6 +1075,7 @@ csched_dom_cntl(
struct csched_dom * const sdom = CSCHED_DOM(d);
struct csched_private *prv = CSCHED_PRIV(ops);
unsigned long flags;
+int rc = 0;
/* Protect both get and put branches with the pluggable scheduler
* lock. Runq lock not needed anywhere in here. */
@@ -1101,12 +1102,13 @@ csched_dom_cntl(
sdom->cap = op->u.credit.cap;
break;
default:
-return -EINVAL;
+rc = -EINVAL;
+break;
}
spin_unlock_irqrestore(&prv->lock, flags);
-return 0;
+return rc;
}
static inline void
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index d48ed5a..b8c8e40 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1416,6 +1416,7 @@ csched2_dom_cntl(
struct csched2_dom * const sdom = CSCHED2_DOM(d);
struct csched2_private *prv = CSCHED2_PRIV(ops);
unsigned long flags;
+int rc = 0;
/* Must hold csched2_priv lock to read and update sdom,
* runq lock to update csvcs. */
@@ -1457,12 +1458,13 @@ csched2_dom_cntl(
}
break;
default:
-return -EINVAL;
+rc = -EINVAL;
+break;
}
spin_unlock_irqrestore(&prv->lock, flags);
-return 0;
+return rc;
}
static void *
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS
On 04/04/2016 23:45, Chong Li wrote:
> From: Chong-Li
>
> Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced
> a bug: it made it possible, in Credit and Credit2, when doing domain
> or vcpu parameters' manipulation, to leave the hypervisor with a
> spinlock held.
And interrupts disabled (which is far more of a problem than just the
spinlock).
>
> Fix it.
>
> Signed-off-by: Chong Li
> Signed-off-by: Meng Xu
> Signed-off-by: Sisu Xi
This patch is not SoB by anyone other than you.
>
> Acked-by: Dario Faggioli
>
> ---
> CC:
> CC:
> CC:
> CC:
> CC:
> CC:
> ---
> xen/common/sched_credit.c | 1 +
> xen/common/sched_credit2.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index e5d15d8..fa6b7f0 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -1101,6 +1101,7 @@ csched_dom_cntl(
> sdom->cap = op->u.credit.cap;
> break;
> default:
> +spin_unlock_irqrestore(&prv->lock, flags);
> return -EINVAL;
> }
>
While Dario didn't care too much how you fixed the issue, I do.
Please use an "int rc = 0" and remove remove the return statement
(instead, assigning rc = -EINVAL; and a break;). It makes far more
readable and understandable code, which is better in the long run.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/5] xentrace: Common Support for get_pg_owner/put_pg_owner on ARM and x86
On 04/04/2016 19:48, Benjamin Sanda wrote:
> Moved get_pg_owner() and put_pg_owner() from the arch specific x86
> mm.c source files into the common page_alloc.c source. This was done
> as theses functions are now needed by both architectures to support
> xentrace on the ARM platform. Forward declarations were added to mm.h.
>
> One conditional compilation check was added in get_pg_owner() for the
> is_pvh_domain(curr) check which is only valid to perform on x86
> platforms.
>
> Signed-off-by: Benjamin Sanda
>
> ---
> Changed since v2:
> * Combined patches 3-5 from v2 into one patch for v3. No code change.
> ---
> xen/arch/x86/mm.c | 48 --
> xen/common/page_alloc.c | 51
> +
> xen/include/xen/mm.h| 2 ++
> 3 files changed, 53 insertions(+), 48 deletions(-)
>
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index c997b53..0d695dd 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2998,54 +2998,6 @@ int new_guest_cr3(unsigned long mfn)
> return rc;
> }
>
> -static struct domain *get_pg_owner(domid_t domid)
> -{
> -struct domain *pg_owner = NULL, *curr = current->domain;
> -
> -if ( likely(domid == DOMID_SELF) )
> -{
> -pg_owner = rcu_lock_current_domain();
> -goto out;
> -}
> -
> -if ( unlikely(domid == curr->domain_id) )
> -{
> -MEM_LOG("Cannot specify itself as foreign domain");
> -goto out;
> -}
> -
> -if ( !is_pvh_domain(curr) && unlikely(paging_mode_translate(curr)) )
> -{
> -MEM_LOG("Cannot mix foreign mappings with translated domains");
> -goto out;
> -}
> -
> -switch ( domid )
> -{
> -case DOMID_IO:
> -pg_owner = rcu_lock_domain(dom_io);
> -break;
> -case DOMID_XEN:
> -pg_owner = rcu_lock_domain(dom_xen);
> -break;
> -default:
> -if ( (pg_owner = rcu_lock_domain_by_id(domid)) == NULL )
> -{
> -MEM_LOG("Unknown domain '%u'", domid);
> -break;
> -}
> -break;
> -}
> -
> - out:
> -return pg_owner;
> -}
> -
> -static void put_pg_owner(struct domain *pg_owner)
> -{
> -rcu_unlock_domain(pg_owner);
> -}
> -
> static inline int vcpumask_to_pcpumask(
> struct domain *d, XEN_GUEST_HANDLE_PARAM(const_void) bmap, cpumask_t
> *pmask)
> {
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 98e30e5..8fe9c03 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -145,6 +145,7 @@
> #ifdef CONFIG_X86
> #include
> #include /* for highmem_start only */
> +#include
> #else
> #define p2m_pod_offline_or_broken_hit(pg) 0
> #define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
> @@ -1996,6 +1997,56 @@ static __init int register_heap_trigger(void)
> }
> __initcall(register_heap_trigger);
>
> +struct domain *get_pg_owner(domid_t domid)
> +{
> +struct domain *pg_owner = NULL, *curr = current->domain;
> +
> +if ( likely(domid == DOMID_SELF) )
> +{
> +pg_owner = rcu_lock_current_domain();
> +goto out;
> +}
> +
> +if ( unlikely(domid == curr->domain_id) )
> +{
> +gdprintk(XENLOG_WARNING,"Cannot specify itself as foreign domain");
> +goto out;
> +}
> +
> +#ifdef CONFIG_X86
> +if ( !is_pvh_domain(curr) && unlikely(paging_mode_translate(curr)) )
> +{
> +gdprintk(XENLOG_WARNING,"Cannot mix foreign mappings with translated
> domains");
Space after comma.
> +goto out;
> +}
> +#endif
> +
> +switch ( domid )
> +{
> +case DOMID_IO:
> +pg_owner = rcu_lock_domain(dom_io);
> +break;
> +case DOMID_XEN:
> +pg_owner = rcu_lock_domain(dom_xen);
> +break;
> +default:
> +if ( (pg_owner = rcu_lock_domain_by_id(domid)) == NULL )
> +{
> +gdprintk(XENLOG_WARNING,"Unknown domain '%u'", domid);
While changing this code, please use d%d for the domain id, to be
consistent with the newer style.
With these two minor issues fixed, Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS
From: Chong-Li
Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced
a bug: it made it possible, in Credit and Credit2, when doing domain
or vcpu parameters' manipulation, to leave the hypervisor with a
spinlock held.
Fix it.
Signed-off-by: Chong Li
Signed-off-by: Meng Xu
Signed-off-by: Sisu Xi
Acked-by: Dario Faggioli
---
CC:
CC:
CC:
CC:
CC:
CC:
---
xen/common/sched_credit.c | 1 +
xen/common/sched_credit2.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index e5d15d8..fa6b7f0 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1101,6 +1101,7 @@ csched_dom_cntl(
sdom->cap = op->u.credit.cap;
break;
default:
+spin_unlock_irqrestore(&prv->lock, flags);
return -EINVAL;
}
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index d48ed5a..cf444c9 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1457,6 +1457,7 @@ csched2_dom_cntl(
}
break;
default:
+spin_unlock_irqrestore(&prv->lock, flags);
return -EINVAL;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS
On Mon, 2016-04-04 at 16:21 -0500, Chong Li wrote:
> From: Chong-Li
>
> Fix a bug in sched_credit.c and sched_credit2.c: in the default case
> of csched_dom_cntl and csched2_dom_cntl, function returns without
> unlocking prv->lock.
>
This should mention what commit introduced the bug. Of course, this is
not a requirement for any bugfix, but in cases like this, where we know
it, it's IMO an important piece of information.
Also, I find it that the changelog itself contains a lot of information
that are already available by looking at the patch itself (e.g., files
and function names), while it should be a more high level description
of what happened/what is being fixed.
So, with a changelog like this:
Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced
a bug: it made it possible, in Credit and Credit2, when doing domain
or vcpu parameters' manipulation, to leave the hypervisor with a
spinlock held.
Fix it.
This patch is:
Acked-by: Dario Faggioli
Let me just say that, I think the code would look much better if a 'int
rc = 0' variable was declared at the beginning, used like this:
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -1101,6 +1101,7 @@ csched_dom_cntl(
> sdom->cap = op->u.credit.cap;
> break;
> default:
> +spin_unlock_irqrestore(&prv->lock, flags);
> return -EINVAL;
rc = -EINVAL;
break;
and then returned.
But since this is functionally equivalent, I'm ok with the current
form, if that can help speeding up things, and I'll be satisfied by an
updated changelog.
Thanks for looking into this so quickly,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On Mon, Apr 04, 2016 at 02:31:46PM -0700, Andy Lutomirski wrote: > Could you do it by moving just the earlyprintk stuff a la > fpu__init_parse_early_param()? Yeah, something like that. I'll play with this more tomorrow. Btw, no need to make any of this part of your patchset - I'd like early changes like that to cook longer for obvious reasons anyway... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 88639: regressions - FAIL
flight 88639 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/88639/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken in 87395 REGR. vs. 66399 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 86830 pass in 88639 test-armhf-armhf-xl-xsm 16 guest-start.2 fail in 87117 pass in 86830 test-armhf-armhf-xl 11 guest-startfail in 87117 pass in 88639 test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 87204 pass in 88639 test-armhf-armhf-xl-rtds 11 guest-startfail in 87204 pass in 88639 test-armhf-armhf-xl-cubietruck 11 guest-start fail in 87204 pass in 88639 test-armhf-armhf-libvirt-qcow2 6 xen-boot fail in 87204 pass in 88639 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 87295 pass in 88639 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 87295 pass in 88639 test-armhf-armhf-xl-credit2 16 guest-start.2 fail in 87395 pass in 87295 test-armhf-armhf-xl-credit2 11 guest-startfail in 87582 pass in 88639 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 87582 pass in 88639 test-armhf-armhf-xl-arndale 9 debian-install fail in 88510 pass in 88639 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail pass in 87117 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 87204 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail pass in 87395 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 87582 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 88251 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-localmigrate fail pass in 88510 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail in 88251 like 66399 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 66399 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 66399 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 66399 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1)blocked in 87395 n/a build-amd64-rumpuserxen 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl 1 build-check(1)blocked in 87395 n/a test-amd64-i386-xl1 build-check(1)blocked in 87395 n/a test-amd64-i386-pair 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-credit2 1 build-check(1)blocked in 87395 n/a test-amd64-i386-libvirt 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt-xsm 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-i386-pvgrub 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-pair 1 build-check(1)blocked in 87395 n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-pygrub 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-rtds 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked in 87395 n/a test-amd64-i386-libvirt-pair 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl-qcow2 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked in 87395 n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked in 87395 n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1)blocked in 87395 n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked in 87395 n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1)blocked in 87395 n/a test-amd
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On Mon, Apr 4, 2016 at 12:38 PM, Borislav Petkov wrote: > On Mon, Apr 04, 2016 at 06:00:42PM +0200, Peter Zijlstra wrote: >> On Mon, Apr 04, 2016 at 08:32:21AM -0700, Andy Lutomirski wrote: >> >> > Adding locking would be easy enough, wouldn't it? >> >> See patch in this thread.. >> >> > But do any platforms really boot a second CPU before switching to real >> > printk? >> >> I _only_ use early_printk() as printk() is a quagmire of fail :-) > > And since I'm the king of minimalistic changes... this below > works. However, the problem is that we need to pull up all that > early_param parsing in order to enable the early console, i.e. > "earlyprintk=ttyS0,115200" cmdline parsing. > > And we can do all that after having setup the IDT. So I'd need to do > some early dancing with cmdline_find_option_bool(boot_command_line, ... > in asm or so. Need to think about it more. > I'd be nervous about moving early param parsing, especially as part of the same patch. Could you do it by moving just the earlyprintk stuff a la fpu__init_parse_early_param()? --Andy ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS
From: Chong-Li Fix a bug in sched_credit.c and sched_credit2.c: in the default case of csched_dom_cntl and csched2_dom_cntl, function returns without unlocking prv->lock. Signed-off-by: Chong Li Signed-off-by: Meng Xu Signed-off-by: Sisu Xi --- CC: CC: CC: CC: CC: CC: --- xen/common/sched_credit.c | 1 + xen/common/sched_credit2.c | 1 + 2 files changed, 2 insertions(+) diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c index e5d15d8..fa6b7f0 100644 --- a/xen/common/sched_credit.c +++ b/xen/common/sched_credit.c @@ -1101,6 +1101,7 @@ csched_dom_cntl( sdom->cap = op->u.credit.cap; break; default: +spin_unlock_irqrestore(&prv->lock, flags); return -EINVAL; } diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c index d48ed5a..cf444c9 100644 --- a/xen/common/sched_credit2.c +++ b/xen/common/sched_credit2.c @@ -1457,6 +1457,7 @@ csched2_dom_cntl( } break; default: +spin_unlock_irqrestore(&prv->lock, flags); return -EINVAL; } -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 88641: regressions - FAIL
flight 88641 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/88641/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 00f18da1ca79beccdf71e30689e19e8b2e3a02fd baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 118 days Failing since 65593 2015-12-08 23:44:51 Z 117 days 136 attempts Testing same since88334 2016-04-01 23:14:47 Z2 days4 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hess Chen Heyi Guo Jaben Carsey James Bottomley Jeff Fan Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com Jordan Justen Juliano Ciocari Karyne Mayer Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leo Duran Liming Gao Mark Rutland Marvin Haeuser Marvin Häuser Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qiu Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail 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. (No revision log; it would be 16082 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/pvh: Initialize ioreq server for PVH guests
ioreq server list needs to be initialized for PVH guests. This list is
walked in handle_hvm_io_completion() by all guests in HVM containers and
leaving it uninitialized may cause PVH guests to crash there.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/hvm.c | 4 ++--
xen/arch/x86/hvm/ioreq.c | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 9d4e5b8..a82318a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -621,6 +621,8 @@ int hvm_domain_initialise(struct domain *d)
register_dpci_portio_handler(d);
+hvm_ioreq_init(d);
+
if ( is_pvh_domain(d) )
{
register_portio_handler(d, 0, 0x10003, handle_pvh_io);
@@ -645,8 +647,6 @@ int hvm_domain_initialise(struct domain *d)
register_portio_handler(d, 0xe9, 1, hvm_print_line);
-hvm_ioreq_init(d);
-
if ( hvm_tsc_scaling_supported )
d->arch.hvm_domain.tsc_scaling_ratio = hvm_default_tsc_scaling_ratio;
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index e640eff..690e478 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1361,7 +1361,8 @@ void hvm_ioreq_init(struct domain *d)
spin_lock_init(&d->arch.hvm_domain.ioreq_server.lock);
INIT_LIST_HEAD(&d->arch.hvm_domain.ioreq_server.list);
-register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
+if ( !is_pvh_domain(d) )
+register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
}
/*
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 88699: tolerable FAIL - PUSHED
flight 88699 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/88699/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfail like 88680
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 1129a99d2f62c6ae2a98c4e153e835fd3a1a8aee
baseline version:
xen a0f793d82d5ec2d0b67c57d7130bf01c91396c60
Last test of basis88680 2016-04-04 16:03:10 Z0 days
Testing same since88699 2016-04-04 19:03:56 Z0 days1 attempts
People who touched revisions under test:
George Dunlap
George Dunlap
Ian Jackson
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt fail
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
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
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=1129a99d2f62c6ae2a98c4e153e835fd3a1a8aee
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
1129a99d2f62c6ae2a98c4e153e835fd3a1a8aee
+ branch=xen-unstable-smoke
+ revision=1129a99d2f62c6ae2a98c4e153e835fd3a1a8aee
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x1129a99d2f62c6ae2a98c4e153e835fd3a1a8aee = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
Re: [Xen-devel] [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
On Mon, Apr 04, 2016 at 09:00:00AM -0600, Jan Beulich wrote: > >>> On 24.03.16 at 21:00, wrote: > > @@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to > > match against. > > The old code allows much more flexibility and an additional guard, > > but is more complex to implement. > > > > +The second option which requires an build-id of the hypervisor > > +is implemented in the Xen Project hypervisor. > > + > > +Specifically each payload has two build-id ELF notes: > > + * The build-id of the payload itself (generated via --build-id). > > + * The build-id of the payload it depends on (extracted from the > > + the previous payload or hypervisor during build time). > > + > > +This means that the very first payload depends on the hypervisor > > +build-id. > > So this is mean to be a singly linked chain, not something with > branches and alike, allowing independent patches to be applied > solely based on the base build ID? Is such a restriction not going Correct. > to get in the way rather sooner than later? Here is what the design doc says: " ### xSplice interdependencies xSplice patches interdependencies are tricky. There are the ways this can be addressed: * A single large patch that subsumes and replaces all previous ones. Over the life-time of patching the hypervisor this large patch grows to accumulate all the code changes. * Hotpatch stack - where an mechanism exists that loads the hotpatches in the same order they were built in. We would need an build-id of the hypevisor to make sure the hot-patches are build against the correct build. * Payload containing the old code to check against that. That allows the hotpatches to be loaded indepedently (if they don't overlap) - or if the old code also containst previously patched code - even if they overlap. The disadvantage of the first large patch is that it can grow over time and not provide an bisection mechanism to identify faulty patches. The hot-patch stack puts stricts requirements on the order of the patches being loaded and requires an hypervisor build-id to match against. The old code allows much more flexibility and an additional guard, but is more complex to implement. The second option which requires an build-id of the hypervisor is implemented in the Xen Project hypervisor. " I was all for "old_code to check against" but that would incur quite a lot of implementation. The 'stacking' (suggested by Martin) is much easier to implement. I am hoping that in next major milestone the 'old code' checking can be implemented such that the admin has the choice to use both. > > > +# Not Yet Done > > + > > +This is for further development of xSplice. > > + > > +## Goals > > + > > +The implementation must also have a mechanism for: > > + > > + * Be able to lookup in the Xen hypervisor the symbol names of functions > > from the ELF payload. > > + * Be able to patch .rodata, .bss, and .data sections. > > + * Further safety checks (blacklist of which functions cannot be patched, > > check > > + the stack, make sure the payload is built with same compiler as > > hypervisor, > > + and NMI/MCE handlers and do_nmi for right now - until an safe solution > > is found). > > + * NOP out the code sequence if `new_size` is zero. > > + * Deal with other relocation types: R_X86_64_[8,16,32,32S], > > R_X86_64_PC[8,16,64] in payload file. > > Does this belong here? Doesn't this duplicate something I saw earlier? ? This is just shrinking the "TODO Goals" section and removing the: "- * An dependency mechanism for the payloads. To use that information to load: -- The appropiate payload. To verify that payload is built against the - hypervisor. This can be done via the `build-id` - or via providing an copy of the old code - so that the hypervisor can
Re: [Xen-devel] [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded.
On Mon, Apr 04, 2016 at 09:06:47AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, wrote:
> > --- a/xen/common/xsplice.c
> > +++ b/xen/common/xsplice.c
> > @@ -566,6 +566,27 @@ static int prepare_payload(struct payload *payload,
> > if ( !payload->id.len || !payload->id.p )
> > return -EINVAL;
> > }
> > +/* Make sure it is not a duplicate. */
> > +if ( payload->id.len )
>
> The conditional is pointless considering the one visible in context
> above.
/me nods. Let me move it inside the braces above.
>
> > +{
> > +struct payload *data;
> > +
> > +spin_lock_recursive(&payload_lock);
> > +list_for_each_entry ( data, &payload_list, list )
> > +{
> > +/* No way payload is on the list. */
> > +ASSERT( data != payload );
> > +if ( data->id.len &&
> > + !memcmp(data->id.p, payload->id.p, data->id.len) )
> > +{
> > +spin_unlock_recursive(&payload_lock);
> > +dprintk(XENLOG_DEBUG, "%s%s: Already loaded as %s!\n",
> > +XSPLICE, elf->name, data->name);
> > +return -EEXIST;
> > +}
> > +}
> > +spin_unlock_recursive(&payload_lock);
>
> Similar question as asked elsewhere - with the lock getting dropped
> here, how is the "no duplicate" state going to be ensured by the
> time you actually load and insert this payload?
It won't. I've removed the spinlock usage here and we are keeping the spinlock
held at xsplice_upload.
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 10/28] xsplice: Implement payload loading
On Fri, Apr 01, 2016 at 03:18:45AM -0600, Jan Beulich wrote:
> >>> On 31.03.16 at 23:26, wrote:
> >> Also - how well will this O(n^2) lookup work once there are enough
> >> payloads? I think this calls for the alternative vmap() extension I've
> >> been suggesting earlier.
> >
> > Could you elaborate on the vmap extension a bit please?
> >
> > Your earlier email seems to say: drop the vmap API and just
> > allocate the underlaying pages yourself.
>
> Actually I had also said in that earlier mail: "If, otoh, you left that
> VA management to (an extended version of) vmap(), by e.g.
> allowing the caller to request allocation from a different VA range
> (much like iirc x86-64 Linux handles its modules address range
> allocation), things would be different. After all the VA
> management is the important part here, while the backing
> memory allocation is just a trivial auxiliary operation."
>
> I.e. elaboration here really just consists of the referral to the
> respective Linux approach.
I am in need here of guidance I am afraid.
Let me explain (did this in IRC but this will have a broader scope):
In Linux we have the 'struct vm_area' which internally contains the start
and end address (amongst other things). The callers usually use
__vmalloc_node_range
to an provide those addresses. Internally the vmalloc API allocates the
'struct vm_area' from the normal SLAB allocator. Vmalloc API also has an
vmap block area (allocated within vmalloc area) which is a red and black tree
for all the users of its API. When vm_size() is called this tree is searched
to find the 'vm_area' for the provided virtual address. There is a lot
of code in this. Copying it and jamming does not look easy so it would be
better to take concepts of this an implement this..
On Xen we setup a bitmap that covers the full vmalloc area (128MB on my
4GB box, but can go up to 64GB) - the 128MB vmalloc area requires about
32K bits.
For every allocation we "waste" an page (and a bit) so that there is a gap.
This gap is needed when trying to to determine the size of the allocated
region - when scanning the bitmap we can easily figure out the cleared
bit which is akin to a fencepost.
To make Xen's vmalloc API be generic I need to wholesale make it able
to deal with virtual addresses that are not part of its space (as in
not in VMAP_VIRT_START to vm_top). At the start I the input to vm_size()
needs to get the size of the virtual address (either the ones from
the vmalloc areas or the ones provided earlier by vmalloc_cb).
One easy mechanism is to embedded an array of simplified 'struct vm_area'
structure:
struct vm_area {
unsigned long va;
}
for every slot in the VMAP_VIRT_START area (that is have 32K entries).
The vm_size and all the rest can check for this array if the virtual
address provided is not within the vmalloc virtual addresses. If there
is a match we just need to consult the vm_bitmap at the same index and
figure out where the empty bit is set.
The downside is that I've to walk the full array (32K entries).
But when you think about it - most of the time we use normal vmalloc addresses
and only in exceptional cases do we need the alternate ones. And the only reason
to keep track of it is to know the size.
The easier way would be to track them via a linked list:
struct vm_area {
struct list_head list;
unsigned long va;
size_t nr;
}
And vm_size, vm_index, etc would consult this list for the virtual address and
could get the proper information. (See inline patch)
But if we are doing that this, then why even put it in the vmalloc API? Why not
track all of this with the user of this? (like it was done in v4 of this patch
series?)
Please advise.
From a0e3015bbf4d99fc8e5428634dc3b281cf8eedb7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Mon, 14 Mar 2016 12:02:05 -0400
Subject: [PATCH] vmap: Add vmalloc_cb
For those users who want to supply their own vmap callback.
This callback will be called _after_ the pages have been
allocated and instead of using the vmap internal API, it will
call the callback which will be responsible for providing the
virtual addresses.
The vmap API also keeps track of this virtual address (along
with the size) so that vunmap, vm_size, and vm_free can operate
on these virtual addresses.
This allows users (such as xSplice) to provide their own
mechanism to change the the page flags, and also use virtual
addresses closer to the hypervisor virtual addresses (at least
on x86).
The users (such as patch titled "xsplice: Implement payload
loading") can wrap the calls to __vmap for this.
Note that the displacement of the hypervisor virtual addresses to the
vmalloc (on x86) is more than 32-bits - which means that ELF relocations
(which are limited to 32-bits) - won't work (we truncate the 34 and 33th
bit). Hence we cannot use on vmalloc virtual addresses but must
supply our own ranges.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Ian Jackson
Cc: Jan Beul
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On Mon, Apr 04, 2016 at 06:00:42PM +0200, Peter Zijlstra wrote:
> On Mon, Apr 04, 2016 at 08:32:21AM -0700, Andy Lutomirski wrote:
>
> > Adding locking would be easy enough, wouldn't it?
>
> See patch in this thread..
>
> > But do any platforms really boot a second CPU before switching to real
> > printk?
>
> I _only_ use early_printk() as printk() is a quagmire of fail :-)
And since I'm the king of minimalistic changes... this below
works. However, the problem is that we need to pull up all that
early_param parsing in order to enable the early console, i.e.
"earlyprintk=ttyS0,115200" cmdline parsing.
And we can do all that after having setup the IDT. So I'd need to do
some early dancing with cmdline_find_option_bool(boot_command_line, ...
in asm or so. Need to think about it more.
---
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 1f4422d5c8d0..ad534226653b 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -130,6 +130,13 @@ static void __init copy_bootdata(char *real_mode_data)
}
}
+static int _early_printk(const char *fmt, va_list args)
+{
+ early_printk(fmt, args);
+
+ return 0;
+}
+
asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
{
int i;
@@ -164,6 +171,10 @@ asmlinkage __visible void __init x86_64_start_kernel(char
* real_mode_data)
load_idt((const struct desc_ptr *)&idt_descr);
copy_bootdata(__va(real_mode_data));
+ parse_early_param();
+ this_cpu_write(printk_func, _early_printk);
+
+ printk("This is a test!\n");
/*
* Load microcode early on BSP.
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2367ae07eb76..998d6c675549 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -882,6 +882,7 @@ void __init setup_arch(char **cmdline_p)
*/
__flush_tlb_all();
#else
+ this_cpu_write(printk_func, vprintk_default);
printk(KERN_INFO "Command line: %s\n", boot_command_line);
#endif
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9ccbdf2c1453..97df81c97b2f 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -169,6 +169,7 @@ void __init setup_log_buf(int early);
__printf(1, 2) void dump_stack_set_arch_desc(const char *fmt, ...);
void dump_stack_print_info(const char *log_lvl);
void show_regs_print_info(const char *log_lvl);
+int vprintk_default(const char *fmt, va_list args);
#else
static inline __printf(1, 0)
int vprintk(const char *s, va_list args)
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 88588: regressions - FAIL
flight 88588 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/88588/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 86491 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 86491 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail pass in 88468 test-amd64-amd64-xl-rtds 9 debian-install fail pass in 88468 Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-buildfail like 86491 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86491 build-amd64-rumpuserxen 6 xen-buildfail like 86491 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 86491 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 86491 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 86491 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 96ae556569b8eaedc0bb242932842c3277b515d8 baseline version: xen a6f2cdb633bf519244a16674031b8034b581ba7f Last test of basis86491 2016-03-17 15:24:59 Z 18 days Failing since 86560 2016-03-18 10:56:34 Z 17 days 21 attempts Testing same since88235 2016-04-01 06:23:37 Z3 days4 attempts People who touched revisions under test: Andrew Cooper Andrew Cooper [for the Ocaml stubs] Anthony PERARD Boris Ostrovsky Chunyan Liu Dagaen Golomb Daniel De Graaf Daniel De Graaf [XSM bits] Dario Faggioli Dave Scott David Scott David Vrabel Doug Goldstein George Dunlap George Dunlap George Dunlap [xenctx bits] Ian Campbell Ian Jackson Jan Beulich Jim Fehlig Jonathan Davies Juergen Gross Jul
[Xen-devel] [PATCH v3 5/5] xenalyze: Build for Both ARM and x86 Platforms
Modified to provide building of the xenalyze binary for both ARM and x86 platforms. The xenalyze binary is now built as part of the BIN list for both platforms. Signed-off-by: Benjamin Sanda Acked-by: Wei Liu --- Changed since v2: * No changes. --- Changed since v1: * Changed xenalyze target from SBIN to BIN * Removed unneeded $(BIN-y) from BIN list --- tools/xentrace/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile index 0157be2..edcc5a7 100644 --- a/tools/xentrace/Makefile +++ b/tools/xentrace/Makefile @@ -9,8 +9,7 @@ LDLIBS += $(LDLIBS_libxenevtchn) LDLIBS += $(LDLIBS_libxenctrl) LDLIBS += $(ARGP_LDFLAGS) -BIN-$(CONFIG_X86) = xenalyze -BIN = $(BIN-y) +BIN = xenalyze SBIN = xentrace xentrace_setsize LIBBIN = xenctx SCRIPTS = xentrace_format -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 3/5] xentrace: Timestamp support for ARM platform
Moved get_cycles() to time.c and modified to return the core timestamp
tick count for use by the trace buffer timestamping routines in
xentrace. get_cycles() was moved to the C file to avoid including the
register specific header file in time.h and to commonize it with the
get_s_time() function. Also defined cycles_t as uint64_t to simplify
casting.
get_s_time() was also modified to now use the updated get_cycles() to
retrieve the tick count instead of directly reading it.
Signed-off-by: Benjamin Sanda
---
Changed since v2:
* Combined v2 patches 7 and 6 into one patch in v3. No code change.
---
Changed since v1:
* Moved get_cycles() to time.c
* Added function prototype for get_cycles()
---
xen/arch/arm/time.c| 9 -
xen/include/asm-arm/time.h | 11 +--
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 7dae28b..9aface3 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -192,10 +192,17 @@ int __init init_xen_time(void)
/* Return number of nanoseconds since boot */
s_time_t get_s_time(void)
{
-uint64_t ticks = READ_SYSREG64(CNTPCT_EL0) - boot_count;
+cycles_t ticks = get_cycles();
return ticks_to_ns(ticks);
}
+/* Return the number of ticks since boot */
+cycles_t get_cycles(void)
+{
+/* return raw tick count of main timer */
+return READ_SYSREG64(CNTPCT_EL0) - boot_count;
+}
+
/* Set the timer to wake us up at a particular time.
* Timeout is a Xen system time (nanoseconds since boot); 0 disables the timer.
* Returns 1 on success; 0 if the timeout is too soon or is in the past. */
diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
index 5b9a31d..b57f4c1 100644
--- a/xen/include/asm-arm/time.h
+++ b/xen/include/asm-arm/time.h
@@ -5,12 +5,8 @@
DT_MATCH_COMPATIBLE("arm,armv7-timer"), \
DT_MATCH_COMPATIBLE("arm,armv8-timer")
-typedef unsigned long cycles_t;
-
-static inline cycles_t get_cycles (void)
-{
-return 0;
-}
+/* Tick count type */
+typedef uint64_t cycles_t;
/* List of timer's IRQ */
enum timer_ppi
@@ -37,6 +33,9 @@ extern void init_timer_interrupt(void);
/* Counter value at boot time */
extern uint64_t boot_count;
+/* Get raw system tick count */
+cycles_t get_cycles(void);
+
extern s_time_t ticks_to_ns(uint64_t ticks);
extern uint64_t ns_to_ticks(s_time_t ns);
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 4/5] xentrace: Trace Buffer Initialization on ARM
Added call to init_trace_bufs() to initialize the trace buffers for use by xentrace. Signed-off-by: Benjamin Sanda --- Changed since v2: * No changes --- Changed since v1: * No changes --- xen/arch/arm/setup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 6d205a9..87e70c9 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include #include @@ -851,6 +852,8 @@ void __init start_xen(unsigned long boot_phys_offset, /* Scrub RAM that is still free and so may go to an unprivileged domain. */ scrub_heap_pages(); +init_trace_bufs(); + init_constructors(); console_endboot(); -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 1/5] xentrace: Common Support for get_pg_owner/put_pg_owner on ARM and x86
Moved get_pg_owner() and put_pg_owner() from the arch specific x86
mm.c source files into the common page_alloc.c source. This was done
as theses functions are now needed by both architectures to support
xentrace on the ARM platform. Forward declarations were added to mm.h.
One conditional compilation check was added in get_pg_owner() for the
is_pvh_domain(curr) check which is only valid to perform on x86
platforms.
Signed-off-by: Benjamin Sanda
---
Changed since v2:
* Combined patches 3-5 from v2 into one patch for v3. No code change.
---
xen/arch/x86/mm.c | 48 --
xen/common/page_alloc.c | 51 +
xen/include/xen/mm.h| 2 ++
3 files changed, 53 insertions(+), 48 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c997b53..0d695dd 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2998,54 +2998,6 @@ int new_guest_cr3(unsigned long mfn)
return rc;
}
-static struct domain *get_pg_owner(domid_t domid)
-{
-struct domain *pg_owner = NULL, *curr = current->domain;
-
-if ( likely(domid == DOMID_SELF) )
-{
-pg_owner = rcu_lock_current_domain();
-goto out;
-}
-
-if ( unlikely(domid == curr->domain_id) )
-{
-MEM_LOG("Cannot specify itself as foreign domain");
-goto out;
-}
-
-if ( !is_pvh_domain(curr) && unlikely(paging_mode_translate(curr)) )
-{
-MEM_LOG("Cannot mix foreign mappings with translated domains");
-goto out;
-}
-
-switch ( domid )
-{
-case DOMID_IO:
-pg_owner = rcu_lock_domain(dom_io);
-break;
-case DOMID_XEN:
-pg_owner = rcu_lock_domain(dom_xen);
-break;
-default:
-if ( (pg_owner = rcu_lock_domain_by_id(domid)) == NULL )
-{
-MEM_LOG("Unknown domain '%u'", domid);
-break;
-}
-break;
-}
-
- out:
-return pg_owner;
-}
-
-static void put_pg_owner(struct domain *pg_owner)
-{
-rcu_unlock_domain(pg_owner);
-}
-
static inline int vcpumask_to_pcpumask(
struct domain *d, XEN_GUEST_HANDLE_PARAM(const_void) bmap, cpumask_t
*pmask)
{
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 98e30e5..8fe9c03 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -145,6 +145,7 @@
#ifdef CONFIG_X86
#include
#include /* for highmem_start only */
+#include
#else
#define p2m_pod_offline_or_broken_hit(pg) 0
#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
@@ -1996,6 +1997,56 @@ static __init int register_heap_trigger(void)
}
__initcall(register_heap_trigger);
+struct domain *get_pg_owner(domid_t domid)
+{
+struct domain *pg_owner = NULL, *curr = current->domain;
+
+if ( likely(domid == DOMID_SELF) )
+{
+pg_owner = rcu_lock_current_domain();
+goto out;
+}
+
+if ( unlikely(domid == curr->domain_id) )
+{
+gdprintk(XENLOG_WARNING,"Cannot specify itself as foreign domain");
+goto out;
+}
+
+#ifdef CONFIG_X86
+if ( !is_pvh_domain(curr) && unlikely(paging_mode_translate(curr)) )
+{
+gdprintk(XENLOG_WARNING,"Cannot mix foreign mappings with translated
domains");
+goto out;
+}
+#endif
+
+switch ( domid )
+{
+case DOMID_IO:
+pg_owner = rcu_lock_domain(dom_io);
+break;
+case DOMID_XEN:
+pg_owner = rcu_lock_domain(dom_xen);
+break;
+default:
+if ( (pg_owner = rcu_lock_domain_by_id(domid)) == NULL )
+{
+gdprintk(XENLOG_WARNING,"Unknown domain '%u'", domid);
+break;
+}
+break;
+}
+
+ out:
+return pg_owner;
+}
+
+void put_pg_owner(struct domain *pg_owner)
+{
+rcu_unlock_domain(pg_owner);
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index d62394f..7b4dd87 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -505,6 +505,8 @@ void scrub_one_page(struct page_info *);
int xenmem_add_to_physmap_one(struct domain *d, unsigned int space,
domid_t foreign_domid,
unsigned long idx, xen_pfn_t gpfn);
+struct domain *get_pg_owner(domid_t domid);
+void put_pg_owner(struct domain *pg_owner);
/* Returns 1 on success, 0 on error, negative if the ring
* for event propagation is full in the presence of paging */
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 0/5] xentrace/xenalyze Support on ARM
This patch set adds support for xentrace/xenalyze to the ARM platform. The Xen heap memory mapping, timestamping, and P2M translation needed by xentrace is corrected for operation on the ARM platform using the x86 platform as reference. Trace buffer initialization is added to setup.c, XENMAPSPACE_gmfn_foreign page mapping and address translation for DOMID_XEN is corrected in mm.c and p2m.c, and timestamping for the trace buffers is corrected in time.c/.h. Finally the xenaylze makefile is configured to build the tool for ARM. --- Changed since v2: * Merged previous single file patches into atomic patches which can be applied and compiled independently. * Updated individual patch names to be more descriptive. * Correct order of patches in patch set to provide correct application/build order. --- Changed since v1: * Removed Flask changes as deemed unnecessary and unclear in purpose * Corrected all commit messages to be line limited to 72 chars * Implemented v1 review comments as indicated in each file's commit log. Benjamin Sanda (5): xentrace: Common Support for get_pg_owner/put_pg_owner on ARM and x86 xentrace: Memory/Page Mapping support for DOMID_XEN on ARM xentrace: Timestamp support for ARM platform xentrace: Trace Buffer Initialization on ARM xenalyze: Build for Both ARM and x86 Platforms tools/xentrace/Makefile| 3 +-- xen/arch/arm/mm.c | 3 ++- xen/arch/arm/p2m.c | 35 +++ xen/arch/arm/setup.c | 3 +++ xen/arch/arm/time.c| 9 +++- xen/arch/x86/mm.c | 48 --- xen/common/page_alloc.c| 51 ++ xen/include/asm-arm/time.h | 11 +- xen/include/xen/mm.h | 2 ++ 9 files changed, 103 insertions(+), 62 deletions(-) -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/5] xentrace: Memory/Page Mapping support for DOMID_XEN on ARM
Modified ARM arch specific p2m.c and mm.c files to provide support for
xentrace. Case for DOMID_XEN added xenmem_add_to_physmap_one() when
XENMAPSPACE_gmfn_foreign domain requested via get_pg_owner. This
provides correct calls to rcu_lock_domain() when DOMID_XEN is
requested.
Check for DOMID_XEN added to p2m_lookup() which skips PFN to MFN
translation. DOMID_XEN is considered a PV guest on x86 (i.e MFN ==
GFN), but on ARM there is no such concept. Thus requests to DOMID_XEN
on ARM use a MFN address directly and do not need translation from
PFN.
Check added to p2m_lookup() to determine read/write or read-only page
type when requesting DOMID_XEN. This is done by checking the
u.inuse.type_info parameter of the requested page. The page rw/ro
paddr_t type is then set accordingly.
---
Changed since v2:
* Combined v2 patches 2 and 8 into one patch for v3. No code changes.
---
Changed since v1:
* Moved get_pg_owner() from the arch specific mm.c source files into
the common page_alloc.c source. This was done as get_pg_owner() is
now needed by both architectures and is essentially identical in
both.
* Moved put_pg_owner from the arch specific mm.c source files into
the common page_alloc.c source to make available to all platforms.
* Removed DOMID_XEN check from page_to_mfn(page) call in
xenmem_add_to_physmap_one() per review comment (check considered
to be in excess of need).
* Removed forward declare of get_pg_owner from mm.c (arm) as it is
now in the mm.h common header.
* Added check to determine page rw/ro type to correctly set the
paddr_t to p2m_ram_rw or p2m_ram_ro instead of assuming p2m_ram_rw
* Corrected block comment format to conform to Xen coding standard
Signed-off-by: Benjamin Sanda
---
xen/arch/arm/mm.c | 3 ++-
xen/arch/arm/p2m.c | 35 +++
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 81f9e2e..19d6c2c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1099,7 +1099,8 @@ int xenmem_add_to_physmap_one(
{
struct domain *od;
p2m_type_t p2mt;
-od = rcu_lock_domain_by_any_id(foreign_domid);
+od = get_pg_owner(foreign_domid);
+
if ( od == NULL )
return -ESRCH;
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index a2a9c4b..a99b670 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -227,11 +227,38 @@ paddr_t p2m_lookup(struct domain *d, paddr_t paddr,
p2m_type_t *t)
{
paddr_t ret;
struct p2m_domain *p2m = &d->arch.p2m;
+struct page_info *page;
+unsigned long mfn;
-spin_lock(&p2m->lock);
-ret = __p2m_lookup(d, paddr, t);
-spin_unlock(&p2m->lock);
-
+/*
+* DOMID_XEN is considered a PV guest on x86 (i.e MFN == GFN), but
+* on ARM there is no such concept. Thus requests to DOMID_XEN
+* on ARM use a MFN address directly and do not need translation
+* from PFN.
+*/
+if(DOMID_XEN != d->domain_id)
+{
+spin_lock(&p2m->lock);
+ret = __p2m_lookup(d, paddr, t);
+spin_unlock(&p2m->lock);
+}
+else
+{
+/* retrieve the page to determine read/write or read only mapping */
+mfn = paddr >> PAGE_SHIFT;
+if (mfn_valid(mfn))
+{
+page = mfn_to_page(mfn);
+*t = (page->u.inuse.type_info == PGT_writable_page ?
+p2m_ram_rw : p2m_ram_ro);
+}
+else
+{
+*t = p2m_invalid;
+}
+ret = paddr;
+}
+
return ret;
}
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Intel MID / CE4100 - platform support - pnpbios support ?
On 04/04/16 11:24, Luis R. Rodriguez wrote: > On Mon, Apr 04, 2016 at 09:01:06AM -0700, H. Peter Anvin wrote: >> On 03/31/16 13:03, Luis R. Rodriguez wrote: >>> Andy S, Peter, Thomas, Jiang (or who might know), >>> >>> Do Intel MID platforms exist with PNP BIOS support? What abot CE4100? >>> As it stands I don't see anything that would prevent this but I would >>> suspect a possibility might be that it doesn't. I'm sanitizing some >>> early boot code right now and pnpbios is one, and as I work on this, >>> this has come up as a question for me. >>> >> >> The "MID" platforms from a Linux platform perspective are the ones with >> SFI and DT bootloaders, respectively; by definition they don't have >> standard BIOS. > > I see thanks, I ask as I'm currently removing a pnpbios replacing a > paravirt_enabled() check to a more general disable pnpbios x86 platform quirk > option, so far lguest and xen would use it but it would seem to me it was > worthy to ask if if MID and CE4100 subarchs also could have this set as well > then. > > It sounds like then at least for Intel MID I can disable pnpbios as well > as a quirk as well. I can introduce that change separately in my series. > > What about CE4100 ? > The same, I am pretty sure. -hpa ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Getting rid of inside_vm in intel8x0
On Sat, Apr 02, 2016 at 10:22:44PM +0200, Takashi Iwai wrote: > On Sat, 02 Apr 2016 20:05:21 +0200, > Andy Lutomirski wrote: > > > > On Apr 2, 2016 12:07 PM, "Takashi Iwai" wrote: > > > > > > On Sat, 02 Apr 2016 14:57:44 +0200, > > > Andy Lutomirski wrote: > > > > > > > > On Fri, Apr 1, 2016 at 10:33 PM, Takashi Iwai wrote: > > > > > On Sat, 02 Apr 2016 00:28:31 +0200, > > > > > Luis R. Rodriguez wrote: > > > > >> If the former, could a we somehow detect an emulated device other > > > > >> than through > > > > >> this type of check ? Or could we *add* a capability of some sort to > > > > >> detect it > > > > >> on the driver ? This would not address the removal, but it could > > > > >> mean finding a > > > > >> way to address emulation issues. > > > > >> > > > > >> If its an IO issue -- exactly what is the causing the delays in IO ? > > > > > > > > > > Luis, there is no problem about emulation itself. It's rather an > > > > > optimization to lighten the host side load, as I/O access on a VM is > > > > > much heavier. > > > > > > > > > >> > > > This is satisfied mostly only on VM, and can't > > > > >> > > > be measured easily unlike the IO read speed. > > > > >> > > > > > > >> > > Interesting, note the original patch claimed it was for KVM and > > > > >> > > Parallels hypervisor only, but since the code uses: > > > > >> > > > > > > >> > > +#if defined(__i386__) || defined(__x86_64__) > > > > >> > > + inside_vm = inside_vm || > > > > >> > > boot_cpu_has(X86_FEATURE_HYPERVISOR); > > > > >> > > +#endif > > > > >> > > > > > > >> > > This makes it apply also to Xen as well, this makes this hack > > > > >> > > more > > > > >> > > broad, but does is it only applicable when an emulated device is > > > > >> > > used ? What about if a hypervisor is used and PCI passthrough is > > > > >> > > used ? > > > > >> > > > > > >> > A good question. Xen was added there at the time from positive > > > > >> > results by quick tests, but it might show an issue if it's running > > > > >> > on > > > > >> > a very old chip with PCI passthrough. But I'm not sure whether PCI > > > > >> > passthrough would work on such old chipsets at all. > > > > >> > > > > >> If it did have an issue then that would have to be special cased, > > > > >> that > > > > >> is the module parameter would not need to be enabled for such type of > > > > >> systems, and heuristics would be needed. As you note, fortunately > > > > >> this > > > > >> may not be common though... > > > > > > > > > > Actually this *is* module parametered. If set to a boolean value, it > > > > > can be applied / skipped forcibly. So, if there has been a problem on > > > > > Xen, this should have been reported. That's why I wrote it's no > > > > > common case. This comes from the real experience. > > > > > > > > > >> but if this type of work around may be > > > > >> taken as a precedent to enable other types of hacks in other drivers > > > > >> I'm very fearful of more hacks later needing these considerations as > > > > >> well. > > > > >> > > > > >> > > > > There are a pile of nonsensical "are we in a VM" checks of > > > > >> > > > > various > > > > >> > > > > sorts scattered throughout the kernel, they're all a mess to > > > > >> > > > > maintain > > > > >> > > > > (there are lots of kinds of VMs in the world, and Linux may > > > > >> > > > > not even > > > > >> > > > > know it's a guest), and, in most cases, it appears that the > > > > >> > > > > correct > > > > >> > > > > solution is to delete the checks. I just removed a nasty > > > > >> > > > > one in the > > > > >> > > > > x86_32 entry asm, and this one is written in C so it should > > > > >> > > > > be a piece > > > > >> > > > > of cake :) > > > > >> > > > > > > > >> > > > This cake looks sweet, but a worm is hidden behind the cream. > > > > >> > > > The loop in the code itself is already a kludge for the buggy > > > > >> > > > hardware > > > > >> > > > where the inconsistent read happens not so often (only at the > > > > >> > > > boundary > > > > >> > > > and in a racy way). It would be nice if we can have a more > > > > >> > > > reliably > > > > >> > > > way to know the hardware buggyness, but it's difficult, > > > > >> > > > unsurprisingly. > > > > >> > > > > > > >> > > The concern here is setting precedents for VM cases sprinkled in > > > > >> > > the kernel. > > > > >> > > The assumption here is such special cases are really paper'ing > > > > >> > > over another > > > > >> > > type of issue, so its best to ultimately try to root cause the > > > > >> > > issue in > > > > >> > > a more generalized fashion. > > > > >> > > > > > >> > Well, it's rather bare metal that shows the buggy behavior, thus we > > > > >> > need to paper over it. In that sense, it's other way round; we > > > > >> > don't > > > > >> > tune for VM. The VM check we're discussing is rather for skipping > > > > >> > the > > > > >> > strange workaround. > > > > >> > > > > >> What is it exactly about a VM that
Re: [Xen-devel] Intel MID / CE4100 - platform support - pnpbios support ?
On Mon, Apr 04, 2016 at 09:01:06AM -0700, H. Peter Anvin wrote: > On 03/31/16 13:03, Luis R. Rodriguez wrote: > > Andy S, Peter, Thomas, Jiang (or who might know), > > > > Do Intel MID platforms exist with PNP BIOS support? What abot CE4100? > > As it stands I don't see anything that would prevent this but I would > > suspect a possibility might be that it doesn't. I'm sanitizing some > > early boot code right now and pnpbios is one, and as I work on this, > > this has come up as a question for me. > > > > The "MID" platforms from a Linux platform perspective are the ones with > SFI and DT bootloaders, respectively; by definition they don't have > standard BIOS. I see thanks, I ask as I'm currently removing a pnpbios replacing a paravirt_enabled() check to a more general disable pnpbios x86 platform quirk option, so far lguest and xen would use it but it would seem to me it was worthy to ask if if MID and CE4100 subarchs also could have this set as well then. It sounds like then at least for Intel MID I can disable pnpbios as well as a quirk as well. I can introduce that change separately in my series. What about CE4100 ? Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 88680: regressions - FAIL
flight 88680 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/88680/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 88144 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen a0f793d82d5ec2d0b67c57d7130bf01c91396c60 baseline version: xen 96ae556569b8eaedc0bb242932842c3277b515d8 Last test of basis88144 2016-03-31 13:06:39 Z4 days Failing since 88279 2016-04-01 14:03:55 Z3 days 34 attempts Testing same since88672 2016-04-04 14:03:45 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Changlong Xie Chong Li Dario Faggioli George Dunlap Ian Campbell Ian Jackson Jan Beulich Juergen Gross Kevin Tian Konrad Rzeszutek Wilk Meng Xu Mike Meyer Olaf Hering Paul Durrant Roger Pau Monne Roger Pau Monné Sisu Xi Wei Liu Wen Congyang Yang Hongyang jobs: build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass 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. (No revision log; it would be 856 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/5] libxl: colo: fix indentation of abort()
Signed-off-by: Wei Liu --- tools/libxl/libxl_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 67f308d..51be98a 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -818,7 +818,7 @@ static char *qemu_disk_scsi_drive_string(libxl__gc *gc, const char *target_path, unit, active_disk, hidden_disk, exportname); break; default: - abort(); +abort(); } return drive; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/5] libxl: colo: add missing break in qemu_disk_scsi_drive_string
Signed-off-by: Wei Liu --- tools/libxl/libxl_dm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 5b79aa2..67f308d 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -816,6 +816,7 @@ static char *qemu_disk_scsi_drive_string(libxl__gc *gc, const char *target_path, "file.backing.file.filename=%s," "file.backing.backing=%s", unit, active_disk, hidden_disk, exportname); +break; default: abort(); } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/5] libxc: colo: don't leak pfns and iov in send_checkpoint_dirty_pfn_list
Signed-off-by: Wei Liu --- tools/libxc/xc_sr_restore.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c index 728edbc..3549f0a 100644 --- a/tools/libxc/xc_sr_restore.c +++ b/tools/libxc/xc_sr_restore.c @@ -494,6 +494,8 @@ static int send_checkpoint_dirty_pfn_list(struct xc_sr_context *ctx) rc = 0; err: +free(pfns); +free(iov); return rc; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 5/5] libxl: colo: remove dead code in colo_save_setup_script_cb
Signed-off-by: Wei Liu
---
tools/libxl/libxl_colo_nic.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/tools/libxl/libxl_colo_nic.c b/tools/libxl/libxl_colo_nic.c
index 2e00c28..5e0968c 100644
--- a/tools/libxl/libxl_colo_nic.c
+++ b/tools/libxl/libxl_colo_nic.c
@@ -219,11 +219,6 @@ static void colo_save_setup_script_cb(libxl__egc *egc,
goto out;
}
-if (status) {
-rc = ERROR_FAIL;
-goto out;
-}
-
rc = 0;
out:
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/5] libxl: colo: simplify colo_proxy_async_wait_for_checkpoint
Signed-off-by: Wei Liu
---
tools/libxl/libxl_colo_save.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_colo_save.c b/tools/libxl/libxl_colo_save.c
index e2fdc4b..26b3afd 100644
--- a/tools/libxl/libxl_colo_save.c
+++ b/tools/libxl/libxl_colo_save.c
@@ -533,11 +533,11 @@ static void
colo_proxy_async_wait_for_checkpoint(libxl__colo_save_state *css)
if (req < 0) {
/* some error happens */
_exit(1);
-} else if (!req) {
-/* no checkpoint is needed, do a checkpoint every 5s */
-_exit(0);
} else {
-/* net packets is not consistent, we need to start a checkpoint */
+/* req == 0: no checkpoint is needed, do a checkpoint every 5s */
+/* req > 0: net packets is not consistent, we need to start a
+ * checkpoint
+ */
_exit(0);
}
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/5] COLO fixes
Wei Liu (5): libxc: colo: don't leak pfns and iov in send_checkpoint_dirty_pfn_list libxl: colo: simplify colo_proxy_async_wait_for_checkpoint libxl: colo: add missing break in qemu_disk_scsi_drive_string libxl: colo: fix indentation of abort() libxl: colo: remove dead code in colo_save_setup_script_cb tools/libxc/xc_sr_restore.c | 2 ++ tools/libxl/libxl_colo_nic.c | 5 - tools/libxl/libxl_colo_save.c | 8 tools/libxl/libxl_dm.c| 3 ++- 4 files changed, 8 insertions(+), 10 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On Mon, Apr 4, 2016 at 11:47 AM, Wei Liu wrote:
> On Mon, Apr 04, 2016 at 06:32:48PM +0200, Dario Faggioli wrote:
>> On Mon, 2016-04-04 at 17:05 +0100, George Dunlap wrote:
>> > On 04/04/16 16:58, Chong Li wrote:
>> > > On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
>> > > wrote:
>> > > > On 01/04/16 05:59, Chong Li wrote:
>> > > > >
>> > > > > --- a/xen/common/sched_credit2.c
>> > > > > +++ b/xen/common/sched_credit2.c
>> > > > > @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
>> > > > > * runq lock to update csvcs. */
>> > > > > spin_lock_irqsave(&prv->lock, flags);
>> > > > >
>> > > > > -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>> > > > > +switch ( op->cmd )
>> > > > > {
>> > > > > +case XEN_DOMCTL_SCHEDOP_getinfo:
>> > > > > op->u.credit2.weight = sdom->weight;
>> > > > > -}
>> > > > > -else
>> > > > > -{
>> > > > > -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>> > > > > -
>> > > > > +break;
>> > > > > +case XEN_DOMCTL_SCHEDOP_putinfo:
>> > > > > if ( op->u.credit2.weight != 0 )
>> > > > > {
>> > > > > struct vcpu *v;
>> > > > > @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
>> > > > > vcpu_schedule_unlock(lock, svc->vcpu);
>> > > > > }
>> > > > > }
>> > > > > +break;
>> > > > > +default:
>> > > > > +return -EINVAL;
>> > > > As does this.
>> > > >
>> > > > Please submit a bugfix ASAP. This will become a security
>> > > > vulnerability
>> > > > if Xen 4.7 is shipped without it being fixed.
>> > > >
>> > > > >
>> > > > > }
>> > > > >
>> > > > > spin_unlock_irqrestore(&prv->lock, flags);
>> > > Thanks for pointing this out.
>> > >
>> > > Dario, do you want to include this bugfix in your cleanup patch, or
>> > > let me submit this?
>> > If you're around and can test it, it's probably better if you can
>> > send a
>> > patch right a way.
>> >
>> Exactly. In fact:
>> - we don't fold bugfixes in clanups,
>> - I think I mentioned wanting to cleanup some code duplication in
>>libxl, this is in xen,
>> - cleanups are delayed to 4.8, while this must be fixed before
>>release (or the patch/the whole feature be reverted).
>>
>> So, if you can't work out a fix today or, at most, tomorrow, let me
>> know and I'll do it myself.
>>
>
> Yes, please fix this by tomorrow. I think it is quite straightforward to
> fix anyway.
>
> Wei.
>
Will do.
--
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 5/9] libxl: Rearrange qemu upstream disk argument code
On 04/04/16 18:11, Andrew Cooper wrote:
> On 04/04/16 17:59, Ian Jackson wrote:
>> George Dunlap writes ("Re: [PATCH v3 5/9] libxl: Rearrange qemu upstream
>> disk argument code"):
>>> I looked through the patch in the branch provided in your reply to 0/9
>>> [1], and it looks correct; morever, I tested it and it and the basic
>>> functionality (using the "dummy" block script) still works.
>>>
>>> Reviewed-by: George Dunlap
>>> Tested-by: George Dunlap
>>>
>>> [1] git://xenbits.xenproject.org/people/iwj/xen.git wip.gwd.hotplug-v3.1
>> Thanks, I have pushed it (rebased) to staging.
> New build failure on CentOS 7
>
> libxl_dm.c: In function 'libxl__build_device_model_args':
> libxl_dm.c:1374:27: error: 'target_path' may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> drive = libxl__sprintf(gc, "%s,file=%s,format=%s",
>^
> libxl_dm.c:1310:25: note: 'target_path' was declared here
> const char *target_path;
> ^
> cc1: all warnings being treated as errors
Sorry - sent too early. Specifically, target_path is genuinely
uninitialised in the case that there is an empty CDROM specified.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] XSM permissive by default.
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] XSM permissive by default."):
> I presume this patch would be to folks +1:
>
> From 3373a50f386b41eea6ecede4b430e4fa09b2fe7e Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk
> Date: Thu, 10 Mar 2016 12:05:29 -0500
> Subject: [PATCH] flask: By default be in FLASK_BOOTPARAM_ENFORCING mode.
This has a Reviewed-by from Doug Goldstein and Andrew Cooper. And
then it was revised by Daniel. But AFAICT it has not yet been
committed. I think this is an important change that is in 4.7.
Is there some reason why this patch hasn't been committed ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 5/9] libxl: Rearrange qemu upstream disk argument code
On 04/04/16 17:59, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v3 5/9] libxl: Rearrange qemu upstream disk
> argument code"):
>> I looked through the patch in the branch provided in your reply to 0/9
>> [1], and it looks correct; morever, I tested it and it and the basic
>> functionality (using the "dummy" block script) still works.
>>
>> Reviewed-by: George Dunlap
>> Tested-by: George Dunlap
>>
>> [1] git://xenbits.xenproject.org/people/iwj/xen.git wip.gwd.hotplug-v3.1
> Thanks, I have pushed it (rebased) to staging.
New build failure on CentOS 7
libxl_dm.c: In function 'libxl__build_device_model_args':
libxl_dm.c:1374:27: error: 'target_path' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
drive = libxl__sprintf(gc, "%s,file=%s,format=%s",
^
libxl_dm.c:1310:25: note: 'target_path' was declared here
const char *target_path;
^
cc1: all warnings being treated as errors
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 5/9] libxl: Rearrange qemu upstream disk argument code
George Dunlap writes ("Re: [PATCH v3 5/9] libxl: Rearrange qemu upstream disk
argument code"):
> I looked through the patch in the branch provided in your reply to 0/9
> [1], and it looks correct; morever, I tested it and it and the basic
> functionality (using the "dummy" block script) still works.
>
> Reviewed-by: George Dunlap
> Tested-by: George Dunlap
>
> [1] git://xenbits.xenproject.org/people/iwj/xen.git wip.gwd.hotplug-v3.1
Thanks, I have pushed it (rebased) to staging.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 03/26] tools/libxl: Add back channel to allow migration target send data back
Olaf Hering writes ("Re: [Xen-devel] [PATCH v13 03/26] tools/libxl: Add back
channel to allow migration target send data back"):
> On Mon, Apr 04, Wei Liu wrote:
> > The fix is to patch libvirt. Looking at libvirt code I think I need to
> > patch Makefile.in to pass in an explicit LIBXL_API_VERSION number.
>
> That might be true.
>
> But shouldnt at the same time libxl.h get a change to recognize
> 0x040700? Perhaps this will be part of the release management.
It is on the release checklist. But perhaps we should do it now.
Patch welcome :-).
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Policy for force pushing smoke branch Was: Re: [xen-unstable-smoke test] 88656: regressions - FAIL [and 1 more messages]
Ian Jackson writes ("Policy for force pushing smoke branch Was: Re: [Xen-devel]
[xen-unstable-smoke test] 88656: regressions - FAIL"):
> Wei Liu writes ("Policy for force pushing smoke branch Was: Re: [Xen-devel]
> [xen-unstable-smoke test] 88656: regressions - FAIL"):
> > It would take some time for libvirt fix to land and propagate to our own
> > mirror.
>
> There is also a risk that the libvirt fix wouldn't pass osstest's push
> gate for the libvirt branch.
>
> > I would like to avoid holding backing xen.git push for too long
> > if possible. So I'm for force-pushing the smoke branch and subsequently
> > master branch if necessary.
>
> I concur. I will wait a bit for contrary opinions, though.
I have now pushed a0f793d82d5ec2d0b67c57d7130bf01c91396c60 to smoke,
apropos of:
osstest service owner writes ("[xen-unstable-smoke test] 88672: regressions -
FAIL"):
> flight 88672 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/88672/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-libvirt 5 libvirt-build fail REGR. vs.
> 88144
>
> version targeted for testing:
> xen a0f793d82d5ec2d0b67c57d7130bf01c91396c60
I'll do a force push to xen.git#master if this is the only blocker,
too. Also, any necessary force push of the osstest tested libvirt
branch.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions
On 04/04/2016 12:30 PM, David Vrabel wrote: On 04/04/16 17:21, Julien Grall wrote: (CC Stefano new e-mail address) Hello Anna-Maria, On 04/04/2016 13:32, Anna-Maria Gleixner wrote: Xen guests do not offline/online CPUs during suspend/resume and therefore FROZEN notifier transitions are not required. Add this explanation as a comment in the code to get not confused why CPU_TASKS_FROZEN masked transitions are not considered. Alternatively, these could be added even if they are not encountered. This might be more future-proof but the documentation might be clearer. Boris, Juergen, any opinion? Wouldn't the same comment need to be added to xen_hvm_cpu_notify()? -boris David>> --- a/drivers/xen/events/events_fifo.c +++ b/drivers/xen/events/events_fifo.c @@ -425,6 +425,12 @@ static int evtchn_fifo_cpu_notification( int cpu = (long)hcpu; int ret = 0; +/* + * Xen guests do not offline/online CPUs during + * suspend/resume, thus CPU_TASKS_FROZEN masked transitions + * are not considered. +*/ NIT: The '*' is not aligned with the others. If this doesn't need any other changes, I'll fix this on commit. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On Mon, Apr 04, 2016 at 06:32:48PM +0200, Dario Faggioli wrote:
> On Mon, 2016-04-04 at 17:05 +0100, George Dunlap wrote:
> > On 04/04/16 16:58, Chong Li wrote:
> > > On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
> > > wrote:
> > > > On 01/04/16 05:59, Chong Li wrote:
> > > > >
> > > > > --- a/xen/common/sched_credit2.c
> > > > > +++ b/xen/common/sched_credit2.c
> > > > > @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
> > > > > * runq lock to update csvcs. */
> > > > > spin_lock_irqsave(&prv->lock, flags);
> > > > >
> > > > > -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
> > > > > +switch ( op->cmd )
> > > > > {
> > > > > +case XEN_DOMCTL_SCHEDOP_getinfo:
> > > > > op->u.credit2.weight = sdom->weight;
> > > > > -}
> > > > > -else
> > > > > -{
> > > > > -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
> > > > > -
> > > > > +break;
> > > > > +case XEN_DOMCTL_SCHEDOP_putinfo:
> > > > > if ( op->u.credit2.weight != 0 )
> > > > > {
> > > > > struct vcpu *v;
> > > > > @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
> > > > > vcpu_schedule_unlock(lock, svc->vcpu);
> > > > > }
> > > > > }
> > > > > +break;
> > > > > +default:
> > > > > +return -EINVAL;
> > > > As does this.
> > > >
> > > > Please submit a bugfix ASAP. This will become a security
> > > > vulnerability
> > > > if Xen 4.7 is shipped without it being fixed.
> > > >
> > > > >
> > > > > }
> > > > >
> > > > > spin_unlock_irqrestore(&prv->lock, flags);
> > > Thanks for pointing this out.
> > >
> > > Dario, do you want to include this bugfix in your cleanup patch, or
> > > let me submit this?
> > If you're around and can test it, it's probably better if you can
> > send a
> > patch right a way.
> >
> Exactly. In fact:
> - we don't fold bugfixes in clanups,
> - I think I mentioned wanting to cleanup some code duplication in
> libxl, this is in xen,
> - cleanups are delayed to 4.8, while this must be fixed before
> release (or the patch/the whole feature be reverted).
>
> So, if you can't work out a fix today or, at most, tomorrow, let me
> know and I'll do it myself.
>
Yes, please fix this by tomorrow. I think it is quite straightforward to
fix anyway.
Wei.
> Sorry for not catching this during review... :-/
>
> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 7/9] x86/paravirt: Add paravirt_{read, write}_msr
On Mon, Apr 4, 2016 at 9:33 AM, David Vrabel wrote:
> On 02/04/16 15:01, Andy Lutomirski wrote:
>> This adds paravirt hooks for unsafe MSR access. On native, they
>> call native_{read,write}_msr. On Xen, they use
>> xen_{read,write}_msr_safe.
>>
>> Nothing uses them yet for ease of bisection. The next patch will
>> use them in rdmsrl, wrmsrl, etc.
>>
>> I intentionally didn't make them warn on #GP on Xen. I think that
>> should be done separately by the Xen maintainers.
> ...
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>
> Reviewed-by: David Vrabel
>
>> @@ -1092,6 +1092,26 @@ static int xen_write_msr_safe(unsigned int msr,
>> unsigned low, unsigned high)
>> return ret;
>> }
>>
>> +static u64 xen_read_msr(unsigned int msr)
>> +{
>> + /*
>> + * This will silently swallow a #GP from RDMSR. It may be worth
>> + * changing that.
>
> This probably isn't important.
>
It might be nice to do a WARN_ON_ONCE like this series does for the
native case to help shake out latent bugs.
--Andy
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On Mon, 2016-04-04 at 17:05 +0100, George Dunlap wrote:
> On 04/04/16 16:58, Chong Li wrote:
> > On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
> > wrote:
> > > On 01/04/16 05:59, Chong Li wrote:
> > > >
> > > > --- a/xen/common/sched_credit2.c
> > > > +++ b/xen/common/sched_credit2.c
> > > > @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
> > > > * runq lock to update csvcs. */
> > > > spin_lock_irqsave(&prv->lock, flags);
> > > >
> > > > -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
> > > > +switch ( op->cmd )
> > > > {
> > > > +case XEN_DOMCTL_SCHEDOP_getinfo:
> > > > op->u.credit2.weight = sdom->weight;
> > > > -}
> > > > -else
> > > > -{
> > > > -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
> > > > -
> > > > +break;
> > > > +case XEN_DOMCTL_SCHEDOP_putinfo:
> > > > if ( op->u.credit2.weight != 0 )
> > > > {
> > > > struct vcpu *v;
> > > > @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
> > > > vcpu_schedule_unlock(lock, svc->vcpu);
> > > > }
> > > > }
> > > > +break;
> > > > +default:
> > > > +return -EINVAL;
> > > As does this.
> > >
> > > Please submit a bugfix ASAP. This will become a security
> > > vulnerability
> > > if Xen 4.7 is shipped without it being fixed.
> > >
> > > >
> > > > }
> > > >
> > > > spin_unlock_irqrestore(&prv->lock, flags);
> > Thanks for pointing this out.
> >
> > Dario, do you want to include this bugfix in your cleanup patch, or
> > let me submit this?
> If you're around and can test it, it's probably better if you can
> send a
> patch right a way.
>
Exactly. In fact:
- we don't fold bugfixes in clanups,
- I think I mentioned wanting to cleanup some code duplication in
libxl, this is in xen,
- cleanups are delayed to 4.8, while this must be fixed before
release (or the patch/the whole feature be reverted).
So, if you can't work out a fix today or, at most, tomorrow, let me
know and I'll do it myself.
Sorry for not catching this during review... :-/
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 7/9] x86/paravirt: Add paravirt_{read, write}_msr
On 02/04/16 15:01, Andy Lutomirski wrote:
> This adds paravirt hooks for unsafe MSR access. On native, they
> call native_{read,write}_msr. On Xen, they use
> xen_{read,write}_msr_safe.
>
> Nothing uses them yet for ease of bisection. The next patch will
> use them in rdmsrl, wrmsrl, etc.
>
> I intentionally didn't make them warn on #GP on Xen. I think that
> should be done separately by the Xen maintainers.
...
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
Reviewed-by: David Vrabel
> @@ -1092,6 +1092,26 @@ static int xen_write_msr_safe(unsigned int msr,
> unsigned low, unsigned high)
> return ret;
> }
>
> +static u64 xen_read_msr(unsigned int msr)
> +{
> + /*
> + * This will silently swallow a #GP from RDMSR. It may be worth
> + * changing that.
This probably isn't important.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions
On 04/04/16 17:21, Julien Grall wrote: > (CC Stefano new e-mail address) > > Hello Anna-Maria, > > On 04/04/2016 13:32, Anna-Maria Gleixner wrote: >> Xen guests do not offline/online CPUs during suspend/resume and >> therefore FROZEN notifier transitions are not required. Add this >> explanation as a comment in the code to get not confused why >> CPU_TASKS_FROZEN masked transitions are not considered. Alternatively, these could be added even if they are not encountered. This might be more future-proof but the documentation might be clearer. Boris, Juergen, any opinion? David>> --- a/drivers/xen/events/events_fifo.c >> +++ b/drivers/xen/events/events_fifo.c >> @@ -425,6 +425,12 @@ static int evtchn_fifo_cpu_notification( >> int cpu = (long)hcpu; >> int ret = 0; >> >> +/* >> + * Xen guests do not offline/online CPUs during >> + * suspend/resume, thus CPU_TASKS_FROZEN masked transitions >> + * are not considered. >> +*/ > > NIT: The '*' is not aligned with the others. If this doesn't need any other changes, I'll fix this on commit. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 88622: regressions - FAIL
flight 88622 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/88622/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 60684 build-amd64-pvops 5 kernel-build fail REGR. vs. 60684 build-i386-pvops 5 kernel-build fail REGR. vs. 60684 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-ch
Re: [Xen-devel] libxl gentypes.pl "saved_FOO" oddity
On Mon, Apr 04, 2016 at 03:57:02PM +0100, Ian Jackson wrote:
> Coverity is complaining (eg, CID 1358114) about this code in
> _libxl_types.c:
>
> *** CID 1358114: Code maintainability issues (UNUSED_VALUE)
> /tools/libxl/_libxl_types.c: 11035 in libxl__device_usbdev_parse_json()
> 11029 x = libxl__json_map_get("hostaddr", x, JSON_INTEGER);
> 11030 if (x) {
> 11031 rc = libxl__uint8_parse_json(gc, x, &p->u.hostdev.hostaddr);
> 11032 if (rc)
> 11033 goto out;
> 11034 }
> >>> CID 1358114: Code maintainability issues (UNUSED_VALUE)
> >>> Assigning value from "saved_hostaddr" to "x" here, but that stored
> vale is overwritten before it can be used.
> 11035 x = saved_hostaddr;
>
> This does seem rather odd. I wasn't able to find any occurrences of
> `x' outside these save/restore regions. So x is saved and restored
> for no particular reason.
>
> The root cause seems to be the reuse of x by both inner and outer
> autogenerated code, where the generator may not know what is to be
> inserted. Why not have a separate variable for each
> libxl__json_map_get ?
>
> This code is generated by gentypes.py, near line 438. It was written
> by Ian Campbell in 2010 and doesn't seem to have been much touched
> since.
>
Actually I wrote that snippet back then. Maybe at the time I meant to
use `x' as a pointer of the node being processed for no particular
reason.
> Opinions welcome. In particular, should I attempt a patch to make
> this code less odd-looking ?
>
Sure. I don't object to this.
Wei.
> Thanks,
> Ian.
>
> (CCing Wei who seems from git log like the only person who might have
> a view.)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling
On Sat, Apr 02, 2016 at 07:01:31AM -0700, Andy Lutomirski wrote: > There are two parts here: > > * FIRST PART: EARLY EXCEPTIONS * > > The first few patches move some early panic code into C, add pt_regs > to early exception handling, and make fancy exception handlers work early. > > * SECOND PART: MSRs * > > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. ... FWIW: Reviewed-by: Borislav Petkov Definitely a step in the right direction, regardless of how we're going to be doing early_printk(), which is a tangential topic. This pile could be taken for a spin in tip. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions
(CC Stefano new e-mail address)
Hello Anna-Maria,
On 04/04/2016 13:32, Anna-Maria Gleixner wrote:
Xen guests do not offline/online CPUs during suspend/resume and
therefore FROZEN notifier transitions are not required. Add this
explanation as a comment in the code to get not confused why
CPU_TASKS_FROZEN masked transitions are not considered.
Cc: David Vrabel
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Anna-Maria Gleixner
---
arch/arm/xen/enlighten.c |6 ++
arch/x86/xen/enlighten.c |7 +++
drivers/xen/events/events_fifo.c |6 ++
3 files changed, 19 insertions(+)
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -213,6 +213,12 @@ static int xen_cpu_notification(struct n
unsigned long action,
void *hcpu)
{
+ /*
+* Xen guests do not offline/online CPUs during
+* suspend/resume, thus CPU_TASKS_FROZEN masked transitions
+* are not considered.
+*/
+
switch (action) {
case CPU_STARTING:
xen_percpu_init();
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1788,6 +1788,13 @@ static int xen_hvm_cpu_notify(struct not
void *hcpu)
{
int cpu = (long)hcpu;
+
+ /*
+* Xen guests do not offline/online CPUs during
+* suspend/resume, thus CPU_TASKS_FROZEN masked transitions
+* are not considered.
+*/
+
switch (action) {
case CPU_UP_PREPARE:
xen_vcpu_setup(cpu);
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -425,6 +425,12 @@ static int evtchn_fifo_cpu_notification(
int cpu = (long)hcpu;
int ret = 0;
+ /*
+* Xen guests do not offline/online CPUs during
+* suspend/resume, thus CPU_TASKS_FROZEN masked transitions
+* are not considered.
+ */
NIT: The '*' is not aligned with the others.
+
switch (action) {
case CPU_UP_PREPARE:
if (!per_cpu(cpu_control_block, cpu))
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/extable: Add a comment about early exception handlers
On Mon, Apr 04, 2016 at 08:46:22AM -0700, Andy Lutomirski wrote: > Borislav asked for a comment explaining why all exception handlers are > allowed early. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/mm/extable.c | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c > index 98b5f45d9d79..36fe03bc81ee 100644 > --- a/arch/x86/mm/extable.c > +++ b/arch/x86/mm/extable.c > @@ -132,6 +132,20 @@ void __init early_fixup_exception(struct pt_regs *regs, > int trapnr) > if (regs->cs != __KERNEL_CS) > goto fail; > > + /* > + * The full exception fixup machinery is available as soon as > + * the early IDT is loaded. This means that it is the > + * responsibility of extable users to either function correctly > + * when handlers are invoked early or to simply avoid causing > + * exceptions before they're ready to handle them. > + * > + * This is better than filtering which handlers can be used, > + * because refusing to call a handler here is guaranteed to > + * result in a hard-to-debug panic. > + * > + * Keep in mind that not all vectors actually get here. Early > + * fage faults, for example, are special. > + */ > if (fixup_exception(regs, trapnr)) > return; > > -- Thanks! Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On 04/04/16 16:58, Chong Li wrote:
> On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
> wrote:
>> On 01/04/16 05:59, Chong Li wrote:
>>> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
>>> index 305889a..e5d15d8 100644
>>> --- a/xen/common/sched_credit.c
>>> +++ b/xen/common/sched_credit.c
>>> @@ -1080,15 +1080,13 @@ csched_dom_cntl(
>>> * lock. Runq lock not needed anywhere in here. */
>>> spin_lock_irqsave(&prv->lock, flags);
>>>
>>> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>>> +switch ( op->cmd )
>>> {
>>> +case XEN_DOMCTL_SCHEDOP_getinfo:
>>> op->u.credit.weight = sdom->weight;
>>> op->u.credit.cap = sdom->cap;
>>> -}
>>> -else
>>> -{
>>> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>>> -
>>> +break;
>>> +case XEN_DOMCTL_SCHEDOP_putinfo:
>>> if ( op->u.credit.weight != 0 )
>>> {
>>> if ( !list_empty(&sdom->active_sdom_elem) )
>>> @@ -1101,7 +1099,9 @@ csched_dom_cntl(
>>>
>>> if ( op->u.credit.cap != (uint16_t)~0U )
>>> sdom->cap = op->u.credit.cap;
>>> -
>>> +break;
>>> +default:
>>> +return -EINVAL;
>>
>> This path returns without unlocking prv->lock.
>>
>>> }
>>>
>>> spin_unlock_irqrestore(&prv->lock, flags);
>>> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
>>> index 7ddad38..d48ed5a 100644
>>> --- a/xen/common/sched_credit2.c
>>> +++ b/xen/common/sched_credit2.c
>>> @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
>>> * runq lock to update csvcs. */
>>> spin_lock_irqsave(&prv->lock, flags);
>>>
>>> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>>> +switch ( op->cmd )
>>> {
>>> +case XEN_DOMCTL_SCHEDOP_getinfo:
>>> op->u.credit2.weight = sdom->weight;
>>> -}
>>> -else
>>> -{
>>> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>>> -
>>> +break;
>>> +case XEN_DOMCTL_SCHEDOP_putinfo:
>>> if ( op->u.credit2.weight != 0 )
>>> {
>>> struct vcpu *v;
>>> @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
>>> vcpu_schedule_unlock(lock, svc->vcpu);
>>> }
>>> }
>>> +break;
>>> +default:
>>> +return -EINVAL;
>>
>> As does this.
>>
>> Please submit a bugfix ASAP. This will become a security vulnerability
>> if Xen 4.7 is shipped without it being fixed.
>>
>>> }
>>>
>>> spin_unlock_irqrestore(&prv->lock, flags);
>>
> Thanks for pointing this out.
>
> Dario, do you want to include this bugfix in your cleanup patch, or
> let me submit this?
If you're around and can test it, it's probably better if you can send a
patch right a way.
Thanks,
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 0/9] xentrace/xenalyze support on ARM
On 04/04/16 16:50, Ben Sanda wrote: > Julien and Wei, > >>> You patches all have the same subject line. Please make them more >>> specific. See my reply to #1 for example. >> +1 >> >> Also, you should at least check that Xen still builds after applying >> each patch. Ideally, you also need to be careful to not break any >> feature currently supported. It's useful when someone needs to >> bisect the tree. >> >> For instance, you use the function get_pg_owner for ARM in patch #2 >> but introduce the function in patch #4. This will break ARM build. >> So the patch #2 should be moved after #4. >> >> Furthermore, you remove the functions get_pg_owner and put_pg_owner >> for x86 in patch #3 and then re-introduced them in patch #4. >> Therefore, the x86 will be broken after #3. In this case, it's better >> to have a patch that move the 2 functions from x86 to common. > Thank you for the comments. I apologize for the errors in the patch > format. This is my first time submitting a patch to Xen and I was > unaware that the patch set order mattered or that I had to account for > a piecewise application of the patch set. I will attempt to resubmit > with this corrected and the patch names updated. > > So then it is permissible to have multiple file changes in one > patch/commit? E.g. a patch that removes from one file and adds to > another in the same commit. I initially thought each patch/ commit was > only supposed to modify one file and that's why I did it that way One logical change per patch (wherever possible). It is fine to change more than one file in a patch. In particular, your patches 3 though 5 are one logical change, "move get_pg_owner() from being x86-specific to being common". It is an absolute must that each invidiual patch compiles and doesn't regress functionality, so the resulting patches can be bisected in the case of an error being introduced. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Intel MID / CE4100 - platform support - pnpbios support ?
On 03/31/16 13:03, Luis R. Rodriguez wrote: > Andy S, Peter, Thomas, Jiang (or who might know), > > Do Intel MID platforms exist with PNP BIOS support? What abot CE4100? > As it stands I don't see anything that would prevent this but I would > suspect a possibility might be that it doesn't. I'm sanitizing some > early boot code right now and pnpbios is one, and as I work on this, > this has come up as a question for me. > The "MID" platforms from a Linux platform perspective are the ones with SFI and DT bootloaders, respectively; by definition they don't have standard BIOS. -hpa ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/hvm: separate ioreq server code from generic hvm code
On 04/01/2016 03:54 AM, Paul Durrant wrote: The code in hvm/hvm.c related to handling I/O emulation using the ioreq server framework is large and mostly self-contained. This patch separates the ioreq server code into a new hvm/ioreq.c source module and accompanying asm-x86/hvm/ioreq.h header file. There is no intended functional change, only code movement. This may be more than just code movement. It breaks PVH. I haven't looked at what exactly is breaking but I figured I'd give a heads-up. -boris (XEN) [ Xen-4.7-unstable x86_64 debug=y Tainted:C ] (XEN) CPU:2 (XEN) RIP:e008:[] handle_hvm_io_completion+0x1bb/0x288 (XEN) RFLAGS: 00010286 CONTEXT: hypervisor (d1v0) (XEN) rax: 8302453b8000 rbx: 8300a56e3000 rcx: 8302453bffc0 (XEN) rdx: 83024da8b000 rsi: 82d080326280 rdi: 8300a56e3000 (XEN) rbp: 8302453bfd80 rsp: 8302453bfc20 r8: 830247180ed0 (XEN) r9: ff21 r10: deadbeef r11: 0246 (XEN) r12: 8300a56e3000 r13: r14: 83024da8b250 (XEN) r15: 8302453f3000 cr0: 8005003b cr4: 001526e0 (XEN) cr3: 00024db49000 cr2: (XEN) ds: 002b es: 002b fs: gs: ss: e010 cs: e008 (XEN) Xen code around (handle_hvm_io_completion+0x1bb/0x288): (XEN) 00 94 fe ff ff 4d 8b 6d <00> 8b 45 00 0f 18 08 4d 39 f5 0f 85 73 fe ff ff (XEN) Xen stack trace from rsp=8302453bfc20: (XEN)8302453b8000 8302453bfc30 (XEN) 8302453bfc88 001526e0 8302453bfc88 (XEN)0046 8300a573d000 0002 8302453f3000 (XEN)8300a29fe000 8302453bfc98 82d080178ad1 8302453bfcf8 (XEN)82d0801659e1 8302453bff18 8302453b8000 efff0002453bfcd8 (XEN)8302453a9000 0046 0082 (XEN)00fd 005077eb2c26 8302453bfd10 (XEN)82d080197ced 8300a56e3000 8302453bfd60 001526e0 (XEN)8302453bfd50 0046 83009f7e7020 83024da8b000 (XEN)8300a56e3000 8302453bfdb0 8300a56e3000 (XEN)8300a573d000 83024da8b000 0002 8302453f3000 (XEN)8302453bfda0 82d0801d4496 8300a56e3000 8300a573d000 (XEN)8302453bfdc0 82d0801f49ee 8302453bfdc0 8300a56e3000 (XEN)8302453bfe20 82d08016a952 (XEN) 8302453bfe20 8300a573d000 (XEN)00507862cc3e 8300a56e3000 830247180128 0001 (XEN)8302453bfeb0 82d08012c50f 92dd98770002 830247180140 (XEN)0002003bfe60 830247180120 8302453bfe60 82d080130034 (XEN)8302453bfeb0 8300a56e3000 01c9c380 82d0801bed01 (XEN)8300a573d000 82d080312b00 82d080312a00 (XEN) Xen call trace: (XEN)[] handle_hvm_io_completion+0x1bb/0x288 (XEN)[] hvm_do_resume+0x35/0x14b (XEN)[] vmx_do_resume+0x12c/0x143 (XEN)[] context_switch+0xf4a/0xf4c (XEN)[] schedule.c#schedule+0x5a5/0x5d7 (XEN)[] softirq.c#__do_softirq+0x82/0x8d (XEN)[] do_softirq+0x13/0x15 (XEN)[] domain.c#idle_loop+0x5e/0x6e (XEN) (XEN) Pagetable walk from : (XEN) L4[0x000] = (XEN) (XEN) (XEN) Panic on CPU 2: (XEN) FATAL PAGE FAULT (XEN) [error_code=] (XEN) Faulting linear address: ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On Mon, Apr 04, 2016 at 08:32:21AM -0700, Andy Lutomirski wrote: > Adding locking would be easy enough, wouldn't it? See patch in this thread.. > But do any platforms really boot a second CPU before switching to real > printk? I _only_ use early_printk() as printk() is a quagmire of fail :-) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V7 2/3] x86/xsaves: fix two remained issues
>>> On 31.03.16 at 10:57, wrote:
Considering this isn't the last patch in the series, the subject isn't
really nice (apart from being mis-spelled). If you e.g. replaced
"remained" by "miscellaneous", I wouldn't insist on splitting.
> 1. get_xsave_addr() will only be called when
> xsave_area_compressed(xsave) is true. So drop the
> conditional expression.
>
> 2. expand_xsave_states() will memset the area when
> get NULL from get_xsave_addr().
Reported-by: ...
> Signed-off-by: Shuai Ruan
>
> xen/arch/x86/xstate.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
> index 8c652bc..f4ea54d 100644
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -164,12 +164,8 @@ static void *get_xsave_addr(struct xsave_struct *xsave,
> const uint16_t *comp_offsets,
> unsigned int xfeature_idx)
> {
> -if ( !((1ul << xfeature_idx) & xsave->xsave_hdr.xstate_bv) )
> -return NULL;
> -
> -return (void *)xsave + (xsave_area_compressed(xsave) ?
> -comp_offsets[xfeature_idx] :
> -xstate_offsets[xfeature_idx]);
> +return (1ul << xfeature_idx) & xsave->xsave_hdr.xstate_bv ?
> + (void *)xsave + comp_offsets[xfeature_idx] : NULL;
> }
I would really have expected an ASSERT() to get added as
(documenting) replacement.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 0/9] xentrace/xenalyze support on ARM
On Mon, Apr 04, 2016 at 03:50:35PM +, Ben Sanda wrote: > Julien and Wei, > > >> You patches all have the same subject line. Please make them more > >> specific. See my reply to #1 for example. > > > > +1 > > > > Also, you should at least check that Xen still builds after applying > > each patch. Ideally, you also need to be careful to not break any > > feature currently supported. It's useful when someone needs to > > bisect the tree. > > > > For instance, you use the function get_pg_owner for ARM in patch #2 > > but introduce the function in patch #4. This will break ARM build. > > So the patch #2 should be moved after #4. > > > > Furthermore, you remove the functions get_pg_owner and put_pg_owner > > for x86 in patch #3 and then re-introduced them in patch #4. > > Therefore, the x86 will be broken after #3. In this case, it's better > > to have a patch that move the 2 functions from x86 to common. > > Thank you for the comments. I apologize for the errors in the patch > format. This is my first time submitting a patch to Xen and I was > unaware that the patch set order mattered or that I had to account for > a piecewise application of the patch set. I will attempt to resubmit > with this corrected and the patch names updated. > > So then it is permissible to have multiple file changes in one > patch/commit? E.g. a patch that removes from one file and adds to That's definitely allowed. Just think of each commit as a logically complete unit. It should compile. It should not break existing functionality. Wei. > another in the same commit. I initially thought each patch/ commit was > only supposed to modify one file and that's why I did it that way > > Thank you, > Ben Sanda ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
wrote:
> On 01/04/16 05:59, Chong Li wrote:
>> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
>> index 305889a..e5d15d8 100644
>> --- a/xen/common/sched_credit.c
>> +++ b/xen/common/sched_credit.c
>> @@ -1080,15 +1080,13 @@ csched_dom_cntl(
>> * lock. Runq lock not needed anywhere in here. */
>> spin_lock_irqsave(&prv->lock, flags);
>>
>> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>> +switch ( op->cmd )
>> {
>> +case XEN_DOMCTL_SCHEDOP_getinfo:
>> op->u.credit.weight = sdom->weight;
>> op->u.credit.cap = sdom->cap;
>> -}
>> -else
>> -{
>> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>> -
>> +break;
>> +case XEN_DOMCTL_SCHEDOP_putinfo:
>> if ( op->u.credit.weight != 0 )
>> {
>> if ( !list_empty(&sdom->active_sdom_elem) )
>> @@ -1101,7 +1099,9 @@ csched_dom_cntl(
>>
>> if ( op->u.credit.cap != (uint16_t)~0U )
>> sdom->cap = op->u.credit.cap;
>> -
>> +break;
>> +default:
>> +return -EINVAL;
>
> This path returns without unlocking prv->lock.
>
>> }
>>
>> spin_unlock_irqrestore(&prv->lock, flags);
>> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
>> index 7ddad38..d48ed5a 100644
>> --- a/xen/common/sched_credit2.c
>> +++ b/xen/common/sched_credit2.c
>> @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
>> * runq lock to update csvcs. */
>> spin_lock_irqsave(&prv->lock, flags);
>>
>> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>> +switch ( op->cmd )
>> {
>> +case XEN_DOMCTL_SCHEDOP_getinfo:
>> op->u.credit2.weight = sdom->weight;
>> -}
>> -else
>> -{
>> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>> -
>> +break;
>> +case XEN_DOMCTL_SCHEDOP_putinfo:
>> if ( op->u.credit2.weight != 0 )
>> {
>> struct vcpu *v;
>> @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
>> vcpu_schedule_unlock(lock, svc->vcpu);
>> }
>> }
>> +break;
>> +default:
>> +return -EINVAL;
>
> As does this.
>
> Please submit a bugfix ASAP. This will become a security vulnerability
> if Xen 4.7 is shipped without it being fixed.
>
>> }
>>
>> spin_unlock_irqrestore(&prv->lock, flags);
>
Thanks for pointing this out.
Dario, do you want to include this bugfix in your cleanup patch, or
let me submit this?
Chong
--
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 88672: regressions - FAIL
flight 88672 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/88672/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 88144 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen a0f793d82d5ec2d0b67c57d7130bf01c91396c60 baseline version: xen 96ae556569b8eaedc0bb242932842c3277b515d8 Last test of basis88144 2016-03-31 13:06:39 Z4 days Failing since 88279 2016-04-01 14:03:55 Z3 days 33 attempts Testing same since88672 2016-04-04 14:03:45 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Changlong Xie Chong Li Dario Faggioli George Dunlap Ian Campbell Ian Jackson Jan Beulich Juergen Gross Kevin Tian Konrad Rzeszutek Wilk Meng Xu Mike Meyer Olaf Hering Paul Durrant Roger Pau Monne Roger Pau Monné Sisu Xi Wei Liu Wen Congyang Yang Hongyang jobs: build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass 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. (No revision log; it would be 856 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 0/9] xentrace/xenalyze support on ARM
Julien and Wei, >> You patches all have the same subject line. Please make them more >> specific. See my reply to #1 for example. > > +1 > > Also, you should at least check that Xen still builds after applying > each patch. Ideally, you also need to be careful to not break any > feature currently supported. It's useful when someone needs to > bisect the tree. > > For instance, you use the function get_pg_owner for ARM in patch #2 > but introduce the function in patch #4. This will break ARM build. > So the patch #2 should be moved after #4. > > Furthermore, you remove the functions get_pg_owner and put_pg_owner > for x86 in patch #3 and then re-introduced them in patch #4. > Therefore, the x86 will be broken after #3. In this case, it's better > to have a patch that move the 2 functions from x86 to common. Thank you for the comments. I apologize for the errors in the patch format. This is my first time submitting a patch to Xen and I was unaware that the patch set order mattered or that I had to account for a piecewise application of the patch set. I will attempt to resubmit with this corrected and the patch names updated. So then it is permissible to have multiple file changes in one patch/commit? E.g. a patch that removes from one file and adds to another in the same commit. I initially thought each patch/ commit was only supposed to modify one file and that's why I did it that way Thank you, Ben Sanda ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V7 1/3] x86/xsaves: fix overwriting between non-lazy/lazy xsaves
>>> On 31.03.16 at 10:57, wrote: > xsaves will not be used until supervised state is introduced in hypervisor. > And XSTATE_XSAVES_ONLY (indicates supervised state is understood in xen) > is instroduced, the use of xsaves depend on whether XSTATE_XSAVES_ONLY There's still a spelling mistake here, despite me having pointed it out before (you fixed one instance, but not the other). This could be dealt with upon commit, though. > is set in xcr0_accum. Btw, I think this shouldn't be a #define, as it can - afaict - be derived from CPUID output. But this can easily be a follow-up patch, even one that doesn't make it into 4.7. > Signed-off-by: Shuai Ruan > Reported-by: Jan Beulich Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early
On Sun, Apr 3, 2016 at 7:10 AM, Borislav Petkov wrote: > On Sun, Apr 03, 2016 at 06:55:00AM -0700, Andy Lutomirski wrote: >> > No, please don't fail at early boot. >> > >> > Early boot is just about the *worst* situation to try to debug odd >> > failures, exactly since things like printk may not be reliable, and >> > things won't get logged etc. >> > >> > So particularly during early boot we should try as hard as possible >> > not to crash - even if it means not being able to log about a problem. >> > At least that way you have a hopefully working machine and can *maybe* >> > debug things. >> > >> >> In this regard, at least, my patch is the right approach. Calling the >> handler, whatever it is, is less likely to panic than refusing to call >> it. > > Ok, good. > > But can we pretty please document this whole situation, i.e., the > fact that we're trying really really hard not to fail early boot for > debuggability reasons - either in the commit message or better in the > code, for future reference. I think this is an important aspect to hold > down. I emailed out a followup patch to add a comment. --Andy > > Thanks. > > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. -- Andy Lutomirski AMA Capital Management, LLC ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/extable: Add a comment about early exception handlers
Borislav asked for a comment explaining why all exception handlers are allowed early. Signed-off-by: Andy Lutomirski --- arch/x86/mm/extable.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c index 98b5f45d9d79..36fe03bc81ee 100644 --- a/arch/x86/mm/extable.c +++ b/arch/x86/mm/extable.c @@ -132,6 +132,20 @@ void __init early_fixup_exception(struct pt_regs *regs, int trapnr) if (regs->cs != __KERNEL_CS) goto fail; + /* +* The full exception fixup machinery is available as soon as +* the early IDT is loaded. This means that it is the +* responsibility of extable users to either function correctly +* when handlers are invoked early or to simply avoid causing +* exceptions before they're ready to handle them. +* +* This is better than filtering which handlers can be used, +* because refusing to call a handler here is guaranteed to +* result in a hard-to-debug panic. +* +* Keep in mind that not all vectors actually get here. Early +* fage faults, for example, are special. +*/ if (fixup_exception(regs, trapnr)) return; -- 2.5.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARMv8: New board bring up hangs in kernel start?
Hi Julien, On 01.04.2016 18:34, Julien Grall wrote: On 31/03/16 18:41, Dirk Behme wrote: Hello Julien, Hello Dirk, On 29.03.2016 20:53, Julien Grall wrote: On 23/03/16 17:24, Dirk Behme wrote: trying to bring up Xen on a new ARMv8 64-bit Cortex A57 eval board, I get [1] and then its hanging there. The logs look normal. Do you know where the kernel get stuck? You can press CTRL-a 3 times to get access to the Xen console and then press: * 0 => dump Dom0 registers * d => dump registers Hmm, CTRL-a 3 times doesn't seem to work, either. This does need working interrupts, too? I.e. that it doesn't work is an additional hint that anything with the interrupt handling might be wrong? The entry point for all the interrupts is do_IRQ. You can add a breakpoint there to know if you receive interrupts. Maybe I should debug this, first. It's handled by Xen's drivers/char/console.c / serial.c and the board specific UART device driver, correct? The generic IRQ code (see do_IRQ) will dispatch the interrupt directly to the interrupt handler you specific via setup_irq/request_irq. Usually this handler is specific to the driver. I'd guess that it hangs due to missing timer interrupt, maybe missing interrupts at all? Any hints how to debug this? Or where to look? It might be possible that the board's firmware (arm-trusted-firmware based) doesn't configure anything correctly. Firmware is running at EL3, Xen at EL2. The same kernel is running fine without Xen. Using a JTAG debugger I've put breakpoints into xen/arch/arm/time.c timer_interrupt() & vtimer_interrupt() but these don't seem to be called at all (?) They should be called if the timer is configured correctly. Best regards Dirk [1] [...] > (XEN) Checking for initrd in /chosen > (XEN) RAM: 4800 - 7fff > (XEN) > (XEN) MODULE[0]: 4800 - 480058a2 Device Tree > (XEN) MODULE[1]: 4820 - 48c0 Kernel > (XEN) > (XEN) Command line: console=dtuart dom0_mem=512M loglvl=all > (XEN) Placing Xen at 0x7fe0-0x8000 > (XEN) Update BOOTMOD_XEN from 4900-49112e01 => > 7fe0-7ff12e01 > (XEN) Domain heap initialised > (XEN) Platform: ARMv8 Cortex A57 64-bit eval board > (XEN) Taking dtuart configuration from /chosen/stdout-path > (XEN) Looking for dtuart at "/soc/serial@e6e88000", options "" > Xen 4.7-unstable > (XEN) Xen version 4.7-unstable (dirk@build) (aarch64-poky-linux-gcc > (Linaro GCC 4.9-2015.03) 4.9.3 20150311 (prerelease)) debug=y Mon Mar 21 > 09:15:03 CET 2016 > (XEN) Latest ChangeSet: Tue Feb 9 09:37:15 2016 +0100 git:b0a2893 I can't find this changeset in tree. Can you provide your baseline commit and the list of patches you applied on top? This is 483ad4439f7fc7 xen-access: minor fixes plus a local patch to support the board's serial port. Is it a patch to add earlyprintk or a completely new driver? Just earlyprintk. Also have you tried a newer version of Xen? I've switched to the recent master a6f2cdb63 x86/hvm/viridian: keep APIC assist page mapped now. No difference. I'll have a deeper look into the interrupt configuration. Is there anywhere some basic description which interrupts are supposed to be handled by XEN and which by the Linux kernel? I.e. how the ARM GIC should be configured regarding the distributor/CPU/virtual parts? All the interrupts are taken by Xen. The function do_IRQ in Xen will dispatch the IRQ either to a guest or call a Xen specific handler. Xen handles only a limited number of interrupt: * timers * UART * SMMU The rest is either routed to guests or blacklisted by Xen. Ok, thanks, that helps :) Once I have it working, maybe I post a patch to add this info to the documentation. Just an other question: On ARMv8 64-bit Xen is supposed to be started at EL2 *nonsecure*, correct? It looks to me that the GICv2 on my board is already partly configured by the firmware at secure EL3. That does mean, whatever gicv2_dist_init() and gicv2_cpu_init() are supposed to do, they can't do it (completely) because they don't have access to the secure part of the GIC (?) Best regards Dirk ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On 4/4/2016 8:32 AM, Andy Lutomirski wrote: Adding locking would be easy enough, wouldn't it? But do any platforms really boot a second CPU before switching to real printk? Given that I see all the smpboot stuff in dmesg, I guess real printk happens first. I admit I haven't actually checked. adding locking also makes things more fragile in terms of getting the last thing out before you go down in flaming death until it's a proven problem, this early, get the message out at all is more important than getting it out perfectly, sometimes. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On Apr 4, 2016 4:51 AM, "Jan Kara" wrote:
>
> On Sat 02-04-16 13:58:19, Andy Lutomirski wrote:
> > [cc Jan Kara]
> >
> > On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov wrote:
> > > On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote:
> > >> Given that I this isn't really a regression with my patches (it
> > >> probably never worked much better on 32-bit and the regs never would
> > >> have shown at all on 64-bit),
> > >
> > > You're right. That thing calls printk *and* early_printk, WTF:
> > >
> > > #ifdef CONFIG_EARLY_PRINTK
> > >
> > > call early_printk
> > > ...
> > >
> > > call dump_stack
> > >
> > > ...
> > >
> > > call __print_symbol
> > >
> > > those last two call printk. Great.
> > >
> > >> I propose a different approach: make
> > >> printk work earlier. Something like:
> > >>
> > >> if (early) {
> > >> early_printk(args);
> > >> }
> > >>
> > >> or early_vprintk or whatever.
> > >>
> > >> If the cost of a branch mattered, this could be alternative-patched
> > >> out later on, but that seems silly. I also bet that a more sensible
> > >> fallback could be created in which printk would try to use an early
> > >> console if there's no real console.
> > >
> > > So how about this:
> > >
> > > printk() does
> > >
> > > vprintk_func = this_cpu_read(printk_func);
> > >
> > > and that's
> > >
> > > DEFINE_PER_CPU(printk_func_t, printk_func) = vprintk_default
> > >
> > > I guess we can make that function be early_printk-something and once
> > > printk is initialized, we overwrite it with vprintk_default.
> > >
> > > Elegant and no need for if branches and alternatives.
> > >
> > > Hmmm.
> >
> > Jan, IIRC you were looking at printk recently-ish. Any thoughts here?
>
> Sounds like a good idea to me. I've also consulted this with Petr Mladek
> (added to CC) who is using printk_func per-cpu variable in his
> printk-from-NMI patches and he also doesn't see a problem with this.
>
> I was just wondering about one thing - this way we add more early printks
> if I understand your intention right. Are we guaranteed that they happen
> only from a single CPU? Because currently there is no locking in
> early_printk() and thus we can end up writing to early console several
> messages in parallel from different CPUs. Not sure what's going to happen
> in that case...
Adding locking would be easy enough, wouldn't it?
But do any platforms really boot a second CPU before switching to real
printk? Given that I see all the smpboot stuff in dmesg, I guess real
printk happens first. I admit I haven't actually checked.
--Andy
>
> Honza
> --
> Jan Kara
> SUSE Labs, CR
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 03/26] tools/libxl: Add back channel to allow migration target send data back
On Mon, Apr 04, Wei Liu wrote:
> The fix is to patch libvirt. Looking at libvirt code I think I need to
> patch Makefile.in to pass in an explicit LIBXL_API_VERSION number.
That might be true.
But shouldnt at the same time libxl.h get a change to recognize
0x040700? Perhaps this will be part of the release management.
For the time being this change fixes it for me:
+++ libvirt.spec(working copy)
@@ -1163,6 +1163,7 @@
autoreconf -f -i
export CFLAGS="$RPM_OPT_FLAGS"
+export CFLAGS="$CFLAGS -DLIBXL_API_VERSION=0x040500"
%configure --disable-static --with-pic \
%{?_without_xen} \
%{?_without_qemu} \
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 27/28] xsplice: Add support for shadow variables.
>>> On 24.03.16 at 21:00, wrote:
> Shadow variables are a piece of infrastructure to be used by xsplice
> modules. They are used to attach a new piece of data to an existing
> structure in memory.
An already known question again: Out of recent XSAs, how many
needed such? I.e. can#t we put this off for now?
> Martin Pohlack also mentions that using the SHADOW_SLOTS of small
> prime numbers has the advantage of having a simple hash function.
This reads kind of backwards.
> +void xsplice_shadow_free(const void *obj, const char *var)
> +{
> +struct shadow_var *entry, *shadow = NULL;
> +unsigned int slot;
> +struct hlist_node *next;
> +
> +slot = (unsigned long)obj % SHADOW_SLOTS;
> +
> +spin_lock(&shadow_lock);
> +hlist_for_each_entry(entry, next, &shadow_tbl[slot], list)
> +{
> +if ( entry->obj == obj &&
> + !strcmp(entry->var, var) )
> +{
> +shadow = entry;
> +break;
> +}
> +}
> +if (shadow)
Coding style.
> +{
> +hlist_del(&shadow->list);
> +xfree(shadow->data);
> +xfree(shadow);
> +}
> +spin_unlock(&shadow_lock);
> +}
Uniqueness not being guaranteed by the allocation function, how
can you free the first hit here ...
> +void *xsplice_shadow_get(const void *obj, const char *var)
> +{
> +struct shadow_var *entry;
> +unsigned int slot;
> +struct hlist_node *next;
> +void *ret = NULL;
> +
> +slot = (unsigned long)obj % SHADOW_SLOTS;
> +
> +spin_lock(&shadow_lock);
> +hlist_for_each_entry(entry, next, &shadow_tbl[slot], list)
> +{
> +if ( entry->obj == obj &&
> + !strcmp(entry->var, var) )
> +{
> +ret = entry->data;
> +break;
> +}
> +}
> +
> +spin_unlock(&shadow_lock);
> +return ret;
> +}
.. or return the first match here?
> +static int __init xsplice_shadow_init(void)
> +{
> +int i;
unsigned int
> --- a/xen/include/xen/xsplice_patch.h
> +++ b/xen/include/xen/xsplice_patch.h
> @@ -56,4 +56,40 @@ typedef void (*xsplice_unloadcall_t)(void);
> #define XSPLICE_UNLOAD_HOOK(_fn) \
> xsplice_unloadcall_t __attribute__((weak)) xsplice_unload_data
> __section(".xsplice.hooks.unload") = _fn;
>
> +
> +/*
> + * The following definitions are to be used in patches. They are taken
> + * from kpatch.
> + */
> +
> +/*
> + * xsplice shadow variables
> + *
> + * These functions can be used to add new "shadow" fields to existing data
> + * structures. For example, to allocate a "newpid" variable associated with
> an
> + * instance of task_struct, and assign it a value of 1000:
> + *
> + * struct task_struct *tsk = current;
> + * int *newpid;
> + * newpid = xsplice_shadow_alloc(tsk, "newpid", sizeof(int));
> + * if (newpid)
> + * *newpid = 1000;
> + *
> + * To retrieve a pointer to the variable:
> + *
> + * struct task_struct *tsk = current;
> + * int *newpid;
> + * newpid = xsplice_shadow_get(tsk, "newpid");
> + * if (newpid)
> + * printk("task newpid = %d\n", *newpid); // prints "task newpid = 1000"
> + *
> + * To free it:
> + *
> + * xsplice_shadow_free(tsk, "newpid");
> + */
While this indeed provides some basic understanding, I think this
should be using a more Xen-affine example, and I fail to see how
with particularly the example given this is going to be useful: How
would the patch module sanely and within reasonable time get
hold of all instances of a particular type?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] libxl: Set rc on failure of usbdev_busaddr_to_busid
We must set rc before using `goto out'.
Bug introduced in bf7628f0 "libxl: add pvusb API".
CID: 1358113
Signed-off-by: Ian Jackson
CC: cover...@xenproject.org
CC: Simon Cao
CC: George Dunlap
CC: Chunyan Liu
---
tools/libxl/libxl_pvusb.c |1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
index 5f92628..6f53317 100644
--- a/tools/libxl/libxl_pvusb.c
+++ b/tools/libxl/libxl_pvusb.c
@@ -905,6 +905,7 @@ static int libxl__device_usbdev_add_xenstore(libxl__gc *gc,
uint32_t domid,
usbdev->u.hostdev.hostaddr);
if (!busid) {
LOG(DEBUG, "Fail to get busid of usb device");
+rc = ERROR_FAIL;
goto out;
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] libxl: Do not leak data on error path from libxl__read_sysfs_file_contents
Bug introduced in bc023ecd "libxl_utils: add internal function to read sysfs file contents" CID: 1358108 Signed-off-by: Ian Jackson CC: cover...@xenproject.org CC: Chunyan Liu --- tools/libxl/libxl_utils.c |1 + 1 file changed, 1 insertion(+) diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index ceb8825..bd58a52 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -466,6 +466,7 @@ int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename, e = errno; assert(e != ENOENT); if (f) fclose(f); +free(data); return e; } -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On 01/04/16 05:59, Chong Li wrote:
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index 305889a..e5d15d8 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -1080,15 +1080,13 @@ csched_dom_cntl(
> * lock. Runq lock not needed anywhere in here. */
> spin_lock_irqsave(&prv->lock, flags);
>
> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
> +switch ( op->cmd )
> {
> +case XEN_DOMCTL_SCHEDOP_getinfo:
> op->u.credit.weight = sdom->weight;
> op->u.credit.cap = sdom->cap;
> -}
> -else
> -{
> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
> -
> +break;
> +case XEN_DOMCTL_SCHEDOP_putinfo:
> if ( op->u.credit.weight != 0 )
> {
> if ( !list_empty(&sdom->active_sdom_elem) )
> @@ -1101,7 +1099,9 @@ csched_dom_cntl(
>
> if ( op->u.credit.cap != (uint16_t)~0U )
> sdom->cap = op->u.credit.cap;
> -
> +break;
> +default:
> +return -EINVAL;
This path returns without unlocking prv->lock.
> }
>
> spin_unlock_irqrestore(&prv->lock, flags);
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 7ddad38..d48ed5a 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
> * runq lock to update csvcs. */
> spin_lock_irqsave(&prv->lock, flags);
>
> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
> +switch ( op->cmd )
> {
> +case XEN_DOMCTL_SCHEDOP_getinfo:
> op->u.credit2.weight = sdom->weight;
> -}
> -else
> -{
> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
> -
> +break;
> +case XEN_DOMCTL_SCHEDOP_putinfo:
> if ( op->u.credit2.weight != 0 )
> {
> struct vcpu *v;
> @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
> vcpu_schedule_unlock(lock, svc->vcpu);
> }
> }
> +break;
> +default:
> +return -EINVAL;
As does this.
Please submit a bugfix ASAP. This will become a security vulnerability
if Xen 4.7 is shipped without it being fixed.
> }
>
> spin_unlock_irqrestore(&prv->lock, flags);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 5/9] libxl: Rearrange qemu upstream disk argument code
On 01/04/16 15:31, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v3 5/9] libxl: Rearrange qemu upstream disk
> argument code"):
>> Reorganize the qemuu disk argument code to make a clean separation
>> between finding a file to use, and constructing the parameters:
>
> This didn't apply to staging, since colo went in.
> I have tried to rebase it and the result compiles.
>
> Can you check it's right please ?
>
> Thanks,
> Ian.
>
> From 6ab86b63462c8e6dc243c796f5ea10240aadc5de Mon Sep 17 00:00:00 2001
> From: George Dunlap
> Date: Thu, 24 Mar 2016 17:18:33 +
> Subject: [PATCH] libxl: Rearrange qemu upstream disk argument code
>
> Reorganize the qemuu disk argument code to make a clean separation
> between finding a file to use, and constructing the parameters:
>
> * Rename pdev_path to target_path
>
> * Only use qemu_disk_format_string() in circumstances where qemu may
> be interpreting the disk (i.e., backend==QDISK). In all other cases,
> it should use RAW.
>
> * Share as much as possible between the is_cdrom path and the normal
> path.
>
> This is mainly prep for sharing the local path finder with the
> bootloader; but it does allow cdroms to use any backend that a normal
> disk can use. Previously this was limited to RAW files or things that
> qemu could handle directly; as of this changeset, it now includes tap
> disks; and in future changesets it will include backends with custom
> block scripts.
>
> NB that this retains an existing bug, that disks with custom block
> scripts or non-dom0 backends will have the bogus pdev_path passed in
> to qemu, most likely resulting in qemu exiting with an error. This
> will be fixed in follow-up patches.
>
> Signed-off-by: George Dunlap
> Signed-off-by: Ian Jackson
I looked through the patch in the branch provided in your reply to 0/9
[1], and it looks correct; morever, I tested it and it and the basic
functionality (using the "dummy" block script) still works.
Reviewed-by: George Dunlap
Tested-by: George Dunlap
[1] git://xenbits.xenproject.org/people/iwj/xen.git wip.gwd.hotplug-v3.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] New Defects reported by Coverity Scan for XenProject
scan-ad...@coverity.com writes ("New Defects reported by Coverity Scan for
XenProject"):
> Please find the latest report on new defect(s) introduced to XenProject found
> with Coverity Scan.
>
> 35 new defect(s) introduced to XenProject found with Coverity Scan.
> 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the
> recent build analyzed by Coverity Scan.
>
> New defect(s) Reported-by: Coverity Scan
> Showing 20 of 35 defect(s)
I have been through the tools reports here. None of them are security
problems in released branches.
I would like some advice from Coverity experts on the two below:
> ** CID 1358088: Concurrent data access violations (MISSING_LOCK)
Applies to 1358086..1358105 inclusive. Here is a sample:
> *** CID 1358088: Concurrent data access violations (MISSING_LOCK)
> /tools/libxl/libxl_event.c: 2189 in libxl__ao_progress_report()
> 2183 } else if (how->callback) {
> 2184 libxl__aop_occurred *aop = libxl__zalloc(&egc->gc,
> sizeof(*aop));
> 2185 ao->progress_reports_outstanding++;
> 2186 aop->ao = ao;
> 2187 aop->ev = ev;
> 2188 aop->how = how;
> >>> CID 1358088: Concurrent data access violations (MISSING_LOCK)
> >>> Accessing "egc->aops_for_callback.tqh_last" without holding lock
> >>> "libxl__ctx.lock". Elsewhere, "libxl__egc.aops_for_callback.tqh_last" is
> >>> accessed with "libxl__ctx.lock" held 34 out of 44 times.
> 2189 LIBXL_TAILQ_INSERT_TAIL(&egc->aops_for_callback, aop, entry);
> 2190 LOG(DEBUG,"ao %p: progress report: callback queued
> aop=%p",ao,aop);
> 2191 } else {
> 2192 LOG(DEBUG,"ao %p: progress report: event queued ev=%p
> type=%s",
> 2193 ao, ev, libxl_event_type_to_string(ev->type));
> 2194 libxl__event_occurred(egc, ev);
This is a false positive. An egc is always allocated on the stack of
the thread that uses it. It is only ever used by that thread. So
does not need to be protected by a lock.
Is there a way we can teach Coverity about this ?
> ** CID 1358085: Incorrect expression (IDENTICAL_BRANCHES)
> /tools/libxl/_libxl_types.c: 5611 in libxl_device_usbdev_gen_json()
Applies to 1358081..1358084 inclusive.
Here is a sample:
> *** CID 1358085: Incorrect expression (IDENTICAL_BRANCHES)
> /tools/libxl/_libxl_types.c: 5611 in libxl_device_usbdev_gen_json()
> 5605 if (s != yajl_gen_status_ok)
> 5606 goto out;
> 5607 break;
> 5608 }
> 5609 }
> 5610 s = yajl_gen_map_close(hand);
> >>> CID 1358085: Incorrect expression (IDENTICAL_BRANCHES)
> >>> The same code is executed when the condition "s !=
> >>> yajl_gen_status_ok" is true or false, because the code in the if-then
> >>> branch and after the if statement is identical. Should the if statement
> >>> be removed?
> 5611 if (s != yajl_gen_status_ok)
> 5612 goto out;
> 5613 out:
> 5614 return s;
This is a false positive arising from autogenerated code. The
autogenerated code naturally has a completely systematic error
handling pattern, which leads to it sometimes doing this:
if (error)
goto out;
out:
/* exit path */
Is there a way to arrange to always persuade Coverity that this is
intentional ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Redundant lstats in libxl_pvusb.c
In libxl_usb.c, usbintf_get_drvpath calls stat(2) on the driver sysfs
path, and then realpath on the same path.
And bind_usbintf calls stat(2) on the driver directory path, and then
open(2) on a file in that directory.
It seems to be that in both cases, libxl could simply directly access
the target object. Ie, it could always call realpath, and always call
open. Appropriate error handling would deal with the cases currently
dealt with by the stat.
Am I wrong about this ?
I'm prompted to look at this by Coverity, Coverity thinks that this
stat-then-realpath, or stat-then-open, might be a TOCTOU security
problem. I think it's wrong, but it would be nice to tidy up the code
and eliminate these complaints.
If I am right, I'd appreciate patch(es). They should mention
CID: 1358112
CID: 1358111
for these two functions, respectively.
Thanks,
Ian.
> *** CID 1358112: Security best practices violations (TOCTOU)
> /tools/libxl/libxl_pvusb.c: 995 in usbintf_get_drvpath()
> 989 spath = GCSPRINTF(SYSFS_USB_DEV "/%s/driver", intf);
> 990
> 991 r = lstat(spath, &st);
> 992 if (r == 0) {
> 993 /* Find the canonical path to the driver. */
> 994 dp = libxl__zalloc(gc, PATH_MAX);
> >>> CID 1358112: Security best practices violations (TOCTOU)
> >>> Calling function "realpath" that uses "spath" after a check function.
> >>> This can cause a time-of-check, time-of-use race condition.
> 995 dp = realpath(spath, dp);
> 996 if (!dp) {
> 997 LOGE(ERROR, "get realpath failed: '%s'", spath);
> 998 return ERROR_FAIL;
> 999 }
> 1000 } else if (errno == ENOENT) {
> *** CID 1358111: Security best practices violations (TOCTOU)
> /tools/libxl/libxl_pvusb.c: 1061 in bind_usbintf()
> 1055 return 0;
> 1056 if (r < 0 && errno != ENOENT)
> 1057 return ERROR_FAIL;
> 1058
> 1059 path = GCSPRINTF("%s/bind", drvpath);
> 1060
> >>> CID 1358111: Security best practices violations (TOCTOU)
> >>> Calling function "open" that uses "path" after a check function. This
> >>> can cause a time-of-check, time-of-use race condition.
> 1061 fd = open(path, O_WRONLY);
> 1062 if (fd < 0) {
> 1063 LOGE(ERROR, "open file failed: '%s'", path);
> 1064 rc = ERROR_FAIL;
> 1065 goto out;
> 1066 }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded.
>>> On 24.03.16 at 21:00, wrote:
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -566,6 +566,27 @@ static int prepare_payload(struct payload *payload,
> if ( !payload->id.len || !payload->id.p )
> return -EINVAL;
> }
> +/* Make sure it is not a duplicate. */
> +if ( payload->id.len )
The conditional is pointless considering the one visible in context
above.
> +{
> +struct payload *data;
> +
> +spin_lock_recursive(&payload_lock);
> +list_for_each_entry ( data, &payload_list, list )
> +{
> +/* No way payload is on the list. */
> +ASSERT( data != payload );
> +if ( data->id.len &&
> + !memcmp(data->id.p, payload->id.p, data->id.len) )
> +{
> +spin_unlock_recursive(&payload_lock);
> +dprintk(XENLOG_DEBUG, "%s%s: Already loaded as %s!\n",
> +XSPLICE, elf->name, data->name);
> +return -EEXIST;
> +}
> +}
> +spin_unlock_recursive(&payload_lock);
Similar question as asked elsewhere - with the lock getting dropped
here, how is the "no duplicate" state going to be ensured by the
time you actually load and insert this payload?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 25/28] xsplice: Print dependency and payloads build_id in the keyhandler.
>>> On 24.03.16 at 21:00, wrote:
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -1514,6 +1514,11 @@ static void xsplice_printall(unsigned char key)
> if ( !(i % 100) )
> process_pending_softirqs();
> }
> +if ( data->id.len )
> +printk("build-id=%*phN\n", data->id.len, data->id.p);
> +
> +if ( data->dep.len )
> +printk("depend-on=%*phN\n", data->dep.len, data->dep.p);
> }
>
> spin_unlock_recursive(&payload_lock);
Looks certainly fine, but wouldn't this better be part of patch 23?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 0/9] xentrace/xenalyze support on ARM
Hello, On 04/04/2016 15:11, Wei Liu wrote: On Fri, Apr 01, 2016 at 04:33:44PM -0400, Benjamin Sanda wrote: --- Changed since v1: * Removed Flask changes as deemed uncessesary and unclear in purpose * Corrected all commit messages to be line limited to 72 chars * Implimented v1 review comments as indicated in each file's commit log. Benjamin Sanda (9): xenalyze: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform You patches all have the same subject line. Please make them more specific. See my reply to #1 for example. +1 Also, you should at least check that Xen still builds after applying each patch. Ideally, you also need to be careful to not break any feature currently supported. It's useful when someone needs to bisect the tree. For instance, you use the function get_pg_owner for ARM in patch #2 but introduce the function in patch #4. This will break ARM build. So the patch #2 should be moved after #4. Furthermore, you remove the functions get_pg_owner and put_pg_owner for x86 in patch #3 and then re-introduced them in patch #4. Therefore, the x86 will be broken after #3. In this case, it's better to have a patch that move the 2 functions from x86 to common. Finally, please CC all the x86 maintainers (Jan and Andrew) on x86 changes. You need to manually check the CCs as under certain conditions the script get_maintainers.pl may not return all the relevant maintainers. I will wait the next iteration of this series to review the code. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Wrong use of sizeof() in libxl_pvusb.c
Coverity complains, rightly, as follows:
> *** CID 1358110: Incorrect expression (SIZEOF_MISMATCH)
> /tools/libxl/libxl_pvusb.c: 1068 in bind_usbintf()
> 1062 if (fd < 0) {
> 1063 LOGE(ERROR, "open file failed: '%s'", path);
> 1064 rc = ERROR_FAIL;
> 1065 goto out;
> 1066 }
> 1067
> >>> CID 1358110: Incorrect expression (SIZEOF_MISMATCH)
> >>> Passing argument "intf" of type "char const *" and argument "8L /*
> >>> sizeof (intf) */" to function "libxl_write_exactly" is suspicious.
> 1068 if (libxl_write_exactly(CTX, fd, intf, sizeof(intf), path,
> intf)) {
There is another occurrence in unbind_usbintf (CID 1358109).
AFAICT the right thing is probably to replace sizeof by strlen, but I
am not 100% sure.
Note that on i386 and armhf, sizeof(intf) will always be 4, and on
amd64 and arm64, always 8. So this will write() garbage data into
sysfs. Presumably the kernel doesn't notice because the garbage is
generally (a) in valid address space for the process and (b) starts
with the nul byte at the end of the string.
Chunyan: please provide a patch (or procure that someone else does
so).
Please mention, in your commit message,
CID: 1358110
CID: 1358109
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
>>> On 24.03.16 at 21:00, wrote:
> @@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to
> match against.
> The old code allows much more flexibility and an additional guard,
> but is more complex to implement.
>
> +The second option which requires an build-id of the hypervisor
> +is implemented in the Xen Project hypervisor.
> +
> +Specifically each payload has two build-id ELF notes:
> + * The build-id of the payload itself (generated via --build-id).
> + * The build-id of the payload it depends on (extracted from the
> + the previous payload or hypervisor during build time).
> +
> +This means that the very first payload depends on the hypervisor
> +build-id.
So this is mean to be a singly linked chain, not something with
branches and alike, allowing independent patches to be applied
solely based on the base build ID? Is such a restriction not going
to get in the way rather sooner than later?
> +# Not Yet Done
> +
> +This is for further development of xSplice.
> +
> +## Goals
> +
> +The implementation must also have a mechanism for:
> +
> + * Be able to lookup in the Xen hypervisor the symbol names of functions
> from the ELF payload.
> + * Be able to patch .rodata, .bss, and .data sections.
> + * Further safety checks (blacklist of which functions cannot be patched,
> check
> + the stack, make sure the payload is built with same compiler as
> hypervisor,
> + and NMI/MCE handlers and do_nmi for right now - until an safe solution is
> found).
> + * NOP out the code sequence if `new_size` is zero.
> + * Deal with other relocation types: R_X86_64_[8,16,32,32S],
> R_X86_64_PC[8,16,64] in payload file.
Does this belong here? Doesn't this duplicate something I saw earlier?
> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -70,10 +70,29 @@ const char *xen_deny(void)
> /* Defined in linker script. */
> extern const Elf_Note __note_gnu_build_id_start[],
> __note_gnu_build_id_end[];
>
> +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len)
> +{
> +/* Check if we really have a build-id. */
> +if ( NT_GNU_BUILD_ID != n->type )
> +return -ENODATA;
> +
> +/* Sanity check, name should be "GNU" for ld-generated build-id. */
> +if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
> +return -ENODATA;
For the embedded notes this suffices as verification, but I question
this being enough for a patch module: No part of the note should
exceed the containing section. And maybe there are other things.
> #else
>
> +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len)
> +{
> +return -ENODATA;
> +}
What case is this needed for, considering that only xSplice code
should be calling it, and that code depends on build ID availability.
> +static int build_id_dep(struct payload *payload, bool_t ignore)
> +{
> +const void *id = NULL;
> +unsigned int len = 0;
> +int rc;
> +const char *name = "hypervisor";
> +
> +ASSERT(payload->dep.len && payload->dep.p);
> +
> +/* First time user is against hypervisor. */
> +if ( ignore || list_empty(&applied_list) )
"ignore" is perhaps not the most descriptive name, as you aren't
ignoring anything here. Maybe "internal"? And then maybe have
the caller pass the argument using list_empty(&applied_list)
instead of you checking it here?
> --- a/xen/include/xen/version.h
> +++ b/xen/include/xen/version.h
> @@ -17,4 +17,7 @@ const char *xen_deny(void);
> #include
> int xen_build_id(const void **p, unsigned int *len);
>
> +#include
> +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len);
The #include is misplaced again, and I'm rather hesitant to see
version.h gain this dependency. Couldn't this go into xen/elf.h?
> --- a/xen/include/xen/xsplice.h
> +++ b/xen/include/xen/xsplice.h
> @@ -40,6 +40,11 @@ struct xsplice_symbol {
> bool_t new_symbol;
> };
>
> +struct xsplice_build_id {
> + const void *p;
> + unsigned int len;
> +};
This isn't being used outside of xsplice.c, so please define the
structure there.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] libxl gentypes.pl "saved_FOO" oddity
Coverity is complaining (eg, CID 1358114) about this code in
_libxl_types.c:
*** CID 1358114: Code maintainability issues (UNUSED_VALUE)
/tools/libxl/_libxl_types.c: 11035 in libxl__device_usbdev_parse_json()
11029 x = libxl__json_map_get("hostaddr", x, JSON_INTEGER);
11030 if (x) {
11031 rc = libxl__uint8_parse_json(gc, x, &p->u.hostdev.hostaddr);
11032 if (rc)
11033 goto out;
11034 }
>>> CID 1358114: Code maintainability issues (UNUSED_VALUE)
>>> Assigning value from "saved_hostaddr" to "x" here, but that stored
>>> vale is overwritten before it can be used.
11035 x = saved_hostaddr;
This does seem rather odd. I wasn't able to find any occurrences of
`x' outside these save/restore regions. So x is saved and restored
for no particular reason.
The root cause seems to be the reuse of x by both inner and outer
autogenerated code, where the generator may not know what is to be
inserted. Why not have a separate variable for each
libxl__json_map_get ?
This code is generated by gentypes.py, near line 438. It was written
by Ian Campbell in 2010 and doesn't seem to have been much touched
since.
Opinions welcome. In particular, should I attempt a patch to make
this code less odd-looking ?
Thanks,
Ian.
(CCing Wei who seems from git log like the only person who might have
a view.)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
