Re: [Xen-devel] [CALL-FOR-AGENDA] Monthly Xen.org Technical Call (2015-10-14)

[Ian Campbell]

On Mon, 2015-10-12 at 09:38 +0100, Ian Campbell wrote:
> The next Xen technical call will be at:
> Wed 14 Oct 17:00:00 BST 2015
> `date -d @1444838400`

No agenda => no call.



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

Re: [Xen-devel] [PATCH QEMU-XEN v3 6/8] xen: Use stable library interfaces when they are available.

[Stefano Stabellini]

On Wed, 7 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
> 
> Specifically libxenevtchn, libxengnttab and libxenforeignmemory.
> 
> Previous patches have already laid the groundwork for using these by
> switching the existing compatibility shims to reflect the intefaces to
> these libraries.
> 
> So all which remains is to update configure to detect the libraries
> and enable their use. Although they are notionally independent we take
> an all or nothing approach to the three libraries since they were
> added at the same time.
> 
> The only non-obvious bit is that we now open a proper xenforeignmemory
> handle for xen_fmem instead of reusing the xen_xc handle.
> 
> Build tested with 4.0, 4.5 and the patches targetting 4.7 which adds
> these libraries.
> 
> Signed-off-by: Ian Campbell 
> ---
>  configure   | 98 
> -
>  include/hw/xen/xen_common.h | 42 ++-
>  xen-common.c|  9 +
>  3 files changed, 145 insertions(+), 4 deletions(-)
> 
> diff --git a/configure b/configure
> index 779623a..508b157 100755
> --- a/configure
> +++ b/configure
> @@ -1839,6 +1839,52 @@ fi
>  # xen probe
>  
>  if test "$xen" != "no" ; then
> +  xenevtchn_libs="-lxenevtchn"
> +
> +  cat > $TMPC < +#include 
> +int main(void) { return 0; }
> +EOF
> +  if compile_prog "" "$xenevtchn_libs" ; then
> +  xenevtchn=yes
> +  else
> +  xenevtchn=no
> +  fi
> +
> +  xengnttab_libs="-lxengnttab"
> +
> +  cat > $TMPC < +#include 
> +int main(void) { return 0; }
> +EOF
> +  if compile_prog "" "$xengnttab_libs" ; then
> +  xengnttab=yes
> +  else
> +  xengnttab=no
> +  fi
> +
> +  xenforeignmemory_libs="-lxenforeignmemory"
> +
> +  cat > $TMPC < +#include 
> +int main(void) { return 0; }
> +EOF
> +  if compile_prog "" "$xenforeignmemory_libs" ; then
> +  xenforeignmemory=yes
> +  else
> +  xenforeignmemory=no
> +  fi
> +
> +  # These libraries were all introduced in the same release, to
> +  # simplify things we therefore assume its either all or nothing and
> +  # treat any other mix as an error
> +  case $xenevtchn$xengnttab$xenforeignmemory in
> +  yesyesyes) xenstablelibs=yes;;
> +  nonono)xenstablelibs=no;;
> +  *) error_exit "Inconsistent set of xen libraries found"
> +   ;;
> +  esac

I would remove all this and introduce a xen_stable_libs for the Xen 4.7
and beyond case:

xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"


>xen_libs="-lxenstore -lxenctrl -lxenguest"
>  
># First we test whether Xen headers and libraries are available.
> @@ -1859,7 +1905,46 @@ EOF
>  fi
>  xen=no
>  
> -  # Xen unstable
> +  # Xen unstable (with stable libs)
> +  elif
> +  # If we have stable libs the we don't want the libxc compat
> +  # layers, regardless of what CFLAGS we may have been given.
> +  test "$xenstablelibs" = "yes" &&
> +  cat > $TMPC < +#undef XC_WANT_COMPAT_EVTCHN_API
> +#undef XC_WANT_COMPAT_GNTTAB_API
> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +#include 
> +#include 
> +#include 
> +#include 
> +#if !defined(HVM_MAX_VCPUS)
> +# error HVM_MAX_VCPUS not defined
> +#endif
> +int main(void) {
> +  xc_interface *xc;
> +  xs_daemon_open();
> +  xc = xc_interface_open(0, 0, 0);
> +  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
> +  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
> +  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
> +  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);

I would add some of the new function calls here.


> +  return 0;
> +}
> +EOF
> +  compile_prog "" "$xen_libs"

  ^ xen_stable_libs

> +  then
> +xen_ctrl_version=470
> +xen=yes
> +
> +  # Xen unstable (without stable libs)

I would ignore this case completely.


> +  elif
> +  test "$xenstablelibs" = "yes"
> +  then
> +  # Inconsistent result, split libs but an older libxenctrl interface?
> +  xen=no
> +
> +  # Xen 4.6
>elif
>cat > $TMPC <  #include 
> @@ -2037,6 +2122,11 @@ EOF
>fi
>  
>if test "$xen" = yes; then
> +if test "$xenstablelibs" = yes; then
> +  libs_softmmu="$xenevtchn_libs $libs_softmmu"
> +  libs_softmmu="$xengnttab_libs $libs_softmmu"
> +  libs_softmmu="$xenforeignmemory_libs $libs_softmmu"
> +fi
>  libs_softmmu="$xen_libs $libs_softmmu"
>fi
>  fi
> @@ -4337,7 +4427,8 @@ if test -n "$sparc_cpu"; then
>  fi
>  echo "xen support   $xen"
>  if test "$xen" = "yes" ; then
> -  echo "xen ctrl version  $xen_ctrl_version"
> +  echo "  stable libs $xenstablelibs"
> +  echo "  ctrl version$xen_ctrl_version"

I don't think is necessary to print something here


>  fi
>  echo "brlapi support$brlapi"
>  echo "bluez  support$bluez"
> @@ -4670,6 +4761,9 @@ fi
>  if 

[Xen-devel] [PATCH v2 3/6] xen: sched: clarify use cases of schedule_cpu_switch()

[Dario Faggioli]

schedule_cpu_switch() is meant to be only used for moving
pCPUs from a cpupool to no cpupool, and from there back
to a cpupool, *not* to move them directly from one cpupool
to another.

This is something that is reflected in the way it is
implemented, and should be kept in mind when looking at
it. However, that is not that clear, by just the look of
it.

Make it more evident by adding commentary and ASSERT()s.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Juergen Gross 
Cc: Jan Beulich 
---
Changes from v1:
 * new patch, was not there in v1.
---
 xen/common/schedule.c |   28 
 1 file changed, 28 insertions(+)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 9aa209d..5ebfa33 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1486,12 +1486,40 @@ void __init scheduler_init(void)
 BUG();
 }
 
+/*
+ * Move a pCPU outside of the influence of the scheduler of its current
+ * cpupool, or subject it to the scheduler of a new cpupool.
+ *
+ * For the pCPUs that are removed from their cpupool, their scheduler becomes
+ *  (the default scheduler, selected at boot, which also services the
+ * default cpupool). However, as these pCPUs are not really part of any pool,
+ * there won't be any scheduling event on them, not even from the default
+ * scheduler. Basically, they will just sit idle until they are explicitly
+ * added back to a cpupool.
+ */
 int schedule_cpu_switch(unsigned int cpu, struct cpupool *c)
 {
 struct vcpu *idle;
 void *ppriv, *ppriv_old, *vpriv, *vpriv_old;
 struct scheduler *old_ops = per_cpu(scheduler, cpu);
 struct scheduler *new_ops = (c == NULL) ?  : c->sched;
+struct cpupool *pool = per_cpu(cpupool, cpu);
+
+/*
+ * pCPUs only move from a valid cpupool to free (i.e., out of any pool),
+ * or from free to a valid cpupool. In the former case (which happens when
+ * c is NULL), we want the CPU to have been marked as free already, as
+ * well as to not be valid for the source pool any longer, when we get to
+ * here. In the latter case (which happens when c is a valid cpupool), we
+ * want the CPU to still be marked as free, as well as to not yet be valid
+ * for the destination pool.
+ * This all is because we do not want any scheduling activity on the CPU
+ * while, in here, we switch things over.
+ */
+ASSERT(c != NULL || pool != NULL);
+ASSERT(cpumask_test_cpu(cpu, _free_cpus));
+ASSERT((c == NULL && !cpumask_test_cpu(cpu, pool->cpu_valid)) ||
+   (c != NULL && !cpumask_test_cpu(cpu, c->cpu_valid)));
 
 if ( old_ops == new_ops )
 return 0;


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

[Xen-devel] [PATCH v2 4/6] xen: sched: better handle (not) inserting idle vCPUs in runqueues

[Dario Faggioli]

Idle vCPUs are set to run immediately, as a part of their
own initialization, so we shouldn't even try to put them
in a runqueue. In fact, actual schedulers don't do that,
even when asked to (that is rather explicit in Credit2
and RTDS, a bit less evident in Credit1).

Let's make things look as follows:
 - in generic code, explicitly avoid even trying to
   insert idle vcpus in runqueues;
 - in specific schedulers' code, enforce that.

Note that, as csched_vcpu_insert() is no longer being
called, during boot, from sched_init_vcpu(), we can
safely avoid saving the flags when taking the runqueue
lock.

Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 
Reviewed-by: Juergen Gross 
---
Changes from v1:
 * changelog: updated and made a little bit less verbose.
---
 xen/common/sched_credit.c  |7 ---
 xen/common/sched_credit2.c |   25 ++---
 xen/common/sched_rt.c  |4 +---
 xen/common/schedule.c  |   21 +++--
 4 files changed, 26 insertions(+), 31 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index e16bd3a..fc447a7 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -904,14 +904,15 @@ csched_vcpu_insert(const struct scheduler *ops, struct 
vcpu *vc)
 {
 struct csched_vcpu *svc = vc->sched_priv;
 spinlock_t *lock;
-unsigned long flags;
 
-lock = vcpu_schedule_lock_irqsave(vc, );
+BUG_ON( is_idle_vcpu(vc) );
+
+lock = vcpu_schedule_lock_irq(vc);
 
 if ( !__vcpu_on_runq(svc) && vcpu_runnable(vc) && !vc->is_running )
 __runq_insert(vc->processor, svc);
 
-vcpu_schedule_unlock_irqrestore(lock, flags, vc);
+vcpu_schedule_unlock_irq(lock, vc);
 
 SCHED_STAT_CRANK(vcpu_insert);
 }
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 6695729..59da919 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -870,30 +870,25 @@ csched2_vcpu_insert(const struct scheduler *ops, struct 
vcpu *vc)
 {
 struct csched2_vcpu *svc = vc->sched_priv;
 struct csched2_dom * const sdom = svc->sdom;
+spinlock_t *lock;
 
 printk("%s: Inserting %pv\n", __func__, vc);
 
-/* NB: On boot, idle vcpus are inserted before alloc_pdata() has
- * been called for that cpu.
- */
-if ( ! is_idle_vcpu(vc) )
-{
-spinlock_t *lock;
+BUG_ON(is_idle_vcpu(vc));
 
-/* FIXME: Do we need the private lock here? */
-list_add_tail(>sdom_elem, >sdom->vcpu);
+/* FIXME: Do we need the private lock here? */
+list_add_tail(>sdom_elem, >sdom->vcpu);
 
-/* Add vcpu to runqueue of initial processor */
-lock = vcpu_schedule_lock_irq(vc);
+/* Add vcpu to runqueue of initial processor */
+lock = vcpu_schedule_lock_irq(vc);
 
-runq_assign(ops, vc);
+runq_assign(ops, vc);
 
-vcpu_schedule_unlock_irq(lock, vc);
+vcpu_schedule_unlock_irq(lock, vc);
 
-sdom->nr_vcpus++;
+sdom->nr_vcpus++;
 
-SCHED_STAT_CRANK(vcpu_insert);
-}
+SCHED_STAT_CRANK(vcpu_insert);
 
 CSCHED2_VCPU_CHECK(vc);
 }
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 1086399..37a32a4 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -624,9 +624,7 @@ rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
 s_time_t now = NOW();
 spinlock_t *lock;
 
-/* not addlocate idle vcpu to dom vcpu list */
-if ( is_idle_vcpu(vc) )
-return;
+BUG_ON( is_idle_vcpu(vc) );
 
 lock = vcpu_schedule_lock_irq(vc);
 if ( now >= svc->cur_deadline )
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 5ebfa33..73114c5 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -240,20 +240,22 @@ int sched_init_vcpu(struct vcpu *v, unsigned int 
processor)
 init_timer(>poll_timer, poll_timer_fn,
v, v->processor);
 
-/* Idle VCPUs are scheduled immediately. */
+v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv);
+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) )
 {
 per_cpu(schedule_data, v->processor).curr = v;
 v->is_running = 1;
 }
-
-TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id);
-
-v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv);
-if ( v->sched_priv == NULL )
-return 1;
-
-SCHED_OP(DOM2OP(d), insert_vcpu, v);
+else
+{
+SCHED_OP(DOM2OP(d), insert_vcpu, v);
+}
 
 return 0;
 }
