Re: [Xen-devel] [PATCH v2 19/30] x86/cpu: Rework Intel masking/faulting setup

[Jan Beulich]

>>> On 05.02.16 at 14:42,  wrote:
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -18,11 +18,18 @@
>  
>  #define select_idle_routine(x) ((void)0)
>  
> -static unsigned int probe_intel_cpuid_faulting(void)
> +static bool_t __init probe_intel_cpuid_faulting(void)
>  {
>   uint64_t x;
> - return !rdmsr_safe(MSR_INTEL_PLATFORM_INFO, x) &&
> - (x & MSR_PLATFORM_INFO_CPUID_FAULTING);
> +
> + if ( rdmsr_safe(MSR_INTEL_PLATFORM_INFO, x) ||
> +  !(x & MSR_PLATFORM_INFO_CPUID_FAULTING) )
> + return 0;

Partial Xen coding style again.

> @@ -44,41 +51,46 @@ void set_cpuid_faulting(bool_t enable)
>  }
>  
>  /*
> - * opt_cpuid_mask_ecx/edx: cpuid.1[ecx, edx] feature mask.
> - * For example, E8400[Intel Core 2 Duo Processor series] ecx = 0x0008E3FD,
> - * edx = 0xBFEBFBFF when executing CPUID.EAX = 1 normally. If you want to
> - * 'rev down' to E8400, you can set these values in these Xen boot 
> parameters.
> + * Set caps in expected_levelling_cap, probe a specific masking MSR, and set
> + * caps in levelling_caps if it is found, or clobber the MSR index if 
> missing.
> + * If preset, reads the default value into msr_val.
>   */
> -static void set_cpuidmask(const struct cpuinfo_x86 *c)
> +static void __init __probe_mask_msr(unsigned int *msr, uint64_t caps,
> + uint64_t *msr_val)
>  {
> - static unsigned int msr_basic, msr_ext, msr_xsave;
> - static enum { not_parsed, no_mask, set_mask } status;
> - u64 msr_val;
> + uint64_t val;
>  
> - if (status == no_mask)
> - return;
> + expected_levelling_cap |= caps;
>  
> - if (status == set_mask)
> - goto setmask;
> + if (rdmsr_safe(*msr, val) || wrmsr_safe(*msr, val))
> + *msr = 0;
> + else
> + {
> + levelling_caps |= caps;
> + *msr_val = val;
> + }
> +}

Same as for the AMD side: Perhaps neater if the function returned
the MSR value? (Also again partial Xen coding style here.)

> +/* Indicies of the masking MSRs, or 0 if unavailable. */
> +static unsigned int __read_mostly msr_basic, msr_ext, msr_xsave;

I think this way __read_mostly applies only to msr_basic, which I
don't think is what you want. Also I think you mean "indices" or
"indexes".

