date:20160214

[Xen-devel] [PATCH] x86/HVM: fold hypercall tables

2016-02-14 Thread Jan Beulich

In order to reduce the risk of unintentionally adding a function
pointer to just one of the two tables, merge them into one, with each
entry pair getting generated by a single macro invocation (at once
dropping all explicit casting outside the macro definition).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5191,13 +5191,6 @@ static long hvm_physdev_op(int cmd, XEN_
 }
 }
 
-typedef unsigned long hvm_hypercall_t(
-unsigned long, unsigned long, unsigned long, unsigned long, unsigned long,
-unsigned long);
-
-#define HYPERCALL(x)\
-[ __HYPERVISOR_ ## x ] = (hvm_hypercall_t *) do_ ## x
-
 static long hvm_grant_table_op_compat32(unsigned int cmd,
 XEN_GUEST_HANDLE_PARAM(void) uop,
 unsigned int count)
@@ -5242,35 +5235,34 @@ static long hvm_physdev_op_compat32(
 }
 }
 
-static hvm_hypercall_t *const hvm_hypercall64_table[NR_hypercalls] = {
-[ __HYPERVISOR_memory_op ] = (hvm_hypercall_t *)hvm_memory_op,
-[ __HYPERVISOR_grant_table_op ] = (hvm_hypercall_t *)hvm_grant_table_op,
-HYPERCALL(vcpu_op),
-[ __HYPERVISOR_physdev_op ] = (hvm_hypercall_t *)hvm_physdev_op,
-HYPERCALL(xen_version),
-HYPERCALL(console_io),
-HYPERCALL(event_channel_op),
-HYPERCALL(sched_op),
-HYPERCALL(set_timer_op),
-HYPERCALL(xsm_op),
-HYPERCALL(hvm_op),
-HYPERCALL(sysctl),
-HYPERCALL(domctl),
-HYPERCALL(tmem_op),
-HYPERCALL(platform_op),
-HYPERCALL(mmuext_op),
-HYPERCALL(xenpmu_op),
-[ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
-};
-
-#define COMPAT_CALL(x)\
-[ __HYPERVISOR_ ## x ] = (hvm_hypercall_t *) compat_ ## x
+typedef unsigned long hvm_hypercall_t(
+unsigned long, unsigned long, unsigned long, unsigned long, unsigned long,
+unsigned long);
 
-static hvm_hypercall_t *const hvm_hypercall32_table[NR_hypercalls] = {
-[ __HYPERVISOR_memory_op ] = (hvm_hypercall_t *)hvm_memory_op_compat32,
-[ __HYPERVISOR_grant_table_op ] = (hvm_hypercall_t 
*)hvm_grant_table_op_compat32,
+#define HYPERCALL(x) \
+[ __HYPERVISOR_ ## x ] = { (hvm_hypercall_t *) do_ ## x, \
+   (hvm_hypercall_t *) do_ ## x }
+
+#define COMPAT_CALL(x)   \
+[ __HYPERVISOR_ ## x ] = { (hvm_hypercall_t *) do_ ## x, \
+   (hvm_hypercall_t *) compat_ ## x }
+
+#define do_memory_op  hvm_memory_op
+#define compat_memory_op  hvm_memory_op_compat32
+#define do_physdev_op hvm_physdev_op
+#define compat_physdev_op hvm_physdev_op_compat32
+#define do_grant_table_op hvm_grant_table_op
+#define compat_grant_table_op hvm_grant_table_op_compat32
+#define do_arch_1 paging_domctl_continuation
+
+static const struct {
+hvm_hypercall_t *native;
+hvm_hypercall_t *compat;
+} hypercall_table[NR_hypercalls] = {
+COMPAT_CALL(memory_op),
+COMPAT_CALL(grant_table_op),
 COMPAT_CALL(vcpu_op),
-[ __HYPERVISOR_physdev_op ] = (hvm_hypercall_t *)hvm_physdev_op_compat32,
+COMPAT_CALL(physdev_op),
 COMPAT_CALL(xen_version),
 HYPERCALL(console_io),
 HYPERCALL(event_channel_op),
@@ -5284,9 +5276,20 @@ static hvm_hypercall_t *const hvm_hyperc
 COMPAT_CALL(platform_op),
 COMPAT_CALL(mmuext_op),
 HYPERCALL(xenpmu_op),
-[ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
+HYPERCALL(arch_1)
 };
 
+#undef do_memory_op
+#undef compat_memory_op
+#undef do_physdev_op
+#undef compat_physdev_op
+#undef do_grant_table_op
+#undef compat_grant_table_op
+#undef do_arch_1
+
+#undef HYPERCALL
+#undef COMPAT_CALL
+
 extern const uint8_t hypercall_args_table[], compat_hypercall_args_table[];
 
 int hvm_do_hypercall(struct cpu_user_regs *regs)
@@ -5316,7 +5319,7 @@ int hvm_do_hypercall(struct cpu_user_reg
 if ( (eax & 0x8000) && is_viridian_domain(currd) )
 return viridian_hypercall(regs);
 
-if ( (eax >= NR_hypercalls) || !hvm_hypercall32_table[eax] )
+if ( (eax >= NR_hypercalls) || !hypercall_table[eax].native )
 {
 regs->eax = -ENOSYS;
 return HVM_HCALL_completed;
@@ -5350,7 +5353,7 @@ int hvm_do_hypercall(struct cpu_user_reg
 #endif
 
 curr->arch.hvm_vcpu.hcall_64bit = 1;
-regs->rax = hvm_hypercall64_table[eax](rdi, rsi, rdx, r10, r8, r9);
+regs->rax = hypercall_table[eax].native(rdi, rsi, rdx, r10, r8, r9);
 
 curr->arch.hvm_vcpu.hcall_64bit = 0;
 
@@ -5395,7 +5398,7 @@ int hvm_do_hypercall(struct cpu_user_reg
 }
 #endif
 
-regs->_eax = hvm_hypercall32_table[eax](ebx, ecx, edx, esi, edi, ebp);
+regs->_eax = hypercall_table[eax].compat(ebx, ecx, edx, esi, edi, ebp);
 
 #ifndef NDEBUG
 if (

[Xen-devel] [PATCH] common: re-arrange struct kernel_param fields

2016-02-14 Thread Jan Beulich

Even if placed in .init.* there's no reason to needlessly bloat the
binary due to padding fields the compiler needs to insert on 64-bit
architectures.

Signed-off-by: Jan Beulich 

--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -81,34 +81,35 @@ struct kernel_param {
 OPT_SIZE,
 OPT_CUSTOM
 } type;
-void *var;
 unsigned int len;
+void *var;
 };
 
 extern struct kernel_param __setup_start, __setup_end;
 
 #define __setup_str static __initdata __attribute__((__aligned__(1))) char
-#define __kparam static __initsetup struct kernel_param
+#define __kparam static __initsetup \
+__attribute__((__aligned__(sizeof(void * struct kernel_param
 
 #define custom_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
-__kparam __setup_##_var = { __setup_str_##_var, OPT_CUSTOM, _var, 0 }
+__kparam __setup_##_var = { __setup_str_##_var, OPT_CUSTOM, 0, _var }
 #define boolean_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
 __kparam __setup_##_var = \
-{ __setup_str_##_var, OPT_BOOL, &_var, sizeof(_var) }
+{ __setup_str_##_var, OPT_BOOL, sizeof(_var), &_var }
 #define integer_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
 __kparam __setup_##_var = \
-{ __setup_str_##_var, OPT_UINT, &_var, sizeof(_var) }
+{ __setup_str_##_var, OPT_UINT, sizeof(_var), &_var }
 #define size_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
 __kparam __setup_##_var = \
-{ __setup_str_##_var, OPT_SIZE, &_var, sizeof(_var) }
+{ __setup_str_##_var, OPT_SIZE, sizeof(_var), &_var }
 #define string_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
 __kparam __setup_##_var = \
-{ __setup_str_##_var, OPT_STR, &_var, sizeof(_var) }
+{ __setup_str_##_var, OPT_STR, sizeof(_var), &_var }
 
 #endif /* __ASSEMBLY__ */
 



common: re-arrange struct kernel_param fields

Even if placed in .init.* there's no reason to needlessly bloat the
binary due to padding fields the compiler needs to insert on 64-bit
architectures.

Signed-off-by: Jan Beulich 

--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -81,34 +81,35 @@ struct kernel_param {
 OPT_SIZE,
 OPT_CUSTOM
 } type;
-void *var;
 unsigned int len;
+void *var;
 };
 
 extern struct kernel_param __setup_start, __setup_end;
 
 #define __setup_str static __initdata __attribute__((__aligned__(1))) char
-#define __kparam static __initsetup struct kernel_param
+#define __kparam static __initsetup \
+__attribute__((__aligned__(sizeof(void * struct kernel_param
 
 #define custom_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
-__kparam __setup_##_var = { __setup_str_##_var, OPT_CUSTOM, _var, 0 }
+__kparam __setup_##_var = { __setup_str_##_var, OPT_CUSTOM, 0, _var }
 #define boolean_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
 __kparam __setup_##_var = \
-{ __setup_str_##_var, OPT_BOOL, &_var, sizeof(_var) }
+{ __setup_str_##_var, OPT_BOOL, sizeof(_var), &_var }
 #define integer_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
 __kparam __setup_##_var = \
-{ __setup_str_##_var, OPT_UINT, &_var, sizeof(_var) }
+{ __setup_str_##_var, OPT_UINT, sizeof(_var), &_var }
 #define size_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
 __kparam __setup_##_var = \
-{ __setup_str_##_var, OPT_SIZE, &_var, sizeof(_var) }
+{ __setup_str_##_var, OPT_SIZE, sizeof(_var), &_var }
 #define string_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
 __kparam __setup_##_var = \
-{ __setup_str_##_var, OPT_STR, &_var, sizeof(_var) }
+{ __setup_str_##_var, OPT_STR, sizeof(_var), &_var }
 
 #endif /* __ASSEMBLY__ */
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 82511: tolerable FAIL - PUSHED

2016-02-14 Thread osstest service owner

flight 82511 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82511/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   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-amd64-amd64-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-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-amd64-amd64-libvirt-vhd 11 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-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  98782f88991a390a358cea960b5776f72fc14451
baseline version:
 libvirt  6ec319b84f67d72bf59fe7e0fd41d88ee9c393c7

Last test of basis80121  2016-02-03 04:26:28 Z   12 days
Failing since 80382  2016-02-04 04:29:24 Z   11 days9 attempts
Testing same since82239  2016-02-13 01:57:52 Z2 days2 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Daniel P. Berrange 
  Dmitry Andreev 
  Erik Skultety 
  Joao Martins 
  John Ferlan 
  JÃ¡n Tomko 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Peter Krempa 
  Roman Bogorodskiy 
  Wido den Hollander 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=98782f88991a390a358cea960b5776f72fc14451
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos

[Xen-devel] [PATCH v3 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

2016-02-14 Thread Corneliu ZUZU

This patch moves monitor_domctl to common-side.
Purpose: move what's common to common, prepare for implementation
of such vm-events on ARM.

* move get_capabilities to arch-side => arch_monitor_get_capabilities.
* add arch-side monitor op handling function => arch_monitor_domctl_op.
  e.g. X86-side handles XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP op
* add arch-side monitor event handling function => arch_monitor_domctl_event.
  e.g. X86-side handles XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR event enable/disable
* remove status_check

Signed-off-by: Corneliu ZUZU 
---
 MAINTAINERS   |   1 +
 xen/arch/x86/monitor.c| 158 --
 xen/common/Makefile   |   1 +
 xen/common/domctl.c   |   2 +-
 xen/common/monitor.c  |  69 ++
 xen/include/asm-arm/monitor.h |  34 +++--
 xen/include/asm-x86/monitor.h |  53 --
 xen/include/xen/monitor.h |  30 
 8 files changed, 226 insertions(+), 122 deletions(-)
 create mode 100644 xen/common/monitor.c
 create mode 100644 xen/include/xen/monitor.h

diff --git a/MAINTAINERS b/MAINTAINERS
index f07384c..5cbb1dc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -355,6 +355,7 @@ M:  Tamas K Lengyel 
 S: Supported
 F: xen/common/vm_event.c
 F: xen/common/mem_access.c
+F: xen/common/monitor.c
 F: xen/arch/x86/hvm/event.c
 F: xen/arch/x86/monitor.c
 F: xen/arch/*/vm_event.c
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 1d43880..069c3c7 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -1,9 +1,10 @@
 /*
  * arch/x86/monitor.c
  *
- * Architecture-specific monitor_op domctl handler.
+ * Arch-specific monitor_op domctl handler.
  *
  * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
+ * Copyright (c) 2016, Bitdefender S.R.L.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public
@@ -18,87 +19,14 @@
  * License along with this program; If not, see .
  */
 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
+#include 
 
-/*
- * Sanity check whether option is already enabled/disabled
- */
-static inline
-int status_check(struct xen_domctl_monitor_op *mop, bool_t status)
-{
-bool_t requested_status = (mop->op == XEN_DOMCTL_MONITOR_OP_ENABLE);
-
-if ( status == requested_status )
-return -EEXIST;
-
-return 0;
-}
-
-static inline uint32_t get_capabilities(struct domain *d)
-{
-uint32_t capabilities = 0;
-
-/*
- * At the moment only Intel HVM domains are supported. However, event
- * delivery could be extended to AMD and PV domains.
- */
-if ( !is_hvm_domain(d) || !cpu_has_vmx )
-return capabilities;
-
-capabilities = (1 << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
-   (1 << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
-   (1 << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
-   (1 << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
-
-/* Since we know this is on VMX, we can just call the hvm func */
-if ( hvm_is_singlestep_supported() )
-capabilities |= (1 << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
-
-return capabilities;
-}
-
-int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
+int arch_monitor_domctl_event(struct domain *d,
+  struct xen_domctl_monitor_op *mop)
 {
-int rc;
 struct arch_domain *ad = >arch;
-uint32_t capabilities = get_capabilities(d);
-
-if ( current->domain == d ) /* no domain_pause() */
-return -EPERM;
-
-rc = xsm_vm_event_control(XSM_PRIV, d, mop->op, mop->event);
-if ( rc )
-return rc;
-
-switch ( mop->op )
-{
-case XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES:
-mop->event = capabilities;
-return 0;
-
-case XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP:
-domain_pause(d);
-ad->mem_access_emulate_each_rep = !!mop->event;
-domain_unpause(d);
-return 0;
-}
-
-/*
- * Sanity check
- */
-if ( mop->op != XEN_DOMCTL_MONITOR_OP_ENABLE &&
- mop->op != XEN_DOMCTL_MONITOR_OP_DISABLE )
-return -EOPNOTSUPP;
-
-/* Check if event type is available. */
-if ( !(capabilities & (1 << mop->event)) )
-return -EOPNOTSUPP;
+bool_t requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op);
 
 switch ( mop->event )
 {
@@ -106,13 +34,11 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 {
 unsigned int ctrlreg_bitmask =
 monitor_ctrlreg_bitmask(mop->u.mov_to_cr.index);
-bool_t status =
+bool_t old_status =
 !!(ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask);
-struct vcpu *v;
 
-rc = status_check(mop, status);
-if ( rc )
-

[Xen-devel] [PATCH v3 1/2] xen/x86: merge 2 hvm_event_... functions into 1

2016-02-14 Thread Corneliu ZUZU

This patch merges almost identical functions hvm_event_int3 and
hvm_event_single_step into a single function called hvm_event_breakpoint.
Also fixes event.c file header comment in the process.

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/x86/hvm/event.c| 108 +++-
 xen/arch/x86/hvm/vmx/vmx.c  |  15 +++---
 xen/include/asm-x86/hvm/event.h |  11 ++--
 3 files changed, 67 insertions(+), 67 deletions(-)

diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index a3d4892..874a36c 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -1,22 +1,24 @@
 /*
-* event.c: Common hardware virtual machine event abstractions.
-*
-* Copyright (c) 2004, Intel Corporation.
-* Copyright (c) 2005, International Business Machines Corporation.
-* Copyright (c) 2008, Citrix Systems, Inc.
-*
-* This program is free software; you can redistribute it and/or modify it
-* under the terms and conditions of the GNU General Public License,
-* version 2, as published by the Free Software Foundation.
-*
-* This program is distributed in the hope it will be useful, but WITHOUT
-* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
-* more details.
-*
-* You should have received a copy of the GNU General Public License along with
-* this program; If not, see .
-*/
+ * arch/x86/hvm/event.c
+ *
+ * Arch-specific hardware virtual machine event abstractions.
+ *
+ * Copyright (c) 2004, Intel Corporation.
+ * Copyright (c) 2005, International Business Machines Corporation.
+ * Copyright (c) 2008, Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ */
 
 #include 
 #include 
@@ -151,61 +153,51 @@ void hvm_event_guest_request(void)
 }
 }
 
-int hvm_event_int3(unsigned long rip)
+static inline unsigned long gfn_of_rip(unsigned long rip)
 {
-int rc = 0;
 struct vcpu *curr = current;
+struct segment_register sreg;
+uint32_t pfec = PFEC_page_present | PFEC_insn_fetch;
 
-if ( curr->domain->arch.monitor.software_breakpoint_enabled )
-{
-struct segment_register sreg;
-uint32_t pfec = PFEC_page_present | PFEC_insn_fetch;
-vm_event_request_t req = {
-.reason = VM_EVENT_REASON_SOFTWARE_BREAKPOINT,
-.vcpu_id = curr->vcpu_id,
-};
-
-hvm_get_segment_register(curr, x86_seg_ss, );
-if ( sreg.attr.fields.dpl == 3 )
-pfec |= PFEC_user_mode;
+hvm_get_segment_register(curr, x86_seg_ss, );
+if ( sreg.attr.fields.dpl == 3 )
+pfec |= PFEC_user_mode;
 
-hvm_get_segment_register(curr, x86_seg_cs, );
-req.u.software_breakpoint.gfn = paging_gva_to_gfn(curr,
-  sreg.base + rip,
-  );
-
-rc = hvm_event_traps(1, );
-}
+hvm_get_segment_register(curr, x86_seg_cs, );
 
-return rc;
+return paging_gva_to_gfn(curr, sreg.base + rip, );
 }
 
-int hvm_event_single_step(unsigned long rip)
+int hvm_event_breakpoint(unsigned long rip,
+ enum hvm_event_breakpoint_type type)
 {
-int rc = 0;
 struct vcpu *curr = current;
+struct arch_domain *ad = >domain->arch;
+vm_event_request_t req;
 
-if ( curr->domain->arch.monitor.singlestep_enabled )
+switch ( type )
 {
-struct segment_register sreg;
-uint32_t pfec = PFEC_page_present | PFEC_insn_fetch;
-vm_event_request_t req = {
-.reason = VM_EVENT_REASON_SINGLESTEP,
-.vcpu_id = curr->vcpu_id,
-};
-
-hvm_get_segment_register(curr, x86_seg_ss, );
-if ( sreg.attr.fields.dpl == 3 )
-pfec |= PFEC_user_mode;
+case HVM_EVENT_SOFTWARE_BREAKPOINT:
+if ( !ad->monitor.software_breakpoint_enabled )
+return 0;
+req.reason = VM_EVENT_REASON_SOFTWARE_BREAKPOINT;
+req.u.software_breakpoint.gfn = gfn_of_rip(rip);
+break;
 
-hvm_get_segment_register(curr, x86_seg_cs, );
-req.u.singlestep.gfn = paging_gva_to_gfn(curr, sreg.base + rip,
- );
+case HVM_EVENT_SINGLESTEP_BREAKPOINT:
+if ( !ad->monitor.singlestep_enabled )
+return 0;
+

[Xen-devel] [PATCH v3 0/2] Vm-events: move monitor vm-events code to common-side.

2016-02-14 Thread Corneliu ZUZU


This patch series is an attempt to move some of the monitor vm-events code to
the common-side. Done to make it easier to move additional parts that can be
moved to common when ARM-side implementations are to be added.

Patches summary:
1. Merge almost identical functions hvm_event_int3 + hvm_event_single_step ->
   hvm_event_breakpoint.
2. Move monitor_domctl to common-side.

Note: ARM support for guest-request, control-register write monitor vm-events
will follow after review of this patch-series.

---
Changed since v2:
  Major:
* moved back all monitor vm-event handling on X86-side
* removed Kconfigs
* arch_monitor_domctl_event & arch_monitor_domctl_op now directly return rc
  Minor:
* squashed commits 4 & 6 on their previous commits
* fixed coding-style mistakes (e.g. use C-style comments only)
* drop xen/config.h include

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support

2016-02-14 Thread Suriyan Ramasami

On Thu, Feb 11, 2016 at 1:40 AM, Ian Campbell 
wrote:

> On Wed, 2016-02-10 at 17:47 -0800, Suriyan Ramasami wrote:
> >
> >
> > On Wed, Feb 10, 2016 at 2:03 AM, Ian Campbell 
> > wrote:
> > > On Tue, 2016-02-09 at 10:20 -0800, Suriyan Ramasami wrote:
> > > >  I agree on the first two paragraphs.
> > > > > > For the third paragraph, the rebuttal is that the exynos5800 and
> > > > > > exynos5422 based SoCs can have both clusters on at the same time.
> > > Hence,
> > > > > > the third paragrapah comment will have to be tweaked further.
> > > Possibly
> > > > > > reading:
> > > > > > The exynos5800 and exynos5422 can have both clusters on at the
> > > same time.
> > > > > > The exynos5800 boots up with cpu0 on cluster0 (A15). The
> > > exynos5422 can
> > > > > > boot up on either clusters as its pin controlled. In this case
> > > the DTS
> > > > > > should properly reflect the cpu order.
> > > > >
> > > > > Does the OS need to be aware of all these combinations though? Is
> > > it not
> > > > > sufficient to know how to bring up an A15 core and how to bring up
> > > an A7
> > > > > core and then just do so based on the information in the DTS,
> > > without
> > > > > needing to worry about which sort of core we happened to have
> > > booted on?
> > > > >
> > > > >
> > > > Unfortunately, at least looking at the boot up code for the
> > > Exynos5422,
> > > > the OS needs to be aware of it. This is what I see in the linux
> > > source
> > > > code. If it boots up on an A7, then a special reset is needed which
> > > is
> > > > not needed when booted up otherwise. I do not have much more details
> > > on
> > > > that other than the Linux code.
> > > > Without that reset sequence, I have also verified that the powered on
> > > CPU
> > > > does not come up.
> > >
> > > Are we able to say that if we are booted on cluster 1 (always the A7s)
> > > then
> > > we always need this magic reset? i.e. is true for all SoCs which have
> > > an A7
> > > cluster and can boot from it? (it's tautologically true for SocS which
> > > either have no A7's or cannot boot from them).
> > >
> > I do not have the information to answer the question. I am limited to
> > what I know (albeit a little bit) wrt the hardkernel related boards -
> > Exynos 5410 (odroid-XU) and the Exynos 5422 (Odoird XU3/XU4). With my
> > limited knowledge, I am only aware of Exynos 5410 which is capable of
> > booting off of an A7 or an A15.
> >
> > >  Maybe I'm looking for similarities between different exynos variants
> > > which
> > > doesn't exist though. If we are going to talk about specific SoCs in
> > > the
> > > comments then I would rather that the code was also explicit rather
> > > than
> > > assuming cluster 1 will only be found on the 5800, that might be as
> > > simple
> > > as mapping the compatible string to a max_cluster (default 0 for
> > > unknown
> > > SoC) and warning if pcluster > max_cluster.
> > Can you please elaborate on the mapping that you talk about above. I am
> > lost here :-(
>
> What I mean is can we say:
> exynos 1234 => Two clusters (max_cluster == 1)
> exynos 5678 => One cluster (max_cluster == 0)
> exynos ABCD => Two clusters (max_cluster == 1)
> Unknown => Assume one cluster
>
> and can we also assume that cluster 0 always consists of A15s and cluster 1
> (if it exists) always consists of A7s?
>
> If so then we can say:
>
>   max_cluster = look_up_by_compat(compat)
>   pcluster = figure out from midr
>   pcpu = figure it out
>
>   if (pcluster >= max_cluster)
> error
>
>   do bringup
>
>   if (pluster == 1)
> do special handling for cluster 1 == a7
>
> The difference compared with what you have is that it adds a check that we
> expect a second cluster for the SoC before it goes poking at stuff.
>
> What I'm trying to avoid is coming across some other SoC variant which has
> 2 clusters but has something different to the A7s or which requires some
> different handling.
>
> If we were confident that all exynos SoCs always require the same
> special handling for cluster 1 then we wouldn't really need this, but I
> don't think we know that?
>
>
I did some looking at the linux 4.4.y dts for exynos, and this is what I
see:
exynos3250: cpu0, cpu1 = A7 (1 cluster)
exynos4210: cpu0, cpu1 = A9 (1 cluster)
exynos4212: cpu0, cpu1 = A9 (1 cluster)
exynos4412: cpu0, cpu1, cpu2, cpu3 = A9 (1 cluster)
exynos4415: cpu0, cpu1, cpu2, cpu3 = A9 (1 cluster)
exynos5250: cpu0, cpu1 = A15 (1 cluster)
exynos5260: cpu0, cpu1 = A15. cpu2, cpu3, cpu4, cpu5 = A7 (2 clusters)
exynos5410: cpu0, cpu1, cpu2, cpu3 = A15 (1 cluster - even thougg it has 2
clusters, but not both can be on at same time)
exynos5420: cpu0, cpu1, cpu2, cpu3 = A15. cpu4, cpu5, cpu6, cpu7 = A7 (2
clusters)
exynos5422: cpu0, cpu1, cpu2, cpu3 = A7. cpu4, cpu5, cpu6, cpu7 = A15 (2
clusters)
exynos5440: cpu0, cpu1, cpu2, cpu3 = A15 (1 cluster)

If we look at the ones that can potentially support hardware

[Xen-devel] [qemu-upstream-4.6-testing test] 82482: tolerable FAIL - PUSHED

2016-02-14 Thread osstest service owner

flight 82482 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82482/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail in 82162 pass in 82482
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 82162 pass in 
82482
 test-armhf-armhf-xl  15 guest-start/debian.repeat   fail pass in 82162

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 77722

Tests which did not succeed, but are not blocking:
 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 14 guest-saverestorefail   never pass
 test-armhf-armhf-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-amd64-amd64-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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-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  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-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-rtds 11 guest-start  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-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 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

version targeted for testing:
 qemuu36d4ccc357252ff5506352c4815533f0a3ebc116
baseline version:
 qemuu9e304f572ac98265f5e7433b6490077962acda97

Last test of basis77722  2016-01-10 11:19:40 Z   35 days
Failing since 80733  2016-02-05 15:18:36 Z9 days4 attempts
Testing same since82162  2016-02-12 15:03:36 Z2 days2 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Jason Wang 
  John Snow 
  Laszlo Ersek 
  Michael S. Tsirkin 
  P J P 
  Paolo Bonzini 
  Peter Maydell 
  Prasad J Pandit 
  Roger Pau Monne 
  Roger Pau MonnÃ© 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvops

Re: [Xen-devel] [PATCH v8 5/5] Scripts to create and delete xen-scsiback nodes in Linux target framework

2016-02-14 Thread Juergen Gross

On 12/02/16 19:36, Olaf Hering wrote:
> On Fri, Feb 12, Wei Liu wrote:
> 
>> On Thu, Feb 11, 2016 at 03:43:31PM +, Olaf Hering wrote:
>>> Just to make them public, not meant for merging:
>>
>> I might be mistaken, but if you don't provide a hotplug script or some
>> sort for Xen how do you expect user to make use vscsi?
> 
> The xenlinux backend uses existing SCSI devices. The pvops backend uses
> devices provided by xen-scsiback which in turn is a frontend in the SCSI
> target framework. This has to be configured manually before usage. I
> have to document all this in the wiki.
> 
> Jürgen suggested to check if libxl could do the configuration in
> configfs, as a replacement for targetcli. Not sure if thats doable. It
> would require yet another syntax in vscsi=[]. I will look at this later.

Hmm, I don't see why this would require another syntax. When adding e.g.
/dev/sr0 to a domain via targetcli I need to call:

targetcli /xen-pvscsi create naa.3ccc1c11088e4086
targetcli /backstores/pscsi create "dev=/dev/sr0" ps_0
targetcli /xen-pvscsi/naa.3ccc1c11088e4086/tpg1/luns create
"/backstores/pscsi/ps_0" 0
targetcli /xen-pvscsi/naa.3ccc1c11088e4086/tpg1 set parameter alias=2:0:0

The WWN (naa.3ccc1c11088e4086) is just generated via /dev/random. The
alias for xen-pvscsi (2:0:0) is taken from lsscsi by omitting the LUN:

# lsscsi
[0:0:0:0]diskATA  WDC WD5000AAKX-7 1H19  /dev/sda
[2:0:0:0]cd/dvd  HL-DT-ST DVD+-RW GHB0NA100  /dev/sr0

The pscsi backstore name (ps_0) is just a name which can be chosen.

The need to use this kind of configuration is a feature of the current
system which can be easily detected by trying to create the xen-pvscsi
directory in configfs: if it succeeds you need to do it.

So all information for deciding to do the configfs related configuration
and all the data needed for doing it are already present. As this is
specific to Linux I'd add a system specific function which will be a nop
for non-Linux systems and could do the check and possibly the configfs
work on Linux.

Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 82450: regressions - FAIL

2016-02-14 Thread osstest service owner

flight 82450 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82450/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 65543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 65543

version targeted for testing:
 ovmf 40696972bffcd5067de02ba6afc19b773e2cfab1
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   68 days
Failing since 65593  2015-12-08 23:44:51 Z   68 days   71 attempts
Testing same since82450  2016-02-14 05:08:39 Z1 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Charles Duffy 
  Cinnamon Shia 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leekha Shaveta 
  Leif Lindholm 
  Liming Gao 
  Mark Rutland 
  Marvin Haeuser 
  Michael Kinney 
  Michael Thomas 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 

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 8478 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

2016-02-14 Thread Tom Herbert

On Fri, Feb 12, 2016 at 5:59 PM, Paul Durrant  wrote:
>> -Original Message-
>> From: David Miller [mailto:da...@davemloft.net]
>> Sent: 12 February 2016 16:42
>> To: Paul Durrant
>> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org
>> Subject: Re: [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing
>>
>> From: Paul Durrant 
>> Date: Fri, 12 Feb 2016 11:07:50 +
>>
>> > Windows *requires* use of Teoplitz so your position completely rules
>> > out being able to support receive side scaling in Windows PV
>> > frontends on Linux kernel backends, not only for Xen but for any
>> > other hypervisor, which I think is totally unreasonable.
>>
>> We have strong reason to believe that Toeplitz has properties that
>> make it very weak if not exploitable, therefore doing software RSS
>> with Jenkins is superior.
>
> I don't disagree, but there is really no choice of algorithm where a Windows 
> frontend is concerned. My patches only add Toeplitz hashing into xen-netback 
> according to the specification in xen's netif.h; the algorithm is not exposed 
> for use by any other part of the kernel.

You are touching struct sk_buff for this. Changing such a core
networking data structure just to satisfy a requirement of Windows
seems like a long shot to me...

> If it would help I can add a module parameter to xen-netback to control 
> advertising the option of the hash to frontends so that it can be globally 
> disabled if it is deployed on host where there are no Windows guests.

Toeplitz is dog-slow to compute in software. Comparing your
implementation to Jenkins hash (hash) it's about 12x slower (102 nsecs
versus 8 nsecs for IPv4 on my system). Doing this for every packet
seems like a non-starter to me. I suspect the majority use case for
receive is simple uniform load balancing across the virtual queues in
which case jhash will be perfectly fine. The case where it probably
matters is if the Windows OS is trying to configure some non-uniform
distribution (isolating a single flow for instance). To handle this
case, you could implement a simple look up flow table to map a
skb->hash to a Toeplitz hash, so that the Toeplitz hash only needs to
be calculated one time for a flow (recomputed with some periodic
timeout). This would be probabilistic though, so if really Windows
requires the hash to be set correctly 100% of the time it won't work.

Tom

>
>   Paul

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next v1 1/8] skbuff: store hash type in socket buffer...

2016-02-14 Thread Tom Herbert

On Fri, Feb 12, 2016 at 11:13 AM, Paul Durrant  wrote:
> ...rather than a boolean merely indicating a canonical L4 hash.
>
> skb_set_hash() takes a hash type (from enum pkt_hash_types) as an
> argument but information is lost since only a single bit in the skb
> stores whether that hash type is PKT_HASH_TYPE_L4 or not.
>
> By using two bits it's possible to store the complete hash type
> information for use by drivers. A subsequent patch to xen-netback
> needs this information to forward packet hashes to VM frontend drivers.
>
> Signed-off-by: Paul Durrant 
> Cc: "David S. Miller" 
> Cc: Jay Vosburgh 
> Cc: Veaceslav Falico 
> Cc: Andy Gospodarek 
> ---
>  drivers/net/bonding/bond_main.c |  2 +-
>  include/linux/skbuff.h  | 53 
> -
>  include/net/flow_dissector.h|  5 
>  include/net/sock.h  |  2 +-
>  include/trace/events/net.h  |  2 +-
>  net/core/flow_dissector.c   | 27 -
>  6 files changed, 65 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 45bdd87..ad0ee00 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3173,7 +3173,7 @@ u32 bond_xmit_hash(struct bonding *bond, struct sk_buff 
> *skb)
> u32 hash;
>
> if (bond->params.xmit_policy == BOND_XMIT_POLICY_ENCAP34 &&
> -   skb->l4_hash)
> +   skb_has_l4_hash(skb))
> return skb->hash;
>
> if (bond->params.xmit_policy == BOND_XMIT_POLICY_LAYER2 ||
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 6ec86f1..9021b52 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -595,8 +595,7 @@ static inline bool skb_mstamp_after(const struct 
> skb_mstamp *t1,
>   * @xmit_more: More SKBs are pending for this queue
>   * @ndisc_nodetype: router type (from link layer)
>   * @ooo_okay: allow the mapping of a socket to a queue to be changed
> - * @l4_hash: indicate hash is a canonical 4-tuple hash over transport
> - * ports.
> + * @hash_type: indicates type of hash (see enum pkt_hash_types below)
>   * @sw_hash: indicates hash was computed in software stack
>   * @wifi_acked_valid: wifi_acked was set
>   * @wifi_acked: whether frame was acked on wifi or not
> @@ -701,10 +700,10 @@ struct sk_buff {
> __u8nf_trace:1;
> __u8ip_summed:2;
> __u8ooo_okay:1;
> -   __u8l4_hash:1;
> __u8sw_hash:1;
> __u8wifi_acked_valid:1;
> __u8wifi_acked:1;
> +   /* 1 bit hole */
>
> __u8no_fcs:1;
> /* Indicates the inner headers are valid in the skbuff. */
> @@ -721,7 +720,8 @@ struct sk_buff {
> __u8ipvs_property:1;
> __u8inner_protocol_type:1;
> __u8remcsum_offload:1;
> -   /* 3 or 5 bit hole */
> +   __u8hash_type:2;

This isn't needed by the stack-- we don't differentiate between L2 and
L3 hash anywhere. Also it doesn't help in the xen case for passing a
hash to Windows without having another bit to indicate that the hash
is indeed Toeplitz.

> +   /* 1 or 3 bit hole */
>
>  #ifdef CONFIG_NET_SCHED
> __u16   tc_index;   /* traffic control index */
> @@ -1030,19 +1030,35 @@ static inline void skb_clear_hash(struct sk_buff *skb)
>  {
> skb->hash = 0;
> skb->sw_hash = 0;
> -   skb->l4_hash = 0;
> +   skb->hash_type = 0;
> +}
> +
> +static inline enum pkt_hash_types skb_hash_type(struct sk_buff *skb)
> +{
> +   return skb->hash_type;
> +}
> +
> +static inline bool skb_has_l4_hash(struct sk_buff *skb)
> +{
> +   return skb_hash_type(skb) == PKT_HASH_TYPE_L4;
> +}
> +
> +static inline bool skb_has_sw_hash(struct sk_buff *skb)
> +{
> +   return !!skb->sw_hash;
>  }
>
>  static inline void skb_clear_hash_if_not_l4(struct sk_buff *skb)
>  {
> -   if (!skb->l4_hash)
> +   if (!skb_has_l4_hash(skb))
> skb_clear_hash(skb);
>  }
>
>  static inline void
> -__skb_set_hash(struct sk_buff *skb, __u32 hash, bool is_sw, bool is_l4)
> +__skb_set_hash(struct sk_buff *skb, __u32 hash, bool is_sw,
> +  enum pkt_hash_types type)
>  {
> -   skb->l4_hash = is_l4;
> +   skb->hash_type = type;
> skb->sw_hash = is_sw;
> skb->hash = hash;
>  }
> @@ -1051,13 +1067,13 @@ static inline void
>  skb_set_hash(struct sk_buff *skb, __u32 hash, enum pkt_hash_types type)
>  {
> /* Used by drivers to set hash from HW */
> -   __skb_set_hash(skb, hash, false, type ==

Re: [Xen-devel] [PATCH net-next v1 7/8] xen-netback: pass toeplitz hash value to the frontend

2016-02-14 Thread Tom Herbert

On Fri, Feb 12, 2016 at 11:13 AM, Paul Durrant  wrote:
> My recent patch to include/xen/interface/io/netif.h defines a new extra
> info type that can be used to pass toeplitz hash values between backend
> and VM frontend.
>
> This patch adds code to xen-netback to pass hash values calculated for
> receive-side packets to the VM frontend.
>
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> ---
>  drivers/net/xen-netback/common.h  |  1 +
>  drivers/net/xen-netback/netback.c | 76 
> ---
>  2 files changed, 65 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/xen-netback/common.h 
> b/drivers/net/xen-netback/common.h
> index 6687702..469dcf0 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -243,6 +243,7 @@ struct xenvif {
> u8 ip_csum:1;
> u8 ipv6_csum:1;
> u8 multicast_control:1;
> +   u8 hash_extra:1;
>
> /* Is this interface disabled? True when backend discovers
>  * frontend is rogue.
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index 41ec7e9..57c91fe 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -163,6 +163,8 @@ static bool xenvif_rx_ring_slots_available(struct 
> xenvif_queue *queue)
> needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
> if (skb_is_gso(skb))
> needed++;
> +   if (queue->vif->hash_extra)
> +   needed++;
>
> do {
> prod = queue->rx.sring->req_prod;
> @@ -280,6 +282,8 @@ struct gop_frag_copy {
> struct xenvif_rx_meta *meta;
> int head;
> int gso_type;
> +   int protocol;
> +   int hash_type;
>
> struct page *page;
>  };
> @@ -326,8 +330,19 @@ static void xenvif_setup_copy_gop(unsigned long gfn,
> npo->copy_off += *len;
> info->meta->size += *len;
>
> +   if (!info->head)
> +   return;
> +
> /* Leave a gap for the GSO descriptor. */
> -   if (info->head && ((1 << info->gso_type) & queue->vif->gso_mask))
> +   if ((1 << info->gso_type) & queue->vif->gso_mask)
> +   queue->rx.req_cons++;
> +
> +   /* Leave a gap for the hash extra segment. */
> +   if (queue->vif->hash_extra &&
> +   (info->hash_type == PKT_HASH_TYPE_L4 ||
> +info->hash_type == PKT_HASH_TYPE_L3) &&
> +   (info->protocol == htons(ETH_P_IP) ||
> +info->protocol == htons(ETH_P_IPV6)))
> queue->rx.req_cons++;
>
> info->head = 0; /* There must be something in this buffer now */
> @@ -362,6 +377,8 @@ static void xenvif_gop_frag_copy(struct xenvif_queue 
> *queue, struct sk_buff *skb
> .npo = npo,
> .head = *head,
> .gso_type = XEN_NETIF_GSO_TYPE_NONE,
> +   .protocol = skb->protocol,
> +   .hash_type = skb_hash_type(skb),
> };
> unsigned long bytes;
>
> @@ -550,6 +567,7 @@ void xenvif_kick_thread(struct xenvif_queue *queue)
>
>  static void xenvif_rx_action(struct xenvif_queue *queue)
>  {
> +   struct xenvif *vif = queue->vif;
> s8 status;
> u16 flags;
> struct xen_netif_rx_response *resp;
> @@ -567,6 +585,8 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
>
> skb_queue_head_init();
>
> +   vif->hash_extra = !!vif->toeplitz.flags;
> +
> while (xenvif_rx_ring_slots_available(queue)
>&& (skb = xenvif_rx_dequeue(queue)) != NULL) {
> queue->last_rx_time = jiffies;
> @@ -585,9 +605,10 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
> gnttab_batch_copy(queue->grant_copy_op, npo.copy_prod);
>
> while ((skb = __skb_dequeue()) != NULL) {
> +   struct xen_netif_extra_info *extra = NULL;
>
> if ((1 << queue->meta[npo.meta_cons].gso_type) &
> -   queue->vif->gso_prefix_mask) {
> +   vif->gso_prefix_mask) {
> resp = RING_GET_RESPONSE(>rx,
>  queue->rx.rsp_prod_pvt++);
>
> @@ -605,7 +626,7 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
> queue->stats.tx_bytes += skb->len;
> queue->stats.tx_packets++;
>
> -   status = xenvif_check_gop(queue->vif,
> +   status = xenvif_check_gop(vif,
>   XENVIF_RX_CB(skb)->meta_slots_used,
>   );
>
> @@ -627,21 +648,52 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
> flags);
>
> if ((1 << queue->meta[npo.meta_cons].gso_type) &
> -   queue->vif->gso_mask) {
> -

Re: [Xen-devel] [PATCH net-next v1 6/8] xen-netback: add an implementation of toeplitz hashing...

2016-02-14 Thread Tom Herbert

On Fri, Feb 12, 2016 at 11:13 AM, Paul Durrant  wrote:
> ...for receive-side packets.
>
> My recent patch to include/xen/interface/io/netif.h defines a set of
> control messages that can be used by a VM frontend driver to configure
> toeplitz hashing of receive-side packets and consequent steering of those
> packets to particular queues.
>
> This patch introduces an implementation of toeplitz hashing and into
> xen-netback and allows it to be configured using the new control messages.
>
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> ---
>  drivers/net/xen-netback/common.h|  13 
>  drivers/net/xen-netback/interface.c | 149 
> 
>  drivers/net/xen-netback/netback.c   | 128 ++-
>  3 files changed, 287 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/xen-netback/common.h 
> b/drivers/net/xen-netback/common.h
> index 093a12a..6687702 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -220,6 +220,12 @@ struct xenvif_mcast_addr {
>
>  #define XEN_NETBK_MCAST_MAX 64
>
> +#define XEN_NETBK_MAX_TOEPLITZ_KEY_SIZE 40
> +
> +#define XEN_NETBK_MAX_TOEPLITZ_MAPPING_ORDER 7
> +#define XEN_NETBK_MAX_TOEPLITZ_MAPPING_SIZE \
> +   BIT(XEN_NETBK_MAX_TOEPLITZ_MAPPING_ORDER)
> +
>  struct xenvif {
> /* Unique identifier for this interface. */
> domid_t  domid;
> @@ -251,6 +257,13 @@ struct xenvif {
> unsigned int num_queues; /* active queues, resource allocated */
> unsigned int stalled_queues;
>
> +   struct {
> +   u32 flags;
> +   u8 key[XEN_NETBK_MAX_TOEPLITZ_KEY_SIZE];
> +   u32 mapping[XEN_NETBK_MAX_TOEPLITZ_MAPPING_SIZE];
> +   unsigned int order;
> +   } toeplitz;
> +
> struct xenbus_watch credit_watch;
> struct xenbus_watch mcast_ctrl_watch;
>
> diff --git a/drivers/net/xen-netback/interface.c 
> b/drivers/net/xen-netback/interface.c
> index 1850ebb..230afde 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -1,3 +1,4 @@
> +
>  /*
>   * Network-device interface management.
>   *
> @@ -151,6 +152,153 @@ void xenvif_wake_queue(struct xenvif_queue *queue)
> netif_tx_wake_queue(netdev_get_tx_queue(dev, id));
>  }
>
> +static u32 toeplitz_hash(const u8 *k, unsigned int klen,
> +const u8 *d, unsigned int dlen)

This should be a common library function, probably in lib directory.

> +{
> +   unsigned int di, ki;
> +   u64 prefix = 0;
> +   u64 hash = 0;
> +
> +   /* Pre-load prefix with the first 8 bytes of the key */
> +   for (ki = 0; ki < 8; ki++) {
> +   prefix <<= 8;
> +   prefix |= (ki < klen) ? k[ki] : 0;
> +   }
> +
> +   for (di = 0; di < dlen; di++) {
> +   u8 byte = d[di];
> +   unsigned int bit;
> +
> +   for (bit = 0x80; bit != 0; bit >>= 1) {
> +   if (byte & bit)
> +   hash ^= prefix;
> +   prefix <<= 1;
> +   }
> +
> +   /* prefix has now been left-shifted by 8, so OR in
> +* the next byte.
> +*/
> +   prefix |= (ki < klen) ? k[ki] : 0;
> +   ki++;
> +   }
> +
> +   /* The valid part of the hash is in the upper 32 bits. */
> +   return hash >> 32;
> +}
> +
> +static void xenvif_set_toeplitz_hash(struct xenvif *vif, struct sk_buff *skb)
> +{
> +   struct flow_keys flow;
> +   u32 hash = 0;
> +   enum pkt_hash_types type = PKT_HASH_TYPE_NONE;
> +   const u8 *key = vif->toeplitz.key;
> +   u32 flags = vif->toeplitz.flags;
> +   const unsigned int len = XEN_NETBK_MAX_TOEPLITZ_KEY_SIZE;
> +   bool has_tcp_hdr;
> +
> +   /* Quick rejection test: If the network protocol doesn't
> +* correspond to any enabled hash type then there's no point
> +* in parsing the packet header.
> +*/
> +   switch (skb->protocol) {
> +   case htons(ETH_P_IP):
> +   if (flags & (XEN_NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP |
> +XEN_NETIF_CTRL_TOEPLITZ_HASH_IPV4))
> +   break;
> +
> +   goto done;
> +
> +   case htons(ETH_P_IPV6):
> +   if (flags & (XEN_NETIF_CTRL_TOEPLITZ_HASH_IPV6_TCP |
> +XEN_NETIF_CTRL_TOEPLITZ_HASH_IPV6))
> +   break;
> +
> +   goto done;
> +
> +   default:
> +   goto done;
> +   }
> +
> +   memset(, 0, sizeof(flow));
> +   if (!skb_flow_dissect_flow_keys(skb, , 0))

Flow dissector will parse into encapsulations to find IP addresses.
This may or may not be what you want (we'd have to look at NDIS spec).

> +

[Xen-devel] [qemu-upstream-4.5-testing test] 82431: regressions - FAIL

2016-02-14 Thread osstest service owner

flight 82431 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82431/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
77858

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 14 guest-saverestore.2 fail in 82131 pass in 82431
 test-armhf-armhf-libvirt-raw  6 xen-bootfail pass in 82131

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 77858
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 77137
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 77752

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 10 guest-start   fail in 82131 never pass
 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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-qcow2 10 guest-start  fail 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  10 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu6d285f1ceb317286c3198a1a13737baa303a814f
baseline version:
 qemuu32bba3499008c847e08858f310d65806e0bade36

Last test of basis77858  2016-01-11 19:23:09 Z   34 days
Failing since 80731  2016-02-05 15:18:36 Z9 days4 attempts
Testing same since82131  2016-02-12 11:00:21 Z2 days2 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Jason Wang 
  John Snow 
  Laszlo Ersek 
  Michael S. Tsirkin 
  P J P 
  Paolo Bonzini 
  Peter Maydell 
  Prasad J Pandit 
  Roger Pau Monne 
  Roger Pau MonnÃ© 
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

2016-02-14 Thread Zhang, Haozhong

On 02/04/16 20:24, Stefano Stabellini wrote:
> On Thu, 4 Feb 2016, Haozhong Zhang wrote:
> > On 02/03/16 15:22, Stefano Stabellini wrote:
> > > On Wed, 3 Feb 2016, George Dunlap wrote:
> > > > On 03/02/16 12:02, Stefano Stabellini wrote:
> > > > > On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> > > > >> Or, we can make a file system on /dev/pmem0, create files on it, set
> > > > >> the owner of those files to xen-qemuuser-domid$domid, and then pass
> > > > >> those files to QEMU. In this way, non-root QEMU should be able to
> > > > >> mmap those files.
> > > > >
> > > > > Maybe that would work. Worth adding it to the design, I would like to
> > > > > read more details on it.
> > > > >
> > > > > Also note that QEMU initially runs as root but drops privileges to
> > > > > xen-qemuuser-domid$domid before the guest is started. Initially QEMU
> > > > > *could* mmap /dev/pmem0 while is still running as root, but then it
> > > > > wouldn't work for any devices that need to be mmap'ed at run time
> > > > > (hotplug scenario).
> > > >
> > > > This is basically the same problem we have for a bunch of other things,
> > > > right?  Having xl open a file and then pass it via qmp to qemu should
> > > > work in theory, right?
> > >
> > > Is there one /dev/pmem? per assignable region?
> > 
> > Yes.
> > 
> > BTW, I'm wondering whether and how non-root qemu works with xl disk
> > configuration that is going to access a host block device, e.g.
> >  disk = [ '/dev/sdb,,hda' ]
> > If that works with non-root qemu, I may take the similar solution for
> > pmem.
>  
> Today the user is required to give the correct ownership and access mode
> to the block device, so that non-root QEMU can open it. However in the
> case of PCI passthrough, QEMU needs to mmap /dev/mem, as a consequence
> the feature doesn't work at all with non-root QEMU
> (http://marc.info/?l=xen-devel=145261763600528).
> 
> If there is one /dev/pmem device per assignable region, then it would be
> conceivable to change its ownership so that non-root QEMU can open it.
> Or, better, the file descriptor could be passed by the toolstack via
> qmp.

Passing file descriptor via qmp is not enough.

Let me clarify where the requirement for root/privileged permissions
comes from. The primary workflow in my design that maps a host pmem
region or files in host pmem region to guest is shown as below:
 (1) QEMU in Dom0 mmap the host pmem (the host /dev/pmem0 or files on
 /dev/pmem0) to its virtual address space, i.e. the guest virtual
 address space.
 (2) QEMU asks Xen hypervisor to map the host physical address, i.e. SPA
 occupied by the host pmem to a DomU. This step requires the
 translation from the guest virtual address (where the host pmem is
 mmaped in (1)) to the host physical address. The translation can be
 done by either
(a) QEMU that parses its own /proc/self/pagemap,
 or
(b) Xen hypervisor that does the translation by itself [1] (though
this choice is not quite doable from Konrad's comments [2]).

[1] http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00434.html
[2] http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00606.html

For 2-a, reading /proc/self/pagemap requires CAP_SYS_ADMIN capability
since linux kernel 4.0. Furthermore, if we don't mlock the mapped host
pmem (by adding MAP_LOCKED flag to mmap or calling mlock after mmap),
pagemap will not contain all mappings. However, mlock may require
privileged permission to lock memory larger than RLIMIT_MEMLOCK. Because
mlock operates on memory, the permission to open(2) the host pmem files
does not solve the problem and therefore passing file descriptor via qmp
does not help.

For 2-b, from Konrad's comments [2], mlock is also required and
privileged permission may be required consequently.

Note that the mapping and the address translation are done before QEMU
dropping privileged permissions, so non-root QEMU should be able to work
with above design until we start considering vNVDIMM hotplug (which has
not been supported by the current vNVDIMM implementation in QEMU). In
the hotplug case, we may let Xen pass explicit flags to QEMU to keep it
running with root permissions.

Haozhong

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-coverity test] 82477: all pass - PUSHED

2016-02-14 Thread osstest service owner

flight 82477 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82477/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 xen  483ad4439f7fc71e12d46dae516f2b9ab2b977ad
baseline version:
 xen  1ac81bb7166b79b6555290547d4e305c74d0

Last test of basis81806  2016-02-10 14:16:39 Z4 days
Testing same since82477  2016-02-14 09:19:06 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Dario Faggioli 
  George Dunlap 
  Ian Campbell 
  Juergen Gross 
  Razvan Cojocaru 
  Tamas K Lengyel 

jobs:
 coverity-amd64   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-coverity
+ revision=483ad4439f7fc71e12d46dae516f2b9ab2b977ad
+ . ./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-coverity 483ad4439f7fc71e12d46dae516f2b9ab2b977ad
+ branch=xen-unstable-coverity
+ revision=483ad4439f7fc71e12d46dae516f2b9ab2b977ad
+ . ./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-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-unstable
+ '[' x483ad4439f7fc71e12d46dae516f2b9ab2b977ad = 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();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ :

[Xen-devel] [linux-linus test] 82419: regressions - trouble: blocked/broken/fail/pass

2016-02-14 Thread osstest service owner

flight 82419 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82419/

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. 59254
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  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-xsm   8 leak-check/basis(8)   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  8 leak-check/basis(8) fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  8 leak-check/basis(8)  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  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-amd64-libvirt 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-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 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-amd64-amd64-libvirt-xsm 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-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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:
 linux4617c2203fbc36f496e6d1060299ba27b8e4d01c
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  220 days
Failing since 59348  2015-07-10 04:24:05 Z  219 days  150 attempts
Testing same since82419  2016-02-14 00:17:15 Z1 days1 attempts


4063 people touched revisions

[Xen-devel] [PATCH 4/5] drivers/xen: make sys-hypervisor.c explicitly non-modular

2016-02-14 Thread Paul Gortmaker

The Kconfig currently controlling compilation of this code is:

config XEN_SYS_HYPERVISOR
   bool "Create xen entries under /sys/hypervisor"

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.  However
one could argue that fs_initcall() might make more sense here.

This change means that the one line function xen_properties_destroy()
has only one user left, and since that is inside an #ifdef, we just
manually inline it there vs. adding more ifdeffery around the function
to avoid compile warnings about "defined but not used".

Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Paul Gortmaker 
---
 drivers/xen/sys-hypervisor.c | 31 ---
 1 file changed, 4 insertions(+), 27 deletions(-)

diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index b5a7342e0ba5..ea6e98d60af0 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -9,7 +9,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -366,11 +366,6 @@ static int __init xen_properties_init(void)
return sysfs_create_group(hypervisor_kobj, _properties_group);
 }
 
-static void xen_properties_destroy(void)
-{
-   sysfs_remove_group(hypervisor_kobj, _properties_group);
-}
-
 #ifdef CONFIG_XEN_HAVE_VPMU
 struct pmu_mode {
const char *name;
@@ -484,11 +479,6 @@ static int __init xen_pmu_init(void)
 {
return sysfs_create_group(hypervisor_kobj, _pmu_group);
 }
-
-static void xen_pmu_destroy(void)
-{
-   sysfs_remove_group(hypervisor_kobj, _pmu_group);
-}
 #endif
 
 static int __init hyper_sysfs_init(void)
@@ -517,7 +507,8 @@ static int __init hyper_sysfs_init(void)
if (xen_initial_domain()) {
ret = xen_pmu_init();
if (ret) {
-   xen_properties_destroy();
+   sysfs_remove_group(hypervisor_kobj,
+  _properties_group);
goto prop_out;
}
}
@@ -535,21 +526,7 @@ version_out:
 out:
return ret;
 }
-
-static void __exit hyper_sysfs_exit(void)
-{
-#ifdef CONFIG_XEN_HAVE_VPMU
-   xen_pmu_destroy();
-#endif
-   xen_properties_destroy();
-   xen_compilation_destroy();
-   xen_sysfs_uuid_destroy();
-   xen_sysfs_version_destroy();
-   xen_sysfs_type_destroy();
-
-}
-module_init(hyper_sysfs_init);
-module_exit(hyper_sysfs_exit);
+device_initcall(hyper_sysfs_init);
 
 static ssize_t hyp_sysfs_show(struct kobject *kobj,
  struct attribute *attr,
-- 
2.6.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/5] drivers/xen: make [xen-]ballon explicitly non-modular

2016-02-14 Thread Paul Gortmaker

The Makefile / Kconfig currently controlling compilation here is:

obj-y   += grant-table.o features.o balloon.o manage.o preempt.o time.o
[...]
obj-$(CONFIG_XEN_BALLOON)   += xen-balloon.o

...with:

drivers/xen/Kconfig:config XEN_BALLOON
drivers/xen/Kconfig:bool "Xen memory balloon driver"

...meaning that they currently are not being built as modules by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

In doing so we uncover two implict includes that were obtained
by module.h having such a wide include scope itself:

In file included from drivers/xen/xen-balloon.c:41:0:
include/xen/balloon.h:26:51: warning: ‘struct page’ declared inside parameter 
list [enabled by default]
 int alloc_xenballooned_pages(int nr_pages, struct page **pages);
   ^
include/xen/balloon.h: In function ‘register_xen_selfballooning’:
include/xen/balloon.h:35:10: error: ‘ENOSYS’ undeclared (first use in this 
function)
  return -ENOSYS;
  ^

This is fixed by adding mm-types.h and errno.h to the list.

We also delete the MODULE_LICENSE tags since all that information
is already contained at the top of the file in the comments.

Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Paul Gortmaker 
---
 drivers/xen/balloon.c |  4 
 drivers/xen/xen-balloon.c | 14 +++---
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 7c8a2cf16f58..9781e0dd59d6 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -42,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -760,7 +759,4 @@ static int __init balloon_init(void)
 
return 0;
 }
-
 subsys_initcall(balloon_init);
-
-MODULE_LICENSE("GPL");
diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
index 39e7ef8d3957..79865b8901ba 100644
--- a/drivers/xen/xen-balloon.c
+++ b/drivers/xen/xen-balloon.c
@@ -33,7 +33,9 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
-#include 
+#include 
+#include 
+#include 
 #include 
 
 #include 
@@ -109,14 +111,6 @@ static int __init balloon_init(void)
 }
 subsys_initcall(balloon_init);
 
-static void balloon_exit(void)
-{
-/* XXX - release balloon here */
-return;
-}
-
-module_exit(balloon_exit);
-
 #define BALLOON_SHOW(name, format, args...)\
static ssize_t show_##name(struct device *dev,  \
   struct device_attribute *attr,   \
@@ -250,5 +244,3 @@ static int register_balloon(struct device *dev)
 
return 0;
 }
-
-MODULE_LICENSE("GPL");
-- 
2.6.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 5/5] drivers/xen: make platform-pci.c explicitly non-modular

2016-02-14 Thread Paul Gortmaker

The Kconfig currently controlling compilation of this code is:

arch/x86/xen/Kconfig:config XEN_PVHVM
arch/x86/xen/Kconfig:   def_bool y

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.

Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Paul Gortmaker 
---
 drivers/xen/platform-pci.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 3454973dc3bb..302232518c98 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -2,6 +2,9 @@
  * platform-pci.c
  *
  * Xen platform PCI device driver
+ *
+ * Authors: ssm...@xensource.com and stefano.stabell...@eu.citrix.com
+ *
  * Copyright (c) 2005, Intel Corporation.
  * Copyright (c) 2007, XenSource Inc.
  * Copyright (c) 2010, Citrix
@@ -24,7 +27,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
@@ -36,10 +39,6 @@
 
 #define DRV_NAME"xen-platform-pci"
 
-MODULE_AUTHOR("ssm...@xensource.com and stefano.stabell...@eu.citrix.com");
-MODULE_DESCRIPTION("Xen platform PCI device");
-MODULE_LICENSE("GPL");
-
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
@@ -181,8 +180,6 @@ static struct pci_device_id platform_pci_tbl[] = {
{0,}
 };
 
-MODULE_DEVICE_TABLE(pci, platform_pci_tbl);
-
 static struct pci_driver platform_driver = {
.name =   DRV_NAME,
.probe =  platform_pci_init,
@@ -192,9 +189,8 @@ static struct pci_driver platform_driver = {
 #endif
 };
 
-static int __init platform_pci_module_init(void)
+static int __init platform_pci_xen_init(void)
 {
return pci_register_driver(_driver);
 }
-
-module_init(platform_pci_module_init);
+device_initcall(platform_pci_xen_init);
-- 
2.6.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/5] xen: audit usages of module.h ; remove unnecessary instances

2016-02-14 Thread Paul Gortmaker

Code that uses no modular facilities whatsoever should not be
sourcing module.h at all, since that header drags in a bunch
of other headers with it.

Similarly, code that is not explicitly using modular facilities
like module_init() but only is declaring module_param setup
variables should be using moduleparam.h and not the larger
module.h file for that.

In making this change, we also uncover an implicit use of BUG()
in inline fcns within arch/arm/include/asm/xen/hypercall.h so
we explicitly source  for that file now.

Cc: Stefano Stabellini 
Cc: Russell King 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: xen-de...@lists.xenproject.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Paul Gortmaker 
---
 arch/arm/include/asm/xen/hypercall.h  | 2 ++
 drivers/xen/events/events_2l.c| 1 -
 drivers/xen/events/events_base.c  | 2 +-
 drivers/xen/events/events_fifo.c  | 1 -
 drivers/xen/features.c| 2 +-
 drivers/xen/grant-table.c | 1 -
 drivers/xen/xen-pciback/conf_space.c  | 2 +-
 drivers/xen/xen-pciback/pciback_ops.c | 2 +-
 drivers/xen/xen-pciback/xenbus.c  | 2 +-
 drivers/xen/xen-selfballoon.c | 1 -
 drivers/xen/xenbus/xenbus_xs.c| 1 -
 drivers/xen/xenfs/xensyms.c   | 1 -
 12 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
index d769972db8cb..b6b962d70db9 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -33,6 +33,8 @@
 #ifndef _ASM_ARM_XEN_HYPERCALL_H
 #define _ASM_ARM_XEN_HYPERCALL_H
 
+#include 
+
 #include 
 #include 
 #include 
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index 7dd46312c180..51b488f5bfe9 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 524c22146429..488017a0806a 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index eff2b88003d9..9289a17712e2 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/xen/features.c b/drivers/xen/features.c
index 99eda169c779..d7d34fdfc993 100644
--- a/drivers/xen/features.c
+++ b/drivers/xen/features.c
@@ -7,7 +7,7 @@
  */
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index effbaf91791f..bb36b1e1dbcc 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -33,7 +33,6 @@
 
 #define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/xen/xen-pciback/conf_space.c 
b/drivers/xen/xen-pciback/conf_space.c
index 9c234209d8b5..8e67336f8ddd 100644
--- a/drivers/xen/xen-pciback/conf_space.c
+++ b/drivers/xen/xen-pciback/conf_space.c
@@ -10,7 +10,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include "pciback.h"
 #include "conf_space.h"
diff --git a/drivers/xen/xen-pciback/pciback_ops.c 
b/drivers/xen/xen-pciback/pciback_ops.c
index 73dafdc494aa..5ad01f9c24fc 100644
--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers/xen/xen-pciback/pciback_ops.c
@@ -6,7 +6,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 4843741e703a..c252eb3f0176 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -6,7 +6,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c
index 3b2bffde534f..53a085fca00c 100644
--- a/drivers/xen/xen-selfballoon.c
+++ b/drivers/xen/xen-selfballoon.c
@@ -71,7 +71,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index ba804f3d8278..374b12af8812 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -44,7 +44,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/xen/xenfs/xensyms.c b/drivers/xen/xenfs/xensyms.c
index a03f261b12d8..c6e2b4a542ea 100644
--- a/drivers/xen/xenfs/xensyms.c
+++ b/drivers/xen/xenfs/xensyms.c

[Xen-devel] [PATCH 0/5] xen: avoid module usage in non-modular code

2016-02-14 Thread Paul Gortmaker

This series of commits is a part of a larger project to ensure
people don't reference modular support functions in non-modular
code.  Overall there was roughly 5k lines of dead code in the
kernel due to this.  So far we've fixed several areas, like tty,
x86, net, ... and we continue to work on other areas.

There are several reasons to not use module support for code that
can never be built as a module, but the big ones are:

 (1) it is easy to accidentally write unused module_exit and remove code
 (2) it can be misleading when reading the source, thinking it can be
  modular when the Makefile and/or Kconfig prohibit it
 (3) it requires the include of the module.h header file which in turn
 includes nearly everything else.
 (4) it gets copied/replicated into other code and spreads like weeds.

For the xen subsystem, there are just five commits:

First, we get rid of "include " instances that are
completely unnecessary.

Then #2 and #3 and #5 are basically trivial remapping to the
appropriate non-modular counterparts, meaning that there is no
runtime change here either.

The fourth hypervisor commit is similar, but also has removal of
some dead code associated with the module_exit function that will
never be called.  So the runtime should be the same, but the object
file will be different (reduced in size).

Patches created on linux-next and build tested for x86-64 and ARM64
allmodconfig.

---

Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Konrad Rzeszutek Wilk 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Russell King 
Cc: Stefano Stabellini 
Cc: xen-de...@lists.xenproject.org

Paul Gortmaker (5):
  xen: audit usages of module.h ; remove unnecessary instances
  drivers/xen: make [xen-]ballon explicitly non-modular
  drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular
  drivers/xen: make sys-hypervisor.c explicitly non-modular
  drivers/xen: make platform-pci.c explicitly non-modular

 arch/arm/include/asm/xen/hypercall.h |  2 ++
 drivers/xen/balloon.c|  4 
 drivers/xen/events/events_2l.c   |  1 -
 drivers/xen/events/events_base.c |  2 +-
 drivers/xen/events/events_fifo.c |  1 -
 drivers/xen/features.c   |  2 +-
 drivers/xen/grant-table.c|  1 -
 drivers/xen/platform-pci.c   | 16 ++--
 drivers/xen/sys-hypervisor.c | 31 ---
 drivers/xen/xen-balloon.c| 14 +++---
 drivers/xen/xen-pciback/conf_space.c |  2 +-
 drivers/xen/xen-pciback/pciback_ops.c|  2 +-
 drivers/xen/xen-pciback/xenbus.c |  2 +-
 drivers/xen/xen-selfballoon.c|  1 -
 drivers/xen/xenbus/xenbus_dev_backend.c  | 13 ++---
 drivers/xen/xenbus/xenbus_dev_frontend.c | 13 ++---
 drivers/xen/xenbus/xenbus_xs.c   |  1 -
 drivers/xen/xenfs/xensyms.c  |  1 -
 18 files changed, 24 insertions(+), 85 deletions(-)

-- 
2.6.1

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/5] drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular

2016-02-14 Thread Paul Gortmaker

The Makefile / Kconfig currently controlling compilation here is:

obj-y   += xenbus_dev_frontend.o
[...]
obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o

...with:

drivers/xen/Kconfig:config XEN_BACKEND
drivers/xen/Kconfig:bool "Backend driver support"

...meaning that they currently are not being built as modules by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

We also delete the MODULE_LICENSE tag since all that information
is already contained at the top of the file in the comments.

Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Paul Gortmaker 
---
 drivers/xen/xenbus/xenbus_dev_backend.c  | 13 ++---
 drivers/xen/xenbus/xenbus_dev_frontend.c | 13 ++---
 2 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c 
b/drivers/xen/xenbus/xenbus_dev_backend.c
index ee6d9efd7b76..4a41ac9af966 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -5,7 +5,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
@@ -18,8 +18,6 @@
 
 #include "xenbus_comms.h"
 
-MODULE_LICENSE("GPL");
-
 static int xenbus_backend_open(struct inode *inode, struct file *filp)
 {
if (!capable(CAP_SYS_ADMIN))
@@ -132,11 +130,4 @@ static int __init xenbus_backend_init(void)
pr_err("Could not register xenbus backend device\n");
return err;
 }
-
-static void __exit xenbus_backend_exit(void)
-{
-   misc_deregister(_backend_dev);
-}
-
-module_init(xenbus_backend_init);
-module_exit(xenbus_backend_exit);
+device_initcall(xenbus_backend_init);
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 9433e46518c8..8c0a359ab4a8 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "xenbus_comms.h"
 
@@ -63,8 +63,6 @@
 #include 
 #include 
 
-MODULE_LICENSE("GPL");
-
 /*
  * An element of a list of outstanding transactions, for which we're
  * still waiting a reply.
@@ -624,11 +622,4 @@ static int __init xenbus_init(void)
pr_err("Could not register xenbus frontend device\n");
return err;
 }
-
-static void __exit xenbus_exit(void)
-{
-   misc_deregister(_dev);
-}
-
-module_init(xenbus_init);
-module_exit(xenbus_exit);
+device_initcall(xenbus_init);
-- 
2.6.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 82388: regressions - FAIL

2016-02-14 Thread osstest service owner

flight 82388 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82388/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-build fail REGR. vs. 79947
 build-amd64-xsm   5 xen-build fail REGR. vs. 79947
 build-i3865 xen-build fail REGR. vs. 79947
 build-i386-xsm5 xen-build fail REGR. vs. 79947
 build-armhf   5 xen-build fail REGR. vs. 79947
 build-armhf-xsm   5 xen-build fail REGR. vs. 79947

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  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-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   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-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  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-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   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-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-pair  1 build-check(1)

[Xen-devel] [linux-mingo-tip-master test] 82303: regressions - FAIL

2016-02-14 Thread osstest service owner

flight 82303 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82303/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 build-amd64-xsm   5 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684

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   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-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-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  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-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux50366e8396d97e86fcf0a88b7aa57832e2542dba
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  185 days
Failing since 60712  2015-08-15 18:33:48 Z  183 days  130 attempts
Testing same since82303  2016-02-13 11:46:21 Z1 days1 attempts

jobs:
 build-amd64-xsm  fail
 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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm blocked 
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked

[Xen-devel] [linux-4.1 test] 82264: regressions - FAIL

2016-02-14 Thread osstest service owner

flight 82264 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82264/

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. 66399
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-xsm  16 guest-start.2fail in 80172 REGR. vs. 66399

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  11 guest-startfail in 80752 pass in 82264
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 80752 pass 
in 82264
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat   fail pass in 80172
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 80752
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 80752

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 80752 like 66399
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399

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-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 80752 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 80752 never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-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-amd64-libvirt 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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  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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linux2d5f6b0413359df065fd02d695c08bbc7d998bbd
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis66399  2015-12-15 18:20:39 Z   61 days
Failing since 78925  2016-01-24 13:50:39 Z   21 days   21 attempts
Testing same since79642  2016-01-31 21:28:16 Z   13 days   12 attempts


People who touched revisions under test:
  Acked-by: David Howells 
  Al Viro 
  Alan Stern 
  Alexandra Yates 
  Alexandru

[Xen-devel] [xen-unstable test] 82212: tolerable FAIL - PUSHED

2016-02-14 Thread osstest service owner

flight 82212 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82212/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 81620
 build-amd64-rumpuserxen   6 xen-buildfail   like 81620
 build-i386-rumpuserxen6 xen-buildfail   like 81620
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 81620
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 81620
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 81620

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 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   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-i386-libvirt-xsm  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-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-amd64-libvirt 12 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-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-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-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  bcfaea685d38c08e5eb90797512ab80f0bc69d0c
baseline version:
 xen  483ad4439f7fc71e12d46dae516f2b9ab2b977ad

Last test of basis81620  2016-02-09 13:15:44 Z5 days
Failing since 81888  2016-02-11 01:50:31 Z3 days2 attempts
Testing same since82212  2016-02-12 22:21:45 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Doug Goldstein 
  George Dunlap 
  Harmandeep Kaur 
  Ian Campbell 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Olaf Hering 
  Paul Durrant 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64

[Xen-devel] [libvirt test] 82239: regressions - FAIL

2016-02-14 Thread osstest service owner

flight 82239 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82239/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-build fail REGR. vs. 80121

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   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-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  98782f88991a390a358cea960b5776f72fc14451
baseline version:
 libvirt  6ec319b84f67d72bf59fe7e0fd41d88ee9c393c7

Last test of basis80121  2016-02-03 04:26:28 Z   11 days
Failing since 80382  2016-02-04 04:29:24 Z   10 days8 attempts
Testing same since82239  2016-02-13 01:57:52 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Daniel P. Berrange 
  Dmitry Andreev 
  Erik Skultety 
  Joao Martins 
  John Ferlan 
  JÃ¡n Tomko 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Peter Krempa 
  Roman Bogorodskiy 
  Wido den Hollander 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  blocked
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm blocked
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt blocked
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  blocked
 test-amd64-amd64-libvirt-pairblocked
 test-amd64-i386-libvirt-pair blocked
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd 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

Re: [Xen-devel] [PATCH V3] vm_event: Remove xc_mem_access_enable_emulate() and friends

2016-02-14 Thread Tamas K Lengyel

On Sun, Feb 14, 2016 at 1:38 AM, Razvan Cojocaru 
wrote:

> xc_mem_access_enable_emulate() and xc_mem_access_disable_emulate()
> are currently no-ops, that is all they do is set a flag that
> nobody else checks. The user can already set the EMULATE flags in
> the vm_event response if emulation is desired, and having an extra
> check above that is not inherently safer, but it does complicate
> (currenly unnecessarily) the API. This patch removes these
> functions and the corresponding hypervisor code.
>
> Signed-off-by: Razvan Cojocaru 
>

Looks good, thanks!

Acked-by: Tamas K Lengyel 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.4-testing test] 82234: tolerable FAIL - PUSHED

2016-02-14 Thread osstest service owner

flight 82234 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82234/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10  fail like 66772

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu352a3530ec72cbf6dda8ba00c103e49951e77f90
baseline version:
 qemuu2264b0c66075cc34c252a1386f019f8be6240890

Last test of basis77834  2016-01-11 13:28:00 Z   34 days
Failing since 80734  2016-02-05 15:19:13 Z9 days6 attempts
Testing same since82234  2016-02-13 01:24:47 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Jason Wang 
  John Snow 
  Laszlo Ersek 
  Michael S. Tsirkin 
  P J P 
  Paolo Bonzini 
  Peter Maydell 
  Prasad J Pandit 
  Roger Pau Monne 
  Roger Pau MonnÃ© 
  Stefano Stabellini 

jobs:
 build-amd64-xend pass
 build-i386-xend  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  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 pass
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+

[Xen-devel] [qemu-upstream-4.6-testing test] 82162: regressions - FAIL

2016-02-14 Thread osstest service owner

flight 82162 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82162/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  6 xen-bootfail REGR. vs. 77722
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 77722

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 77722

Tests which did not succeed, but are not blocking:
 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 14 guest-saverestorefail   never pass
 test-armhf-armhf-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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   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-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-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  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-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-rtds 11 guest-start  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-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:
 qemuu36d4ccc357252ff5506352c4815533f0a3ebc116
baseline version:
 qemuu9e304f572ac98265f5e7433b6490077962acda97

Last test of basis77722  2016-01-10 11:19:40 Z   34 days
Failing since 80733  2016-02-05 15:18:36 Z8 days3 attempts
Testing same since82162  2016-02-12 15:03:36 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Jason Wang 
  John Snow 
  Laszlo Ersek 
  Michael S. Tsirkin 
  P J P 
  Paolo Bonzini 
  Peter Maydell 
  Prasad J Pandit 
  Roger Pau Monne 
  Roger Pau MonnÃ© 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl

[Xen-devel] [PATCH V3] vm_event: Remove xc_mem_access_enable_emulate() and friends

2016-02-14 Thread Razvan Cojocaru

xc_mem_access_enable_emulate() and xc_mem_access_disable_emulate()
are currently no-ops, that is all they do is set a flag that
nobody else checks. The user can already set the EMULATE flags in
the vm_event response if emulation is desired, and having an extra
check above that is not inherently safer, but it does complicate
(currenly unnecessarily) the API. This patch removes these
functions and the corresponding hypervisor code.

Signed-off-by: Razvan Cojocaru 

---
Changes since V1:
 - Commented-out the XENMEM_access_op_enable_emulate and
   XENMEM_access_op_disable_emulate #defines instead of simply
   removing them to prevent their reuse, as requested by
   Jan Beulich.
---
 tools/libxc/include/xenctrl.h | 11 ---
 tools/libxc/xc_mem_access.c   | 24 
 xen/common/mem_access.c   |  8 
 xen/include/asm-arm/p2m.h | 14 --
 xen/include/asm-x86/domain.h  |  1 -
 xen/include/asm-x86/p2m.h | 24 
 xen/include/public/memory.h   |  9 +++--
 7 files changed, 7 insertions(+), 84 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 1a5f4ec..42eafa4 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2101,17 +2101,6 @@ int xc_set_mem_access(xc_interface *xch, domid_t 
domain_id,
 int xc_get_mem_access(xc_interface *xch, domid_t domain_id,
   uint64_t pfn, xenmem_access_t *access);
 
-/*
- * Instructions causing a mem_access violation can be emulated by Xen
- * to progress the execution without having to relax the mem_access
- * permissions.
- * This feature has to be first enabled, then in the vm_event
- * response to a mem_access event it can be indicated if the instruction
- * should be emulated.
- */
-int xc_mem_access_enable_emulate(xc_interface *xch, domid_t domain_id);
-int xc_mem_access_disable_emulate(xc_interface *xch, domid_t domain_id);
-
 /***
  * Monitor control operations.
  *
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 3634c39..eee088c 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -62,30 +62,6 @@ int xc_get_mem_access(xc_interface *xch,
 return rc;
 }
 
-int xc_mem_access_enable_emulate(xc_interface *xch,
- domid_t domain_id)
-{
-xen_mem_access_op_t mao =
-{
-.op = XENMEM_access_op_enable_emulate,
-.domid  = domain_id,
-};
-
-return do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
-}
-
-int xc_mem_access_disable_emulate(xc_interface *xch,
-  domid_t domain_id)
-{
-xen_mem_access_op_t mao =
-{
-.op = XENMEM_access_op_disable_emulate,
-.domid  = domain_id,
-};
-
-return do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index 159c036..0fb6699 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -98,14 +98,6 @@ int mem_access_memop(unsigned long cmd,
 break;
 }
 
-case XENMEM_access_op_enable_emulate:
-rc = p2m_mem_access_enable_emulate(d);
-break;
-
-case XENMEM_access_op_disable_emulate:
-rc = p2m_mem_access_disable_emulate(d);
-break;
-
 default:
 rc = -ENOSYS;
 break;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 4c62725..433952a 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -89,20 +89,6 @@ typedef enum {
 } p2m_type_t;
 
 static inline
-int p2m_mem_access_enable_emulate(struct domain *d)
-{
-/* Not supported on ARM */
-return -ENOSYS;
-}
-
-static inline
-int p2m_mem_access_disable_emulate(struct domain *d)
-{
-/* Not supported on ARM */
-return -ENOSYS;
-}
-
-static inline
 void p2m_mem_access_emulate_check(struct vcpu *v,
   const vm_event_response_t *rsp)
 {
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 4072e27..4fad638 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -390,7 +390,6 @@ struct arch_domain
 } monitor;
 
 /* Mem_access emulation control */
-bool_t mem_access_emulate_enabled;
 bool_t mem_access_emulate_each_rep;
 
 /* Emulated devices enabled bitmap. */
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index fa46dd9..2a90491 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -647,30 +647,6 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
 struct npfec npfec,
 vm_event_request_t **req_ptr);
 
-/*
- * Emulating a memory access requires custom handling. These non-atomic
- * functions should be called under domctl lock.
- */
-static inline
-int p2m_mem_access_enable_emulate(struct domain *d)
-{
-

Re: [Xen-devel] [PATCH V3] vm_event: Remove xc_mem_access_enable_emulate() and friends

2016-02-14 Thread Razvan Cojocaru

On 02/14/2016 10:38 AM, Razvan Cojocaru wrote:
> xc_mem_access_enable_emulate() and xc_mem_access_disable_emulate()
> are currently no-ops, that is all they do is set a flag that
> nobody else checks. The user can already set the EMULATE flags in
> the vm_event response if emulation is desired, and having an extra
> check above that is not inherently safer, but it does complicate
> (currenly unnecessarily) the API. This patch removes these
> functions and the corresponding hypervisor code.
> 
> Signed-off-by: Razvan Cojocaru 
> 
> ---
> Changes since V1:
>  - Commented-out the XENMEM_access_op_enable_emulate and
>XENMEM_access_op_disable_emulate #defines instead of simply
>removing them to prevent their reuse, as requested by
>Jan Beulich.

I apologize for the typo, it's obviously V2.


Thanks,
Razvan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01

2016-02-14 Thread Steven Haigh

Hi all,

Just been looking at the polarssl parts in Xen 4.6 and others - seems
like we're hard coded to version 1.1.4 which was released on 31st May 2012.

Branch 1.1.x has been EOL for a number of years, 1.2.x has been EOL
since Jan.

It's now called mbedtls and current versions are 2.2.1 released in Jan
this year.

I'm not exactly clear on what polarssl is used for (and why not
openssl?) - but is it time this was shown some loving?

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-unstable test] 82198: tolerable FAIL - PUSHED

2016-02-14 Thread osstest service owner

flight 82198 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82198/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 80694
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 80694
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 80694

Tests which did not succeed, but are not blocking:
 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 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   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-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass

version targeted for testing:
 qemuu4c15fc66f7764a921ba2fc43cc3cb7b89e0cd35e
baseline version:
 qemuue9d825298c0d7e14caf6c4d36d4d3894d138f858

Last test of basis80694  2016-02-05 11:52:32 Z8 days
Failing since 80923  2016-02-06 13:10:41 Z7 days5 attempts
Testing same since82198  2016-02-12 19:59:04 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Jason Wang 
  John Snow 
  Michael S. Tsirkin 
  P J P 
  Paolo Bonzini 
  Peter Maydell 
  Prasad J Pandit 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl

[Xen-devel] [PATCH] x86/HVM: fold hypercall tables

[Xen-devel] [PATCH] common: re-arrange struct kernel_param fields

[Xen-devel] [libvirt test] 82511: tolerable FAIL - PUSHED

[Xen-devel] [PATCH v3 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

[Xen-devel] [PATCH v3 1/2] xen/x86: merge 2 hvm_event_... functions into 1

[Xen-devel] [PATCH v3 0/2] Vm-events: move monitor vm-events code to common-side.

Re: [Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support

[Xen-devel] [qemu-upstream-4.6-testing test] 82482: tolerable FAIL - PUSHED

Re: [Xen-devel] [PATCH v8 5/5] Scripts to create and delete xen-scsiback nodes in Linux target framework

[Xen-devel] [ovmf test] 82450: regressions - FAIL

Re: [Xen-devel] [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

Re: [Xen-devel] [PATCH net-next v1 1/8] skbuff: store hash type in socket buffer...

Re: [Xen-devel] [PATCH net-next v1 7/8] xen-netback: pass toeplitz hash value to the frontend

Re: [Xen-devel] [PATCH net-next v1 6/8] xen-netback: add an implementation of toeplitz hashing...

[Xen-devel] [qemu-upstream-4.5-testing test] 82431: regressions - FAIL

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

[Xen-devel] [xen-unstable-coverity test] 82477: all pass - PUSHED

[Xen-devel] [linux-linus test] 82419: regressions - trouble: blocked/broken/fail/pass

[Xen-devel] [PATCH 4/5] drivers/xen: make sys-hypervisor.c explicitly non-modular

[Xen-devel] [PATCH 2/5] drivers/xen: make [xen-]ballon explicitly non-modular

[Xen-devel] [PATCH 5/5] drivers/xen: make platform-pci.c explicitly non-modular

[Xen-devel] [PATCH 1/5] xen: audit usages of module.h ; remove unnecessary instances

[Xen-devel] [PATCH 0/5] xen: avoid module usage in non-modular code

[Xen-devel] [PATCH 3/5] drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular

[Xen-devel] [qemu-mainline test] 82388: regressions - FAIL

[Xen-devel] [linux-mingo-tip-master test] 82303: regressions - FAIL

[Xen-devel] [linux-4.1 test] 82264: regressions - FAIL

[Xen-devel] [xen-unstable test] 82212: tolerable FAIL - PUSHED

[Xen-devel] [libvirt test] 82239: regressions - FAIL

Re: [Xen-devel] [PATCH V3] vm_event: Remove xc_mem_access_enable_emulate() and friends

[Xen-devel] [qemu-upstream-4.4-testing test] 82234: tolerable FAIL - PUSHED

[Xen-devel] [qemu-upstream-4.6-testing test] 82162: regressions - FAIL

[Xen-devel] [PATCH V3] vm_event: Remove xc_mem_access_enable_emulate() and friends

Re: [Xen-devel] [PATCH V3] vm_event: Remove xc_mem_access_enable_emulate() and friends

[Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01

[Xen-devel] [qemu-upstream-unstable test] 82198: tolerable FAIL - PUSHED

36 matches

Site Navigation

Mail list logo

Footer information