@@ -1542,7 +1544,6 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool 
*c)
 ppriv_old = per_cpu(schedule_data, cpu).sched_priv;
 per_cpu(schedule_data, cpu).sched_priv = ppriv;
 SCHED_OP(new_ops, 

[Xen-devel] [PATCH v2 6/6] xen: sched: get rid of the per domain vCPU list in Credit2

[Dario Faggioli]

As, curently, there is no reason for bothering having
it and keeping it updated.

In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.

While there, improve alignment of comments, ad
add a const qualifier to a pointer, making things
more consistent with what happens everywhere else
in the source file.

This also allows us to kill one of the remaining
FIXMEs in the code, which is always good.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Andrew Cooper 
---
Changes from v1:
 * removed spurious hunk about sched_rt.c, as noted
   during review;
 * fixed the BUG_ON inside csched2_dom_destroy(), as
   noted during review;
 * used 'v' instead of 'vc' for 'vcpu' (in new code),
   as suggested during review.
---
Not applying the review tags, as the patch changed a little
bit.
---
 xen/common/sched_credit2.c |   34 +++---
 1 file changed, 11 insertions(+), 23 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 59da919..df85ecd 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -234,9 +234,8 @@ struct csched2_private {
  * Virtual CPU
  */
 struct csched2_vcpu {
-struct list_head rqd_elem;  /* On the runqueue data list */
-struct list_head sdom_elem; /* On the domain vcpu list */
-struct list_head runq_elem; /* On the runqueue */
+struct list_head rqd_elem; /* On the runqueue data list  */
+struct list_head runq_elem;/* On the runqueue*/
 struct csched2_runqueue_data *rqd; /* Up-pointer to the runqueue */
 
 /* Up-pointers */
@@ -261,7 +260,6 @@ struct csched2_vcpu {
  * Domain
  */
 struct csched2_dom {
-struct list_head vcpu;
 struct list_head sdom_elem;
 struct domain *dom;
 uint16_t weight;
@@ -772,7 +770,6 @@ csched2_alloc_vdata(const struct scheduler *ops, struct 
vcpu *vc, void *dd)
 return NULL;
 
 INIT_LIST_HEAD(>rqd_elem);
-INIT_LIST_HEAD(>sdom_elem);
 INIT_LIST_HEAD(>runq_elem);
 
 svc->sdom = dd;
@@ -876,9 +873,6 @@ csched2_vcpu_insert(const struct scheduler *ops, struct 
vcpu *vc)
 
 BUG_ON(is_idle_vcpu(vc));
 
-/* FIXME: Do we need the private lock here? */
-list_add_tail(>sdom_elem, >sdom->vcpu);
-
 /* Add vcpu to runqueue of initial processor */
 lock = vcpu_schedule_lock_irq(vc);
 
@@ -923,10 +917,6 @@ csched2_vcpu_remove(const struct scheduler *ops, struct 
vcpu *vc)
 
 vcpu_schedule_unlock_irq(lock, vc);
 
-/* Remove from sdom list.  Don't need a lock for this, as it's called
- * syncronously when nothing else can happen. */
-list_del_init(>sdom_elem);
-
 svc->sdom->nr_vcpus--;
 }
 }
@@ -1443,7 +1433,7 @@ csched2_dom_cntl(
 
 if ( op->u.credit2.weight != 0 )
 {
-struct list_head *iter;
+struct vcpu *v;
 int old_weight;
 
 old_weight = sdom->weight;
@@ -1451,9 +1441,9 @@ csched2_dom_cntl(
 sdom->weight = op->u.credit2.weight;
 
 /* Update weights for vcpus, and max_weight for runqueues on which 
they reside */
-list_for_each ( iter, >vcpu )
+for_each_vcpu ( d, v )
 {
-struct csched2_vcpu *svc = list_entry(iter, struct 
csched2_vcpu, sdom_elem);
+struct csched2_vcpu *svc = CSCHED2_VCPU(v);
 
 /* NB: Locking order is important here.  Because we grab this 
lock here, we
  * must never lock csched2_priv.lock if we're holding a 
runqueue lock.
@@ -1487,7 +1477,6 @@ csched2_alloc_domdata(const struct scheduler *ops, struct 
domain *dom)
 return NULL;
 
 /* Initialize credit and weight */
-INIT_LIST_HEAD(>vcpu);
 INIT_LIST_HEAD(>sdom_elem);
 sdom->dom = dom;
 sdom->weight = CSCHED2_DEFAULT_WEIGHT;
@@ -1539,9 +1528,7 @@ csched2_free_domdata(const struct scheduler *ops, void 
*data)
 static void
 csched2_dom_destroy(const struct scheduler *ops, struct domain *dom)
 {
-struct csched2_dom *sdom = CSCHED2_DOM(dom);
-
-BUG_ON(!list_empty(>vcpu));
+BUG_ON(CSCHED2_DOM(dom)->nr_vcpus > 0);
 
 csched2_free_domdata(ops, CSCHED2_DOM(dom));
 }
@@ -1881,7 +1868,7 @@ csched2_dump_pcpu(const struct scheduler *ops, int cpu)
 static void
 csched2_dump(const struct scheduler *ops)
 {
-struct list_head *iter_sdom, *iter_svc;
+struct list_head *iter_sdom;
 struct csched2_private *prv = CSCHED2_PRIV(ops);
 unsigned long flags;
 int i, loop;
@@ -1926,6 +1913,8 @@ csched2_dump(const struct scheduler *ops)
 list_for_each( iter_sdom, >sdom )
 {
 struct csched2_dom *sdom;
+struct vcpu *v;
+
 sdom = list_entry(iter_sdom, struct csched2_dom, sdom_elem);
 
 printk("\tDomain: %d w %d v %d\n",
@@ -1933,12 +1922,11 @@ csched2_dump(const 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-pvh-amd   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-amd64-pvgrub  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-i386-pvgrub  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 60684
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-i386-xl-raw6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-pygrub   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 60684

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl6 xen-bootfail pass in 62941
 test-amd64-i386-libvirt   6 xen-bootfail pass in 62941

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 60684
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host fail REGR. vs. 60684

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-check fail in 62941 never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux 

[Xen-devel] [PATCH v2 5/6] xen: sched: get rid of the per domain vCPU list in RTDS

[Dario Faggioli]

As, curently, there is no reason for bothering having
it and keeping it updated.

In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.

While there, take care of the case when
XEN_DOMCTL_SCHEDOP_getinfo is called but no vCPUs have
been allocated yet (by returning the default scheduling
parameters).

Signed-off-by: Dario Faggioli 
---
Cc: Meng Xu 
Cc: George Dunlap 
Cc: Andrew Cooper 
---
Changes from v1:
 * address the case when d->vcpu[] has not been allocated
   yet, as requested during review;
 * style: space before brackets of for_each_vcpu, as
   requested during review;
 * used 'v' instead of 'vc' for 'vcpu' (in new code).
---
Not applying the review tags, as the patch changed a little
bit.
---
 xen/common/sched_rt.c |   54 -
 1 file changed, 26 insertions(+), 28 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 37a32a4..3f1d047 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -160,7 +160,6 @@ struct rt_private {
  */
 struct rt_vcpu {
 struct list_head q_elem;/* on the runq/depletedq list */
-struct list_head sdom_elem; /* on the domain VCPU list */
 
 /* Up-pointers */
 struct rt_dom *sdom;
@@ -182,7 +181,6 @@ struct rt_vcpu {
  * Domain
  */
 struct rt_dom {
-struct list_head vcpu;  /* link its VCPUs */
 struct list_head sdom_elem; /* link list on rt_priv */
 struct domain *dom; /* pointer to upper domain */
 };
@@ -290,7 +288,7 @@ rt_dump_pcpu(const struct scheduler *ops, int cpu)
 static void
 rt_dump(const struct scheduler *ops)
 {
-struct list_head *iter_sdom, *iter_svc, *runq, *depletedq, *iter;
+struct list_head *runq, *depletedq, *iter;
 struct rt_private *prv = rt_priv(ops);
 struct rt_vcpu *svc;
 struct rt_dom *sdom;
@@ -319,14 +317,16 @@ rt_dump(const struct scheduler *ops)
 }
 
 printk("Domain info:\n");
-list_for_each( iter_sdom, >sdom )
+list_for_each( iter, >sdom )
 {
-sdom = list_entry(iter_sdom, struct rt_dom, sdom_elem);
+struct vcpu *v;
+
+sdom = list_entry(iter, struct rt_dom, sdom_elem);
 printk("\tdomain: %d\n", sdom->dom->domain_id);
 
-list_for_each( iter_svc, >vcpu )
+for_each_vcpu ( sdom->dom, v )
 {
-svc = list_entry(iter_svc, struct rt_vcpu, sdom_elem);
+svc = rt_vcpu(v);
 rt_dump_vcpu(ops, svc);
 }
 }
@@ -527,7 +527,6 @@ rt_alloc_domdata(const struct scheduler *ops, struct domain 
*dom)
 if ( sdom == NULL )
 return NULL;
 
-INIT_LIST_HEAD(>vcpu);
 INIT_LIST_HEAD(>sdom_elem);
 sdom->dom = dom;
 
@@ -587,7 +586,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu 
*vc, void *dd)
 return NULL;
 
 INIT_LIST_HEAD(>q_elem);
-INIT_LIST_HEAD(>sdom_elem);
 svc->flags = 0U;
 svc->sdom = dd;
 svc->vcpu = vc;
@@ -614,8 +612,7 @@ rt_free_vdata(const struct scheduler *ops, void *priv)
  * This function is called in sched_move_domain() in schedule.c
  * When move a domain to a new cpupool.
  * It inserts vcpus of moving domain to the scheduler's RunQ in
- * dest. cpupool; and insert rt_vcpu svc to scheduler-specific
- * vcpu list of the dom
+ * dest. cpupool.
  */
 static void
 rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
@@ -634,15 +631,11 @@ rt_vcpu_insert(const struct scheduler *ops, struct vcpu 
*vc)
 __runq_insert(ops, svc);
 vcpu_schedule_unlock_irq(lock, vc);
 
-/* add rt_vcpu svc to scheduler-specific vcpu list of the dom */
-list_add_tail(>sdom_elem, >sdom->vcpu);
-
 SCHED_STAT_CRANK(vcpu_insert);
 }
 
 /*
- * Remove rt_vcpu svc from the old scheduler in source cpupool; and
- * Remove rt_vcpu svc from scheduler-specific vcpu list of the dom
+ * Remove rt_vcpu svc from the old scheduler in source cpupool.
  */
 static void
 rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
@@ -659,9 +652,6 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
 if ( __vcpu_on_q(svc) )
 __q_remove(svc);
 vcpu_schedule_unlock_irq(lock, vc);
-
-if ( !is_idle_vcpu(vc) )
-list_del_init(>sdom_elem);
 }
 
 /*
@@ -1135,20 +1125,28 @@ rt_dom_cntl(
 struct xen_domctl_scheduler_op *op)
 {
 struct rt_private *prv = rt_priv(ops);
-struct rt_dom * const sdom = rt_dom(d);
 struct rt_vcpu *svc;
-struct list_head *iter;
+struct vcpu *v;
 unsigned long flags;
 int rc = 0;
 
 switch ( op->cmd )
 {
 case XEN_DOMCTL_SCHEDOP_getinfo:
-spin_lock_irqsave(>lock, flags);
-svc = list_entry(sdom->vcpu.next, struct rt_vcpu, sdom_elem);
-op->u.rtds.period = svc->period / MICROSECS(1); /* transfer to us */
-op->u.rtds.budget = svc->budget / MICROSECS(1);
-   

Re: [Xen-devel] [PATCH v7 23/32] xen/x86: make sure the HVM callback vector is correctly set

[Jan Beulich]

>>> On 02.10.15 at 17:48,  wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -330,6 +330,10 @@ void hvm_set_callback_via(struct domain *d, uint64_t 
> via)
>   (via_type > HVMIRQ_callback_vector) )
>  via_type = HVMIRQ_callback_none;
>  
> +if ( via_type != HVMIRQ_callback_vector &&
> + (!has_vlapic(d) || !has_vioapic(d) || !has_vpic(d)) )
> +return;

Why are both IO-APIC and PIC required? Doesn't one suffice, or
can't MSI-like interrupts even get delivered without either?

Jan


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

Re: [Xen-devel] [PATCH QEMU-XEN v3 7/8] xen: domainbuild: reopen libxenctrl interface after forking for domain watcher.

[Stefano Stabellini]

On Wed, 7 Oct 2015, Ian Campbell wrote:
> Using an existing libxenctrl handle after a fork was never
> particularly safe (especially if foreign mappings existed at the time
> of the fork) and the xc fd has been unavailable for many releases.
> 
> Reopen the handle after fork and therefore do away with xc_fd().
> 
> Signed-off-by: Ian Campbell 
>
> The fact that xc_fd hasn't been useful since at least Xen 4.1 makes me
> question the utility of this domainbuild in QEMU. Perhaps we should
> just nuke it?

Indeed

Acked-by: Stefano Stabellini 

>  hw/xenpv/xen_domainbuild.c  |  9 ++---
>  include/hw/xen/xen_common.h | 17 -
>  2 files changed, 6 insertions(+), 20 deletions(-)
> 
> diff --git a/hw/xenpv/xen_domainbuild.c b/hw/xenpv/xen_domainbuild.c
> index c0ab753..3e8422f 100644
> --- a/hw/xenpv/xen_domainbuild.c
> +++ b/hw/xenpv/xen_domainbuild.c
> @@ -174,12 +174,15 @@ static int xen_domain_watcher(void)
>  for (i = 3; i < n; i++) {
>  if (i == fd[0])
>  continue;
> -if (i == xc_fd(xen_xc)) {
> -continue;
> -}
>  close(i);
>  }
>  
> +/*
> + * Reopen xc interface, since the original is unsafe after fork
> + * and was closed above.
> + */
> +xen_xc = xc_interface_open(0, 0, 0);
> +
>  /* ignore term signals */
>  signal(SIGINT,  SIG_IGN);
>  signal(SIGTERM, SIG_IGN);
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 1b824aa..a7c1ca0 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -116,12 +116,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
> void *dombuild_logger,
>  #define xenforeignmemory_map(h,d,p,a,e,n) xc_map_foreign_bulk(*h,d,p,a,e,n)
>  #define xenforeignmemory_unmap(h,p,s) munmap(p, s)
>  
> -static inline int xc_fd(int xen_xc)
> -{
> -return xen_xc;
> -}
> -
> -
>  static inline int xc_domain_populate_physmap_exact
>  (XenXC xc_handle, uint32_t domid, unsigned long nr_extents,
>   unsigned int extent_order, unsigned int mem_flags, xen_pfn_t 
> *extent_start)
> @@ -193,11 +187,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
> void *dombuild_logger,
>  #define xenforeignmemory_map(h,d,p,a,e,n) xc_map_foreign_bulk(*h,d,p,a,e,n)
>  #define xenforeignmemory_unmap(h,p,s) munmap(p, s)
>  
> -/* FIXME There is now way to have the xen fd */
> -static inline int xc_fd(xc_interface *xen_xc)
> -{
> -return -1;
> -}
>  #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470 */
>  
>  #ifndef CONFIG_XEN_STABLE_LIBS
> @@ -219,12 +208,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
> void *dombuild_logger,
>  return xc_interface_open(logger, dombuild_logger, open_flags);
>  }
>  
> -/* FIXME There is now way to have the xen fd */
> -static inline int xc_fd(xc_interface *xen_xc)
> -{
> -return -1;
> -}
> -
>  #endif
>  
>  /* Xen before 4.2 */
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] Xen 4.6, OVMF and arm64

[Ian Campbell]

On Wed, 2015-10-14 at 15:11 +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, Ian Campbell wrote:
> > On Wed, 2015-10-14 at 14:51 +0100, Stefano Stabellini wrote:
> > > I am very practical in this regard and I just don't want the raisin
> > > build to fail on arm64 with xen 4.6.  We could have a different
> > > raisin
> > > config file, with a different ovmf revision for Xen 4.6 on arm64, but
> > > I
> > > would prefer to avoid it: I think it is nicer and simpler if one
> > > config
> > > file per Xen release was provided, no matter the underlying arch.
> > > In other words ovmf is built separately on raisin on x86 too, but I
> > > would prefer if we used the same ovmf revision for all archs.
> > 
> > Please bear in mind that what you are asking is has consequences
> > outside of
> > raisin which are not necessarily simple.
> > 
> > Right now we do not having a branching strategy for ovmf, so cherry
> > -picking
> > fixes for aarch64 means someone would need to come up with one and
> > implement it. There are also the implications which Wei raised.
> > 
> > Based on Wei's comments regarding support from upstream it seems like
> > we
> > should probably just pull ovmf forward to something newer (~= current
> > tested master based on x86 testing) for 4.6.1.
> 
> That's fine for me

I think this corresponds to backporting the patch Wei sent out earlier:

From: Wei Liu 
To: Xen-devel 
Cc: [...]
Subject: [PATCH] Config.mk: update OVMF changeset
Date: Wed, 14 Oct 2015 12:41:13 +0100
Message-id: <1444822873-28287-1-git-send-email-wei.l...@citrix.com>

I'll try and remember to mention this when I commit.

Ian.

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

Re: [Xen-devel] RFC: Survey on release cycle

[Ian Campbell]

On Wed, 2015-10-14 at 14:08 +0100, Wei Liu wrote:
> On Wed, Oct 14, 2015 at 01:21:11PM +0100, Ian Campbell wrote:
> > Aside: I'm a bit confused regarding whether our "stable release scheme" is
> > defined in terms of number of concurrently supported releases or in terms
> > of an absolute time. 
> > http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases definitely
> > says it is concurrent release based, but your proposal above suggests
> > otherwise. Is the wiki wrong?
> > 
> 
> Sorry about the confusion. I picked the time-based interpretation
> because that's why I slightly preferred (again, note that all details
> are merely my preferences). There is room for discussion of course.
> Whether the stable releases based on absolute time or number of
> concurrent releases, I won't argue for one over another.

My confusion wasn't down to arguing for/against one or the other, just that
the options presented did not make it clear which one they were using,
which meant their use of the word "current" was potentially confusing.

Ian.

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

Re: [Xen-devel] [PATCH QEMU-XEN v3 5/8] xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory API.

[Ian Campbell]

On Wed, 2015-10-14 at 16:41 +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, Ian Campbell wrote:
> > On Wed, 2015-10-14 at 15:10 +0100, Stefano Stabellini wrote:
> > > On Wed, 7 Oct 2015, Ian Campbell wrote:
> > > > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > > > separate libraries which will provide backward and forward API and
> > > > ABI
> > > > compatiblity.
> > > > 
> > > > One such library will be libxenforeignmemory which provides access
> > > > to
> > > > privileged foreign mappings and which will provide an interface
> > > > equivalent to xc_map_foreign_bulk.
> > > > 
> > > > In preparation for adding support for libxenforeignmemory add
> > > > support
> > > > to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
> > > > switch to using the new API. These shims will disappear for
> > > > versions
> > > > of Xen which include libxenforeignmemory.
> > > > 
> > > > Since libxenforeignmemory will have its own handle type but for <=
> > > > 4.6
> > > > the functionality is provided by using a libxenctrl handle we
> > > > introduce a new global xen_fmem alongside the existing xen_xc. In
> > > > fact
> > > > we make xen_fmem a pointer to the existing xen_xc, which then works
> > > > correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc
> > > > handle
> > > > is a pointer). In the latter case xen_fmem is actually a double
> > > > indirect pointer, but it all falls out in the wash.
> > > > 
> > > > Unlike libxenctrl libxenforeignmemory has an explicit unmap
> > > > function,
> > > > rather than just specifying that munmap should be used, so the
> > > > unmap
> > > > paths are updated to use xenforeignmemory_unmap, which is a shim
> > > > for
> > > > munmap on these versions of xen. The mappings in xen-hvm.c do not
> > > > appear to be unmapped (which makes sense for a qemu-dm process)
> > > > 
> > > > In fb_disconnect this results in a change from simply mmap over the
> > > > existing mapping (with an implciit munmap) to expliclty unmapping
> > > > with
> > > > xenforeignmemory_unmap and then mapping the required anonymous
> > > > memory
> > > > in the same hole. I don't think this is a problem since any other
> > > > thread which was racily touching this region would already be
> > > > running
> > > > the risk of hitting the mapping halfway through the call. If this
> > > > is
> > > > thought to be a problem then we could consider adding an extra API
> > > > to
> > > > the libxenforeignmemory interface to replace a foreign mapping with
> > > > anonymous shared memory, but I'd prefer not to.
> > > > 
> > > > Build tested with 4.0 and 4.5.
> > > > 
> > > > Signed-off-by: Ian Campbell 
> > > > ---
> > > > I noticed in xen_console.c that the decision to use a foreign
> > > > privileged memory mapping vs a grant dev is made using different
> > > > variables in con_initialise vs con_disconnect. The former uses
> > > > xendev->dev while the latter uses xendev->gnttabdev. Is this a
> > > > latent
> > > > bug?
> > > 
> > > The code in con_disconnect is superfluous: the initial check
> > > 
> > > if (!xendev->dev) {
> > > return;
> > > }
> > > 
> > > makes sure the rest of the function only deals with dev != 0.
> > > I guess it should be
> > > 
> > > if (!xendev->dev) {
> > 
> > Did you mean xendev->gnttabdev here? Since this is what the code is
> > touching.
> > 
> > Should ->dev and ->gnttabdev be either both set or neither then?
> 
> That's right
> 
> 
> > Since con_connect uses the former to decide it would seem logical for
> > teardown to use the same condition, but I don't know if I'm missing
> > something. In particular given the initial check you point to how is
> > the
> > foreign mapping not already leaked today if the lifecycle of ->dev and 
> > ->gnttabdev are strictly aligned?
> > 
> > > munmap(con->sring, XC_PAGE_SIZE);
> > 
> > And this is how the code should be _now_, i.e. with this patch it
> > should
> > become xenforeignmemory_unmap?
> 
> Yes, I think that today it is leaked, but in practice there is one QEMU
> process per VM and the VM never disconnect/reconnect the primary console
> (I don't think there is a way to do that). In other words, after
> con_disconnect, QEMU is killed.

Part of the reason for xenforeignmemory_unmap is so that we can make things
like valgrind more aware of what is going on, so having this happen even if
things are about to exit is still useful.

I came up with the following patch which I will insert at the front of v4,
but I have one doubt, namely are the calls to qemu_chr_add_handler and
qemu_chr_fe_release not useful here too?

Obviously the call to xen_be_unbind_evtchn is not useful as is, but I do
wonder where the evtchn which the primary console must have somewhere
actually is then...

Maybe the reasoning here is the same "we are going to exit anyway", and
maybe this cleanup isn't the sort of thing valgrind will complain about
(i.e. neither of them free any 

Re: [Xen-devel] [PATCH 3/4] x86: don't use FPU instructions when there is no FPU

[Andrew Cooper]

On 14/10/15 14:31, Jan Beulich wrote:
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -170,6 +170,7 @@
>  #define CPUID5_ECX_EXTENSIONS_SUPPORTED 0x1
>  #define CPUID5_ECX_INTERRUPT_BREAK  0x2
>  
> +#define cpu_has_fpu  boot_cpu_has(X86_FEATURE_FPU)

This distinguishes only between an onboard fpu or an original x87
co-processor.  It does not represent the presence or absence of an fpu.

Looking at the Xeon Phi documentation
(http://download-software.intel.com/sites/default/files/forum/278102/327364001en.pdf),
it has this feature bit set, although it does have MMX clear.

Interestingly however, a Phi's default MXCSR value ix 0x2h and will
#GP at any attempt to clear bit 21, which means fpu_init() will
unconditionally blow up on such a system.

I am not aware of a bit which signifies the absence of FPU
capabilities.  Until there is, I don't think changes along these lines
are a safe way to go.

~Andrew

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

Re: [Xen-devel] [PATCH 3/4] x86: don't use FPU instructions when there is no FPU

[Jan Beulich]

>>> On 14.10.15 at 16:30,  wrote:
> On 14/10/15 14:31, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/cpufeature.h
>> +++ b/xen/include/asm-x86/cpufeature.h
>> @@ -170,6 +170,7 @@
>>  #define CPUID5_ECX_EXTENSIONS_SUPPORTED 0x1
>>  #define CPUID5_ECX_INTERRUPT_BREAK  0x2
>>  
>> +#define cpu_has_fpu boot_cpu_has(X86_FEATURE_FPU)
> 
> This distinguishes only between an onboard fpu or an original x87
> co-processor.  It does not represent the presence or absence of an fpu.

That's a very odd statement with off-chip FPUs having disappeared
with the Pentium. We don't care about x87 co-processors at all in Xen.

> Looking at the Xeon Phi documentation
> (http://download-software.intel.com/sites/default/files/forum/278102/327364001en.pdf),
> it has this feature bit set, although it does have MMX clear.
> 
> Interestingly however, a Phi's default MXCSR value ix 0x2h and will
> #GP at any attempt to clear bit 21, which means fpu_init() will
> unconditionally blow up on such a system.

"... one of the many things ..."

> I am not aware of a bit which signifies the absence of FPU
> capabilities.  Until there is, I don't think changes along these lines
> are a safe way to go.

See above; I continue to think this is the right thing at this point.
Going forward we'll have to see whether co-processors re-appear.

Jan


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

Re: [Xen-devel] [PATCH XEN v3 11/22] tools: Remove xc_map_foreign_batch

[Ian Campbell]

On Wed, 2015-10-07 at 16:08 +0100, George Dunlap wrote:
> On 07/10/15 15:15, Ian Campbell wrote:
> > 
[...]
> > Signed-off-by: Ian Campbell 
> > Acked-by: George Dunlap 
> > Cc: George Dunlap 
> > 
[...]
> In any case:
> 
> Acked-by: George Dunlap 

It must be a really good patch... ;-)

Ian.

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

Re: [Xen-devel] [PATCH QEMU-XEN v3 3/8] xen: Switch uses of xc_map_foreign_range into xc_map_foreign_bulk

[Ian Campbell]

On Wed, 2015-10-14 at 15:01 +0100, Stefano Stabellini wrote:
> On Wed, 7 Oct 2015, Ian Campbell wrote:
> > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > separate libraries which will provide backward and forward API and ABI
> > compatiblity.
> > 
> > One such library will be libxenforeignmemory which provides access to
> > privileged foreign mappings and which will provide an interface
> > equivalent to xc_map_foreign_bulk.
> > 
> > In preparation for this switch all uses of xc_map_foreign_range to
> > xc_map_foreign_bulk. 
> 
> The sentence is incomplete.

If you mean "grammatically incorrect" then I don't think it is. Did you
mean it was missing some information which you hoped to to see? If so then
which?

> Unfortunately xc_map_foreign_bulk is not that well documented, but I am
> assuming that the mfn parameter is not supposed to be changed by the
> function, right?

Given:

/**
 * Like xc_map_foreign_pages(), except it can succeed partially.
 * When a page cannot be mapped, its respective field in @err is
 * set to the corresponding errno value.
 */
void *xc_map_foreign_bulk(xc_interface *xch, uint32_t dom, int prot,
  const xen_pfn_t *arr, int *err, unsigned int num);

by "the mfn parameter" I suppose you mean arr[0] (for cases where arr is
passed as  as below)?

That's a pointer to an array of const xen_pfn_t so no need to worry about
it changing, unlike some other interfaces per-page errors are reported via
the separate err array.

Ian.

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

Re: [Xen-devel] [PATCH v7 16/32] xen/x86: allow disabling the pmtimer

[Jan Beulich]

>>> On 02.10.15 at 17:48,  wrote:
> Signed-off-by: Roger Pau Monné 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
> Changes since v6:
>  - Return ENODEV in pmtimer_load if the timer is disabled.
>  - hvm_acpi_power_button and hvm_acpi_sleep_button become noops if the
>pmtimer is disabled.

But how are those two features connected? I don't think you can
assume absence of a PM block just because there's no PM timer.
Or if you want to tie them together for now, the predicate needs
to be renamed.

>  - Return ENODEV if pmtimer_change_ioport is called with the pmtimer
>disabled.

Same here.

Jan

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

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Xu, Quan]

>> >>> On 13.10.2015 at 22:50  wrote:
> >>> On 13.10.15 at 16:29,  wrote:
> >> > >>>On 29.09.2015 at 15:22  wrote:
> >> >>> On 29.09.15 at 04:53,  wrote:
> >>  Monday, September 28, 2015 2:47 PM, wrote:
> >> >> >>> On 28.09.15 at 05:08,  wrote:
> >> >>  Thursday, September 24, 2015 12:27 AM, Tim Deegan wrote:

> > 1. if (page->count_info & PGC_count_mask == 0) and (page->count_info
> > != 0) In this case, can the page be freed to xen domain heap?
> 
> Whether a page can get freed depends on changes to count_info, not just its
> current state. For instance, PGC_allocated set implies
> page->count_info & PGC_count_mask != 0, i.e. your question above
> cannot be answered properly. Just look at put_page() - it frees the page when
> the count _drops_ to zero.
> 
> > 2. if  (page->count_info & PGC_count_mask == 0) and
> (page->u.inuse.type_info != 0) :
> > In this case, can the page be freed to xen domain heap?
> 
> Generally type_info should be zero when the ref count is zero; there are, I 
> think,
> exceptional cases (like during domain death) where this might get violated 
> with
> no harm. But again - look at put_page() and you'll see that type_info doesn't
> matter for whether a page gets freed; all it matter is whether a page's type 
> can
> change: Only when type count is zero.
> 

Jan, Thanks for kind explanation.

-Quan

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

Re: [Xen-devel] [PATCH v7 20/32] xen/x86: set the vPMU interface based on the presence of a lapic

[Roger Pau Monné]

El 14/10/15 a les 16.59, Boris Ostrovsky ha escrit:
> On 10/14/2015 10:41 AM, Jan Beulich wrote:
> On 02.10.15 at 17:48,  wrote:
>>> Instead of choosing the interface to expose to guests based on the guest
>>> type, do it based on whether the guest has an emulated local apic or
>>> not.
>>>
>>> Signed-off-by: Roger Pau Monné 
>> Acked-by: Jan Beulich 
>> depending on Boris' ack/review.
> 
> 
> I sent Roger additional patch a couple of days ago to make this work
> (I've been using his series for a while now) so presumably he will
> integrate it in the next spin (or will resend this patch).
> 
> Assuming he agrees with my changes, of course.

TBH, I still need to look into them, I've been busy with the FPU stuff.
But I'm quite sure they are fine, I will merge them with this patch and
add your signed-off to it if that's fine.

Roger.


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

[Xen-devel] [PATCH v2 0/6] xen: sched: fix locking of {insert, remove}_vcpu()

[Dario Faggioli]

Hey,

Here it comes v2 of this series. It took a bit more than how I wanted, mostly
because of the cpufreq issue I found while testing (as I though I was causing
it! :-/).

Version 1 is here:

 http://www.gossamer-threads.com/lists/xen/devel/401619?page=last

I think I've addressed all the review comments, but the series also changed a
little bit. Because of that, most of the patches don't carry the
Reviewed-/Acked-by tags they were given during v1's review.

More specifically:
 
 * patch 2 needed adjustments as, in case only patches 1 and 2 are applied
   (i.e., if what was patch 3 in v1, which is now patch 4, is _not_applied)
   the runqueue lock in Credit1's implementation of insert_vcpu() needs to
   be an _irqsave() one. In fact, it is acquired with interrupt disabled
   during boot (when initializing idle vCPUs). Since Credit2 and RTDS bail
   out before even trying taking the lock, for idle vCPUs, they're fine with
   just _irq(). Also, it can be turned into an _irq() one in patch 4, when we
   kill the need of calling that hook altogether, for idle vCPUs.  This is
   done like this because I think it is worth considering backporting patches
   1 and 2, so I think it's important that they work well, independently from
   the rest of the series (which is mostly improvements, so backporting is
   out of question)

 * patch 3 is new. It's "just" comments and ASSERT()-s about something
   discussed already with both Jan and George.

The rest, really should be no more than v1 with review comments addressed
(except, of course, patches 6 and 7 from v1, which are in already :-D).

Git branch available here:

 git://xenbits.xen.org/people/dariof/xen.git  rel/sched/fix-vcpu-ins-rem-v2

Thanks and Regards,
Dario
---
Dario Faggioli (6):
  xen: sched: fix locking of remove_vcpu() in credit1
  xen: sched: fix locking for insert_vcpu() in credit1 and RTDS
  xen: sched: clarify use cases of schedule_cpu_switch()
  xen: sched: better handle (not) inserting idle vCPUs in runqueues
  xen: sched: get rid of the per domain vCPU list in RTDS
  xen: sched: get rid of the per domain vCPU list in Credit2

 xen/common/sched_credit.c  |   17 ++--
 xen/common/sched_credit2.c |   55 ++--
 xen/common/sched_rt.c  |   61 ++--
 xen/common/schedule.c  |   55 
 4 files changed, 102 insertions(+), 86 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 1/6] xen: sched: fix locking of remove_vcpu() in credit1

[Dario Faggioli]

In fact, csched_vcpu_remove() (i.e., the credit1
implementation of remove_vcpu()) manipulates runqueues,
so holding the runqueue lock is necessary.

Also, while there, *_lock_irq() (for the private lock) is
enough, there is no need to *_lock_irqsave().

Signed-off-by: Dario Faggioli 
Reviewed-by: Andrew Cooper 
---
Cc: George Dunlap 
Cc: Jan Beulich 
---
Changes from the other series:
 * split the patch (wrt the original patch, in the original
   series), and take care, in this one, only of remove_vcpu();
 * removed pointless parentheses.
---
 xen/common/sched_credit.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index b8f28fe..6f71e0d 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -926,7 +926,7 @@ csched_vcpu_remove(const struct scheduler *ops, struct vcpu 
*vc)
 struct csched_private *prv = CSCHED_PRIV(ops);
 struct csched_vcpu * const svc = CSCHED_VCPU(vc);
 struct csched_dom * const sdom = svc->sdom;
-unsigned long flags;
+spinlock_t *lock;
 
 SCHED_STAT_CRANK(vcpu_remove);
 
@@ -936,15 +936,19 @@ csched_vcpu_remove(const struct scheduler *ops, struct 
vcpu *vc)
 vcpu_unpause(svc->vcpu);
 }
 
+lock = vcpu_schedule_lock_irq(vc);
+
 if ( __vcpu_on_runq(svc) )
 __runq_remove(svc);
 
-spin_lock_irqsave(&(prv->lock), flags);
+vcpu_schedule_unlock_irq(lock, vc);
+
+spin_lock_irq(>lock);
 
 if ( !list_empty(>active_vcpu_elem) )
 __csched_vcpu_acct_stop_locked(prv, svc);
 
-spin_unlock_irqrestore(&(prv->lock), flags);
+spin_unlock_irq(>lock);
 
 BUG_ON( sdom == NULL );
 BUG_ON( !list_empty(>runq_elem) );


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

Re: [Xen-devel] [PATCH v7 23/32] xen/x86: make sure the HVM callback vector is correctly set

[Andrew Cooper]

On 14/10/15 16:54, Jan Beulich wrote:
 On 02.10.15 at 17:48,  wrote:
>> --- a/xen/arch/x86/hvm/irq.c
>> +++ b/xen/arch/x86/hvm/irq.c
>> @@ -330,6 +330,10 @@ void hvm_set_callback_via(struct domain *d, uint64_t 
>> via)
>>   (via_type > HVMIRQ_callback_vector) )
>>  via_type = HVMIRQ_callback_none;
>>  
>> +if ( via_type != HVMIRQ_callback_vector &&
>> + (!has_vlapic(d) || !has_vioapic(d) || !has_vpic(d)) )
>> +return;
> Why are both IO-APIC and PIC required? Doesn't one suffice, or
> can't MSI-like interrupts even get delivered without either?

In real hardware, MSI-like interrupts have no interaction with the
IO-APIC or PIC.

In fact, the purpose of the IO-APIC is to turn legacy line interrupts
into MSI interrupts.  The PICs were from the pre-MSI days where it
asserted the #INTR pin on the processor.

Our virtual interrupt infrastructure should behave in a consistent manor.

~Andrew

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

Re: [Xen-devel] [PATCH QEMU-XEN v3 5/8] xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory API.

[Ian Campbell]

On Wed, 2015-10-14 at 16:59 +0100, Ian Campbell wrote:

> I came up with the following patch[...] 

>  if (!xendev->dev) {
> +if (con->string) {

I've fixed the obvious typo in my actual tree...

> +munmap(con->sring, XC_PAGE_SIZE);
> +con->sring = NULL;
> +}
>  return;


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

Re: [Xen-devel] [PATCH v7 14/32] xen/x86: allow disabling the emulated local apic

[Jan Beulich]

>>> On 02.10.15 at 17:48,  wrote:
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 
(but awaiting an update to patch 2 for it to go in)

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

Re: [Xen-devel] [PATCH v7 20/32] xen/x86: set the vPMU interface based on the presence of a lapic

[Jan Beulich]

>>> On 02.10.15 at 17:48,  wrote:
> Instead of choosing the interface to expose to guests based on the guest
> type, do it based on whether the guest has an emulated local apic or not.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 
depending on Boris' ack/review.

Jan

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

Re: [Xen-devel] [PATCH QEMU-XEN v3 8/8] xen: make it possible to build without the Xen PV domain builder

[Stefano Stabellini]

On Wed, 7 Oct 2015, Ian Campbell wrote:
> Until the previous patch this relied on xc_fd(), which was only
> implemented for Xen 4.0 and earlier.
> 
> I stopped short of disabling this by default, although I think there's
> a pretty strong argument for doing so.
> 
> Removing this support drops the use of a bunch of symbols from
> libxenctrl, specifically:
> 
>   - xc_domain_create
>   - xc_domain_destroy
>   - xc_domain_getinfo
>   - xc_domain_max_vcpus
>   - xc_domain_setmaxmem
>   - xc_domain_unpause
>   - xc_evtchn_alloc_unbound
>   - xc_linux_build
> 
> This is another step towards only using Xen libraries which provide a
> stable inteface.

I would prefer to remove it, but the discussion needs to happen on
qemu-devel.



> Signed-off-by: Ian Campbell 
> ---
>  configure | 17 +
>  hw/xenpv/Makefile.objs|  4 +++-
>  hw/xenpv/xen_machine_pv.c | 14 ++
>  3 files changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/configure b/configure
> index 508b157..534d280 100755
> --- a/configure
> +++ b/configure
> @@ -910,6 +910,10 @@ for opt do
>;;
>--enable-xen-pci-passthrough) xen_pci_passthrough="yes"
>;;
> +  --disable-xen-pv-domain-build) xen_pv_domain_build="no"
> +  ;;
> +  --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
> +  ;;
>--disable-brlapi) brlapi="no"
>;;
>--enable-brlapi) brlapi="yes"
> @@ -2148,6 +2152,15 @@ if test "$xen_pci_passthrough" != "no"; then
>fi
>  fi
>  
> +if test "$xen_pv_domain_build" != "no"; then
> +  if test "$xen_pv_domain_build" = "yes" &&
> + test "$xen" != "yes"; then
> +  error_exit "User requested Xen PV domain builder support" \
> +  "which requires Xen support."
> +  fi
> +  xen_pv_domain_build=$xen
> +fi
> +
>  ##
>  # libtool probe
>  
> @@ -4429,6 +4442,7 @@ echo "xen support   $xen"
>  if test "$xen" = "yes" ; then
>echo "  stable libs $xenstablelibs"
>echo "  ctrl version$xen_ctrl_version"
> +  echo "  PV dom build$xen_pv_domain_build"
>  fi
>  echo "brlapi support$brlapi"
>  echo "bluez  support$bluez"
> @@ -4764,6 +4778,9 @@ if test "$xen" = "yes" ; then
>if test "$xenstablelibs" = "yes" ; then
>  echo "CONFIG_XEN_STABLE_LIBS=y" >> $config_host_mak
>fi
> +  if test "$xen_pv_domain_build" = "yes" ; then
> +echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
> +  fi
>  fi
>  if test "$linux_aio" = "yes" ; then
>echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
> diff --git a/hw/xenpv/Makefile.objs b/hw/xenpv/Makefile.objs
> index 49f6e9e..bbf5873 100644
> --- a/hw/xenpv/Makefile.objs
> +++ b/hw/xenpv/Makefile.objs
> @@ -1,2 +1,4 @@
>  # Xen PV machine support
> -obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o
> +obj-$(CONFIG_XEN) += xen_machine_pv.o
> +# Xen PV machine builder support
> +obj-$(CONFIG_XEN_PV_DOMAIN_BUILD) += xen_domainbuild.o
> diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
> index 2e545d2..d19d29f 100644
> --- a/hw/xenpv/xen_machine_pv.c
> +++ b/hw/xenpv/xen_machine_pv.c
> @@ -30,9 +30,6 @@
>  
>  static void xen_init_pv(MachineState *machine)
>  {
> -const char *kernel_filename = machine->kernel_filename;
> -const char *kernel_cmdline = machine->kernel_cmdline;
> -const char *initrd_filename = machine->initrd_filename;
>  DriveInfo *dinfo;
>  int i;
>  
> @@ -46,13 +43,22 @@ static void xen_init_pv(MachineState *machine)
>  case XEN_ATTACH:
>  /* nothing to do, xend handles everything */
>  break;
> -case XEN_CREATE:
> +case XEN_CREATE: {
> +#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
> + const char *kernel_filename = machine->kernel_filename;
> + const char *kernel_cmdline = machine->kernel_cmdline;
> + const char *initrd_filename = machine->initrd_filename;
>  if (xen_domain_build_pv(kernel_filename, initrd_filename,
>  kernel_cmdline) < 0) {
>  fprintf(stderr, "xen pv domain creation failed\n");
>  exit(1);
>  }
> +#else
> + fprintf(stderr, "xen pv domain creation not supported\n");
> + exit (1);
> +#endif
>  break;
> +}
>  case XEN_EMULATE:
>  fprintf(stderr, "xen emulation not implemented (yet)\n");
>  exit(1);
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH 4/4] x86/capabilities: set/clear them using non-locked bitops

[Andrew Cooper]

On 14/10/15 14:31, Jan Beulich wrote:
> Their initialization happens without races, so there's no point in
> using atomic (locked) operations to update the respective flags.
> (There's one case where the clear_bit() was completely pointless.)
>
> Also drop a neighboring stale comment from AMD code.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Xu, Quan]

>> >>>On 13.10.2015 at 17:35,  wrote:
> At 11:09 + on 11 Oct (1444561760), Xu, Quan wrote:


> What in particular is worrying you about scheme A?  AFAICS you need to build
> the same refcount-taking mechanism for either scheme.
> 
> Is it the interactions with other p2m-based features in VMs that don't have
> devices passed through?  In that case perhaps you could just mandate that ATS
> support means no shared HAP/IOMMU tables, and do the refcounting only in the
> IOMMU ones?
> 

I am worrying that I should keep a log of all relevant pending derefs and to be 
processed when the flush completes for __scheme_A__..
Now I know only need the log/deref whenever you need to flush the IOMMU. :):)


> >  I think __scheme_A__ is complex to keep a log of all relevant pending
> > derefs, and to be processed when the flush completes;
> >
> > optimized __scheme_A__:
> > It could keep a log of the reference only when the IOMMU entry is _
> removed/overwritten_.(if the IOMMU entry is not _ removed/overwritten_, it is
> safe.).
> 
> Yes, though I'd add any change from read-write to read-only.
> Basically, you only need the log/deref whenever you need to flush the
> IOMMU. :)
> 

A summary of __scheme_A__:

 Q1: - when to take the references?
 take the reference when the IOMMU entry is _created_;
 in detail:
  --iommu_map_page(), or
  --ept_set_entry() [Once IOMMU shares EPT page table.]

 Q2: how do you know when to drop them?
- Log (or something) when the IOMMU entry is removed/overwritten; and
- Drop the entry when the flush completes.
in detail:
   --iommu_unmap_page(); or
   --ept_set_entry() [Once IOMMU shares EPT page table.]


   **The challenge: how to log when IOMMU entry is removed/overwritten?



 Q3: what to do about mappings of other domains' memory (i.e. grant and
 foreign mappings).