> +static void __init probe_masking_msrs(void)
> +{
> + const struct cpuinfo_x86 *c = _cpu_data;
> + unsigned int exp_msr_basic = 0, exp_msr_ext = 0, exp_msr_xsave = 0;
>  
>   /* Only family 6 supports this feature. */
> - if (c->x86 != 6) {
> - printk("No CPUID feature masking support available\n");
> + if (c->x86 != 6)
>   return;
> - }
>  
>   switch (c->x86_model) {
>   case 0x17: /* Yorkfield, Wolfdale, Penryn, Harpertown(DP) */
>   case 0x1d: /* Dunnington(MP) */
> - msr_basic = MSR_INTEL_MASK_V1_CPUID1;
> + exp_msr_basic = msr_basic = MSR_INTEL_MASK_V1_CPUID1;
>   break;
>  
>   case 0x1a: /* Bloomfield, Nehalem-EP(Gainestown) */
> @@ -88,71 +100,126 @@ static void set_cpuidmask(const struct cpuinfo_x86 *c)
>   case 0x2c: /* Gulftown, Westmere-EP */
>   case 0x2e: /* Nehalem-EX(Beckton) */
>   case 0x2f: /* Westmere-EX */
> - msr_basic = MSR_INTEL_MASK_V2_CPUID1;
> - msr_ext   = MSR_INTEL_MASK_V2_CPUID8001;
> + exp_msr_basic = msr_basic = MSR_INTEL_MASK_V2_CPUID1;
> + exp_msr_ext   = msr_ext   = MSR_INTEL_MASK_V2_CPUID8001;
>   break;
>  
>   case 0x2a: /* SandyBridge */
>   case 0x2d: /* SandyBridge-E, SandyBridge-EN, SandyBridge-EP */
> - msr_basic = MSR_INTEL_MASK_V3_CPUID1;
> - msr_ext   = MSR_INTEL_MASK_V3_CPUID8001;
> - msr_xsave = MSR_INTEL_MASK_V3_CPUIDD_01;
> + exp_msr_basic = msr_basic = MSR_INTEL_MASK_V3_CPUID1;
> + exp_msr_ext   = msr_ext   = MSR_INTEL_MASK_V3_CPUID8001;
> + exp_msr_xsave = msr_xsave = MSR_INTEL_MASK_V3_CPUIDD_01;
>   break;
>   }

Instead of all these changes, and instead of the variable needing
initializers, you could simply initialize all three ext_msr_* right after
the switch().

> +static void intel_ctxt_switch_levelling(const struct domain *nextd)
> +{
> + struct cpuidmasks *these_masks = _cpu(cpuidmasks);
> + const struct cpuidmasks *masks = _defaults;
> +
> +#define LAZY(msr, field) \
> + ({  \
> + if (msr && (these_masks->field != masks->field))\
> + {   \
> + wrmsrl(msr, masks->field);  \
> + these_masks->field = masks->field;  \
> + }   \
> + })

Re: [Xen-devel] [PATCH v2 18/30] x86/cpu: Rework AMD masking MSR setup

[Jan Beulich]

>>> On 05.02.16 at 14:42,  wrote:
> @@ -126,126 +133,189 @@ static const struct cpuidmask *__init noinline 
> get_cpuidmask(const char *opt)
>  }
>  
>  /*
> + * Sets caps in expected_levelling_cap, probes for the specified mask MSR, 
> and
> + * set caps in levelling_caps if it is found.  Processors prior to Fam 10h
> + * required a 32-bit password for masking MSRs.  Reads the default value into
> + * msr_val.
> + */
> +static void __init __probe_mask_msr(unsigned int msr, uint64_t caps,

Please reduce the leading underscores to at most one.

> +uint64_t *msr_val)
> +{
> + unsigned int hi, lo;
> +
> +expected_levelling_cap |= caps;

Indentation.

> + if ((rdmsr_amd_safe(msr, , ) == 0) &&
> + (wrmsr_amd_safe(msr, lo, hi) == 0))
> + levelling_caps |= caps;
> +
> + *msr_val = ((uint64_t)hi << 32) | lo;
> +}

Why can't this function, currently returning void, simply return the
value read?

> +/*
> + * Context switch levelling state to the next domain.  A parameter of NULL is
> + * used to context switch to the default host state, and is used by the 
> BSP/AP
> + * startup code.
> + */
> +static void amd_ctxt_switch_levelling(const struct domain *nextd)
> +{
> + struct cpuidmasks *these_masks = _cpu(cpuidmasks);
> + const struct cpuidmasks *masks = _defaults;

May I suggest naming this "defaults", to aid clarity of the code
below?

> +#define LAZY(cap, msr, field)
> \
> + ({  \
> + if (((levelling_caps & cap) == cap) &&  \
> + (these_masks->field != masks->field))   \

Perhaps worth swapping the operands of the && and wrapping
the then left side of it in unlikely(), to hopefully make the most
desirable route through this function a branch-less one?

> +static void __init noinline amd_init_levelling(void)
>  {
> - static unsigned int feat_ecx, feat_edx;
> - static unsigned int extfeat_ecx, extfeat_edx;
> - static unsigned int l7s0_eax, l7s0_ebx;
> - static unsigned int thermal_ecx;
> - static bool_t skip_feat, skip_extfeat;
> - static bool_t skip_l7s0_eax_ebx, skip_thermal_ecx;
> - static enum { not_parsed, no_mask, set_mask } status;
> - unsigned int eax, ebx, ecx, edx;
> -
> - if (status == no_mask)
> - return;
> + const struct cpuidmask *m = NULL;
>  
> - if (status == set_mask)
> - goto setmask;
> + probe_masking_msrs();
>  
> - ASSERT((status == not_parsed) && (c == _cpu_data));
> - status = no_mask;
> + if (*opt_famrev != '\0') {
> + m = get_cpuidmask(opt_famrev);
>  
> - /* Fam11 doesn't support masking at all. */
> - if (c->x86 == 0x11)
> - return;
> + if (!m)
> + printk("Invalid processor string: %s\n", opt_famrev);
> + }
>  
> - if (~(opt_cpuid_mask_ecx & opt_cpuid_mask_edx &
> -   opt_cpuid_mask_ext_ecx & opt_cpuid_mask_ext_edx &
> -   opt_cpuid_mask_l7s0_eax & opt_cpuid_mask_l7s0_ebx &
> -   opt_cpuid_mask_thermal_ecx)) {
> - feat_ecx = opt_cpuid_mask_ecx;
> - feat_edx = opt_cpuid_mask_edx;
> - extfeat_ecx = opt_cpuid_mask_ext_ecx;
> - extfeat_edx = opt_cpuid_mask_ext_edx;
> - l7s0_eax = opt_cpuid_mask_l7s0_eax;
> - l7s0_ebx = opt_cpuid_mask_l7s0_ebx;
> - thermal_ecx = opt_cpuid_mask_thermal_ecx;
> - } else if (*opt_famrev == '\0') {
> - return;
> - } else {
> - const struct cpuidmask *m = get_cpuidmask(opt_famrev);
> + if ((levelling_caps & LCAP_1cd) == LCAP_1cd) {
> + uint32_t ecx, edx, tmp;
>  
> - if (!m) {
> - printk("Invalid processor string: %s\n", opt_famrev);
> - printk("CPUID will not be masked\n");
> - return;
> + cpuid(0x0001, , , , );

Didn't you collect raw CPUID output already?

> + if(~(opt_cpuid_mask_ecx & opt_cpuid_mask_edx)) {
> + ecx &= opt_cpuid_mask_ecx;
> + edx &= opt_cpuid_mask_edx;
> + } else if ( m ) {

Partial Xen coding style slipped in here.

Jan


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

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

[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 
Acked-by: Stefano Stabellini 
Acked-by: Razvan Cojocaru 

---
Changed since v4:
  * arch_monitor_domctl_event @ x86/monitor.c:
replaced !old_status w/ requested_status (equivalent but more readable)
---
 MAINTAINERS   |   1 +
 xen/arch/x86/monitor.c| 153 +++---
 xen/common/Makefile   |   1 +
 xen/common/domctl.c   |   2 +-
 xen/common/monitor.c  |  69 +++
 xen/include/asm-arm/monitor.h |  30 +++--
 xen/include/asm-x86/monitor.h |  53 +--
 xen/include/xen/monitor.h |  30 +
 8 files changed, 217 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..a507edb 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 =
 

[Xen-devel] [PATCH v5 1/2] xen/arm: fix file comments

[Corneliu ZUZU]

Add file header comment and local variable block @ EOF
of xen/arch/arm/hvm.c.

Signed-off-by: Corneliu ZUZU 
Acked-by: Stefano Stabellini 

---
Changed since v4: 
---
 xen/arch/arm/hvm.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index 5fd0753..056db1a 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -1,3 +1,21 @@
+/*
+ * arch/arm/hvm.c
+ *
+ * Arch-specific hardware virtual machine abstractions.
+ *
+ * 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 
 #include 
@@ -14,7 +32,6 @@
 #include 
 
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
-
 {
 long rc = 0;
 
@@ -65,3 +82,13 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 return rc;
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.5.0


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

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

[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. Fix file comment
Acked-by: Stefano Stabellini 
2. Move monitor_domctl to common-side.
Acked-by: Stefano Stabellini 
Acked-by: Razvan Cojocaru 

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

---
Changed since v4:
  1/2: nothing changed
  2/2: arch_monitor_domctl_event:
replaced !old_status w/ requested_status (equivalent but more readable)

Corneliu ZUZU (2):
  xen/arm: fix file comments
  xen/vm-events: Move parts of monitor_domctl code to common-side.

 MAINTAINERS   |   1 +
 xen/arch/arm/hvm.c|  29 +++-
 xen/arch/x86/monitor.c| 153 +++---
 xen/common/Makefile   |   1 +
 xen/common/domctl.c   |   2 +-
 xen/common/monitor.c  |  69 +++
 xen/include/asm-arm/monitor.h |  30 +++--
 xen/include/asm-x86/monitor.h |  53 +--
 xen/include/xen/monitor.h |  30 +
 9 files changed, 245 insertions(+), 123 deletions(-)
 create mode 100644 xen/common/monitor.c
 create mode 100644 xen/include/xen/monitor.h

-- 
2.5.0


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

Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands

[Chun Yan Liu]

n

>>> On 2/17/2016 at 12:56 AM, in message <20160216165608.ga21...@gmail.com>, 
>>> Olaf
Hering  wrote: 
> On Tue, Jan 19, Chunyan Liu wrote: 
>  
> >  #xl usbctrl-attach test_vm version=1 ports=8 
>  
> >  #xl usbdev-attach test_vm hostbus=1 hostaddr=2 
>  
> I think this does not handle the -N knob of xl. Other commands check the 
> global dryrun_only variable. 

Thanks. I'll add.

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



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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 82516
 build-amd64-rumpuserxen   6 xen-buildfail   like 82662
 build-i386-rumpuserxen6 xen-buildfail   like 82662
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 82662
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 82662
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 82662

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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-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-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  3fba5f5ec6bd2c9375735ae09d9615ccb1d7c0d0
baseline version:
 xen  bcfaea685d38c08e5eb90797512ab80f0bc69d0c

Last test of basis82662  2016-02-15 10:57:54 Z1 days
Testing same since82825  2016-02-16 10:58:18 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Corneliu ZUZU 
  Ian Jackson 
  Jan Beulich 
  Razvan Cojocaru 
  Roger Pau Monné 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

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   

Re: [Xen-devel] [PATCH v7 0/9] virtio DMA API, yet again

[Andy Lutomirski]

On Tue, Feb 2, 2016 at 9:46 PM, Andy Lutomirski  wrote:
> This switches virtio to use the DMA API on Xen and if requested by
> module option.

Michael, any update on this?

--Andy

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

[Xen-devel] [PATCH 2/3] docs: fix typo in xl-disk-configuration.txt

[Jim Fehlig]

---
 docs/misc/xl-disk-configuration.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/misc/xl-disk-configuration.txt 
b/docs/misc/xl-disk-configuration.txt
index 6a2118d..29f6ddb 100644
--- a/docs/misc/xl-disk-configuration.txt
+++ b/docs/misc/xl-disk-configuration.txt
@@ -160,7 +160,7 @@ Mandatory: No
 Default value: Automatically determine which backend to use.
 
 This does not affect the guest's view of the device.  It controls
-which software implementation of the Xen backend driver us used.
+which software implementation of the Xen backend driver is used.
 
 Not all backend drivers support all combinations of other options.
 For example, "phy" does not support formats other than "raw".
-- 
1.8.0.1


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

[Xen-devel] [PATCH 0/3] libxl and docs: small improvements in qdisk support

[Jim Fehlig]

This series contains a few improvments related to libxl's
support for the various qdisk types. Patch1 is a small fix
for libxlu_cfg to error when encountering unknown backslash-
escaped characters instead of silently dropping them. Patch2
is actually unrelated and fixes a typo noticed while reviewing
xl-disk-configuration.txt, which is improved a bit in patch3
wrt target= syntax.

Jim Fehlig (3):
  libxlu_cfg: reject unknown characters following '\'
  docs: fix typo in xl-disk-configuration.txt
  docs: add more info about target= in disk config

 docs/misc/xl-disk-configuration.txt | 12 ++--
 tools/libxl/libxlu_cfg.c|  5 +
 2 files changed, 15 insertions(+), 2 deletions(-)

-- 
1.8.0.1


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

[Xen-devel] [PATCH 1/3] libxlu_cfg: reject unknown characters following '\'

[Jim Fehlig]

When dequoting config strings in xlu__cfgl_dequote(), unknown
characters following a '\', and the '\' itself, are discarded.
E.g. a disk configuration string containing

  rbd:pool/image:mon_host=192.168.0.100\:6789

would be dequoted as

  rbd:pool/image:mon_host=192.168.0.1006789

Instead of discarding the '\' and unknown character, reject the
string and set error to EINVAL.
---
 tools/libxl/libxlu_cfg.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 1d70909..f8e0bc7 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -533,6 +533,11 @@ char *xlu__cfgl_dequote(CfgParseContext *ctx, const char 
*src) {
 NUMERIC_CHAR(2,2,16,"hex");
 } else if (nc>='0' && nc<='7') {
 NUMERIC_CHAR(1,3,10,"octal");
+} else {
+xlu__cfgl_lexicalerror(ctx, "invalid character after backlash "
+   "in quoted string");
+ctx->err= EINVAL;
+goto x;
 }
 assert(p <= src+len-1);
 } else {
-- 
1.8.0.1


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

[Xen-devel] [PATCH 3/3] docs: add more info about target= in disk config

[Jim Fehlig]

target= in disk config can be used to convey arbitrary
configuration information to backends. Add a bit more info
to xl-disk-configuration.txt to clarify this, including some
simple nbd and rbd qdisk configurations.
---
 docs/misc/xl-disk-configuration.txt | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xl-disk-configuration.txt 
b/docs/misc/xl-disk-configuration.txt
index 29f6ddb..0918fb8 100644
--- a/docs/misc/xl-disk-configuration.txt
+++ b/docs/misc/xl-disk-configuration.txt
@@ -75,7 +75,15 @@ Special syntax:
the target was already specified as a positional parameter.  This
is the only way to specify a target string containing metacharacters
such as commas and (in some cases) colons, which would otherwise be
-   misinterpreted.
+   misinterpreted. Meta-information in a target string can be used to
+   specify configuration information for a qdisk block backend. For
+   example the nbd and rbd qdisk block backends can be configured with
+
+ target=nbd:192.168.0.1:
+ target=rbd:pool/image:mon_host=192.186.0.1\\:6789
+
+   Note the use of double backslash ('\\') for metacharacters that need
+   escaped.
 
Future parameter and flag names will start with an ascii letter and
contain only ascii alphanumerics, hyphens and underscores, and will
-- 
1.8.0.1


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

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Tian, Kevin]

> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, February 16, 2016 7:11 PM
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 16 February 2016 10:34
> > To: Paul Durrant
> > Cc: Andrew Cooper; George Dunlap; Ian Campbell; Ian Jackson; Stefano
> > Stabellini; Wei Liu; Kevin Tian; Zhiyuan Lv; Zhang Yu; 
> > xen-devel@lists.xen.org;
> > George Dunlap; Keir (Xen.org)
> > Subject: RE: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
> > max_wp_ram_ranges.
> >
> > >>> On 16.02.16 at 09:50,  wrote:
> > >>  -Original Message-
> > >> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > >> Sent: 16 February 2016 07:23
> > >> To: Paul Durrant; George Dunlap
> > >> Cc: Jan Beulich; George Dunlap; Wei Liu; Ian Campbell; Andrew Cooper;
> > >> Zhang Yu; xen-devel@lists.xen.org; Stefano Stabellini; Lv, Zhiyuan; Ian
> > >> Jackson; Keir (Xen.org)
> > >> Subject: RE: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
> > >> max_wp_ram_ranges.
> > >>
> > >> > From: Paul Durrant [mailto:paul.durr...@citrix.com]
> > >> > Sent: Friday, February 05, 2016 7:24 PM
> > >> >
> > >> > > -Original Message-
> > >> > > From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> > >> > > George Dunlap
> > >> > > Sent: 05 February 2016 11:14
> > >> > > To: Paul Durrant
> > >> > > Cc: Jan Beulich; George Dunlap; Kevin Tian; Wei Liu; Ian Campbell;
> > >> Andrew
> > >> > > Cooper; Zhang Yu; xen-devel@lists.xen.org; Stefano Stabellini;
> > >> > > zhiyuan...@intel.com; Ian Jackson; Keir (Xen.org)
> > >> > > Subject: Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
> > >> > > max_wp_ram_ranges.
> > >> > >
> > >> > > On Fri, Feb 5, 2016 at 9:24 AM, Paul Durrant
> > 
> > >> > > wrote:
> > >> > > > Utilizing the default server is a backwards step. GVT-g would have 
> > >> > > > to
> > >> use
> > >> > > the old HVM_PARAM mechanism to cause it's emulator to become
> > >> default. I
> > >> > > think a more appropriate mechanism would be p2m_mmio_write_dm
> > to
> > >> > > become something like 'p2m_ioreq_server_write' and then have a
> > >> hypercall
> > >> > > to allow it to be mapped to a particular ioreq server.
> > >> > > > Obviously only one could claim it but, with a p2t, the bit could 
> > >> > > > be re-
> > >> > > purposed to simply mean 'go look in the p2t' for more information and
> > >> then
> > >> > > the p2t could be structured to allow emulations to be steered to one
> > of
> > >> many
> > >> > > ioreq servers (for read and/or write emulation).
> > >> > >
> > >> > > Right; I had in mind that Xen would allow at any given time a max of 
> > >> > > N
> > >> > > ioreq servers to register for mmio_write_dm ranges, first-come
> > >> > > first-served; with 'N' being '1' to begin with.  If a second ioreq
> > >> > > server requested mmio_write_dm functionality, it would get -EBUSY.
> > >> > > This would allow their current setup (one qemu dm which doesn't do
> > >> > > mmio_write_dm, one xengt dm which does) to work without needing
> > to
> > >> > > worry any more about how many pages might need to be tracked
> > (either
> > >> > > for efficiency or correctness).
> > >> > >
> > >> > > We could then extend this to some larger number (4 seems pretty
> > >> > > reasonable to me) either by adding an extra 3 types, or by some other
> > >> > > method (such as the one Paul suggests).
> > >> >
> > >> > I think it would be best to do away with the 'write dm' name though. I
> > >> would like to see it
> > >> > be possible to steer reads+writes, as well as writes (and maybe just
> > > reads?)
> > >> to a particular
> > >> > ioreq server based on type information. So maybe we just call the
> > existing
> > >> type
> > >> > 'p2m_ioreq_server' and then, in the absence of a p2t, hardcode this to
> > go
> > >> to whichever
> > >> > emulator makes the new TBD hypercall.
> > >> > I think we need a proper design at this point. Given that it's Chinese
> > New
> > >> Year maybe I'll
> > >> > have a stab in Yu's absence.
> > >> >
> > >>
> > >> Hi, Paul, what about your progress on this?
> > >>
> > >> My feeling is that we do not need a new hypercall to explicitly claim
> > >> whether a ioreq server wants to handle write requests. It can be
> > >> implicitly marked upon whether a specific page is requested for
> > >> write-protection through a specific ioreq channel, and then that
> > >> ioreq server will claim the attribute automatically.
> > >
> > > Hi Kevin,
> > >
> > > Is there a hypercall to do that? Maybe I'm missing something but I was
> > under
> > > the impression that the only way to set write protection was via an
> > > HVMOP_set_mem_type and that does not carry an ioreq server id.

Thanks for clarification. I've got a bit messed on current state before. :-)

> > >
> > > I'm afraid I have made little progress due to the distractions of trying 
> > > get
> > > some patches into Linux but my thoughts are 

Re: [Xen-devel] Nested virtualization off VMware vSphere 6.0 with EL6 guests crashes on Xen 4.6

[Tian, Kevin]

> From: Tian, Kevin
> Sent: Thursday, February 04, 2016 1:52 PM
> 
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, February 03, 2016 5:35 PM
> > > (XEN) nvmx_handle_vmwrite: 0
> > > (XEN) nvmx_handle_vmwrite: 2008
> > > (XEN) nvmx_handle_vmwrite: 2008
> > > (XEN) nvmx_handle_vmwrite: 0
> > > (XEN) nvmx_handle_vmwrite: 2008
> > > (XEN) nvmx_handle_vmwrite: 0
> > > (XEN) nvmx_handle_vmwrite: 2008
> > > (XEN) nvmx_handle_vmwrite: 2008
> > > (XEN) nvmx_handle_vmwrite: 2008
> > > (XEN) nvmx_handle_vmwrite: 2008
> > > (XEN) nvmx_handle_vmwrite: 2008
> > > (XEN) nvmx_handle_vmwrite: 800
> > > (XEN) nvmx_handle_vmwrite: 804
> > > (XEN) nvmx_handle_vmwrite: 806
> > > (XEN) nvmx_handle_vmwrite: 80a
> > > (XEN) nvmx_handle_vmwrite: 80e
> > > (XEN) nvmx_update_virtual_apic_address: vCPU1 0x(vAPIC)
> 0x0(APIC),
> > 0x0(TPR) ctrl=b5b9effe sec=0
> >
> > Assuming the field starts out as other than all ones, could you check
> > its value on each of the intercepted VMWRITEs, to at least narrow
> > when it changes.
> >
> > Kevin, Jun - are there any cases where the hardware would alter
> > this field's value? Like during some guest side LAPIC manipulations?
> > (The same monitoring as suggested during VMWRITEs could of
> > course also be added to LAPIC accesses visible to the hypervisor,
> > but I guess there won't be too many of those.)
> >
> 
> No such case in my knowledge. But let me confirm with hardware team.
> 

Confirmed no such case.

Thanks
Kevin

___
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

[Suriyan Ramasami]

On Tue, Feb 16, 2016 at 2:03 AM, Ian Campbell 
wrote:

> On Sun, 2016-02-14 at 22:32 -0800, Suriyan Ramasami wrote:
> >
> >
> > On Thu, Feb 11, 2016 at 1:40 AM, Ian Campbell <
> > ian.campb...@citrix.com> wrote:
> > > On Wed, 2016-02-10 at 17:47 -0800, Suriyan Ramasami wrote:
> > > >
> > > >
> > > > On Wed, Feb 10, 2016 at 2:03 AM, Ian Campbell <
> > > ian.campb...@citrix.com>
> > > > 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 

[Xen-devel] [linux-3.18 test] 82793: regressions - FAIL

[osstest service owner]

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

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. 79037
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 79037

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-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-amd64-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-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-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-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-amd64-amd64-libvirt-vhd 11 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:
 linux2c07053b8e1e0c22bb54dfbdf8e86a70f8bf00fc
baseline version:
 linux707e840c5e24bb2df1ea4e753964275e257ec816

Last test of basis79037  2016-01-25 18:28:55 Z   22 days
Testing same since82793  2016-02-16 05:49:14 Z0 days1 attempts


People who touched revisions under test:
  "J. Bruce Fields" 
  
  Adrian Hunter 
  Al Viro 
  Alan Stern 
  Alex Deucher 
  Alexander Aring 
  Alexandru Cornea 
  Alexei Starovoitov 
  amish 
  Andrew Elble 
  Andrew Gabbasov 
  Andrew Morton 
  Andrey Ryabinin 
  Andy Gospodarek 
  Andy Shevchenko 
  Antonio Ospite 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Aurélien 

Re: [Xen-devel] [PATCH 0/4] xl: consolidate adhoc parsers

[Wei Liu]

On Tue, Feb 16, 2016 at 03:09:37PM -0700, Jim Fehlig wrote:
> Wei Liu wrote:
> > This patch series consolidates adhoc parsers in xl.
> 
> Hi Wei,
> 
> I never tested or reviewed this series after seeing Ian's comments. Did you 
> have
> time to work on a V2? Or did I miss a V2? :-) Let me know if I can help.
>

Sorry, this series fell through the crack -- it was only the work of
one afternoon when I had some free cycles. Now I'm busy with other
stuff and haven't had the time to pick it up again.

One thing I'm not entirely happy with writing this in plain C is that
there is subtle semantics difference from the ones generated by
flex/bison even if they expose similar APIs. For example, the
functions to parse disk spec won't allow you to set same attribute
twice, while the work present in this function allows you to do
that. It's cumbersome to implement the same functionality with open
coding in C IMHO.

To get to the point where I feel happy requires quite a bit of work,
so I put "consolidating xl ad hoc parser" (a super set of this series)
to this year's GSoC this morning. Basically I want to consolidate ad
hoc parser, let them have similar semantics if possible, and then
provide a test suite so that it won't be broken by mistake.

That being said, perfection is the enemy of good. If you think this is
important, I will try to find some time to refresh this series; but I
don't have time for the test suite yet. You're welcome to take over
this series if you have time.

Wei.

(Please forgive my errors in grammar etc, it's a bit late at night here...)

> Regards,
> Jim

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

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

[osstest service owner]

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

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-i386-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-credit2  15 guest-start/debian.repeat fail REGR. vs. 59254
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  8 leak-check/basis(8) fail in 82614 pass in 82764
 test-armhf-armhf-xl-xsm  11 guest-startfail in 82614 pass in 82764
 test-armhf-armhf-xl  8 leak-check/basis(8) fail in 82614 pass in 82764
 test-armhf-armhf-xl-multivcpu 8 leak-check/basis(8) fail in 82614 pass in 82764
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
82614 pass in 82764
 test-armhf-armhf-xl-cubietruck  8 leak-check/basis(8)   fail pass in 82614

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-armhf-armhf-xl-cubietruck 12 migrate-support-check fail in 82614 never 
pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail in 82614 
never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-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-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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-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-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-xl-multivcpu 13 saverestore-support-checkfail  never 

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

[osstest service owner]

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

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 fbf2338143952da2c63241e51379504a15aa3ea9
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   70 days
Failing since 65593  2015-12-08 23:44:51 Z   69 days   73 attempts
Testing same since82785  2016-02-16 04:46:54 Z0 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 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  edk2 dev 
  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 
  jiewen yao 
  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 8696 lines long.)

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

Re: [Xen-devel] [PATCH 0/4] xl: consolidate adhoc parsers

[Jim Fehlig]

Wei Liu wrote:
> This patch series consolidates adhoc parsers in xl.

Hi Wei,

I never tested or reviewed this series after seeing Ian's comments. Did you have
time to work on a V2? Or did I miss a V2? :-) Let me know if I can help.

Regards,
Jim

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

Re: [Xen-devel] [PATCH] xl: close nullfd after dup2'ing it to stdin

[Ian Campbell]

On Tue, 2016-02-16 at 17:45 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] xl: close nullfd after dup2'ing it to
> stdin"):
> > Taking care not to do so if nullfd happens (somehow) to have the
> same
> > fd number as stdin/out/err.
> 
> I think that can only happen if the program (the process) has a
> serious problem: ie, fd 0 1 or 2 would have to be closed.

Yes, that was my thought and what I wanted to guard against.

> If that happens many other things can go badly wrong.

Indeed. I've seen this happen in other scenarios with non-C programs
forking and execing stuff with stdio fds closed.

> If this is causing Coverity to complain I would suggest adding
>assert(nullfd >= 3);
>assert(logfile >= 3);
> instead.

Coverity wasn't complaining about this particular aspect, it was only
complaining about the leak of nullfd, avoiding stdin/out/err was just
me being belt and braces about the possibility of nullfd being one of
the stdio fds. I'm happy with the assert approach too.

Ian

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

[Xen-devel] [PATCH 3/4] xenconfig: support xl<->xml conversion of rbd disk devices

[Jim Fehlig]

The target= setting in xl disk configuration can be used to encode
meta info that is meaningful to a backend. Leverage this fact to
support qdisk network disk types such as rbd. E.g. xl disk config
containing

  disk = [ "format=raw,vdev=hdb,access=rw,backendtype=qdisk,
target=rbd:pool/image:auth_supported=none:\
mon_host=mon1.example.org\:6321\;mon2.example.org\:6322\;\
mon3.example.org\:6322" ]

can be converted to the following XML (and vice versa)

   
 
 
   
   
   
 
 
 
   

Note that conversion of  config is not handled in this patch,
but can be done in a follow-up patch.

Also add a test for the conversions.

Signed-off-by: Jim Fehlig 
---
 src/xenconfig/xen_xl.c   | 145 +--
 tests/xlconfigdata/test-rbd-multihost-noauth.cfg |  26 
 tests/xlconfigdata/test-rbd-multihost-noauth.xml |  51 
 tests/xlconfigtest.c |   1 +
 4 files changed, 216 insertions(+), 7 deletions(-)

diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
index f3e8b55..fadfe71 100644
--- a/src/xenconfig/xen_xl.c
+++ b/src/xenconfig/xen_xl.c
@@ -246,6 +246,24 @@ xenParseXLSpice(virConfPtr conf, virDomainDefPtr def)
 return -1;
 }
 
+
+static int
+xenParseXLDiskSrc(virDomainDiskDefPtr disk, char *srcstr)
+{
+if (STRPREFIX(srcstr, "rbd:")) {
+virDomainDiskSetType(disk, VIR_STORAGE_TYPE_NETWORK);
+disk->src->protocol = VIR_STORAGE_NET_PROTOCOL_RBD;
+return virStorageSourceParseRBDColonString(srcstr + strlen("rbd:"),
+   disk->src);
+} else {
+if (virDomainDiskSetSource(disk, srcstr) < 0)
+return -1;
+}
+
+return 0;
+}
+
+
 /*
  * For details on xl disk config syntax, see
  * docs/misc/xl-disk-configuration.txt in the Xen sources.  The important
@@ -311,12 +329,12 @@ xenParseXLDisk(virConfPtr conf, virDomainDefPtr def)
 if (!(disk = virDomainDiskDefNew(NULL)))
 goto fail;
 
+if (xenParseXLDiskSrc(disk, libxldisk->pdev_path) < 0)
+goto fail;
+
 if (VIR_STRDUP(disk->dst, libxldisk->vdev) < 0)
 goto fail;
 
-if (virDomainDiskSetSource(disk, libxldisk->pdev_path) < 0)
-goto fail;
-
 disk->src->readonly = !libxldisk->readwrite;
 disk->removable = libxldisk->removable;
 
@@ -358,7 +376,8 @@ xenParseXLDisk(virConfPtr conf, virDomainDefPtr def)
 case LIBXL_DISK_BACKEND_UNKNOWN:
 if (virDomainDiskSetDriver(disk, "qemu") < 0)
 goto fail;
-virDomainDiskSetType(disk, VIR_STORAGE_TYPE_FILE);
+if (virDomainDiskGetType(disk) == VIR_STORAGE_TYPE_NONE)
+virDomainDiskSetType(disk, VIR_STORAGE_TYPE_FILE);
 break;
 
 case LIBXL_DISK_BACKEND_TAP:
@@ -578,14 +597,115 @@ xenFormatXLOS(virConfPtr conf, virDomainDefPtr def)
 }
 
 
+static char *
+xenFormatXLDiskSrcNet(virStorageSourcePtr src)
+{
+char *ret = NULL;
+virBuffer buf = VIR_BUFFER_INITIALIZER;
+size_t i;
+
+switch ((virStorageNetProtocol) src->protocol) {
+case VIR_STORAGE_NET_PROTOCOL_NBD:
+case VIR_STORAGE_NET_PROTOCOL_HTTP:
+case VIR_STORAGE_NET_PROTOCOL_HTTPS:
+case VIR_STORAGE_NET_PROTOCOL_FTP:
+case VIR_STORAGE_NET_PROTOCOL_FTPS:
+case VIR_STORAGE_NET_PROTOCOL_TFTP:
+case VIR_STORAGE_NET_PROTOCOL_ISCSI:
+case VIR_STORAGE_NET_PROTOCOL_GLUSTER:
+case VIR_STORAGE_NET_PROTOCOL_SHEEPDOG:
+case VIR_STORAGE_NET_PROTOCOL_LAST:
+case VIR_STORAGE_NET_PROTOCOL_NONE:
+virReportError(VIR_ERR_NO_SUPPORT,
+   _("Unsupported network block protocol '%s'"),
+   virStorageNetProtocolTypeToString(src->protocol));
+goto cleanup;
+
+case VIR_STORAGE_NET_PROTOCOL_RBD:
+if (strchr(src->path, ':')) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+   _("':' not allowed in RBD source volume name '%s'"),
+   src->path);
+goto cleanup;
+}
+
+virBufferStrcat(, "rbd:", src->path, NULL);
+
+virBufferAddLit(, ":auth_supported=none");
+
+if (src->nhosts > 0) {
+virBufferAddLit(, ":mon_host=");
+for (i = 0; i < src->nhosts; i++) {
+if (i)
+virBufferAddLit(, "\\;");
+
+/* assume host containing : is ipv6 */
+if (strchr(src->hosts[i].name, ':'))
+virBufferEscape(, '\\', ":", "[%s]",
+src->hosts[i].name);
+else
+virBufferAsprintf(, "%s", src->hosts[i].name);
+
+if (src->hosts[i].port)
+virBufferAsprintf(, "\\:%s", 

[Xen-devel] [PATCH 1/4] xenconfig: replace text 'xm' with 'xl' in xlconfigtest

[Jim Fehlig]

While at it, improve a few comments. No functional change.

Signed-off-by: Jim Fehlig 
---
 tests/xlconfigtest.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/tests/xlconfigtest.c b/tests/xlconfigtest.c
index 4b2f28f..aa53ed8 100644
--- a/tests/xlconfigtest.c
+++ b/tests/xlconfigtest.c
@@ -1,5 +1,5 @@
 /*
- * xlconfigtest.c: Test backend for xl_internal config file handling
+ * xlconfigtest.c: Test xl.cfg(5) <-> domXML config conversions
  *
  * Copyright (C) 2007, 2010-2011, 2014 Red Hat, Inc.
  * Copyright (c) 2015 SUSE LINUX Products GmbH, Nuernberg, Germany.
@@ -42,20 +42,22 @@
 
 static virCapsPtr caps;
 static virDomainXMLOptionPtr xmlopt;
+
 /*
- * parses the xml, creates a domain def and compare with equivalent xm config
+ * Parses domXML to virDomainDef object, which is then converted to xl.cfg(5)
+ * config and compared with expected config.
  */
 static int
-testCompareParseXML(const char *xmcfg, const char *xml)
+testCompareParseXML(const char *xlcfg, const char *xml)
 {
-char *gotxmcfgData = NULL;
+char *gotxlcfgData = NULL;
 virConfPtr conf = NULL;
 virConnectPtr conn = NULL;
 int wrote = 4096;
 int ret = -1;
 virDomainDefPtr def = NULL;
 
-if (VIR_ALLOC_N(gotxmcfgData, wrote) < 0)
+if (VIR_ALLOC_N(gotxlcfgData, wrote) < 0)
 goto fail;
 
 conn = virGetConnect();
@@ -73,17 +75,17 @@ testCompareParseXML(const char *xmcfg, const char *xml)
 if (!(conf = xenFormatXL(def, conn)))
 goto fail;
 
-if (virConfWriteMem(gotxmcfgData, , conf) < 0)
+if (virConfWriteMem(gotxlcfgData, , conf) < 0)
 goto fail;
-gotxmcfgData[wrote] = '\0';
+gotxlcfgData[wrote] = '\0';
 
-if (virtTestCompareToFile(gotxmcfgData, xmcfg) < 0)
+if (virtTestCompareToFile(gotxlcfgData, xlcfg) < 0)
 goto fail;
 
 ret = 0;
 
  fail:
-VIR_FREE(gotxmcfgData);
+VIR_FREE(gotxlcfgData);
 if (conf)
 virConfFree(conf);
 virDomainDefFree(def);
@@ -91,13 +93,15 @@ testCompareParseXML(const char *xmcfg, const char *xml)
 
 return ret;
 }
+
 /*
- * parses the xl config, develops domain def and compares with equivalent xm 
config
+ * Parses xl.cfg(5) config to virDomainDef object, which is then converted to
+ * domXML and compared to expected XML.
  */
 static int
-testCompareFormatXML(const char *xmcfg, const char *xml)
+testCompareFormatXML(const char *xlcfg, const char *xml)
 {
-char *xmcfgData = NULL;
+char *xlcfgData = NULL;
 char *gotxml = NULL;
 virConfPtr conf = NULL;
 int ret = -1;
@@ -107,10 +111,10 @@ testCompareFormatXML(const char *xmcfg, const char *xml)
 conn = virGetConnect();
 if (!conn) goto fail;
 
-if (virtTestLoadFile(xmcfg, ) < 0)
+if (virtTestLoadFile(xlcfg, ) < 0)
 goto fail;
 
-if (!(conf = virConfReadMem(xmcfgData, strlen(xmcfgData), 0)))
+if (!(conf = virConfReadMem(xlcfgData, strlen(xlcfgData), 0)))
 goto fail;
 
 if (!(def = xenParseXL(conf, caps, xmlopt)))
@@ -128,7 +132,7 @@ testCompareFormatXML(const char *xmcfg, const char *xml)
  fail:
 if (conf)
 virConfFree(conf);
-VIR_FREE(xmcfgData);
+VIR_FREE(xlcfgData);
 VIR_FREE(gotxml);
 virDomainDefFree(def);
 virObjectUnref(conn);
-- 
2.6.1


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

[Xen-devel] [PATCH 4/4] libxl: add support for rbd qdisk

[Jim Fehlig]

xl/libxl already supports qemu's network-based block backends
such as nbd and rbd. libvirt has supported configuring such
s for long time too. This patch adds support for rbd
disks in the libxl driver by generating a rbd device URL from
the virDomainDiskDef object. The URL is passed to libxl via the
pdev_path field of libxl_device_disk struct. libxl then passes
the URL to qemu for cosumption by the rbd backend.

Signed-off-by: Jim Fehlig 
---
 src/libxl/libxl_conf.c | 192 -
 1 file changed, 191 insertions(+), 1 deletion(-)

diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 48b77d2..5133299 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -46,6 +46,7 @@
 #include "libxl_conf.h"
 #include "libxl_utils.h"
 #include "virstoragefile.h"
+#include "base64.h"
 
 
 #define VIR_FROM_THIS VIR_FROM_LIBXL
@@ -920,17 +921,206 @@ libxlDomainGetEmulatorType(const virDomainDef *def)
 return ret;
 }
 
+static char *
+libxlGetSecretString(virConnectPtr conn,
+ const char *scheme,
+ bool encoded,
+ virStorageAuthDefPtr authdef,
+ virSecretUsageType secretUsageType)
+{
+size_t secret_size;
+virSecretPtr sec = NULL;
+char *secret = NULL;
+char uuidStr[VIR_UUID_STRING_BUFLEN];
+
+/* look up secret */
+switch (authdef->secretType) {
+case VIR_STORAGE_SECRET_TYPE_UUID:
+sec = virSecretLookupByUUID(conn, authdef->secret.uuid);
+virUUIDFormat(authdef->secret.uuid, uuidStr);
+break;
+case VIR_STORAGE_SECRET_TYPE_USAGE:
+sec = virSecretLookupByUsage(conn, secretUsageType,
+ authdef->secret.usage);
+break;
+}
+
+if (!sec) {
+if (authdef->secretType == VIR_STORAGE_SECRET_TYPE_UUID) {
+virReportError(VIR_ERR_NO_SECRET,
+   _("%s no secret matches uuid '%s'"),
+   scheme, uuidStr);
+} else {
+virReportError(VIR_ERR_NO_SECRET,
+   _("%s no secret matches usage value '%s'"),
+   scheme, authdef->secret.usage);
+}
+goto cleanup;
+}
+
+secret = (char *)conn->secretDriver->secretGetValue(sec, _size, 0,
+
VIR_SECRET_GET_VALUE_INTERNAL_CALL);
+if (!secret) {
+if (authdef->secretType == VIR_STORAGE_SECRET_TYPE_UUID) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("could not get value of the secret for "
+ "username '%s' using uuid '%s'"),
+   authdef->username, uuidStr);
+} else {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("could not get value of the secret for "
+ "username '%s' using usage value '%s'"),
+   authdef->username, authdef->secret.usage);
+}
+goto cleanup;
+}
+
+if (encoded) {
+char *base64 = NULL;
+
+base64_encode_alloc(secret, secret_size, );
+VIR_FREE(secret);
+if (!base64) {
+virReportOOMError();
+goto cleanup;
+}
+secret = base64;
+}
+
+ cleanup:
+virObjectUnref(sec);
+return secret;
+}
+
+static char *
+libxlMakeNetworkDiskSrcStr(virStorageSourcePtr src,
+   const char *username,
+   const char *secret)
+{
+char *ret = NULL;
+virBuffer buf = VIR_BUFFER_INITIALIZER;
+size_t i;
+
+switch ((virStorageNetProtocol) src->protocol) {
+case VIR_STORAGE_NET_PROTOCOL_NBD:
+case VIR_STORAGE_NET_PROTOCOL_HTTP:
+case VIR_STORAGE_NET_PROTOCOL_HTTPS:
+case VIR_STORAGE_NET_PROTOCOL_FTP:
+case VIR_STORAGE_NET_PROTOCOL_FTPS:
+case VIR_STORAGE_NET_PROTOCOL_TFTP:
+case VIR_STORAGE_NET_PROTOCOL_ISCSI:
+case VIR_STORAGE_NET_PROTOCOL_GLUSTER:
+case VIR_STORAGE_NET_PROTOCOL_SHEEPDOG:
+case VIR_STORAGE_NET_PROTOCOL_LAST:
+case VIR_STORAGE_NET_PROTOCOL_NONE:
+virReportError(VIR_ERR_NO_SUPPORT,
+   _("Unsupported network block protocol '%s'"),
+   virStorageNetProtocolTypeToString(src->protocol));
+goto cleanup;
+
+case VIR_STORAGE_NET_PROTOCOL_RBD:
+if (strchr(src->path, ':')) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+   _("':' not allowed in RBD source volume name '%s'"),
+   src->path);
+goto cleanup;
+}
+
+virBufferStrcat(, "rbd:", src->path, NULL);
+
+if (username) {
+virBufferEscape(, '\\', ":", ":id=%s", username);
+virBufferEscape(, '\\', ":",
+":key=%s:auth_supported=cephx\\;none",
+

[Xen-devel] [PATCH 0/4] libxl: support qemu's network-based block backends

[Jim Fehlig]

xl/libxl already supports qemu's network-based block backends
such as nbd and rbd. libvirt has supported configuring network
disks for long time too. This series marries the two in the
libxl driver and in the xl<->xml converter. Only rbd supported
is added in this series. Support for other backends such as nbd
and iscsi can be added as a follow-up improvement.

Patch 1 is super trivial and contains no functional changes.

Patch 2 changes the xl disk configuration produced by the
xml->xl converter to use the formal key=value syntax described
in xl-disk-configuration.txt.

Patch 3 adds support for converting rbd info between xl and xml
config formats.

Patch 4 adds support for rbd disks in the libxl driver.

Jim Fehlig (4):
  xenconfig: replace text 'xm' with 'xl' in xlconfigtest
  xenconfig: produce key=value disk config syntax in xl formatter
  xenconfig: support xl<->xml conversion of rbd disk devices
  libxl: add support for rbd qdisk

 src/libxl/libxl_conf.c | 192 -
 src/xenconfig/xen_xl.c | 168 --
 .../test-disk-positional-parms-full.cfg|  26 +++
 .../test-disk-positional-parms-full.xml|  54 ++
 .../test-disk-positional-parms-partial.cfg |  26 +++
 .../test-disk-positional-parms-partial.xml |  54 ++
 .../test-fullvirt-direct-kernel-boot.cfg   |   2 +-
 tests/xlconfigdata/test-fullvirt-multiusb.cfg  |   2 +-
 tests/xlconfigdata/test-new-disk.cfg   |   2 +-
 tests/xlconfigdata/test-paravirt-cmdline.cfg   |   2 +-
 tests/xlconfigdata/test-paravirt-maxvcpus.cfg  |   2 +-
 tests/xlconfigdata/test-rbd-multihost-noauth.cfg   |  26 +++
 tests/xlconfigdata/test-rbd-multihost-noauth.xml   |  51 ++
 tests/xlconfigdata/test-spice-features.cfg |   2 +-
 tests/xlconfigdata/test-spice.cfg  |   2 +-
 tests/xlconfigdata/test-vif-rate.cfg   |   2 +-
 tests/xlconfigtest.c   |  37 ++--
 17 files changed, 610 insertions(+), 40 deletions(-)
 create mode 100644 tests/xlconfigdata/test-disk-positional-parms-full.cfg
 create mode 100644 tests/xlconfigdata/test-disk-positional-parms-full.xml
 create mode 100644 tests/xlconfigdata/test-disk-positional-parms-partial.cfg
 create mode 100644 tests/xlconfigdata/test-disk-positional-parms-partial.xml
 create mode 100644 tests/xlconfigdata/test-rbd-multihost-noauth.cfg
 create mode 100644 tests/xlconfigdata/test-rbd-multihost-noauth.xml

-- 
2.6.1


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

[Xen-devel] [PATCH 2/4] xenconfig: produce key=value disk config syntax in xl formatter

[Jim Fehlig]

The most formal form of xl disk configuration uses key=value
syntax to define each configuration item, e.g.

format=raw, vdev=xvda, access=rw, backendtype=phy, target=disksrc

Change the xl disk formatter to produce this syntax, which allows
target= to contain meta info needed to setup a network-based
disksrc (e.g. rbd, nbd, iscsi). For details on xl disk config
format, see  $xen-src/docs/misc/xl-disk-configuration.txt

Update the disk config in the tests to use the formal syntax.
But add tests to ensure disks specified with the positional
parameter syntax are correctly converted to  XML.

Signed-off-by: Jim Fehlig 
---
 src/xenconfig/xen_xl.c | 27 ++-
 .../test-disk-positional-parms-full.cfg| 26 +++
 .../test-disk-positional-parms-full.xml| 54 ++
 .../test-disk-positional-parms-partial.cfg | 26 +++
 .../test-disk-positional-parms-partial.xml | 54 ++
 .../test-fullvirt-direct-kernel-boot.cfg   |  2 +-
 tests/xlconfigdata/test-fullvirt-multiusb.cfg  |  2 +-
 tests/xlconfigdata/test-new-disk.cfg   |  2 +-
 tests/xlconfigdata/test-paravirt-cmdline.cfg   |  2 +-
 tests/xlconfigdata/test-paravirt-maxvcpus.cfg  |  2 +-
 tests/xlconfigdata/test-spice-features.cfg |  2 +-
 tests/xlconfigdata/test-spice.cfg  |  2 +-
 tests/xlconfigdata/test-vif-rate.cfg   |  2 +-
 tests/xlconfigtest.c   |  2 +
 14 files changed, 186 insertions(+), 19 deletions(-)

diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
index be194e3..f3e8b55 100644
--- a/src/xenconfig/xen_xl.c
+++ b/src/xenconfig/xen_xl.c
@@ -587,9 +587,8 @@ xenFormatXLDisk(virConfValuePtr list, virDomainDiskDefPtr 
disk)
 int format = virDomainDiskGetFormat(disk);
 const char *driver = virDomainDiskGetDriver(disk);
 
-/* target */
-virBufferAsprintf(, "%s,", src);
 /* format */
+virBufferAddLit(, "format=");
 switch (format) {
 case VIR_STORAGE_FILE_RAW:
 virBufferAddLit(, "raw,");
@@ -609,31 +608,37 @@ xenFormatXLDisk(virConfValuePtr list, virDomainDiskDefPtr 
disk)
 }
 
 /* device */
-virBufferAdd(, disk->dst, -1);
-
-virBufferAddLit(, ",");
+virBufferAsprintf(, "vdev=%s,", disk->dst);
 
+/* access */
+virBufferAddLit(, "access=");
 if (disk->src->readonly)
-virBufferAddLit(, "r,");
+virBufferAddLit(, "ro,");
 else if (disk->src->shared)
 virBufferAddLit(, "!,");
 else
-virBufferAddLit(, "w,");
+virBufferAddLit(, "rw,");
 if (disk->transient) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("transient disks not supported yet"));
 goto cleanup;
 }
 
+/* backendtype */
+virBufferAddLit(, "backendtype=");
 if (STREQ_NULLABLE(driver, "qemu"))
-virBufferAddLit(, "backendtype=qdisk");
+virBufferAddLit(, "qdisk,");
 else if (STREQ_NULLABLE(driver, "tap"))
-virBufferAddLit(, "backendtype=tap");
+virBufferAddLit(, "tap,");
 else if (STREQ_NULLABLE(driver, "phy"))
-virBufferAddLit(, "backendtype=phy");
+virBufferAddLit(, "phy,");
 
+/* devtype */
 if (disk->device == VIR_DOMAIN_DISK_DEVICE_CDROM)
-virBufferAddLit(, ",devtype=cdrom");
+virBufferAddLit(, "devtype=cdrom,");
+
+/* target */
+virBufferAsprintf(, "target=%s", src);
 
 if (virBufferCheckError() < 0)
 goto cleanup;
diff --git a/tests/xlconfigdata/test-disk-positional-parms-full.cfg 
b/tests/xlconfigdata/test-disk-positional-parms-full.cfg
new file mode 100644
index 000..026e451
--- /dev/null
+++ b/tests/xlconfigdata/test-disk-positional-parms-full.cfg
@@ -0,0 +1,26 @@
+name = "XenGuest2"
+uuid = "c7a5fdb2-cdaf-9455-926a-d65c16db1809"
+maxmem = 579
+memory = 394
+vcpus = 1
+pae = 1
+acpi = 1
+apic = 1
+hap = 0
+viridian = 0
+rtc_timeoffset = 0
+localtime = 0
+on_poweroff = "destroy"
+on_reboot = "restart"
+on_crash = "restart"
+device_model = "/usr/lib/xen/bin/qemu-dm"
+sdl = 0
+vnc = 1
+vncunused = 1
+vnclisten = "127.0.0.1"
+vif = [ "mac=00:16:3e:66:92:9c,bridge=xenbr1,script=vif-bridge,model=e1000" ]
+parallel = "none"
+serial = "none"
+builder = "hvm"
+boot = "d"
+disk = [ "/dev/HostVG/XenGuest2,raw,hda,rw,backendtype=phy", 
"/var/lib/libvirt/images/XenGuest2-home,qcow2,hdb,rw", 
"/root/boot.iso,raw,hdc,ro,devtype=cdrom" ]
diff --git a/tests/xlconfigdata/test-disk-positional-parms-full.xml 
b/tests/xlconfigdata/test-disk-positional-parms-full.xml
new file mode 100644
index 000..49f6dbe
--- /dev/null
+++ b/tests/xlconfigdata/test-disk-positional-parms-full.xml
@@ -0,0 +1,54 @@
+
+  XenGuest2
+  c7a5fdb2-cdaf-9455-926a-d65c16db1809
+  592896
+  403456
+  1
+  
+hvm
+/usr/lib/xen/boot/hvmloader
+
+  
+  
+
+
+
+  
+  
+  destroy
+  restart
+  

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

[osstest service owner]

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

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 12 migrate-support-checkfail   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-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-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  d6165440779f3ffda20bedae387a990077f08dcf
baseline version:
 libvirt  98782f88991a390a358cea960b5776f72fc14451

Last test of basis82511  2016-02-14 13:33:09 Z2 days
Failing since 82637  2016-02-15 07:01:16 Z1 days2 attempts
Testing same since82783  2016-02-16 04:22:14 Z0 days1 attempts


People who touched revisions under test:
  Ján Tomko 
  Laine Stump 
  Peter Krempa 

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=d6165440779f3ffda20bedae387a990077f08dcf
+ . ./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 libvirt 
d6165440779f3ffda20bedae387a990077f08dcf
+ 

Re: [Xen-devel] [PATCH v4 1/4] x86/HVM: update the start info structure layout

[Boris Ostrovsky]

On 02/16/2016 12:37 PM, Roger Pau Monne wrote:

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 7b629b1..6ba060f 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -787,25 +787,46 @@ typedef struct start_info start_info_t;
  /*
   * Start of day structure passed to PVH guests in %ebx.
   *
- * NOTE: nothing will be loaded at physical address 0, so
- * a 0 value in any of the address fields should be treated
- * as not present.
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ *  0 ++
+ *| magic  | Contains the magic value HVM_START_MAGIC_VALUE
+ *|| ("xEn3" with the 0x80 bit of the "E" set).
+ *  4 ++
+ *| version| Version of this structure. Current version is 0. New
+ *|| versions are guaranteed to be backwards-compatible.


#define XEN_HVM_START_INFO_VERSION   0

is needed then?



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

Re: [Xen-devel] [PATCH v3 13/23] XENVER_build_id: Provide ld-embedded build-ids (v10)

[Konrad Rzeszutek Wilk]

> >>> +/* Return value is the number of bytes written, or XEN_Exx on error.
> >>> + * Calling with empty parameter returns the size of build_id. */
> >>> +#define XENVER_build_id 10
> >>> +struct xen_build_id {
> >>> +uint32_tlen; /* IN: size of buf[]. */
> >>> +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> >>> +unsigned char   buf[];
> >>> +#elif defined(__GNUC__)
> >>> +unsigned char   buf[1]; /* OUT: Variable length buffer with 
> >>> build_id. */
> >>> +#endif
> >>> +};
> >>> +typedef struct xen_build_id xen_build_id_t;
> >> I am still against trying to perpetuate this broken interface.  Variable
> >> length structures are a pain for everyone to use.  How about introducing
> >> a brand new hypercall with a separate length and data parameters?
> > As in subop to sysctl? I am fine with that (which is what I think was
> > in the first iteration of this patch had). Or it could go under the
> > XSPLICE subops :-)
> >
> > Preferences?
> 
> A completely brand new hypercall.  Then we can deprecate the existing
> xenver, including moving the relevent information such as plain version
> numbers and leaving the irrelevant information (compile date, etc.).

How would you deprecate the xenver when there are existing guests that
depend on this? Say RHEL5, SLES11 or NetBSD? They are not going to move
over and it would be a bit of silly to deprecate something and actually
never deprecate it because of users still depending on it.

Let me stress out that I have no problems adding a new hypercall (albeit
I think it is an overkill), and adding BUILD_ID in it. However I wouldn't
have the time for Xen 4.7 to add the rest of the sub-ops in it - such as
version, command line, what not.

Keep in mind we have one month left..

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

Re: [Xen-devel] [PATCH v3 13/23] XENVER_build_id: Provide ld-embedded build-ids (v10)

[Andrew Cooper]

On 16/02/16 20:22, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 16, 2016 at 08:09:13PM +, Andrew Cooper wrote:
>> On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
>>
>> Building the hypervisor with buildid and making it available via
>> hypercall really should be split into two different patches, especially
>> given the complexity in each.
> OK, will do.
>
>
> .. snip..
>
>>> +/* Return value is the number of bytes written, or XEN_Exx on error.
>>> + * Calling with empty parameter returns the size of build_id. */
>>> +#define XENVER_build_id 10
>>> +struct xen_build_id {
>>> +uint32_tlen; /* IN: size of buf[]. */
>>> +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>>> +unsigned char   buf[];
>>> +#elif defined(__GNUC__)
>>> +unsigned char   buf[1]; /* OUT: Variable length buffer with 
>>> build_id. */
>>> +#endif
>>> +};
>>> +typedef struct xen_build_id xen_build_id_t;
>> I am still against trying to perpetuate this broken interface.  Variable
>> length structures are a pain for everyone to use.  How about introducing
>> a brand new hypercall with a separate length and data parameters?
> As in subop to sysctl? I am fine with that (which is what I think was
> in the first iteration of this patch had). Or it could go under the
> XSPLICE subops :-)
>
> Preferences?

A completely brand new hypercall.  Then we can deprecate the existing
xenver, including moving the relevent information such as plain version
numbers and leaving the irrelevant information (compile date, etc.).

~Andrew

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

Re: [Xen-devel] [PATCH v3 13/23] XENVER_build_id: Provide ld-embedded build-ids (v10)

[Konrad Rzeszutek Wilk]

On Tue, Feb 16, 2016 at 08:09:13PM +, Andrew Cooper wrote:
> On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
> 
> Building the hypervisor with buildid and making it available via
> hypercall really should be split into two different patches, especially
> given the complexity in each.

OK, will do.


.. snip..

> > +/* Return value is the number of bytes written, or XEN_Exx on error.
> > + * Calling with empty parameter returns the size of build_id. */
> > +#define XENVER_build_id 10
> > +struct xen_build_id {
> > +uint32_tlen; /* IN: size of buf[]. */
> > +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> > +unsigned char   buf[];
> > +#elif defined(__GNUC__)
> > +unsigned char   buf[1]; /* OUT: Variable length buffer with 
> > build_id. */
> > +#endif
> > +};
> > +typedef struct xen_build_id xen_build_id_t;
> 
> I am still against trying to perpetuate this broken interface.  Variable
> length structures are a pain for everyone to use.  How about introducing
> a brand new hypercall with a separate length and data parameters?

As in subop to sysctl? I am fine with that (which is what I think was
in the first iteration of this patch had). Or it could go under the
XSPLICE subops :-)

Preferences?
> 
> ~Andrew

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

Re: [Xen-devel] [PATCH v3 17/23] xsplice: Print dependency and payloads build_id in the keyhandler.

[Andrew Cooper]

On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  xen/common/xsplice.c | 36 
>  1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> index 2ba5bb5..8c5557e 100644
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -101,6 +101,21 @@ static const char *state2str(int32_t state)
>  return names[state];
>  }
>  
> +static void xsplice_print_build_id(char *id, unsigned int len)
> +{
> +unsigned int i;
> +
> +if ( !len )
> +return;
> +
> +for ( i = 0; i < len; i++ )
> +{
> +uint8_t c = id[i];
> +printk("%02x", c);

What about the already existing %*ph custom format?  If the spaces are a
problem we could introduce %*phN from Linux which has no spaces.

The advantage of this is that it is a single call to printk, rather than
many, and avoids the ability for a different cpu to interleave in the
middle of a line.

~Andrew

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

Re: [Xen-devel] [PATCH v3 15/23] xsplice: Print build_id in keyhandler.

[Andrew Cooper]

On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
> As it should be an useful debug mechanism.
>
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  xen/common/xsplice.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> index 65b1f11..34719fc 100644
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -99,7 +100,22 @@ static const char *state2str(int32_t state)
>  static void xsplice_printall(unsigned char key)
>  {
>  struct payload *data;
> -unsigned int i;
> +char *binary_id = NULL;
> +unsigned int len = 0, i;
> +int rc;
> +
> +rc = xen_build_id(_id, );
> +printk("build-id: ");

This line should only be printed if a buildid is included.  Otherwise,
you will repeatedly see -ENODATA if the linker was lacking.

> +if ( !rc )
> +{
> +for ( i = 0; i < len; i++ )
> +{
> +   uint8_t c = binary_id[i];
> +   printk("%02x", c);

Indentation.

Also, the buildid will want printing in the start of day banner.

~Andrew

> +}
> +   printk("\n");
> +} else if ( rc < 0 )
> +printk("rc = %d\n", rc);
>  
>  spin_lock(_lock);
>  


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

Re: [Xen-devel] [PATCH v3 13/23] XENVER_build_id: Provide ld-embedded build-ids (v10)

[Andrew Cooper]

On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:

Building the hypervisor with buildid and making it available via
hypercall really should be split into two different patches, especially
given the complexity in each.

> The mechanism to get this is via the XENVER hypercall and
> we add a new sub-command to retrieve the binary build-id
> called XENVER_build_id. The sub-hypercall parameter
> allows an arbitrary size (the buffer and len is provided
> to the hypervisor). A NULL parameter will probe the hypervisor
> for the length of the build-id.
>
> One can also retrieve the value of the build-id by doing
> 'readelf -n xen-syms'.
>
> For EFI builds we re-use the same build-id that the xen-syms
> was built with.
>
> The version of ld that first implemented --build-id is v2.18.
> Hence we check for that or later version - if older version
> found we do not build the hypervisor with the build-id
> (and the return code is -ENODATA for that case).
>
> For x86 we have two binaries - the xen-syms and the xen - an
> smaller version with lots of sections removed. To make it possible
> for readelf -n xen we also modify mkelf32 and xen.lds.S to include
> the PT_NOTE ELF section.
>
> The EFI binary is more complicated. Having any non-recognizable
> sections (.note, .data.note, etc) causes the boot to hang.
> Moving the .note in the .data section makes it work. It is also
> worth noting that the PE/COFF does not have any "comment"
> sections to the author.
>
> Suggested-by: Andrew Cooper 
> Signed-off-by: Martin Pohlack 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
> v1: Rebase it on Martin's initial patch
> v2: Move it to XENVER hypercall
> v3: Fix EFI building (Ross's fix)
> v4: Don't use the third argument for length.
> v5: Use new structure for XENVER_build_id with variable buf.
> v6: Include Ross's fix.
> v7: Include detection of bin-utils for build-id support, add
> probing for size, and return -EPERM for XSM denied calls.
> v8: Build xen_build_id under ARM, required adding ELFSIZE in proper file.
> v9: Rebase on top XSM version class.
> v10: Include the build-id .note in the xen ELF binary.
>  s/build_id/build_id_linker/
> For EFI build, moved the --build-id values in .data section
> ---
>  Config.mk|  11 +++
>  tools/flask/policy/policy/modules/xen/xen.te |   4 +-
>  tools/libxc/xc_private.c |   7 ++
>  tools/libxc/xc_private.h |  10 ++
>  xen/arch/arm/Makefile|   2 +-
>  xen/arch/arm/xen.lds.S   |  13 +++
>  xen/arch/x86/Makefile|  31 +-
>  xen/arch/x86/boot/mkelf32.c  | 137 
> +++
>  xen/arch/x86/xen.lds.S   |  23 +
>  xen/common/kernel.c  |  36 +++
>  xen/common/version.c |  48 ++
>  xen/include/public/version.h |  16 +++-
>  xen/include/xen/version.h|   1 +
>  xen/xsm/flask/hooks.c|   3 +
>  xen/xsm/flask/policy/access_vectors  |   2 +
>  15 files changed, 319 insertions(+), 25 deletions(-)
>
> diff --git a/Config.mk b/Config.mk
> index 429e460..61186e2 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -126,6 +126,17 @@ endef
>  check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least 
> gcc-4.1")
>  $(eval $(check-y))
>  
> +ld-ver-build-id = $(shell $(1) --build-id 2>&1 | \
> + grep -q unrecognized && echo n || echo 
> y)
> +
> +# binutils 2.18 implement build-id.
> +ifeq ($(call ld-ver-build-id,$(LD)),n)
> +build_id_linker :=
> +else
> +CFLAGS += -DBUILD_ID
> +build_id_linker := --build-id=sha1
> +endif
> +
>  # as-insn: Check whether assembler supports an instruction.
>  # Usage: cflags-y += $(call as-insn "insn",option-yes,option-no)
>  as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
> b/tools/flask/policy/policy/modules/xen/xen.te
> index 9ad648a..2988954 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.te
> +++ b/tools/flask/policy/policy/modules/xen/xen.te
> @@ -79,7 +79,7 @@ allow dom0_t xen_t:xen2 {
>  # Note that dom0 is part of domain_type so this has duplicates.
>  allow dom0_t xen_t:version {
>  version extraversion compile_info capabilities changeset
> -platform_parameters get_features pagesize guest_handle commandline
> +platform_parameters get_features pagesize guest_handle commandline 
> build_id
>  };
>  
>  allow dom0_t xen_t:mmu memorymap;
> @@ -146,7 +146,7 @@ if (guest_writeconsole) {
>  # pmu_ctrl is for)
>  allow domain_type xen_t:xen2 pmu_use;
>  
> -# For normal guests all except XENVER_commandline
> +# For normal guests all except XENVER_commandline|build_id
>  allow domain_type xen_t:version {
>  version 

Re: [Xen-devel] [PATCH v4 1/4] x86/HVM: update the start info structure layout

[Konrad Rzeszutek Wilk]

On Tue, Feb 16, 2016 at 06:37:46PM +0100, Roger Pau Monne wrote:
> After some discussion around the new boot ABI consensus has been reached
> about the layout and contents of the start info. The following patch updates
> the layout to what has been agreed.

.. It would be good to have an URL to the discussion?
> 
> Also, the new layout is described in binary terms in order to avoid issues
> with alignments when using C structs.

Should the title say more about HVMLite/PVH instead of just 'HVM'?

> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Samuel Thibault 
> Cc: Ian Jackson 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 

You forgot Boris who is working on the Linux side. CC-ing him.

Actually please CC him on _ALL_ PVH related work.

> ---
>  tools/libxc/include/xc_dom.h | 31 +
>  xen/include/public/xen.h | 55 
> ++--
>  2 files changed, 69 insertions(+), 17 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index cac4698..6ebe946 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -216,6 +216,37 @@ struct xc_dom_image {
>  struct xc_hvm_firmware_module smbios_module;
>  };
>  
> +#if defined(__i386__) || defined(__x86_64__)
> +/* C representation of the x86/HVM start info layout.
> + *
> + * The canonical definition of this layout resides in public/xen.h, this
> + * is just a way to represent the layout described there using C types.
> + *
> + * NB: the packed attribute is not really needed, but it helps us enforce
> + * the fact this this is just a representation, and it might indeed
> + * be required in the future if there are alignment changes.
> + */
> +struct hvm_start_info {
> +uint32_t magic; /* Contains the magic value 0x336ec578   
> */
> +/* ("xEn3" with the 0x80 bit of the "E" 
> set).*/
> +uint32_t version;   /* Version of this structure.
> */
> +uint32_t flags; /* SIF_xxx flags.
> */
> +uint32_t cmdline_paddr; /* Physical address of the command line. 
> */
> +uint32_t nr_modules;/* Number of modules passed to the kernel.   
> */
> +uint32_t modlist_paddr; /* Physical address of an array of   
> */
> +/* hvm_modlist_entry.
> */
> +uint32_t rsdp_paddr;/* Physical address of the RSDP ACPI data
> */
> +/* structure.
> */
> +} __attribute__((packed));
> +
> +struct hvm_modlist_entry {
> +uint64_t paddr; /* Physical address of the module.   
> */
> +uint64_t size;  /* Size of the module in bytes.  
> */
> +uint64_t cmdline_paddr; /* Physical address of the command line. 
> */
> +uint64_t reserved;
> +} __attribute__((packed));
> +#endif /* x86 */
> +
>  /* --- pluggable kernel loader - */
>  
>  struct xc_dom_loader {
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 7b629b1..6ba060f 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -787,25 +787,46 @@ typedef struct start_info start_info_t;
>  /*
>   * Start of day structure passed to PVH guests in %ebx.
>   *
> - * NOTE: nothing will be loaded at physical address 0, so
> - * a 0 value in any of the address fields should be treated
> - * as not present.
> + * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
> + * of the address fields should be treated as not present.
> + *
> + *  0 ++
> + *| magic  | Contains the magic value HVM_START_MAGIC_VALUE
> + *|| ("xEn3" with the 0x80 bit of the "E" set).
> + *  4 ++
> + *| version| Version of this structure. Current version is 0. New
> + *|| versions are guaranteed to be backwards-compatible.
> + *  8 ++
> + *| flags  | SIF_xxx flags.
> + * 12 ++
> + *| cmdline_paddr  | Physical address of the command line,
> + *|| a zero-terminated ASCII string.
> + * 16 ++
> + *| nr_modules | Number of modules passed to the kernel.
> + * 20 ++
> + *| modlist_paddr  | Physical address of an array of modules
> + *|| (layout of the structure below).
> + * 24 ++
> + *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
> + * 28 ++
> + *
> + * The layout of each entry in the module structure is the following:
> + *
> + *  0 

[Xen-devel] [xen-unstable-smoke test] 82876: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  e33b2921d28c8a3aff2c25fd3d046c7432b3a606
baseline version:
 xen  3fba5f5ec6bd2c9375735ae09d9615ccb1d7c0d0

Last test of basis82717  2016-02-15 18:01:23 Z1 days
Testing same since82876  2016-02-16 18:02:41 Z0 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Samuel Thibault 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=e33b2921d28c8a3aff2c25fd3d046c7432b3a606
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
e33b2921d28c8a3aff2c25fd3d046c7432b3a606
+ branch=xen-unstable-smoke
+ revision=e33b2921d28c8a3aff2c25fd3d046c7432b3a606
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable-coverity
+ '[' xe33b2921d28c8a3aff2c25fd3d046c7432b3a606 = 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 $!;
'

Re: [Xen-devel] [PATCH v3 11/23] xsplice: Add support for alternatives

[Andrew Cooper]

On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> index d863a99..65b1f11 100644
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -695,7 +695,7 @@ static int find_special_sections(struct payload *payload,
>  if ( sec )
>  {
>  if ( ( !sec->sec->sh_size ) ||
> - ( sec->sec->sh_size % sizeof *sec->load_addr ) )
> + ( sec->sec->sh_size % sizeof (struct exception_table_entry) ) )

This hunk looks like it wants to be in the previous patch.

>  return -EINVAL;
>  
>  payload->start_ex_table = (struct exception_table_entry 
> *)sec->load_addr;
> @@ -703,6 +703,14 @@ static int find_special_sections(struct payload *payload,
>  
>  sort_exception_table(payload->start_ex_table, 
> payload->stop_ex_table);
>  }
> +sec = xsplice_elf_sec_by_name(elf, ".altinstructions");
> +if ( sec )
> +{
> +local_irq_disable();
> +apply_alternatives((struct alt_instr *)sec->load_addr,
> +   (struct alt_instr *)(sec->load_addr + 
> sec->sec->sh_size));
> +local_irq_enable();
> +}

None of that code is active, and it can't be made active at this point. 
Interrupts absolutely shouldn't be disabled here.  Instead, the
assertion in apply_alternatives() should be modified as you are adding a
new valid usecase.

Also, modifications like this in a function named
find_special_sections() seem wrong.  It looks like the function would be
better named prepare_payload() or similar.

~Andrew

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

Re: [Xen-devel] [PATCH v3 09/23] xsplice: Add support for bug frames. (v4)

[Andrew Cooper]

On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
> diff --git a/xen/common/symbols.c b/xen/common/symbols.c
> index a59c59d..bf5623f 100644
> --- a/xen/common/symbols.c
> +++ b/xen/common/symbols.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -101,6 +102,12 @@ bool_t is_active_kernel_text(unsigned long addr)
>  (system_state < SYS_STATE_active && is_kernel_inittext(addr)));
>  }
>  
> +bool_t is_active_text(unsigned long addr)
> +{
> +return is_active_kernel_text(addr) ||
> +   is_active_module_text(addr);
> +}

This would be better as a static inline in a header file, to avoid a
call into a separate translation unit.

> +
>  const char *symbols_lookup(unsigned long addr,
> unsigned long *symbolsize,
> unsigned long *offset,
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> index b854c0a..7f71ac6 100644
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -42,7 +42,10 @@ struct payload {
>  struct list_head applied_list;   /* Linked to 'applied_list'. */
>  struct xsplice_patch_func *funcs;/* The array of functions to patch. 
> */
>  unsigned int nfuncs; /* Nr of functions to patch. */
> -
> +size_t core_size;/* Everything else - .data,.rodata, 
> etc. */
> +size_t core_text_size;   /* Only .text size. */

These two lines should be reversed, so the comments make sense.

> +struct bug_frame *start_bug_frames[BUGFRAME_NR]; /* .bug.frame patching. 
> */
> +struct bug_frame *stop_bug_frames[BUGFRAME_NR];
>  char name[XEN_XSPLICE_NAME_SIZE + 1];/* Name of it. */
>  };
>  
> @@ -561,6 +564,7 @@ static int move_payload(struct payload *payload, struct 
> xsplice_elf *elf)
>   (SHF_ALLOC|SHF_EXECINSTR) )
>  calc_section(>sec[i], );
>  }
> +payload->core_text_size = size;
>  
>  /* Compute rw data */
>  for ( i = 0; i < elf->hdr->e_shnum; i++ )
> @@ -579,6 +583,7 @@ static int move_payload(struct payload *payload, struct 
> xsplice_elf *elf)
>   !(elf->sec[i].sec->sh_flags & SHF_WRITE) )
>  calc_section(>sec[i], );
>  }
> +payload->core_size = size;
>  
>  buf = alloc_payload(size);
>  if ( !buf ) {
> @@ -663,6 +668,24 @@ static int find_special_sections(struct payload *payload,
>  if ( f->pad[j] )
>  return -EINVAL;
>  }
> +
> +/* Optional sections. */
> +for ( i = 0; i < BUGFRAME_NR; i++ )
> +{
> +char str[14];
> +
> +snprintf(str, sizeof str, ".bug_frames.%d", i);
> +sec = xsplice_elf_sec_by_name(elf, str);
> +if ( !sec )
> +continue;
> +
> +if ( ( !sec->sec->sh_size ) ||
> + ( sec->sec->sh_size % sizeof (struct bug_frame) ) )
> +return -EINVAL;

Too many spaces.  (not a common style nit!)

> +
> +payload->start_bug_frames[i] = (struct bug_frame *)sec->load_addr;
> +payload->stop_bug_frames[i] = (struct bug_frame *)(sec->load_addr + 
> sec->sec->sh_size);
> +}
>  return 0;
>  }
>  
> @@ -961,6 +984,72 @@ void do_xsplice(void)
>  }
>  }
>  
> +
> +/*
> + * Functions for handling special sections.
> + */
> +struct bug_frame *xsplice_find_bug(const char *eip, int *id)
> +{
> +struct payload *data;
> +struct bug_frame *bug;
> +int i;
> +
> +/* No locking since this list is only ever changed during apply or revert
> + * context. */
> +list_for_each_entry ( data, _list, applied_list )
> +{
> +for (i = 0; i < BUGFRAME_NR; i++) {

braces on new lines.

> +if (!data->start_bug_frames[i])
> +continue;

Newline, and can you borrow some spaces from above.

> +if ( !((void *)eip >= data->payload_address &&
> +   (void *)eip < (data->payload_address + 
> data->core_text_size)))
> +continue;
> +
> +for ( bug = data->start_bug_frames[i]; bug != 
> data->stop_bug_frames[i]; ++bug ) {
> +if ( bug_loc(bug) == eip )
> +{
> +*id = i;
> +return bug;
> +}
> +}
> +}
> +}
> +
> +return NULL;
> +}
> +
> +bool_t is_module(const void *ptr)

I would recommend naming this "is_patch", to avoid the suggestion that
Xen supports modules.

> +{
> +struct payload *data;
> +
> +/* No locking since this list is only ever changed during apply or revert
> + * context. */
> +list_for_each_entry ( data, _list, applied_list )
> +{
> +if ( ptr >= data->payload_address &&
> + ptr < (data->payload_address + data->core_size))
> +return 1;
> +}
> +
> +return 0;
> +}
> +
> +bool_t is_active_module_text(unsigned long addr)
> +{
> +struct payload *data;
> +
> +/* No locking since this list is 

Re: [Xen-devel] [PATCH v4 1/4] x86/HVM: update the start info structure layout

[Andrew Cooper]

On 16/02/16 17:37, Roger Pau Monne wrote:
> After some discussion around the new boot ABI consensus has been reached
> about the layout and contents of the start info. The following patch updates
> the layout to what has been agreed.
>
> Also, the new layout is described in binary terms in order to avoid issues
> with alignments when using C structs.
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3 07/23] xsplice: Implement support for applying/reverting/replacing patches. (v5)

[Andrew Cooper]

On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 9d43f7b..b5995b9 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -121,6 +122,7 @@ static void idle_loop(void)
>  (*pm_idle)();
>  do_tasklet();
>  do_softirq();
> +do_xsplice(); /* Must be last. */

Then name "do_xsplice()" is slightly misleading (although it is in equal
company here).  check_for_xsplice_work() would be more accurate.

> diff --git a/xen/arch/x86/xsplice.c b/xen/arch/x86/xsplice.c
> index 814dd52..ae35e91 100644
> --- a/xen/arch/x86/xsplice.c
> +++ b/xen/arch/x86/xsplice.c
> @@ -10,6 +10,25 @@
>  __func__,__LINE__, x); return x; }
>  #endif
>  
> +#define PATCH_INSN_SIZE 5

Somewhere you should have a BUILD_BUG_ON() confirming that
PATCH_INSN_SIZE fits within the undo array.

Having said that, I think all of xsplice_patch_func should be
arch-specific rather than generic.

> +
> +void xsplice_apply_jmp(struct xsplice_patch_func *func)
> +{
> +uint32_t val;
> +uint8_t *old_ptr;
> +
> +old_ptr = (uint8_t *)func->old_addr;
> +memcpy(func->undo, old_ptr, PATCH_INSN_SIZE);

At least a newline here please.

> +*old_ptr++ = 0xe9; /* Relative jump */
> +val = func->new_addr - func->old_addr - PATCH_INSN_SIZE;

E9 takes a rel32 parameter, which is signed.

I think you need to explicitly cast to intptr_t and used signed
arithmetic throughout this calculation to correctly calculate a
backwards jump.

I think there should also be some sanity checks that both old_addr and
new_addr are in the Xen 1G virtual region.

> +memcpy(old_ptr, , sizeof val);
> +}
> +
> +void xsplice_revert_jmp(struct xsplice_patch_func *func)
> +{
> +memcpy((void *)func->old_addr, func->undo, PATCH_INSN_SIZE);

_p() is common shorthand in Xen for a cast to (void *)

> +}
> +
>  int xsplice_verify_elf(struct xsplice_elf *elf, uint8_t *data)
>  {
>  
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> index fbd6129..b854c0a 100644
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -3,6 +3,7 @@
>   *
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -10,16 +11,25 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  
> +/*
> + * Protects against payload_list operations and also allows only one
> + * caller in schedule_work.
> + */
>  static DEFINE_SPINLOCK(payload_lock);
>  static LIST_HEAD(payload_list);
>  
> +static LIST_HEAD(applied_list);
> +
>  static unsigned int payload_cnt;
>  static unsigned int payload_version = 1;
>  
> @@ -29,6 +39,9 @@ struct payload {
>  struct list_head list;   /* Linked to 'payload_list'. */
>  void *payload_address;   /* Virtual address mapped. */
>  size_t payload_pages;/* Nr of the pages. */
> +struct list_head applied_list;   /* Linked to 'applied_list'. */
> +struct xsplice_patch_func *funcs;/* The array of functions to patch. 
> */
> +unsigned int nfuncs; /* Nr of functions to patch. */
>  
>  char name[XEN_XSPLICE_NAME_SIZE + 1];/* Name of it. */
>  };
> @@ -36,6 +49,24 @@ struct payload {
>  static int load_payload_data(struct payload *payload, uint8_t *raw, ssize_t 
> len);
>  static void free_payload_data(struct payload *payload);
>  
> +/* Defines an outstanding patching action. */
> +struct xsplice_work
> +{
> +atomic_t semaphore;  /* Used for rendezvous. First to grab it 
> will
> +do the patching. */
> +atomic_t irq_semaphore;  /* Used to signal all IRQs disabled. */
> +uint32_t timeout;/* Timeout to do the operation. */
> +struct payload *data;/* The payload on which to act. */
> +volatile bool_t do_work; /* Signals work to do. */
> +volatile bool_t ready;   /* Signals all CPUs synchronized. */
> +uint32_t cmd;/* Action request: XSPLICE_ACTION_* */
> +};
> +
> +/* There can be only one outstanding patching action. */
> +static struct xsplice_work xsplice_work;

This is a scalability issue, specifically that every cpu on the
return-to-guest path polls the bytes making up do_work.  See below for
my suggestion to fix this.

> +
> +static int schedule_work(struct payload *data, uint32_t cmd, uint32_t 
> timeout);
> +
>  static const char *state2str(int32_t state)
>  {
>  #define STATE(x) [XSPLICE_STATE_##x] = #x
> @@ -61,14 +92,23 @@ static const char *state2str(int32_t state)
>  static void xsplice_printall(unsigned char key)
>  {
>  struct payload *data;
> +unsigned int i;
>  
>  spin_lock(_lock);
>  
>  list_for_each_entry ( data, _list, list )
> -printk(" name=%s 

Re: [Xen-devel] [PATCH v2 06/16] xen: sched: tracing: enable TSC tracing for all events

[Meng Xu]

Hi Dario,

Since this patch did some obvious change, I will reply with
reviewed-by, although my reviewed-by does not count much. ;-)

On Tue, Feb 16, 2016 at 1:11 PM, Dario Faggioli
 wrote:
>
> it is enabled for pretty much all of them already.
> There were just a few that had it disabled.
>
> When tracing a scheduler, timing information is
> really important, so enable it everywhere scheduling
> related.
>
> Note that this was not really a problem if looking
> at the traces with xenalyze, but it was if using
> xentrace_format.

I just have a quick (and perhaps naive) question: :-)
If xenanlyze works better than xentrace_format, why shouldn't we stick
to xenanlyze?
Is there some functionality xentrace_format can but xenalyze cannot?

(I have to confess that I only used xenalyze but didn't use
xentrace_format before. :-()

>
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Meng Xu 
> Cc: Tianyang Chen 
> Cc: Olaf Hering 
> ---
>  xen/common/sched_credit.c  |2 +-
>  xen/common/sched_credit2.c |6 +++---
>  xen/common/sched_rt.c  |2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index 5279b92..bd2f37f 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -476,7 +476,7 @@ static inline void __runq_tickle(struct csched_vcpu *new)
>  {
>  /* Avoid TRACE_*: saves checking !tb_init_done each step */
>  for_each_cpu(cpu, )
> -__trace_var(TRC_CSCHED_TICKLE, 0, sizeof(cpu), );
> +__trace_var(TRC_CSCHED_TICKLE, 1, sizeof(cpu), );
>  }
>
>  /* Send scheduler interrupts to designated CPUs */
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index cf40f68..2934e26 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -456,7 +456,7 @@ runq_insert(const struct scheduler *ops, unsigned int 
> cpu, struct csched2_vcpu *
>  d.dom = svc->vcpu->domain->domain_id;
>  d.vcpu = svc->vcpu->vcpu_id;
>  d.pos = pos;
> -trace_var(TRC_CSCHED2_RUNQ_POS, 0,
> +trace_var(TRC_CSCHED2_RUNQ_POS, 1,
>sizeof(d),
>(unsigned char *));
>  }
> @@ -564,7 +564,7 @@ tickle:
>  unsigned cpu:16, pad:16;
>  } d;
>  d.cpu = ipid; d.pad = 0;
> -trace_var(TRC_CSCHED2_TICKLE, 0,
> +trace_var(TRC_CSCHED2_TICKLE, 1,
>sizeof(d),
>(unsigned char *));
>  }
> @@ -1721,7 +1721,7 @@ csched2_schedule(
>   */
>  if ( tasklet_work_scheduled )
>  {
> -trace_var(TRC_CSCHED2_SCHED_TASKLET, 0, 0,  NULL);
> +trace_var(TRC_CSCHED2_SCHED_TASKLET, 1, 0,  NULL);
>  snext = CSCHED2_VCPU(idle_vcpu[cpu]);
>  }
>  else
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 53de6d6..33ac9de 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -985,7 +985,7 @@ out:
>  } d;
>  d.cpu = cpu_to_tickle;
>  d.pad = 0;
> -trace_var(TRC_RTDS_TICKLE, 0,
> +trace_var(TRC_RTDS_TICKLE, 1,
>sizeof(d),
>(unsigned char *));
>  }
>

Reviewed-by: Meng Xu 

Best,

Meng


---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

[Xen-devel] [PATCH v2 04/16] xen: credit2: pack trace data better for xentrace_format

[Dario Faggioli]

when tracing runstate changes, the vcpu and domain IDs
are encoded in the lower and higher, respectively, parts
of a 32 bits integer. When decoding a trace with
xentrace_format, this makes it possible to display
such events like this:

CPU0  833435853624 (+ 768)  running_to_runnable [ dom:vcpu = 0x7fff ]
CPU0  833435854416 (+ 792)  runnable_to_running [ dom:vcpu = 0x0007 ]

For consistency, we should do the same when displaying
the events coming from the Credit2 scheduler (when using
the same tool), and to do that, we need to invert the
order in which the fields are being put in the trace
struct right now.

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
Cc: Olaf Hering 
---
 xen/common/sched_credit2.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 78220a7..cf40f68 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -382,7 +382,7 @@ __update_svc_load(const struct scheduler *ops,
 
 {
 struct {
-unsigned dom:16,vcpu:16;
+unsigned vcpu:16, dom:16;
 unsigned v_avgload:32;
 } d;
 d.dom = svc->vcpu->domain->domain_id;
@@ -450,7 +450,7 @@ runq_insert(const struct scheduler *ops, unsigned int cpu, 
struct csched2_vcpu *
 
 {
 struct {
-unsigned dom:16,vcpu:16;
+unsigned vcpu:16, dom:16;
 unsigned pos;
 } d;
 d.dom = svc->vcpu->domain->domain_id;
@@ -536,7 +536,7 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, 
struct csched2_vcpu *
 
 /* TRACE */ {
 struct {
-unsigned dom:16,vcpu:16;
+unsigned vcpu:16, dom:16;
 unsigned credit;
 } d;
 d.dom = cur->vcpu->domain->domain_id;
@@ -561,9 +561,9 @@ tickle:
 
 /* TRACE */ {
 struct {
-unsigned cpu:8;
+unsigned cpu:16, pad:16;
 } d;
-d.cpu = ipid;
+d.cpu = ipid; d.pad = 0;
 trace_var(TRC_CSCHED2_TICKLE, 0,
   sizeof(d),
   (unsigned char *));
@@ -634,7 +634,7 @@ static void reset_credit(const struct scheduler *ops, int 
cpu, s_time_t now,
 
 /* TRACE */ {
 struct {
-unsigned dom:16,vcpu:16;
+unsigned vcpu:16, dom:16;
 unsigned credit_start, credit_end;
 unsigned multiplier;
 } d;
@@ -683,7 +683,7 @@ void burn_credits(struct csched2_runqueue_data *rqd, struct 
csched2_vcpu *svc, s
 /* TRACE */
 {
 struct {
-unsigned dom:16,vcpu:16;
+unsigned vcpu:16, dom:16;
 unsigned credit;
 int delta;
 } d;
@@ -812,7 +812,7 @@ __runq_assign(struct csched2_vcpu *svc, struct 
csched2_runqueue_data *rqd)
 /* TRACE */
 {
 struct {
-unsigned dom:16,vcpu:16;
+unsigned vcpu:16, dom:16;
 unsigned rqi:16;
 } d;
 d.dom = svc->vcpu->domain->domain_id;


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

[Xen-devel] [PATCH v2 02/16] xen: sched: move up the trace record for vcpu_wake and vcpu_sleep

[Dario Faggioli]

vcpu_wake() and vcpu_sleep() are called before the specific
schedulers wakeup and sleep routines (in fact, it is them
that calls those specific routine).

Make the trace reflect that, by moving the records up. In
fact, it is more natural and easy to find the record of
the event (e.g., the wakeup) *before* the records of the
actions that deals with the event itself.

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
---
 xen/common/schedule.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 7306d71..c87922f 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -381,7 +381,11 @@ void sched_destroy_domain(struct domain *d)
 void vcpu_sleep_nosync(struct vcpu *v)
 {
 unsigned long flags;
-spinlock_t *lock = vcpu_schedule_lock_irqsave(v, );
+spinlock_t *lock;
+
+TRACE_2D(TRC_SCHED_SLEEP, v->domain->domain_id, v->vcpu_id);
+
+lock = vcpu_schedule_lock_irqsave(v, );
 
 if ( likely(!vcpu_runnable(v)) )
 {
@@ -392,8 +396,6 @@ void vcpu_sleep_nosync(struct vcpu *v)
 }
 
 vcpu_schedule_unlock_irqrestore(lock, flags, v);
-
-TRACE_2D(TRC_SCHED_SLEEP, v->domain->domain_id, v->vcpu_id);
 }
 
 void vcpu_sleep_sync(struct vcpu *v)
@@ -409,7 +411,11 @@ void vcpu_sleep_sync(struct vcpu *v)
 void vcpu_wake(struct vcpu *v)
 {
 unsigned long flags;
-spinlock_t *lock = vcpu_schedule_lock_irqsave(v, );
+spinlock_t *lock;
+
+TRACE_2D(TRC_SCHED_WAKE, v->domain->domain_id, v->vcpu_id);
+
+lock = vcpu_schedule_lock_irqsave(v, );
 
 if ( likely(vcpu_runnable(v)) )
 {
@@ -424,8 +430,6 @@ void vcpu_wake(struct vcpu *v)
 }
 
 vcpu_schedule_unlock_irqrestore(lock, flags, v);
-
-TRACE_2D(TRC_SCHED_WAKE, v->domain->domain_id, v->vcpu_id);
 }
 
 void vcpu_unblock(struct vcpu *v)


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

[Xen-devel] [PATCH v2 01/16] xen: sched: __runq_tickle takes a useless cpu parameter

[Dario Faggioli]

as it is always acts on v->processor of the vcpu that
we are tickling.

Getting rid of it makes the code easier to understand
and better looking.

While there, remove a spurious blank line.

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
---
Changes from v1:
 * fix wording inside the changelog, as suggested during
   review.
---
 xen/common/sched_credit.c |   10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 671bbee..5279b92 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -360,9 +360,9 @@ boolean_param("tickle_one_idle_cpu", opt_tickle_one_idle);
 
 DEFINE_PER_CPU(unsigned int, last_tickle_cpu);
 
-static inline void
-__runq_tickle(unsigned int cpu, struct csched_vcpu *new)
+static inline void __runq_tickle(struct csched_vcpu *new)
 {
+unsigned int cpu = new->vcpu->processor;
 struct csched_vcpu * const cur = CSCHED_VCPU(curr_on_cpu(cpu));
 struct csched_private *prv = CSCHED_PRIV(per_cpu(scheduler, cpu));
 cpumask_t mask, idle_mask, *online;
@@ -375,7 +375,6 @@ __runq_tickle(unsigned int cpu, struct csched_vcpu *new)
 cpumask_and(_mask, prv->idlers, online);
 idlers_empty = cpumask_empty(_mask);
 
-
 /*
  * If the pcpu is idle, or there are no idlers and the new
  * vcpu is a higher priority than the old vcpu, run it here.
@@ -980,11 +979,10 @@ static void
 csched_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
 {
 struct csched_vcpu * const svc = CSCHED_VCPU(vc);
-const unsigned int cpu = vc->processor;
 
 BUG_ON( is_idle_vcpu(vc) );
 
-if ( unlikely(curr_on_cpu(cpu) == vc) )
+if ( unlikely(curr_on_cpu(vc->processor) == vc) )
 {
 SCHED_STAT_CRANK(vcpu_wake_running);
 return;
@@ -1028,7 +1026,7 @@ csched_vcpu_wake(const struct scheduler *ops, struct vcpu 
*vc)
 
 /* Put the VCPU on the runq and tickle CPUs */
 __runq_insert(svc);
-__runq_tickle(cpu, svc);
+__runq_tickle(svc);
 }
 
 static void


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

[Xen-devel] [PATCH v2 16/16] xenalyze: handle DOM0 operaions events

[Dario Faggioli]

(i.e., domain creation and destruction) so the
trace will show properly decoded info, rather
than just a bunch of hex codes.
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
Cc: Konrad Rzeszutek Wilk 
---
Changes from v1:
 * new patch in the series.
---
 tools/xentrace/xenalyze.c |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index dd21229..267f932 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -8452,6 +8452,30 @@ void hw_process(struct pcpu_info *p)
 }
 
 }
+
+#define TRC_DOM0_SUB_DOMOPS 1
+void dom0_process(struct pcpu_info *p)
+{
+struct record_info *ri = >ri;
+
+switch(ri->evt.sub)
+{
+case TRC_DOM0_SUB_DOMOPS:
+if(opt.dump_all) {
+struct {
+unsigned int domid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s %s domain d%u\n", ri->dump_header,
+   ri->event == TRC_DOM0_DOM_ADD ? "creating" : "destroying",
+   r->domid);
+}
+break;
+default:
+process_generic(>ri);
+}
+}
+
 /*  Base - */
 void dump_generic(FILE * f, struct record_info *ri)
 {
@@ -9288,6 +9312,8 @@ void process_record(struct pcpu_info *p) {
 hw_process(p);
 break;
 case TRC_DOM0OP_MAIN:
+dom0_process(p);
+break;
 default:
 process_generic(ri);
 }


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

[Xen-devel] [PATCH v2 11/16] xentrace: formats: add domain create and destroy events.

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
Cc: Konrad Rzeszutek Wilk 
---
Changes from v2:
 * new patch in the series.
---
 tools/xentrace/formats |3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 60a8e8f..d204351 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -62,6 +62,9 @@
 0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu 
= 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
 0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
 
+0x00041001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_create   [ dom = 
0x%(1)08x ]
+0x00041002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_destroy  [ dom = 
0x%(1)08x ]
+
 0x00081001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMENTRY
 0x00081002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMEXIT  [ exitcode = 
0x%(1)08x, rIP  = 0x%(2)08x ]
 0x00081102  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMEXIT  [ exitcode = 
0x%(1)08x, rIP  = 0x%(3)08x%(2)08x ]


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

[Xen-devel] [PATCH v2 14/16] xenalyze: handle Credit2 scheduler events

[Dario Faggioli]

so the trace will show properly decoded info,
rather than just a bunch of hex codes.

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
Cc: Konrad Rzeszutek Wilk 
---
Changes from v1:
 * '} * r =' turned into '} *r =', as requested
   during review.
---
 tools/xentrace/xenalyze.c |  101 +
 1 file changed, 101 insertions(+)

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 4ab2dba..8f97f3a 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7727,6 +7727,107 @@ void sched_process(struct pcpu_info *p)
ri->dump_header, r->cpu);
 }
 break;
+/* CREDIT 2 (TRC_CSCHED2_xxx) */
+case TRC_SCHED_CLASS_EVT(CSCHED2, 1): /* TICK  */
+case TRC_SCHED_CLASS_EVT(CSCHED2, 4): /* CREDIT_ADD*/
+case TRC_SCHED_CLASS_EVT(CSCHED2, 9): /* UPDATE_LOAD   */
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 2): /* RUNQ_POS  */
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16, pos;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched2:runq_insert d%uv%u, position %u\n",
+   ri->dump_header, r->domid, r->vcpuid, r->pos);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 3): /* CREDIT_BURN   */
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16, credit;
+int delta;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched2:burn_credits d%uv%u, credit = %u, delta = 
%d\n",
+   ri->dump_header, r->domid, r->vcpuid,
+   r->credit, r->delta);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 5): /* TICKLE_CHECK  */
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16;
+unsigned int credit;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched2:tickle_check d%uv%u, credit = %u\n",
+   ri->dump_header, r->domid, r->vcpuid, r->credit);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 6): /* TICKLE*/
+if(opt.dump_all) {
+struct {
+unsigned int cpu:16;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched2:runq_tickle cpu %u\n",
+   ri->dump_header, r->cpu);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 7):  /* CREDIT_RESET */
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16;
+unsigned int credit_start, credit_end;
+unsigned int multiplier;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched2:reset_credits d%uv%u, "
+   "credit_start = %u, credit_end = %u, mult = %u\n",
+   ri->dump_header, r->domid, r->vcpuid,
+   r->credit_start, r->credit_end, r->multiplier);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 8):  /* SCHED_TASKLET*/
+if(opt.dump_all)
+printf(" %s csched2:sched_tasklet\n", ri->dump_header);
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 10): /* RUNQ_ASSIGN  */
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16;
+unsigned int rqi;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched2:runq_assign d%uv%u on rq# %u\n",
+   ri->dump_header, r->domid, r->vcpuid, r->rqi);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 11): /* UPDATE_VCPU_LOAD */
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16;
+unsigned int avgload;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched2:update_vcpu_load d%uv%u, avg_load = %u\n",
+   ri->dump_header, r->domid, r->vcpuid, r->avgload);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED2, 12): /* UPDATE_RUNQ_LOAD */
+if(opt.dump_all) {
+struct {
+unsigned int rq_load:4, rq_avgload:28;
+unsigned int rq_id:4, b_avgload:28;
+} *r = 

[Xen-devel] [PATCH v2 15/16] xenalyze: handle RTDS scheduler events

[Dario Faggioli]

so the trace will show properly decoded info,
rather than just a bunch of hex codes.

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
Cc: Meng Xu 
Cc: Tianyang Chen 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
---
Changes from v1:
 * '} * r =' turned into '} *r =', as requested
   during review.
---
 tools/xentrace/xenalyze.c |   59 +
 1 file changed, 59 insertions(+)

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 8f97f3a..dd21229 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7828,6 +7828,65 @@ void sched_process(struct pcpu_info *p)
r->rq_avgload, r->b_avgload);
 }
 break;
+/* RTDS (TRC_RTDS_xxx) */
+case TRC_SCHED_CLASS_EVT(RTDS, 1): /* TICKLE   */
+if(opt.dump_all) {
+struct {
+unsigned int cpu:16;
+} *r = (typeof(r))ri->d;
+
+printf(" %s rtds:runq_tickle cpu %u\n",
+   ri->dump_header, r->cpu);
+}
+break;
+case TRC_SCHED_CLASS_EVT(RTDS, 2): /* RUNQ_PICK*/
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16;
+unsigned int cur_dl_lo, cur_dl_hi;
+unsigned int cur_bg_lo, cur_bg_hi;
+} *r = (typeof(r))ri->d;
+uint64_t dl = (((uint64_t)r->cur_dl_hi) << 32) + r->cur_dl_lo;
+uint64_t bg = (((uint64_t)r->cur_bg_hi) << 32) + r->cur_bg_lo;
+
+printf(" %s rtds:runq_pick d%uv%u, deadline = %"PRIu64", "
+   "budget = %"PRIu64"\n", ri->dump_header,
+   r->domid, r->vcpuid, dl, bg);
+}
+break;
+case TRC_SCHED_CLASS_EVT(RTDS, 3): /* BUDGET_BURN  */
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16;
+unsigned int cur_bg_lo, cur_bg_hi;
+int delta;
+} *r = (typeof(r))ri->d;
+uint64_t bg = (((uint64_t)r->cur_bg_hi) << 32) + r->cur_bg_lo;
+
+printf(" %s rtds:burn_budget d%uv%u, budget = %"PRIu64", "
+   "delta = %d\n", ri->dump_header, r->domid,
+   r->vcpuid, bg, r->delta);
+}
+break;
+case TRC_SCHED_CLASS_EVT(RTDS, 4): /* BUDGET_REPLENISH */
+if(opt.dump_all) {
+struct {
+unsigned int vcpuid:16, domid:16;
+unsigned int cur_dl_lo, cur_dl_hi;
+unsigned int cur_bg_lo, cur_bg_hi;
+} *r = (typeof(r))ri->d;
+uint64_t dl = (((uint64_t)r->cur_dl_hi) << 32) + r->cur_dl_lo;
+uint64_t bg = (((uint64_t)r->cur_bg_hi) << 32) + r->cur_bg_lo;
+
+printf(" %s rtds:repl_budget d%uv%u, deadline = %"PRIu64", "
+   "budget = %"PRIu64"\n", ri->dump_header,
+   r->domid, r->vcpuid, dl, bg);
+}
+break;
+case TRC_SCHED_CLASS_EVT(RTDS, 5): /* SCHED_TASKLET*/
+if(opt.dump_all)
+printf(" %s rtds:sched_tasklet\n", ri->dump_header);
+break;
 default:
 process_generic(ri);
 }


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

[Xen-devel] [PATCH v2 13/16] xenalyze: handle Credit1 scheduler events

[Dario Faggioli]

so the trace will show properly decoded info,
rather than just a bunch of hex codes.

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
---
Changes from v1:
 * '} * r =' turned into '} *r =', as requested
   during review.
---
 tools/xentrace/xenalyze.c |   57 +
 1 file changed, 57 insertions(+)

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 17021f1..4ab2dba 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7673,6 +7673,63 @@ void sched_process(struct pcpu_info *p)
 default:
 process_generic(>ri);
 }
+} else if(ri->evt.sub == 2) {
+/* TRC_SCHED_CLASS */
+switch(ri->event)
+{
+/* CREDIT (TRC_CSCHED_xxx) */
+case TRC_SCHED_CLASS_EVT(CSCHED, 1): /* SCHED_TASKLET */
+if(opt.dump_all)
+printf(" %s csched:sched_tasklet\n", ri->dump_header);
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED, 2): /* ACCOUNT_START */
+case TRC_SCHED_CLASS_EVT(CSCHED, 3): /* ACCOUNT_STOP  */
+if(opt.dump_all) {
+struct {
+unsigned int domid, vcpuid, actv_cnt;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched:acct_%s d%uv%u, active_vcpus %u\n",
+   ri->dump_header,
+   ri->event == TRC_SCHED_CLASS_EVT(CSCHED, 2) ?
+   "start" : "stop",
+   r->domid, r->vcpuid,
+   r->actv_cnt);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED, 4): /* STOLEN_VCPU   */
+if(opt.dump_all) {
+struct {
+unsigned int peer_cpu, domid, vcpuid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched:stolen_vcpu d%uv%u from cpu %u\n",
+   ri->dump_header, r->domid, r->vcpuid, r->peer_cpu);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED, 5): /* PICKED_CPU*/
+if(opt.dump_all) {
+struct {
+unsigned int domid, vcpuid, cpu;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched:pick_cpu %u for d%uv%u\n",
+   ri->dump_header, r->cpu, r->domid, r->vcpuid);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED, 6): /* TICKLE*/
+if(opt.dump_all) {
+struct {
+unsigned int cpu;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched:runq_tickle, cpu %u\n",
+   ri->dump_header, r->cpu);
+}
+break;
+default:
+process_generic(ri);
+}
 } else {
 UPDATE_VOLUME(p, sched_verbose, ri->size);
 process_generic(>ri);


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

[Xen-devel] [PATCH v2 12/16] xenalyze: handle scheduling events

[Dario Faggioli]

so the trace will show properly decoded info,
rather than just a bunch of hex codes.

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
---
Changes from v1:
 * SCHED_DOM_{ADD,REM} handling slightly changed, to avoid
   confusion with DOM0_DOM_{ADD,REM} (introduced later in
   the series);
 * '} * r =' turned into '} *r =', as requested
   during review.
---
 tools/xentrace/xenalyze.c |  156 -
 1 file changed, 126 insertions(+), 30 deletions(-)

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 6520790..17021f1 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -1519,27 +1519,6 @@ struct pv_data {
 };
 
 /* Sched data */
-
-enum {
-SCHED_DOM_ADD=1,
-SCHED_DOM_REM,
-SCHED_SLEEP,
-SCHED_WAKE,
-SCHED_YIELD,
-SCHED_BLOCK,
-SCHED_SHUTDOWN,
-SCHED_CTL,
-SCHED_ADJDOM,
-SCHED_SWITCH,
-SCHED_S_TIMER_FN,
-SCHED_T_TIMER_FN,
-SCHED_DOM_TIMER_FN,
-SCHED_SWITCH_INFPREV,
-SCHED_SWITCH_INFNEXT,
-SCHED_SHUTDOWN_CODE,
-SCHED_MAX
-};
-
 enum {
 RUNSTATE_RUNNING=0,
 RUNSTATE_RUNNABLE,
@@ -7431,6 +7410,17 @@ no_update:
 return;
 }
 
+void dump_sched_switch(struct record_info *ri)
+{
+struct {
+unsigned int prev_dom, prev_vcpu, next_dom, next_vcpu;
+} *r = (typeof(r))ri->d;
+
+printf(" %s sched_switch prev d%uv%u next d%uv%u\n",
+   ri->dump_header, r->prev_dom, r->prev_vcpu,
+   r->next_dom, r->next_vcpu);
+}
+
 void sched_switch_process(struct pcpu_info *p)
 {
 struct vcpu_data *prev, *next;
@@ -7440,10 +7430,7 @@ void sched_switch_process(struct pcpu_info *p)
 } * r = (typeof(r))ri->d;
 
 if(opt.dump_all)
-printf("%s sched_switch prev d%uv%u next d%uv%u\n",
-   ri->dump_header,
-   r->prev_dom, r->prev_vcpu,
-   r->next_dom, r->next_vcpu);
+dump_sched_switch(ri);
 
 if(r->prev_vcpu > MAX_CPUS)
 {
@@ -7559,6 +7546,14 @@ void sched_summary_domain(struct domain_data *d)
 }
 }
 