i.e. grant:
-Take the reference when the IOMMU entry is _created_;
then,
-Queue the reference drop;and
-Queue grant iflag update(only for grant_unmap and grant_transfer are 
enough -- we can hold on this question).



 __afaics__:
   1. Are Q1/Q2/Q3 enough for this memory security issue?
   2. Are there any other potential memory issues, when I finish  
__scheme_A__?
   3. Do you have any idea how to log when IOMMU entry is 
removed/overwritten?
  
Tim, thanks for your help!


Quan






























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

Re: [Xen-devel] [PATCH XEN v3 11/22] tools: Remove xc_map_foreign_batch

[George Dunlap]

On 14/10/15 16:05, Ian Campbell wrote:
> On Wed, 2015-10-07 at 16:08 +0100, George Dunlap wrote:
>> On 07/10/15 15:15, Ian Campbell wrote:
>>>
> [...]
>>> Signed-off-by: Ian Campbell 
>>> Acked-by: George Dunlap 
>>> Cc: George Dunlap 
>>>
> [...]
>> In any case:
>>
>> Acked-by: George Dunlap 
> 
> It must be a really good patch... ;-)

Haha -- well at least I'm consistent. :-)

 -George


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

Re: [Xen-devel] [PATCH QEMU-XEN v3 3/8] xen: Switch uses of xc_map_foreign_range into xc_map_foreign_bulk

[Stefano Stabellini]

On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 15:01 +0100, Stefano Stabellini wrote:
> > On Wed, 7 Oct 2015, Ian Campbell wrote:
> > > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > > separate libraries which will provide backward and forward API and ABI
> > > compatiblity.
> > > 
> > > One such library will be libxenforeignmemory which provides access to
> > > privileged foreign mappings and which will provide an interface
> > > equivalent to xc_map_foreign_bulk.
> > > 
> > > In preparation for this switch all uses of xc_map_foreign_range to
> > > xc_map_foreign_bulk. 
> > 
> > The sentence is incomplete.
> 
> If you mean "grammatically incorrect" then I don't think it is. Did you
> mean it was missing some information which you hoped to to see? If so then
> which?

Sorry, I read it as:

In preparation for this switch,
all uses of xc_map_foreign_range  to xc_map_foreign_bulk.

:-)


> > Unfortunately xc_map_foreign_bulk is not that well documented, but I am
> > assuming that the mfn parameter is not supposed to be changed by the
> > function, right?
> 
> Given:
> 
> /**
>  * Like xc_map_foreign_pages(), except it can succeed partially.
>  * When a page cannot be mapped, its respective field in @err is
>  * set to the corresponding errno value.
>  */
> void *xc_map_foreign_bulk(xc_interface *xch, uint32_t dom, int prot,
>   const xen_pfn_t *arr, int *err, unsigned int num);
> 
> by "the mfn parameter" I suppose you mean arr[0] (for cases where arr is
> passed as  as below)?

that's right


> That's a pointer to an array of const xen_pfn_t so no need to worry about
> it changing, unlike some other interfaces per-page errors are reported via
> the separate err array.

That's what I gathered from the code too, I just wanted to be sure

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

Re: [Xen-devel] [PATCH v7 20/32] xen/x86: set the vPMU interface based on the presence of a lapic

[Boris Ostrovsky]

On 10/14/2015 10:41 AM, Jan Beulich wrote:

On 02.10.15 at 17:48,  wrote:

Instead of choosing the interface to expose to guests based on the guest
type, do it based on whether the guest has an emulated local apic or not.

Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 
depending on Boris' ack/review.



I sent Roger additional patch a couple of days ago to make this work 
(I've been using his series for a while now) so presumably he will 
integrate it in the next spin (or will resend this patch).


Assuming he agrees with my changes, of course.

-boris

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

Re: [Xen-devel] [PATCH v7 20/32] xen/x86: set the vPMU interface based on the presence of a lapic

[Boris Ostrovsky]

On 10/14/2015 11:06 AM, Roger Pau Monné wrote:

El 14/10/15 a les 16.59, Boris Ostrovsky ha escrit:

On 10/14/2015 10:41 AM, Jan Beulich wrote:

On 02.10.15 at 17:48,  wrote:

Instead of choosing the interface to expose to guests based on the guest
type, do it based on whether the guest has an emulated local apic or
not.

Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 
depending on Boris' ack/review.


I sent Roger additional patch a couple of days ago to make this work
(I've been using his series for a while now) so presumably he will
integrate it in the next spin (or will resend this patch).

Assuming he agrees with my changes, of course.

TBH, I still need to look into them, I've been busy with the FPU stuff.
But I'm quite sure they are fine, I will merge them with this patch and
add your signed-off to it if that's fine.


Sure.

-boris


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

[Xen-devel] [PATCH v2 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS

[Dario Faggioli]

The insert_vcpu() hook is handled with inconsistent locking.
In fact, schedule_cpu_switch() calls the hook with runqueue
lock held, while sched_move_domain() relies on the hook
implementations to take the lock themselves (and, since that
is not done in Credit1 and RTDS, such operation is not safe
in those cases).

Turn this situation into _always_ taking the lock in the
hook implementations, in specific schedulers' code.

Note that it is safe to get rid of the locking in
schedule_cpu_switch() as the pCPU being switched is, at
the time of the switch, not a valid member of any cpupool,
so no scheduling event should be expected on it, locking
or not.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Meng Xu 
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
Changes from v1 (of this series):
 * in Credit1, the lock wants to be an _irqsave() one. If
   not, the ASSERT() in _spin_lock_irq() will trigger when
   the hook is called, during boot, from sched_init_vcpu();
 * reprhased the changelog (to be less verbose);
 * add a few words, in the changelog, about why it is safe
   to get rid of the locking in schedule_cpu_switch(). Proper
   commentary and ASSERT()-s about that will come in another
   patch.

Changes from the other series:
 * split the patch (wrt the original patch, in the original
   series), and take care, in this one, only of insert_vcpu();
---
Note that I'm not picking up Andrew's Reviewed-by, as the patch
changed a little bit.
---
 xen/common/sched_credit.c |6 ++
 xen/common/sched_rt.c |3 +++
 xen/common/schedule.c |6 --
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 6f71e0d..e16bd3a 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -903,10 +903,16 @@ static void
 csched_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
 {
 struct csched_vcpu *svc = vc->sched_priv;
+spinlock_t *lock;
+unsigned long flags;
+
+lock = vcpu_schedule_lock_irqsave(vc, );
 
 if ( !__vcpu_on_runq(svc) && vcpu_runnable(vc) && !vc->is_running )
 __runq_insert(vc->processor, svc);
 
+vcpu_schedule_unlock_irqrestore(lock, flags, vc);
+
 SCHED_STAT_CRANK(vcpu_insert);
 }
 
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 6a341b1..1086399 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -622,16 +622,19 @@ rt_vcpu_insert(const struct scheduler *ops, struct vcpu 
*vc)
 {
 struct rt_vcpu *svc = rt_vcpu(vc);
 s_time_t now = NOW();
+spinlock_t *lock;
 
 /* not addlocate idle vcpu to dom vcpu list */
 if ( is_idle_vcpu(vc) )
 return;
 
+lock = vcpu_schedule_lock_irq(vc);
 if ( now >= svc->cur_deadline )
 rt_update_deadline(now, svc);
 
 if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
 __runq_insert(ops, svc);
+vcpu_schedule_unlock_irq(lock, vc);
 
 /* add rt_vcpu svc to scheduler-specific vcpu list of the dom */
 list_add_tail(>sdom_elem, >sdom->vcpu);
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index c5f640f..9aa209d 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1488,9 +1488,7 @@ void __init scheduler_init(void)
 
 int schedule_cpu_switch(unsigned int cpu, struct cpupool *c)
 {
-unsigned long flags;
 struct vcpu *idle;
-spinlock_t *lock;
 void *ppriv, *ppriv_old, *vpriv, *vpriv_old;
 struct scheduler *old_ops = per_cpu(scheduler, cpu);
 struct scheduler *new_ops = (c == NULL) ?  : c->sched;
@@ -1509,8 +1507,6 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool 
*c)
 return -ENOMEM;
 }
 
-lock = pcpu_schedule_lock_irqsave(cpu, );
-
 SCHED_OP(old_ops, tick_suspend, cpu);
 vpriv_old = idle->sched_priv;
 idle->sched_priv = vpriv;
@@ -1520,8 +1516,6 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool 
*c)
 SCHED_OP(new_ops, tick_resume, cpu);
 SCHED_OP(new_ops, insert_vcpu, idle);
 
-pcpu_schedule_unlock_irqrestore(lock, flags, cpu);
-
 SCHED_OP(old_ops, free_vdata, vpriv_old);
 SCHED_OP(old_ops, free_pdata, ppriv_old, cpu);
 


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

[Xen-devel] [PATCH] Print out components which are skipped because unsupported on a given platform

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
---
 lib/common-functions.sh |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/common-functions.sh b/lib/common-functions.sh
index 03642ae..27f6434 100644
--- a/lib/common-functions.sh
+++ b/lib/common-functions.sh
@@ -301,11 +301,16 @@ function for_each_component () {
 break
 fi
 done
-if ! $found || "$component"_skip
+if ! $found
 then
 verbose_echo "$component" is disabled
 continue
 fi
+if "$component"_skip
+then
+error_echo "$component" will be skipped on your platform
+continue
+fi
 
 echo "$PREPEND" calling "$component"_"$1"
 if [[ $VERBOSE -eq 0 ]]
-- 
1.7.9.5


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

[Xen-devel] [PATCH v2] raisin: enable ovmf build for arm64

[Stefano Stabellini]

Disable ovmf build on x86_32: it does not work, the code was already
forcing a x86_64 build.

---

Changes in v2:
- disable x86_32 build (it doesn't work, but it wasn't explicitly
  disabled)
- remove export GCC48_AARCH64_PREFIX= as it is not necessary
- add a comment on why we are using -t GCC48
---
 components/ovmf |   47 +++
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/components/ovmf b/components/ovmf
index ffdde19..48091ac 100644
--- a/components/ovmf
+++ b/components/ovmf
@@ -1,24 +1,28 @@
 #!/usr/bin/env bash
 
 function ovmf_skip() {
-if [[ $RAISIN_ARCH != "x86_64" && $RAISIN_ARCH != "x86_32" ]]
-then
-return 0
-else
-return 1
-fi
+case $RAISIN_ARCH in
+"arm32"|"x86_32" )
+return 0
+;;
+"arm64"|"x86_64" )
+return 1
+;;
+esac
 }
 
 function ovmf_check_package() {
-local DEP_Debian_common="build-essential nasm uuid-dev python iasl"
-local DEP_Debian_x86_32="$DEP_Debian_common"
-local DEP_Debian_x86_64="$DEP_Debian_common"
-local DEP_Debian_arm32="$DEP_Debian_common"
+local DEP_Debian_common="build-essential uuid-dev python iasl"
+local DEP_Debian_x86_64="$DEP_Debian_common nasm"
 local DEP_Debian_arm64="$DEP_Debian_common"
 
-local DEP_Fedora_common="make gcc gcc-c++ nasm libuuid-devel python 
acpica-tools"
-local DEP_Fedora_x86_32="$DEP_Fedora_common"
-local DEP_Fedora_x86_64="$DEP_Fedora_common"
+local DEP_Fedora_common="make gcc gcc-c++ libuuid-devel python 
acpica-tools"
+local DEP_Fedora_x86_64="$DEP_Fedora_common nasm"
+local DEP_Fedora_arm64="$DEP_Debian_common"
+
+local DEP_CentOS_common="$DEP_Fedora_common"
+local DEP_CentOS_x86_64="$DEP_Fedora_x86_64"
+local DEP_CentOS_arm64="$DEP_Fedora_arm64"
 
 verbose_echo Checking OVMF dependencies
 eval check-package \$DEP_"$DISTRO"_"$RAISIN_ARCH"
@@ -30,9 +34,20 @@ function ovmf_build() {
 git-checkout $OVMF_URL $OVMF_REVISION ovmf-dir
 cd ovmf-dir
 
-make -C BaseTools/Source/C
-OvmfPkg/build.sh -a X64 -b RELEASE -n 4
-cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
+make -C BaseTools
+
+if [[ $RAISIN_ARCH = "arm64" ]]
+then
+# Just use gcc4.8 flags for now: we have to specify a gcc
+# version and the 4.8 flags are almost identical to 4.9, etc.
+bash -c "source edksetup.sh && \
+ build -a AARCH64 -t GCC48 -p ArmVirtPkg/ArmVirtXen.dsc -b 
RELEASE"
+mkdir -p "$INST_DIR"/$PREFIX/lib/xen/boot
+cp Build/ArmVirtXen-AARCH64/RELEASE_GCC*/FV/XEN_EFI.fd 
"$INST_DIR"/$PREFIX/lib/xen/boot/XEN_EFI.fd
+else
+OvmfPkg/build.sh -a X64 -b RELEASE -n 4
+cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
+fi
 
 cd "$BASEDIR"
 }
-- 
1.7.9.5


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

Re: [Xen-devel] [PATCH v2] raisin: enable ovmf build for arm64

[Ian Campbell]

On Wed, 2015-10-14 at 16:57 +0100, Stefano Stabellini wrote:
> Disable ovmf build on x86_32: it does not work, the code was already
> forcing a x86_64 build.

FYI osstest builds OVMF (64-bit) in its build-i386 jobs just fine. e.g. in
[0]. That's useful in 32-on-64 type scenarios, maybe raisin doesn't want to
support those?

The build run for both x86's in xen.git is just:
OvmfPkg/build.sh -a X64 -b $(TARGET) -n 4
cp Build/OvmfX64/$(TARGET)_GCC*/FV/OVMF.fd ovmf.bin

Which looks pretty close to what you have below...

Ian

[0] 
http://logs.test-lab.xenproject.org/osstest/logs/62946/build-i386/5.ts-xen-build.log

> 
> ---
> 
> Changes in v2:
> - disable x86_32 build (it doesn't work, but it wasn't explicitly
>   disabled)
> - remove export GCC48_AARCH64_PREFIX= as it is not necessary
> - add a comment on why we are using -t GCC48
> ---
>  components/ovmf |   47 +++
>  1 file changed, 31 insertions(+), 16 deletions(-)
> 
> diff --git a/components/ovmf b/components/ovmf
> index ffdde19..48091ac 100644
> --- a/components/ovmf
> +++ b/components/ovmf
> @@ -1,24 +1,28 @@
>  #!/usr/bin/env bash
>  
>  function ovmf_skip() {
> -if [[ $RAISIN_ARCH != "x86_64" && $RAISIN_ARCH != "x86_32" ]]
> -then
> -return 0
> -else
> -return 1
> -fi
> +case $RAISIN_ARCH in
> +"arm32"|"x86_32" )
> +return 0
> +;;
> +"arm64"|"x86_64" )
> +return 1
> +;;
> +esac
>  }
>  
>  function ovmf_check_package() {
> -local DEP_Debian_common="build-essential nasm uuid-dev python iasl"
> -local DEP_Debian_x86_32="$DEP_Debian_common"
> -local DEP_Debian_x86_64="$DEP_Debian_common"
> -local DEP_Debian_arm32="$DEP_Debian_common"
> +local DEP_Debian_common="build-essential uuid-dev python iasl"
> +local DEP_Debian_x86_64="$DEP_Debian_common nasm"
>  local DEP_Debian_arm64="$DEP_Debian_common"
>  
> -local DEP_Fedora_common="make gcc gcc-c++ nasm libuuid-devel python
> acpica-tools"
> -local DEP_Fedora_x86_32="$DEP_Fedora_common"
> -local DEP_Fedora_x86_64="$DEP_Fedora_common"
> +local DEP_Fedora_common="make gcc gcc-c++ libuuid-devel python
> acpica-tools"
> +local DEP_Fedora_x86_64="$DEP_Fedora_common nasm"
> +local DEP_Fedora_arm64="$DEP_Debian_common"
> +
> +local DEP_CentOS_common="$DEP_Fedora_common"
> +local DEP_CentOS_x86_64="$DEP_Fedora_x86_64"
> +local DEP_CentOS_arm64="$DEP_Fedora_arm64"
>  
>  verbose_echo Checking OVMF dependencies
>  eval check-package \$DEP_"$DISTRO"_"$RAISIN_ARCH"
> @@ -30,9 +34,20 @@ function ovmf_build() {
>  git-checkout $OVMF_URL $OVMF_REVISION ovmf-dir
>  cd ovmf-dir
>  
> -make -C BaseTools/Source/C
> -OvmfPkg/build.sh -a X64 -b RELEASE -n 4
> -cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
> +make -C BaseTools
> +
> +if [[ $RAISIN_ARCH = "arm64" ]]
> +then
> +# Just use gcc4.8 flags for now: we have to specify a gcc
> +# version and the 4.8 flags are almost identical to 4.9, etc.
> +bash -c "source edksetup.sh && \
> + build -a AARCH64 -t GCC48 -p ArmVirtPkg/ArmVirtXen.dsc 
> -b RELEASE"
> +mkdir -p "$INST_DIR"/$PREFIX/lib/xen/boot
> +cp Build/ArmVirtXen-AARCH64/RELEASE_GCC*/FV/XEN_EFI.fd
> "$INST_DIR"/$PREFIX/lib/xen/boot/XEN_EFI.fd
> +else
> +OvmfPkg/build.sh -a X64 -b RELEASE -n 4
> +cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
> +fi
>  
>  cd "$BASEDIR"
>  }

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

[Xen-devel] xen,arm: enable cpu_hotplug

[Stefano Stabellini]

Hi all,

this small patch series enable cpu_hotplug in ARM and ARM64 guests,
using the PV path to plug and unplug the cpus and psci to enable/disable
them.


Stefano Stabellini (3):
  xen/arm: Enable cpu_hotplug.c
  xen, cpu_hotplug: call device_offline instead of cpu_down
  xen/arm: don't try to re-register vcpu_info on cpu_hotplug.

 arch/arm/include/asm/xen/hypervisor.h |8 
 arch/arm/xen/enlighten.c  |6 ++
 arch/x86/include/asm/xen/hypervisor.h |5 +
 arch/x86/xen/enlighten.c  |   15 +++
 drivers/xen/Makefile  |2 --
 drivers/xen/cpu_hotplug.c |9 ++---
 6 files changed, 40 insertions(+), 5 deletions(-)

Cheers,

Stefano

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

[Xen-devel] [PATCH 1/3] xen/arm: Enable cpu_hotplug.c

[Stefano Stabellini]

Build cpu_hotplug for ARM and ARM64 guests.

Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an
empty implementation on ARM and ARM64. On x86 just call
arch_(un)register_cpu as we are already doing.

Initialize cpu_hotplug on ARM.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/hypervisor.h |8 
 arch/x86/include/asm/xen/hypervisor.h |5 +
 arch/x86/xen/enlighten.c  |   15 +++
 drivers/xen/Makefile  |2 --
 drivers/xen/cpu_hotplug.c |6 --
 5 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypervisor.h 
b/arch/arm/include/asm/xen/hypervisor.h
index 04ff8e7..2bc418a 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -26,4 +26,12 @@ void __init xen_early_init(void);
 static inline void xen_early_init(void) { return; }
 #endif
 
+static inline void xen_arch_register_cpu(int num)
+{
+}
+
+static inline void xen_arch_unregister_cpu(int num)
+{
+}
+
 #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/x86/include/asm/xen/hypervisor.h 
b/arch/x86/include/asm/xen/hypervisor.h
index d866959..8b2d4be 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -57,4 +57,9 @@ static inline bool xen_x2apic_para_available(void)
 }
 #endif
 