+void dump_sched_vcpu_action(struct record_info *ri, const char *action)
+{
+struct {
+unsigned int domid, vcpuid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s %s d%uv%u\n", ri->dump_header, action, r->domid, r->vcpuid);
+}
 
 void sched_process(struct pcpu_info *p)
 {
@@ -7573,13 +7568,114 @@ void sched_process(struct pcpu_info *p)
 default:
 process_generic(>ri);
 }
-} else {
-if(ri->evt.sub == 1)
-sched_runstate_process(p);
-else {
-UPDATE_VOLUME(p, sched_verbose, ri->size);
+return;
+}
+
+if(ri->evt.sub == 1) {
+/* TRC_SCHED_MIN */
+sched_runstate_process(p);
+} else if (ri->evt.sub == 8) {
+/* TRC_SCHED_VERBOSE */
+switch(ri->event)
+{
+case TRC_SCHED_DOM_ADD:
+if(opt.dump_all) {
+struct {
+unsigned int domid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s sched_init_domain d%u\n", ri->dump_header, 
r->domid);
+}
+break;
+case TRC_SCHED_DOM_REM:
+if(opt.dump_all) {
+struct {
+unsigned int domid, vcpuid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s sched_destroy_domain d%u\n", ri->dump_header, 
r->domid);
+}
+break;
+case TRC_SCHED_SLEEP:
+if(opt.dump_all)
+dump_sched_vcpu_action(ri, "vcpu_sleep");
+break;
+case TRC_SCHED_WAKE:
+if(opt.dump_all)
+dump_sched_vcpu_action(ri, "vcpu_wake");
+break;
+case TRC_SCHED_YIELD:
+if(opt.dump_all)
+dump_sched_vcpu_action(ri, "vcpu_yield");
+break;
+case TRC_SCHED_BLOCK:
+if(opt.dump_all)
+dump_sched_vcpu_action(ri, "vcpu_block");
+break;
+case TRC_SCHED_SHUTDOWN:
+case TRC_SCHED_SHUTDOWN_CODE:
+if(opt.dump_all) {
+struct {
+unsigned int domid, vcpuid, reason;
+} *r = (typeof(r))ri->d;
+
+printf(" %s %s d%uv%u, reason = %u\n", ri->dump_header,
+   ri->event == TRC_SCHED_SHUTDOWN ? "sched_shutdown" :
+   "sched_shutdown_code", r->domid, r->vcpuid, r->reason);
+}
+break;
+case TRC_SCHED_ADJDOM:
+if(opt.dump_all) {
+struct {
+unsigned int domid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s 

[Xen-devel] [PATCH v2 10/16] xentrace: formats: add events from RTDS scheduler

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Meng Xu 
Cc: Tianyang Chen 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
---
 tools/xentrace/formats |6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 6911fcb..60a8e8f 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -56,6 +56,12 @@
 0x0002220b  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:updt_vcpu_load [ 
dom:vcpu = 0x%(1)08x, avgload = %(2)d ]
 0x0002220c  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:updt_runq_load [ 
rq_load[4]:rq_avgload[28] = 0x%(1)08x, rq_id[4]:b_avgload[28] = 0x%(2)08x ]
 
+0x00022801  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:tickle[ cpu = 
%(1)d ]
+0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick [ dom:vcpu 
= 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
+0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ dom:vcpu 
= 0x%(1)08x, cur_budget = 0x%(3)08x%(2)08x, delta = %(4)d ]
+0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu 
= 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
+0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
+
 0x00081001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMENTRY
 0x00081002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMEXIT  [ exitcode = 
0x%(1)08x, rIP  = 0x%(2)08x ]
 0x00081102  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMEXIT  [ exitcode = 
0x%(1)08x, rIP  = 0x%(3)08x%(2)08x ]


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

[Xen-devel] [PATCH v2 09/16] xentrace: formats: add events from Credit2 scheduler

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
---
Changes from v1:
 * fix typo in two events (rq_idx/rq_id)., as requested during
   review.
---
 tools/xentrace/formats |   13 +
 1 file changed, 13 insertions(+)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index a5636e9..6911fcb 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -43,6 +43,19 @@
 0x00022005  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:picked_cpu[ 
dom:vcpu = 0x%(1)04x%(2)04x, cpu = %(3)d ]
 0x00022006  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:tickle[ cpu = 
%(1)d ]
 
+0x00022201  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tick
+0x00022202  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_pos   [ 
dom:vcpu = 0x%(1)08x, pos = %(2)d]
+0x00022203  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit burn[ 
dom:vcpu = 0x%(1)08x, credit = %(2)d, delta = %(3)d ]
+0x00022204  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit_add
+0x00022205  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tickle_check   [ 
dom:vcpu = 0x%(1)08x, credit = %(2)d ]
+0x00022206  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tickle [ cpu = 
%(1)d ]
+0x00022207  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit_reset   [ 
dom:vcpu = 0x%(1)08x, cr_start = %(2)d, cr_end = %(3)d, mult = %(4)d ]
+0x00022208  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:sched_tasklet
+0x00022209  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:update_load
+0x0002220a  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_assign[ 
dom:vcpu = 0x%(1)08x, rq_id = %(2)d ]
+0x0002220b  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:updt_vcpu_load [ 
dom:vcpu = 0x%(1)08x, avgload = %(2)d ]
+0x0002220c  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:updt_runq_load [ 
rq_load[4]:rq_avgload[28] = 0x%(1)08x, rq_id[4]:b_avgload[28] = 0x%(2)08x ]
+
 0x00081001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMENTRY
 0x00081002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMEXIT  [ exitcode = 
0x%(1)08x, rIP  = 0x%(2)08x ]
 0x00081102  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMEXIT  [ exitcode = 
0x%(1)08x, rIP  = 0x%(3)08x%(2)08x ]


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

[Xen-devel] [PATCH v2 08/16] xentrace: formats: add events from Credit scheduler

[Dario Faggioli]

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
---
 tools/xentrace/formats |7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 5257cf0..a5636e9 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -36,6 +36,13 @@
 0x0002800f  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infnext[ new_domid 
= 0x%(1)08x, time = %(2)d, r_time = %(3)d ]
 0x00028010  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_shutdown_code [ 
dom:vcpu = 0x%(1)04x%(2)04x, reason = 0x%(3)08x ]
 
+0x00022001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:sched_tasklet
+0x00022002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:account_start [ 
dom:vcpu = 0x%(1)04x%(2)04x, active = %(3)d ]
+0x00022003  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:account_stop  [ 
dom:vcpu = 0x%(1)04x%(2)04x, active = %(3)d ]
+0x00022004  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:stolen_vcpu   [ 
dom:vcpu = 0x%(2)04x%(3)04x, from = %(1)d ]
+0x00022005  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:picked_cpu[ 
dom:vcpu = 0x%(1)04x%(2)04x, cpu = %(3)d ]
+0x00022006  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:tickle[ cpu = 
%(1)d ]
+
 0x00081001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMENTRY
 0x00081002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMEXIT  [ exitcode = 
0x%(1)08x, rIP  = 0x%(2)08x ]
 0x00081102  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMEXIT  [ exitcode = 
0x%(1)08x, rIP  = 0x%(3)08x%(2)08x ]


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

[Xen-devel] [PATCH v2 05/16] xen: RTDS: pack trace data better for xentrace_format

[Dario Faggioli]

when tracing runstate changes, the vcpu and domain IDs
are encoded in the lower and higher, respectively, parts
of a 32 bits integer. When decoding a trace with
xentrace_format, this makes it possible to display
such events like this:

CPU0  833435853624 (+ 768)  running_to_runnable [ dom:vcpu = 0x7fff ]
CPU0  833435854416 (+ 792)  runnable_to_running [ dom:vcpu = 0x0007 ]

For consistency, we should do the same when displaying
the events coming from the RTDS scheduler (when using
the same tool), and to do that, we need to invert the
order in which the fields are being put in the trace
struct right now.

While there, we also:
 - fix the use of TRC_RTDS_SCHED_TASKLET (it should
   only be involved when a tasklet is scheduled, not
   _every_ time rt_schedule() is invoked!);
 - remove a very chatty and useless (nothing has been
   picked!) use of TRC_RTDS_RUNQ_PICK.

In fact, one can already figure out when nothing has been
picked from the runqueue, by looking at when cpu_idle
is invoked --which is the same thing one would do if on
Credit or Credit2.

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
Cc: Meng Xu 
Cc: Tianyang Chen 
Cc: Olaf Hering 
---
Changes from v1:
 * enhanced changelog, as suggested during review.
---
 xen/common/sched_rt.c |   27 ---
 1 file changed, 4 insertions(+), 23 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 2e5430f..53de6d6 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -362,7 +362,7 @@ rt_update_deadline(s_time_t now, struct rt_vcpu *svc)
 /* TRACE */
 {
 struct {
-unsigned dom:16,vcpu:16;
+unsigned vcpu:16, dom:16;
 unsigned cur_deadline_lo, cur_deadline_hi;
 unsigned cur_budget_lo, cur_budget_hi;
 } d;
@@ -711,7 +711,7 @@ burn_budget(const struct scheduler *ops, struct rt_vcpu 
*svc, s_time_t now)
 /* TRACE */
 {
 struct {
-unsigned dom:16, vcpu:16;
+unsigned vcpu:16, dom:16;
 unsigned cur_budget_lo;
 unsigned cur_budget_hi;
 int delta;
@@ -763,7 +763,7 @@ __runq_pick(const struct scheduler *ops, const cpumask_t 
*mask)
 if( svc != NULL )
 {
 struct {
-unsigned dom:16, vcpu:16;
+unsigned vcpu:16, dom:16;
 unsigned cur_deadline_lo, cur_deadline_hi;
 unsigned cur_budget_lo, cur_budget_hi;
 } d;
@@ -777,8 +777,6 @@ __runq_pick(const struct scheduler *ops, const cpumask_t 
*mask)
   sizeof(d),
   (unsigned char *) );
 }
-else
-trace_var(TRC_RTDS_RUNQ_PICK, 1, 0, NULL);
 }
 
 return svc;
@@ -845,6 +843,7 @@ rt_schedule(const struct scheduler *ops, s_time_t now, 
bool_t tasklet_work_sched
 
 if ( tasklet_work_scheduled )
 {
+trace_var(TRC_RTDS_SCHED_TASKLET, 1, 0,  NULL);
 snext = rt_vcpu(idle_vcpu[cpu]);
 }
 else
@@ -885,24 +884,6 @@ rt_schedule(const struct scheduler *ops, s_time_t now, 
bool_t tasklet_work_sched
 ret.time = MIN(snext->budget, MAX_SCHEDULE); /* sched quantum */
 ret.task = snext->vcpu;
 
-/* TRACE */
-{
-struct {
-unsigned dom:16,vcpu:16;
-unsigned cur_deadline_lo, cur_deadline_hi;
-unsigned cur_budget_lo, cur_budget_hi;
-} d;
-d.dom = snext->vcpu->domain->domain_id;
-d.vcpu = snext->vcpu->vcpu_id;
-d.cur_deadline_lo = (unsigned) snext->cur_deadline;
-d.cur_deadline_hi = (unsigned) (snext->cur_deadline >> 32);
-d.cur_budget_lo = (unsigned) snext->cur_budget;
-d.cur_budget_hi = (unsigned) (snext->cur_budget >> 32);
-trace_var(TRC_RTDS_SCHED_TASKLET, 1,
-  sizeof(d),
-  (unsigned char *));
-}
-
 return ret;
 }
 


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

[Xen-devel] [PATCH v2 07/16] xentrace: formats: update format of scheduling events

[Dario Faggioli]

to include the vcpu IDs, in a way that matches
how the "dom:vcpu" couple is displayed in other
events (runstate changes).

Also add the trace for TRC_SCHED_SHUTDOWN_CODE which
was missing and was done via SCHEDOP_shutdown_code hypercall.
(TRC_SCHED_SHUTDOWN trace was present).

Signed-off-by: Dario Faggioli 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Olaf Hering 
---
Changes from v1:
 * enhanced changelog, as suggested during review.
---
 tools/xentrace/formats |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 5d7b72a..5257cf0 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -19,22 +19,22 @@
 0x00021311  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  offline_to_runnable [ dom:vcpu 
= 0x%(1)08x ]
 0x00021321  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  offline_to_blocked  [ dom:vcpu 
= 0x%(1)08x ]
 
-0x00028001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  sched_add_domain  [ domid = 
0x%(1)08x, edomid = 0x%(2)08x ]
-0x00028002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  sched_rem_domain  [ domid = 
0x%(1)08x, edomid = 0x%(2)08x ]
-0x00028003  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_sleep  [ domid = 
0x%(1)08x, edomid = 0x%(2)08x ]
-0x00028004  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_wake   [ domid = 
0x%(1)08x, edomid = 0x%(2)08x ]
-0x00028005  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  do_yield  [ domid = 
0x%(1)08x, edomid = 0x%(2)08x ]
-0x00028006  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  do_block  [ domid = 
0x%(1)08x, edomid = 0x%(2)08x ]
-0x00022006  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  do_block  [ dom:vcpu = 
0x%(1)08x, domid = 0x%(2)08x ]
-0x00028007  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_shutdown  [ 
domid = 0x%(1)08x, edomid = 0x%(2)08x, reason = 0x%(3)08x ]
+0x00028001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  sched_add_domain  [ domid = 
0x%(1)08x ]
+0x00028002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  sched_rem_domain  [ domid = 
0x%(1)08x ]
+0x00028003  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_sleep  [ dom:vcpu = 
0x%(1)04x%(2)04x ]
+0x00028004  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_wake   [ dom:vcpu = 
0x%(1)04x%(2)04x ]
+0x00028005  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  do_yield  [ dom:vcpu = 
0x%(1)04x%(2)04x ]
+0x00028006  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  do_block  [ dom:vcpu = 
0x%(1)04x%(2)04x ]
+0x00028007  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_shutdown  [ 
dom:vcpu = 0x%(1)04x%(2)04x, reason = 0x%(3)08x ]
 0x00028008  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  sched_ctl
 0x00028009  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  sched_adjdom  [ domid = 
0x%(1)08x ]
-0x0002800a  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  __enter_scheduler [ 
prev = 0x%(1)08x : 0x%(2)08x, next = 0x%(3)08x : 
0x%(4)08x ]
+0x0002800a  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  __enter_scheduler [ 
prev = 0x%(1)04x%(2)04x, next = 0x%(3)04x%(4)04x ]
 0x0002800b  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  s_timer_fn
 0x0002800c  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  t_timer_fn
 0x0002800d  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  dom_timer_fn
 0x0002800e  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infprev[ old_domid 
= 0x%(1)08x, runtime = %(2)d ]
 0x0002800f  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infnext[ new_domid 
= 0x%(1)08x, time = %(2)d, r_time = %(3)d ]
+0x00028010  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_shutdown_code [ 
dom:vcpu = 0x%(1)04x%(2)04x, reason = 0x%(3)08x ]
 
 0x00081001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMENTRY
 0x00081002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMEXIT  [ exitcode = 
0x%(1)08x, rIP  = 0x%(2)08x ]


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

[Xen-devel] [PATCH v2 06/16] xen: sched: tracing: enable TSC tracing for all events

[Dario Faggioli]

it is enabled for pretty much all of them already.
There were just a few that had it disabled.

When tracing a scheduler, timing information is
really important, so enable it everywhere scheduling
related.

Note that this was not really a problem if looking
at the traces with xenalyze, but it was if using
xentrace_format.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Meng Xu 
Cc: Tianyang Chen 
Cc: Olaf Hering 
---
 xen/common/sched_credit.c  |2 +-
 xen/common/sched_credit2.c |6 +++---
 xen/common/sched_rt.c  |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 5279b92..bd2f37f 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -476,7 +476,7 @@ static inline void __runq_tickle(struct csched_vcpu *new)
 {
 /* Avoid TRACE_*: saves checking !tb_init_done each step */
 for_each_cpu(cpu, )
-__trace_var(TRC_CSCHED_TICKLE, 0, sizeof(cpu), );
+__trace_var(TRC_CSCHED_TICKLE, 1, sizeof(cpu), );
 }
 
 /* Send scheduler interrupts to designated CPUs */
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index cf40f68..2934e26 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -456,7 +456,7 @@ runq_insert(const struct scheduler *ops, unsigned int cpu, 
struct csched2_vcpu *
 d.dom = svc->vcpu->domain->domain_id;
 d.vcpu = svc->vcpu->vcpu_id;
 d.pos = pos;
-trace_var(TRC_CSCHED2_RUNQ_POS, 0,
+trace_var(TRC_CSCHED2_RUNQ_POS, 1,
   sizeof(d),
   (unsigned char *));
 }
@@ -564,7 +564,7 @@ tickle:
 unsigned cpu:16, pad:16;
 } d;
 d.cpu = ipid; d.pad = 0;
-trace_var(TRC_CSCHED2_TICKLE, 0,
+trace_var(TRC_CSCHED2_TICKLE, 1,
   sizeof(d),
   (unsigned char *));
 }
@@ -1721,7 +1721,7 @@ csched2_schedule(
  */
 if ( tasklet_work_scheduled )
 {
-trace_var(TRC_CSCHED2_SCHED_TASKLET, 0, 0,  NULL);
+trace_var(TRC_CSCHED2_SCHED_TASKLET, 1, 0,  NULL);
 snext = CSCHED2_VCPU(idle_vcpu[cpu]);
 }
 else
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 53de6d6..33ac9de 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -985,7 +985,7 @@ out:
 } d;
 d.cpu = cpu_to_tickle;
 d.pad = 0;
-trace_var(TRC_RTDS_TICKLE, 0,
+trace_var(TRC_RTDS_TICKLE, 1,
   sizeof(d),
   (unsigned char *));
 }


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

[Xen-devel] [PATCH v2 00/16] Scheduling related tracing improvements

[Dario Faggioli]

Hi,

Take 2 of this series. v1 is here:

 http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01016.html

Konrad's feedback taken into acount, which basically meant modifying a little
bit patch 3 ("xen: sched: improve domain creation tracing"), and adding two
simple patches to xentrace formats file, and to xenalyze (patch 11 and 16).

Thanks and Regards,
Dario
---
Dario Faggioli (16):
  xen: sched: __runq_tickle takes a useless cpu parameter
  xen: sched: move up the trace record for vcpu_wake and vcpu_sleep
  xen: sched: improve domain creation tracing
  xen: credit2: pack trace data better for xentrace_format
  xen: RTDS: pack trace data better for xentrace_format
  xen: sched: tracing: enable TSC tracing for all events
  xentrace: formats: update format of scheduling events
  xentrace: formats: add events from Credit scheduler
  xentrace: formats: add events from Credit2 scheduler
  xentrace: formats: add events from RTDS scheduler
  xentrace: formats: add domain create and destroy events.
  xenalyze: handle scheduling events
  xenalyze: handle Credit1 scheduler events
  xenalyze: handle Credit2 scheduler events
  xenalyze: handle RTDS scheduler events
  xenalyze: handle DOM0 operaions events

 tools/xentrace/formats |   47 -
 tools/xentrace/xenalyze.c  |  399 +---
 xen/common/domain.c|5 -
 xen/common/sched_credit.c  |   12 +
 xen/common/sched_credit2.c |   22 +-
 xen/common/sched_rt.c  |   29 +--
 xen/common/schedule.c  |   20 +-
 xen/include/public/trace.h |6 +
 8 files changed, 450 insertions(+), 90 deletions(-)
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

[Xen-devel] [PATCH v2 03/16] xen: sched: improve domain creation tracing

[Dario Faggioli]

by doing the following two things:

 - move TRC_SCHED_DOM_{ADD,REM}, into the functions
   that do the actual scheduling-related domain
   initialization;

 - add two 'generic' DOM_{ADD,REM} events. They're
   made part of the TRC_DOM0 tracing class, as Dom0
   is, usually, from where domains are created and
   destroyed.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Konrad Rzeszutek Wilk 
---
Changes from v1:
 * added generic domain creation and destruction events, as
   suggested during review.
---
 xen/common/domain.c|5 -
 xen/common/schedule.c  |4 ++--
 xen/include/public/trace.h |6 ++
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 425767c..45273d4 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -270,6 +270,8 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 
 d->domain_id = domid;
 
+TRACE_1D(TRC_DOM0_DOM_ADD, d->domain_id);
+
 lock_profile_register_struct(LOCKPROF_TYPE_PERDOM, d, domid, "Domain");
 
 if ( (err = xsm_alloc_security_domain(d)) != 0 )
@@ -864,10 +866,11 @@ void domain_destroy(struct domain *d)
 if ( atomic_cmpxchg(>refcnt, 0, DOMAIN_DESTROYED) != 0 )
 return;
 
+TRACE_1D(TRC_DOM0_DOM_REM, d->domain_id);
+
 cpupool_rm_domain(d);
 
 /* Delete from task list and task hashtable. */
-TRACE_1D(TRC_SCHED_DOM_REM, d->domain_id);
 spin_lock(_update_lock);
 pd = _list;
 while ( *pd != d ) 
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index c87922f..27695e3 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -241,8 +241,6 @@ int sched_init_vcpu(struct vcpu *v, unsigned int processor)
 if ( v->sched_priv == NULL )
 return 1;
 
-TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id);
-
 /* Idle VCPUs are scheduled immediately, so don't put them in runqueue. */
 if ( is_idle_domain(d) )
 {
@@ -369,12 +367,14 @@ void sched_destroy_vcpu(struct vcpu *v)
 int sched_init_domain(struct domain *d)
 {
 SCHED_STAT_CRANK(dom_init);
+TRACE_1D(TRC_SCHED_DOM_ADD, d->domain_id);
 return SCHED_OP(DOM2OP(d), init_domain, d);
 }
 
 void sched_destroy_domain(struct domain *d)
 {
 SCHED_STAT_CRANK(dom_destroy);
+TRACE_1D(TRC_SCHED_DOM_REM, d->domain_id);
 SCHED_OP(DOM2OP(d), destroy_domain, d);
 }
 
diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h
index 274f8f6..5ef9c37 100644
--- a/xen/include/public/trace.h
+++ b/xen/include/public/trace.h
@@ -85,6 +85,9 @@
   ((TRC_SCHED_##_c << TRC_SCHED_ID_SHIFT) & TRC_SCHED_ID_MASK) ) + \
 (_e & TRC_SCHED_EVT_MASK) )
 
+/* Trace classes for DOM0 operations */
+#define TRC_DOM0_DOMOPS 0x00041000   /* Domains manipulations */
+
 /* Trace classes for Hardware */
 #define TRC_HW_PM   0x00801000   /* Power management traces */
 #define TRC_HW_IRQ  0x00802000   /* Traces relating to the handling of 
IRQs */
@@ -113,6 +116,9 @@
 #define TRC_SCHED_SWITCH_INFNEXT (TRC_SCHED_VERBOSE + 15)
 #define TRC_SCHED_SHUTDOWN_CODE  (TRC_SCHED_VERBOSE + 16)
 
+#define TRC_DOM0_DOM_ADD (TRC_DOM0_DOMOPS + 1)
+#define TRC_DOM0_DOM_REM (TRC_DOM0_DOMOPS + 2)
+
 #define TRC_MEM_PAGE_GRANT_MAP  (TRC_MEM + 1)
 #define TRC_MEM_PAGE_GRANT_UNMAP(TRC_MEM + 2)
 #define TRC_MEM_PAGE_GRANT_TRANSFER (TRC_MEM + 3)


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

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

[osstest service owner]

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

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
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host 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-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  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-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  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-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linuxc4c3da71673d42ca12b7f3ee59f46f9f511be488
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  187 days
Failing since 60712  2015-08-15 18:33:48 Z  184 days  132 attempts
Testing same since82581  2016-02-14 22:26:59 Z1 days2 attempts

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-pvopsfail
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl

Re: [Xen-devel] [PATCH v4 4/4] libxl: fix cd-eject

[Ian Jackson]

Roger Pau Monne writes ("[PATCH v4 4/4] libxl: fix cd-eject"):
> Current libxl__device_disk_set_backend implementation tried to guess the
> backend of devices with format LIBXL_DISK_FORMAT_EMPTY, which is of course
> doomed to fail since the disk is empty. Instead just return early from the
> function if an empty disk is detected.
> 
> This fixes cd ejection.

DYK when this was broken ?  Or, to put it another way, how did this
ever work ?

...looking at the code...

AFAICT disk_try_backend should succeed for both LIBXL_DISK_BACKEND_PHY
and LIBXL_DISK_BACKEND_QDISK.  So even before your patch:

>  }
> -memset(, 0, sizeof(a.stab));
> +/* Disk is empty, so it's useless to try to guess the backend type. 
> */
> +return 0;
>  } else if ((disk->backend == LIBXL_DISK_BACKEND_UNKNOWN ||

libxl__device_disk_set_backend should work.

Worse, this change seems to leave disk->backend unset on return from
libxl__device_disk_set_backend, which seems quite wrong to me.

Ian.

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

Re: [Xen-devel] [PATCH] MAINTAINERS: add myself as seabios maintainer

[Ian Jackson]

Wei Liu writes ("[PATCH] MAINTAINERS: add myself as seabios maintainer"):
>  SEABIOS UPSTREAM
>  M:   Ian Campbell 
> +M:   Wei Liu 
>  S:   Supported
>  T:   git git://xenbits.xen.org/seabios.git

Acked-by: Ian Jackson 

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

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

[Tamas K Lengyel]

On Tue, Feb 16, 2016 at 10:48 AM, Corneliu ZUZU 
wrote:

> On 2/16/2016 6:02 PM, Tamas K Lengyel wrote:
>
>
>> @@ -143,77 +72,75 @@ int monitor_domctl(struct domain *d, struct
>> xen_domctl_monitor_op *mop)
>>
>>  case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR:
>>  {
>>
>
> So since we will now have two separate booleans, requested_status and
> old_status and then manually verify they are opposite..
>
>
>> -bool_t status = ad->monitor.mov_to_msr_enabled;
>> +bool_t old_status = ad->monitor.mov_to_msr_enabled;
>>
>
> ...here we should set the field to requested_status, not !old_status.
> While they are technically equivalent, the code would read better to other
> way around.
>
>
>>
>> -ad->monitor.mov_to_msr_enabled = !status;
>> +ad->monitor.mov_to_msr_enabled = !old_status;
>
>  domain_unpause(d);
>>  break;
>>  }
>>
>>  case XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP:
>>  {
>> -bool_t status = ad->monitor.singlestep_enabled;
>> +bool_t old_status = ad->monitor.singlestep_enabled;
>>
>> -rc = status_check(mop, status);
>> -if ( rc )
>> -return rc;
>> +if ( unlikely(old_status == requested_status) )
>> +return -EEXIST;
>>
>>  domain_pause(d);
>>
>
> Here as well..
>
>
>> -ad->monitor.singlestep_enabled = !status;
>> +ad->monitor.singlestep_enabled = !old_status;
>>  domain_unpause(d);
>>  break;
>>  }
>>
>>  case XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT:
>>  {
>> -bool_t status = ad->monitor.software_breakpoint_enabled;
>> +bool_t old_status = ad->monitor.software_breakpoint_enabled;
>>
>> -rc = status_check(mop, status);
>> -if ( rc )
>> -return rc;
>> +if ( unlikely(old_status == requested_status) )
>> +return -EEXIST;
>>
>>  domain_pause(d);
>>
>
> ..and here..
>
>
>> -ad->monitor.software_breakpoint_enabled = !status;
>> +ad->monitor.software_breakpoint_enabled = !old_status;
>>  domain_unpause(d);
>>  break;
>>  }
>>
>>  case XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST:
>>  {
>> -bool_t status = ad->monitor.guest_request_enabled;
>> +bool_t old_status = ad->monitor.guest_request_enabled;
>>
>> -rc = status_check(mop, status);
>> -if ( rc )
>> -return rc;
>> +if ( unlikely(old_status == requested_status) )
>> +return -EEXIST;
>>
>>  domain_pause(d);
>>  ad->monitor.guest_request_sync = mop->u.guest_request.sync;
>>
>
> ..and here.
>
>
>> -ad->monitor.guest_request_enabled = !status;
>> +ad->monitor.guest_request_enabled = !old_status;
>>  domain_unpause(d);
>>  break;
>>  }
>>
>
> Otherwise the patch looks good.
>
> Thanks,
> Tamas
>
>
> Oh, right, that would look better. Shall I send a v5 then with that
> change? (and if yes I guess it won't hurt if I also include the left-shift
> sanity checks I mentioned I should have added (?))
>

Please do send another revision with these changes. As I understood Jan
prefers the sanity-checks to be added as a separate patch, so do that.

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

Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands

[Ian Jackson]

Jim Fehlig writes ("Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands"):
> I just noticed this is the case with network devices as well. E.g.
> 
> #xl network-attach hvm-domU mac=00:16:3e:xx:yy:zz,bridge=br0
> libxl: error: libxl_device.c:1095:device_hotplug_child_death_cb: script: Could
> not find bridge device xenbr0

This is clearly a bug.

> main_networkattach() in tools/libxl/xl_cmdimpl.c doesn't split on
> the ',', so everything after mac=00:16:3e:xx:yy:zz is ignored.

That's quite silly, isn't it.  Looking at the code it would also accept
  mac=00:16:3e:aa:bb:cc:THIS:SHOULD:NOT:BE:HERE

The bug seems to be that the ad-hoc strtoul-based mac address parser
in xl_cmdimpl.c:parse_nic_config doesn't notice garbage after its
option.

> I'd need advice on how to fix this though. Based on
> xl-network-configuration doc and Xen tool's long history of
> network-attach supporting that syntax, I'd say main_networkattach()
> should be changed to split on ','. I could also change the docs. Do
> tools maintainers have a preference, or alternative option?

I don't have a strong opinion, but I would lean towards insisting that
on command lines each setting should be in its own argument.

Ian.

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

Re: [Xen-devel] [PATCH v8 3/5] libxl: add support for vscsi

[Ian Jackson]

Olaf Hering writes ("Re: [PATCH v8 3/5] libxl: add support for vscsi"):
> On Mon, Feb 15, Ian Jackson wrote:
> > One reason you might define a virtual controller with no devices yet
> > is so that you have a stable and pre-expected device path for any
> > actual targets you choose to hotplug later.
> 
> Would it be acceptable to reuse the devid as the "group index"?
> The various vdev in vscsi=['pdev,vdev'] will be assigned to the same
> vscsictrl if the host part in host:chn:target:lun matches. Right now an
> empty vscsictrl has no property to store the "host" part. This could be
> handled by either reusing devid, or by introducing a new xenstore
> property such as "libxl_vscsictrl_index". The value itself has no
> meaning other than being an index or label.

I haven't been following this design in detail, but: why is the
vscictrl `host' number not part of the xenstore path for the
controller, which in turn contains the devices ?

Ian.

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

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

[Corneliu ZUZU]

On 2/16/2016 6:02 PM, Tamas K Lengyel wrote:



@@ -143,77 +72,75 @@ int monitor_domctl(struct domain *d, struct
xen_domctl_monitor_op *mop)

 case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR:
 {


So since we will now have two separate booleans, requested_status and 
old_status and then manually verify they are opposite..


-bool_t status = ad->monitor.mov_to_msr_enabled;
+bool_t old_status = ad->monitor.mov_to_msr_enabled;


...here we should set the field to requested_status, not !old_status. 
While they are technically equivalent, the code would read better to 
other way around.



-ad->monitor.mov_to_msr_enabled = !status;
+ad->monitor.mov_to_msr_enabled = !old_status; 


 domain_unpause(d);
 break;
 }

 case XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP:
 {
-bool_t status = ad->monitor.singlestep_enabled;
+bool_t old_status = ad->monitor.singlestep_enabled;

-rc = status_check(mop, status);
-if ( rc )
-return rc;
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;

 domain_pause(d);


Here as well..

-ad->monitor.singlestep_enabled = !status;
+ad->monitor.singlestep_enabled = !old_status;
 domain_unpause(d);
 break;
 }

 case XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT:
 {
-bool_t status = ad->monitor.software_breakpoint_enabled;
+bool_t old_status = ad->monitor.software_breakpoint_enabled;

-rc = status_check(mop, status);
-if ( rc )
-return rc;
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;

 domain_pause(d);


..and here..

-ad->monitor.software_breakpoint_enabled = !status;
+ad->monitor.software_breakpoint_enabled = !old_status;
 domain_unpause(d);
 break;
 }

 case XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST:
 {
-bool_t status = ad->monitor.guest_request_enabled;
+bool_t old_status = ad->monitor.guest_request_enabled;

-rc = status_check(mop, status);
-if ( rc )
-return rc;
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;

 domain_pause(d);
 ad->monitor.guest_request_sync = mop->u.guest_request.sync;


..and here.

-ad->monitor.guest_request_enabled = !status;
+ad->monitor.guest_request_enabled = !old_status;
 domain_unpause(d);
 break;
 }


Otherwise the patch looks good.

Thanks,
Tamas



Oh, right, that would look better. Shall I send a v5 then with that 
change? (and if yes I guess it won't hurt if I also include the 
left-shift sanity checks I mentioned I should have added (?))


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

Re: [Xen-devel] [PATCH] xl: close nullfd after dup2'ing it to stdin

[Ian Jackson]

Ian Campbell writes ("[PATCH] xl: close nullfd after dup2'ing it to stdin"):
> Taking care not to do so if nullfd happens (somehow) to have the same
> fd number as stdin/out/err.

I think that can only happen if the program (the process) has a
serious problem: ie, fd 0 1 or 2 would have to be closed.  If that
happens many other things can go badly wrong.

If this is causing Coverity to complain I would suggest adding
   assert(nullfd >= 3);
   assert(logfile >= 3);
instead.

Ian.

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

Re: [Xen-devel] [PATCH] libxl: add basic spice support for pv domUs

[Wei Liu]

On Wed, Jan 13, 2016 at 11:47:55AM +0100, Fabio Fantoni wrote:
[...]
> >>
> >>diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> >>index 3b695bd..04a96ba 100644
> >>--- a/docs/man/xl.cfg.pod.5
> >>+++ b/docs/man/xl.cfg.pod.5
> >>@@ -1607,82 +1607,6 @@ it.
> >>  =back
> >>-=head3 Spice Graphics Support
> >>-
> >>-The following options control the features of SPICE.
> >>-
> >>-=over 4
> >>-
> >>-=item 

Re: [Xen-devel] [PATCH] libxl: close fd's in parent when spawning qdisk

[Ian Jackson]

Wei Liu writes ("Re: [PATCH] libxl: close fd's in parent when spawning qdisk"):
> On Tue, Feb 16, 2016 at 11:49:53AM +, Ian Campbell wrote:
> > Coverity points out that these remain open in the parent upon
> > success, which is a resource leak.
> 
> Acked-by: Wei Liu 

Committed-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] tools: libxl: NULL terminate partially constructed hex string

[Ian Jackson]

Wei Liu writes ("Re: [PATCH] tools: libxl: NULL terminate partially constructed 
hex string"):
> On Tue, Feb 16, 2016 at 11:18:20AM +, Ian Campbell wrote:
> > Coverity (correctly) complains that the strncpy(p, "0x", 2) will not
> > null terminate p.
> > Signed-off-by: Ian Campbell 
> 
> Acked-by: Wei Liu 

Committed-by: Ian Jackson 

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

[Xen-devel] [PATCH v4 4/4] libxl: fix cd-eject

[Roger Pau Monne]

Current libxl__device_disk_set_backend implementation tried to guess the
backend of devices with format LIBXL_DISK_FORMAT_EMPTY, which is of course
doomed to fail since the disk is empty. Instead just return early from the
function if an empty disk is detected.

This fixes cd ejection.

Signed-off-by: Roger Pau Monné 
Reported-by: Alex Braunegg 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Alex Braunegg 
---
 tools/libxl/libxl_device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8bb5e93..b93cbbf 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -273,7 +273,8 @@ int libxl__device_disk_set_backend(libxl__gc *gc, 
libxl_device_disk *disk) {
 LOG(ERROR, "Disk vdev=%s is empty but not cdrom", disk->vdev);
 return ERROR_INVAL;
 }
-memset(, 0, sizeof(a.stab));
+/* Disk is empty, so it's useless to try to guess the backend type. */
+return 0;
 } else if ((disk->backend == LIBXL_DISK_BACKEND_UNKNOWN ||
 disk->backend == LIBXL_DISK_BACKEND_PHY) &&
disk->backend_domid == LIBXL_TOOLSTACK_DOMID &&
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v4 2/4] libxl: introduce LIBXL_VGA_INTERFACE_TYPE_UNKNOWN

[Roger Pau Monne]

And use it as the default value for the VGA kind. This allows libxl to set
it to the default value later on when the domain type is known. For HVM
guests the default value is LIBXL_VGA_INTERFACE_TYPE_CIRRUS while for
HVMlite the default value is LIBXL_VGA_INTERFACE_TYPE_NONE.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v3:
 - s/UNDEF/UNKNOWN/.
 - Add a LIBXL_HAVE_VGA_INTERFACE_TYPE_UNKNOWN.
---
 tools/libxl/libxl.h | 10 ++
 tools/libxl/libxl_create.c  |  8 ++--
 tools/libxl/libxl_dm.c  |  6 ++
 tools/libxl/libxl_types.idl |  3 ++-
 4 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index fa87f53..1d11e02 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -876,6 +876,16 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
libxl_mac *src);
  */
 #define LIBXL_HAVE_DEVICE_MODEL_VERSION_NONE 1
 
+/*
+ * LIBXL_HAVE_VGA_INTERFACE_TYPE_UNKNOWN
+ *
+ * In the case that LIBXL_HAVE_VGA_INTERFACE_TYPE_UNKNOWN is set the
+ * libxl_vga_interface_type enumeration type contains a
+ * LIBXL_VGA_INTERFACE_TYPE_UNKNOWN identifier. This is used to signal
+ * that a libxl_vga_interface_type type has not been initialized yet.
+ */
+#define LIBXL_HAVE_VGA_INTERFACE_TYPE_UNKNOWN 1
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index de5d27f..e1a20a9 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -222,8 +222,12 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 if (b_info->u.hvm.mmio_hole_memkb == LIBXL_MEMKB_DEFAULT)
 b_info->u.hvm.mmio_hole_memkb = 0;
 
-if (!b_info->u.hvm.vga.kind)
-b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_UNKNOWN) {
+if (b_info->device_model_version == 
LIBXL_DEVICE_MODEL_VERSION_NONE)
+b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_NONE;
+else
+b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+}
 
 if (!b_info->u.hvm.hdtype)
 b_info->u.hvm.hdtype = LIBXL_HDTYPE_IDE;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a088d71..9aa0cc8 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -531,6 +531,9 @@ static int libxl__build_device_model_args_old(libxl__gc *gc,
 break;
 case LIBXL_VGA_INTERFACE_TYPE_QXL:
 break;
+default:
+LOG(ERROR, "Invalid emulated video card specified");
+return ERROR_INVAL;
 }
 
 if (b_info->u.hvm.boot) {
@@ -970,6 +973,9 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
 GCSPRINTF("qxl-vga,vram_size_mb=%"PRIu64",ram_size_mb=%"PRIu64,
 (b_info->video_memkb/2/1024), (b_info->video_memkb/2/1024) ) );
 break;
+default:
+LOG(ERROR, "Invalid emulated video card specified");
+return ERROR_INVAL;
 }
 
 if (b_info->u.hvm.boot) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 9ad7eba..e9e0da0 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -204,11 +204,12 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
 ], init_val = "LIBXL_SHUTDOWN_REASON_UNKNOWN")
 
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
+(0, "UNKNOWN"),
 (1, "CIRRUS"),
 (2, "STD"),
 (3, "NONE"),
 (4, "QXL"),
-], init_val = "LIBXL_VGA_INTERFACE_TYPE_CIRRUS")
+], init_val = "LIBXL_VGA_INTERFACE_TYPE_UNKNOWN")
 
 libxl_vendor_device = Enumeration("vendor_device", [
 (0, "NONE"),
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v4 3/4] libelf: rewrite symtab/strtab loading

[Roger Pau Monne]

Current implementation of elf_load_bsdsyms is broken when loading inside of
a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
memory space, which it is not.

Take the oportunity to do some cleanup and properly document how
elf_{parse/load}_bsdsyms works. The new implementation uses elf_load_image
when dealing with data that needs to be copied to the guest memory space.
Also reduce the number of section headers copied to the minimum necessary.

This patch also removes the duplication of code found in the libxc ELF
loader, since the libelf symtab/strtab loading code will also handle this
case without having to duplicate it.

Signed-off-by: Roger Pau Monné 
---
 tools/libxc/xc_dom_elfloader.c| 203 --
 xen/common/libelf/libelf-loader.c | 223 --
 2 files changed, 163 insertions(+), 263 deletions(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 5039f3f..62d421a 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -133,204 +133,6 @@ static elf_negerrnoval xc_dom_probe_elf_kernel(struct 
xc_dom_image *dom)
 return 0;
 }
 
-static elf_errorstatus xc_dom_load_elf_symtab(struct xc_dom_image *dom,
-  struct elf_binary *elf, bool load)
-{
-struct elf_binary syms;
-ELF_HANDLE_DECL(elf_shdr) shdr; ELF_HANDLE_DECL(elf_shdr) shdr2;
-xen_vaddr_t symtab, maxaddr;
-elf_ptrval hdr;
-size_t size;
-unsigned h, count, type, i, tables = 0;
-unsigned long *strtab_referenced = NULL;
-
-if ( elf_swap(elf) )
-{
-DOMPRINTF("%s: non-native byte order, bsd symtab not supported",
-  __FUNCTION__);
-return 0;
-}
-
-size = elf->bsd_symtab_pend - elf->bsd_symtab_pstart;
-
-if ( load )
-{
-char *hdr_ptr;
-size_t allow_size;
-
-if ( !dom->bsd_symtab_start )
-return 0;
-hdr_ptr = xc_dom_vaddr_to_ptr(dom, dom->bsd_symtab_start, _size);
-if ( hdr_ptr == NULL )
-{
-DOMPRINTF("%s: xc_dom_vaddr_to_ptr(dom,dom->bsd_symtab_start"
-  " => NULL", __FUNCTION__);
-return -1;
-}
-elf->caller_xdest_base = hdr_ptr;
-elf->caller_xdest_size = allow_size;
-hdr = ELF_REALPTR2PTRVAL(hdr_ptr);
-elf_store_val(elf, unsigned, hdr, size - sizeof(unsigned));
-}
-else
-{
-char *hdr_ptr;
-
-hdr_ptr = xc_dom_malloc(dom, size);
-if ( hdr_ptr == NULL )
-return 0;
-elf->caller_xdest_base = hdr_ptr;
-elf->caller_xdest_size = size;
-hdr = ELF_REALPTR2PTRVAL(hdr_ptr);
-dom->bsd_symtab_start = elf_round_up(elf, dom->kernel_seg.vend);
-dom->kernel_seg.vend = elf_round_up(elf, dom->bsd_symtab_start + size);
-return 0;
-}
-
-elf_memcpy_safe(elf, hdr + sizeof(unsigned),
-   ELF_IMAGE_BASE(elf),
-   elf_size(elf, elf->ehdr));
-elf_memcpy_safe(elf, hdr + sizeof(unsigned) + elf_size(elf, elf->ehdr),
-   ELF_IMAGE_BASE(elf) + elf_uval(elf, elf->ehdr, e_shoff),
-   elf_shdr_count(elf) * elf_size(elf, shdr));
-if ( elf_64bit(elf) )
-{
-Elf64_Ehdr *ehdr = (Elf64_Ehdr *)(hdr + sizeof(unsigned));
-ehdr->e_phoff = 0;
-ehdr->e_phentsize = 0;
-ehdr->e_phnum = 0;
-ehdr->e_shoff = elf_size(elf, elf->ehdr);
-ehdr->e_shstrndx = SHN_UNDEF;
-}
-else
-{
-Elf32_Ehdr *ehdr = (Elf32_Ehdr *)(hdr + sizeof(unsigned));
-ehdr->e_phoff = 0;
-ehdr->e_phentsize = 0;
-ehdr->e_phnum = 0;
-ehdr->e_shoff = elf_size(elf, elf->ehdr);
-ehdr->e_shstrndx = SHN_UNDEF;
-}
-if ( elf->caller_xdest_size < sizeof(unsigned) )
-{
-DOMPRINTF("%s: header size %"PRIx64" too small",
-  __FUNCTION__, (uint64_t)elf->caller_xdest_size);
-return -1;
-}
-if ( elf_init(, elf->caller_xdest_base + sizeof(unsigned),
-  elf->caller_xdest_size - sizeof(unsigned)) )
-return -1;
-
-/*
- * The caller_xdest_{base,size} and dest_{base,size} need to
- * remain valid so long as each struct elf_image does.  The
- * principle we adopt is that these values are set when the
- * memory is allocated or mapped, and cleared when (and if)
- * they are unmapped.
- *
- * Mappings of the guest are normally undone by xc_dom_unmap_all
- * (directly or via xc_dom_release).  We do not explicitly clear
- * these because in fact that happens only at the end of
- * xc_dom_boot_image, at which time all of these ELF loading
- * functions have returned.  No relevant struct elf_binary*
- * escapes this file.
- */
-
-xc_elf_set_logfile(dom->xch, , 1);
-
-symtab = dom->bsd_symtab_start + sizeof(unsigned);
-maxaddr = elf_round_up(, symtab 

[Xen-devel] [PATCH v4 0/4] Assorted fixes and improvements

[Roger Pau Monne]

Hello,

This series contains some assorted patches and improvements. They are 
completely ortogonal one fro meach other, so they can be applied 
independently without issues. I've just decided to group them together 
because I prefer it rather than spamming the list with 4 different threads.

#1 updates the HVMlite boot ABI according to the discussion we had arround 
the design document.

#2 introduces a new UNKNOWN VGA type that can be used to let libxl decide 
which emulated VGA it's going to be used.

#3 rewrites and simplifies the strtab/symtab loading, and get rid of a bunch 
of duplicated code.

#4 is a fix for cd-eject issues, which consists in fixing 
libxl__device_disk_set_backend in order to avoid trying to guess the backend 
type for LIBXL_DISK_FORMAT_EMPTY disks.

Thanks, Roger.

NB: this is labeled as v4 because #2 is at v4, I'm not sure about the 
version of the others, but it's certainly < 4.

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

[Xen-devel] [PATCH v4 1/4] x86/HVM: update the start info structure layout

[Roger Pau Monne]

After some discussion around the new boot ABI consensus has been reached
about the layout and contents of the start info. The following patch updates
the layout to what has been agreed.

Also, the new layout is described in binary terms in order to avoid issues
with alignments when using C structs.

Signed-off-by: Roger Pau Monné 
---
Cc: Samuel Thibault 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/libxc/include/xc_dom.h | 31 +
 xen/include/public/xen.h | 55 ++--
 2 files changed, 69 insertions(+), 17 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index cac4698..6ebe946 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -216,6 +216,37 @@ struct xc_dom_image {
 struct xc_hvm_firmware_module smbios_module;
 };
 
+#if defined(__i386__) || defined(__x86_64__)
+/* C representation of the x86/HVM start info layout.
+ *
+ * The canonical definition of this layout resides in public/xen.h, this
+ * is just a way to represent the layout described there using C types.
+ *
+ * NB: the packed attribute is not really needed, but it helps us enforce
+ * the fact this this is just a representation, and it might indeed
+ * be required in the future if there are alignment changes.
+ */
+struct hvm_start_info {
+uint32_t magic; /* Contains the magic value 0x336ec578   */
+/* ("xEn3" with the 0x80 bit of the "E" set).*/
+uint32_t version;   /* Version of this structure.*/
+uint32_t flags; /* SIF_xxx flags.*/
+uint32_t cmdline_paddr; /* Physical address of the command line. */
+uint32_t nr_modules;/* Number of modules passed to the kernel.   */
+uint32_t modlist_paddr; /* Physical address of an array of   */
+/* hvm_modlist_entry.*/
+uint32_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
+/* structure.*/
+} __attribute__((packed));
+
+struct hvm_modlist_entry {
+uint64_t paddr; /* Physical address of the module.   */
+uint64_t size;  /* Size of the module in bytes.  */
+uint64_t cmdline_paddr; /* Physical address of the command line. */
+uint64_t reserved;
+} __attribute__((packed));
+#endif /* x86 */
+
 /* --- pluggable kernel loader - */
 
 struct xc_dom_loader {
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 7b629b1..6ba060f 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -787,25 +787,46 @@ typedef struct start_info start_info_t;
 /*
  * Start of day structure passed to PVH guests in %ebx.
  *
- * NOTE: nothing will be loaded at physical address 0, so
- * a 0 value in any of the address fields should be treated
- * as not present.
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ *  0 ++
+ *| magic  | Contains the magic value HVM_START_MAGIC_VALUE
+ *|| ("xEn3" with the 0x80 bit of the "E" set).
+ *  4 ++
+ *| version| Version of this structure. Current version is 0. New
+ *|| versions are guaranteed to be backwards-compatible.
+ *  8 ++
+ *| flags  | SIF_xxx flags.
+ * 12 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 16 ++
+ *| nr_modules | Number of modules passed to the kernel.
+ * 20 ++
+ *| modlist_paddr  | Physical address of an array of modules
+ *|| (layout of the structure below).
+ * 24 ++
+ *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
+ * 28 ++
+ *
+ * The layout of each entry in the module structure is the following:
+ *
+ *  0 ++
+ *| paddr  | Physical address of the module.
+ *  8 ++
+ *| size   | Size of the module in bytes.
+ * 16 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 24 ++
+ *| reserved   |
+ * 32 ++
+ *
+ * The address and size of the modules is a 64bit unsigned integer. However
+ * Xen will always try to place all modules below the 4GiB boundary.
  */
-struct 

Re: [Xen-devel] [PATCH] tools: libxl: free devpath on failure in libxl__blktap_devpath

[Ian Jackson]

Wei Liu writes ("Re: [PATCH] tools: libxl: free devpath on failure in 
libxl__blktap_devpath"):
> On Tue, Feb 16, 2016 at 11:09:43AM +, Ian Campbell wrote:
> > The underlying code paths in tap_ctl_create attempt to handle both
> > *devpath == NULL (by allocating) and *devpath != NULL (caller provided
> > name) and if they allocate tend to write the return immediately before
> > doing other potentially error generating tasks. All of which makes
> > handling this at a lower level rather more complicated than handling
> > it in the error path of libxl__bllktap_devpath.

Committed-by: Ian Jackson 

> Extraneous "l" in the function name.

Fixed this.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v2] stubdom: fix link farm runes

[Ian Jackson]

Wei Liu writes ("[PATCH v2] stubdom: fix link farm runes"):
> Previously in the three problematic libraries all public headers were
> linked to source code directory. We should have created an include
> directory for each library and linked public headers there.
> 
> Note that there was no breakage for those three libraries before this
> patch. This patch merely changes the location headers are linked to so
> that all libraries follow the same pattern.
> 
> Signed-off-by: Wei Liu 
> Acked-by: Samuel Thibault 

Committed-by: Ian Jackson 

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

[Xen-devel] [PATCH] MAINTAINERS: add myself as seabios maintainer

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f07384c..c056284 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -299,6 +299,7 @@ F:  xen/common/sched*
 
 SEABIOS UPSTREAM
 M: Ian Campbell 
+M: Wei Liu 
 S: Supported
 T: git git://xenbits.xen.org/seabios.git
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2] xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"

[Stefano Stabellini]

On Tue, 16 Feb 2016, Arnd Bergmann wrote:
> The Xen framebuffer driver selects the xen keyboard driver, so the latter
> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
> is a loadable module, this configuration cannot work. On mainline kernels,
> the symbol will be enabled but not used, while in combination with
> a patch I have to detect such useless configurations, we get the
> expected link failure:
> 
> drivers/input/built-in.o: In function `xenkbd_remove':
> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
> 
> This removes the extra "select", as it just causes more trouble than
> it helps. In theory, some defconfig file might break if it has
> XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
> fragment we ship in the kernel (kernel/configs/xen.config) however
> already enables both, and anyone using an old .config file would
> keep having both enabled.
> 
> Signed-off-by: Arnd Bergmann 
> Suggested-by: David Vrabel 
> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")

Acked-by: Stefano Stabellini 


> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5cd806..d889ef2048df 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2246,7 +2246,6 @@ config XEN_FBDEV_FRONTEND
>   select FB_SYS_IMAGEBLIT
>   select FB_SYS_FOPS
>   select FB_DEFERRED_IO
> - select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
>   select XEN_XENBUS_FRONTEND
>   default y
>   help
> 

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

Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands

[Olaf Hering]

On Tue, Jan 19, Chunyan Liu wrote:

>  #xl usbctrl-attach test_vm version=1 ports=8

>  #xl usbdev-attach test_vm hostbus=1 hostaddr=2

I think this does not handle the -N knob of xl. Other commands check the
global dryrun_only variable.

Olaf

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

[Xen-devel] xen/arm64: interrupt trouble porting to a new board

[Dirk Behme]

Hi,

trying to bring up Xen on an ARM64 CA57 device (1 core atm) using a 
recent Xen 4.7-unstable and Linux kernel 4.4.0+ I'm getting [1]. The 
device tree configures arm,gic-400.


Regarding the , the Linux kernel boot messages are stopping 
here. The debugger shows the system looping in xen/arch/arm/domain.c 
idle_loop().


It's my impression that anything with the interrupts might be wrong, 
which prevents the Linux kernel from further booting (?).


Talking about the interrupts, the log shows various

d0v0: vGICD: unhandled word write 0x to ICACTIVERx

messages while the kernel is booting.

I'm not sure if both issues might be related (?).

Any idea?

Any hint where to look or debug?

Best regards

Dirk

[1]

...
 Xen 4.7-unstable
...
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=f101
(XEN) gic_cpu_addr=f102
(XEN) gic_hyp_addr=f104
(XEN) gic_vcpu_addr=f106
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
...
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch 
input to Xen)

(XEN) Freed 288kB init memory.
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER28
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER32
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER36
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER40
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER44
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER48
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER52
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER56
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER60
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
[0.00] Booting Linux on physical CPU 0x0
...
[0.173561] xen:grant_table: Grant tables using version 1 layout
[0.176538] Grant table initialized
[0.178321] xen:events: Using FIFO-based ABI
[0.180483] Xen: initializing cpu0




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

Re: [Xen-devel] Wall-Clock-Time-Jump after migration [xen-4.1]

[David Vrabel]

On 16/02/16 15:38, Philipp Hahn wrote:
> Hello,
> 
> I'm trying to understand Xens implementation of (wall-)clock time and
> observed a strange behaviour:
> 
> Summary: When a Linux-PV-domU is migrated between two hosts, the
> "ntpdate" time jumps.
> 
> Environment: xen-4.1 with linux-3.2 and linux-3.10, ntpdate running in
> all dom[0U].

You might need the following commits in your dom0 kernel, all of which
are in 3.11 and later.

3565184ed0c1ea46bea5b792da5f72a83c43e49b
7c4c3a0f18ba57ea2a2985034532303d2929902a
0eb071651474952c8b6daecd36b378e2d01be22c
04397fe94ad65289884b9862b6a0c722ececaadf
780427f0e113b4c77dfff4d258c05a902cdb0eb9
5584880e44e49c587059801faa2a9f7d22619c48
47433b8c9d7480a3eebd99df38e857ce85a37cee

David

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

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

[Tamas K Lengyel]

>
>
> @@ -143,77 +72,75 @@ int monitor_domctl(struct domain *d, struct
> xen_domctl_monitor_op *mop)
>
>  case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR:
>  {
>

So since we will now have two separate booleans, requested_status and
old_status and then manually verify they are opposite..


> -bool_t status = ad->monitor.mov_to_msr_enabled;
> +bool_t old_status = ad->monitor.mov_to_msr_enabled;
>

...here we should set the field to requested_status, not !old_status. While
they are technically equivalent, the code would read better to other way
around.


>
> -ad->monitor.mov_to_msr_enabled = !status;
> +ad->monitor.mov_to_msr_enabled = !old_status;

 domain_unpause(d);
>  break;
>  }
>
>  case XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP:
>  {
> -bool_t status = ad->monitor.singlestep_enabled;
> +bool_t old_status = ad->monitor.singlestep_enabled;
>
> -rc = status_check(mop, status);
> -if ( rc )
> -return rc;
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
>
>  domain_pause(d);
>

Here as well..


> -ad->monitor.singlestep_enabled = !status;
> +ad->monitor.singlestep_enabled = !old_status;
>  domain_unpause(d);
>  break;
>  }
>
>  case XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT:
>  {
> -bool_t status = ad->monitor.software_breakpoint_enabled;
> +bool_t old_status = ad->monitor.software_breakpoint_enabled;
>
> -rc = status_check(mop, status);
> -if ( rc )
> -return rc;
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
>
>  domain_pause(d);
>

..and here..


> -ad->monitor.software_breakpoint_enabled = !status;
> +ad->monitor.software_breakpoint_enabled = !old_status;
>  domain_unpause(d);
>  break;
>  }
>
>  case XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST:
>  {
> -bool_t status = ad->monitor.guest_request_enabled;
> +bool_t old_status = ad->monitor.guest_request_enabled;
>
> -rc = status_check(mop, status);
> -if ( rc )
> -return rc;
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
>
>  domain_pause(d);
>  ad->monitor.guest_request_sync = mop->u.guest_request.sync;
>

..and here.


> -ad->monitor.guest_request_enabled = !status;
> +ad->monitor.guest_request_enabled = !old_status;
>  domain_unpause(d);
>  break;
>  }
>

Otherwise the patch looks good.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat fail REGR. vs. 82574
 test-armhf-armhf-xl-vhd   9 debian-di-install fail REGR. vs. 82574

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 82574
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 82574

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

version targeted for testing:
 qemuu80b5d6bfc1280fa06e2514a414690c0e5b4b514b
baseline version:
 qemuua5af12871fd4601c44f08d9e49131e9ca13ef102

Last test of basis82574  2016-02-14 21:26:53 Z1 days
Testing same since82711  2016-02-15 17:28:37 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Richard Henderson 

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   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 

[Xen-devel] [PATCH V2] xen: make some constants usable for assembler

[Juergen Gross]

Some constants defined in xen/include/public/xen.h are not usable in
assembler sources as they are either defined with "U" or "UL" suffixes
or they are inside #ifndef __ASSEMBLY__ areas.

Change this as grub2 could make use of those definitions.

This requires to move the definition of mk_unsigned_long() up. While
we are touching this macro, rename it in order to avoid namespace
pollution. This in turn requires adaption of some arch-x86 specific
headers.

Signed-off-by: Juergen Gross 
---
V2: - rename mk_unsigned_long to xen_mk_ulong and mk_unsigned to xen_mk_uint
  as requested by Jan Beulich
- corrected UVMF_* definitions as requested by Jan Beulich
---
 xen/include/public/arch-x86/xen-x86_32.h | 21 +---
 xen/include/public/arch-x86/xen-x86_64.h |  8 ++---
 xen/include/public/xen.h | 58 +---
 3 files changed, 44 insertions(+), 43 deletions(-)

diff --git a/xen/include/public/arch-x86/xen-x86_32.h 
b/xen/include/public/arch-x86/xen-x86_32.h
index be9a6c6..7eca6cd 100644
--- a/xen/include/public/arch-x86/xen-x86_32.h
+++ b/xen/include/public/arch-x86/xen-x86_32.h
@@ -58,34 +58,31 @@
 #define __HYPERVISOR_VIRT_START_PAE0xF580
 #define __MACH2PHYS_VIRT_START_PAE 0xF580
 #define __MACH2PHYS_VIRT_END_PAE   0xF680
-#define HYPERVISOR_VIRT_START_PAE  \
-mk_unsigned_long(__HYPERVISOR_VIRT_START_PAE)
-#define MACH2PHYS_VIRT_START_PAE   \
-mk_unsigned_long(__MACH2PHYS_VIRT_START_PAE)
-#define MACH2PHYS_VIRT_END_PAE \
-mk_unsigned_long(__MACH2PHYS_VIRT_END_PAE)
+#define HYPERVISOR_VIRT_START_PAE  
xen_mk_ulong(__HYPERVISOR_VIRT_START_PAE)
+#define MACH2PHYS_VIRT_START_PAE   xen_mk_ulong(__MACH2PHYS_VIRT_START_PAE)
+#define MACH2PHYS_VIRT_END_PAE xen_mk_ulong(__MACH2PHYS_VIRT_END_PAE)
 
 /* Non-PAE bounds are obsolete. */
 #define __HYPERVISOR_VIRT_START_NONPAE 0xFC00
 #define __MACH2PHYS_VIRT_START_NONPAE  0xFC00
 #define __MACH2PHYS_VIRT_END_NONPAE0xFC40
 #define HYPERVISOR_VIRT_START_NONPAE   \
-mk_unsigned_long(__HYPERVISOR_VIRT_START_NONPAE)
+xen_mk_ulong(__HYPERVISOR_VIRT_START_NONPAE)
 #define MACH2PHYS_VIRT_START_NONPAE\
-mk_unsigned_long(__MACH2PHYS_VIRT_START_NONPAE)
+xen_mk_ulong(__MACH2PHYS_VIRT_START_NONPAE)
 #define MACH2PHYS_VIRT_END_NONPAE  \
-mk_unsigned_long(__MACH2PHYS_VIRT_END_NONPAE)
+xen_mk_ulong(__MACH2PHYS_VIRT_END_NONPAE)
 
 #define __HYPERVISOR_VIRT_START __HYPERVISOR_VIRT_START_PAE
 #define __MACH2PHYS_VIRT_START  __MACH2PHYS_VIRT_START_PAE
 #define __MACH2PHYS_VIRT_END__MACH2PHYS_VIRT_END_PAE
 
 #ifndef HYPERVISOR_VIRT_START
-#define HYPERVISOR_VIRT_START mk_unsigned_long(__HYPERVISOR_VIRT_START)
+#define HYPERVISOR_VIRT_START xen_mk_ulong(__HYPERVISOR_VIRT_START)
 #endif
 
-#define MACH2PHYS_VIRT_START  mk_unsigned_long(__MACH2PHYS_VIRT_START)
-#define MACH2PHYS_VIRT_ENDmk_unsigned_long(__MACH2PHYS_VIRT_END)
+#define MACH2PHYS_VIRT_START  xen_mk_ulong(__MACH2PHYS_VIRT_START)
+#define MACH2PHYS_VIRT_ENDxen_mk_ulong(__MACH2PHYS_VIRT_END)
 #define MACH2PHYS_NR_ENTRIES  ((MACH2PHYS_VIRT_END-MACH2PHYS_VIRT_START)>>2)
 #ifndef machine_to_phys_mapping
 #define machine_to_phys_mapping ((unsigned long *)MACH2PHYS_VIRT_START)
diff --git a/xen/include/public/arch-x86/xen-x86_64.h 
b/xen/include/public/arch-x86/xen-x86_64.h
index 1c4e159..5e18613 100644
--- a/xen/include/public/arch-x86/xen-x86_64.h
+++ b/xen/include/public/arch-x86/xen-x86_64.h
@@ -76,12 +76,12 @@
 #define __MACH2PHYS_VIRT_END0x8040
 
 #ifndef HYPERVISOR_VIRT_START
-#define HYPERVISOR_VIRT_START mk_unsigned_long(__HYPERVISOR_VIRT_START)
-#define HYPERVISOR_VIRT_END   mk_unsigned_long(__HYPERVISOR_VIRT_END)
+#define HYPERVISOR_VIRT_START xen_mk_ulong(__HYPERVISOR_VIRT_START)
+#define HYPERVISOR_VIRT_END   xen_mk_ulong(__HYPERVISOR_VIRT_END)
 #endif
 
-#define MACH2PHYS_VIRT_START  mk_unsigned_long(__MACH2PHYS_VIRT_START)
-#define MACH2PHYS_VIRT_ENDmk_unsigned_long(__MACH2PHYS_VIRT_END)
+#define MACH2PHYS_VIRT_START  xen_mk_ulong(__MACH2PHYS_VIRT_START)
+#define MACH2PHYS_VIRT_ENDxen_mk_ulong(__MACH2PHYS_VIRT_END)
 #define MACH2PHYS_NR_ENTRIES  ((MACH2PHYS_VIRT_END-MACH2PHYS_VIRT_START)>>3)
 #ifndef machine_to_phys_mapping
 #define machine_to_phys_mapping ((unsigned long *)HYPERVISOR_VIRT_START)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 7b629b1..6c9e42b 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -52,6 +52,19 @@ DEFINE_XEN_GUEST_HANDLE(void);
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
 DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
+
+/* Turn a plain number into a C unsigned (long) constant. */
+#define __xen_mk_uint(x)  x ## U
+#define __xen_mk_ulong(x) x ## UL
+#define xen_mk_uint(x)__xen_mk_uint(x)
+#define xen_mk_ulong(x)   __xen_mk_ulong(x)
+
+#else
+
+/* In assembly code we cannot use C numeric constant suffixes. */

[Xen-devel] Wall-Clock-Time-Jump after migration [xen-4.1]

[Philipp Hahn]

Hello,

I'm trying to understand Xens implementation of (wall-)clock time and
observed a strange behaviour:

Summary: When a Linux-PV-domU is migrated between two hosts, the
"ntpdate" time jumps.

Environment: xen-4.1 with linux-3.2 and linux-3.10, ntpdate running in
all dom[0U].

1. If I start a new domU (just kernel and InitRamFS with busybox as to
minimize the processes involved), the wall-clock-time if off by ~283
(=4m43s) seconds:

dom0: Tue Deb 16 14:48:12 UTC 2016 (before starting domU)
domU: Tue Feb 16 14:43:32 UTC 2016 (after boot, which takes ~3s)

If I then run "ntpdate" that domU, the offset is corrected:
> 16 Feb 14:51:59 ntpdate[150]: step time server X.X.73.241 offset 283.697217 
> sec


Q: Where does the initial time for the domU come from?

As a PV domain the domU does not have /dev/rtc and ntpdate hasn't been
run yet, so the time is what the domU got from Xen, I guess.


Q: Where does that offset of ~283s come from?

From reading the Xen source code I guess it was the error of the RTC
clock of the dom0, when the host was booted. The dom0 uses NTP to
correct its time, but that difference never got re-applied back to the
hypervisor.
My understanding is, that the Hypervisor initialized its time from the
RTC and changing the time in dom0 only updates the delta between the
Hypervisor-clock and the dom0 (struct domain.time_offset_seconds), but
not the Hypervisor-clock itself, which keeps counting seconds since
boot. As each domX hat its own "time_offset_seconds", each new domU is
still off by that initial delta.
> # hwclock --show  
>   
>   
> Di 16 Feb 2016 16:32:46 CET  -0.203211 seconds



Q: Is the shard_info.wc_sec supposed to be updated?

I used `xm dump-core domU` and `readelf -x .xen_shared_info core` to get
the content from "stuct whared_info -> wc_sec" of the domU:
> 0x0c00 0200 d10dc654 edc99a3b

Using offsetof() and big-endian to little-endian I get:
> LANG=C TZ=UTC date -d @$((0x54c60dd1))
> Mon Jan 26 09:50:09 UTC 2015

Adding the uptime of that system of ~1 year I nearly get now():
> # LANG=C TZ=UTC date -d @$((0x54c60dd1+$(cut -c1-8 /proc/uptime)));LANG=C 
> TZ=UTC date
> Tue Feb 16 15:04:16 UTC 2016
> Tue Feb 16 15:04:37 UTC 2016

To me that looks like its the time of boot, but not the current
wall-clock time. Did I do something wrong or what do I misunderstand?


2. If I repeat the same steps with starting the domU on my second host,
I do get different offsets:
dom0: Tue Feb 16 15:10:55 UTC 2016 (before starting domU)
domU: Tue Feb 16 15:10:33 UTC 2016 (after boot taking ~3s)

The delta is ~22s, which ntpdate confirms:
> 16 Feb 15:13:06 ntpdate[149]: step time server X.X.73.241 offset 26.009473 sec

> # hwclock --show  
>   
>   
> Di 16 Feb 2016 16:32:42 CET  -0.916229 seconds



3. If I migrate the domain from the first host to the second while
running "ntpdate" in a loop, I see the clock jumping ~257s, which
matches the difference between the time_offset_seconds between the hosts
(283 - 22):
> 16 Feb 15:21:17 ntpdate[154]: adjust time server X.X.73.241 offset 0.000546 
> sec
> 16 Feb 15:17:07 ntpdate[155]: step time server X.X.73.241 offset -257.532775 
> sec
> 16 Feb 15:17:15 ntpdate[156]: adjust time server X.X.73.241 offset -0.000493 
> sec
> 16 Feb 15:17:24 ntpdate[157]: adjust time server X.X.73.241 offset 0.000374 
> sec
> 16 Feb 15:17:32 ntpdate[158]: adjust time server X.X.73.241 offset 0.10 
> sec
> 16 Feb 15:17:40 ntpdate[159]: adjust time server X.X.73.241 offset 0.000170 
> sec
> 16 Feb 15:17:48 ntpdate[160]: adjust time server X.X.73.241 offset 0.000269 
> sec
> 16 Feb 15:17:56 ntpdate[161]: adjust time server X.X.73.241 offset -0.000194 
> sec
> 16 Feb 15:18:04 ntpdate[162]: adjust time server X.X.73.241 offset 0.000287 
> sec
> 16 Feb 15:18:12 ntpdate[163]: adjust time server X.X.73.241 offset 0.000146 
> sec

To me that looks like "time_offset_seconds" is migrated, but as "wc_sec"
between the two hosts is not synchronized, the time jumps.

Q: Is that a known problem and has it been fixed in newer versions of Xen?


Q: Is there some recommended procedure to synchronize the time of
multiple hypervisors, like perhaps:
  1. boot xen once
  2. correct time using NTP
  3. write time to RTC
  4. reboot the hypervisor so it can read the corrected RTC
  5. onyl now start domUs and migrate them


Correct wall-clock time is essential, so I'm looking for a stable
solution to have correct wall-clock-time in our domUs. The jump of
several seconds is unacceptable and NTPd would take to long to slew that
clock back to reality. That's why we're using ntpdate, as we want to go
back to real-time as fast as 

[Xen-devel] [PATCH] xen: cleanup config.h

[Juergen Gross]

config.h contains an unused definition of mk_unsigned_long().

Remove it.

Signed-off-by: Juergen Gross 
---
 xen/include/xen/config.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index d780121..a992933 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -77,15 +77,6 @@
 #define __STR(...) #__VA_ARGS__
 #define STR(...) __STR(__VA_ARGS__)
 
-#ifndef __ASSEMBLY__
-/* Turn a plain number into a C unsigned long constant. */
-#define __mk_unsigned_long(x) x ## UL
-#define mk_unsigned_long(x) __mk_unsigned_long(x)
-#else /* __ASSEMBLY__ */
-/* In assembly code we cannot use C numeric constant suffixes. */
-#define mk_unsigned_long(x) x
-#endif /* !__ASSEMBLY__ */
-
 #ifdef CONFIG_FLASK
 #define XSM_MAGIC 0xf97cff8c
 /* Maintain statistics on the access vector cache */
-- 
2.6.2


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

Re: [Xen-devel] [PATCH v8 3/5] libxl: add support for vscsi

[Olaf Hering]

On Mon, Feb 15, Ian Jackson wrote:

> One reason you might define a virtual controller with no devices yet
> is so that you have a stable and pre-expected device path for any
> actual targets you choose to hotplug later.

Would it be acceptable to reuse the devid as the "group index"?
The various vdev in vscsi=['pdev,vdev'] will be assigned to the same
vscsictrl if the host part in host:chn:target:lun matches. Right now an
empty vscsictrl has no property to store the "host" part. This could be
handled by either reusing devid, or by introducing a new xenstore
property such as "libxl_vscsictrl_index". The value itself has no
meaning other than being an index or label.

Olaf

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

Re: [Xen-devel] [PATCH OSSTEST] crontab: Add a coverity run on a Wednesday

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST] crontab: Add a coverity run on a 
Wednesday"):
> In addition to the current Sunday run.
> 
> Projects of Xen's size are currently allowed 2 builds per week (max 1
> per day), so make use of both.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Ian Jackson 

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

[Xen-devel] [PATCH v3] public/io/netif.h: make control ring hash protocol more general

[Paul Durrant]

This patch modified the control ring protocol (of which there is
not yet an implementation) to make it more general. Most of the
concepts are not limited to toeplitz hashing so it's best not to
make them unnecessarily specific.

Apart from changing the names of various definitions and modifying
comments, this patch:

- Adds a new control message type to select a hash algorithm.
- Adds a reference implementation of the toeplitz hash.
- Changes the 'toeplitz' extra info fragment into a 'hash' extra
  info fragment and replaces the octet of padding with the index of
  the algorithm that was used to create the hash value.

The patch also fixes a few spelling typos noticed along the way.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---

v2:
  - Remove 'inline' from reference hash definition and make the
definition optional

v3:
  - Use XEN_NETIF_ prefix instead of NETIF_
  - Make hash mapping table optional
  - Allow a hash mapping table that is not power-of-two sized
---
 xen/include/public/io/netif.h | 275 --
 1 file changed, 183 insertions(+), 92 deletions(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index 8816e0f..6eacd76 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -164,7 +164,7 @@
  * Control ring
  * 
  *
- * Some features, such as toeplitz hashing (detailed below), require a
+ * Some features, such as hashing (detailed below), require a
  * significant amount of out-of-band data to be passed from frontend to
  * backend. Use of xenstore is not suitable for large quantities of data
  * because of quota limitations and so a dedicated 'control ring' is used.
@@ -191,8 +191,8 @@
  */
 
 /*
- * Toeplitz hash types
- * ===
+ * Hash types
+ * ==
  *
  * For the purposes of the definitions below, 'Packet[]' is an array of
  * octets containing an IP packet without options, 'Array[X..Y]' means a
@@ -206,10 +206,10 @@
  * Buffer[0..8] = Packet[12..15] (source address) +
  *Packet[16..19] (destination address)
  *
- * Result = ToeplitzHash(Buffer, 8)
+ * Result = Hash(Buffer, 8)
  */
-#define _NETIF_CTRL_TOEPLITZ_HASH_IPV4 0
-#define NETIF_CTRL_TOEPLITZ_HASH_IPV4  (1 << 
_NETIF_CTRL_TOEPLITZ_HASH_IPV4)
+#define _NETIF_CTRL_HASH_TYPE_IPV4 0
+#define NETIF_CTRL_HASH_TYPE_IPV4 (1 << _NETIF_CTRL_HASH_TYPE_IPV4)
 
 /*
  * A hash calculated over an IP version 4 header and TCP header as
@@ -220,10 +220,10 @@
  * Packet[20..21] (source port) +
  * Packet[22..23] (destination port)
  *
- * Result = ToeplitzHash(Buffer, 12)
+ * Result = Hash(Buffer, 12)
  */
-#define _NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP 1
-#define NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP  (1 << 
_NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP)
+#define _NETIF_CTRL_HASH_TYPE_IPV4_TCP 1
+#define NETIF_CTRL_HASH_TYPE_IPV4_TCP (1 << _NETIF_CTRL_HASH_TYPE_IPV4_TCP)
 
 /*
  * A hash calculated over an IP version 6 header as follows:
@@ -231,10 +231,10 @@
  * Buffer[0..32] = Packet[8..23]  (source address ) +
  * Packet[24..39] (destination address)
  *
- * Result = ToeplitzHash(Buffer, 32)
+ * Result = Hash(Buffer, 32)
  */
-#define _NETIF_CTRL_TOEPLITZ_HASH_IPV6 2
-#define NETIF_CTRL_TOEPLITZ_HASH_IPV6  (1 << 
_NETIF_CTRL_TOEPLITZ_HASH_IPV4)
+#define _NETIF_CTRL_HASH_TYPE_IPV6 2
+#define NETIF_CTRL_HASH_TYPE_IPV6 (1 << _NETIF_CTRL_HASH_TYPE_IPV6)
 
 /*
  * A hash calculated over an IP version 6 header and TCP header as
@@ -245,10 +245,79 @@
  * Packet[40..41] (source port) +
  * Packet[42..43] (destination port)
  *
- * Result = ToeplitzHash(Buffer, 36)
+ * Result = Hash(Buffer, 36)
+ */
+#define _NETIF_CTRL_HASH_TYPE_IPV6_TCP 3
+#define NETIF_CTRL_HASH_TYPE_IPV6_TCP (1 << _NETIF_CTRL_HASH_TYPE_IPV6_TCP)
+
+/*
+ * Hash algorithms
+ * ===
+ */
+
+#define NETIF_CTRL_HASH_ALGORITHM_NONE 0
+
+/*
+ * Toeplitz hash:
  */
-#define _NETIF_CTRL_TOEPLITZ_HASH_IPV6_TCP 3
-#define NETIF_CTRL_TOEPLITZ_HASH_IPV6_TCP  (1 << 
_NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP)
+
+#define NETIF_CTRL_HASH_ALGORITHM_TOEPLITZ 1
+
+/*
+ * This algorithm uses a 'key' as well as the data buffer itself.
+ * (Buffer[] and Key[] are treated as shift-registers where the MSB of
+ * Buffer/Key[0] is considered 'left-most' and the LSB of Buffer/Key[N-1]
+ * is the 'right-most').
+ *
+ * Value = 0
+ * For number of bits in Buffer[]
+ *If (left-most bit of Buffer[] is 1)
+ *Value ^= left-most 32 bits of Key[]
+ *Key[] << 1
+ *Buffer[] << 1
+ *
+ * The code below is provided for convenience where an operating system
+ * does not already provide an implementation.
+ */
+#ifdef XEN_NETIF_DEFINE_TOEPLITZ
+static uint32_t netif_toeplitz_hash(const uint8_t 

Re: [Xen-devel] [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select

[Arnd Bergmann]

On Tuesday 16 February 2016 12:14:14 Stefano Stabellini wrote:
> > at all.
> 
> Please correct me if I am wrong, but the difference is that with this
> change if INPUT=m, then the build system would ask the user whether she
> wants to select INPUT_XEN_KBDDEV_FRONTEND as m or y, instead of
> unconditionally set INPUT_XEN_KBDDEV_FRONTEND=y.

INPUT_XEN_KBDDEV_FRONTEND cannot be set by the user to 'y' if
INPUT=m, because of an implied dependency around the input/misc/Kconfig
file.

> However it is true that if the users chooses
> INPUT_XEN_KBDDEV_FRONTEND=y, then the problem persists.
> Maybe we also need:
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 1f2337a..303df24 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -721,7 +721,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
> tristate "Xen virtual keyboard and mouse support"
> -   depends on XEN
> +   depends on XEN && INPUT
> default y
> select XEN_XENBUS_FRONTEND
> help
> 
> 
> Do you have a kernel config with INPUT=m that I can use to test with?

You can easily set that in any config if you disable CONFIG_VT. I don't
think it's worth spending more time on that, as everyone seems to be
happy with just removing the 'select', and I've sent a replacement
patch to do that.

Arnd

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

[Xen-devel] [PATCH OSSTEST] crontab: Add a coverity run on a Wednesday

[Ian Campbell]

In addition to the current Sunday run.

Projects of Xen's size are currently allowed 2 builds per week (max 1
per day), so make use of both.

Signed-off-by: Ian Campbell 
---
This change is already live in the production colo
---
 crontab | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crontab b/crontab
index f83e494..2cfad74 100755
--- a/crontab
+++ b/crontab
@@ -8,7 +8,7 @@ MAILTO=ian.jack...@citrix.com,ian.campb...@eu.citrix.com
 0  *   * * *   cd testing.git && 
BRANCHES=xen-unstable-smoke   ./cr-for-branches branches -q "./cr-daily-branch 
--real"
 4-59/30*   * * *   cd testing.git &&   
./cr-for-branches branches -q "./cr-daily-branch --real"
 18 9   * * 1,3,5   cd testing.git && BRANCHES=linux-next   
./cr-for-branches branches -w "./cr-daily-branch --real"
-18 9   * * 7   cd testing.git && 
BRANCHES=xen-unstable-coverity ./cr-for-branches branches -w "./cr-daily-branch 
--real"
+18 9   * * 3,7 cd testing.git && 
BRANCHES=xen-unstable-coverity ./cr-for-branches branches -w "./cr-daily-branch 
--real"
 18 4   * * *   cd testing.git && BRANCHES='linux-linus 
linux-mingo-tip-master linux-3.0 libvirt rumpuserxen' ./cr-for-branches 
branches -w "./cr-daily-branch --real"
 6-59/15*   * * *   cd testing.git && 
EXTRA_BRANCHES='linux-linus linux-3.0 rumpuserxen libvirt' ./cr-for-branches 
bisects -w "./cr-try-bisect --real"
 #8-59/5*   * * *   cd bisects/adhoc.git && 
with-lock-ex -q data-tree-lock bash -c "./cr-try-bisect-adhoc; exit $?"
-- 
2.6.1


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

[Xen-devel] [PATCH v2] xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"

[Arnd Bergmann]

The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:

drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'

This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.

Signed-off-by: Arnd Bergmann 
Suggested-by: David Vrabel 
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5cd806..d889ef2048df 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2246,7 +2246,6 @@ config XEN_FBDEV_FRONTEND
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
-   select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
select XEN_XENBUS_FRONTEND
default y
help


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

Re: [Xen-devel] [PATCH v2] public/io/netif.h: make control ring hash protocol more general

[Ian Campbell]

On Tue, 2016-02-16 at 14:17 +, Paul Durrant wrote:
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: 16 February 2016 14:13
> > To: Paul Durrant; xen-de...@lists.xenproject.org
> > Cc: Ian Jackson; Jan Beulich; Keir (Xen.org); Tim (Xen.org)
> > Subject: Re: [PATCH v2] public/io/netif.h: make control ring hash
> > protocol
> > more general
> > 
> > On Tue, 2016-02-16 at 14:02 +, Paul Durrant wrote:
> > > > -Original Message-
> > > [snip]
> > > > > 
> > > > > > >   *
> > > > > > > - * NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING_ORDER
> > > > > > > - * --
> > > > > > > + * NETIF_CTRL_TYPE_SET_HASH_MAPPING_ORDER
> > > > > > 
> > > > > > This one needs a similar "if the hash algorithm requires it"
> > > > > > wording
> > > > > > like the setting the key one had.
> > > > > > 
> > > > > 
> > > > > Why? Is there any point of doing hashing at all if the backend is
> > > > > not
> > > > > going to map it to a queue via a mapping table?
> > > > 
> > > > But will all hashing algorithms work via a table with a variable
> > > > order?
> > > > 
> > > 
> > > My view is that the algorithm used to generate the hash (which is
> > > after
> > > all just a number) and then mapping that hash to a queue via a table
> > > are
> > > pretty separate. Do you have an example in mind where these things
> > > are
> > > more intertwined? (Maybe my view is too simplistic).
> > 
> > I don't know of a specific example, but was just trying to generalise
> > along
> > the lines this was already heading in order to avoid future headaches
> > when
> > trying to add new (perhaps not yet invented) schemes, e.g. to
> > algorithms
> > with fixed numbers of queues, which support non-power of two table
> > sizes
> > or
> > which take the hash output mod N as the queue number without passing
> > via
> > a
> > table lookup phase etc.
> 
> I could change things to allow for a non power-of-two hash table now, so
> I'll do that so as not to rule it out. And with that, of course, you can
> provide a table to give a simple hash-mod-N mapping.

I was envisaging something the other way round i.e. a hash which hardcoded
that hash-mod-N mapping, i.e. where it would be an error to try and set
some other table or arguably to permit setting any table at all even if it
happened to be 1:1 (since making the b/e for such an algorithm check seems
like unnecessary overhead/complexity).

Ian.

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

Re: [Xen-devel] [PATCH v2] public/io/netif.h: make control ring hash protocol more general

[Paul Durrant]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 16 February 2016 14:13
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Ian Jackson; Jan Beulich; Keir (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v2] public/io/netif.h: make control ring hash protocol
> more general
> 
> On Tue, 2016-02-16 at 14:02 +, Paul Durrant wrote:
> > > -Original Message-
> > [snip]
> > > >
> > > > > >   *
> > > > > > - * NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING_ORDER
> > > > > > - * --
> > > > > > + * NETIF_CTRL_TYPE_SET_HASH_MAPPING_ORDER
> > > > >
> > > > > This one needs a similar "if the hash algorithm requires it"
> > > > > wording
> > > > > like the setting the key one had.
> > > > >
> > > >
> > > > Why? Is there any point of doing hashing at all if the backend is not
> > > > going to map it to a queue via a mapping table?
> > >
> > > But will all hashing algorithms work via a table with a variable order?
> > >
> >
> > My view is that the algorithm used to generate the hash (which is after
> > all just a number) and then mapping that hash to a queue via a table are
> > pretty separate. Do you have an example in mind where these things are
> > more intertwined? (Maybe my view is too simplistic).
> 
> I don't know of a specific example, but was just trying to generalise along
> the lines this was already heading in order to avoid future headaches when
> trying to add new (perhaps not yet invented) schemes, e.g. to algorithms
> with fixed numbers of queues, which support non-power of two table sizes
> or
> which take the hash output mod N as the queue number without passing via
> a
> table lookup phase etc.

I could change things to allow for a non power-of-two hash table now, so I'll 
do that so as not to rule it out. And with that, of course, you can provide a 
table to give a simple hash-mod-N mapping.

  Paul

> 
> I was concerned about retro fitting such things, but now I think about it
> that would involve adding a new hash type and perhaps new ops for the
> parameters of that hash, at which point the table size op could become
> optional based on the hash type at that point too, without causing any
> forward/backward compatibility concerns.
> 
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] public/io/netif.h: make control ring hash protocol more general

[Paul Durrant]

> -Original Message-
[snip]
> >
> > > >   *
> > > > - * NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING_ORDER
> > > > - * --
> > > > + * NETIF_CTRL_TYPE_SET_HASH_MAPPING_ORDER
> > >
> > > This one needs a similar "if the hash algorithm requires it" wording
> > > like the setting the key one had.
> > >
> >
> > Why? Is there any point of doing hashing at all if the backend is not
> > going to map it to a queue via a mapping table?
> 
> But will all hashing algorithms work via a table with a variable order?
> 

My view is that the algorithm used to generate the hash (which is after all 
just a number) and then mapping that hash to a queue via a table are pretty 
separate. Do you have an example in mind where these things are more 
intertwined? (Maybe my view is too simplistic).

  Paul

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

Re: [Xen-devel] [PATCH v2 17/30] x86/cpu: Common infrastructure for levelling context switching

[Jan Beulich]

>>> On 05.02.16 at 14:42,  wrote:
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -574,6 +574,34 @@ void microcode_set_module(unsigned int);
>  int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len);
>  int microcode_resume_cpu(unsigned int cpu);
>  
> +#define LCAP_faulting (1U << 0)
> +#define LCAP_1cd  (3U << 1)
> +#define LCAP_e1cd (3U << 3)
> +#define LCAP_Da1  (1U << 5)
> +#define LCAP_6c   (1U << 6)
> +#define LCAP_7ab0 (3U << 7)

I guess the cases where the mask has two set bits is when two
CPUID output registers are being controlled, but I don't see
what use that pairing is going to be. But with the patch
supposedly going to make sense only in the context of the
following ones, I'll see (and I'd presumably be able to ack this
one then also only when having seen the others).

Jan


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

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

[osstest service owner]

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

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-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 82689
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 80752 pass 
in 82689
 test-armhf-armhf-xl-credit2  11 guest-startfail in 82560 pass in 82689
 test-armhf-armhf-xl-xsm  11 guest-startfail in 82560 pass in 82689
 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
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail pass in 82560

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-i386-xl-qemut-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-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 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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-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-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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-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   62 days
Failing since 78925  2016-01-24 13:50:39 Z   23 days   23 attempts
Testing same since79642  2016-01-31 21:28:16 Z   15 days   14 attempts


People who touched revisions under test:
  

Re: [Xen-devel] [PATCH v2] public/io/netif.h: make control ring hash protocol more general

[Ian Campbell]

On Tue, 2016-02-16 at 14:02 +, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > > 
> > > > >   *
> > > > > - * NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING_ORDER
> > > > > - * --
> > > > > + * NETIF_CTRL_TYPE_SET_HASH_MAPPING_ORDER
> > > > 
> > > > This one needs a similar "if the hash algorithm requires it"
> > > > wording
> > > > like the setting the key one had.
> > > > 
> > > 
> > > Why? Is there any point of doing hashing at all if the backend is not
> > > going to map it to a queue via a mapping table?
> > 
> > But will all hashing algorithms work via a table with a variable order?
> > 
> 
> My view is that the algorithm used to generate the hash (which is after
> all just a number) and then mapping that hash to a queue via a table are
> pretty separate. Do you have an example in mind where these things are
> more intertwined? (Maybe my view is too simplistic).