+#ifdef CONFIG_HOTPLUG_CPU
+void xen_arch_register_cpu(int num);
+void xen_arch_unregister_cpu(int num);
+#endif
+
 #endif /* _ASM_X86_XEN_HYPERVISOR_H */
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 11d6fb4..ba62d8e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -71,6 +71,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_ACPI
 #include 
@@ -1868,3 +1869,17 @@ const struct hypervisor_x86 x86_hyper_xen = {
.set_cpu_features   = xen_set_cpu_features,
 };
 EXPORT_SYMBOL(x86_hyper_xen);
+
+#ifdef CONFIG_HOTPLUG_CPU
+void xen_arch_register_cpu(int num)
+{
+   arch_register_cpu(num);
+}
+EXPORT_SYMBOL(xen_arch_register_cpu);
+
+void xen_arch_unregister_cpu(int num)
+{
+   arch_unregister_cpu(num);
+}
+EXPORT_SYMBOL(xen_arch_unregister_cpu);
+#endif
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index e293bc5..aa8a7f7 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,6 +1,4 @@
-ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
 obj-$(CONFIG_HOTPLUG_CPU)  += cpu_hotplug.o
-endif
 obj-$(CONFIG_X86)  += fallback.o
 obj-y  += grant-table.o features.o balloon.o manage.o preempt.o
 obj-y  += events/
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index cc6513a..122b351 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -11,7 +11,7 @@
 static void enable_hotplug_cpu(int cpu)
 {
if (!cpu_present(cpu))
-   arch_register_cpu(cpu);
+   xen_arch_register_cpu(cpu);
 
set_cpu_present(cpu, true);
 }
@@ -19,7 +19,7 @@ static void enable_hotplug_cpu(int cpu)
 static void disable_hotplug_cpu(int cpu)
 {
if (cpu_present(cpu))
-   arch_unregister_cpu(cpu);
+   xen_arch_unregister_cpu(cpu);
 
set_cpu_present(cpu, false);
 }
@@ -102,8 +102,10 @@ static int __init setup_vcpu_hotplug_event(void)
static struct notifier_block xsn_cpu = {
.notifier_call = setup_cpu_watcher };
 
+#ifdef CONFIG_X86
if (!xen_pv_domain())
return -ENODEV;
+#endif
 
register_xenstore_notifier(_cpu);
 
-- 
1.7.9.5


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

[Xen-devel] [PATCH 2/3] xen, cpu_hotplug: call device_offline instead of cpu_down

[Stefano Stabellini]

When offlining a cpu, instead of cpu_down, call device_offline, which
also takes care of updating the cpu.dev.offline field. This keeps the
sysfs file /sys/devices/system/cpu/cpuN/online, up to date.  Also move
the call to disable_hotplug_cpu, because it makes more sense to have it
there.