I don't know of a specific example, but was just trying to generalise along
the lines this was already heading in order to avoid future headaches when
trying to add new (perhaps not yet invented) schemes, e.g. to algorithms
with fixed numbers of queues, which support non-power of two table sizes or
which take the hash output mod N as the queue number without passing via a
table lookup phase etc.

I was concerned about retro fitting such things, but now I think about it
that would involve adding a new hash type and perhaps new ops for the
parameters of that hash, at which point the table size op could become
optional based on the hash type at that point too, without causing any
forward/backward compatibility concerns.

Ian.

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

Re: [Xen-devel] [PATCH v2 16/30] x86/cpu: Move set_cpumask() calls into c_early_init()

[Jan Beulich]

>>> On 05.02.16 at 14:42,  wrote:
> Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
> commandline-provided masks would take effect in Xen's view of the features.
> 
> As the masks got applied after the query for features, the redundant call to
> generic_identify() would clobber the pre-masking feature information with the
> post-masking information.
> 
> Move the set_cpumask() calls into c_early_init() so their effects take place
> before the main query for features in generic_identify().
> 
> The cpuid_mask_* command line parameters now limit the entire system, a
> feature XenServer was relying on for testing purposes.

And I continue to view this as a step backwards, and hence can't
really approve of this change. And XenServer relying on this for
whatever purposes is hardly a good argument here.

Jan


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

Re: [Xen-devel] [PATCH] xen: make some constants usable for assembler

[Juergen Gross]

On 16/02/16 15:04, Jan Beulich wrote:
 On 16.02.16 at 14:02,  wrote:
>> Some constants defined in xen/include/public/xen.h are not usable in
>> assembler sources as they are either defined with "U" or "UL" suffixes
>> or they are inside #ifndef __ASSEMBLY__ areas.
>>
>> Change this as grub2 could make use of those definitions.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  xen/include/public/xen.h | 58 
>> ++--
>>  1 file changed, 31 insertions(+), 27 deletions(-)
>>
>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> index 7b629b1..e29a12a 100644
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -52,6 +52,19 @@ DEFINE_XEN_GUEST_HANDLE(void);
>>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
>>  DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>>  DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>> +
>> +/* Turn a plain number into a C unsigned (long) constant. */
>> +#define __mk_unsigned(x)  x ## U
>> +#define __mk_unsigned_long(x) x ## UL
>> +#define mk_unsigned(x)__mk_unsigned(x)
>> +#define mk_unsigned_long(x)   __mk_unsigned_long(x)
>> +
>> +#else
>> +
>> +/* In assembly code we cannot use C numeric constant suffixes. */
>> +#define mk_unsigned(x)  x
>> +#define mk_unsigned_long(x) x
>> +
>>  #endif
> 
> I realize that you're just moving up the mis-named
> mk_unsigned_long(). That alone I guess we'd have to tolerate, but
> since you also add another variant thereof, the name space issue
> needs fixing imo (even more so since they can't be #undef-d at the
> end of the header): Both should carry Xen in their name in some
> way. Maybe xen_mk_uint() and xen_mk_ulong()?