Signed-off-by: Stefano Stabellini 
---
 drivers/xen/cpu_hotplug.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 122b351..785f9ce 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -18,6 +18,8 @@ static void enable_hotplug_cpu(int cpu)
 
 static void disable_hotplug_cpu(int cpu)
 {
+   if (cpu_online(cpu))
+   device_offline(get_cpu_device(cpu));
if (cpu_present(cpu))
xen_arch_unregister_cpu(cpu);
 
@@ -55,7 +57,6 @@ static void vcpu_hotplug(unsigned int cpu)
enable_hotplug_cpu(cpu);
break;
case 0:
-   (void)cpu_down(cpu);
disable_hotplug_cpu(cpu);
break;
default:
-- 
1.7.9.5


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

[Xen-devel] [PATCH 3/5] raisin: Allow iasl to alias acpica-tools, unify Fedora and CentOS deps for xen

[George Dunlap]

CentOS 7 now aliases acpica-tools instead of iasl, making its deps
essentially the same as Fedora.  Add iasl|acpica-tools as an alias in
the Fedora deps, and make the CentOS deps a straight clone of the
Fedora deps (as they are for the other components).

Signed-off-by: George Dunlap 
---
 components/xen | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/components/xen b/components/xen
index 93ed288..4c37cca 100644
--- a/components/xen
+++ b/components/xen
@@ -25,12 +25,12 @@ function xen_check_package() {
 then
DEP_Fedora_common="$DEP_Fedora_common 
systemd-devel|systemd-container-devel"
 fi
-local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools texinfo"
+local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 iasl|acpica-tools 
texinfo"
 local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
 
 local DEP_CentOS_common="$DEP_Fedora_common"
-local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
-local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
+local DEP_CentOS_x86_32="$DEP_Fedora_x86_32"
+local DEP_CentOS_x86_64="$DEP_Fedora_x86_64"
 
 
 verbose_echo Checking Xen dependencies
-- 
2.1.4


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

[Xen-devel] [PATCH 2/5] raisin: Detect systemd

[George Dunlap]

Add systemd development libraries if we detect systemd present on the system

Signed-off-by: George Dunlap 
---
 components/xen | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/components/xen b/components/xen
index 090cceb..93ed288 100644
--- a/components/xen
+++ b/components/xen
@@ -8,6 +8,11 @@ function xen_check_package() {
 local DEP_Debian_common="build-essential python-dev gettext uuid-dev   \
  libncurses5-dev libyajl-dev libaio-dev pkg-config libglib2.0-dev  
\
  libssl-dev libpixman-1-dev bridge-utils wget"
+
+if [[ -e "/usr/lib/systemd" ]]
+then
+   DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
+fi
 local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86 texinfo"
 local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
 local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
@@ -16,6 +21,10 @@ function xen_check_package() {
 local DEP_Fedora_common="make gcc python-devel gettext libuuid-devel   \
  ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel   
\
  patch pixman-devel glibc-devel bridge-utils grub2 wget tar bzip2"
+if [[ -e "/usr/lib/systemd" ]]
+then
+   DEP_Fedora_common="$DEP_Fedora_common 
systemd-devel|systemd-container-devel"
+fi
 local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools texinfo"
 local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
 
@@ -23,6 +32,7 @@ function xen_check_package() {
 local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
 local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
 
+
 verbose_echo Checking Xen dependencies
 eval check-package \$DEP_"$DISTRO"_"$RAISIN_ARCH"
 }
-- 
2.1.4


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

[Xen-devel] [PATCH 4/5] raisin: Change update/release parsing OSes

[George Dunlap]

At the moment, something like 7.1.1503 will be parsed as RELEASE=7.1
UPDATE=1503.  Change the bash string so that RELEASE=7 UPDATE=1.1503
in this case.

Also add an example CentOS 7 release string, and add the RELEASE /
UPDATE parsing to lsb_release as well.

Signed-off-by: George Dunlap 
---
 lib/common-functions.sh | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/common-functions.sh b/lib/common-functions.sh
index a389054..1343dc8 100644
--- a/lib/common-functions.sh
+++ b/lib/common-functions.sh
@@ -103,13 +103,15 @@ function get_distro() {
 os_VENDOR=`lsb_release -i -s`
 os_RELEASE=`lsb_release -r -s`
 os_CODENAME=`lsb_release -c -s`
-os_UPDATE=""
+os_UPDATE=${os_RELEASE#*.}
+os_RELEASE=${os_RELEASE%%.*}
 elif [[ -r /etc/redhat-release ]]
 then
 # Red Hat Enterprise Linux Server release 5.5 (Tikanga)
 # Red Hat Enterprise Linux Server release 7.0 Beta (Maipo)
 # CentOS release 5.5 (Final)
 # CentOS Linux release 6.0 (Final)
+# CentOS Linux release 7.1.1503 (Core)
 # Fedora release 16 (Verne)
 # XenServer release 6.2.0-70446c (xenenterprise)
 os_CODENAME=""
@@ -120,8 +122,8 @@ function get_distro() {
 ver=`sed -e 's/^.* \([0-9].*\) (\(.*\)).*$/\1\|\2/' 
/etc/redhat-release`
 os_CODENAME=${ver#*|}
 os_RELEASE=${ver%|*}
-os_UPDATE=${os_RELEASE##*.}
-os_RELEASE=${os_RELEASE%.*}
+os_UPDATE=${os_RELEASE#*.}
+os_RELEASE=${os_RELEASE%%.*}
 break
 fi
 done
-- 
2.1.4


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

[Xen-devel] [PATCH 1/5] raisin: Handle aliases for packages, add pciutils-dev / libpci-dev alias

[George Dunlap]

It's not uncommon for packages to be renamed, and for package managers
to know the translation from old packages to new packages.  For
example:

# apt-get install pciutils-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libpci-dev' instead of 'pciutils-dev'
libpci-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

So the command succeeds, but the subsequent package check still fails,
cince "pciutils-dev" wasn't actually installed.  This means that even
after running "install-builddep", "build" will prompt you to install the
old package every time.

Allow components to specify known aliases for a given package by
speficying a a|b|c.  Check-package will check consecutively for a, b,
and c; if it finds any of them, it will stop looking and install
nothing.  If it finds nothing, it will add the first package to the
missing_packages list.

Assuming that package managers are backwards-compatible, components
should put the oldest known package first for maximum compatibility.

Also add such an alias for pciutils-dev|libpci-dev in qemu_traditional

Signed-off-by: George Dunlap 
---
 components/qemu_traditional |  2 +-
 lib/common-functions.sh | 25 -
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/components/qemu_traditional b/components/qemu_traditional
index 3150c3e..d73c6b8 100644
--- a/components/qemu_traditional
+++ b/components/qemu_traditional
@@ -10,7 +10,7 @@ function qemu_traditional_skip() {
 }
 
 function qemu_traditional_check_package() {
-local DEP_Debian_common="build-essential zlib1g-dev pciutils-dev 
pkg-config \
+local DEP_Debian_common="build-essential zlib1g-dev 
pciutils-dev|libpci-dev pkg-config \
   libncurses5-dev"
 local DEP_Debian_x86_32="$DEP_Debian_common"
 local DEP_Debian_x86_64="$DEP_Debian_common"
diff --git a/lib/common-functions.sh b/lib/common-functions.sh
index 03642ae..a389054 100644
--- a/lib/common-functions.sh
+++ b/lib/common-functions.sh
@@ -233,14 +233,29 @@ function _install-package-unknown() {
 
 # Modifies inherited variable "missing"
 function check-package() {
+local OIFS=${IFS}
+local p
+local x
+
 for p in $*
 do
-if ! _check-package-${PKGTYPE} $p
-then
-missing+=("$p")
-fi
+   local found=false
+   IFS='|'
+   for x in $p
+   do
+if _check-package-${PKGTYPE} $x
+then
+   found=true
+fi
+   done
+   IFS="$OIFS"
+   if ! $found
+   then
+   # Add the first of the aliases, on the assumption that the package
+   # manager will be backwards-compatible
+   missing+=("${p%%|*}")
+   fi
 done
-
 }
 
 function install-package() {
-- 
2.1.4


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

[Xen-devel] [PATCH 3/3] xen/arm: don't try to re-register vcpu_info on cpu_hotplug.

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6c09cc4..59f5421 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -93,6 +93,12 @@ static void xen_percpu_init(void)
int err;
int cpu = get_cpu();
 
+   /* vcpu_info already registered, can happen with cpu-hotplug */
+   if (per_cpu(xen_vcpu, cpu) != NULL) {
+   put_cpu();
+   return;
+   }
+
pr_info("Xen: initializing cpu%d\n", cpu);
vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
 
-- 
1.7.9.5


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

Re: [Xen-devel] [PATCH 1/3] xen/arm: Enable cpu_hotplug.c

[Konrad Rzeszutek Wilk]

On October 14, 2015 1:49:55 PM EDT, Stefano Stabellini 
 wrote:
>Build cpu_hotplug for ARM and ARM64 guests.
>
>Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an
>empty implementation on ARM and ARM64. On x86 just call
>arch_(un)register_cpu as we are already doing.
>
>Initialize cpu_hotplug on ARM.

Have you tested this on x86? As your changes touch the generic code path.

>
>Signed-off-by: Stefano Stabellini 
>---
> arch/arm/include/asm/xen/hypervisor.h |8 
> arch/x86/include/asm/xen/hypervisor.h |5 +
> arch/x86/xen/enlighten.c  |   15 +++
> drivers/xen/Makefile  |2 --
> drivers/xen/cpu_hotplug.c |6 --
> 5 files changed, 32 insertions(+), 4 deletions(-)
>
>diff --git a/arch/arm/include/asm/xen/hypervisor.h
>b/arch/arm/include/asm/xen/hypervisor.h
>index 04ff8e7..2bc418a 100644
>--- a/arch/arm/include/asm/xen/hypervisor.h
>+++ b/arch/arm/include/asm/xen/hypervisor.h
>@@ -26,4 +26,12 @@ void __init xen_early_init(void);
> static inline void xen_early_init(void) { return; }
> #endif
> 
>+static inline void xen_arch_register_cpu(int num)
>+{
>+}
>+
>+static inline void xen_arch_unregister_cpu(int num)
>+{
>+}
>+
> #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
>diff --git a/arch/x86/include/asm/xen/hypervisor.h
>b/arch/x86/include/asm/xen/hypervisor.h
>index d866959..8b2d4be 100644
>--- a/arch/x86/include/asm/xen/hypervisor.h
>+++ b/arch/x86/include/asm/xen/hypervisor.h
>@@ -57,4 +57,9 @@ static inline bool xen_x2apic_para_available(void)
> }
> #endif
> 
>+#ifdef CONFIG_HOTPLUG_CPU
>+void xen_arch_register_cpu(int num);
>+void xen_arch_unregister_cpu(int num);
>+#endif
>+
> #endif /* _ASM_X86_XEN_HYPERVISOR_H */
>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>index 11d6fb4..ba62d8e 100644
>--- a/arch/x86/xen/enlighten.c
>+++ b/arch/x86/xen/enlighten.c
>@@ -71,6 +71,7 @@
> #include 
> #include 
> #include 
>+#include 
> 
> #ifdef CONFIG_ACPI
> #include 
>@@ -1868,3 +1869,17 @@ const struct hypervisor_x86 x86_hyper_xen = {
>   .set_cpu_features   = xen_set_cpu_features,
> };
> EXPORT_SYMBOL(x86_hyper_xen);
>+
>+#ifdef CONFIG_HOTPLUG_CPU
>+void xen_arch_register_cpu(int num)
>+{
>+  arch_register_cpu(num);
>+}
>+EXPORT_SYMBOL(xen_arch_register_cpu);
>+
>+void xen_arch_unregister_cpu(int num)
>+{
>+  arch_unregister_cpu(num);
>+}
>+EXPORT_SYMBOL(xen_arch_unregister_cpu);
>+#endif
>diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>index e293bc5..aa8a7f7 100644
>--- a/drivers/xen/Makefile
>+++ b/drivers/xen/Makefile
>@@ -1,6 +1,4 @@
>-ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
> obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
>-endif
> obj-$(CONFIG_X86) += fallback.o
> obj-y += grant-table.o features.o balloon.o manage.o preempt.o
> obj-y += events/
>diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
>index cc6513a..122b351 100644
>--- a/drivers/xen/cpu_hotplug.c
>+++ b/drivers/xen/cpu_hotplug.c
>@@ -11,7 +11,7 @@
> static void enable_hotplug_cpu(int cpu)
> {
>   if (!cpu_present(cpu))
>-  arch_register_cpu(cpu);
>+  xen_arch_register_cpu(cpu);
> 
>   set_cpu_present(cpu, true);
> }
>@@ -19,7 +19,7 @@ static void enable_hotplug_cpu(int cpu)
> static void disable_hotplug_cpu(int cpu)
> {
>   if (cpu_present(cpu))
>-  arch_unregister_cpu(cpu);
>+  xen_arch_unregister_cpu(cpu);
> 
>   set_cpu_present(cpu, false);
> }
>@@ -102,8 +102,10 @@ static int __init setup_vcpu_hotplug_event(void)
>   static struct notifier_block xsn_cpu = {
>   .notifier_call = setup_cpu_watcher };
> 
>+#ifdef CONFIG_X86
>   if (!xen_pv_domain())
>   return -ENODEV;
>+#endif
> 
>   register_xenstore_notifier(_cpu);
> 



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

[Xen-devel] [PATCH 0/5] raisin: Miscelaneous improvements

[George Dunlap]

Miscellaneous improvements

George Dunlap (5):
  raisin: Handle aliases for packages, add pciutils-dev / libpci-dev
alias
  raisin: Detect systemd
  raisin: Allow iasl to alias acpica-tools, unify Fedora and CentOS deps
for xen
  raisin: Change update/release parsing OSes
  raisin: Add XEN_CONFIG_EXTRA to config file

 components/qemu_traditional |  2 +-
 components/xen  | 18 ++
 configs/config-4.5  |  4 
 configs/config-4.6  |  4 
 configs/config-master   |  4 
 lib/common-functions.sh | 33 +
 6 files changed, 52 insertions(+), 13 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 5/5] raisin: Add XEN_CONFIG_EXTRA to config file

[George Dunlap]

Allowing the user to enable or disable specific functionality, such as
stubdoms.

Signed-off-by: George Dunlap 
---
 components/xen| 2 +-
 configs/config-4.5| 4 
 configs/config-4.6| 4 
 configs/config-master | 4 
 4 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/components/xen b/components/xen
index 4c37cca..06806b5 100644
--- a/components/xen
+++ b/components/xen
@@ -53,7 +53,7 @@ function xen_build() {
 ovmf_opt="--enable-ovmf 
--with-system-ovmf="$BASEDIR"/ovmf-dir/ovmf.bin"
 fi
 ./configure --prefix=$PREFIX 
--with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
---disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt
+--disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt 
$XEN_CONFIG_EXTRA
 $RAISIN_MAKE
 $RAISIN_MAKE install DESTDIR="$INST_DIR"
 cd "$BASEDIR"
diff --git a/configs/config-4.5 b/configs/config-4.5
index e3b92d5..1fe86c7 100644
--- a/configs/config-4.5
+++ b/configs/config-4.5
@@ -41,6 +41,10 @@ LIBVIRT_REVISION="origin/xen-tested-master"
 OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
 LINUX_REVISION="master"
 
+# Per-project options
+## Passed to "./configure" when building Xen.  Use to enable or disable 
specific features
+# XEN_CONFIG_EXTRA="--disable-stubdom"
+
 # Tests
 ## All tests: busybox-pv busybox-hvm
 ## ENABLED_TESTS is the list of test run by raise test
diff --git a/configs/config-4.6 b/configs/config-4.6
index ebd45e7..623d43c 100644
--- a/configs/config-4.6
+++ b/configs/config-4.6
@@ -41,6 +41,10 @@ LIBVIRT_REVISION="origin/xen-tested-master"
 OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
 LINUX_REVISION="master"
 
+# Per-project options
+## Passed to "./configure" when building Xen.  Use to enable or disable 
specific features
+# XEN_CONFIG_EXTRA="--disable-stubdom"
+
 # Tests
 ## All tests: busybox-pv busybox-hvm
 ## ENABLED_TESTS is the list of test run by raise test
diff --git a/configs/config-master b/configs/config-master
index b218708..7d2f822 100644
--- a/configs/config-master
+++ b/configs/config-master
@@ -40,6 +40,10 @@ LIBVIRT_REVISION="origin/xen-tested-master"
 OVMF_REVISION="origin/xen-tested-master"
 LINUX_REVISION="master"
 
+# Per-project options
+## Passed to "./configure" when building Xen.  Use to enable or disable 
specific features
+# XEN_CONFIG_EXTRA="--disable-stubdom"
+
 # Tests
 ## All tests: busybox-pv busybox-hvm
 ## ENABLED_TESTS is the list of test run by raise test
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 2/5] raisin: Detect systemd

[George Dunlap]

On 14/10/15 17:21, George Dunlap wrote:
> Add systemd development libraries if we detect systemd present on the system
> 
> Signed-off-by: George Dunlap 

Sorry, meant to add a comment here...

> ---
>  components/xen | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/components/xen b/components/xen
> index 090cceb..93ed288 100644
> --- a/components/xen
> +++ b/components/xen
> @@ -8,6 +8,11 @@ function xen_check_package() {
>  local DEP_Debian_common="build-essential python-dev gettext uuid-dev   \
>   libncurses5-dev libyajl-dev libaio-dev pkg-config 
> libglib2.0-dev  \
>   libssl-dev libpixman-1-dev bridge-utils wget"
> +
> +if [[ -e "/usr/lib/systemd" ]]
> +then
> + DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
> +fi
>  local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86 texinfo"
>  local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
>  local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
> @@ -16,6 +21,10 @@ function xen_check_package() {
>  local DEP_Fedora_common="make gcc python-devel gettext libuuid-devel   \
>   ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel 
>   \
>   patch pixman-devel glibc-devel bridge-utils grub2 wget tar 
> bzip2"
> +if [[ -e "/usr/lib/systemd" ]]
> +then
> + DEP_Fedora_common="$DEP_Fedora_common 
> systemd-devel|systemd-container-devel"
> +fi

This is a bit dodgy, as basically CentOS (and I think Fedora) have
separate packages for systemd when inside a container vs on real
hardware.  But unfortunately I'm not sure there's a way to make yum
smart enough to know, "Gee, I'm in a container, I should run systemd
instead".

Having the "alias" like this allows the user to work around it by
manually installing systemd-container-devel.  It's not great though,
because there's still nothing to prompt the user to install the correct
package.

Also...

>  local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools texinfo"
>  local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
>  
> @@ -23,6 +32,7 @@ function xen_check_package() {
>  local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
>  local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
>  
> +

Oops.

 -George


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

Re: [Xen-devel] [PATCH RFC 2/3] xen/hvm: introduce a fpu_initialised filed to the CPU save record

[Andrew Cooper]

On 14/10/15 17:24, Roger Pau Monne wrote:
> Introduce a new filed to signal if the FPU has been initialised or not. Xen

"field", I am guessing?

> diff --git a/xen/include/public/arch-x86/hvm/save.h 
> b/xen/include/public/arch-x86/hvm/save.h
> index c7560f2..c4863be 100644
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -47,7 +47,8 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
>  /*
>   * Processor
>   *
> - * Compat: Pre-3.4 didn't have msr_tsc_aux
> + * Compat2: Pre-4.7 didn't have fpu_initialised
> + * Compat1: Pre-3.4 didn't have msr_tsc_aux

I would suggest reversing the Compat1 and 2 lines, to match chronology.

>   */
>  
>  struct hvm_hw_cpu {
> @@ -157,9 +158,121 @@ struct hvm_hw_cpu {
>  };
>  /* error code for pending event */
>  uint32_t error_code;
> +/* is fpu initialised? */
> +uint8_t fpu_initialised:1;

Bitfields can't be used in the public ABI, and please don't leave
trailing implicit padding.

I would recommend uint32_t flags and specify that bit 0 indicates that
fpu context is initialised.

~Andrew

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

Re: [Xen-devel] [PATCH QEMU-XEN v3 5/8] xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory API.

[Stefano Stabellini]

On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 17:29 +0100, Stefano Stabellini wrote:
> 
> > > Obviously the call to xen_be_unbind_evtchn is not useful as is, but I do
> > > wonder where the evtchn which the primary console must have somewhere
> > > actually is then...
> > 
> > Actually I think that xen_be_unbind_evtchn might be useful too, I think
> > that is the primary console evtchn. I wonder what specific bug I was
> > trying to fix when I introduced that if (!xendev->dev) check.
> 
> I misread xen_be_unbind_evtchn(>xendev) as taking xendev->dev instead,
> which would be NULL and hence pointless... But given that it isn't then yes
> it seems like it would be worth calling.
> 
> Is it not the case that >xendev == xendev here, leading to another
> potential cleanup?

Yes, it is the same

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

Re: [Xen-devel] [PATCH RFC 3/3] Revert "libxc: create an initial FPU state for HVM guests"

[Wei Liu]

On Wed, Oct 14, 2015 at 06:24:40PM +0200, Roger Pau Monne wrote:
> This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad.
> 
> Xen always set the FPU as initialized when loading a HVM context, so libxc
> has to provide a valid FPU context when setting the CPU registers.
> 
> This is a stop-gap measure in order to unblock OSSTest Windows 7 failures
> while a proper fix for the HVM CPU save/restore is being worked on.

I think it is better to say in the commit message that a proper fix is
in place so we can revert the stop-gap patch instead of copying the
commit message from the patch this is being reverted.

Assuming I'm right about a proper fix will be committed before this
patch and the commit message fixed:

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH RFC 3/3] Revert "libxc: create an initial FPU state for HVM guests"

[Roger Pau Monne]

This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad.

Xen always set the FPU as initialized when loading a HVM context, so libxc
has to provide a valid FPU context when setting the CPU registers.

This is a stop-gap measure in order to unblock OSSTest Windows 7 failures
while a proper fix for the HVM CPU save/restore is being worked on.

Signed-off-by: Roger Pau Monné 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxc/xc_dom_x86.c | 38 --
 1 file changed, 38 deletions(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 034abe0..dd331bf 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -841,27 +841,6 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 struct hvm_save_descriptor end_d;
 HVM_SAVE_TYPE(END) end;
 } bsp_ctx;
-/*
- * The layout of the fpu context structure is the same for
- * both 32 and 64 bits.
- */
-struct {
-uint16_t fcw;
-uint16_t fsw;
-uint8_t ftw;
-uint8_t rsvd1;
-uint16_t fop;
-union {
-uint64_t addr;
-struct {
-uint32_t offs;
-uint16_t sel;
-uint16_t rsvd;
-};
-} fip, fdp;
-uint32_t mxcsr;
-uint32_t mxcsr_mask;
-} *fpu_ctxt;
 uint8_t *full_ctx = NULL;
 int rc;
 
@@ -929,23 +908,6 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 /* Set the control registers. */
 bsp_ctx.cpu.cr0 = X86_CR0_PE | X86_CR0_ET;
 
-/*
- * XXX: Set initial FPU state.
- *
- * This should be removed once Xen is able to know if the
- * FPU state saved is valid or not, now Xen always sets
- * fpu_initialised to true regardless of the FPU state.
- *
- * The code below mimics the FPU sate after executing
- * fninit
- * ldmxcsr 0x1f80
- */
-fpu_ctxt = (typeof(fpu_ctxt))bsp_ctx.cpu.fpu_regs;
-
-fpu_ctxt->fcw = 0x37f;
-fpu_ctxt->ftw = 0xff;
-fpu_ctxt->mxcsr = 0x1f80;
-
 /* Set the IP. */
 bsp_ctx.cpu.rip = dom->parms.phys_entry;
 
-- 
1.9.5 (Apple Git-50.3)


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

Re: [Xen-devel] [PATCH QEMU-XEN v3 5/8] xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory API.

[Ian Campbell]

On Wed, 2015-10-14 at 17:29 +0100, Stefano Stabellini wrote:

> > Obviously the call to xen_be_unbind_evtchn is not useful as is, but I do
> > wonder where the evtchn which the primary console must have somewhere
> > actually is then...
> 
> Actually I think that xen_be_unbind_evtchn might be useful too, I think
> that is the primary console evtchn. I wonder what specific bug I was
> trying to fix when I introduced that if (!xendev->dev) check.

I misread xen_be_unbind_evtchn(>xendev) as taking xendev->dev instead,
which would be NULL and hence pointless... But given that it isn't then yes
it seems like it would be worth calling.

Is it not the case that >xendev == xendev here, leading to another
potential cleanup?

Ian.

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

[Xen-devel] [PATCH RFC 2/3] xen/hvm: introduce a fpu_initialised filed to the CPU save record

[Roger Pau Monne]

Introduce a new filed to signal if the FPU has been initialised or not. Xen
needs this new filed in order to know whether to set the FPU as initialised
or not during restore of CPU context. Previously Xen always wrongly assumed
the FPU was initialised on restore.

Signed-off-by: Roger Pau Monné 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/hvm.c |   5 +-
 xen/include/public/arch-x86/hvm/save.h | 146 ++---
 2 files changed, 139 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 3fa2280..e71570c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1796,6 +1796,7 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt.fpu_regs));
 else 
 memset(ctxt.fpu_regs, 0, sizeof(ctxt.fpu_regs));
+ctxt.fpu_initialised = v->fpu_initialised;
 
 ctxt.rax = v->arch.user_regs.eax;
 ctxt.rbx = v->arch.user_regs.ebx;
@@ -1975,7 +1976,7 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
-if ( hvm_load_entry(CPU, h, ) != 0 ) 
+if ( hvm_load_entry_zeroextend(CPU, h, ) != 0 )
 return -EINVAL;
 
 /* Sanity check some control registers. */
@@ -2118,7 +2119,7 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 v->arch.debugreg[7] = ctxt.dr7;
 
 v->arch.vgc_flags = VGCF_online;
-v->fpu_initialised = 1;
+v->fpu_initialised = ctxt.fpu_initialised;
 
 /* Auxiliary processors should be woken immediately. */
 v->is_initialised = 1;
diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index c7560f2..c4863be 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -47,7 +47,8 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
 /*
  * Processor
  *
- * Compat: Pre-3.4 didn't have msr_tsc_aux
+ * Compat2: Pre-4.7 didn't have fpu_initialised
+ * Compat1: Pre-3.4 didn't have msr_tsc_aux
  */
 
 struct hvm_hw_cpu {
@@ -157,9 +158,121 @@ struct hvm_hw_cpu {
 };
 /* error code for pending event */
 uint32_t error_code;
+/* is fpu initialised? */
+uint8_t fpu_initialised:1;
 };
 
-struct hvm_hw_cpu_compat {
+struct hvm_hw_cpu_compat2 {
+uint8_t  fpu_regs[512];
+
+uint64_t rax;
+uint64_t rbx;
+uint64_t rcx;
+uint64_t rdx;
+uint64_t rbp;
+uint64_t rsi;
+uint64_t rdi;
+uint64_t rsp;
+uint64_t r8;
+uint64_t r9;
+uint64_t r10;
+uint64_t r11;
+uint64_t r12;
+uint64_t r13;
+uint64_t r14;
+uint64_t r15;
+
+uint64_t rip;
+uint64_t rflags;
+
+uint64_t cr0;
+uint64_t cr2;
+uint64_t cr3;
+uint64_t cr4;
+
+uint64_t dr0;
+uint64_t dr1;
+uint64_t dr2;
+uint64_t dr3;
+uint64_t dr6;
+uint64_t dr7;
+
+uint32_t cs_sel;
+uint32_t ds_sel;
+uint32_t es_sel;
+uint32_t fs_sel;
+uint32_t gs_sel;
+uint32_t ss_sel;
+uint32_t tr_sel;
+uint32_t ldtr_sel;
+
+uint32_t cs_limit;
+uint32_t ds_limit;
+uint32_t es_limit;
+uint32_t fs_limit;
+uint32_t gs_limit;
+uint32_t ss_limit;
+uint32_t tr_limit;
+uint32_t ldtr_limit;
+uint32_t idtr_limit;
+uint32_t gdtr_limit;
+
+uint64_t cs_base;
+uint64_t ds_base;
+uint64_t es_base;
+uint64_t fs_base;
+uint64_t gs_base;
+uint64_t ss_base;
+uint64_t tr_base;
+uint64_t ldtr_base;
+uint64_t idtr_base;
+uint64_t gdtr_base;
+
+uint32_t cs_arbytes;
+uint32_t ds_arbytes;
+uint32_t es_arbytes;
+uint32_t fs_arbytes;
+uint32_t gs_arbytes;
+uint32_t ss_arbytes;
+uint32_t tr_arbytes;
+uint32_t ldtr_arbytes;
+
+uint64_t sysenter_cs;
+uint64_t sysenter_esp;
+uint64_t sysenter_eip;
+
+/* msr for em64t */
+uint64_t shadow_gs;
+
+/* msr content saved/restored. */
+uint64_t msr_flags;
+uint64_t msr_lstar;
+uint64_t msr_star;
+uint64_t msr_cstar;
+uint64_t msr_syscall_mask;
+uint64_t msr_efer;
+uint64_t msr_tsc_aux;
+
+/* guest's idea of what rdtsc() would return */
+uint64_t tsc;
+
+/* pending event, if any */
+union {
+uint32_t pending_event;
+struct {
+uint8_t  pending_vector:8;
+uint8_t  pending_type:3;
+uint8_t  pending_error_valid:1;
+uint32_t pending_reserved:19;
+uint8_t  pending_valid:1;
+};
+};
+/* error code for pending event */
+uint32_t error_code;
+/*uint8_t fpu_initialised:1; COMPAT */
+};
+
+struct hvm_hw_cpu_compat1 {
 uint8_t  fpu_regs[512];
 
 uint64_t rax;
@@ -266,27 +379,40 @@ struct hvm_hw_cpu_compat {
 };
 /* error code for pending event */
 

[Xen-devel] [PATCH RFC 1/3] xen/save: pass a size paramter to the HVM compat functions

[Roger Pau Monne]

In order to cope with types having multiple compat versions pass a parameter
to the fixup function so we can identify which compat version Xen is dealing
with.

Signed-off-by: Roger Pau Monné 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Tim Deegan 
---
 xen/include/public/arch-x86/hvm/save.h |  2 +-
 xen/include/public/hvm/save.h  | 10 ++
 xen/include/xen/hvm/save.h |  2 +-
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index efb0b62..c7560f2 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -268,7 +268,7 @@ struct hvm_hw_cpu_compat {
 uint32_t error_code;
 };
 
-static inline int _hvm_hw_fix_cpu(void *h) {
+static inline int _hvm_hw_fix_cpu(void *h, int size) {
 
 union hvm_hw_cpu_union {
 struct hvm_hw_cpu nat;
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index cc8b5fd..411871e 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -63,13 +63,15 @@ struct hvm_save_descriptor {
 
 #ifdef __XEN__
 # define DECLARE_HVM_SAVE_TYPE_COMPAT(_x, _code, _type, _ctype, _fix) \
-static inline int __HVM_SAVE_FIX_COMPAT_##_x(void *h) { return _fix(h); } \
-struct __HVM_SAVE_TYPE_##_x { _type t; char c[_code]; char cpt[2];}; \
+static inline int __HVM_SAVE_FIX_COMPAT_##_x(void *h, int size)   \
+{ return _fix(h, size); } \
+struct __HVM_SAVE_TYPE_##_x { _type t; char c[_code]; char cpt[2];};  \
 struct __HVM_SAVE_TYPE_COMPAT_##_x { _ctype t; }   
 
 # include  /* BUG() */
 # define DECLARE_HVM_SAVE_TYPE(_x, _code, _type) \
-static inline int __HVM_SAVE_FIX_COMPAT_##_x(void *h) { BUG(); return -1; 
} \
+static inline int __HVM_SAVE_FIX_COMPAT_##_x(void *h, int size)  \
+{ BUG(); return -1; }\
 struct __HVM_SAVE_TYPE_##_x { _type t; char c[_code]; char cpt[1];}; \
 struct __HVM_SAVE_TYPE_COMPAT_##_x { _type t; }   
 #else
@@ -89,7 +91,7 @@ struct hvm_save_descriptor {
 # define HVM_SAVE_LENGTH_COMPAT(_x) (sizeof (HVM_SAVE_TYPE_COMPAT(_x)))
 
 # define HVM_SAVE_HAS_COMPAT(_x) (sizeof (((struct __HVM_SAVE_TYPE_##_x 
*)(0))->cpt)-1)
-# define HVM_SAVE_FIX_COMPAT(_x, _dst) __HVM_SAVE_FIX_COMPAT_##_x(_dst)
+# define HVM_SAVE_FIX_COMPAT(_x, _dst, _code) __HVM_SAVE_FIX_COMPAT_##_x(_dst, 
_code)
 #endif
 
 /* 
diff --git a/xen/include/xen/hvm/save.h b/xen/include/xen/hvm/save.h
index aa27a50..14e6754 100644
--- a/xen/include/xen/hvm/save.h
+++ b/xen/include/xen/hvm/save.h
@@ -67,7 +67,7 @@ void _hvm_read_entry(struct hvm_domain_context *h,
  && (r = _hvm_check_entry((_h), HVM_SAVE_CODE(_x),  \
HVM_SAVE_LENGTH_COMPAT(_x), (_strict))) == 0 ) { \
 _hvm_read_entry((_h), (_dst), HVM_SAVE_LENGTH_COMPAT(_x));  \
-r=HVM_SAVE_FIX_COMPAT(_x, (_dst));  \
+r=HVM_SAVE_FIX_COMPAT(_x, (_dst), (_h)->size);  \
 }   \
 r; })
 
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH RFC 0/3] Introduce a fpu_initilised filed to HVM CPU context

[Roger Pau Monne]

Hello,

This patch series tries to properly solve the problem seen with the HVMlite 
series, that Xen always assumes the FPU is initialised on CPU context 
restore.

Since I don't have a pre-3.4 Xen box, I would like to request if this patch 
series can be tested by the XenServer CI loop, which I've heard tests 
migrations between very old Xen versions.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH QEMU-XEN v3 5/8] xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory API.

[Stefano Stabellini]

On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 16:41 +0100, Stefano Stabellini wrote:
> > On Wed, 14 Oct 2015, Ian Campbell wrote:
> > > On Wed, 2015-10-14 at 15:10 +0100, Stefano Stabellini wrote:
> > > > On Wed, 7 Oct 2015, Ian Campbell wrote:
> > > > > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > > > > separate libraries which will provide backward and forward API and
> > > > > ABI
> > > > > compatiblity.
> > > > > 
> > > > > One such library will be libxenforeignmemory which provides access
> > > > > to
> > > > > privileged foreign mappings and which will provide an interface
> > > > > equivalent to xc_map_foreign_bulk.
> > > > > 
> > > > > In preparation for adding support for libxenforeignmemory add
> > > > > support
> > > > > to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
> > > > > switch to using the new API. These shims will disappear for
> > > > > versions
> > > > > of Xen which include libxenforeignmemory.
> > > > > 
> > > > > Since libxenforeignmemory will have its own handle type but for <=
> > > > > 4.6
> > > > > the functionality is provided by using a libxenctrl handle we
> > > > > introduce a new global xen_fmem alongside the existing xen_xc. In
> > > > > fact
> > > > > we make xen_fmem a pointer to the existing xen_xc, which then works
> > > > > correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc
> > > > > handle
> > > > > is a pointer). In the latter case xen_fmem is actually a double
> > > > > indirect pointer, but it all falls out in the wash.
> > > > > 
> > > > > Unlike libxenctrl libxenforeignmemory has an explicit unmap
> > > > > function,
> > > > > rather than just specifying that munmap should be used, so the
> > > > > unmap
> > > > > paths are updated to use xenforeignmemory_unmap, which is a shim
> > > > > for
> > > > > munmap on these versions of xen. The mappings in xen-hvm.c do not
> > > > > appear to be unmapped (which makes sense for a qemu-dm process)
> > > > > 
> > > > > In fb_disconnect this results in a change from simply mmap over the
> > > > > existing mapping (with an implciit munmap) to expliclty unmapping
> > > > > with
> > > > > xenforeignmemory_unmap and then mapping the required anonymous
> > > > > memory
> > > > > in the same hole. I don't think this is a problem since any other
> > > > > thread which was racily touching this region would already be
> > > > > running
> > > > > the risk of hitting the mapping halfway through the call. If this
> > > > > is
> > > > > thought to be a problem then we could consider adding an extra API
> > > > > to
> > > > > the libxenforeignmemory interface to replace a foreign mapping with
> > > > > anonymous shared memory, but I'd prefer not to.
> > > > > 
> > > > > Build tested with 4.0 and 4.5.
> > > > > 
> > > > > Signed-off-by: Ian Campbell 
> > > > > ---
> > > > > I noticed in xen_console.c that the decision to use a foreign
> > > > > privileged memory mapping vs a grant dev is made using different
> > > > > variables in con_initialise vs con_disconnect. The former uses
> > > > > xendev->dev while the latter uses xendev->gnttabdev. Is this a
> > > > > latent
> > > > > bug?
> > > > 
> > > > The code in con_disconnect is superfluous: the initial check
> > > > 
> > > > if (!xendev->dev) {
> > > > return;
> > > > }
> > > > 
> > > > makes sure the rest of the function only deals with dev != 0.
> > > > I guess it should be
> > > > 
> > > > if (!xendev->dev) {
> > > 
> > > Did you mean xendev->gnttabdev here? Since this is what the code is
> > > touching.
> > > 
> > > Should ->dev and ->gnttabdev be either both set or neither then?
> > 
> > That's right
> > 
> > 
> > > Since con_connect uses the former to decide it would seem logical for
> > > teardown to use the same condition, but I don't know if I'm missing
> > > something. In particular given the initial check you point to how is
> > > the
> > > foreign mapping not already leaked today if the lifecycle of ->dev and 
> > > ->gnttabdev are strictly aligned?
> > > 
> > > > munmap(con->sring, XC_PAGE_SIZE);
> > > 
> > > And this is how the code should be _now_, i.e. with this patch it
> > > should
> > > become xenforeignmemory_unmap?
> > 
> > Yes, I think that today it is leaked, but in practice there is one QEMU
> > process per VM and the VM never disconnect/reconnect the primary console
> > (I don't think there is a way to do that). In other words, after
> > con_disconnect, QEMU is killed.
> 
> Part of the reason for xenforeignmemory_unmap is so that we can make things
> like valgrind more aware of what is going on, so having this happen even if
> things are about to exit is still useful.
> 
> I came up with the following patch which I will insert at the front of v4,
> but I have one doubt, namely are the calls to qemu_chr_add_handler and
> qemu_chr_fe_release not useful here too?

Yes, it looks like they might be useful.


> Obviously the call to 

[Xen-devel] [RFC] Results of Phase 1 of the Review Process study

[Lars Kurth]

Hi everyone,

I wanted to walk you through some of the results of the Review Process study 
https://github.com/dicortazar/ipython-notebooks/blob/master/projects/xen-analysis/Code-Review-Metrics.ipynb
 

I am also looking for input and views.

Best Regards
Lars

== Caveats ==
C1) Only 60% percent of the reviews on the mailing list could be matched to 
commits. This can be improved going forward, but we felt that the dataset is 
big enough for statical analysis and didn't want to spend too much time to get 
the matching perfect at this stage. See "Coverage analysis" for more details

C2) In many cases, you will only want to look at median (green) rather mean 
(blue) trends in sections 1-5. In particular where the numbers are small. Also 
note that there is significant monthly variation in some graphs and thus graphs 
may be skewed by freeze periods, holidays, ... in those cases it is really 
necessary to look at the integral areas underneath the graphs and/or trend 
lines.

C3) Some of the time related diagrams in section 6 show data in different ways 
(e.g. [67] and [68]). For example, 
- [67] maps the starting point of a completed review to a year
- [68] maps the end points of a completed review to a year
The former is less prone to be skewed by freeze periods, holidays, dev summits, 
...
 
== Summary ==
S1) We had a very high influx of complex patches, clogging up the review 
pipeline. However the situation seems to be have become better in the first 
half of 2015.

S2) We have had an increase of 10% per year of submitted patches since 2011

S3) The median number of review comments per patch has increased from around 3 
(from 2009 to 2013) to 5 after 2013. This appears to be a reflection of higher 
demands on quality, but there are other explanations also. But indications are, 
that the root cause is that higher quality is expected today compared to the 
past.

S4) Contributors have become better at re-work: in 2011 the average time 
reviewers waited for patches to be re-worked while a series was reviewed was 
around 30 days, now it is around 15 days. For an exact definition see 1, Time 
to re-work a patch

S5) The community is faster at turning around review cycles: up to 2012 a 
single review cycle (e.g. from v1 to v2, v2 to v3, ...) took approx. 13 days, 
and was around approx. 7 since

S6) We do seem to have increased the number of people who actively review 
individual patches (the median was 2 and now is 3 per patch), but the overall 
number of reviewers has stayed the same. ]

S7) However, the variations on all the above figures have become generally 
higher: in other words we do have more "outliers" - aka individual patch series 
- which go into the opposite direction

S8) Historically we have handled an average of 513 patch series a year. The 
*bad news* is that we have about a years worth of patches (481) which had 
review activity in the last 12 months. And a bit more than a year's backlog 
(600) which is stalled and didn't receive attention for 12 months. But we do 
not yet have data how this has evolved historically, so we don't know yet 
whether the last 2 years were different to what we have seen in the past.

It is worth noting that the same set of people are doing more reviews, more 
effectively. First a big thank you to our reviewers. However, this is an issue 
in the long run, which needs addressing. 

== Explanation of Graphs (where not obvious) ==

=== Histograms and Log Scale diagrams in sections 1-5 ===

The time period covered is usually over the entire existence of the project, 
unless stated otherwise. 

The histograms are pretty obvious: we know that the scales are a bit crude and 
will improve this.

The log scale diagrams are more interesting (See LogScale.png for a legend). 

1: 25% - in this example 25% of new review cycles are started within a day
2: 50% - in this example 50% of new review cycles are started within approx. 
3.5 days
3: 75% - in this example 75% of new review cycles are started within approx. 
10.5 days
4: Threshold for statistical significance - everything above the line is *not* 
statistically significant. In this case everything above 12 days is *not* 
statistically significant.
5: Shows a "+" for each datapoint that is not statistically significant

== Cycle Time [27] to [29] ==
This is not quite obvious from the definition in 1. For the cycle time, we 
basically ignore the mapping to a patch or patch series and just look at the 
cycle times between review iterations *regardless* of which series it belongs 
to.

For example [29] then tells us that the median cycle of any code review has 
been fairly static around 5 days from 2012.

== Backlog Analysis ==
This section shows us the total of patch series reviews that could be modelled 
(60%) over the project's life-time 

Complete: 5641
Active (aka activity in the last 7 days) : 78
Ongoing (aka activity in the last 12 months): 403
Stalled (no activity for 12 months): 600
 
This is an area where time based 

Re: [Xen-devel] [PATCH v7 3/3] tools & docs: add tools and docs support for Intel CDP

[Dario Faggioli]

On Tue, 2015-10-13 at 16:53 +0800, He Chen wrote:
> diff --git a/docs/misc/xl-psr.markdown b/docs/misc/xl-psr.markdown
> index c32e25c..9b08ee3 100644
> --- a/docs/misc/xl-psr.markdown
> +++ b/docs/misc/xl-psr.markdown
> @@ -127,6 +127,59 @@ Per domain CBM settings can be shown by:
>  
>  `xl psr-cat-show`
>  
> +## Code and Data Prioritization (CDP)
> +
> +Code and Data Prioritization (CDP) Technology is an extension of
> CAT, which
> +is available on Intel Broadwell and later server platforms. CDP
> enables
> +isolation and separate prioritization of code and data fetches to
> the L3
> +cache in a software configurable manner, which can enable workload
> +prioritization and tuning of cache capacity to the characteristics
> of the
> +workload. CDP extends Cache Allocation Technology (CAT) by providing
> +separate code and data masks per Class of Service (COS).
> +
> +CDP can be enabled by adding `psr=cdp` to Xen command line.
> +
> +When CDP is enabled,
> +
> + * the CAT masks are re-mapped into interleaved pairs of masks for
> data or
> +   code fetches.
> +
> + * the range of COS for CAT is re-indexed, with the lower-half of
> the COS
> +   range available for CDP.
> +
> +CDP allows the OS or Hypervisor to partition cache allocation in a
> more
> +fine-grained.
>
"In a more fine-grained" "way"? Or "manner"?

(I'm not a native speaker, though, so if that's not the case, sorry for
the noise.)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] OSSTest standalone script

[Hu, Robert]

Hi Ian,

When I now try to use standalone script for debug, it seems doesn't work as 
before. Any usage changed?

[root@robert-ivt osstest]# ./standalone run-job --dry-run -h dummy 
test-amd64-amd64-qemuu-nested
Could not open a connection to your authentication agent.
WARNING: Unable to access ssh-agent. Some tests may fail
./standalone: line 195: savelog: command not found

Best Regards,
Robert Ho


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

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Jan Beulich]

>>> On 14.10.15 at 07:12,  wrote:
> Jan Beulich wrote on 2015-10-13:
> On 13.10.15 at 07:27,  wrote:
>>> Jan Beulich wrote on 2015-10-12:
>>> On 12.10.15 at 03:42,  wrote:
> So, my suggestion is that we can rely on user to not assign the
> ATS device if hypervisor says it cannot support such device. For
> example, if hypervisor find the invalidation isn't completed in 1
> second, then hypervisor can crash itself and tell the user this
> ATS device needs more than 1 second invalidation time which is not
> support by
>>> Xen.
 
 Crashing the hypervisor in such a case is a security issue, i.e. is
 not
>>> 
>>> Indeed. Crashing the guest is more reasonable.
>>> 
 an acceptable thing (and the fact that we panic() on timeout expiry
 right now isn't really acceptable either). If crashing the
 offending guest was sufficient to contain the issue, that might be an 
 option.
 Else
>>> 
>>> I think it should be sufficient (any concern from you?).
>> 
>> Having looked at the code, it wasn't immediately clear whether that
>> would work. After all there one would think there would be a reason
>> for the code panic()ing right now instead.
> 
> What the panic()ing refer to here?

E.g. what we have in queue_invalidate_wait():

while ( poll_slot != QINVAL_STAT_DONE )
{
if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
{
print_qi_regs(iommu);
panic("queue invalidate wait descriptor was not executed");
}
cpu_relax();
}

>>> But if solution 1 is acceptable, I prefer it since most of ATS
>>> devices are still able to play with Xen.
>> 
>> With a multi-millisecond spin, solution 1 would imo be acceptable only
>> as a transitional measure.
> 
> What does the transitional measure mean? Do you mean we still need the async 
> flush for ATS issue or we can adapt solution 1 before ATS spec changed?

As long as the multi-millisecond spins aren't going to go away by
other means, I think conversion to async mode is ultimately
unavoidable.

Jan


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

[Xen-devel] [PATCH] xen/arm: domain_build: Removed unused variable in write_properties

[Julien Grall]

The variable new_data is initialized to NULL and free but never
allocated neither used.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index eb93a3a..0c3441a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -415,7 +415,6 @@ static int write_properties(struct domain *d, struct 
kernel_info *kinfo,
 dt_for_each_property_node (node, prop)
 {
 const void *prop_data = prop->value;
-void *new_data = NULL;
 u32 prop_len = prop->length;
 
 /*
@@ -471,8 +470,6 @@ static int write_properties(struct domain *d, struct 
kernel_info *kinfo,
 
 res = fdt_property(kinfo->fdt, prop->name, prop_data, prop_len);
 
-xfree(new_data);
-
 if ( res )
 return res;
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v8 02/17] Add cmpxchg16b support for x86-64

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, October 14, 2015 5:46 PM
> To: Wu, Feng 
> Cc: Andrew Cooper ; xen-devel@lists.xen.org;
> Keir Fraser 
> Subject: RE: [PATCH v8 02/17] Add cmpxchg16b support for x86-64
> 
> >>> On 14.10.15 at 11:29,  wrote:
> > I understand your comments above. My understanding about the gcc
> > online doc is we don't need to add memory clobber when the variable
> > is either an input _or_ output one. However, seems your options is
> > memory clobber can be removed only when it is an input _and_ output
> > one. It would be highly appreciated if you can correct me if I understand
> > the doc incorrectly.
> 
> Yes, I'm pretty convinced you read it wrong: "performs memory
> reads or writes to items other than those listed in the input and
> output operands" means _any_ operation not expressed by the
> ams operands. The two sentence following that actually explain
> this in more detail. IOW - unless your operands correctly express
> _everything_ the assembly instruction(s) do(es), you need a
> clobber (and this is not limited to memory).

Thanks for the clarification. So do you think it is better to send only
this single patch after fixing the issue in your comments, or wait
for the next version of this whole patch set?

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [PATCH v7 3/3] tools & docs: add tools and docs support for Intel CDP

[Ian Campbell]

On Wed, 2015-10-14 at 10:38 +0800, Chao Peng wrote:
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 365798b..8db0132 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -8434,6 +8434,8 @@ static int psr_cat_hwinfo(void)
> >  }
> >  printf("%-16s: %u\n", "Socket ID", info[i].id);
> >  printf("%-16s: %uKB\n", "L3 Cache", l3_cache_size);
> > +printf("%-16s: %s\n", "CDP Status",
> > +   info->cdp_enabled ? "Enabled" : "Disabled");
> 
> Sorry I didn't notice this before but I guess 'info->cdp_enabled' here
> really would be 'info[i].cdp_enabled' as CDP status is per-socket.
> Current code will always print the data for the first socket in each
> iteration, which is undesirable.

I think you are correct, well spotted.


> With this and the indention issue proposed by Ian being fixed:
> 
> Reviewed-by: Chao Peng 
> 
> >  printf("%-16s: %u\n", "Maximum COS", info[i].cos_max);
> >  printf("%-16s: %u\n", "CBM length", info[i].cbm_len);
> >  printf("%-16s: %#llx\n", "Default CBM",
> > @@ -8445,29 +8447,46 @@ out:
> >  return rc;
> >  }

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

Re: [Xen-devel] [PATCH] x86/EPT: defer enabling of A/D maintenance until PML get enabled

[Kai Huang]

Hi Jan,

After some thinking, just set/clear p2m->ept.ept_ad is not enough -- we 
also need to __vmwrite it to VMCS's EPTP, and then call ept_sync_domain. 
I have verified attached patch can work.


Which implementation would you prefer, existing code or with attached 
patch? If you prefer the latter, please provide comments.


Thanks,
-Kai

On 10/14/2015 09:19 AM, Kai Huang wrote:

Hi Jan,

Our QA tested this patch but this patch broke PML. Neither GUI display 
(video ram tracking also uses PML) nor live migration works. I'll 
investigate what's wrong and get back to you.


Thanks,
-Kai

On 09/30/2015 08:45 PM, Kai Huang wrote:

On Wed, Sep 30, 2015 at 5:54 PM, Jan Beulich  wrote:

On 30.09.15 at 10:58,  wrote:

Good to me, if you have tested it. Sorry I cannot test it as I am
taking vacation  until Oct.8.

Note how I asked for help with testing ...

On Mon, Sep 28, 2015 at 10:42 PM, Jan Beulich  
wrote:

There's no point in enabling the extra feature for every domain when
we're not meaning to use it (yet). Just setting the flag should be
sufficient - the domain is required to be paused for PML enabling
anyway, i.e. hardware will pick up the new setting the next time
each vCPU of the guest gets scheduled.

Signed-off-by: Jan Beulich 
Cc: Kai Huang 
---
VT-x maintainers, Kai: Me lacking the hardware to test this, may I 
ask

for your help here?

... here. This patch can certainly wait until you get back from
vacation.
Thanks. I'll test it or ask someone has machine to test it after I 
get back.


Thanks,
-Kai

Jan







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



>From cd01ef0908ee6d0931ea15ff25606f76fe859757 Mon Sep 17 00:00:00 2001
From: Kai Huang 
Date: Wed, 14 Oct 2015 17:01:24 +0800
Subject: [PATCH] x86/ept: defer enabling EPT A/D bit until PML is enabled.

Signed-off-by: Kai Huang 
---
 xen/arch/x86/hvm/vmx/vmcs.c | 20 
 xen/arch/x86/mm/p2m-ept.c   |  2 --
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 3592a88..9bb278b 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1382,6 +1382,8 @@ bool_t vmx_vcpu_pml_enabled(const struct vcpu *v)
 
 int vmx_vcpu_enable_pml(struct vcpu *v)
 {
+struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
+
 if ( vmx_vcpu_pml_enabled(v) )
 return 0;
 
@@ -1399,6 +1401,9 @@ int vmx_vcpu_enable_pml(struct vcpu *v)
 __vmwrite(SECONDARY_VM_EXEC_CONTROL,
   v->arch.hvm_vmx.secondary_exec_control);
 
+/* we leave ept_sync_domain to vmx_domain_enable_pml */
+__vmwrite(EPT_POINTER, ept_get_eptp(>ept));
+
 vmx_vmcs_exit(v);
 
 return 0;
@@ -1406,6 +1411,8 @@ int vmx_vcpu_enable_pml(struct vcpu *v)
 
 void vmx_vcpu_disable_pml(struct vcpu *v)
 {
+struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
+
 if ( !vmx_vcpu_pml_enabled(v) )
 return;
 
@@ -1418,6 +1425,9 @@ void vmx_vcpu_disable_pml(struct vcpu *v)
 __vmwrite(SECONDARY_VM_EXEC_CONTROL,
   v->arch.hvm_vmx.secondary_exec_control);
 
+/* we leave ept_sync_domain to vmx_domain_enable_pml */
+__vmwrite(EPT_POINTER, ept_get_eptp(>ept));
+
 vmx_vmcs_exit(v);
 
 v->domain->arch.paging.free_page(v->domain, v->arch.hvm_vmx.pml_pg);
@@ -1492,6 +1502,7 @@ bool_t vmx_domain_pml_enabled(const struct domain *d)
  */
 int vmx_domain_enable_pml(struct domain *d)
 {
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 struct vcpu *v;
 int rc;
 
@@ -1500,10 +1511,14 @@ int vmx_domain_enable_pml(struct domain *d)
 if ( vmx_domain_pml_enabled(d) )
 return 0;
 
+p2m->ept.ept_ad = 1;
+
 for_each_vcpu( d, v )
 if ( (rc = vmx_vcpu_enable_pml(v)) != 0 )
 goto error;
 
+ept_sync_domain(p2m);
+
 d->arch.hvm_domain.vmx.status |= VMX_DOMAIN_PML_ENABLED;
 
 return 0;
@@ -1523,6 +1538,7 @@ int vmx_domain_enable_pml(struct domain *d)
  */
 void vmx_domain_disable_pml(struct domain *d)
 {
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 struct vcpu *v;
 
 ASSERT(atomic_read(>pause_count));
@@ -1530,10 +1546,14 @@ void vmx_domain_disable_pml(struct domain *d)
 if ( !vmx_domain_pml_enabled(d) )
 return;
 
+p2m->ept.ept_ad = 0;
+
 for_each_vcpu( d, v )
 vmx_vcpu_disable_pml(v);
 
 d->arch.hvm_domain.vmx.status &= ~VMX_DOMAIN_PML_ENABLED;
+
+ept_sync_domain(p2m);
 }
 
 /*
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 74ce9e0..0d689b0 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1166,8 +1166,6 @@ int ept_p2m_init(struct p2m_domain *p2m)
 
 if ( cpu_has_vmx_pml )
 {
-/* Enable EPT A/D bits if we are going to use PML. */
-

Re: [Xen-devel] [PATCH v7 3/3] tools & docs: add tools and docs support for Intel CDP

[Ian Campbell]

On Wed, 2015-10-14 at 11:08 +0200, Dario Faggioli wrote:
> On Tue, 2015-10-13 at 16:53 +0800, He Chen wrote:
> > diff --git a/docs/misc/xl-psr.markdown b/docs/misc/xl-psr.markdown
> > index c32e25c..9b08ee3 100644
> > --- a/docs/misc/xl-psr.markdown
> > +++ b/docs/misc/xl-psr.markdown
> > @@ -127,6 +127,59 @@ Per domain CBM settings can be shown by:
> >  
> >  `xl psr-cat-show`
> >  
> > +## Code and Data Prioritization (CDP)
> > +
> > +Code and Data Prioritization (CDP) Technology is an extension of
> > CAT, which
> > +is available on Intel Broadwell and later server platforms. CDP
> > enables
> > +isolation and separate prioritization of code and data fetches to
> > the L3
> > +cache in a software configurable manner, which can enable workload
> > +prioritization and tuning of cache capacity to the characteristics
> > of the
> > +workload. CDP extends Cache Allocation Technology (CAT) by providing
> > +separate code and data masks per Class of Service (COS).
> > +
> > +CDP can be enabled by adding `psr=cdp` to Xen command line.
> > +
> > +When CDP is enabled,
> > +
> > + * the CAT masks are re-mapped into interleaved pairs of masks for
> > data or
> > +   code fetches.
> > +
> > + * the range of COS for CAT is re-indexed, with the lower-half of
> > the COS
> > +   range available for CDP.
> > +
> > +CDP allows the OS or Hypervisor to partition cache allocation in a
> > more
> > +fine-grained.
> > 
> "In a more fine-grained" "way"? Or "manner"?
> 
> (I'm not a native speaker, though, so if that's not the case, sorry for
> the noise.)

You are right, there is a word missing. "manner" would be my interpretation
of what was intended.

Ian.


> 
> Regards,
> Dario

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

Re: [Xen-devel] [PATCH v8 02/17] Add cmpxchg16b support for x86-64

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, October 14, 2015 5:06 PM
> To: Wu, Feng 
> Cc: Andrew Cooper ; xen-devel@lists.xen.org;
> Keir Fraser 
> Subject: RE: [PATCH v8 02/17] Add cmpxchg16b support for x86-64
> 
> >>> On 14.10.15 at 07:57,  wrote:
> 
> >
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Tuesday, October 13, 2015 11:29 PM
> >> To: Wu, Feng 
> >> Cc: Andrew Cooper ; xen-devel@lists.xen.org;
> >> Keir Fraser 
> >> Subject: Re: [PATCH v8 02/17] Add cmpxchg16b support for x86-64
> >>
> >> >>> On 12.10.15 at 10:54,  wrote:
> >> > --- a/xen/include/asm-x86/x86_64/system.h
> >> > +++ b/xen/include/asm-x86/x86_64/system.h
> >> > @@ -6,6 +6,39 @@
> >> > (unsigned long)(n),sizeof(*(ptr
> >> >
> >> >  /*
> >> > + * Atomic 16 bytes compare and exchange.  Compare OLD with MEM, if
> >> > + * identical, store NEW in MEM.  Return the initial value in MEM.
> >> > + * Success is indicated by comparing RETURN with OLD.
> >> > + *
> >> > + * This function can only be called when cpu_has_cx16 is true.
> >> > + */
> >> > +
> >> > +static always_inline __uint128_t __cmpxchg16b(
> >> > +volatile void *ptr, const __uint128_t *old, const __uint128_t *new)
> >> > +{
> >> > +__uint128_t prev;
> >> > +uint64_t new_high = *new >> 64;
> >> > +uint64_t new_low = *new;
> >> > +
> >> > +ASSERT(cpu_has_cx16);
> >> > +
> >> > +asm volatile ( "lock; cmpxchg16b %3"
> >> > +   : "=A" (prev)
> >> > +   : "c" (new_high), "b" (new_low),
> >> > + "m" (*__xg(ptr)), "0" (*old) );
> >>
> >> I was about to apply this when I spotted that this is still wrong:
> >> The (requested) removal of the memory clobber requires that
> >> the memory location (all 16 bytes of it) appear as output.
> >
> > This is the description about memory clobber from gcc online docs:
> > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers
> >
> > "The "memory" clobber tells the compiler that the assembly code
> > performs memory reads or writes to items other than those listed
> > in the input and output operands"
> >
> > My understanding to it is if the variable is listed as input of output,
> > we don't need to add memory clobber. We need to add it only
> > when it is not listed in the intput/output and the memory may be
> > changed behind us.
> 
> Did you misunderstand my reply? I'm not asking the memory clobber
> to be re-added (after all it was me who asked for it to be removed).
> Instead I'm pointing out that with the removal of the clobber the
> memory operand needs to become an input and output one, instead
> of just an input (which would make the compiler believe the memory
> location's contents don't change).

I understand your comments above. My understanding about the gcc
online doc is we don't need to add memory clobber when the variable
is either an input _or_ output one. However, seems your options is
memory clobber can be removed only when it is an input _and_ output
one. It would be highly appreciated if you can correct me if I understand
the doc incorrectly.

Thanks,
Feng 

> 
> Jan


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

Re: [Xen-devel] OSSTest standalone script

[Hu, Robert]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, October 14, 2015 5:48 PM
> To: Hu, Robert ; ian.jack...@citrix.com
> Cc: xen-devel@lists.xen.org
> Subject: Re: OSSTest standalone script
> 
> On Wed, 2015-10-14 at 09:29 +, Hu, Robert wrote:
> > Hi Ian,
> >
> > When I now try to use standalone script for debug, it seems doesn't work
> > as before. Any usage changed?
> >
> > [root@robert-ivt osstest]# ./standalone run-job --dry-run -h dummy test
> > -amd64-amd64-qemuu-nested
> > Could not open a connection to your authentication agent.
> > WARNING: Unable to access ssh-agent. Some tests may fail
> 
> It seems you do not have a ssh-agent running.
> 
> This isn't strictly needed (i.e if your ssh key has no passphrase) hence
> this is just a warning.
> 
> > ./standalone: line 195: savelog: command not found
> 
> And this indicates that you need to install the "savelog" command.
> 
> In Debian this comes from the 'debianutils' package, so it is probably
> Debian specific, which I had not realised.
> 
> If you aren't using Debian then I think the following will help, although
> you won't benefit from the rotation of logs, which is the old behaviour.
> 
> -8>
> 
> From ed4fd4bf2b175a02b9dbe3e394577b7095a8f3be Mon Sep 17 00:00:00
> 2001
> From: Ian Campbell 
> Date: Wed, 14 Oct 2015 10:45:36 +0100
> Subject: [PATCH] standalone: only rotate logs if savelog is available
> 
> `savelog' comes from the `debianutils' package and so is unlikely to
> be available elsewhere. Revert to the old behaviour of clobbering the
> logs in this case.
> 
> Signed-off-by: Ian Campbell 
> ---
>  standalone | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/standalone b/standalone
> index 20a6ad5..c804b74 100755
> --- a/standalone
> +++ b/standalone
> @@ -192,7 +192,9 @@ ensure_logs() {
>  with_logging() {
>  local log=$1; shift
>  ensure_logs
> -savelog -c 300 -n "$log" >/dev/null
> +if command -v savelog >/dev/null ; then
> +savelog -c 300 -n "$log" >/dev/null
> +fi
>  "$@" 2>&1 | tee "$log"
>  rc=${PIPESTATUS[0]}
>  if [ $rc -ne 0 ] ; then
 
Thanks for quick reply! It works!

> --
> 2.5.3

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

Re: [Xen-devel] [PATCH v8 02/17] Add cmpxchg16b support for x86-64

[Jan Beulich]

>>> On 14.10.15 at 07:57,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, October 13, 2015 11:29 PM
>> To: Wu, Feng 
>> Cc: Andrew Cooper ; xen-devel@lists.xen.org;
>> Keir Fraser 
>> Subject: Re: [PATCH v8 02/17] Add cmpxchg16b support for x86-64
>> 
>> >>> On 12.10.15 at 10:54,  wrote:
>> > --- a/xen/include/asm-x86/x86_64/system.h
>> > +++ b/xen/include/asm-x86/x86_64/system.h
>> > @@ -6,6 +6,39 @@
>> > (unsigned long)(n),sizeof(*(ptr
>> >
>> >  /*
>> > + * Atomic 16 bytes compare and exchange.  Compare OLD with MEM, if
>> > + * identical, store NEW in MEM.  Return the initial value in MEM.
>> > + * Success is indicated by comparing RETURN with OLD.
>> > + *
>> > + * This function can only be called when cpu_has_cx16 is true.
>> > + */
>> > +
>> > +static always_inline __uint128_t __cmpxchg16b(
>> > +volatile void *ptr, const __uint128_t *old, const __uint128_t *new)
>> > +{
>> > +__uint128_t prev;
>> > +uint64_t new_high = *new >> 64;
>> > +uint64_t new_low = *new;
>> > +
>> > +ASSERT(cpu_has_cx16);
>> > +
>> > +asm volatile ( "lock; cmpxchg16b %3"
>> > +   : "=A" (prev)
>> > +   : "c" (new_high), "b" (new_low),
>> > + "m" (*__xg(ptr)), "0" (*old) );
>> 
>> I was about to apply this when I spotted that this is still wrong:
>> The (requested) removal of the memory clobber requires that
>> the memory location (all 16 bytes of it) appear as output. 
> 
> This is the description about memory clobber from gcc online docs:
> https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers 
> 
> "The "memory" clobber tells the compiler that the assembly code
> performs memory reads or writes to items other than those listed
> in the input and output operands"
> 
> My understanding to it is if the variable is listed as input of output,
> we don't need to add memory clobber. We need to add it only
> when it is not listed in the intput/output and the memory may be
> changed behind us.

Did you misunderstand my reply? I'm not asking the memory clobber
to be re-added (after all it was me who asked for it to be removed).
Instead I'm pointing out that with the removal of the clobber the
memory operand needs to become an input and output one, instead
of just an input (which would make the compiler believe the memory
location's contents don't change).

Jan


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

Re: [Xen-devel] [Xen-users] Purpose of mem-max command

[David Vrabel]

On 13/10/15 22:14, Daniel Kiper wrote:
> On Tue, Oct 13, 2015 at 11:55:09AM +0100, Ian Campbell wrote:
>> [CCing Daniel]
>>
>> Daniel, please could you advice on which Xen releases, guest types and
>> guest kernel versions are currently expected to work with memory hotplug.
> 
> Well... It worked, regardless of guest type, when it was introduced first 
> time.
> At that time xend was Xen toolstack. Than xl appeared on the scene and it 
> stopped
> working. I tried to fix it but I was diverted to something more important. 
> Last
> time David (CC-ed here) fixed some memory hotplug issues in Linux kernel 
> (please
> check for-linus-4.4 branch in 
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for more details). I suppose that he manged to overcome some xl deficiencies 
> and
> he will be able to shed some light what he did. If not or his work is not 
> upstreamable
> then I leave this on my TODO list. I hope that I will be able to work on this 
> next
> year. However, if somebody is up to this work I am able to mentor he/she or at
> least review relevant patch series. Here are my old patches for xl:
> http://lists.xen.org/archives/html/xen-devel/2013-04/msg03072.html This is 
> really
> old but I think it could be good starting point for further work.

I think I had to manually fiddle with xenstore keys to persuade xl to
allow mem-max to work as expected.

David

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

Re: [Xen-devel] Swapping frame contents

[Bilal Bakht Ahmad]

This is exactly what we're looking to do. Do you know of any relevant areas
in the Xen source code where this may be taking place?

On Mon, Oct 5, 2015 at 3:08 PM, George Dunlap 
wrote:

> On Sun, Oct 4, 2015 at 12:37 PM, Bilal Bakht Ahmad 
> wrote:
> > Is there any way the contents of 2 frames be swapped given their
> gmfn/mfn?
>
> Probably?
>
> Your question isn't very detailed; you might benefit from reading this:
>
> http://wiki.xenproject.org/wiki/Asking_Developer_Questions
>
> Would the following algorithm work?
> - pause VM
> - copy data from gmfn A into temporary buffer
> - copy data from gmfn B into gmfn A
> - copy data from temporary buffer into gmfn B
> - unpause VM
>
>  -George
>



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

Re: [Xen-devel] [PATCH v8 02/17] Add cmpxchg16b support for x86-64

[Jan Beulich]

>>> On 14.10.15 at 11:29,  wrote:
> I understand your comments above. My understanding about the gcc
> online doc is we don't need to add memory clobber when the variable
> is either an input _or_ output one. However, seems your options is
> memory clobber can be removed only when it is an input _and_ output
> one. It would be highly appreciated if you can correct me if I understand
> the doc incorrectly.

Yes, I'm pretty convinced you read it wrong: "performs memory
reads or writes to items other than those listed in the input and
output operands" means _any_ operation not expressed by the
ams operands. The two sentence following that actually explain
this in more detail. IOW - unless your operands correctly express
_everything_ the assembly instruction(s) do(es), you need a
clobber (and this is not limited to memory).

Jan


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

Re: [Xen-devel] OSSTest standalone script

[Ian Campbell]

On Wed, 2015-10-14 at 09:29 +, Hu, Robert wrote:
> Hi Ian,
> 
> When I now try to use standalone script for debug, it seems doesn't work
> as before. Any usage changed?
> 
> [root@robert-ivt osstest]# ./standalone run-job --dry-run -h dummy test
> -amd64-amd64-qemuu-nested
> Could not open a connection to your authentication agent.
> WARNING: Unable to access ssh-agent. Some tests may fail

It seems you do not have a ssh-agent running.

This isn't strictly needed (i.e if your ssh key has no passphrase) hence
this is just a warning.

> ./standalone: line 195: savelog: command not found

And this indicates that you need to install the "savelog" command.

In Debian this comes from the 'debianutils' package, so it is probably
Debian specific, which I had not realised.

If you aren't using Debian then I think the following will help, although
you won't benefit from the rotation of logs, which is the old behaviour.

-8>

>From ed4fd4bf2b175a02b9dbe3e394577b7095a8f3be Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Wed, 14 Oct 2015 10:45:36 +0100
Subject: [PATCH] standalone: only rotate logs if savelog is available

`savelog' comes from the `debianutils' package and so is unlikely to
be available elsewhere. Revert to the old behaviour of clobbering the
logs in this case.

Signed-off-by: Ian Campbell 
---
 standalone | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/standalone b/standalone
index 20a6ad5..c804b74 100755
--- a/standalone
+++ b/standalone
@@ -192,7 +192,9 @@ ensure_logs() {
 with_logging() {
 local log=$1; shift
 ensure_logs
-savelog -c 300 -n "$log" >/dev/null
+if command -v savelog >/dev/null ; then
+savelog -c 300 -n "$log" >/dev/null
+fi
 "$@" 2>&1 | tee "$log"
 rc=${PIPESTATUS[0]}
 if [ $rc -ne 0 ] ; then
-- 
2.5.3


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

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

[ CC qemu-block ]

Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben:
> On Tue, 13 Oct 2015, John Snow wrote:
> > On 10/13/2015 11:55 AM, Fabio Fantoni wrote:
> > > I added ahci disk support in libxl and using it for week seems that was
> > > ok, after a reply of Stefano Stabellini seems that xen disk unplug
> > > support only ide disks:
> > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8
> > > 
> > > Today Paul Durrant told me that even if pv disk is ok also with ahci and
> > > the emulated one is offline can be a risk:
> > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html
> > > 
> > > 
> > > I tried to take a fast look in qemu code but I not understand the needed
> > > thing for add the xen disk unplug support also for ahci, can someone do
> > > it or tell me useful information for do it please?
> > > 
> > > Thanks for any reply and sorry for my bad english.
> > > 
> > 
> > I'm not entirely sure what features you need AHCI to support in order
> > for Xen to be happy.
> > 
> > I'd guess hotplugging, but where I get confused is that IDE disks don't
> > support hotplugging either, so I guess I'm not sure sure what you need.
> > 
> > Stefano, can you help bridge my Xen knowledge gap?
>  
> Hi John,
> 
> we need something like hw/i386/xen/xen_platform.c:unplug_disks but that
> can unplug AHCI disk. And by unplug, I mean "make disappear" like
> pci_piix3_xen_ide_unplug does for ide.

Maybe this would be the right time to stop the craziness with your
hybrid IDE/xendisk setup. It's a horrible thing that would never happen
on real hardware.

Can't you just teach SeaBIOS how to deal with your PV disks and then
only add that to your VM and forget about IDE/AHCI? I mean, that's how
it's done for virtio-blk, and it doesn't involve any insanities like
ripping out non-hotpluggable devices.

Hm... How does a reboot of a machine that had its IDE already removed
actually work? Do you restart the qemu process on reboot?

Kevin

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

[Xen-devel] [linux-linus test] 62948: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 62908 pass in 62948
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 62940 pass in 62948
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 62940 pass in 62948
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail pass in 62908
 test-armhf-armhf-xl-rtds 15 guest-start.2   fail pass in 62908
 test-armhf-armhf-xl-xsm  15 guest-start.2   fail pass in 62940

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-qcow2 7 host-ping-check-xen fail in 62908 baseline 
untested
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 62908 like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 linux25cb62b76430a91cc6195f902e61c2cb84ade622
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z   97 days
Failing since 59348  2015-07-10 04:24:05 Z   96 days   56 attempts
Testing same since62908  2015-10-11 19:28:19 Z2 days3 attempts


2435 people touched revisions under test,
not listing them all

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
 

Re: [Xen-devel] [PATCH] x86/EPT: defer enabling of A/D maintenance until PML get enabled

[Jan Beulich]

>>> On 14.10.15 at 11:08,  wrote:
> After some thinking, just set/clear p2m->ept.ept_ad is not enough -- we 
> also need to __vmwrite it to VMCS's EPTP, and then call ept_sync_domain. 

Ah, yes, this makes sense of course.

> I have verified attached patch can work.

Thanks!

> Which implementation would you prefer, existing code or with attached 
> patch? If you prefer the latter, please provide comments.

I think it's marginal whether to flip the bit in ept_{en,dis}able_pml()
or vmx_domain_{en,dis}able_pml(); the former would seem slightly
more logical.

There's one possible problem with the patch though: Deferring the
sync from the vcpu to the domain function is fine when the domain
function is the caller, but what about the calls out of vmx.c? The
calls look safe as the domain isn't running (yet or anymore) at that
point, but the respective comments may need adjustment (and
the disable one should also refer to vmx_domain_disable_pml()),
in order to avoid confusing future readers. Also you'd need to fix
coding style of these new comments.

Jan


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

Re: [Xen-devel] [PATCH] libxc: create an initial FPU state for HVM guests

[Jan Beulich]

>>> On 13.10.15 at 18:18,  wrote:
> El 13/10/15 a les 16.43, Jan Beulich ha escrit:
> On 13.10.15 at 15:32,  wrote:
>>> --- a/tools/libxc/xc_dom_x86.c
>>> +++ b/tools/libxc/xc_dom_x86.c
>>> @@ -841,6 +841,23 @@ static int vcpu_hvm(struct xc_dom_image *dom)
>>>  struct hvm_save_descriptor end_d;
>>>  HVM_SAVE_TYPE(END) end;
>>>  } bsp_ctx;
>>> +struct {
>>> +uint16_t fcw;
>>> +uint16_t fsw;
>>> +uint8_t ftw;
>>> +uint8_t rsvd1;
>>> +uint16_t fop;
>>> +union {
>>> +uint64_t addr;
>>> +struct {
>>> +uint32_t offs;
>>> +uint16_t sel;
>>> +uint16_t rsvd;
>>> +};
>>> +} fip, fdp;
>>> +uint32_t mxcsr;
>>> +uint32_t mxcsr_mask;
>>> +} *fpu_ctxt;
>> 
>> I think a comment should be added here that this layout is the 64-bit
>> one, no matter what bitness the tool stack. Or perhaps leave out all
>> pieces that you don't need; the ones you care about live at the same
>> offsets in both 32- and 64-bit variants.
> 
> The layout of this structure is exactly the same for 32 and 64bits, I'm
> going to add a comment stating this.

Oh, sorry, I mixed this up with the FSAVE/FRSTOR layout, of which we
still have traces in our tree. I'll go clean this up.

Jan


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

Re: [Xen-devel] [PATCH v2] libxc: create an initial FPU state for HVM guests

[Wei Liu]

On Tue, Oct 13, 2015 at 06:27:20PM +0200, Roger Pau Monne wrote:
> Xen always set the FPU as initialized when loading a HVM context, so libxc
> has to provide a valid FPU context when setting the CPU registers.
> 
> This is a stop-gap measure in order to unblock OSSTest Windows 7 failures
> while a proper fix for the HVM CPU save/restore is being worked on.
> 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Andrew Cooper 
> Suggested-by: Jan Beulich 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Ian Campbell 
> Cc: Wei Liu 

I think all concerns in previous version have been addressed, so this
patch is fine by me:

Acked-by: Wei Liu 

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

[Xen-devel] [distros-debian-squeeze test] 38167: all pass

[Platform Team regression test user]

flight 38167 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38167/

Perfect :-)
All tests in this flight passed
baseline version:
 flight   38133

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubpass
 test-amd64-i386-amd64-squeeze-netboot-pygrub pass
 test-amd64-amd64-i386-squeeze-netboot-pygrub pass
 test-amd64-i386-i386-squeeze-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 01/13] x86/time.c: Use system time to calculate elapsed_nsec in tsc_get_info()

[Haozhong Zhang]

On Wed, Oct 14, 2015 at 03:40:01AM -0600, Jan Beulich wrote:
> >>> On 14.10.15 at 04:45,  wrote:
> > However, patch 2 is still necessary. The existing tsc_get_info() uses
> > the host TSC frequency as the guest TSC frequency for a domain in
> > TSC_MODE_DEFAULT, which could cause errors in the following example:
> >  - A domain d using TSC_MODE_DEFAULT is created on host A, then
> >migrated to host B, and finally migrated to host C.
> >  - The host TSC frequencies of three hosts are f_a, f_b and f_c
> >respectively and f_a != f_b and f_b != f_c.
> >  - Both host B and host C support TSC scaling (either VMX TSC scaling
> >or SVM TSC ratio).
> > 
> > In above example w/o patch 2,
> >  1. Initially, d->arch.tsc_khz == f_a.
> >  
> >  2. In the first migration, tsc_get_info() on host A passes f_a as the
> > guest TSC frequency to tsc_set_info() on host B, so that after the
> > migration it's still that d->arch.tsc_khz == f_a. As TSC scaling
> > takes effect, guest programs can still observe TSC in frequency f_a.
> > So far so good.
> > 
> >  3. However, in the second migration, f_b (!= f_a) is passed as the
> > guest TSC frequency to tsc_set_info() on host C so that after the
> > migration d->arch.tsc_khz is not f_a any more.
> 
> Hmm, yes, looks like you're right. But I don't think the current use of
> cpu_khz should be blindly replaced - instead this should be done only
> when cpu_has_tsc_ratio (mirroring what tsc_set_info() does). Unless
> of course it can be proven that d->arch.tsc_khz == cpu_khz in all
> relevant cases without use of TSC ratio (i.e. the use of cpu_khz here
> just served as kind of a shorthand).
>
> Jan
> 

Sounds reasonable. A better patch 2 may look like

- *gtsc_khz = cpu_khz;
+ if ( is_hvm_domain(d) && cpu_has_tsc_ratio )
+ *gtsc_khz = d->arch.tsc_khz;
+ else
+ *gtsc_khz = cpu_khz;

which gets d->arch.tsc_khz only if TSC ratio is used, otherwise it
follows the existing behavior.

- Haozhong

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: don't try to re-register vcpu_info on cpu_hotplug.

[Julien Grall]

Hi Stefano,

On 14/10/2015 18:49, Stefano Stabellini wrote:

Signed-off-by: Stefano Stabellini 
---
  arch/arm/xen/enlighten.c |6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6c09cc4..59f5421 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -93,6 +93,12 @@ static void xen_percpu_init(void)
int err;
int cpu = get_cpu();

+   /* vcpu_info already registered, can happen with cpu-hotplug */


Can you please add more comment and explain in the commit message why 
this is necessary for cpu-hotplug?


I had to look at the x86 code to fully understand that it's not possible 
to call VCPUOP_register_vcpu_info twice because there is no hypercall to 
remove the vcpu shared page.




+   if (per_cpu(xen_vcpu, cpu) != NULL) {
+   put_cpu();
+   return;
+   }
+
pr_info("Xen: initializing cpu%d\n", cpu);
vcpup = per_cpu_ptr(xen_vcpu_info, cpu);




Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] raisin: enable ovmf build for arm64

[Julien Grall]

Hi Stefano,

On 14/10/2015 16:57, Stefano Stabellini wrote:

-make -C BaseTools/Source/C
-OvmfPkg/build.sh -a X64 -b RELEASE -n 4
-cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
+make -C BaseTools
+
+if [[ $RAISIN_ARCH = "arm64" ]]
+then
+# Just use gcc4.8 flags for now: we have to specify a gcc
+# version and the 4.8 flags are almost identical to 4.9, etc.


It would have been nice to mention that the downside is we always use 
the large model (see [1]).


Regards,

[1] http://lists.xen.org/archives/html/xen-devel/2015-10/msg01450.html

--
Julien Grall

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

[Xen-devel] [xen-unstable test] 62956: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 62711
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 62711
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 62711
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 62711

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 62711
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
62711
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 62711
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 62711
 test-armhf-armhf-xl-rtds 15 guest-start.2fail   like 62711

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

version targeted for testing:
 xen  ed740187a5d8a7fcec2116c410d850f1b54a0603
baseline version:
 xen  a23ce429779011de127e8ff6c9bf3486d87154d5

Last test of basis62711  2015-10-07 10:34:21 Z7 days
Failing since 62733  2015-10-08 22:34:06 Z5 days6 attempts
Testing same since62956  2015-10-14 05:41:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Brijesh Singh 
  Daniel Kiper 
  Dario Faggioli 
  Fabio Fantoni 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Mike Latimer 
  Roger Pau Monne 
  Roger Pau Monné 
  Sander Eikelenboom 
  Tamas K Lengyel 
  Tim Deegan 
  Wei Liu 
  Wei Wang 
  Yang Zhang 

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

Re: [Xen-devel] [PATCH 1/3] xen/arm: Enable cpu_hotplug.c

[Julien Grall]

Hi Stefano,

On 14/10/2015 18:49, Stefano Stabellini wrote:

Build cpu_hotplug for ARM and ARM64 guests.

Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an
empty implementation on ARM and ARM64. On x86 just call
arch_(un)register_cpu as we are already doing.

Initialize cpu_hotplug on ARM.

Signed-off-by: Stefano Stabellini 
---
  arch/arm/include/asm/xen/hypervisor.h |8 
  arch/x86/include/asm/xen/hypervisor.h |5 +
  arch/x86/xen/enlighten.c  |   15 +++
  drivers/xen/Makefile  |2 --
  drivers/xen/cpu_hotplug.c |6 --
  5 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypervisor.h 
b/arch/arm/include/asm/xen/hypervisor.h
index 04ff8e7..2bc418a 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -26,4 +26,12 @@ void __init xen_early_init(void);
  static inline void xen_early_init(void) { return; }
  #endif



I know that those helpers are empty for now. But I would prefer to see 
them protected by (FWIW, it's what you did for x86).


#ifdef CONFIG_CPU_HOTPLUG


+static inline void xen_arch_register_cpu(int num)
+{
+}
+
+static inline void xen_arch_unregister_cpu(int num)
+{
+}
+


#endif


  #endif /* _ASM_ARM_XEN_HYPERVISOR_H */


[...]


diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index cc6513a..122b351 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -11,7 +11,7 @@
  static void enable_hotplug_cpu(int cpu)
  {
if (!cpu_present(cpu))
-   arch_register_cpu(cpu);
+   xen_arch_register_cpu(cpu);

set_cpu_present(cpu, true);
  }
@@ -19,7 +19,7 @@ static void enable_hotplug_cpu(int cpu)
  static void disable_hotplug_cpu(int cpu)
  {
if (cpu_present(cpu))
-   arch_unregister_cpu(cpu);
+   xen_arch_unregister_cpu(cpu);

set_cpu_present(cpu, false);
  }
@@ -102,8 +102,10 @@ static int __init setup_vcpu_hotplug_event(void)
static struct notifier_block xsn_cpu = {
.notifier_call = setup_cpu_watcher };

+#ifdef CONFIG_X86
if (!xen_pv_domain())
return -ENODEV;
+#endif


For ARM, you need to check if it's a Xen domain. Otherwise a kernel 
aware of Xen won't boot on baremetal.




register_xenstore_notifier(_cpu);




Regards,

--
Julien Grall

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

Re: [Xen-devel] RFC: Survey on release cycle

[Dario Faggioli]

On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote:
> Hi all
> 

> Please express your preference with -2 (strongly argue against), -1
> (not happy but not against), +1 (happy but won't argue for) and +2
> (happy and argue for).
> 

> # 6 months release cycle + current stable release scheme
> 
> The same stable release scheme applies (18 months full support + 18
> months security fixes). Encourage more people to step up to share the
> maintenance burden if necessary. Automate part of the workflow to
> maintain stable releases. Write down guideline for maintainers.
> 
+1

I especially like the 6 months cadence with fixed dates. Keeping the
current stable release scheme could be a good thing, e.g., to avoid
introducing too many changes at the same time (although, I personally
think we could well give the LTS model a try, as said below).

> # 6 months release cycle + LTS scheme
> 
> Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS
> releases receive shorter support. Encourage more people to step up to
> share the maintenance burden if necessary. Automate part of the
> workflow to maintain stable releases and LTS releases. Write down
> guideline for maintainers.
> 
> The length of support hasn't been discussed thoroughly -- but to make
> LTS scheme stand out the length of support would be longer than what
> we have now (18 + 18).
> 
+2

I really like the 6 months cadence with fixed dates, and, although I
don't have much experience with them, I like the LTS idea, enough to
think that we should give it a try, at least.

> # 9 months release cycle + current stable release scheme
> 
-2

As said above, I think we should go (try) 6

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] libxl: No emulated disk driver for xvdX disk

[Anthony PERARD]

When a guest configuration list xvdX for its disks, there is no need to
provide an emulated driver for the same target.

Such configuration can work with the OVMF firmware, as it supports PV
disk.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_dm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 71a1a3e..5371f72 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1190,6 +1190,12 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 drive = libxl__sprintf
 (gc, 
"file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback",
  pdev_path, disk, format);
+else if (strncmp(disks[i].vdev, "xvd", 3) == 0)
+/*
+ * Do not add any emulated disk when PV disk are
+ * explicitly asked for.
+ */
+continue;
 else if (disk < 6 && b_info->u.hvm.hdtype == 
LIBXL_HDTYPE_AHCI) {
 flexarray_vappend(dm_args, "-drive",
 
GCSPRINTF("file=%s,if=none,id=ahcidisk-%d,format=%s,cache=writeback",
-- 
Anthony PERARD


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

Re: [Xen-devel] Xen 4.6, OVMF and arm64

[Wei Liu]

On Wed, Oct 14, 2015 at 12:25:32PM +0100, Stefano Stabellini wrote:
> Hi Wei, Anthony,
> 
> the OVMF revision that we use with Xen 4.6 is
> cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, however that doesn't work for
> arm64. It is not a problem for xen.git, because the arm64 build of ovmf
> is not enabled in the xen tree (it is built separately). However it is a
> problem for raisin: I am trying to enable the ovmf build on arm64 in
> raisin but it fails on arm64 for the latest release (at least on CentOS
> 7) which is not nice.
> 
> One fix is required on top of
> cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd to make it work:
> 
> commit 28e80befa4fe0edd7cce876e991fed912f0f2795
> Author: Leif Lindholm 
> Date:   Thu Jul 9 16:29:44 2015 +
> 
> BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags
> 
> 
> This is not required but it would be nice:
> 
> commit ad2a2e5623a4a4ac5f24ae827f7842995ef4c2a9
> Author: Ard Biesheuvel 
> Date:   Wed Aug 12 05:22:49 2015 +
> 
> BaseTools: add ARCH detection for AARCH64 and ARM
> 
> 
> They only affect aarch64. Do you think it would be possible to apply
> them to the ovfm tree on xenbits and maybe update the ovmf revision in
> Config.mk, once it passes any required osstest tests?
> 

I can send a patch for Config.mk when the patch passed our tests.

Wei.

> Thanks,
> 
> Stefano

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

[Xen-devel] Xen 4.6, OVMF and arm64

[Stefano Stabellini]

Hi Wei, Anthony,

the OVMF revision that we use with Xen 4.6 is
cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, however that doesn't work for
arm64. It is not a problem for xen.git, because the arm64 build of ovmf
is not enabled in the xen tree (it is built separately). However it is a
problem for raisin: I am trying to enable the ovmf build on arm64 in
raisin but it fails on arm64 for the latest release (at least on CentOS
7) which is not nice.

One fix is required on top of
cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd to make it work:

commit 28e80befa4fe0edd7cce876e991fed912f0f2795
Author: Leif Lindholm 
Date:   Thu Jul 9 16:29:44 2015 +

BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags


This is not required but it would be nice:

commit ad2a2e5623a4a4ac5f24ae827f7842995ef4c2a9
Author: Ard Biesheuvel 
Date:   Wed Aug 12 05:22:49 2015 +

BaseTools: add ARCH detection for AARCH64 and ARM


They only affect aarch64. Do you think it would be possible to apply
them to the ovfm tree on xenbits and maybe update the ovmf revision in
Config.mk, once it passes any required osstest tests?

Thanks,

Stefano

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

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Stefano Stabellini]

On Wed, 14 Oct 2015, Kevin Wolf wrote:
> [ CC qemu-block ]
> 
> Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben:
> > On Tue, 13 Oct 2015, John Snow wrote:
> > > On 10/13/2015 11:55 AM, Fabio Fantoni wrote:
> > > > I added ahci disk support in libxl and using it for week seems that was
> > > > ok, after a reply of Stefano Stabellini seems that xen disk unplug
> > > > support only ide disks:
> > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8
> > > > 
> > > > Today Paul Durrant told me that even if pv disk is ok also with ahci and
> > > > the emulated one is offline can be a risk:
> > > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html
> > > > 
> > > > 
> > > > I tried to take a fast look in qemu code but I not understand the needed
> > > > thing for add the xen disk unplug support also for ahci, can someone do
> > > > it or tell me useful information for do it please?
> > > > 
> > > > Thanks for any reply and sorry for my bad english.
> > > > 
> > > 
> > > I'm not entirely sure what features you need AHCI to support in order
> > > for Xen to be happy.
> > > 
> > > I'd guess hotplugging, but where I get confused is that IDE disks don't
> > > support hotplugging either, so I guess I'm not sure sure what you need.
> > > 
> > > Stefano, can you help bridge my Xen knowledge gap?
> >  
> > Hi John,
> > 
> > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that
> > can unplug AHCI disk. And by unplug, I mean "make disappear" like
> > pci_piix3_xen_ide_unplug does for ide.
> 
> Maybe this would be the right time to stop the craziness with your
> hybrid IDE/xendisk setup. It's a horrible thing that would never happen
> on real hardware.

I would be quite happy to stop (or even get rid of) the craziness.


> Can't you just teach SeaBIOS how to deal with your PV disks and then
> only add that to your VM and forget about IDE/AHCI? I mean, that's how
> it's done for virtio-blk, and it doesn't involve any insanities like
> ripping out non-hotpluggable devices.

Teaching SeaBIOS to deal with PV disks can be done, in fact we already
support PV disks in OVMF. It is possible to boot Windows with OVMF
without any IDE disks (patch pending for libxl to create a VM without
emulated IDE disks).

However we have to be honest that implementing PV disk support in
SeaBIOS is a different magnitude of effort compared to implementing AHCI
"unplug".

I would suggest Fabio to avoid AHCI disks altogether and just use OVMF
with PV disks only and Anthony's patch to libxl to avoid creating any
IDE disks: http://marc.info/?l=xen-devel=144482080812353.

Would that work for you?


> Hm... How does a reboot of a machine that had its IDE already removed
> actually work? Do you restart the qemu process on reboot?

Restart QEMU, yes.

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

[Xen-devel] [PATCH OSSTEST] README: discuss how to create and run an adhoc flight and/or job.

[Ian Campbell]

I also needed to document some of the more special runvars for
reference purposes.

Signed-off-by: Ian Campbell 
---
 README | 177 +
 1 file changed, 177 insertions(+)

diff --git a/README b/README
index 56d590b..3e64a13 100644
--- a/README
+++ b/README
@@ -192,6 +192,53 @@ test-$XENARCH-$DOM0ARCH-
 
 NB: $ARCH (and $XENARCH etc) are Debian arch names, i386, amd64, armhf.
 
+Common/Special Runvars
+==
+
+Many test aspects of the individual test-scripts (ts-*) are configured
+via "runvars" and are only of interest to a specific script and to the
+make-flight which sets them up.
+
+However there are some runvars which are globally interesting.
+
+- Build Jobs:
+
+A runvar which ends "buildjob" (more formally, which matches
+/^(?:.*_)?([^_]*)buildjob$/) indicates that the job containing
+that runvar requires the outout of another job in order to run.
+
+Examples of these are `xenbuildjob', which is the job providing the
+hypervisor; `buildjob', which provides the tools or `kernbuildjob'
+which provides the dom0 (and possibly guest) kernel.
+
+In production mode osstest will take care of ensuring that any
+required build jobs are complete before running the job. In
+standalone mode this is the user's responsibility.
+
+A build job runvar can simply (and most commonly) name another job
+within the same flight or it can be of the form "."
+to use the output of a job in another flight. The latter is common
+associated with bisection which will attempt to reuse existing
+builds where possible.
+
+- Host Idents:
+
+Most jobs require one or more hosts to operate on, these are
+passed to the ts-* commands making up the job as command line
+options given the "ident" of the host, which is simply an
+identifier for the role of the host. Most often a job which only
+requires a single host will have a single ident `host`, a
+migration job might involve `src_host' and `dst_host'.
+
+In general the ident is simply passed to the ts-* scripts by
+sg-run-job or by ./standalone and is then converted to an actual
+host by looking for an identically named runvar.
+
+This runvar is usually set by ts-hosts-allocate which in
+production mode interacts with the resource planner. However in
+some cases, e.g. bisection, this runvar is configured when the
+flight is constructed (so that bisection happens on the same host).
+
 Standalone Mode
 ===
 
@@ -519,3 +566,133 @@ ExecutiveDbnamePat
 ExecutiveDbname_
PostgreSQL dbname string for the database .  Default is to use
ExecutiveDbnamePat.
+
+Adhoc/Custom Flights
+
+
+Normally a flight is constructed using "make-flight", either via
+"./standalone make-flight" or by calling make-flight (or another
+make-*-flight) directly.
+
+In production mode this usually happens via cr-for-branches invoking
+cr-daily-branch for a given branch, while in standalone mode it is
+either done by hand or using the standalone helpers make-flight
+operation.
+
+However it can be useful to create a custom flight "by-hand" in order
+to repeatedly test one aspect or to facilitate adhoc tests etc.
+
+A fresh empty flight is created by using the "cs-flight-create"
+script. It takes as arguments a "blessing" and a "branch" and on
+success prints the new flight number.
+
+The blessing should almost always be "adhoc". The branch doesn't
+really matter, if you are testing something related to a failure on a
+given branch you may as well use that, otherwise "adhoc" or
+"xen-unstable" is a reasonably fallback.
+
+Thus the normal way to invoke cs-flight-create is:
+
+$ flight=`./cs-flight-create adhoc adhoc`
+
+Which results in a $flight which can be used for the remainder of the
+configuration.
+
+Once you have an empty flights there are two main ways to populate it
+with jobs. Firstly you can create jobs from scratch using
+cs-job-create or secondly by copying one or more jobs from an existing
+template flight using "cs-adjust-flight copy-jobs". In either case the
+job can then be further customised using cs-adjust-flight to add and
+remove runvars etc.
+
+cs-job-create requires a flight ($flight from above), a job name (any
+string), a recipe (either custom, see below, or from any
+run-job/ in sg-run-job) and then the runvars in key=value
+form. Deciding on the runvars in particular can be tricky, it is
+usually easiest to copy an existing job.
+
+A job can be copied from a template flight using cs-adjust-flight
+copy-jobs e.g.:
+
+$ ./cs-adjust-flight $flight copy-jobs $template 
+
+Having created (or copied) a job then you may wish to customise, which
+can be done using cs-adjust-flight. In particular you can add or
+remove runvars, see the doc comment at the top of the script. Most
+commonly you may which to preset the host ident to a specific if you
+are 

[Xen-devel] [qemu-mainline test] 62950: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm  7 host-ping-check-xen   fail REGR. vs. 62943
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail blocked in 62943
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 62943

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   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-qcow2  9 debian-di-installfail 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-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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass

version targeted for testing:
 qemuuc49d3411faae8ffaab8f7e5db47405a008411c10
baseline version:
 qemuu5451316ed07b758a187dedf21047bed8f843f7f1

Last test of basis62943  2015-10-13 04:49:09 Z1 days
Testing same since62950  2015-10-13 20:48:18 Z0 days1 attempts


People who touched revisions under test:
  Eric Blake 
  Markus Armbruster 
  Peter Maydell 

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
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm

Re: [Xen-devel] [PATCH v8 02/17] Add cmpxchg16b support for x86-64

[Jan Beulich]

>>> On 14.10.15 at 12:03,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, October 14, 2015 5:46 PM
>> To: Wu, Feng 
>> Cc: Andrew Cooper ; xen-devel@lists.xen.org;
>> Keir Fraser 
>> Subject: RE: [PATCH v8 02/17] Add cmpxchg16b support for x86-64
>> 
>> >>> On 14.10.15 at 11:29,  wrote:
>> > I understand your comments above. My understanding about the gcc
>> > online doc is we don't need to add memory clobber when the variable
>> > is either an input _or_ output one. However, seems your options is
>> > memory clobber can be removed only when it is an input _and_ output
>> > one. It would be highly appreciated if you can correct me if I understand
>> > the doc incorrectly.
>> 
>> Yes, I'm pretty convinced you read it wrong: "performs memory
>> reads or writes to items other than those listed in the input and
>> output operands" means _any_ operation not expressed by the
>> ams operands. The two sentence following that actually explain
>> this in more detail. IOW - unless your operands correctly express
>> _everything_ the assembly instruction(s) do(es), you need a
>> clobber (and this is not limited to memory).
> 
> Thanks for the clarification. So do you think it is better to send only
> this single patch after fixing the issue in your comments, or wait
> for the next version of this whole patch set?

I don't know - I didn't get around to look at the rest of the series yet.

Jan


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

Re: [Xen-devel] [PATCH] xen/arm: ctxt_switch: Document the erratum #852523 related to Cortex A57

[Ian Campbell]

On Fri, 2015-10-09 at 11:40 +0100, Julien Grall wrote:
> On 09/10/15 10:22, Ian Campbell wrote:
> > On Thu, 2015-10-08 at 20:22 +0100, Julien Grall wrote:
> > > When restoring the system register state for an AArch32 guest at EL2,
> > > writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> > > which can lead to the guest effectively running into unexpected
> > > domain
> > > faults.
> > > 
> > > Thankfully, we don't hit this erratum in Xen. Nonetheless, document
> > > the
> > > code to prevent any introduction of the erratum if the context switch
> > > code is re-ordered.
> > > 
> > > Link: 
> > > http://lists.xen.org/archives/html/xen-devel/2015-09/msg01746.html
> > > Signed-off-by: Julien Grall 
> > 
> > Acked-by: Ian Campbell 
> > 
> > nits:
> > >  
> > > +/*
> > > + * This write to sysreg CONTEXTIDR_EL1 ensure we don't hit the
> > > erratum
> > 
> > "ensures" and s/the //.
> > 
> > (fixable on commit)
> 
> I'm fine if you fix it while committing.

Done.


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

Re: [Xen-devel] [PATCH v2] libxc: create an initial FPU state for HVM guests

[Ian Campbell]

On Wed, 2015-10-14 at 10:59 +0100, Wei Liu wrote:
> On Tue, Oct 13, 2015 at 06:27:20PM +0200, Roger Pau Monne wrote:
> > Xen always set the FPU as initialized when loading a HVM context, so
> > libxc
> > has to provide a valid FPU context when setting the CPU registers.
> > 
> > This is a stop-gap measure in order to unblock OSSTest Windows 7
> > failures
> > while a proper fix for the HVM CPU save/restore is being worked on.
> > 
> > Signed-off-by: Roger Pau Monné 
> > Reviewed-by: Andrew Cooper 
> > Suggested-by: Jan Beulich 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Ian Jackson 
> > Cc: Stefano Stabellini 
> > Cc: Ian Campbell 
> > Cc: Wei Liu 
> 
> I think all concerns in previous version have been addressed, so this
> patch is fine by me:
> 
> Acked-by: Wei Liu 

I was thinking the same, so acked by me as well and applied.



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

Re: [Xen-devel] [PATCH] xen/arm: domain_build: Removed unused variable in write_properties

[Ian Campbell]

On Wed, 2015-10-14 at 10:34 +0100, Julien Grall wrote:
> The variable new_data is initialized to NULL and free but never
> allocated neither used.
> 
> Signed-off-by: Julien Grall 

Acked + applied.


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

Re: [Xen-devel] [PATCH v7 3/3] tools & docs: add tools and docs support for Intel CDP

[Jan Beulich]

>>> On 13.10.15 at 10:53,  wrote:
> This is the xl/xc changes to support Intel Code/Data Prioritization.
> CAT xl commands to set/get CBMs are extended to support CDP.
> Add new CDP options with CAT commands in xl interface man page.
> Add description of CDP in xl-psr.markdown.
> 
> Signed-off-by: He Chen 

Tools maintainers, JFTR - I committed patches 1 and 2 of this series,
and will drop this tools side patch from my queue, assuming one of
you is going to take care of it.

Jan


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

Re: [Xen-devel] RFC: Survey on release cycle

[Stefano Stabellini]

On Mon, 12 Oct 2015, Wei Liu wrote:
> Hi all
> 
> We've had two separate discussions about release cycles, one for
> normal release [0], the other for changes in stable release
> maintenance and possible long term supported releases [1]. There were
> overwhelming support for having a shorter release cycle from
> xen-unstable but we couldn't reach consensus on how to manage stable
> releases.
> 
> The details on the current 9 months release cycle and proposed 6
> months release cycle can be found in [0], while the current scheme for
> stable releases can be found in [2]. A plethora of arguments can be
> found in both [0] and [1], but in the end most if not all of them boil
> down to empirical arguments / expectations or just merely different
> opinions on the same fact so there wasn't really concrete outcome of
> that two threads.
> 
> With the release of 4.6, it's important that we have agreement so that
> we can get on with planning next release.
> 
> There are several general options on how to proceed that I summarise
> from previous discussions. Note that because there are too many moving
> parts I pick some of my preferences as a starting point for the
> discussion. I also omit the combination of 9 months release cycle +
> LTS scheme because it doesn't look attractive in the first place.
> 
> Please express your preference with -2 (strongly argue against), -1
> (not happy but not against), +1 (happy but won't argue for) and +2
> (happy and argue for).
> 
> # 6 months release cycle + current stable release scheme
> 
> The same stable release scheme applies (18 months full support + 18
> months security fixes). Encourage more people to step up to share the
> maintenance burden if necessary. Automate part of the workflow to
> maintain stable releases. Write down guideline for maintainers.

+1
I think it would be a bit too much work for us, but we could probably
cope. However it is still better than what we have now.


> # 6 months release cycle + LTS scheme
> 
> Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS
> releases receive shorter support. Encourage more people to step up to
> share the maintenance burden if necessary. Automate part of the
> workflow to maintain stable releases and LTS releases. Write down
> guideline for maintainers.
> 
> The length of support hasn't been discussed thoroughly -- but to make
> LTS scheme stand out the length of support would be longer than what
> we have now (18 + 18).

+2
LTSes solve the problem of the load on stable trees maintainers.


> # 9 months release cycle + current stable release scheme
> 
> Don't change anything.

-2

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

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Ian Campbell]

On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote:
> > Can't you just teach SeaBIOS how to deal with your PV disks and then
> > only add that to your VM and forget about IDE/AHCI? I mean, that's how
> > it's done for virtio-blk, and it doesn't involve any insanities like
> > ripping out non-hotpluggable devices.
> 
> Teaching SeaBIOS to deal with PV disks can be done, in fact we already
> support PV disks in OVMF. It is possible to boot Windows with OVMF
> without any IDE disks (patch pending for libxl to create a VM without
> emulated IDE disks).

One stumbling block in the past has been how to know when the PV drivers in
the BIOS are no longer required, such that the ring can be torn down and/or
the connection etc handed over to the OS driver.

I think we deal with this in OVMF using ExitBootServices? (TBH I'm not sure 
how). AFAIK the BIOS interfaces do not have anything as reliable as that.

How does virtio deal with this in the BIOS case?

Ian.

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

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf]

Am 14.10.2015 um 13:06 hat Stefano Stabellini geschrieben:
> On Wed, 14 Oct 2015, Kevin Wolf wrote:
> > [ CC qemu-block ]
> > 
> > Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben:
> > > On Tue, 13 Oct 2015, John Snow wrote:
> > > > On 10/13/2015 11:55 AM, Fabio Fantoni wrote:
> > > > > I added ahci disk support in libxl and using it for week seems that 
> > > > > was
> > > > > ok, after a reply of Stefano Stabellini seems that xen disk unplug
> > > > > support only ide disks:
> > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8
> > > > > 
> > > > > Today Paul Durrant told me that even if pv disk is ok also with ahci 
> > > > > and
> > > > > the emulated one is offline can be a risk:
> > > > > http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html
> > > > > 
> > > > > 
> > > > > I tried to take a fast look in qemu code but I not understand the 
> > > > > needed
> > > > > thing for add the xen disk unplug support also for ahci, can someone 
> > > > > do
> > > > > it or tell me useful information for do it please?
> > > > > 
> > > > > Thanks for any reply and sorry for my bad english.
> > > > > 
> > > > 
> > > > I'm not entirely sure what features you need AHCI to support in order
> > > > for Xen to be happy.
> > > > 
> > > > I'd guess hotplugging, but where I get confused is that IDE disks don't
> > > > support hotplugging either, so I guess I'm not sure sure what you need.
> > > > 
> > > > Stefano, can you help bridge my Xen knowledge gap?
> > >  
> > > Hi John,
> > > 
> > > we need something like hw/i386/xen/xen_platform.c:unplug_disks but that
> > > can unplug AHCI disk. And by unplug, I mean "make disappear" like
> > > pci_piix3_xen_ide_unplug does for ide.
> > 
> > Maybe this would be the right time to stop the craziness with your
> > hybrid IDE/xendisk setup. It's a horrible thing that would never happen
> > on real hardware.
> 
> I would be quite happy to stop (or even get rid of) the craziness.
> 
> 
> > Can't you just teach SeaBIOS how to deal with your PV disks and then
> > only add that to your VM and forget about IDE/AHCI? I mean, that's how
> > it's done for virtio-blk, and it doesn't involve any insanities like
> > ripping out non-hotpluggable devices.
> 
> Teaching SeaBIOS to deal with PV disks can be done, in fact we already
> support PV disks in OVMF. It is possible to boot Windows with OVMF
> without any IDE disks (patch pending for libxl to create a VM without
> emulated IDE disks).
> 
> However we have to be honest that implementing PV disk support in
> SeaBIOS is a different magnitude of effort compared to implementing AHCI
> "unplug".

Agreed. But we generally try to do the right thing and not the easy
thing.

Maybe I'm missing something, but my impression was that the hybrid setup
was only used so that you can boot from a PV disk even though the BIOS
doesn't have a PV driver. In that case, why would you even want to use
AHCI instead of IDE? During the early boot performance shouldn't be much
different as there is no parallelism, and afterwards the PV driver is
used.

> I would suggest Fabio to avoid AHCI disks altogether and just use OVMF
> with PV disks only and Anthony's patch to libxl to avoid creating any
> IDE disks: http://marc.info/?l=xen-devel=144482080812353.
> 
> Would that work for you?

That sounds certainly like a better step forward than adding a crude
hack to AHCI.

And if you want to make me completely happy, plan to extend SeaBIOS so
that we can even drop the existing hack in IDE.

Kevin

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

Re: [Xen-devel] Xen 4.6, OVMF and arm64

[Stefano Stabellini]

On Wed, 14 Oct 2015, Wei Liu wrote:
> On Wed, Oct 14, 2015 at 12:25:32PM +0100, Stefano Stabellini wrote:
> > Hi Wei, Anthony,
> > 
> > the OVMF revision that we use with Xen 4.6 is
> > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd, however that doesn't work for
> > arm64. It is not a problem for xen.git, because the arm64 build of ovmf
> > is not enabled in the xen tree (it is built separately). However it is a
> > problem for raisin: I am trying to enable the ovmf build on arm64 in
> > raisin but it fails on arm64 for the latest release (at least on CentOS
> > 7) which is not nice.
> > 
> > One fix is required on top of
> > cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd to make it work:
> > 
> > commit 28e80befa4fe0edd7cce876e991fed912f0f2795
> > Author: Leif Lindholm 
> > Date:   Thu Jul 9 16:29:44 2015 +
> > 
> > BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags
> > 
> > 
> > This is not required but it would be nice:
> > 
> > commit ad2a2e5623a4a4ac5f24ae827f7842995ef4c2a9
> > Author: Ard Biesheuvel 
> > Date:   Wed Aug 12 05:22:49 2015 +
> > 
> > BaseTools: add ARCH detection for AARCH64 and ARM
> > 
> > 
> > They only affect aarch64. Do you think it would be possible to apply
> > them to the ovfm tree on xenbits and maybe update the ovmf revision in
> > Config.mk, once it passes any required osstest tests?
> > 
> 
> I can send a patch for Config.mk when the patch passed our tests.

OK, thanks. But can you also cherry-pick them into
git://xenbits.xen.org/ovmf.git ?

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