I'm fine with this.

> 
>> @@ -451,13 +464,13 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>>  /* When specifying UVMF_MULTI, also OR in a pointer to a CPU bitmap.   */
>>  /* UVMF_LOCAL is merely UVMF_MULTI with a NULL bitmap pointer. */
>>  /* ` enum uvm_flags { */
>> -#define UVMF_NONE   (0UL<<0) /* No flushing at all.   */
>> -#define UVMF_TLB_FLUSH  (1UL<<0) /* Flush entire TLB(s).  */
>> -#define UVMF_INVLPG (2UL<<0) /* Flush only one entry. */
>> -#define UVMF_FLUSHTYPE_MASK (3UL<<0)
>> -#define UVMF_MULTI  (0UL<<2) /* Flush subset of TLBs. */
>> -#define UVMF_LOCAL  (0UL<<2) /* Flush local TLB.  */
>> -#define UVMF_ALL(1UL<<2) /* Flush all TLBs.   */
>> +#define UVMF_NONEmk_unsigned_long(0<<0) /* No flushing at all.  
>>  */
>> +#define UVMF_TLB_FLUSH   mk_unsigned_long(1<<0) /* Flush entire TLB(s). 
>>  */
>> +#define UVMF_INVLPG  mk_unsigned_long(2<<0) /* Flush only one 
>> entry. */
>> +#define UVMF_FLUSHTYPE_MASK  mk_unsigned_long(3<<0)
>> +#define UVMF_MULTI   mk_unsigned_long(0<<2) /* Flush subset of 
>> TLBs. */
>> +#define UVMF_LOCAL   mk_unsigned_long(0<<2) /* Flush local TLB. 
>>  */
>> +#define UVMF_ALL mk_unsigned_long(1<<2) /* Flush all TLBs.  
>>  */
> 
> These all look wrong - I think you mean
> 
> #define UVMF_ALL (mk_unsigned_long(1)<<2)
> 
> etc, even if the difference is benign.

Oops, you are right. Sorry.

> 
>> @@ -504,15 +517,11 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>>  #define MAX_VMASST_TYPE  3
>>  #endif
>>  
>> -#ifndef __ASSEMBLY__
>> -
>> -typedef uint16_t domid_t;
>> -
>>  /* Domain ids >= DOMID_FIRST_RESERVED cannot be used for ordinary domains. 
>> */
>> -#define DOMID_FIRST_RESERVED (0x7FF0U)
>> +#define DOMID_FIRST_RESERVED mk_unsigned(0x7FF0)
>>  
>>  /* DOMID_SELF is used in certain contexts to refer to oneself. */
>> -#define DOMID_SELF (0x7FF0U)
>> +#define DOMID_SELF   mk_unsigned(0x7FF0)
>>  
>>  /*
>>   * DOMID_IO is used to restrict page-table updates to mapping I/O memory.
>> @@ -523,7 +532,7 @@ typedef uint16_t domid_t;
>>   * This only makes sense in MMUEXT_SET_FOREIGNDOM, but in that context can
>>   * be specified by any calling domain.
>>   */
>> -#define DOMID_IO   (0x7FF1U)
>> +#define DOMID_IO mk_unsigned(0x7FF1)
>>  
>>  /*
>>   * DOMID_XEN is used to allow privileged domains to map restricted parts of
>> @@ -531,17 +540,21 @@ typedef uint16_t domid_t;
>>   * This only makes sense in MMUEXT_SET_FOREIGNDOM, and is only permitted if
>>   * the caller is privileged.
>>   */
>> -#define DOMID_XEN  (0x7FF2U)
>> +#define DOMID_XENmk_unsigned(0x7FF2)
>>  
>>  /*
>>   * DOMID_COW is used as the owner of sharable pages */
>> -#define DOMID_COW  (0x7FF3U)
>> +#define DOMID_COWmk_unsigned(0x7FF3)
>>  
>>  /* DOMID_INVALID is used to identify pages with unknown owner. */
>> -#define DOMID_INVALID (0x7FF4U)
>> +#define DOMID_INVALIDmk_unsigned(0x7FF4)
>>  
>>  /* Idle domain. */
>> -#define DOMID_IDLE (0x7FFFU)
>> +#define DOMID_IDLE   mk_unsigned(0x7FFF)
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +typedef uint16_t domid_t;
> 
> It's hard to see why domain