Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Pry Mar]

Wei,

[PATCH] glibc 223 fix gmp-crosslib config error
http://paste.fedoraproject.org/462654/14777176/

I've used this patch since last spring. This is a configure bug which stops
the Stubdom build. The bug first appeared in Ubuntu 16.04 when they went to
libc6 2.23+. Next, Stretch followed with the same upgrade. It has nothing
to do with gcc version.

In the above patch, I posted a link to the developer on the aur-xen list
that saw the solution.

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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 5211ece936eedb0a29ea170b449e0af8edff8db2
baseline version:
 ovmf 6c12fe63f989b1a3aff9f44c22b2833fa78cfcab

Last test of basis   101749  2016-10-28 10:03:05 Z0 days
Testing same since   101763  2016-10-28 19:21:45 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Laszlo Ersek 
  Ryan Harkin 
  Satya Yarlagadda 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Not pushing.

(No revision log; it would be 349 lines long.)

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

Re: [Xen-devel] [PATCH v6 00/11] implement vcpu preempted check

[Pan Xinhui]

在 2016/10/29 03:38, Konrad Rzeszutek Wilk 写道:

On Fri, Oct 28, 2016 at 04:11:16AM -0400, Pan Xinhui wrote:

change from v5:
spilt x86/kvm patch into guest/host part.
introduce kvm_write_guest_offset_cached.
fix some typos.
rebase patch onto 4.9.2
change from v4:
spilt x86 kvm vcpu preempted check into two patches.
add documentation patch.
add x86 vcpu preempted check patch under xen
add s390 vcpu preempted check patch
change from v3:
add x86 vcpu preempted check patch
change from v2:
no code change, fix typos, update some comments
change from v1:
a simplier definition of default vcpu_is_preempted
skip mahcine type check on ppc, and add config. remove dedicated macro.
add one patch to drop overload of rwsem_spin_on_owner and 
mutex_spin_on_owner.
add more comments
thanks boqun and Peter's suggestion.

This patch set aims to fix lock holder preemption issues.


Do you have a git tree with these patches?


Currently no, sorry :(

I make a tar file for this patcheset. Maybe a little easier to apply :)

thanks
xinhui



test-case:
perf record -a perf bench sched messaging -g 400 -p && perf report

18.09%  sched-messaging  [kernel.vmlinux]  [k] osq_lock
12.28%  sched-messaging  [kernel.vmlinux]  [k] rwsem_spin_on_owner
 5.27%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
 3.89%  sched-messaging  [kernel.vmlinux]  [k] wait_consider_task
 3.64%  sched-messaging  [kernel.vmlinux]  [k] _raw_write_lock_irq
 3.41%  sched-messaging  [kernel.vmlinux]  [k] mutex_spin_on_owner.is
 2.49%  sched-messaging  [kernel.vmlinux]  [k] system_call

We introduce interface bool vcpu_is_preempted(int cpu) and use it in some spin
loops of osq_lock, rwsem_spin_on_owner and mutex_spin_on_owner.
These spin_on_onwer variant also cause rcu stall before we apply this patch set

We also have observed some performace improvements in uninx benchmark tests.

PPC test result:
1 copy - 0.94%
2 copy - 7.17%
4 copy - 11.9%
8 copy -  3.04%
16 copy - 15.11%

details below:
Without patch:

1 copy - File Write 4096 bufsize 8000 maxblocks  2188223.0 KBps  (30.0 s, 1 
samples)
2 copy - File Write 4096 bufsize 8000 maxblocks  1804433.0 KBps  (30.0 s, 1 
samples)
4 copy - File Write 4096 bufsize 8000 maxblocks  1237257.0 KBps  (30.0 s, 1 
samples)
8 copy - File Write 4096 bufsize 8000 maxblocks  1032658.0 KBps  (30.0 s, 1 
samples)
16 copy - File Write 4096 bufsize 8000 maxblocks   768000.0 KBps  (30.1 s, 
1 samples)

With patch:

1 copy - File Write 4096 bufsize 8000 maxblocks  2209189.0 KBps  (30.0 s, 1 
samples)
2 copy - File Write 4096 bufsize 8000 maxblocks  1943816.0 KBps  (30.0 s, 1 
samples)
4 copy - File Write 4096 bufsize 8000 maxblocks  1405591.0 KBps  (30.0 s, 1 
samples)
8 copy - File Write 4096 bufsize 8000 maxblocks  1065080.0 KBps  (30.0 s, 1 
samples)
16 copy - File Write 4096 bufsize 8000 maxblocks   904762.0 KBps  (30.0 s, 
1 samples)

X86 test result:
test-case   after-patch   before-patch
Execl Throughput   |18307.9 lps  |11701.6 lps
File Copy 1024 bufsize 2000 maxblocks  |  1352407.3 KBps |   790418.9 KBps
File Copy 256 bufsize 500 maxblocks|   367555.6 KBps |   222867.7 KBps
File Copy 4096 bufsize 8000 maxblocks  |  3675649.7 KBps |  1780614.4 KBps
Pipe Throughput| 11872208.7 lps  | 11855628.9 lps
Pipe-based Context Switching   |  1495126.5 lps  |  1490533.9 lps
Process Creation   |29881.2 lps  |28572.8 lps
Shell Scripts (1 concurrent)   |23224.3 lpm  |22607.4 lpm
Shell Scripts (8 concurrent)   | 3531.4 lpm  | 3211.9 lpm
System Call Overhead   | 10385653.0 lps  | 10419979.0 lps

Christian Borntraeger (1):
  s390/spinlock: Provide vcpu_is_preempted

Juergen Gross (1):
  x86, xen: support vcpu preempted check

Pan Xinhui (9):
  kernel/sched: introduce vcpu preempted check interface
  locking/osq: Drop the overload of osq_lock()
  kernel/locking: Drop the overload of {mutex,rwsem}_spin_on_owner
  powerpc/spinlock: support vcpu preempted check
  x86, paravirt: Add interface to support kvm/xen vcpu preempted check
  KVM: Introduce kvm_write_guest_offset_cached
  x86, kvm/x86.c: support vcpu preempted check
  x86, kernel/kvm.c: support vcpu preempted check
  Documentation: virtual: kvm: Support vcpu preempted check

 Documentation/virtual/kvm/msr.txt |  9 -
 arch/powerpc/include/asm/spinlock.h   |  8 
 arch/s390/include/asm/spinlock.h  |  8 
 arch/s390/kernel/smp.c|  9 +++--
 arch/s390/lib/spinlock.c  | 25 -
 arch/x86/include/asm/paravirt_types.h |  2 ++
 arch/x86/include/asm/spinlock.h   |  8 
 arch/x86/include/uapi/asm/kvm_para.h  |  4 +++-
 arch/x86/kernel/kvm.c | 12 
 

Re: [Xen-devel] [PATCH v6 10/11] x86, xen: support vcpu preempted check

[Pan Xinhui]

在 2016/10/29 03:43, Konrad Rzeszutek Wilk 写道:

On Fri, Oct 28, 2016 at 04:11:26AM -0400, Pan Xinhui wrote:

From: Juergen Gross 

Support the vcpu_is_preempted() functionality under Xen. This will
enhance lock performance on overcommitted hosts (more runnable vcpus
than physical cpus in the system) as doing busy waits for preempted
vcpus will hurt system performance far worse than early yielding.

A quick test (4 vcpus on 1 physical cpu doing a parallel build job
with "make -j 8") reduced system time by about 5% with this patch.

Signed-off-by: Juergen Gross 
Signed-off-by: Pan Xinhui 
---
 arch/x86/xen/spinlock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 3d6e006..74756bb 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -114,7 +114,6 @@ void xen_uninit_lock_cpu(int cpu)
per_cpu(irq_name, cpu) = NULL;
 }

-


Spurious change.

well, just remove one unnecessary blank line while at it.


 /*
  * Our init of PV spinlocks is split in two init functions due to us
  * using paravirt patching and jump labels patching and having to do
@@ -137,6 +136,8 @@ void __init xen_init_spinlocks(void)
pv_lock_ops.queued_spin_unlock = 
PV_CALLEE_SAVE(__pv_queued_spin_unlock);
pv_lock_ops.wait = xen_qlock_wait;
pv_lock_ops.kick = xen_qlock_kick;
+
+   pv_lock_ops.vcpu_is_preempted = xen_vcpu_stolen;
 }

 /*
--
2.4.11


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





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

[Xen-devel] [PULL 09/13] xen: Rename xen_be_unbind_evtchn

[Stefano Stabellini]

From: Emil Condrea 

Prepare xen_be_unbind_evtchn to be shared with frontends:
 * xen_be_unbind_evtchn -> xen_pv_unbind_evtchn

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/block/xen_disk.c| 2 +-
 hw/char/xen_console.c  | 2 +-
 hw/display/xenfb.c | 2 +-
 hw/net/xen_nic.c   | 2 +-
 hw/usb/xen-usb.c   | 2 +-
 hw/xen/xen_pvdev.c | 2 +-
 include/hw/xen/xen_pvdev.h | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 6145567..8f7fe41 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -1194,7 +1194,7 @@ static void blk_disconnect(struct XenDevice *xendev)
 blk_unref(blkdev->blk);
 blkdev->blk = NULL;
 }
-xen_be_unbind_evtchn(>xendev);
+xen_pv_unbind_evtchn(>xendev);
 
 if (blkdev->sring) {
 xengnttab_unmap(blkdev->xendev.gnttabdev, blkdev->sring, 1);
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index aa7a27e..15463dc 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -262,7 +262,7 @@ static void con_disconnect(struct XenDevice *xendev)
 struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
 
 qemu_chr_fe_deinit(>chr);
-xen_be_unbind_evtchn(>xendev);
+xen_pv_unbind_evtchn(>xendev);
 
 if (con->sring) {
 if (!xendev->dev) {
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index d7b94b0..1077575 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -112,7 +112,7 @@ static int common_bind(struct common *c)
 
 static void common_unbind(struct common *c)
 {
-xen_be_unbind_evtchn(>xendev);
+xen_pv_unbind_evtchn(>xendev);
 if (c->page) {
 xenforeignmemory_unmap(xen_fmem, c->page, 1);
c->page = NULL;
diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 2d6e033..c996684 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -372,7 +372,7 @@ static void net_disconnect(struct XenDevice *xendev)
 {
 struct XenNetDev *netdev = container_of(xendev, struct XenNetDev, xendev);
 
-xen_be_unbind_evtchn(>xendev);
+xen_pv_unbind_evtchn(>xendev);
 
 if (netdev->txs) {
 xengnttab_unmap(netdev->xendev.gnttabdev, netdev->txs, 1);
diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 6b06fd8..4ae9b6a 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -834,7 +834,7 @@ static void usbback_disconnect(struct XenDevice *xendev)
 
 usbif = container_of(xendev, struct usbback_info, xendev);
 
-xen_be_unbind_evtchn(xendev);
+xen_pv_unbind_evtchn(xendev);
 
 if (usbif->urb_sring) {
 xengnttab_unmap(xendev->gnttabdev, usbif->urb_sring, 1);
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index 6938c09..b362eb7 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -246,7 +246,7 @@ void xen_be_evtchn_event(void *opaque)
 }
 }
 
-void xen_be_unbind_evtchn(struct XenDevice *xendev)
+void xen_pv_unbind_evtchn(struct XenDevice *xendev)
 {
 if (xendev->local_port == -1) {
 return;
diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h
index 7aedc91..1aff68c 100644
--- a/include/hw/xen/xen_pvdev.h
+++ b/include/hw/xen/xen_pvdev.h
@@ -69,7 +69,7 @@ void xen_pv_insert_xendev(struct XenDevice *xendev);
 void xen_be_del_xendev(struct XenDevice *xendev);
 struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev);
 
-void xen_be_unbind_evtchn(struct XenDevice *xendev);
+void xen_pv_unbind_evtchn(struct XenDevice *xendev);
 int xen_be_send_notify(struct XenDevice *xendev);
 
 void xen_pv_printf(struct XenDevice *xendev, int msg_level,
-- 
1.9.1


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

[Xen-devel] [PULL 12/13] xen: Rename xen_be_find_xendev

[Stefano Stabellini]

From: Emil Condrea 

Prepare xen_be_find_xendev to be shared with frontends:
 * xen_be_find_xendev -> xen_pv_find_xendev

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/display/xenfb.c | 4 ++--
 hw/xen/xen_backend.c   | 2 +-
 hw/xen/xen_pvdev.c | 2 +-
 include/hw/xen/xen_pvdev.h | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 184e735..7a8727a 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -988,8 +988,8 @@ void xen_init_display(int domid)
 wait_more:
 i++;
 main_loop_wait(true);
-xfb = xen_be_find_xendev("vfb", domid, 0);
-xin = xen_be_find_xendev("vkbd", domid, 0);
+xfb = xen_pv_find_xendev("vfb", domid, 0);
+xin = xen_pv_find_xendev("vkbd", domid, 0);
 if (!xfb || !xin) {
 if (i < 256) {
 usleep(1);
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index f594dba..98fcb77 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -114,7 +114,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 {
 struct XenDevice *xendev;
 
-xendev = xen_be_find_xendev(type, dom, dev);
+xendev = xen_pv_find_xendev(type, dom, dev);
 if (xendev) {
 return xendev;
 }
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index 28acf61..af29150 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -264,7 +264,7 @@ int xen_pv_send_notify(struct XenDevice *xendev)
 
 /* - */
 
-struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
+struct XenDevice *xen_pv_find_xendev(const char *type, int dom, int dev)
 {
 struct XenDevice *xendev;
 
diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h
index caf1edc..4b1cc60 100644
--- a/include/hw/xen/xen_pvdev.h
+++ b/include/hw/xen/xen_pvdev.h
@@ -67,7 +67,7 @@ const char *xenbus_strstate(enum xenbus_state state);
 void xen_pv_evtchn_event(void *opaque);
 void xen_pv_insert_xendev(struct XenDevice *xendev);
 void xen_be_del_xendev(struct XenDevice *xendev);
-struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev);
+struct XenDevice *xen_pv_find_xendev(const char *type, int dom, int dev);
 
 void xen_pv_unbind_evtchn(struct XenDevice *xendev);
 int xen_pv_send_notify(struct XenDevice *xendev);
-- 
1.9.1


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

[Xen-devel] [PULL 06/13] xen: Prepare xendev qtail to be shared with frontends

[Stefano Stabellini]

From: Emil Condrea 

 * move xendevs qtail to xen_pvdev.c
 * change xen_be_get_xendev to use a new function: xen_pv_insert_xendev

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/xen/xen_backend.c | 51 +--
 hw/xen/xen_pvdev.c   | 57 
 include/hw/xen/xen_backend.h |  1 -
 include/hw/xen/xen_pvdev.h   |  4 
 4 files changed, 62 insertions(+), 51 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 1487db2..2875e7c 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -54,8 +54,6 @@ struct xs_dirs {
 static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup =
 QTAILQ_HEAD_INITIALIZER(xs_cleanup);
 
-static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs =
-QTAILQ_HEAD_INITIALIZER(xendevs);
 static int debug;
 
 static void xenstore_cleanup_dir(char *dir)
@@ -157,27 +155,6 @@ int xen_be_set_state(struct XenDevice *xendev, enum 
xenbus_state state)
 return 0;
 }
 
-/* - */
-
-struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
-{
-struct XenDevice *xendev;
-
-QTAILQ_FOREACH(xendev, , next) {
-if (xendev->dom != dom) {
-continue;
-}
-if (xendev->dev != dev) {
-continue;
-}
-if (strcmp(xendev->type, type) != 0) {
-continue;
-}
-return xendev;
-}
-return NULL;
-}
-
 /*
  * get xen backend device, allocate a new one if it doesn't exist.
  */
@@ -226,7 +203,7 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 xendev->gnttabdev = NULL;
 }
 
-QTAILQ_INSERT_TAIL(, xendev, next);
+xen_pv_insert_xendev(xendev);
 
 if (xendev->ops->alloc) {
 xendev->ops->alloc(xendev);
@@ -235,32 +212,6 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 return xendev;
 }
 
-/*
- * release xen backend device.
- */
-static void xen_be_del_xendev(struct XenDevice *xendev)
-{
-if (xendev->ops->free) {
-xendev->ops->free(xendev);
-}
-
-if (xendev->fe) {
-char token[XEN_BUFSIZE];
-snprintf(token, sizeof(token), "fe:%p", xendev);
-xs_unwatch(xenstore, xendev->fe, token);
-g_free(xendev->fe);
-}
-
-if (xendev->evtchndev != NULL) {
-xenevtchn_close(xendev->evtchndev);
-}
-if (xendev->gnttabdev != NULL) {
-xengnttab_close(xendev->gnttabdev);
-}
-
-QTAILQ_REMOVE(, xendev, next);
-g_free(xendev);
-}
 
 /*
  * Sync internal data structures on xenstore updates.
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index 7607e44..96ed2a3 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -22,7 +22,11 @@
 #include "hw/xen/xen_backend.h"
 #include "hw/xen/xen_pvdev.h"
 
+/* private */
 static int debug;
+static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs =
+QTAILQ_HEAD_INITIALIZER(xendevs);
+
 /* - */
 
 int xenstore_write_str(const char *base, const char *node, const char *val)
@@ -206,3 +210,56 @@ int xen_be_send_notify(struct XenDevice *xendev)
 {
 return xenevtchn_notify(xendev->evtchndev, xendev->local_port);
 }
+
+/* - */
+
+struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
+{
+struct XenDevice *xendev;
+
+QTAILQ_FOREACH(xendev, , next) {
+if (xendev->dom != dom) {
+continue;
+}
+if (xendev->dev != dev) {
+continue;
+}
+if (strcmp(xendev->type, type) != 0) {
+continue;
+}
+return xendev;
+}
+return NULL;
+}
+
+/*
+ * release xen backend device.
+ */
+void xen_be_del_xendev(struct XenDevice *xendev)
+{
+if (xendev->ops->free) {
+xendev->ops->free(xendev);
+}
+
+if (xendev->fe) {
+char token[XEN_BUFSIZE];
+snprintf(token, sizeof(token), "fe:%p", xendev);
+xs_unwatch(xenstore, xendev->fe, token);
+g_free(xendev->fe);
+}
+
+if (xendev->evtchndev != NULL) {
+xenevtchn_close(xendev->evtchndev);
+}
+if (xendev->gnttabdev != NULL) {
+xengnttab_close(xendev->gnttabdev);
+}
+
+QTAILQ_REMOVE(, xendev, next);
+g_free(xendev);
+}
+
+void xen_pv_insert_xendev(struct XenDevice *xendev)
+{
+QTAILQ_INSERT_TAIL(, xendev, next);
+}
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 6c617d9..cbda40e 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -27,7 +27,6 @@ int xenstore_read_fe_int(struct XenDevice *xendev, const char 
*node, int *ival);
 

[Xen-devel] [PULL 05/13] xen: Move evtchn functions to xen_pvdev.c

[Stefano Stabellini]

From: Emil Condrea 

The name of the functions moved:
 * xen_be_evtchn_event
 * xen_be_unbind_evtchn
 * xen_be_send_notify

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/xen/xen_backend.c | 35 ---
 hw/xen/xen_pvdev.c   | 35 +++
 include/hw/xen/xen_backend.h |  2 --
 include/hw/xen/xen_pvdev.h   |  4 
 4 files changed, 39 insertions(+), 37 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index e3a7d95..1487db2 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -607,25 +607,6 @@ void xenstore_update_fe(char *watch, struct XenDevice 
*xendev)
 xen_be_frontend_changed(xendev, node);
 xen_be_check_state(xendev);
 }
-static void xen_be_evtchn_event(void *opaque)
-{
-struct XenDevice *xendev = opaque;
-evtchn_port_t port;
-
-port = xenevtchn_pending(xendev->evtchndev);
-if (port != xendev->local_port) {
-xen_be_printf(xendev, 0,
-  "xenevtchn_pending returned %d (expected %d)\n",
-  port, xendev->local_port);
-return;
-}
-xenevtchn_unmask(xendev->evtchndev, port);
-
-if (xendev->ops->event) {
-xendev->ops->event(xendev);
-}
-}
-
 /*  */
 
 int xen_be_init(void)
@@ -702,22 +683,6 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 return 0;
 }
 
-void xen_be_unbind_evtchn(struct XenDevice *xendev)
-{
-if (xendev->local_port == -1) {
-return;
-}
-qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
-xenevtchn_unbind(xendev->evtchndev, xendev->local_port);
-xen_be_printf(xendev, 2, "unbind evtchn port %d\n", xendev->local_port);
-xendev->local_port = -1;
-}
-
-int xen_be_send_notify(struct XenDevice *xendev)
-{
-return xenevtchn_notify(xendev->evtchndev, xendev->local_port);
-}
-
 
 static int xen_sysdev_init(SysBusDevice *dev)
 {
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index 22a1abe..7607e44 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -171,3 +171,38 @@ void xen_be_printf(struct XenDevice *xendev, int msg_level,
 }
 qemu_log_flush();
 }
+
+void xen_be_evtchn_event(void *opaque)
+{
+struct XenDevice *xendev = opaque;
+evtchn_port_t port;
+
+port = xenevtchn_pending(xendev->evtchndev);
+if (port != xendev->local_port) {
+xen_be_printf(xendev, 0,
+  "xenevtchn_pending returned %d (expected %d)\n",
+  port, xendev->local_port);
+return;
+}
+xenevtchn_unmask(xendev->evtchndev, port);
+
+if (xendev->ops->event) {
+xendev->ops->event(xendev);
+}
+}
+
+void xen_be_unbind_evtchn(struct XenDevice *xendev)
+{
+if (xendev->local_port == -1) {
+return;
+}
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
+xenevtchn_unbind(xendev->evtchndev, xendev->local_port);
+xen_be_printf(xendev, 2, "unbind evtchn port %d\n", xendev->local_port);
+xendev->local_port = -1;
+}
+
+int xen_be_send_notify(struct XenDevice *xendev)
+{
+return xenevtchn_notify(xendev->evtchndev, xendev->local_port);
+}
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 2e54150..6c617d9 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -36,8 +36,6 @@ void xen_be_register_common(void);
 int xen_be_register(const char *type, struct XenDevOps *ops);
 int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state);
 int xen_be_bind_evtchn(struct XenDevice *xendev);
-void xen_be_unbind_evtchn(struct XenDevice *xendev);
-int xen_be_send_notify(struct XenDevice *xendev);
 
 /* actual backend drivers */
 extern struct XenDevOps xen_console_ops;  /* xen_console.c */
diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h
index 3c4cc01..a8da3da 100644
--- a/include/hw/xen/xen_pvdev.h
+++ b/include/hw/xen/xen_pvdev.h
@@ -64,6 +64,10 @@ void xenstore_update(void *unused);
 
 const char *xenbus_strstate(enum xenbus_state state);
 
+void xen_be_evtchn_event(void *opaque);
+void xen_be_unbind_evtchn(struct XenDevice *xendev);
+int xen_be_send_notify(struct XenDevice *xendev);
+
 void xen_be_printf(struct XenDevice *xendev, int msg_level,
const char *fmt, ...)  GCC_FMT_ATTR(3, 4);
 
-- 
1.9.1


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

[Xen-devel] [PULL 07/13] xen: Move xenstore cleanup and mkdir functions

[Stefano Stabellini]

From: Emil Condrea 

The name of the functions moved to xen_pvdev.c:
 * xenstore_cleanup_dir
 * xen_config_cleanup
 * xenstore_mkdir

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/xen/xen_backend.c | 49 -
 hw/xen/xen_pvdev.c   | 51 +++
 2 files changed, 51 insertions(+), 49 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 2875e7c..216072d 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -47,57 +47,8 @@ struct xs_handle *xenstore = NULL;
 const char *xen_protocol;
 
 /* private */
-struct xs_dirs {
-char *xs_dir;
-QTAILQ_ENTRY(xs_dirs) list;
-};
-static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup =
-QTAILQ_HEAD_INITIALIZER(xs_cleanup);
-
 static int debug;
 
-static void xenstore_cleanup_dir(char *dir)
-{
-struct xs_dirs *d;
-
-d = g_malloc(sizeof(*d));
-d->xs_dir = dir;
-QTAILQ_INSERT_TAIL(_cleanup, d, list);
-}
-
-void xen_config_cleanup(void)
-{
-struct xs_dirs *d;
-
-QTAILQ_FOREACH(d, _cleanup, list) {
-xs_rm(xenstore, 0, d->xs_dir);
-}
-}
-
-int xenstore_mkdir(char *path, int p)
-{
-struct xs_permissions perms[2] = {
-{
-.id= 0, /* set owner: dom0 */
-}, {
-.id= xen_domid,
-.perms = p,
-}
-};
-
-if (!xs_mkdir(xenstore, 0, path)) {
-xen_be_printf(NULL, 0, "xs_mkdir %s: failed\n", path);
-return -1;
-}
-xenstore_cleanup_dir(g_strdup(path));
-
-if (!xs_set_permissions(xenstore, 0, path, perms, 2)) {
-xen_be_printf(NULL, 0, "xs_set_permissions %s: failed\n", path);
-return -1;
-}
-return 0;
-}
-
 int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const 
char *val)
 {
 return xenstore_write_str(xendev->be, node, val);
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index 96ed2a3..e432d30 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -24,11 +24,62 @@
 
 /* private */
 static int debug;
+
+struct xs_dirs {
+char *xs_dir;
+QTAILQ_ENTRY(xs_dirs) list;
+};
+
+static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup =
+QTAILQ_HEAD_INITIALIZER(xs_cleanup);
+
 static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs =
 QTAILQ_HEAD_INITIALIZER(xendevs);
 
 /* - */
 
+static void xenstore_cleanup_dir(char *dir)
+{
+struct xs_dirs *d;
+
+d = g_malloc(sizeof(*d));
+d->xs_dir = dir;
+QTAILQ_INSERT_TAIL(_cleanup, d, list);
+}
+
+void xen_config_cleanup(void)
+{
+struct xs_dirs *d;
+
+QTAILQ_FOREACH(d, _cleanup, list) {
+xs_rm(xenstore, 0, d->xs_dir);
+}
+}
+
+int xenstore_mkdir(char *path, int p)
+{
+struct xs_permissions perms[2] = {
+{
+.id= 0, /* set owner: dom0 */
+}, {
+.id= xen_domid,
+.perms = p,
+}
+};
+
+if (!xs_mkdir(xenstore, 0, path)) {
+xen_be_printf(NULL, 0, "xs_mkdir %s: failed\n", path);
+return -1;
+}
+xenstore_cleanup_dir(g_strdup(path));
+
+if (!xs_set_permissions(xenstore, 0, path, perms, 2)) {
+xen_be_printf(NULL, 0, "xs_set_permissions %s: failed\n", path);
+return -1;
+}
+return 0;
+}
+
 int xenstore_write_str(const char *base, const char *node, const char *val)
 {
 char abspath[XEN_BUFSIZE];
-- 
1.9.1


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

[Xen-devel] [PULL 10/13] xen: Rename xen_be_send_notify

[Stefano Stabellini]

From: Emil Condrea 

Prepare xen_be_send_notify to be shared with frontends:
 * xen_be_send_notify -> xen_pv_send_notify

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/block/xen_disk.c| 4 ++--
 hw/char/xen_console.c  | 4 ++--
 hw/display/xenfb.c | 8 
 hw/net/xen_nic.c   | 4 ++--
 hw/usb/xen-usb.c   | 6 +++---
 hw/xen/xen_pvdev.c | 2 +-
 include/hw/xen/xen_pvdev.h | 2 +-
 7 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 8f7fe41..3a7dc19 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -796,7 +796,7 @@ static void blk_send_response_all(struct XenBlkDev *blkdev)
 ioreq_release(ioreq, true);
 }
 if (send_notify) {
-xen_be_send_notify(>xendev);
+xen_pv_send_notify(>xendev);
 }
 }
 
@@ -866,7 +866,7 @@ static void blk_handle_requests(struct XenBlkDev *blkdev)
 };
 
 if (blk_send_response_one(ioreq)) {
-xen_be_send_notify(>xendev);
+xen_pv_send_notify(>xendev);
 }
 ioreq_release(ioreq, false);
 continue;
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 15463dc..c01f410 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -74,7 +74,7 @@ static void buffer_append(struct XenConsole *con)
 
 xen_mb();
 intf->out_cons = cons;
-xen_be_send_notify(>xendev);
+xen_pv_send_notify(>xendev);
 
 if (buffer->max_capacity &&
buffer->size > buffer->max_capacity) {
@@ -142,7 +142,7 @@ static void xencons_receive(void *opaque, const uint8_t 
*buf, int len)
 }
 xen_wmb();
 intf->in_prod = prod;
-xen_be_send_notify(>xendev);
+xen_pv_send_notify(>xendev);
 }
 
 static void xencons_send(struct XenConsole *con)
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 1077575..184e735 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -215,7 +215,7 @@ static int xenfb_kbd_event(struct XenInput *xenfb,
 XENKBD_IN_RING_REF(page, prod) = *event;
 xen_wmb(); /* ensure ring contents visible */
 page->in_prod = prod + 1;
-return xen_be_send_notify(>c.xendev);
+return xen_pv_send_notify(>c.xendev);
 }
 
 /* Send a keyboard (or mouse button) event */
@@ -397,7 +397,7 @@ static void input_event(struct XenDevice *xendev)
 if (page->out_prod == page->out_cons)
return;
 page->out_cons = page->out_prod;
-xen_be_send_notify(>c.xendev);
+xen_pv_send_notify(>c.xendev);
 }
 
 /*  */
@@ -672,7 +672,7 @@ static void xenfb_send_event(struct XenFB *xenfb, union 
xenfb_in_event *event)
 xen_wmb();  /* ensure ring contents visible */
 page->in_prod = prod + 1;
 
-xen_be_send_notify(>c.xendev);
+xen_pv_send_notify(>c.xendev);
 }
 
 static void xenfb_send_refresh_period(struct XenFB *xenfb, int period)
@@ -945,7 +945,7 @@ static void fb_event(struct XenDevice *xendev)
 struct XenFB *xenfb = container_of(xendev, struct XenFB, c.xendev);
 
 xenfb_handle_events(xenfb);
-xen_be_send_notify(>c.xendev);
+xen_pv_send_notify(>c.xendev);
 }
 
 /*  */
diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index c996684..20c43a6 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -69,7 +69,7 @@ static void net_tx_response(struct XenNetDev *netdev, 
netif_tx_request_t *txp, i
 netdev->tx_ring.rsp_prod_pvt = ++i;
 RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>tx_ring, notify);
 if (notify) {
-xen_be_send_notify(>xendev);
+xen_pv_send_notify(>xendev);
 }
 
 if (i == netdev->tx_ring.req_cons) {
@@ -221,7 +221,7 @@ static void net_rx_response(struct XenNetDev *netdev,
 netdev->rx_ring.rsp_prod_pvt = ++i;
 RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>rx_ring, notify);
 if (notify) {
-xen_be_send_notify(>xendev);
+xen_pv_send_notify(>xendev);
 }
 }
 
diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 4ae9b6a..1b3c2fb 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -314,7 +314,7 @@ static void usbback_do_response(struct usbback_req 
*usbback_req, int32_t status,
 RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>urb_ring, notify);
 
 if (notify) {
-xen_be_send_notify(xendev);
+xen_pv_send_notify(xendev);
 }
 }
 
@@ -590,7 +590,7 @@ static void usbback_hotplug_notify(struct usbback_info 
*usbif)
 
 /* Check for full ring. */
 if ((RING_SIZE(ring) - ring->rsp_prod_pvt - ring->req_cons) == 0) {
-xen_be_send_notify(>xendev);
+xen_pv_send_notify(>xendev);
 return;
 }
 
@@ -609,7 +609,7 @@ 

[Xen-devel] [PULL 00/13] xen-20161028-tag

[Stefano Stabellini]

The following changes since commit 5b2ecabaeabc17f032197246c4846b9ba95ba8a6:

  Merge remote-tracking branch 'remotes/kraxel/tags/pull-ui-20161028-1' into 
staging (2016-10-28 17:59:04 +0100)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161028-tag

for you to fetch changes up to 71981364b6152e63d0f3098fcdf8b884fa9ffa50:

  xen: Rename xen_be_del_xendev (2016-10-28 17:54:49 -0700)


Xen 2016/10/28


Emil Condrea (13):
  xen: Fix coding style errors
  xen: Fix coding style warnings
  xen: Create a new file xen_pvdev.c
  xen: Move xenstore_update to xen_pvdev.c
  xen: Move evtchn functions to xen_pvdev.c
  xen: Prepare xendev qtail to be shared with frontends
  xen: Move xenstore cleanup and mkdir functions
  xen: Rename xen_be_printf to xen_pv_printf
  xen: Rename xen_be_unbind_evtchn
  xen: Rename xen_be_send_notify
  xen: Rename xen_be_evtchn_event
  xen: Rename xen_be_find_xendev
  xen: Rename xen_be_del_xendev

 hw/block/xen_disk.c  |  65 
 hw/char/xen_console.c|  30 ++--
 hw/display/xenfb.c   | 127 
 hw/net/xen_nic.c |  36 +++--
 hw/usb/xen-usb.c |  46 +++---
 hw/xen/Makefile.objs |   2 +-
 hw/xen/xen_backend.c | 348 +--
 hw/xen/xen_devconfig.c   |   4 +-
 hw/xen/xen_pvdev.c   | 316 +++
 include/hw/xen/xen_backend.h |  72 +
 include/hw/xen/xen_pvdev.h   |  78 ++
 xen-common.c |   4 +-
 12 files changed, 603 insertions(+), 525 deletions(-)
 create mode 100644 hw/xen/xen_pvdev.c
 create mode 100644 include/hw/xen/xen_pvdev.h

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

[Xen-devel] [PULL 02/13] xen: Fix coding style warnings

[Stefano Stabellini]

From: Emil Condrea 

Fixes:
 * WARNING: line over 80 characters

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/block/xen_disk.c  |  3 ++-
 hw/char/xen_console.c|  3 ++-
 hw/display/xenfb.c   |  6 --
 hw/net/xen_nic.c | 12 
 hw/xen/xen_backend.c | 15 ++-
 include/hw/xen/xen_backend.h |  8 +---
 6 files changed, 31 insertions(+), 16 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 1292a4b..5b037e7 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -1068,7 +1068,8 @@ static int blk_connect(struct XenDevice *xendev)
 blk_set_enable_write_cache(blkdev->blk, !writethrough);
 } else {
 /* setup via qemu cmdline -> already setup for us */
-xen_be_printf(>xendev, 2, "get configured bdrv (cmdline 
setup)\n");
+xen_be_printf(>xendev, 2,
+  "get configured bdrv (cmdline setup)\n");
 blkdev->blk = blk_by_legacy_dinfo(blkdev->dinfo);
 if (blk_is_read_only(blkdev->blk) && !readonly) {
 xen_be_printf(>xendev, 0, "Unexpected read-only drive");
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index d236a46..9ae9558 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -248,7 +248,8 @@ static int con_initialise(struct XenDevice *xendev)
 qemu_chr_fe_set_handlers(>chr, xencons_can_receive,
  xencons_receive, NULL, con, NULL, true);
 
-xen_be_printf(xendev, 1, "ring mfn %d, remote port %d, local port %d, 
limit %zd\n",
+xen_be_printf(xendev, 1,
+  "ring mfn %d, remote port %d, local port %d, limit %zd\n",
  con->ring_ref,
  con->xendev.remote_port,
  con->xendev.local_port,
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index eaa1fce..d458fc1 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -561,7 +561,8 @@ static int xenfb_configure_fb(struct XenFB *xenfb, size_t 
fb_len_lim,
 xenfb->offset = offset;
 xenfb->up_fullscreen = 1;
 xenfb->do_resize = 1;
-xen_be_printf(>c.xendev, 1, "framebuffer %dx%dx%d offset %d stride 
%d\n",
+xen_be_printf(>c.xendev, 1,
+  "framebuffer %dx%dx%d offset %d stride %d\n",
   width, height, depth, offset, row_stride);
 return 0;
 }
@@ -729,7 +730,8 @@ static void xenfb_update(void *opaque)
 break;
 }
 dpy_gfx_replace_surface(xenfb->c.con, surface);
-xen_be_printf(>c.xendev, 1, "update: resizing: %dx%d @ %d 
bpp%s\n",
+xen_be_printf(>c.xendev, 1,
+  "update: resizing: %dx%d @ %d bpp%s\n",
   xenfb->width, xenfb->height, xenfb->depth,
   is_buffer_shared(surface) ? " (shared)" : "");
 xenfb->up_fullscreen = 1;
diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 9d93466..dbf3a89 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -140,7 +140,8 @@ static void net_tx_packets(struct XenNetDev *netdev)
 #endif
 
 if (txreq.size < 14) {
-xen_be_printf(>xendev, 0, "bad packet size: %d\n", 
txreq.size);
+xen_be_printf(>xendev, 0, "bad packet size: %d\n",
+  txreq.size);
 net_tx_error(netdev, , rc);
 continue;
 }
@@ -213,7 +214,8 @@ static void net_rx_response(struct XenNetDev *netdev,
 resp->status = (int16_t)st;
 }
 
-xen_be_printf(>xendev, 3, "rx response: idx %d, status %d, flags 
0x%x\n",
+xen_be_printf(>xendev, 3,
+  "rx response: idx %d, status %d, flags 0x%x\n",
   i, resp->status, resp->flags);
 
 netdev->rx_ring.rsp_prod_pvt = ++i;
@@ -256,7 +258,8 @@ static ssize_t net_rx_packet(NetClientState *nc, const 
uint8_t *buf, size_t size
netdev->xendev.dom,
rxreq.gref, PROT_WRITE);
 if (page == NULL) {
-xen_be_printf(>xendev, 0, "error: rx gref dereference failed 
(%d)\n",
+xen_be_printf(>xendev, 0,
+  "error: rx gref dereference failed (%d)\n",
   rxreq.gref);
 net_rx_response(netdev, , NETIF_RSP_ERROR, 0, 0, 0);
 return -1;
@@ -330,7 +333,8 @@ static int net_connect(struct XenDevice *xendev)
 rx_copy = 0;
 }
 if (rx_copy == 0) {
-xen_be_printf(>xendev, 0, "frontend doesn't support 
rx-copy.\n");
+xen_be_printf(>xendev, 0,
+  "frontend doesn't support rx-copy.\n");
 return -1;
 }
 
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 545ee47..0e95880 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -53,7 

[Xen-devel] [PULL 03/13] xen: Create a new file xen_pvdev.c

[Stefano Stabellini]

From: Emil Condrea 

The purpose of the new file is to store generic functions shared by frontend
and backends such as xenstore operations, xendevs.

Signed-off-by: Quan Xu 
Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/xen/Makefile.objs |   2 +-
 hw/xen/xen_backend.c | 126 +---
 hw/xen/xen_pvdev.c   | 150 +++
 include/hw/xen/xen_backend.h |  64 +-
 include/hw/xen/xen_pvdev.h   |  69 
 5 files changed, 222 insertions(+), 189 deletions(-)
 create mode 100644 hw/xen/xen_pvdev.c
 create mode 100644 include/hw/xen/xen_pvdev.h

diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index d367094..591cdc2 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
 # xen backend driver support
-common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
+common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o xen_pvdev.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o 
xen_pt_graphics.o xen_pt_msi.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 0e95880..b32b0dd 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -30,6 +30,7 @@
 #include "sysemu/char.h"
 #include "qemu/log.h"
 #include "hw/xen/xen_backend.h"
+#include "hw/xen/xen_pvdev.h"
 
 #include 
 
@@ -57,8 +58,6 @@ static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs =
 QTAILQ_HEAD_INITIALIZER(xendevs);
 static int debug;
 
-/* - */
-
 static void xenstore_cleanup_dir(char *dir)
 {
 struct xs_dirs *d;
@@ -77,34 +76,6 @@ void xen_config_cleanup(void)
 }
 }
 
-int xenstore_write_str(const char *base, const char *node, const char *val)
-{
-char abspath[XEN_BUFSIZE];
-
-snprintf(abspath, sizeof(abspath), "%s/%s", base, node);
-if (!xs_write(xenstore, 0, abspath, val, strlen(val))) {
-return -1;
-}
-return 0;
-}
-
-char *xenstore_read_str(const char *base, const char *node)
-{
-char abspath[XEN_BUFSIZE];
-unsigned int len;
-char *str, *ret = NULL;
-
-snprintf(abspath, sizeof(abspath), "%s/%s", base, node);
-str = xs_read(xenstore, 0, abspath, );
-if (str != NULL) {
-/* move to qemu-allocated memory to make sure
- * callers can savely g_free() stuff. */
-ret = g_strdup(str);
-free(str);
-}
-return ret;
-}
-
 int xenstore_mkdir(char *path, int p)
 {
 struct xs_permissions perms[2] = {
@@ -129,48 +100,6 @@ int xenstore_mkdir(char *path, int p)
 return 0;
 }
 
-int xenstore_write_int(const char *base, const char *node, int ival)
-{
-char val[12];
-
-snprintf(val, sizeof(val), "%d", ival);
-return xenstore_write_str(base, node, val);
-}
-
-int xenstore_write_int64(const char *base, const char *node, int64_t ival)
-{
-char val[21];
-
-snprintf(val, sizeof(val), "%"PRId64, ival);
-return xenstore_write_str(base, node, val);
-}
-
-int xenstore_read_int(const char *base, const char *node, int *ival)
-{
-char *val;
-int rc = -1;
-
-val = xenstore_read_str(base, node);
-if (val && 1 == sscanf(val, "%d", ival)) {
-rc = 0;
-}
-g_free(val);
-return rc;
-}
-
-int xenstore_read_uint64(const char *base, const char *node, uint64_t *uval)
-{
-char *val;
-int rc = -1;
-
-val = xenstore_read_str(base, node);
-if (val && 1 == sscanf(val, "%"SCNu64, uval)) {
-rc = 0;
-}
-g_free(val);
-return rc;
-}
-
 int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const 
char *val)
 {
 return xenstore_write_str(xendev->be, node, val);
@@ -214,20 +143,6 @@ int xenstore_read_fe_uint64(struct XenDevice *xendev, 
const char *node,
 
 /* - */
 
-const char *xenbus_strstate(enum xenbus_state state)
-{
-static const char *const name[] = {
-[XenbusStateUnknown]   = "Unknown",
-[XenbusStateInitialising]  = "Initialising",
-[XenbusStateInitWait]  = "InitWait",
-[XenbusStateInitialised]   = "Initialised",
-[XenbusStateConnected] = "Connected",
-[XenbusStateClosing]   = "Closing",
-[XenbusStateClosed]= "Closed",
-};
-return (state < ARRAY_SIZE(name)) ? name[state] : "INVALID";
-}
-
 int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state)
 {
 int rc;
@@ -827,45 +742,6 @@ int xen_be_send_notify(struct XenDevice *xendev)
 return xenevtchn_notify(xendev->evtchndev, xendev->local_port);
 }
 
-/*
- * msg_level:
- *  0 == errors (stderr + logfile).
- *  1 == informative debug 

[Xen-devel] [PULL 11/13] xen: Rename xen_be_evtchn_event

[Stefano Stabellini]

From: Emil Condrea 

Prepare xen_be_evtchn_event to be shared with frontends:
 * xen_be_evtchn_event -> xen_pv_evtchn_event

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/xen/xen_backend.c   | 2 +-
 hw/xen/xen_pvdev.c | 2 +-
 include/hw/xen/xen_pvdev.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index e960dad..f594dba 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -581,7 +581,7 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 }
 xen_pv_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
 qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev),
-xen_be_evtchn_event, NULL, xendev);
+xen_pv_evtchn_event, NULL, xendev);
 return 0;
 }
 
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index 8c7e3f5..28acf61 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -227,7 +227,7 @@ void xen_pv_printf(struct XenDevice *xendev, int msg_level,
 qemu_log_flush();
 }
 
-void xen_be_evtchn_event(void *opaque)
+void xen_pv_evtchn_event(void *opaque)
 {
 struct XenDevice *xendev = opaque;
 evtchn_port_t port;
diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h
index 2e5d6e1..caf1edc 100644
--- a/include/hw/xen/xen_pvdev.h
+++ b/include/hw/xen/xen_pvdev.h
@@ -64,7 +64,7 @@ void xenstore_update(void *unused);
 
 const char *xenbus_strstate(enum xenbus_state state);
 
-void xen_be_evtchn_event(void *opaque);
+void xen_pv_evtchn_event(void *opaque);
 void xen_pv_insert_xendev(struct XenDevice *xendev);
 void xen_be_del_xendev(struct XenDevice *xendev);
 struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev);
-- 
1.9.1


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

[Xen-devel] [PULL 13/13] xen: Rename xen_be_del_xendev

[Stefano Stabellini]

From: Emil Condrea 

Prepare xen_be_del_xendev to be shared with frontends:
 * xen_be_del_xendev -> xen_pv_del_xendev

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/xen/xen_backend.c   | 2 +-
 hw/xen/xen_pvdev.c | 2 +-
 include/hw/xen/xen_pvdev.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 98fcb77..41ba5c5 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -483,7 +483,7 @@ void xenstore_update_be(char *watch, char *type, int dom,
 if (xendev != NULL) {
 bepath = xs_read(xenstore, 0, xendev->be, );
 if (bepath == NULL) {
-xen_be_del_xendev(xendev);
+xen_pv_del_xendev(xendev);
 } else {
 free(bepath);
 xen_be_backend_changed(xendev, path);
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index af29150..405e154 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -286,7 +286,7 @@ struct XenDevice *xen_pv_find_xendev(const char *type, int 
dom, int dev)
 /*
  * release xen backend device.
  */
-void xen_be_del_xendev(struct XenDevice *xendev)
+void xen_pv_del_xendev(struct XenDevice *xendev)
 {
 if (xendev->ops->free) {
 xendev->ops->free(xendev);
diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h
index 4b1cc60..083f0a9 100644
--- a/include/hw/xen/xen_pvdev.h
+++ b/include/hw/xen/xen_pvdev.h
@@ -66,7 +66,7 @@ const char *xenbus_strstate(enum xenbus_state state);
 
 void xen_pv_evtchn_event(void *opaque);
 void xen_pv_insert_xendev(struct XenDevice *xendev);
-void xen_be_del_xendev(struct XenDevice *xendev);
+void xen_pv_del_xendev(struct XenDevice *xendev);
 struct XenDevice *xen_pv_find_xendev(const char *type, int dom, int dev);
 
 void xen_pv_unbind_evtchn(struct XenDevice *xendev);
-- 
1.9.1


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

[Xen-devel] [PULL 04/13] xen: Move xenstore_update to xen_pvdev.c

[Stefano Stabellini]

From: Emil Condrea 

 * xenstore_update -> xen_pvdev.c

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/xen/xen_backend.c | 30 +++---
 hw/xen/xen_pvdev.c   | 23 +++
 include/hw/xen/xen_backend.h |  3 +++
 include/hw/xen/xen_pvdev.h   |  1 +
 4 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b32b0dd..e3a7d95 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -556,8 +556,8 @@ static int xenstore_scan(const char *type, int dom, struct 
XenDevOps *ops)
 return 0;
 }
 
-static void xenstore_update_be(char *watch, char *type, int dom,
-   struct XenDevOps *ops)
+void xenstore_update_be(char *watch, char *type, int dom,
+struct XenDevOps *ops)
 {
 struct XenDevice *xendev;
 char path[XEN_BUFSIZE], *bepath;
@@ -590,7 +590,7 @@ static void xenstore_update_be(char *watch, char *type, int 
dom,
 }
 }
 
-static void xenstore_update_fe(char *watch, struct XenDevice *xendev)
+void xenstore_update_fe(char *watch, struct XenDevice *xendev)
 {
 char *node;
 unsigned int len;
@@ -607,30 +607,6 @@ static void xenstore_update_fe(char *watch, struct 
XenDevice *xendev)
 xen_be_frontend_changed(xendev, node);
 xen_be_check_state(xendev);
 }
-
-static void xenstore_update(void *unused)
-{
-char **vec = NULL;
-intptr_t type, ops, ptr;
-unsigned int dom, count;
-
-vec = xs_read_watch(xenstore, );
-if (vec == NULL) {
-goto cleanup;
-}
-
-if (sscanf(vec[XS_WATCH_TOKEN], "be:%" PRIxPTR ":%d:%" PRIxPTR,
-   , , ) == 3) {
-xenstore_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void*)ops);
-}
-if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, ) == 1) {
-xenstore_update_fe(vec[XS_WATCH_PATH], (void *)ptr);
-}
-
-cleanup:
-free(vec);
-}
-
 static void xen_be_evtchn_event(void *opaque)
 {
 struct XenDevice *xendev = opaque;
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index a1dc2be..22a1abe 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -95,6 +95,29 @@ int xenstore_read_uint64(const char *base, const char *node, 
uint64_t *uval)
 return rc;
 }
 
+void xenstore_update(void *unused)
+{
+char **vec = NULL;
+intptr_t type, ops, ptr;
+unsigned int dom, count;
+
+vec = xs_read_watch(xenstore, );
+if (vec == NULL) {
+goto cleanup;
+}
+
+if (sscanf(vec[XS_WATCH_TOKEN], "be:%" PRIxPTR ":%d:%" PRIxPTR,
+   , , ) == 3) {
+xenstore_update_be(vec[XS_WATCH_PATH], (void *)type, dom, (void*)ops);
+}
+if (sscanf(vec[XS_WATCH_TOKEN], "fe:%" PRIxPTR, ) == 1) {
+xenstore_update_fe(vec[XS_WATCH_PATH], (void *)ptr);
+}
+
+cleanup:
+free(vec);
+}
+
 const char *xenbus_strstate(enum xenbus_state state)
 {
 static const char *const name[] = {
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 973cb4b..2e54150 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -19,6 +19,9 @@ int xenstore_write_be_int(struct XenDevice *xendev, const 
char *node, int ival);
 int xenstore_write_be_int64(struct XenDevice *xendev, const char *node, 
int64_t ival);
 char *xenstore_read_be_str(struct XenDevice *xendev, const char *node);
 int xenstore_read_be_int(struct XenDevice *xendev, const char *node, int 
*ival);
+void xenstore_update_fe(char *watch, struct XenDevice *xendev);
+void xenstore_update_be(char *watch, char *type, int dom,
+struct XenDevOps *ops);
 char *xenstore_read_fe_str(struct XenDevice *xendev, const char *node);
 int xenstore_read_fe_int(struct XenDevice *xendev, const char *node, int 
*ival);
 int xenstore_read_fe_uint64(struct XenDevice *xendev, const char *node,
diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h
index cd3d6bc..3c4cc01 100644
--- a/include/hw/xen/xen_pvdev.h
+++ b/include/hw/xen/xen_pvdev.h
@@ -60,6 +60,7 @@ int xenstore_write_int64(const char *base, const char *node, 
int64_t ival);
 char *xenstore_read_str(const char *base, const char *node);
 int xenstore_read_int(const char *base, const char *node, int *ival);
 int xenstore_read_uint64(const char *base, const char *node, uint64_t *uval);
+void xenstore_update(void *unused);
 
 const char *xenbus_strstate(enum xenbus_state state);
 
-- 
1.9.1


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

[Xen-devel] [PULL 08/13] xen: Rename xen_be_printf to xen_pv_printf

[Stefano Stabellini]

From: Emil Condrea 

Prepare xen_be_printf to be used by both backend and frontends:
 * xen_be_printf -> xen_pv_printf

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/block/xen_disk.c| 58 +++---
 hw/char/xen_console.c  |  8 +++
 hw/display/xenfb.c | 42 -
 hw/net/xen_nic.c   | 22 +-
 hw/usb/xen-usb.c   | 38 +++---
 hw/xen/xen_backend.c   | 46 ++--
 hw/xen/xen_devconfig.c |  4 ++--
 hw/xen/xen_pvdev.c | 10 
 include/hw/xen/xen_pvdev.h |  2 +-
 xen-common.c   |  4 ++--
 10 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 5b037e7..6145567 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -167,12 +167,12 @@ static void destroy_grant(gpointer pgnt)
 xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
 
 if (xengnttab_unmap(gnt, grant->page, 1) != 0) {
-xen_be_printf(>blkdev->xendev, 0,
+xen_pv_printf(>blkdev->xendev, 0,
   "xengnttab_unmap failed: %s\n",
   strerror(errno));
 }
 grant->blkdev->persistent_gnt_count--;
-xen_be_printf(>blkdev->xendev, 3,
+xen_pv_printf(>blkdev->xendev, 3,
   "unmapped grant %p\n", grant->page);
 g_free(grant);
 }
@@ -184,11 +184,11 @@ static void remove_persistent_region(gpointer data, 
gpointer dev)
 xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
 
 if (xengnttab_unmap(gnt, region->addr, region->num) != 0) {
-xen_be_printf(>xendev, 0,
+xen_pv_printf(>xendev, 0,
   "xengnttab_unmap region %p failed: %s\n",
   region->addr, strerror(errno));
 }
-xen_be_printf(>xendev, 3,
+xen_pv_printf(>xendev, 3,
   "unmapped grant region %p with %d pages\n",
   region->addr, region->num);
 g_free(region);
@@ -255,7 +255,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 size_t len;
 int i;
 
-xen_be_printf(>xendev, 3,
+xen_pv_printf(>xendev, 3,
   "op %d, nr %d, handle %d, id %" PRId64 ", sector %" PRId64 
"\n",
   ioreq->req.operation, ioreq->req.nr_segments,
   ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number);
@@ -275,28 +275,28 @@ static int ioreq_parse(struct ioreq *ioreq)
 case BLKIF_OP_DISCARD:
 return 0;
 default:
-xen_be_printf(>xendev, 0, "error: unknown operation (%d)\n",
+xen_pv_printf(>xendev, 0, "error: unknown operation (%d)\n",
   ioreq->req.operation);
 goto err;
 };
 
 if (ioreq->req.operation != BLKIF_OP_READ && blkdev->mode[0] != 'w') {
-xen_be_printf(>xendev, 0, "error: write req for ro device\n");
+xen_pv_printf(>xendev, 0, "error: write req for ro device\n");
 goto err;
 }
 
 ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
 for (i = 0; i < ioreq->req.nr_segments; i++) {
 if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
-xen_be_printf(>xendev, 0, "error: nr_segments too big\n");
+xen_pv_printf(>xendev, 0, "error: nr_segments too big\n");
 goto err;
 }
 if (ioreq->req.seg[i].first_sect > ioreq->req.seg[i].last_sect) {
-xen_be_printf(>xendev, 0, "error: first > last sector\n");
+xen_pv_printf(>xendev, 0, "error: first > last sector\n");
 goto err;
 }
 if (ioreq->req.seg[i].last_sect * BLOCK_SIZE >= XC_PAGE_SIZE) {
-xen_be_printf(>xendev, 0, "error: page crossing\n");
+xen_pv_printf(>xendev, 0, "error: page crossing\n");
 goto err;
 }
 
@@ -308,7 +308,7 @@ static int ioreq_parse(struct ioreq *ioreq)
 qemu_iovec_add(>v, (void*)mem, len);
 }
 if (ioreq->start + ioreq->v.size > blkdev->file_size) {
-xen_be_printf(>xendev, 0, "error: access beyond end of 
file\n");
+xen_pv_printf(>xendev, 0, "error: access beyond end of 
file\n");
 goto err;
 }
 return 0;
@@ -331,7 +331,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 return;
 }
 if (xengnttab_unmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
-xen_be_printf(>blkdev->xendev, 0,
+xen_pv_printf(>blkdev->xendev, 0,
   "xengnttab_unmap failed: %s\n",
   strerror(errno));
 }
@@ -343,7 +343,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 continue;
 }
 if (xengnttab_unmap(gnt, ioreq->page[i], 1) != 0) {
-   

[Xen-devel] [PULL 01/13] xen: Fix coding style errors

[Stefano Stabellini]

From: Emil Condrea 

Fixes the following errors:
 * ERROR: line over 90 characters
 * ERROR: code indent should never use tabs
 * ERROR: space prohibited after that open square bracket '['
 * ERROR: do not initialise statics to 0 or NULL
 * ERROR: "(foo*)" should be "(foo *)"

Signed-off-by: Emil Condrea 
Signed-off-by: Stefano Stabellini 
Signed-off-by: Quan Xu 
Acked-by: Anthony PERARD 
---
 hw/char/xen_console.c | 21 ++--
 hw/display/xenfb.c| 91 ---
 hw/net/xen_nic.c  |  8 +++--
 hw/xen/xen_backend.c  | 20 +--
 4 files changed, 76 insertions(+), 64 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 86cdc52..d236a46 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -158,16 +158,17 @@ static void xencons_send(struct XenConsole *con)
 len = size;
 }
 if (len < 1) {
-   if (!con->backlog) {
-   con->backlog = 1;
-   xen_be_printf(>xendev, 1, "backlog piling up, nobody 
listening?\n");
-   }
+if (!con->backlog) {
+con->backlog = 1;
+xen_be_printf(>xendev, 1,
+  "backlog piling up, nobody listening?\n");
+}
 } else {
-   buffer_advance(>buffer, len);
-   if (con->backlog && len == size) {
-   con->backlog = 0;
-   xen_be_printf(>xendev, 1, "backlog is gone\n");
-   }
+buffer_advance(>buffer, len);
+if (con->backlog && len == size) {
+con->backlog = 0;
+xen_be_printf(>xendev, 1, "backlog is gone\n");
+}
 }
 }
 
@@ -191,7 +192,7 @@ static int con_init(struct XenDevice *xendev)
 
 type = xenstore_read_str(con->console, "type");
 if (!type || strcmp(type, "ioemu") != 0) {
-   xen_be_printf(xendev, 1, "not for me (type=%s)\n", type);
+xen_be_printf(xendev, 1, "not for me (type=%s)\n", type);
 ret = -1;
 goto out;
 }
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 46b7d5e..eaa1fce 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -90,21 +90,22 @@ static int common_bind(struct common *c)
 xen_pfn_t mfn;
 
 if (xenstore_read_fe_uint64(>xendev, "page-ref", ) == -1)
-   return -1;
+return -1;
 mfn = (xen_pfn_t)val;
 assert(val == mfn);
 
 if (xenstore_read_fe_int(>xendev, "event-channel", 
>xendev.remote_port) == -1)
-   return -1;
+return -1;
 
 c->page = xenforeignmemory_map(xen_fmem, c->xendev.dom,
PROT_READ | PROT_WRITE, 1, , NULL);
 if (c->page == NULL)
-   return -1;
+return -1;
 
 xen_be_bind_evtchn(>xendev);
-xen_be_printf(>xendev, 1, "ring mfn %"PRI_xen_pfn", remote-port %d, 
local-port %d\n",
- mfn, c->xendev.remote_port, c->xendev.local_port);
+xen_be_printf(>xendev, 1,
+  "ring mfn %"PRI_xen_pfn", remote-port %d, local-port %d\n",
+  mfn, c->xendev.remote_port, c->xendev.local_port);
 
 return 0;
 }
@@ -500,8 +501,8 @@ out:
 }
 
 static int xenfb_configure_fb(struct XenFB *xenfb, size_t fb_len_lim,
- int width, int height, int depth,
- size_t fb_len, int offset, int row_stride)
+  int width, int height, int depth,
+  size_t fb_len, int offset, int row_stride)
 {
 size_t mfn_sz = sizeof(*((struct xenfb_page *)0)->pd);
 size_t pd_len = sizeof(((struct xenfb_page *)0)->pd) / mfn_sz;
@@ -510,40 +511,47 @@ static int xenfb_configure_fb(struct XenFB *xenfb, size_t 
fb_len_lim,
 int max_width, max_height;
 
 if (fb_len_lim > fb_len_max) {
-   xen_be_printf(>c.xendev, 0, "fb size limit %zu exceeds %zu, 
corrected\n",
- fb_len_lim, fb_len_max);
-   fb_len_lim = fb_len_max;
+xen_be_printf(>c.xendev, 0,
+  "fb size limit %zu exceeds %zu, corrected\n",
+  fb_len_lim, fb_len_max);
+fb_len_lim = fb_len_max;
 }
 if (fb_len_lim && fb_len > fb_len_lim) {
-   xen_be_printf(>c.xendev, 0, "frontend fb size %zu limited to 
%zu\n",
- fb_len, fb_len_lim);
-   fb_len = fb_len_lim;
+xen_be_printf(>c.xendev, 0,
+  "frontend fb size %zu limited to %zu\n",
+  fb_len, fb_len_lim);
+fb_len = fb_len_lim;
 }
 if (depth != 8 && depth != 16 && depth != 24 && depth != 32) {
-   xen_be_printf(>c.xendev, 0, "can't handle frontend fb depth 
%d\n",
- depth);
-   return -1;
+xen_be_printf(>c.xendev, 0,
+  "can't handle frontend fb depth %d\n",
+  depth);
+return -1;
 }
 if (row_stride <= 0 || row_stride > fb_len) {

[Xen-devel] [linux-3.4 test] 101746: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
92983
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 92983
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 92983

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101695 pass 
in 101746
 test-amd64-amd64-i386-pvgrub  6 xen-boot   fail pass in 101695
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101695
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101695
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101720
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101720

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun7 xen-buildfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux8d1988f838a95e836342b505398d38b223181f17
baseline version:
 linux343a5fbeef08baf2097b8cf4e26137cebe3cfef4

Last test of basis92983  2016-04-27 16:21:44 Z  184 days
Testing same since   101695  2016-10-26 18:26:23 Z2 days3 attempts


People who touched revisions under test:
  "Suzuki K. Poulose" 
  Aaro Koskinen 
  Al Viro 
  Alan Stern 
  Aleksander Morgado 
  Alex Thorlton 
  Alexandru Cornea 
  Alexey Khoroshilov 
  Amitkumar Karwar 
  Andrew Banman 
  Andrew Morton 
  Andrey Ryabinin 
  Anson Huang 
  Arnaldo Carvalho de Melo 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Ben Hutchings 
  Bjørn Mork 
  Boris Brezillon 
  Borislav Petkov 
  Brian Norris 
  Charles Keepax 
  Chen Yu 
  Christoph Hellwig 
  Chunfeng Yun 
  Clemens Ladisch 
  Colin Ian King 
  Cong Wang 
  Daeho Jeong 
  Dan Carpenter 
  Darren Hart 
  Dave Airlie 
  David Howells 
  David Rientjes 
  David 

Re: [Xen-devel] [RFC PATCH 11/24] ARM: vGICv3: handle virtual LPI pending and property tables

[Stefano Stabellini]

On Wed, 28 Sep 2016, Andre Przywara wrote:
> Allow a guest to provide the address and size for the memory regions
> it has reserved for the GICv3 pending and property tables.
> We sanitise the various fields of the respective redistributor
> registers and map those pages into Xen's address space to have easy
> access.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-v3.c| 189 
> ++
>  xen/arch/arm/vgic.c   |   4 +
>  xen/include/asm-arm/domain.h  |   7 +-
>  xen/include/asm-arm/gic-its.h |  10 ++-
>  xen/include/asm-arm/vgic.h|   3 +
>  5 files changed, 197 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index e9b6490..8fe8386 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -20,12 +20,14 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -228,12 +230,14 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu 
> *v, mmio_info_t *info,
>  goto read_reserved;
>  
>  case VREG64(GICR_PROPBASER):
> -/* LPI's not implemented */
> -goto read_as_zero_64;
> +if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> +*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
> +return 1;
>  
>  case VREG64(GICR_PENDBASER):
> -/* LPI's not implemented */
> -goto read_as_zero_64;
> +if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> +*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
> +return 1;
>  
>  case 0x0080:
>  goto read_reserved;
> @@ -301,11 +305,6 @@ bad_width:
>  domain_crash_synchronous();
>  return 0;
>  
> -read_as_zero_64:
> -if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> -*r = 0;
> -return 1;
> -
>  read_as_zero_32:
>  if ( dabt.size != DABT_WORD ) goto bad_width;
>  *r = 0;
> @@ -330,11 +329,149 @@ read_unknown:
>  return 1;
>  }
>  
> +static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
> +int field_shift,
> +uint64_t (*sanitise_fn)(uint64_t))
> +{
> +uint64_t field = (reg & field_mask) >> field_shift;
> +
> +field = sanitise_fn(field) << field_shift;
> +return (reg & ~field_mask) | field;
> +}
> +
> +/* We want to avoid outer shareable. */
> +static uint64_t vgic_sanitise_shareability(uint64_t field)
> +{
> +switch (field) {
> +case GIC_BASER_OuterShareable:
> +return GIC_BASER_InnerShareable;
> +default:
> +return field;
> +}
> +}
> +
> +/* Avoid any inner non-cacheable mapping. */
> +static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
> +{
> +switch (field) {
> +case GIC_BASER_CACHE_nCnB:
> +case GIC_BASER_CACHE_nC:
> +return GIC_BASER_CACHE_RaWb;
> +default:
> +return field;
> +}
> +}
> +
> +/* Non-cacheable or same-as-inner are OK. */
> +static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
> +{
> +switch (field) {
> +case GIC_BASER_CACHE_SameAsInner:
> +case GIC_BASER_CACHE_nC:
> +return field;
> +default:
> +return GIC_BASER_CACHE_nC;
> +}
> +}
> +
> +static uint64_t sanitize_propbaser(uint64_t reg)
> +{
> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
> +  GICR_PROPBASER_SHAREABILITY_SHIFT,
> +  vgic_sanitise_shareability);
> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
> +  GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
> +  vgic_sanitise_inner_cacheability);
> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
> +  GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
> +  vgic_sanitise_outer_cacheability);
> +
> +reg &= ~PROPBASER_RES0_MASK;
> +reg &= ~GENMASK(51, 48);
> +return reg;
> +}
> +
> +static uint64_t sanitize_pendbaser(uint64_t reg)
> +{
> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
> +  GICR_PENDBASER_SHAREABILITY_SHIFT,
> +  vgic_sanitise_shareability);
> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
> +  GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
> +  vgic_sanitise_inner_cacheability);
> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
> +  GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
> +  vgic_sanitise_outer_cacheability);
> +
> +reg &= ~PENDBASER_RES0_MASK;
> +reg &= ~GENMASK(51, 48);
> +

[Xen-devel] [distros-debian-jessie test] 67954: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-i386-jessie-netboot-pvgrub 10 guest-start  fail like 67919

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass

baseline version:
 flight   67919

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   fail
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-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
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 67957: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67957 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67957/

Regressions :-(

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

version targeted for testing:
 ovmf d1b757e2cd034e32676c5cc2d542f785e74f8c5d
baseline version:
 ovmf 0a18956d54cfe70b736b029c62ce53f29b903745

Last test of basis67952  2016-10-27 21:51:32 Z1 days
Testing same since67957  2016-10-28 13:17:43 Z0 days1 attempts


People who touched revisions under test:
  David Wei 
  Gary Lin 
  gdong1 
  Guo Dong 
  Jiewen Yao 
  Jordan Justen 
  Laszlo Ersek 
  Maurice Ma 
  Michael Kinney 
  Satya Yarlagadda 
  Star Zeng 
  Yao, Jiewen 
  Yarlagadda, Satya P 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  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.

(No revision log; it would be 893 lines long.)

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

Re: [Xen-devel] [RFC PATCH 10/24] ARM: GICv3: enable ITS and LPIs on the host

[Stefano Stabellini]

On Wed, 28 Sep 2016, Andre Przywara wrote:
> Now that the host part of the ITS code is in place, we can enable the
> ITS and also LPIs on each redistributor to get the show rolling.
> At this point there would be no LPIs mapped, as guests don't know about
> the ITS yet.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/gic-its.c |  4 
>  xen/arch/arm/gic-v3.c  | 19 +++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> index b7aa918..6bac422 100644
> --- a/xen/arch/arm/gic-its.c
> +++ b/xen/arch/arm/gic-its.c
> @@ -449,6 +449,10 @@ int gicv3_its_init(struct host_its *hw_its)
>  its_send_cmd_mapc(hw_its, smp_processor_id(), smp_processor_id());
>  its_send_cmd_sync(hw_its, smp_processor_id());
>  
> +/* Now enable interrupt translation on that ITS. */
> +reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
> +writel_relaxed(reg | GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
> +
>  return 0;
>  }
>  
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index b9387a3..57009c6 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -642,6 +642,21 @@ static void gicv3_rdist_init_lpis(void __iomem * 
> rdist_base)
>  gicv3_its_setup_collection(smp_processor_id());
>  }
>  
> +/* Enable LPIs on this redistributor (only useful when the host has an ITS. 
> */
> +static bool gicv3_enable_lpis(void)
> +{
> +uint32_t val;
> +
> +val = readl_relaxed(GICD_RDIST_BASE + GICR_TYPER);
> +if ( !(val & GICR_TYPER_PLPIS) )
> +return false;
> +
> +val = readl_relaxed(GICD_RDIST_BASE + GICR_CTLR);
> +writel_relaxed(val | GICR_CTLR_ENABLE_LPIS, GICD_RDIST_BASE + GICR_CTLR);
> +
> +return true;
> +}
> +
>  static int __init gicv3_populate_rdist(void)
>  {
>  int i;
> @@ -741,6 +756,10 @@ static int gicv3_cpu_init(void)
>  if ( gicv3_enable_redist() )
>  return -ENODEV;
>  
> +/* If the host has any ITSes, enable LPIs now. */
> +if ( !list_empty(_its_list) )
> +gicv3_enable_lpis();
> +
>  /* Set priority on PPI and SGI interrupts */
>  priority = (GIC_PRI_IPI << 24 | GIC_PRI_IPI << 16 | GIC_PRI_IPI << 8 |
>  GIC_PRI_IPI);
> -- 
> 2.9.0
> 

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

[Xen-devel] [qemu-mainline baseline-only test] 67951: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67951 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67951/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail REGR. vs. 67935

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67935
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 67935

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

version targeted for testing:
 qemuuede0cbeb7892bdf4a19128853a3a3c61a17fb068
baseline version:
 qemuu4429532b48a25740817aa0901a4355a5de991e5b

Last test of basis67935  2016-10-26 04:18:12 Z2 days
Testing same since67951  2016-10-27 21:51:32 Z1 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  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

Re: [Xen-devel] [PATCH v6 10/11] x86, xen: support vcpu preempted check

[Konrad Rzeszutek Wilk]

On Fri, Oct 28, 2016 at 04:11:26AM -0400, Pan Xinhui wrote:
> From: Juergen Gross 
> 
> Support the vcpu_is_preempted() functionality under Xen. This will
> enhance lock performance on overcommitted hosts (more runnable vcpus
> than physical cpus in the system) as doing busy waits for preempted
> vcpus will hurt system performance far worse than early yielding.
> 
> A quick test (4 vcpus on 1 physical cpu doing a parallel build job
> with "make -j 8") reduced system time by about 5% with this patch.
> 
> Signed-off-by: Juergen Gross 
> Signed-off-by: Pan Xinhui 
> ---
>  arch/x86/xen/spinlock.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 3d6e006..74756bb 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -114,7 +114,6 @@ void xen_uninit_lock_cpu(int cpu)
>   per_cpu(irq_name, cpu) = NULL;
>  }
>  
> -

Spurious change.
>  /*
>   * Our init of PV spinlocks is split in two init functions due to us
>   * using paravirt patching and jump labels patching and having to do
> @@ -137,6 +136,8 @@ void __init xen_init_spinlocks(void)
>   pv_lock_ops.queued_spin_unlock = 
> PV_CALLEE_SAVE(__pv_queued_spin_unlock);
>   pv_lock_ops.wait = xen_qlock_wait;
>   pv_lock_ops.kick = xen_qlock_kick;
> +
> + pv_lock_ops.vcpu_is_preempted = xen_vcpu_stolen;
>  }
>  
>  /*
> -- 
> 2.4.11
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v6 00/11] implement vcpu preempted check

[Konrad Rzeszutek Wilk]

On Fri, Oct 28, 2016 at 04:11:16AM -0400, Pan Xinhui wrote:
> change from v5:
>   spilt x86/kvm patch into guest/host part.
>   introduce kvm_write_guest_offset_cached.
>   fix some typos.
>   rebase patch onto 4.9.2
> change from v4:
>   spilt x86 kvm vcpu preempted check into two patches.
>   add documentation patch.
>   add x86 vcpu preempted check patch under xen
>   add s390 vcpu preempted check patch 
> change from v3:
>   add x86 vcpu preempted check patch
> change from v2:
>   no code change, fix typos, update some comments
> change from v1:
>   a simplier definition of default vcpu_is_preempted
>   skip mahcine type check on ppc, and add config. remove dedicated macro.
>   add one patch to drop overload of rwsem_spin_on_owner and 
> mutex_spin_on_owner. 
>   add more comments
>   thanks boqun and Peter's suggestion.
> 
> This patch set aims to fix lock holder preemption issues.

Do you have a git tree with these patches?

> 
> test-case:
> perf record -a perf bench sched messaging -g 400 -p && perf report
> 
> 18.09%  sched-messaging  [kernel.vmlinux]  [k] osq_lock
> 12.28%  sched-messaging  [kernel.vmlinux]  [k] rwsem_spin_on_owner
>  5.27%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
>  3.89%  sched-messaging  [kernel.vmlinux]  [k] wait_consider_task
>  3.64%  sched-messaging  [kernel.vmlinux]  [k] _raw_write_lock_irq
>  3.41%  sched-messaging  [kernel.vmlinux]  [k] mutex_spin_on_owner.is
>  2.49%  sched-messaging  [kernel.vmlinux]  [k] system_call
> 
> We introduce interface bool vcpu_is_preempted(int cpu) and use it in some spin
> loops of osq_lock, rwsem_spin_on_owner and mutex_spin_on_owner.
> These spin_on_onwer variant also cause rcu stall before we apply this patch 
> set
> 
> We also have observed some performace improvements in uninx benchmark tests.
> 
> PPC test result:
> 1 copy - 0.94%
> 2 copy - 7.17%
> 4 copy - 11.9%
> 8 copy -  3.04%
> 16 copy - 15.11%
> 
> details below:
> Without patch:
> 
> 1 copy - File Write 4096 bufsize 8000 maxblocks  2188223.0 KBps  (30.0 s, 
> 1 samples)
> 2 copy - File Write 4096 bufsize 8000 maxblocks  1804433.0 KBps  (30.0 s, 
> 1 samples)
> 4 copy - File Write 4096 bufsize 8000 maxblocks  1237257.0 KBps  (30.0 s, 
> 1 samples)
> 8 copy - File Write 4096 bufsize 8000 maxblocks  1032658.0 KBps  (30.0 s, 
> 1 samples)
> 16 copy - File Write 4096 bufsize 8000 maxblocks   768000.0 KBps  (30.1 
> s, 1 samples)
> 
> With patch: 
> 
> 1 copy - File Write 4096 bufsize 8000 maxblocks  2209189.0 KBps  (30.0 s, 
> 1 samples)
> 2 copy - File Write 4096 bufsize 8000 maxblocks  1943816.0 KBps  (30.0 s, 
> 1 samples)
> 4 copy - File Write 4096 bufsize 8000 maxblocks  1405591.0 KBps  (30.0 s, 
> 1 samples)
> 8 copy - File Write 4096 bufsize 8000 maxblocks  1065080.0 KBps  (30.0 s, 
> 1 samples)
> 16 copy - File Write 4096 bufsize 8000 maxblocks   904762.0 KBps  (30.0 
> s, 1 samples)
> 
> X86 test result:
>   test-case   after-patch   before-patch
> Execl Throughput   |18307.9 lps  |11701.6 lps 
> File Copy 1024 bufsize 2000 maxblocks  |  1352407.3 KBps |   790418.9 KBps
> File Copy 256 bufsize 500 maxblocks|   367555.6 KBps |   222867.7 KBps
> File Copy 4096 bufsize 8000 maxblocks  |  3675649.7 KBps |  1780614.4 KBps
> Pipe Throughput| 11872208.7 lps  | 11855628.9 lps 
> Pipe-based Context Switching   |  1495126.5 lps  |  1490533.9 lps 
> Process Creation   |29881.2 lps  |28572.8 lps 
> Shell Scripts (1 concurrent)   |23224.3 lpm  |22607.4 lpm 
> Shell Scripts (8 concurrent)   | 3531.4 lpm  | 3211.9 lpm 
> System Call Overhead   | 10385653.0 lps  | 10419979.0 lps 
> 
> Christian Borntraeger (1):
>   s390/spinlock: Provide vcpu_is_preempted
> 
> Juergen Gross (1):
>   x86, xen: support vcpu preempted check
> 
> Pan Xinhui (9):
>   kernel/sched: introduce vcpu preempted check interface
>   locking/osq: Drop the overload of osq_lock()
>   kernel/locking: Drop the overload of {mutex,rwsem}_spin_on_owner
>   powerpc/spinlock: support vcpu preempted check
>   x86, paravirt: Add interface to support kvm/xen vcpu preempted check
>   KVM: Introduce kvm_write_guest_offset_cached
>   x86, kvm/x86.c: support vcpu preempted check
>   x86, kernel/kvm.c: support vcpu preempted check
>   Documentation: virtual: kvm: Support vcpu preempted check
> 
>  Documentation/virtual/kvm/msr.txt |  9 -
>  arch/powerpc/include/asm/spinlock.h   |  8 
>  arch/s390/include/asm/spinlock.h  |  8 
>  arch/s390/kernel/smp.c|  9 +++--
>  arch/s390/lib/spinlock.c  | 25 -
>  arch/x86/include/asm/paravirt_types.h |  2 ++
>  arch/x86/include/asm/spinlock.h   |  8 
>  arch/x86/include/uapi/asm/kvm_para.h  |  4 +++-
>  

[Xen-devel] [xtf test] 101754: all pass - PUSHED

[osstest service owner]

flight 101754 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101754/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  83d31c3933d0c7155b10c72889addf5e376e5b23
baseline version:
 xtf  bba9529a79eefead64a4db97658f27a275d415ca

Last test of basis   101733  2016-10-28 00:42:20 Z0 days
Testing same since   101754  2016-10-28 12:31:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

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

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


Pushing revision :

+ branch=xtf
+ revision=83d31c3933d0c7155b10c72889addf5e376e5b23
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf 
83d31c3933d0c7155b10c72889addf5e376e5b23
+ branch=xtf
+ revision=83d31c3933d0c7155b10c72889addf5e376e5b23
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x83d31c3933d0c7155b10c72889addf5e376e5b23 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' 

[Xen-devel] [seabios baseline-only test] 67953: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67953 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67953/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 67944
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67944
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67944
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 67944

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 seabios  d7adf6044a4c772b497e97272adf97426b34a249
baseline version:
 seabios  99e3316d5970dbcdac8ce7bb0f89f0986d01c0ce

Last test of basis67944  2016-10-27 11:16:28 Z1 days
Testing same since67953  2016-10-28 05:18:42 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-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-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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.


commit d7adf6044a4c772b497e97272adf97426b34a249
Author: Kevin O'Connor 
Date:   Wed Oct 26 11:17:34 2016 -0400

docs: Note v1.10.0 release

Signed-off-by: Kevin O'Connor 

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

[Xen-devel] [ovmf test] 101749: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 6c12fe63f989b1a3aff9f44c22b2833fa78cfcab
baseline version:
 ovmf d1b757e2cd034e32676c5cc2d542f785e74f8c5d

Last test of basis   101729  2016-10-27 21:49:45 Z0 days
Testing same since   101749  2016-10-28 10:03:05 Z0 days1 attempts


People who touched revisions under test:
  Dong, Guo 
  Fu Siyuan 
  Guo Dong 
  Michael Kinney 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=6c12fe63f989b1a3aff9f44c22b2833fa78cfcab
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
6c12fe63f989b1a3aff9f44c22b2833fa78cfcab
+ branch=ovmf
+ revision=6c12fe63f989b1a3aff9f44c22b2833fa78cfcab
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x6c12fe63f989b1a3aff9f44c22b2833fa78cfcab = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101401
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 101401
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 
101401
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail in 101687 
REGR. vs. 101401

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
101687 pass in 101737
 test-armhf-armhf-xl-credit2  11 guest-startfail pass in 101687
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail pass in 101687
 test-armhf-armhf-xl-cubietruck 11 guest-start  fail pass in 101715
 test-armhf-armhf-xl-xsm  11 guest-startfail pass in 101715
 test-armhf-armhf-xl-rtds 11 guest-startfail pass in 101715

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail blocked in 
101401
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 101687 like 
101401
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 101715 
like 101401
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 101715 like 101401
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101715 like 
101401
 test-armhf-armhf-xl  15 guest-start/debian.repeatfail  like 101401
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101401
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101401
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101401
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101401
 test-armhf-armhf-xl-vhd   9 debian-di-installfail  like 101401

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2 12 migrate-support-check fail in 101687 never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 101687 never 
pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail in 101687 never 
pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail in 101715 never 
pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail in 101715 
never pass
 test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 101715 never pass
 test-armhf-armhf-xl-xsm 13 saverestore-support-check fail in 101715 never pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 101715 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 101715 never pass
 build-i386-rumprun7 xen-buildfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt-xsm  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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-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

version targeted for testing:
 linux9ca365c0c8bdd8552ec064f0e696600cf7ea66dd
baseline version:
 linux91473db3a3257eacead8f4d84cf4bc96c447193f

Last test of basis   101401  2016-10-12 15:06:53 Z   16 days
Testing same since   101649  2016-10-24 18:21:35 Z4 

Re: [Xen-devel] [RFC] Shared coprocessor framework

[Andrew Cooper]

On 28/10/16 18:53, Andrii Anisov wrote:
> Dear All,
>
> At this moment we are designing a shared coprocessor framework to be
> introduced into XEN hypervisor.
> Please review an initial draft of the requirements and design overview.

Thankyou for the design doc.  An immediate +1 from me, simply for the
doc existing :)

>
> ===
>
> Shared coprocessor framework
> 
>
> The main idea of the coprocessor sharing is to let different domains use
> coprocessor concurrently and independently within some time share.

Forgive my ignorance (I am an x86 person, and given the CC list, I guess
this is talking about ARM systems), but what are coprocessors and what
might I do with one?

I think you might want a brief introduction sentence or two describing
what kind of systems this is applicable to, and an example of the kind
of thing which might want to be shared.

>
> It is targeted capability of different domains to run concurrently different
> firmware on the coproc.

I cant parse this sentence.  I presume you mean that the purpose of this
framework is to provide a mechanism for Xen to share a coprocessors
resource between multiple domains?

> This target implies that there is a way to switch
> coproc execution context externally from the main CPU which is running a
> hypervisor.
>
> Сomplexity and predictability of a coprocessor externally issued context
> switching process defines the accuracy of the coproc scheduling and resources
> allocation for domains as well as scheduling overhead.
>
> Shared coprocessor framework requirements
> =
>
> Functional
> --
> The framework shall:
> * provide a coprocessor resources sharing between different domains

Grammar nit.  Either "Provide coprocessor resource sharing between..."
or "Provide sharing of coprocessor resources between..."

> * support a number of coprocessor instances shared between domains in runtime
> * support configurable on system startup shareable coprocessors configuration
>   (number of instances, type of instances, scheduling algorithm per
>   coprocessor instance, etc)

Does it need to only be configurable at system startup?  There is often
more flexibility by having a default configuration at system start (so
dom0 can use the resources), which can later be altered by toolstack policy.

Considering the latter option, even if you don't implement support at
first, tends to lead to a cleaner design, but of course it does depend
heavily on the details of the situation.

> * support configurable on domain startup list of coprocessors shared to this
>   particular domain
> * support runtime configuration of scheduling algorithm per instance of shared
>   coprocessor
>
> Non-functional
> --
> * The framework will provide an interface to integrate different coprocessor
>   support implementation
> * The framework will provide an interface to integrate different scheduling
>   algorithms implementation.
> * (Optional) The coprocessor firmware and drivers should not be changed in
>   order to support the sharing.
>
> Operation environment
> -
> * XEN 4.8+
>
> Assumptions and dependencies
> 
> * MMU-enabled SoC with MMU-protected coprocessor(s)

Right - definitely ARM then, but it took me until half way through the
document to work this out.

>
> Design overview
> ===
>
> The Shared coprocessor framework will be implemented as a part of the XEN
> hypervisor. The framework design and development will be based on master
> branch not earlier than 4.8.0-rc2 targeting upstreaming before XEN 4.9 
> release.
>
> Following are described design overview addressing requirements:
>
> Coprocessors resources sharing mechanism
> 
>
> The coprocessor resources sharing will be done in a way of switching context
> (per domain instance of firmware running) on the coprocessor issued by the
> main processor. It is done by a hypervisor running on the main cpu and aware
> about domains, their capabilities and needs.
>
> The hypervisor is aware about coprocessors to be shared. For each shared
> coprocessor there are: an assigned timer, scheduler and per-domain vcoproc
> instances list.
>
> It will be implemented a vcoproc scheduling mechanism independent of XEN VCPU
> scheduling mechanism. It is caused by the difference in vcoproc and vcpu
> nature:
> * it is not considered pool of equal vcoproc running on a pool of equal
>   coprocessors (SMP like behavior)
> * due to fact that scheduler is not running on the coprocessor itself:
> * a vcoproc scheduler does not preempt the coprocessor context
> * coprocessor could deny context switching at the moment scheduler decide
> so, scheduling mechanism should adopt that
> * there could be number of different coprocessors instances with scheduler and
>   vcoproc queue associated
>
> 

[Xen-devel] [linux-3.10 test] 101731: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 100648
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 100648

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 101576
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 101594
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101663
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101680
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot  fail pass in 101680

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 101594 like 100646
 build-i386-rumprun5 rumprun-build fail in 101663 baseline untested
 build-amd64-rumprun   5 rumprun-build fail in 101663 baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100648
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100648

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101680 never pass
 build-i386-rumprun7 xen-buildfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux7828a9658951301a3fd83daa4ed0a607d370399e
baseline version:
 linux2ecaf1d025af0f481d00b3701ffbcc600dcab076

Last test of basis   100648  2016-08-28 23:14:14 Z   60 days
Testing same since   101576  2016-10-21 10:51:14 Z7 days   11 attempts


People who touched revisions under test:
  Andrea Arcangeli 
  Andrew Morton 
  Bjorn Helgaas 
  Casey Schaufler 
  Dan Carpenter 
  Dave Carroll 
  Greg Kroah-Hartman 
  Herbert Xu 
  Hugh Dickins 
  Ian Abbott 
  James Hogan 
  Jann Horn 
  Jason S. McMullan 
  Jiri Slaby 
  Kashyap Desai 
  Kees Cook 
  Linus Torvalds 
  Martin K. Petersen 
  Paolo Bonzini 
  Philipp Hahn 
  Rafael J. Wysocki 
  Simon Horman 
  Wei Liu 
  Willy Tarreau 
  Yinghai Lu 

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

[Xen-devel] [RFC] Shared coprocessor framework

[Andrii Anisov]

Dear All,

At this moment we are designing a shared coprocessor framework to be
introduced into XEN hypervisor.
Please review an initial draft of the requirements and design overview.

===

Shared coprocessor framework


The main idea of the coprocessor sharing is to let different domains use
coprocessor concurrently and independently within some time share.

It is targeted capability of different domains to run concurrently different
firmware on the coproc. This target implies that there is a way to switch
coproc execution context externally from the main CPU which is running a
hypervisor.

Сomplexity and predictability of a coprocessor externally issued context
switching process defines the accuracy of the coproc scheduling and resources
allocation for domains as well as scheduling overhead.

Shared coprocessor framework requirements
=

Functional
--
The framework shall:
* provide a coprocessor resources sharing between different domains
* support a number of coprocessor instances shared between domains in runtime
* support configurable on system startup shareable coprocessors configuration
  (number of instances, type of instances, scheduling algorithm per
  coprocessor instance, etc)
* support configurable on domain startup list of coprocessors shared to this
  particular domain
* support runtime configuration of scheduling algorithm per instance of shared
  coprocessor

Non-functional
--
* The framework will provide an interface to integrate different coprocessor
  support implementation
* The framework will provide an interface to integrate different scheduling
  algorithms implementation.
* (Optional) The coprocessor firmware and drivers should not be changed in
  order to support the sharing.

Operation environment
-
* XEN 4.8+

Assumptions and dependencies

* MMU-enabled SoC with MMU-protected coprocessor(s)

Design overview
===

The Shared coprocessor framework will be implemented as a part of the XEN
hypervisor. The framework design and development will be based on master
branch not earlier than 4.8.0-rc2 targeting upstreaming before XEN 4.9 release.

Following are described design overview addressing requirements:

Coprocessors resources sharing mechanism


The coprocessor resources sharing will be done in a way of switching context
(per domain instance of firmware running) on the coprocessor issued by the
main processor. It is done by a hypervisor running on the main cpu and aware
about domains, their capabilities and needs.

The hypervisor is aware about coprocessors to be shared. For each shared
coprocessor there are: an assigned timer, scheduler and per-domain vcoproc
instances list.

It will be implemented a vcoproc scheduling mechanism independent of XEN VCPU
scheduling mechanism. It is caused by the difference in vcoproc and vcpu
nature:
* it is not considered pool of equal vcoproc running on a pool of equal
  coprocessors (SMP like behavior)
* due to fact that scheduler is not running on the coprocessor itself:
* a vcoproc scheduler does not preempt the coprocessor context
* coprocessor could deny context switching at the moment scheduler decide
so, scheduling mechanism should adopt that
* there could be number of different coprocessors instances with scheduler and
  vcoproc queue associated

Due to the fact that some domain assigned a vcoproc could access coproc when
it is running another domain context, framework will implement iomem access
emulation for domains which are not provided coproc at the moment of access.

Interrupts from coprocessor will be effectively delivered to the domain which
vcoproc context is being running at the moment of the interrupt.

While the context switching is coprocessor and SoC specific procedure, the
framework would not encapsulate such procedure, but provides interface to
register platform implementation of context switching procedure.

It is assumed that the coprocessor has an iommu associated or corresponding
system level iommu (i.e. arm smmu) owned by hypervisor. The iommu setup is
also platform specific code and part of context switching.

In case of only having coprocessor associated iommu, platform code is also
responsible to handle that iommu setup (i.e. in a way of iomem access
emulation).

Support a number of coprocessor instances shared between domains in runtime
---

The coprocessor framework will have a list of coprocessors available for
sharing during system runtime. Any running domain could be using none, one or
several shared coprocessors.

System startup configuration


The compilation time configuration will provide separate config for the shared
coprocessor framework 

Re: [Xen-devel] [PATCH v2] xenfv: set has_acpi_build to false

[Stefano Stabellini]

On Fri, 28 Oct 2016, Wei Liu wrote:
> On Thu, Oct 27, 2016 at 11:58:29AM -0700, Stefano Stabellini wrote:
> > On Thu, 27 Oct 2016, Sander Eikelenboom wrote:
> > > Thursday, October 27, 2016, 3:51:09 PM, you wrote:
> > > 
> > > > Xen's toolstack is in charge of building ACPI tables. Skip ACPI table
> > > > building and loading in QEMU by setting has_acpi_build to false for
> > > > xenfv machine.
> > > 
> > > > This issue is discovered due to direct kernel boot on Xen doesn't boot
> > > > anymore, because the new ACPI tables cause the guest to exceed its
> > > > memory allocation limit.
> > > 
> > > > Reported-by: Sander Eikelenboom 
> > > > Signed-off-by: Wei Liu 
> > > 
> > > Just given this patch a spin and you may add a:
> > > Tested-by: Sander Eikelenboom 
> > 
> > The problem with this patch is that it only covers the xenfv machine
> > case, which is default, but QEMU can also be invoked with -M
> > pc,accel=xen. That case wouldn't be fixed by this patch. Wei, you can
> > test it by adding "xen_platform_pci=0" to the VM config file.
> > That's why we probably need a new option, similar to has_acpi_build, but
> > that can be changed at accelerator init time.
> > 
> 
> Do you mean we should add a new field to AccelClass?

I mean that this patch is insufficient unfortunately. I am not sure
about what is the best way to solve this problem, but Eduardo suggested
to add a new PCMachineState field:
http://marc.info/?l=qemu-devel=147749203112422=2

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

[Xen-devel] [libvirt test] 101738: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101677
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101677
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101677
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101677

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass

version targeted for testing:
 libvirt  65462b2944d761eb185cb6d10db9ccf026bea36b
baseline version:
 libvirt  13022ce430da9d6ce4dc9e9117d6be519e7afc4a

Last test of basis   101677  2016-10-26 04:21:37 Z2 days
Failing since101711  2016-10-27 04:22:25 Z1 days2 attempts
Testing same since   101738  2016-10-28 04:24:49 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Chen Hanxiao 
  Gema Gomez 
  John Ferlan 
  Ján Tomko 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Sławek Kapłoński 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=65462b2944d761eb185cb6d10db9ccf026bea36b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;

Re: [Xen-devel] Error migrating VM to secondary host using COLO replication

[Konrad Rzeszutek Wilk]

On Thu, Oct 27, 2016 at 08:56:34PM -0200, Sadi wrote:
> Hello,
Hey!

CC-ing relevant people.
> 
> I've been trying to set COLO replication to work but i'm stuck on a problem
> when migrating de primary VM to secondary host.
> 
> I have been following the instructions from this wiki
> 
> - http://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
> 
> and this mail thread
> 
>  -
> http://xen.markmail.org/search/?q=COLO#query:COLO+page:1+mid:fb7wrn62vbks4unn+state:results
> 
> I'm anexing the steps i took setting the environment before facing this
> problem when executing 'xl remus' command:
> 
> >migration target: Ready to receive domain.
> >Saving to migration stream new xl format (info 0x3/0x0/2840)
> >Loading new save file  (new xl fmt info
> 0x3/0x0/2840)
> >Savefile contains xl domain config in JSON format
> >Parsing config from 
> >xc: info: Saving domain 2, type x86 HVM
> >xc: info: Found x86 HVM domain from Xen 4.7
> >xc: info: Restoring domain
> >xc: Frames iteration 0 of 5: 1045504/1045504  100%
> >xc: Domain now suspended: 0/00%
> >libxl: error: libxl_qmp.c:702:libxl__qmp_initialize: Connection error: No
> such file or directory
> >libxl: error: libxl_colo_restore.c:817:colo_restore_setup_cds_done: COLO:
> failed to setup device >for guest with domid 1
> >xc: error: Restore failed (38 = Function not implemented): Internal error
> >libxl: info: libxl_colo_restore.c:320:libxl__colo_restore_teardown: colo
> fails
> >libxl: error: libxl_stream_read.c:852:libxl__xc_domain_restore_done:
> restoring domain: Function >not implemented
> >libxl: info: libxl_colo_restore.c:320:libxl__colo_restore_teardown: colo
> fails
> 
> I'm hoping that someone could provide with directions.
> 
> Thanks for your time and sory for bad english (not native language).
> 
> 
> Sadi.

> Network
> 
> master:
> br0 : 10.20.107.30 binded with eth0
> eth1: 192.168.1.30
> eth2: 192.168.2.30
> 
> slave:
> br0 eth0: 10.20.107.33 binded with eth0
> br1: no ip address binded with eth1
> eth1: 192.168.1.33
> eth2: 192.168.2.33
> 
> Eth1 both sides directly connected by cable
> Eth2 both sides directly connected by cable
> 
> Repositories used:
> 
> https://github.com/Pating/colo-proxy/tree/changlox
> https://github.com/macrosheep/iptables.git 
> https://github.com/torvalds/linux 
> 
> https://github.com/wencongyang/xen 
> 
> Kernel build instructions followed:
> 
> 2. Prepare host kernel for Dom0
> colo-proxy kernel module need cooperate with linux kernel. You should patch 
> kernel with ~/colo-proxy/colo-patch-for-kernel.patch 
> -cd ~/colo-proxy/; git checkout 405527cbfa9f
> -cd ~/linux/; git checkout v4.0; git am 
> ~/colo-proxy/colo-patch-for-kernel.patch 
> -cp /boot/config-3.0.76-0.11-xen .config; make menuconfig to config your 
> kernel support Dom0. Ref: 
> http://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs 
> -make -j8; make modules_install; make install 
> -reboot
> 
> 
> COLO-Proxy:
> 
> -cd ~/colo-proxy/; git checkout 405527cbfa9f; make; make install
> 
> IPTables:
> 
> -cd iptables; ./autogen.sh; ./configure --prefix=/usr/ --libdir=/usr/lib64; 
> make; make install
> 
> XEN:
> 
> -./autogen.sh
> -./configure --enable-debug 
> -touch tools/libxl/libxlu_disk_l.l 
> -touch tools/libxl/libxlu_cfg_l.l 
> -make dist-xen 
> -make dist-tools 
> -make install-xen 
> -make install-tools 
> 
> *i've tried with https://github.com/wencongyang/qemu-xen but got an error 
> with qemu when xl creating the VM as follows:
> 
> >libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error 
> >message from QMP server: Could not set password
> 
> Qemu
> 
> -cd ~/qemu-xen/; git checkout colo-xen-v2
> 
> Configured QEMU with script provided at:
> http://xen.markmail.org/message/y4jcdqxw2s2labdo?q=COLO#query:COLO+page:1+mid:3lzcuzeokqsqpu4i+state:results
> 
> *path_to_xen_source updated according my directory tree.
> then..
> 
> -make
> -make install
> 
> Running COLO
> 
> *HVM SUSE 64bits
> 
> primary:
> rm -f /var/log/xen/* 
> rm -f /var/lib/xen/userdata-d.* 
> service xencommons start 
> modprobe nf_conntrack_ipv4 
> modprobe xt_PMYCOLO sec_dev=eth1
> 
> secondary:
> rm -f /var/log/xen/*
> rm -f /var/lib/xen/userdata-d.*
> service xencommons start
> modprobe xt_SECCOLO
> active_disk=/mnt/ramfs/active_disk.img
> hidden_disk=/mnt/ramfs/hidden_disk.img
> local_img=/root/new/SUSE/xenguest.img
> tmp_disk_size=`/root/new/pating/qemu-xen/qemu-img info $local_img |grep 
> 'virtual size' |awk  '{print $3}'`
> rm -rf /mnt/ramfs/*
> umount /mnt/ramfs/
> rm -rf /mnt/ramfs/
> mkdir /mnt/ramfs
> 
> function create_image()
> {
>  /root/new/pating/qemu-xen/qemu-img create -f qcow2 $1 $tmp_disk_size
> }
> function prepare_temp_images()
> {
>  grep -q "^none /mnt/ramfs ramfs" /proc/mounts
>  if [[ $? -ne 0 ]]; then
>  mount -t ramfs none /mnt/ramfs/ -o size=2G
>  fi
> 
>  if [[ ! -e $active_disk ]]; then
>  create_image $active_disk
>  fi
> 
>  if [[ ! -e $hidden_disk ]]; then
>

Re: [Xen-devel] [PATCH v4 0/3] libfs, xenfs: replace /proc/xen/xenbus with a symlink

[Al Viro]

On Fri, Oct 28, 2016 at 04:52:36PM +0100, David Vrabel wrote:
> Using /proc/xen/xenbus can cause deadlocks on the atomic file position
> mutex since this file should behave like a character device and not a
> regular file.  This is easiest to achive by making it a symlink to the
> existing /dev/xen/xenbus device.

What.  The.  Hell?  What's wrong with simply adding
file->f_mode &= ~FMODE_ATOMIC_POS;  /* cdev-style semantics */

in the ->open() of those files, rather than going through all those
convolutions?

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

[Xen-devel] [PATCH v2] VMX: fix realmode emulation SReg handling

[Jan Beulich]

Commit 0888d36bb2 ("x86/emul: Correct the decoding of SReg3 operands")
overlooked three places where x86_seg_cs was assumed to be zero.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 
---
v2: Add BUILD_BUG_ON() and use ARRAY_SIZE(reg) as loop bound.

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1496,21 +1496,23 @@ static void vmx_update_guest_cr(struct v
 enum x86_segment s; 
 struct segment_register reg[x86_seg_tr + 1];
 
+BUILD_BUG_ON(x86_seg_tr != x86_seg_gs + 1);
+
 /* Entering or leaving real mode: adjust the segment registers.
  * Need to read them all either way, as realmode reads can update
  * the saved values we'll use when returning to prot mode. */
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
+for ( s = 0; s < ARRAY_SIZE(reg); s++ )
 vmx_get_segment_register(v, s, [s]);
 v->arch.hvm_vmx.vmx_realmode = realmode;
 
 if ( realmode )
 {
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
+for ( s = 0; s < ARRAY_SIZE(reg); s++ )
 vmx_set_segment_register(v, s, [s]);
 }
 else 
 {
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ ) 
+for ( s = 0; s < ARRAY_SIZE(reg); s++ )
 if ( !(v->arch.hvm_vmx.vm86_segment_mask & (1<arch.hvm_vmx.vm86_saved_seg[s]);


VMX: fix realmode emulation SReg handling

Commit 0888d36bb2 ("x86/emul: Correct the decoding of SReg3 operands")
overlooked three places where x86_seg_cs was assumed to be zero.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 
---
v2: Add BUILD_BUG_ON() and use ARRAY_SIZE(reg) as loop bound.

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1496,21 +1496,23 @@ static void vmx_update_guest_cr(struct v
 enum x86_segment s; 
 struct segment_register reg[x86_seg_tr + 1];
 
+BUILD_BUG_ON(x86_seg_tr != x86_seg_gs + 1);
+
 /* Entering or leaving real mode: adjust the segment registers.
  * Need to read them all either way, as realmode reads can update
  * the saved values we'll use when returning to prot mode. */
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
+for ( s = 0; s < ARRAY_SIZE(reg); s++ )
 vmx_get_segment_register(v, s, [s]);
 v->arch.hvm_vmx.vmx_realmode = realmode;
 
 if ( realmode )
 {
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
+for ( s = 0; s < ARRAY_SIZE(reg); s++ )
 vmx_set_segment_register(v, s, [s]);
 }
 else 
 {
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ ) 
+for ( s = 0; s < ARRAY_SIZE(reg); s++ )
 if ( !(v->arch.hvm_vmx.vm86_segment_mask & (1<arch.hvm_vmx.vm86_saved_seg[s]);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101703

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101676
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101703
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101703
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101703
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101703
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101703
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101703

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

version targeted for testing:
 qemuu835f3d24b42fcbeca5c49048994a4e5d0fe905c5
baseline version:
 qemuuede0cbeb7892bdf4a19128853a3a3c61a17fb068

Last test of basis   101703  2016-10-27 00:46:02 Z1 days
Testing same since   101727  2016-10-27 21:32:21 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Brad Smith 
  Emilio G. Cota 
  Gerd Hoffmann 
  Jason Wang 
  John Paul Adrian Glaubitz 
  Kevin Wolf 
  Laurent Vivier 
  Li Qiang 
  Peter Maydell 
  Prasad J Pandit 
  Richard Henderson 
  Richard Henderson 
  Zhang Chen 

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

Re: [Xen-devel] [PATCH] VMX: fix realmode emulation SReg handling

[Jan Beulich]

>>> On 28.10.16 at 17:29,  wrote:
> On 28/10/16 16:24, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1499,18 +1499,18 @@ static void vmx_update_guest_cr(struct v
>>  /* Entering or leaving real mode: adjust the segment registers.
>>   * Need to read them all either way, as realmode reads can 
>> update
>>   * the saved values we'll use when returning to prot mode. */
>> -for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
>> +for ( s = 0; s <= x86_seg_tr ; s++ )
> 
> As you are changing these lines, mind dropping the space between tr and ; ?

How did I not notice them?

> Alternatively, swapping x86_seg_tr for ARRAY_SIZE(reg) so the indices
> never get out of sync?
> 
> Finally, perhaps an extra BUILD_BUG_ON(x86_seg_tr != x86_seg_gs + 1), to
> cover the expectation of this bit of code?

Done both. v2 coming after another smoke test.

Jan


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

Re: [Xen-devel] Test Xen 4.8 RC4 not stable 27.10.16

[Wei Liu]

On Fri, Oct 28, 2016 at 12:04:29PM -0400, Boris Ostrovsky wrote:
> On 10/28/2016 11:30 AM, Wei Liu wrote:
> > On Fri, Oct 28, 2016 at 04:01:54PM +0100, Juergen Schinker wrote:
> >>
> >> - On 28 Oct, 2016, at 13:07, Boris Ostrovsky 
> >> boris.ostrov...@oracle.com wrote:
> >>
> >>> I believe at least on some distros /var/run should be soft-linked to
> >>> /run, otherwise whoever cleans up those directories (the command name
> >>> escapes me right now) will only remove files from /run and leave
> >>> /var/run (and therefore /var/run/xen/xenstored.pid) untouched.
> >>>
> >>> And because xencommons checks for existence of this this file before
> >>> starting xenstored the latter never starts.
> >>>
> >>> -boris
> >> root@xen:~# ls -la /var/run/xen/xenstored.pid 
> >> -rw-r- 1 root root 6 Oct 28 15:15 /var/run/xen/xenstored.pid
> >>
> >>   
> >>33 ?00:00:00 xenwatch
> >>34 ?00:00:00 xenbus
> >>45 ?00:00:00 xenbus_frontend
> >>   785 ?00:00:00 xen_pciback_wor
> >>  1137 ?00:00:00 xenwatchdogd
> >>  1169 ?00:00:00 xen-init-dom0
> >>  1175 ?00:00:00 xenconsoled

And this ^ 

xenconsoled requires xenstored.service, so if xenstored is not available
xenconsoled wouldn't be started, I think.

xen-init-dom0 as well.

> >>
> >> Thats exactly what I'm sayin , maybe we need a more intelligent check to 
> >> see if xenstored is running
> >>
> >> not just a simple pid check
> >>
> > But ... the pid check is the usual way of checking if a daemon is
> > active.
> >
> > I think a bit work is required to work out why xenstored.pid stays
> > across reboot -- it is not supposed to work like that on a FHS compliant
> > system.
> 
> I remember now: it's systemd-tmpfiles that creates and cleans up those
> files. I think the way it works is it checks
> /usr/lib/tmpfiles.d/var.conf for the rules. On my fedora24:
> 
> L /var/run - - - - ../run
> 
> Which IIUIC means that /var/run should be linked to ../run (i.e. /run)
> during boot. Or something along these lines. Perhaps because when we
> shut down xenstored.pid is still there and so the link cannot be made.

It's the same on my Debian Jessie box, but it works just fine, FWIW.

Wei.

> 
> 
> -boris
> 
> >
> > And how do other daemons work on your test host, presumably they will
> > see stale pid files as well.  Are there any other pid files under
> > /var/run? If so, do the corresponding daemon run properly?
> >
> > Wei.
> >
> >> J
> 
> 

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

Re: [Xen-devel] Test Xen 4.8 RC4 not stable 27.10.16

[Boris Ostrovsky]

On 10/28/2016 11:30 AM, Wei Liu wrote:
> On Fri, Oct 28, 2016 at 04:01:54PM +0100, Juergen Schinker wrote:
>>
>> - On 28 Oct, 2016, at 13:07, Boris Ostrovsky boris.ostrov...@oracle.com 
>> wrote:
>>
>>> I believe at least on some distros /var/run should be soft-linked to
>>> /run, otherwise whoever cleans up those directories (the command name
>>> escapes me right now) will only remove files from /run and leave
>>> /var/run (and therefore /var/run/xen/xenstored.pid) untouched.
>>>
>>> And because xencommons checks for existence of this this file before
>>> starting xenstored the latter never starts.
>>>
>>> -boris
>> root@xen:~# ls -la /var/run/xen/xenstored.pid 
>> -rw-r- 1 root root 6 Oct 28 15:15 /var/run/xen/xenstored.pid
>>
>>   
>>33 ?00:00:00 xenwatch
>>34 ?00:00:00 xenbus
>>45 ?00:00:00 xenbus_frontend
>>   785 ?00:00:00 xen_pciback_wor
>>  1137 ?00:00:00 xenwatchdogd
>>  1169 ?00:00:00 xen-init-dom0
>>  1175 ?00:00:00 xenconsoled
>>
>> Thats exactly what I'm sayin , maybe we need a more intelligent check to see 
>> if xenstored is running
>>
>> not just a simple pid check
>>
> But ... the pid check is the usual way of checking if a daemon is
> active.
>
> I think a bit work is required to work out why xenstored.pid stays
> across reboot -- it is not supposed to work like that on a FHS compliant
> system.

I remember now: it's systemd-tmpfiles that creates and cleans up those
files. I think the way it works is it checks
/usr/lib/tmpfiles.d/var.conf for the rules. On my fedora24:

L /var/run - - - - ../run

Which IIUIC means that /var/run should be linked to ../run (i.e. /run)
during boot. Or something along these lines. Perhaps because when we
shut down xenstored.pid is still there and so the link cannot be made.


-boris

>
> And how do other daemons work on your test host, presumably they will
> see stale pid files as well.  Are there any other pid files under
> /var/run? If so, do the corresponding daemon run properly?
>
> Wei.
>
>> J


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

[Xen-devel] [PATCH v3 00/15] Initial PVHv2 Dom0 support

[Roger Pau Monne]

Hello,

This is the first batch of the PVH Dom0 support series, that includes 
everything up to the point where ACPI tables for the Dom0 are crafted. I've 
decided to left the last part of the series (the one that contains the PCI 
config space handlers, and other emulation/trapping related code) separated, 
in order to focus and ease the review. This is of course not functional, one 
might be able to partially boot a Dom0 kernel if it doesn't try to access 
any physical device.

Another reason for splitting this series is so that I can write a proper 
design document about how this trapping is going to work, and what is it 
supposed to do, because during the last review round I got the feeling that 
some comments where not really related to the code itself, but to what I was 
trying to achieve, so it's best to discuss them in a design document rather 
than mixed up with code.

Thanks, Roger.

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

[Xen-devel] [PATCHv4 3/3] xenfs: Use proc_create_mount_point() to create /proc/xen

[David Vrabel]

From: Seth Forshee 

Mounting proc in user namespace containers fails if the xenbus
filesystem is mounted on /proc/xen because this directory fails
the "permanently empty" test. proc_create_mount_point() exists
specifically to create such mountpoints in proc but is currently
proc-internal. Export this interface to modules, then use it in
xenbus when creating /proc/xen.

Signed-off-by: Seth Forshee 
Signed-off-by: David Vrabel 
---
 drivers/xen/xenbus/xenbus_probe.c | 2 +-
 fs/proc/generic.c | 1 +
 fs/proc/internal.h| 1 -
 include/linux/proc_fs.h   | 2 ++
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index 33a31cf..b5c1dec 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -826,7 +826,7 @@ static int __init xenbus_init(void)
 * Create xenfs mountpoint in /proc for compatibility with
 * utilities that expect to find "xenbus" under "/proc/xen".
 */
-   proc_mkdir("xen", NULL);
+   proc_create_mount_point("xen");
 #endif
 
 out_error:
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 5f2dc20..7eb3cef 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -479,6 +479,7 @@ struct proc_dir_entry *proc_create_mount_point(const char 
*name)
}
return ent;
 }
+EXPORT_SYMBOL(proc_create_mount_point);
 
 struct proc_dir_entry *proc_create_data(const char *name, umode_t mode,
struct proc_dir_entry *parent,
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 5378441..7de6795 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -195,7 +195,6 @@ static inline bool is_empty_pde(const struct proc_dir_entry 
*pde)
 {
return S_ISDIR(pde->mode) && !pde->proc_iops;
 }
-struct proc_dir_entry *proc_create_mount_point(const char *name);
 
 /*
  * inode.c
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index b97bf2e..8bd2f72 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -21,6 +21,7 @@ extern struct proc_dir_entry *proc_mkdir_data(const char *, 
umode_t,
  struct proc_dir_entry *, void *);
 extern struct proc_dir_entry *proc_mkdir_mode(const char *, umode_t,
  struct proc_dir_entry *);
+struct proc_dir_entry *proc_create_mount_point(const char *name);
  
 extern struct proc_dir_entry *proc_create_data(const char *, umode_t,
   struct proc_dir_entry *,
@@ -56,6 +57,7 @@ static inline struct proc_dir_entry *proc_symlink(const char 
*name,
struct proc_dir_entry *parent,const char *dest) { return NULL;}
 static inline struct proc_dir_entry *proc_mkdir(const char *name,
struct proc_dir_entry *parent) {return NULL;}
+static inline struct proc_dir_entry *proc_create_mount_point(const char *name) 
{ return NULL; }
 static inline struct proc_dir_entry *proc_mkdir_data(const char *name,
umode_t mode, struct proc_dir_entry *parent, void *data) { return NULL; 
}
 static inline struct proc_dir_entry *proc_mkdir_mode(const char *name,
-- 
2.1.4


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

[Xen-devel] [PATCHv4 1/3] libfs: allow simple_fill_super() to add symlinks

[David Vrabel]

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
The target is provided in the new "link" field.

Signed-off-by: David Vrabel 
---
v4:
- Use switch for file type.

v2:
- simplified.
---
 fs/libfs.c | 27 ---
 include/linux/fs.h |  2 +-
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/fs/libfs.c b/fs/libfs.c
index 48826d4..8eabcb1 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -509,6 +509,7 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
struct dentry *root;
struct dentry *dentry;
int i;
+   int ret = -ENOMEM;
 
s->s_blocksize = PAGE_SIZE;
s->s_blocksize_bits = PAGE_SHIFT;
@@ -550,9 +551,29 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
dput(dentry);
goto out;
}
-   inode->i_mode = S_IFREG | files->mode;
+   switch (files->mode & S_IFMT) {
+   case S_IFLNK:
+   inode->i_mode = files->mode;
+   inode->i_op = _symlink_inode_operations;
+   inode->i_link = kstrdup(files->link, GFP_KERNEL);
+   if (!inode->i_link) {
+   iput(inode);
+   dput(dentry);
+   goto out;
+   }
+   break;
+   case S_IFREG:
+   case 0:
+   inode->i_mode = S_IFREG | files->mode;
+   inode->i_fop = files->ops;
+   break;
+   default:
+   iput(inode);
+   dput(dentry);
+   ret = -EINVAL;
+   goto out;
+   }
inode->i_atime = inode->i_mtime = inode->i_ctime = 
current_time(inode);
-   inode->i_fop = files->ops;
inode->i_ino = i;
d_add(dentry, inode);
}
@@ -562,7 +583,7 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
d_genocide(root);
shrink_dcache_parent(root);
dput(root);
-   return -ENOMEM;
+   return ret;
 }
 EXPORT_SYMBOL(simple_fill_super);
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 16d2b6e..4b64fbb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2988,7 +2988,7 @@ extern const struct file_operations simple_dir_operations;
 extern const struct inode_operations simple_dir_inode_operations;
 extern void make_empty_dir_inode(struct inode *inode);
 extern bool is_empty_dir_inode(struct inode *inode);
-struct tree_descr { char *name; const struct file_operations *ops; int mode; };
+struct tree_descr { char *name; const struct file_operations *ops; int mode; 
char *link; };
 struct dentry *d_alloc_name(struct dentry *, const char *);
 extern int simple_fill_super(struct super_block *, unsigned long, struct 
tree_descr *);
 extern int simple_pin_fs(struct file_system_type *, struct vfsmount **mount, 
int *count);
-- 
2.1.4


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

[Xen-devel] [PATCH v4 0/3] libfs, xenfs: replace /proc/xen/xenbus with a symlink

[David Vrabel]

Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file.  This is easiest to achive by making it a symlink to the
existing /dev/xen/xenbus device.

This requires extending simple_fill_super() to add symlinks as well as
regular files.

David

Changes in v4:
- Switch on file type in simple_fill_super()
- Make xen_xenus_fops and xen_privcmd_fops static
- Rebased on v4.9-rc2.
- Add patch from Seth for namespace support.

Changes in v3:
- Rebased on v4.7-rc5.

Changes in v2:
- Simplified simple_fill_super() change.


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

[Xen-devel] [PATCHv4 2/3] xenfs: replace xenbus and privcmd with symlinks

[David Vrabel]

/proc/xen/xenbus does not work correctly.  A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates.  This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.

/proc/xen/xenbus is supposed to be identical to the character device
/dev/xen/xenbus so replace the file with a symlink.

Similarly, replace /proc/xen/privcmd with a symlink since it should be
the same as /dev/xen/privcmd.

Signed-off-by: David Vrabel 
---
v4:
- Make xen_xenbus_fops and xen_privcmd_fops static.
---
 drivers/xen/privcmd.c|  5 +
 drivers/xen/privcmd.h|  3 ---
 drivers/xen/xenbus/xenbus_comms.h|  2 --
 drivers/xen/xenbus/xenbus_dev_frontend.c |  3 +--
 drivers/xen/xenfs/super.c| 10 --
 5 files changed, 6 insertions(+), 17 deletions(-)
 delete mode 100644 drivers/xen/privcmd.h

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 702040f..12ece8d 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -37,8 +37,6 @@
 #include 
 #include 
 
-#include "privcmd.h"
-
 MODULE_LICENSE("GPL");
 
 #define PRIV_VMA_LOCKED ((void *)1)
@@ -644,12 +642,11 @@ static int privcmd_vma_range_is_mapped(
   is_mapped_fn, NULL) != 0;
 }
 
-const struct file_operations xen_privcmd_fops = {
+const static struct file_operations xen_privcmd_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = privcmd_ioctl,
.mmap = privcmd_mmap,
 };
-EXPORT_SYMBOL_GPL(xen_privcmd_fops);
 
 static struct miscdevice privcmd_dev = {
.minor = MISC_DYNAMIC_MINOR,
diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
deleted file mode 100644
index 14facae..000
--- a/drivers/xen/privcmd.h
+++ /dev/null
@@ -1,3 +0,0 @@
-#include 
-
-extern const struct file_operations xen_privcmd_fops;
diff --git a/drivers/xen/xenbus/xenbus_comms.h 
b/drivers/xen/xenbus/xenbus_comms.h
index e74f9c1..39efb85 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -47,6 +47,4 @@ extern struct xenstore_domain_interface *xen_store_interface;
 extern int xen_store_evtchn;
 extern enum xenstore_init xen_store_domain_type;
 
-extern const struct file_operations xen_xenbus_fops;
-
 #endif /* _XENBUS_COMMS_H */
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index c1010f01..a45e7f2 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -598,7 +598,7 @@ static unsigned int xenbus_file_poll(struct file *file, 
poll_table *wait)
return 0;
 }
 
-const struct file_operations xen_xenbus_fops = {
+const static struct file_operations xen_xenbus_fops = {
.read = xenbus_file_read,
.write = xenbus_file_write,
.open = xenbus_file_open,
@@ -606,7 +606,6 @@ const struct file_operations xen_xenbus_fops = {
.poll = xenbus_file_poll,
.llseek = no_llseek,
 };
-EXPORT_SYMBOL_GPL(xen_xenbus_fops);
 
 static struct miscdevice xenbus_dev = {
.minor = MISC_DYNAMIC_MINOR,
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 8559a71..0f2e2cd 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -18,8 +18,6 @@
 #include 
 
 #include "xenfs.h"
-#include "../privcmd.h"
-#include "../xenbus/xenbus_comms.h"
 
 #include 
 
@@ -45,16 +43,16 @@ static const struct file_operations capabilities_file_ops = 
{
 static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
static struct tree_descr xenfs_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{""},
};
 
static struct tree_descr xenfs_init_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
{ "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
 #ifdef CONFIG_XEN_SYMS
-- 
2.1.4


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

Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Ian Jackson]

Wei Liu writes ("Re: Stubdom GMP build failure for gcc 6"):
> On Fri, Oct 28, 2016 at 02:30:02PM +0100, Ian Jackson wrote:
> > Can we not just reproduce its link line somehow ?
> 
> I don't think that would result in a program that can run on Linux.

Well, yes, sorry, I took it as read that we would say we were
cross-compiling.

Ian.

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

Re: [Xen-devel] [PATCH for-4.8] tools/libacpi: fix sed usage

[Ian Jackson]

Roger Pau Monne writes ("[PATCH for-4.8] tools/libacpi: fix sed usage"):
> Current usage of sed in the libacpi Makefile make uses of non-POSIX options,
> that are not available on all the OSes supported by the Xen tools.
...
> - awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
> - # Strip license comment
> - sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
> + # Remove last bracket and strip license comment
> + awk 'NR > 1 {print s} {s=$$0}' $< | sed '1,/\*\//d' > $@.$(TMP_SUFFIX)

Sadly, unless countermeasures are taken, this pretends to succeed if
awk fails.  I don't think the obvious countermeasure (set -o pipefail)
is remotely portable.

I normally split this kind of thing up and just use .1.tmp .2.tmp etc.

Ina.

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

Re: [Xen-devel] [PATCH for-4.8] tools/libacpi: fix sed usage

[Boris Ostrovsky]

On 10/28/2016 10:33 AM, Roger Pau Monne wrote:
> Current usage of sed in the libacpi Makefile make uses of non-POSIX options,
> that are not available on all the OSes supported by the Xen tools.
>
> The '-i' option has slightly different semantics between GNU and BSD sed
> implementations, while on the GNU version the suffix is optional, on the BSD
> one it is not. Also BSD sed seems to have problems parsing the script
> itself, reporting "extra characters at the end of d command".
>
> Fix those issues by piping the output of awk into sed directly, and
> replacing the script with a simpler version that achieves the same purpose
> (removing the initial license header comment).
>
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Boris Ostrovsky 
> Cc: Jan Beulich 
> Cc: Ian Jackson 
> Cc: Wei Liu 

Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [PATCH for-4.8] flask: build policy in different locations

[Wei Liu]

On Fri, Oct 28, 2016 at 09:32:19AM -0600, Jan Beulich wrote:
> >>> On 28.10.16 at 17:17,  wrote:
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -285,6 +285,8 @@ xen/xsm/flask/include/av_permissions.h
> >  xen/xsm/flask/include/class_to_string.h
> >  xen/xsm/flask/include/flask.h
> >  xen/xsm/flask/include/initial_sid_to_string.h
> > +xen/xsm/flask/policy.*
> > +xen/xsm/flask/xenpolicy-*
> 
> The two entries getting added here aren't in line with ...
> 
> >  clean:
> > -   $(RM) tmp policy.conf $(POLICY_FILENAME)
> > +   $(RM) $(FLASK_BUILD_DIR)/tmp $(FLASK_BUILD_DIR)/policy.conf 
> > $(POLICY_FILENAME)
> 
> ... the altered tmp removal here. I can't, however, tell which side
> needs updating.
> 

tmp should be removed because there is no such thing.

Wei.

> Jan
> 

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

Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Wei Liu]

On Fri, Oct 28, 2016 at 04:44:10PM +0200, Juergen Gross wrote:
> On 28/10/16 14:10, Wei Liu wrote:
> > Hi all
> > 
> > There have been a few reports on stubdom build failure with gcc 6
> > toolchain. I spent some time yesterday to figure what went wrong. Here
> > is what I found.
> > 
> > When building GMP library, its configure script generates small C
> > programs to determine various aspects of the system. Unfortunately the
> > build rune for it is incorrect, so the test program ends up consuming
> > newlib headers while linking against the host glibc. It's amazing that
> > this even worked in the past few years! :-)
> > 
> > Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
> > -LXXX" doesn't work. It turns out that there is no crt generated in
> > newlib. I'm not sure if that's because the newlib port is incomplete or
> > I haven't discovered a way to teach it to generate one.
> > 
> > So what should we do with this? I'm not sure if I can come up with a
> > non-intrusive patch quickly.  GMP is only used by tpm emulator, so for
> > the imminent 4.8 release I can write a patch to disable building that.
> > 
> > Ultimately we need to have a proper solution, because there can be other
> > breakages in the future. And I do wish users who need tpm emulator can
> > continue to use it. I don't have a clear answer as to how many people
> > care about this and how can we fix it.
> > 
> > Thoughts?
> 
> I just tried to verify it is working (or failing) for me. On the machine
> I normally did my Xen builds cmake was missing so it never tried to
> build libgmp. After installing it I saw the following problem:
> 
> at the end of libgmp build:
> Libraries have been installed in:
>/home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib64
> 
> and when trying to link stubdom-vtpm:
> make[2]: Entering directory '/home/gross/xen/extras/mini-os-remote'
> ld -r -d -nostdlib
> -L/home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
> elf_x86_64 -\( /home/gross/xen/stubdom/vtpm/vtpm.a -T app.lds -\) -ltpm
> -ltpm_crypto -lgmp -lpolarssl --undefined main -o
> /home/gross/xen/stubdom/mini-os-x86_64-vtpm/mini-os_app.o
> ld: cannot find -lgmp
> 
> manually adding
> "-L/home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib64" lets
> the link command succeed.
> 

This is a different issue from the one I report here.

But both stems from the fact that we don't really create a complete
cross-compile toolchain for stubdom, but piggy-back on the host
toolchain.

Presumably you didn't see my issue because you're using an older version
of glibc.

Wei.

> 
> Juergen

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

Re: [Xen-devel] [PATCH] VMX: fix realmode emulation SReg handling

[Andrew Cooper]

On 28/10/16 16:24, Jan Beulich wrote:
> Commit 0888d36bb2 ("x86/emul: Correct the decoding of SReg3 operands")
> overlooked three places where x86_seg_cs was assumed to be zero.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper    Sorry for
breaking this (especially as I had mentally noted to do something with
these loops).

>
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1499,18 +1499,18 @@ static void vmx_update_guest_cr(struct v
>  /* Entering or leaving real mode: adjust the segment registers.
>   * Need to read them all either way, as realmode reads can update
>   * the saved values we'll use when returning to prot mode. */
> -for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
> +for ( s = 0; s <= x86_seg_tr ; s++ )

As you are changing these lines, mind dropping the space between tr and ; ?

Alternatively, swapping x86_seg_tr for ARRAY_SIZE(reg) so the indices
never get out of sync?

Finally, perhaps an extra BUILD_BUG_ON(x86_seg_tr != x86_seg_gs + 1), to
cover the expectation of this bit of code?

>  vmx_get_segment_register(v, s, [s]);
>  v->arch.hvm_vmx.vmx_realmode = realmode;
>  
>  if ( realmode )
>  {
> -for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
> +for ( s = 0; s <= x86_seg_tr ; s++ )
>  vmx_set_segment_register(v, s, [s]);
>  }
>  else 
>  {
> -for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ ) 
> +for ( s = 0; s <= x86_seg_tr ; s++ )
>  if ( !(v->arch.hvm_vmx.vm86_segment_mask & (1<  vmx_set_segment_register(
>  v, s, >arch.hvm_vmx.vm86_saved_seg[s]);
>
>
>


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

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

[Lan Tianyu]

On 2016年10月21日 04:36, Andrew Cooper wrote:

>>

>>> u64 iova;
>>> /* Out parameters. */
>>> u64 translated_addr;
>>> u64 addr_mask; /* Translation page size */
>>> IOMMUAccessFlags permisson;

>>
>> How is this translation intended to be used?  How do you plan to avoid
>> race conditions where qemu requests a translation, receives one, the
>> guest invalidated the mapping, and then qemu tries to use its translated
>> address?
>>
>> There are only two ways I can see of doing this race-free.  One is to
>> implement a "memcpy with translation" hypercall, and the other is to
>> require the use of ATS in the vIOMMU, where the guest OS is required to
>> wait for a positive response from the vIOMMU before it can safely reuse
>> the mapping.
>>
>> The former behaves like real hardware in that an intermediate entity
>> performs the translation without interacting with the DMA source.  The
>> latter explicitly exposing the fact that caching is going on at the
>> endpoint to the OS.

>
> The former one seems to move DMA operation into hypervisor but Qemu
> vIOMMU framework just passes IOVA to dummy xen-vIOMMU without input
> data and access length. I will dig more to figure out solution.

Yes - that does in principle actually move the DMA out of Qemu.


Hi Adnrew:

The first solution "Move the DMA out of Qemu": Qemu vIOMMU framework
just give a chance of doing DMA translation to dummy xen-vIOMMU device
model and DMA access operation is in the vIOMMU core code. It's hard to
move this out. There are a lot of places to call translation callback
and some these are not for DMA access(E,G Map guest memory in Qemu).

The second solution "Use ATS to sync invalidation operation.": This
requires to enable ATS for all virtual PCI devices. This is not easy to do.

The following is my proposal:
When IOMMU driver invalidates IOTLB, it also will wait until the
invalidation completion. We may use this to drain in-fly DMA operation.

Guest triggers invalidation operation and trip into vIOMMU in
hypervisor to flush cache data. After this, it should go to Qemu to
drain in-fly DMA translation.

To do that, dummy vIOMMU in Qemu registers the same MMIO region as
vIOMMU's and emulation part of invalidation operation returns
X86EMUL_UNHANDLEABLE after flush cache. MMIO emulation part is supposed
to send event to Qemu and dummy vIOMMU get a chance to starts a thread
to drain in-fly DMA and return emulation done.

Guest polls IVT(invalidate IOTLB) bit in the IOTLB invalidate register
until it's cleared. Dummy vIOMMU notifies vIOMMU drain operation
completed via hypercall, vIOMMU clears IVT bit and guest finish
invalidation operation.

--
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH for-4.8] flask: build policy in different locations

[Jan Beulich]

>>> On 28.10.16 at 17:17,  wrote:
> --- a/.gitignore
> +++ b/.gitignore
> @@ -285,6 +285,8 @@ xen/xsm/flask/include/av_permissions.h
>  xen/xsm/flask/include/class_to_string.h
>  xen/xsm/flask/include/flask.h
>  xen/xsm/flask/include/initial_sid_to_string.h
> +xen/xsm/flask/policy.*
> +xen/xsm/flask/xenpolicy-*

The two entries getting added here aren't in line with ...

>  clean:
> - $(RM) tmp policy.conf $(POLICY_FILENAME)
> + $(RM) $(FLASK_BUILD_DIR)/tmp $(FLASK_BUILD_DIR)/policy.conf 
> $(POLICY_FILENAME)

... the altered tmp removal here. I can't, however, tell which side
needs updating.

Jan

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

Re: [Xen-devel] [PATCH] VMX: fix realmode emulation SReg handling

[Wei Liu]

On Fri, Oct 28, 2016 at 04:29:24PM +0100, Andrew Cooper wrote:
> On 28/10/16 16:24, Jan Beulich wrote:
> > Commit 0888d36bb2 ("x86/emul: Correct the decoding of SReg3 operands")
> > overlooked three places where x86_seg_cs was assumed to be zero.
> >
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] Test Xen 4.8 RC4 not stable 27.10.16

[Wei Liu]

On Fri, Oct 28, 2016 at 04:01:54PM +0100, Juergen Schinker wrote:
> 
> 
> - On 28 Oct, 2016, at 13:07, Boris Ostrovsky boris.ostrov...@oracle.com 
> wrote:
> 
> > I believe at least on some distros /var/run should be soft-linked to
> > /run, otherwise whoever cleans up those directories (the command name
> > escapes me right now) will only remove files from /run and leave
> > /var/run (and therefore /var/run/xen/xenstored.pid) untouched.
> > 
> > And because xencommons checks for existence of this this file before
> > starting xenstored the latter never starts.
> > 
> > -boris
> 
> root@xen:~# ls -la /var/run/xen/xenstored.pid 
> -rw-r- 1 root root 6 Oct 28 15:15 /var/run/xen/xenstored.pid
> 
>   
>33 ?00:00:00 xenwatch
>34 ?00:00:00 xenbus
>45 ?00:00:00 xenbus_frontend
>   785 ?00:00:00 xen_pciback_wor
>  1137 ?00:00:00 xenwatchdogd
>  1169 ?00:00:00 xen-init-dom0
>  1175 ?00:00:00 xenconsoled
> 
> Thats exactly what I'm sayin , maybe we need a more intelligent check to see 
> if xenstored is running
> 
> not just a simple pid check
> 

But ... the pid check is the usual way of checking if a daemon is
active.

I think a bit work is required to work out why xenstored.pid stays
across reboot -- it is not supposed to work like that on a FHS compliant
system.

And how do other daemons work on your test host, presumably they will
see stale pid files as well.  Are there any other pid files under
/var/run? If so, do the corresponding daemon run properly?

Wei.

> J

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

[Xen-devel] [PATCH] VMX: fix realmode emulation SReg handling

[Jan Beulich]

Commit 0888d36bb2 ("x86/emul: Correct the decoding of SReg3 operands")
overlooked three places where x86_seg_cs was assumed to be zero.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1499,18 +1499,18 @@ static void vmx_update_guest_cr(struct v
 /* Entering or leaving real mode: adjust the segment registers.
  * Need to read them all either way, as realmode reads can update
  * the saved values we'll use when returning to prot mode. */
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
+for ( s = 0; s <= x86_seg_tr ; s++ )
 vmx_get_segment_register(v, s, [s]);
 v->arch.hvm_vmx.vmx_realmode = realmode;
 
 if ( realmode )
 {
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
+for ( s = 0; s <= x86_seg_tr ; s++ )
 vmx_set_segment_register(v, s, [s]);
 }
 else 
 {
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ ) 
+for ( s = 0; s <= x86_seg_tr ; s++ )
 if ( !(v->arch.hvm_vmx.vm86_segment_mask & (1<arch.hvm_vmx.vm86_saved_seg[s]);


VMX: fix realmode emulation SReg handling

Commit 0888d36bb2 ("x86/emul: Correct the decoding of SReg3 operands")
overlooked three places where x86_seg_cs was assumed to be zero.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1499,18 +1499,18 @@ static void vmx_update_guest_cr(struct v
 /* Entering or leaving real mode: adjust the segment registers.
  * Need to read them all either way, as realmode reads can update
  * the saved values we'll use when returning to prot mode. */
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
+for ( s = 0; s <= x86_seg_tr ; s++ )
 vmx_get_segment_register(v, s, [s]);
 v->arch.hvm_vmx.vmx_realmode = realmode;
 
 if ( realmode )
 {
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ )
+for ( s = 0; s <= x86_seg_tr ; s++ )
 vmx_set_segment_register(v, s, [s]);
 }
 else 
 {
-for ( s = x86_seg_cs ; s <= x86_seg_tr ; s++ ) 
+for ( s = 0; s <= x86_seg_tr ; s++ )
 if ( !(v->arch.hvm_vmx.vm86_segment_mask & (1<arch.hvm_vmx.vm86_saved_seg[s]);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH for-4.8] flask: build policy in different locations

[Wei Liu]

The flask policy can be build twice -- one for hypervisor and one for
tools.

Before this patch, everything is built inside tools/flask/policy
directory.  It is possible to have a race to write to the same output
file when running parallel builds.

Prepend output file names with FLASK_BUILD_DIR. Hypervisor and tools
build will set that variable to different directories, so that we can
be safe from races.

Adjust other bits of the build system as needed.

Signed-off-by: Wei Liu 
---
Cc: Daniel De Graaf 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 .gitignore |  2 ++
 tools/flask/policy/Makefile|  2 ++
 tools/flask/policy/Makefile.common | 12 
 xen/xsm/flask/Makefile |  7 ---
 4 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6e5955e..a2f34a1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -285,6 +285,8 @@ xen/xsm/flask/include/av_permissions.h
 xen/xsm/flask/include/class_to_string.h
 xen/xsm/flask/include/flask.h
 xen/xsm/flask/include/initial_sid_to_string.h
+xen/xsm/flask/policy.*
+xen/xsm/flask/xenpolicy-*
 tools/flask/policy/policy.conf
 tools/flask/policy/xenpolicy-*
 xen/xen
diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index bead199..2fa8392 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -1,4 +1,6 @@
 XEN_ROOT=$(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+FLASK_BUILD_DIR=$(CURDIR)
+
 include $(CURDIR)/Makefile.common
diff --git a/tools/flask/policy/Makefile.common 
b/tools/flask/policy/Makefile.common
index 312dec9..6d3ae3b 100644
--- a/tools/flask/policy/Makefile.common
+++ b/tools/flask/policy/Makefile.common
@@ -3,6 +3,10 @@
 
 XEN_ROOT=$(CURDIR)/../../..
 
+ifeq ($(FLASK_BUILD_DIR),)
+$(error FLASK_BUILD_DIR not set)
+endif
+
 
 #
 # Configurable portions of the Makefile
@@ -31,7 +35,7 @@ OUTPUT_POLICY ?= $(BEST_POLICY_VER)
 #
 
 
-POLICY_FILENAME = xenpolicy-$(shell $(MAKE) -C $(XEN_ROOT)/xen xenversion 
--no-print-directory)
+POLICY_FILENAME = $(FLASK_BUILD_DIR)/xenpolicy-$(shell $(MAKE) -C 
$(XEN_ROOT)/xen xenversion --no-print-directory)
 POLICY_LOADPATH = /boot
 
 # List of policy versions supported by the hypervisor
@@ -114,14 +118,14 @@ install: $(POLICY_FILENAME)
$(INSTALL_DIR) $(DESTDIR)/$(POLICY_LOADPATH)
$(INSTALL_DATA) $^ $(DESTDIR)/$(POLICY_LOADPATH)
 
-$(POLICY_FILENAME): policy.conf
+$(POLICY_FILENAME): $(FLASK_BUILD_DIR)/policy.conf
$(CHECKPOLICY) $(CHECKPOLICY_PARAM) $^ -o $@
 
-policy.conf: $(POLICY_SECTIONS) $(MOD_CONF)
+$(FLASK_BUILD_DIR)/policy.conf: $(POLICY_SECTIONS) $(MOD_CONF)
$(M4) $(M4PARAM) $(POLICY_SECTIONS) > $@
 
 clean:
-   $(RM) tmp policy.conf $(POLICY_FILENAME)
+   $(RM) $(FLASK_BUILD_DIR)/tmp $(FLASK_BUILD_DIR)/policy.conf 
$(POLICY_FILENAME)
 
 distclean: clean
 
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index 0ed7d7b..898cc20 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -29,10 +29,11 @@ $(AV_H_FILES): $(AV_H_DEPEND)
 
 obj-$(CONFIG_XSM_POLICY) += policy.o
 
-POLICY_SRC := $(XEN_ROOT)/tools/flask/policy/xenpolicy-$(XEN_FULLVERSION)
+FLASK_BUILD_DIR := $(CURDIR)
+POLICY_SRC := $(FLASK_BUILD_DIR)/xenpolicy-$(XEN_FULLVERSION)
 
 policy.bin: FORCE
-   $(MAKE) -f $(XEN_ROOT)/tools/flask/policy/Makefile.common -C 
$(XEN_ROOT)/tools/flask/policy
+   $(MAKE) -f $(XEN_ROOT)/tools/flask/policy/Makefile.common -C 
$(XEN_ROOT)/tools/flask/policy FLASK_BUILD_DIR=$(FLASK_BUILD_DIR)
cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@
 
 policy.c: policy.bin gen-policy.py
@@ -40,4 +41,4 @@ policy.c: policy.bin gen-policy.py
 
 .PHONY: clean
 clean::
-   rm -f $(ALL_H_FILES) *.o $(DEPS) policy.c policy.bin
+   rm -f $(ALL_H_FILES) *.o $(DEPS) policy.* $(POLICY_SRC)
-- 
2.1.4


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

[Xen-devel] [PATCH] stubdom: fix stubdom-vtpm build

[Juergen Gross]

stubdom-vtpm needs gmp and expects it under
stubdom/cross-root-x86_64/x86_64-xen-elf/lib while gmp seems to install
it under stubdom/cross-root-x86_64/x86_64-xen-elf/lib64

Modify the Makefile to account for this by moving the gmp.a file from
lib64 to lib if necessary.

Signed-off-by: Juergen Gross 
---
 stubdom/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index 0252bcc..4851d03 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -176,11 +176,13 @@ gmp-$(XEN_TARGET_ARCH): gmp-$(GMP_VERSION).tar.bz2 
$(NEWLIB_STAMPFILE)
touch $@
 
 GMP_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libgmp.a
+GMP_STAMPFILE64=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib64/libgmp.a
 cross-gmp: $(GMP_STAMPFILE)
 $(GMP_STAMPFILE): gmp-$(XEN_TARGET_ARCH)
( cd $< && \
  $(MAKE) && \
  $(MAKE) DESTDIR= install )
+   if [ ! -f "$(GMP_STAMPFILE)" -a -f "$(GMP_STAMPFILE64)" ]; then mv 
$(GMP_STAMPFILE64) $(GMP_STAMPFILE); fi
 
 #
 # cross-polarssl
-- 
2.6.6


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

Re: [Xen-devel] Test Xen 4.8 RC4 not stable 27.10.16

[Juergen Schinker]

- On 28 Oct, 2016, at 13:07, Boris Ostrovsky boris.ostrov...@oracle.com 
wrote:

> I believe at least on some distros /var/run should be soft-linked to
> /run, otherwise whoever cleans up those directories (the command name
> escapes me right now) will only remove files from /run and leave
> /var/run (and therefore /var/run/xen/xenstored.pid) untouched.
> 
> And because xencommons checks for existence of this this file before
> starting xenstored the latter never starts.
> 
> -boris

root@xen:~# ls -la /var/run/xen/xenstored.pid 
-rw-r- 1 root root 6 Oct 28 15:15 /var/run/xen/xenstored.pid

  
   33 ?00:00:00 xenwatch
   34 ?00:00:00 xenbus
   45 ?00:00:00 xenbus_frontend
  785 ?00:00:00 xen_pciback_wor
 1137 ?00:00:00 xenwatchdogd
 1169 ?00:00:00 xen-init-dom0
 1175 ?00:00:00 xenconsoled

Thats exactly what I'm sayin , maybe we need a more intelligent check to see if 
xenstored is running

not just a simple pid check

J

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

[Xen-devel] [PATCH] stubdom: fix "make distclean" regarding gmp

[Juergen Gross]

make distclean tries to remove stubdom/gmp-4.3.2.tar.gz, while the
downloaded file is stubdom/gmp-4.3.2.tar.bz2

Signed-off-by: Juergen Gross 
---
 stubdom/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index d7a47f0..0252bcc 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -649,7 +649,7 @@ patchclean: crossclean
 downloadclean: patchclean
rm -f newlib-$(NEWLIB_VERSION).tar.gz
rm -f zlib-$(ZLIB_VERSION).tar.gz
-   rm -f gmp-$(GMP_VERSION).tar.gz
+   rm -f gmp-$(GMP_VERSION).tar.bz2
rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz
rm -f pciutils-$(LIBPCI_VERSION).tar.bz2
rm -f grub-$(GRUB_VERSION).tar.gz
-- 
2.6.6


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

Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Juergen Gross]

On 28/10/16 14:10, Wei Liu wrote:
> Hi all
> 
> There have been a few reports on stubdom build failure with gcc 6
> toolchain. I spent some time yesterday to figure what went wrong. Here
> is what I found.
> 
> When building GMP library, its configure script generates small C
> programs to determine various aspects of the system. Unfortunately the
> build rune for it is incorrect, so the test program ends up consuming
> newlib headers while linking against the host glibc. It's amazing that
> this even worked in the past few years! :-)
> 
> Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
> -LXXX" doesn't work. It turns out that there is no crt generated in
> newlib. I'm not sure if that's because the newlib port is incomplete or
> I haven't discovered a way to teach it to generate one.
> 
> So what should we do with this? I'm not sure if I can come up with a
> non-intrusive patch quickly.  GMP is only used by tpm emulator, so for
> the imminent 4.8 release I can write a patch to disable building that.
> 
> Ultimately we need to have a proper solution, because there can be other
> breakages in the future. And I do wish users who need tpm emulator can
> continue to use it. I don't have a clear answer as to how many people
> care about this and how can we fix it.
> 
> Thoughts?

I just tried to verify it is working (or failing) for me. On the machine
I normally did my Xen builds cmake was missing so it never tried to
build libgmp. After installing it I saw the following problem:

at the end of libgmp build:
Libraries have been installed in:
   /home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib64

and when trying to link stubdom-vtpm:
make[2]: Entering directory '/home/gross/xen/extras/mini-os-remote'
ld -r -d -nostdlib
-L/home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib  -m
elf_x86_64 -\( /home/gross/xen/stubdom/vtpm/vtpm.a -T app.lds -\) -ltpm
-ltpm_crypto -lgmp -lpolarssl --undefined main -o
/home/gross/xen/stubdom/mini-os-x86_64-vtpm/mini-os_app.o
ld: cannot find -lgmp

manually adding
"-L/home/gross/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib64" lets
the link command succeed.


Juergen

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

[Xen-devel] [PATCH for-4.8] tools/libacpi: fix sed usage

[Roger Pau Monne]

Current usage of sed in the libacpi Makefile make uses of non-POSIX options,
that are not available on all the OSes supported by the Xen tools.

The '-i' option has slightly different semantics between GNU and BSD sed
implementations, while on the GNU version the suffix is optional, on the BSD
one it is not. Also BSD sed seems to have problems parsing the script
itself, reporting "extra characters at the end of d command".

Fix those issues by piping the output of awk into sed directly, and
replacing the script with a simpler version that achieves the same purpose
(removing the initial license header comment).

Signed-off-by: Roger Pau Monné 
---
Cc: Boris Ostrovsky 
Cc: Jan Beulich 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libacpi/Makefile | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 18a5cd4..c9eb514 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -47,9 +47,8 @@ $(MK_DSDT): mk_dsdt.c
 
 ifeq ($(GPL),y)
 $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
gpl/mk_dsdt_gpl.sh $(MK_DSDT)
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
-   # Strip license comment
-   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   # Remove last bracket and strip license comment
+   awk 'NR > 1 {print s} {s=$$0}' $< | sed '1,/\*\//d' > $@.$(TMP_SUFFIX)
$(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
$(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
@@ -57,8 +56,8 @@ $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl 
dsdt_acpi_info.asl gpl/mk_d
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
 $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl 
gpl/mk_dsdt_gpl.sh $(MK_DSDT)
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
-   sed -i '1,/\*\//{/\/\*/,/\*\//d}' $@.$(TMP_SUFFIX)
+   # Remove last bracket and strip license comment
+   awk 'NR > 1 {print s} {s=$$0}' $< | sed '1,/\*\//d' > $@.$(TMP_SUFFIX)
$(SHELL) gpl/mk_dsdt_gpl.sh >> $@.$(TMP_SUFFIX)
cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
$(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@.$(TMP_SUFFIX)
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] [PATCH v2] xenfv: set has_acpi_build to false

[Wei Liu]

On Thu, Oct 27, 2016 at 11:58:29AM -0700, Stefano Stabellini wrote:
> On Thu, 27 Oct 2016, Sander Eikelenboom wrote:
> > Thursday, October 27, 2016, 3:51:09 PM, you wrote:
> > 
> > > Xen's toolstack is in charge of building ACPI tables. Skip ACPI table
> > > building and loading in QEMU by setting has_acpi_build to false for
> > > xenfv machine.
> > 
> > > This issue is discovered due to direct kernel boot on Xen doesn't boot
> > > anymore, because the new ACPI tables cause the guest to exceed its
> > > memory allocation limit.
> > 
> > > Reported-by: Sander Eikelenboom 
> > > Signed-off-by: Wei Liu 
> > 
> > Just given this patch a spin and you may add a:
> > Tested-by: Sander Eikelenboom 
> 
> The problem with this patch is that it only covers the xenfv machine
> case, which is default, but QEMU can also be invoked with -M
> pc,accel=xen. That case wouldn't be fixed by this patch. Wei, you can
> test it by adding "xen_platform_pci=0" to the VM config file.
> That's why we probably need a new option, similar to has_acpi_build, but
> that can be changed at accelerator init time.
> 

Do you mean we should add a new field to AccelClass?

Wei.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  35ac0c08178ac15565b32ca56b00fa5414f1d3b1
baseline version:
 xen  a418ec07cf2668197548c6503924139a2098e41d

Last test of basis   101722  2016-10-27 15:02:03 Z0 days
Testing same since   101752  2016-10-28 12:02:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=35ac0c08178ac15565b32ca56b00fa5414f1d3b1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
35ac0c08178ac15565b32ca56b00fa5414f1d3b1
+ branch=xen-unstable-smoke
+ revision=35ac0c08178ac15565b32ca56b00fa5414f1d3b1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x35ac0c08178ac15565b32ca56b00fa5414f1d3b1 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables

[Boris Ostrovsky]

On 10/27/2016 11:04 AM, Roger Pau Monne wrote:
> On Thu, Oct 27, 2016 at 10:40:52AM -0400, Boris Ostrovsky wrote:
>>
>> On 10/27/2016 10:30 AM, Jan Beulich wrote:
>> On 27.10.16 at 16:15,  wrote:
 On 10/27/2016 10:02 AM, Jan Beulich wrote:
 On 27.10.16 at 15:51,  wrote:
>> I re-read this thread and I am not sure I understand why we can't keep
>> host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so
>> we can place our versions of RSDT/XSDT at the address that the
>> descriptor points to.
>>
>> Unless that address is beyond dom0 memory allocation so that could be a
>> problem I guess.
> Also eventually we may want to add tables, not just remove some,
> and then there may not be enough space at the original location.
> Plus I think nothing precludes the XSDT living below 1Mb, and then
> we're back into the same problems discussed in another branch of
> this thread.
 Yes, that is a problem.

 I guess we will need to do something in Linux to override descriptor
 search. There is already some cruft for this but it appears to be
 kexec-specific.
>>> As Roger pointed out - there should be kexec-independent logic
>>> to avoid that lookup on EFI systems (by finding the pointer earlier
>>> another way).
>>
>> Yes, that's exactly what Linux does (acpi_os_get_root_pointer()) but that
>> would imply that we are running on a UEFI system, which we are not. And
>> trying to fake just this feature may cause other components to get confused.
> TBH, I would just make acpi_rsdp not dependent on KEXEC, but is this going 
> to be propagated to user-space tools somehow (ie: so that acpidump will 
> report the right tables)?

(Sorry, I forgot to respond)

If a tool is reading /sys/firmware/acpi/tables then I think it will see
what the kernel is using. acpidump, for example, *is* reading this
directory.

-boris

>
> I prefer this solution because it seems simpler and less likely to cause 
> future issues, but if this seems like too much fuss I can always try to 
> place the RSDP on top of the original one and shadow that page. From the 
> information I've been able to find on the Internet, the EBDA just seems to 
> contain the position of the pointing device (PS/2 mouse) [0], which I doubt 
> is used by any modern OS.
>
> Roger.
>
> [0] 
> http://www.msc-technologies.eu/fileadmin/documentpool/Support-Center/Archive/70-PISA/PISA-P/02-Manual/BIOS%20Programmer's%20Guide%20v10.pdf?file==


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

Re: [Xen-devel] [XTF PATCH] XSA-186: Work around suspected Broadwell TLB erratum

[Jan Beulich]

>>> On 28.10.16 at 15:02,  wrote:
> On 28/10/16 13:49, Jan Beulich wrote:
> On 28.10.16 at 14:39,  wrote:
>>> On 28/10/16 13:03, Jan Beulich wrote:
>>> On 28.10.16 at 12:36,  wrote:
> Signed-off-by: Andrew Cooper 
 Reviewed-by: Jan Beulich 
 (Maybe you want to drop the ...

> --- a/tests/xsa-186/main.c
> +++ b/tests/xsa-186/main.c
> @@ -144,6 +144,29 @@ void test_main(void)
>  memcpy(stub, insn_buf_start, insn_buf_end - insn_buf_start);
>  
>  /*
> + * Work around suspected Broadwell TLB Erratum
> + *
> + * Occasionally, this test failes with:
> + *
> + *   --- Xen Test Framework ---
> + *   Environment: HVM 64bit (Long mode 4 levels)
> + *   XSA-186 PoC
> + *   **
> + *   PANIC: Unhandled exception at 0008:fffa
> + *   Vec 14 #PF[-I-sr-] %cr2 fffa
> + *   **
> + *
> + * on Broadwell hardware.  The mapping is definitely present as the
> + * memcpy() has already succeeded.  Inserting an invlpg resolves the
> + * issue, sugguesting that there is a race conditon between dTLB/iTLB
 ... stray u which slipped into "suggesting".)

 Btw - would you mind trying something else: Instead of the INVLPG,
 put a CPUID or some other serializing instruction in here. ISTR that
 for self modifying code this is required, i.e. the CPU could have been
 fetching instructions ahead of the memcpy(), and nothing would be
 there to force it to drop what it has already executed speculatively,
 including the exception token.
>>> That is an interesting point, but still doesn't explain the symptoms. 
>>> If the icache wasn't flushed, we might get junk instructions and a #UD/#GP.
>> No. As the processor speculates the call, it won't be able to fetch
>> the target instruction and hence would insert an exception token
>> into the queue. There would be junk instruction bytes only if there
>> was a prior mapping for that page, but aiui a mapping for that
>> address gets established exactly once.
> 
> Re-reading Intel Vol 3 11.6 "Self-Modifying Code".
> 
> * A write to a memory location in a code segment that is currently
> cached in the processor causes the associated cache line (or lines) to
> be invalidated. This check is based on the physical address of the
> instruction.  If the write affects a prefetched instruction, the
> prefetch queue is invalidated. This latter check is based on the linear
> address of the instruction.
> 
> * Systems software, such as a debugger, that might possibly modify an
> instruction using a different linear address than that used to fetch the
> instruction, will execute a serializing operation, such as a CPUID
> instruction, before the modified instruction is executed, which will
> automatically resynchronize the instruction cache and prefetch queue.
> 
> As this is a single vcpu using a single flat address space, the memcpy()
> should invalidate any speculative execution which has already happened.

And still you describe only the case where there would need to be
a prior mapping - without one there simply is no physical address to
compare against. What if speculative execution ends up performing
the call to stub before you finish populating page tables? That would
also explain the error code. But aiui this might still be an erratum, as
it might be a memory ordering violation (depending on whether insn
fetches count as reads here, which would then have to observe
earlier writes, albeit the addresses of the two are different).

Jan

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

Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Wei Liu]

On Fri, Oct 28, 2016 at 02:30:02PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Stubdom GMP build failure for gcc 6"):
> > Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
> > -LXXX" doesn't work. It turns out that there is no crt generated in
> > newlib. I'm not sure if that's because the newlib port is incomplete or
> > I haven't discovered a way to teach it to generate one.
> 
> How does stubdom link its actual final program, without a crt0 ?
> 

It chdir to mini-os and uses linker script provided there.

> Can we not just reproduce its link line somehow ?
> 

I don't think that would result in a program that can run on Linux.

Wei.

> Ian.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   5 xen-buildfail REGR. vs. 101673
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail REGR. vs. 101673
 test-amd64-i386-xl-qemuu-debianhvm-amd64 18 guest-start.2 fail REGR. vs. 101673
 test-armhf-armhf-xl-vhd  10 guest-start  fail REGR. vs. 101673
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101673
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 101673
 test-armhf-armhf-libvirt-qcow2 14 guest-start/debian.repeat fail REGR. vs. 
101673

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101673
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101673
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101673
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101673
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101673
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101673
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101673

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass

version targeted for testing:
 xen  a418ec07cf2668197548c6503924139a2098e41d
baseline version:
 xen  6f9b62ca57322197e26d3b22ff11b629697142bd

Last test of basis   101673  2016-10-26 02:01:16 Z2 days
Failing since101698  2016-10-26 19:50:48 Z1 days2 attempts
Testing same since   101726  2016-10-27 18:38:28 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Ian Jackson]

Wei Liu writes ("Stubdom GMP build failure for gcc 6"):
> Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
> -LXXX" doesn't work. It turns out that there is no crt generated in
> newlib. I'm not sure if that's because the newlib port is incomplete or
> I haven't discovered a way to teach it to generate one.

How does stubdom link its actual final program, without a crt0 ?

Can we not just reproduce its link line somehow ?

Ian.

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

Re: [Xen-devel] [PATCH v6 3/7] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed

[Jan Beulich]

>>> On 28.10.16 at 04:37,  wrote:
> We should remove the vCPU from the per-cpu blocking list
> if it is going to be destroyed.

I think I did raise this question at least once before: Why can it
still be on the list in the first place, after patch 2? This is even
more odd with ...

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -338,6 +338,7 @@ static void vmx_vcpu_destroy(struct vcpu *v)
>   * separately here.
>   */
>  vmx_vcpu_disable_pml(v);
> +vmx_pi_unblock_vcpu(v);

... the renamed function: A vCPU being destroyed can hardly get
unblocked.

If the apparently proper solution (removing devices from a domain
before destroying its vCPU-s) is not possible or feasible for some
reason, then the commit message should say so (and explain why).

Jan

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

Re: [Xen-devel] [PATCH v6 4/7] VMX: Make sure PI is in proper state before install the hooks

[Jan Beulich]

>>> On 28.10.16 at 04:37,  wrote:
> We may hit the last ASSERT() in vmx_vcpu_block in the current code,
> since vmx_vcpu_block() may get called before vmx_pi_switch_to()
> has been installed or executed. Here We use cmpxchg to update
> the NDST field, this can make sure we only update the NDST when
> vmx_pi_switch_to() has not been called. So the NDST is in a
> proper state in vmx_vcpu_block().
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Feng Wu 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v6 2/7] VMX: Properly handle pi when all the assigned devices are removed

[Jan Beulich]

>>> On 28.10.16 at 04:37,  wrote:
> @@ -215,11 +220,21 @@ void vmx_pi_hooks_assign(struct domain *d)
>  /* This function is called when pcidevs_lock is held */
>  void vmx_pi_hooks_deassign(struct domain *d)
>  {
> +struct vcpu *v;
> +
>  if ( !iommu_intpost || !has_hvm_container_domain(d) )
>  return;
>  
>  ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
>  
> +/*
> + * Pausing the domain can make sure the vCPU is not
> + * running and hence not calling the hooks simultaneously
> + * when deassigning the PI hooks and removing the vCPU
> + * from the blocking list.
> + */
> +domain_pause(d);

There's one additional caveat here which no-one of us so far thought
of: Currently there's nothing preventing the domctl-s under which
this sits from being issued by the control domain for itself. Various
other domctl-s, however, guard against this case when intending
to pause the target domain. The same needs to be done for the
ones leading here.

Jan

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

Re: [Xen-devel] [PATCH v6 1/7] VMX: Permanently assign PI hook vmx_pi_switch_to()

[Jan Beulich]

>>> On 28.10.16 at 15:04,  wrote:
 On 28.10.16 at 04:37,  wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -221,9 +221,14 @@ void vmx_pi_hooks_deassign(struct domain *d)
>>  ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
>>  
>>  d->arch.hvm_domain.vmx.vcpu_block = NULL;
>> -d->arch.hvm_domain.vmx.pi_switch_from = NULL;
>> -d->arch.hvm_domain.vmx.pi_switch_to = NULL;
> 
> And with the commit message as it is right now, it is completely
> unclear why the from hook also gets zapped. In fact, with the
> description pointing out a problem with just the SN=1 case, I
> don't see what you need the from hook for without devices
> assigned, as that's where SN gets set (and you want to avoid
> that).
> 
>>  d->arch.hvm_domain.vmx.pi_do_resume = NULL;
>> +d->arch.hvm_domain.vmx.pi_switch_from = NULL;

Oh, I'm sorry - I paid attention only to the lines getting removed
above, not the one line getting re-inserted here. That addresses
my comment, of course; I just can't see why the line needs to be
moved.

Jan

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

[Xen-devel] [ovmf baseline-only test] 67952: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67952 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67952/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0a18956d54cfe70b736b029c62ce53f29b903745
baseline version:
 ovmf 4e908975c645bedd40ac77497d42629ef3cf9fc5

Last test of basis67940  2016-10-27 04:18:26 Z1 days
Testing same since67952  2016-10-27 21:51:32 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Brian J. Johnson 
  Brian Johnson 
  Gary Lin 
  gdong1 
  Jaben Carsey 
  Kyle Roberts 
  Laszlo Ersek 
  Maurice Ma 
  Ryan Harkin 
  Zhang Lubo 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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.

(No revision log; it would be 525 lines long.)

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

Re: [Xen-devel] Test Xen 4.8 RC4 not stable 27.10.16

[Boris Ostrovsky]

On 10/28/2016 05:29 AM, Wei Liu wrote:
> On Thu, Oct 27, 2016 at 11:01:50PM +0100, Juergen Schinker wrote:
>>
>> - On 27 Oct, 2016, at 09:53, Wei Liu wei.l...@citrix.com wrote:
>>
>>> For the second part, xenstored.pid normally would be stored under
>>> /var/run, which should be cleared whenever the system is booted [0].
>> I know but the /var/run/xenstored.pid  stays but anyway
>>
> Please check the content of that file and see if there is really such
> process in your system.
>
> It is possible that some other init scripts are interfering with
> systemd. I don't know.


I believe at least on some distros /var/run should be soft-linked to
/run, otherwise whoever cleans up those directories (the command name
escapes me right now) will only remove files from /run and leave
/var/run (and therefore /var/run/xen/xenstored.pid) untouched.

And because xencommons checks for existence of this this file before
starting xenstored the latter never starts.

-boris


>
>> RC4 is not so stable - I have random freezes 
>>
>
> Please try to extract guest / hypervisor log that contains text of
> interest.
>
> Wei.
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel


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

Re: [Xen-devel] [XTF PATCH] XSA-186: Work around suspected Broadwell TLB erratum

[Andrew Cooper]

On 28/10/16 13:49, Jan Beulich wrote:
 On 28.10.16 at 14:39,  wrote:
>> On 28/10/16 13:03, Jan Beulich wrote:
>> On 28.10.16 at 12:36,  wrote:
 Signed-off-by: Andrew Cooper 
>>> Reviewed-by: Jan Beulich 
>>> (Maybe you want to drop the ...
>>>
 --- a/tests/xsa-186/main.c
 +++ b/tests/xsa-186/main.c
 @@ -144,6 +144,29 @@ void test_main(void)
  memcpy(stub, insn_buf_start, insn_buf_end - insn_buf_start);
  
  /*
 + * Work around suspected Broadwell TLB Erratum
 + *
 + * Occasionally, this test failes with:
 + *
 + *   --- Xen Test Framework ---
 + *   Environment: HVM 64bit (Long mode 4 levels)
 + *   XSA-186 PoC
 + *   **
 + *   PANIC: Unhandled exception at 0008:fffa
 + *   Vec 14 #PF[-I-sr-] %cr2 fffa
 + *   **
 + *
 + * on Broadwell hardware.  The mapping is definitely present as the
 + * memcpy() has already succeeded.  Inserting an invlpg resolves the
 + * issue, sugguesting that there is a race conditon between dTLB/iTLB
>>> ... stray u which slipped into "suggesting".)
>>>
>>> Btw - would you mind trying something else: Instead of the INVLPG,
>>> put a CPUID or some other serializing instruction in here. ISTR that
>>> for self modifying code this is required, i.e. the CPU could have been
>>> fetching instructions ahead of the memcpy(), and nothing would be
>>> there to force it to drop what it has already executed speculatively,
>>> including the exception token.
>> That is an interesting point, but still doesn't explain the symptoms. 
>> If the icache wasn't flushed, we might get junk instructions and a #UD/#GP.
> No. As the processor speculates the call, it won't be able to fetch
> the target instruction and hence would insert an exception token
> into the queue. There would be junk instruction bytes only if there
> was a prior mapping for that page, but aiui a mapping for that
> address gets established exactly once.

Re-reading Intel Vol 3 11.6 "Self-Modifying Code".

* A write to a memory location in a code segment that is currently
cached in the processor causes the associated cache line (or lines) to
be invalidated. This check is based on the physical address of the
instruction.  If the write affects a prefetched instruction, the
prefetch queue is invalidated. This latter check is based on the linear
address of the instruction.

* Systems software, such as a debugger, that might possibly modify an
instruction using a different linear address than that used to fetch the
instruction, will execute a serializing operation, such as a CPUID
instruction, before the modified instruction is executed, which will
automatically resynchronize the instruction cache and prefetch queue.

As this is a single vcpu using a single flat address space, the memcpy()
should invalidate any speculative execution which has already happened.

>
>> However, in this case the fault is for an instruction fetch from a
>> non-present page, not a failure to execute what it found there.
>>
>> I expect a cpuid instruction would resolve the issue, but it also forces
>> a vmexit which complicates the microarchitectural interactions here. 
>> Something else, like executing an int3 will also serialise the pipeline,
>> but not vmexit.  I will try and find some time to experiment.
> You're in ring 0, aren't you? That gives you plenty of serializing
> instructions which don't directly interact with the TLBs. An LLDT
> with a zero selector might be the one with least side effects. And
> in case you're not in ring 0, make up an interrupt frame and
> execute an IRET.

Yes - all better options.

~Andrew

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

Re: [Xen-devel] [PATCH v6 1/7] VMX: Permanently assign PI hook vmx_pi_switch_to()

[Jan Beulich]

>>> On 28.10.16 at 04:37,  wrote:
> PI hook vmx_pi_switch_to() is needed even when any previously
> assigned device is detached from the domain. Since 'SN' bit is
> also used to control the CPU side PI and we change the state of
> SN bit in these two functions,

There's just one function you've mentioned up to here.

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -221,9 +221,14 @@ void vmx_pi_hooks_deassign(struct domain *d)
>  ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
>  
>  d->arch.hvm_domain.vmx.vcpu_block = NULL;
> -d->arch.hvm_domain.vmx.pi_switch_from = NULL;
> -d->arch.hvm_domain.vmx.pi_switch_to = NULL;

And with the commit message as it is right now, it is completely
unclear why the from hook also gets zapped. In fact, with the
description pointing out a problem with just the SN=1 case, I
don't see what you need the from hook for without devices
assigned, as that's where SN gets set (and you want to avoid
that).

>  d->arch.hvm_domain.vmx.pi_do_resume = NULL;
> +d->arch.hvm_domain.vmx.pi_switch_from = NULL;
> +
> +/*
> + * In fact, we can remove 'vmx_pi_switch_to' inside itself if no new 
> device

s/can/could/

> + * is in the process of getting assigned and "from" hook is NULL. 
> However,
> + * it is not straightforward to find a clear solution, so just leave it 
> here.
> + */
>  }
>  
>  static int vmx_domain_initialise(struct domain *d)

Jan

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

Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Wei Liu]

On Fri, Oct 28, 2016 at 06:56:39AM -0600, Jan Beulich wrote:
> >>> On 28.10.16 at 14:50,  wrote:
> > On Fri, Oct 28, 2016 at 06:29:49AM -0600, Jan Beulich wrote:
> >> >>> On 28.10.16 at 14:10,  wrote:
> >> > There have been a few reports on stubdom build failure with gcc 6
> >> > toolchain. I spent some time yesterday to figure what went wrong. Here
> >> > is what I found.
> >> > 
> >> > When building GMP library, its configure script generates small C
> >> > programs to determine various aspects of the system. Unfortunately the
> >> > build rune for it is incorrect, so the test program ends up consuming
> >> > newlib headers while linking against the host glibc. It's amazing that
> >> > this even worked in the past few years! :-)
> >> > 
> >> > Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
> >> > -LXXX" doesn't work. It turns out that there is no crt generated in
> >> > newlib. I'm not sure if that's because the newlib port is incomplete or
> >> > I haven't discovered a way to teach it to generate one.
> >> 
> >> Considering that they can't reasonably try to run any of these
> >> test programs (after all this is a cross build), wouldn't it suffice to
> >> make up crt*.o just for the configure process, and just providing
> >> the necessary symbols to make linking succeed? Agreed this, if
> >> anything, makes the present situation even uglier, but it might
> >> work.
> > 
> > It might. But that's not sustainable IMO.
> 
> I agree, and tried to indicate so with the last sentence. It was just
> a thought for a possible non-intrusive workaround for 4.8.
> 
> > One thing is that gmp configure doesn't try to run those test programs,
> > because the configure rune doesn't indicate a cross-build, although it
> > is actually one.
> 
> Considering what you write further down, DYM "does try to run"
> (in which case indeed we're hosed)?
> 

Yes, I meant "does try to run".

> >> But what I'm not understanding - what did change with gcc 6
> >> here? There's surely no libc version dependency in the compiler,
> >> so whatever worked in older gcc for linking purposes should work
> >> here too.
> >> 
> > 
> > It's not it doesn't link anymore.
> > 
> > A sample test program:
> > 
> >typedef unsigned short ac__type_sizeof_;
> > static long int longval () { return (long int) (sizeof
> > (ac__type_sizeof_)); }
> > static unsigned long int ulongval () { return (long int) (sizeof
> > (ac__type_sizeof_)); }
> > #include 
> > #include 
> > int
> > main ()
> > {
> > 
> >   FILE *f = fopen ("conftest.val", "w");
> >   if (! f)
> > return 1;
> >   if (((long int) (sizeof (ac__type_sizeof_))) < 0)
> > {
> >   long int i = longval ();
> >   if (i != ((long int) (sizeof (ac__type_sizeof_
> > return 1;
> >   fprintf (f, "%ld\n", i);
> > }
> >   else
> > {
> >   unsigned long int i = ulongval ();
> >   if (i != ((long int) (sizeof (ac__type_sizeof_
> > return 1;
> >   fprintf (f, "%lu\n", i);
> > }
> >   return ferror (f) || fclose (f) != 0;
> >   ;
> >   return 0;
> > }
> > 
> > ferror is a macro in newlib, which checks if one certain bit X is set. I
> > suppose the same bit X has a different semantics now in glibc, and then
> > fprintf (a function from glibc) happens to set bit X. This program will
> > then exit with non-zero and configure deems it failed to run.
> 
> But how is any of this gcc version dependent?
> 

Oh, yes, the subject line is misleading. Sorry.

I wrote that because it was discovered in the context of trying to
compile stubdom gmp with gcc 6.

Wei.

> Jan
> 

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

Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Jan Beulich]

>>> On 28.10.16 at 14:50,  wrote:
> On Fri, Oct 28, 2016 at 06:29:49AM -0600, Jan Beulich wrote:
>> >>> On 28.10.16 at 14:10,  wrote:
>> > There have been a few reports on stubdom build failure with gcc 6
>> > toolchain. I spent some time yesterday to figure what went wrong. Here
>> > is what I found.
>> > 
>> > When building GMP library, its configure script generates small C
>> > programs to determine various aspects of the system. Unfortunately the
>> > build rune for it is incorrect, so the test program ends up consuming
>> > newlib headers while linking against the host glibc. It's amazing that
>> > this even worked in the past few years! :-)
>> > 
>> > Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
>> > -LXXX" doesn't work. It turns out that there is no crt generated in
>> > newlib. I'm not sure if that's because the newlib port is incomplete or
>> > I haven't discovered a way to teach it to generate one.
>> 
>> Considering that they can't reasonably try to run any of these
>> test programs (after all this is a cross build), wouldn't it suffice to
>> make up crt*.o just for the configure process, and just providing
>> the necessary symbols to make linking succeed? Agreed this, if
>> anything, makes the present situation even uglier, but it might
>> work.
> 
> It might. But that's not sustainable IMO.

I agree, and tried to indicate so with the last sentence. It was just
a thought for a possible non-intrusive workaround for 4.8.

> One thing is that gmp configure doesn't try to run those test programs,
> because the configure rune doesn't indicate a cross-build, although it
> is actually one.

Considering what you write further down, DYM "does try to run"
(in which case indeed we're hosed)?

>> But what I'm not understanding - what did change with gcc 6
>> here? There's surely no libc version dependency in the compiler,
>> so whatever worked in older gcc for linking purposes should work
>> here too.
>> 
> 
> It's not it doesn't link anymore.
> 
> A sample test program:
> 
>typedef unsigned short ac__type_sizeof_;
> static long int longval () { return (long int) (sizeof
> (ac__type_sizeof_)); }
> static unsigned long int ulongval () { return (long int) (sizeof
> (ac__type_sizeof_)); }
> #include 
> #include 
> int
> main ()
> {
> 
>   FILE *f = fopen ("conftest.val", "w");
>   if (! f)
> return 1;
>   if (((long int) (sizeof (ac__type_sizeof_))) < 0)
> {
>   long int i = longval ();
>   if (i != ((long int) (sizeof (ac__type_sizeof_
>   return 1;
>   fprintf (f, "%ld\n", i);
> }
>   else
> {
>   unsigned long int i = ulongval ();
>   if (i != ((long int) (sizeof (ac__type_sizeof_
>   return 1;
>   fprintf (f, "%lu\n", i);
> }
>   return ferror (f) || fclose (f) != 0;
>   ;
>   return 0;
> }
> 
> ferror is a macro in newlib, which checks if one certain bit X is set. I
> suppose the same bit X has a different semantics now in glibc, and then
> fprintf (a function from glibc) happens to set bit X. This program will
> then exit with non-zero and configure deems it failed to run.

But how is any of this gcc version dependent?

Jan

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

Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Wei Liu]

On Fri, Oct 28, 2016 at 06:29:49AM -0600, Jan Beulich wrote:
> >>> On 28.10.16 at 14:10,  wrote:
> > There have been a few reports on stubdom build failure with gcc 6
> > toolchain. I spent some time yesterday to figure what went wrong. Here
> > is what I found.
> > 
> > When building GMP library, its configure script generates small C
> > programs to determine various aspects of the system. Unfortunately the
> > build rune for it is incorrect, so the test program ends up consuming
> > newlib headers while linking against the host glibc. It's amazing that
> > this even worked in the past few years! :-)
> > 
> > Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
> > -LXXX" doesn't work. It turns out that there is no crt generated in
> > newlib. I'm not sure if that's because the newlib port is incomplete or
> > I haven't discovered a way to teach it to generate one.
> 
> Considering that they can't reasonably try to run any of these
> test programs (after all this is a cross build), wouldn't it suffice to
> make up crt*.o just for the configure process, and just providing
> the necessary symbols to make linking succeed? Agreed this, if
> anything, makes the present situation even uglier, but it might
> work.
> 

It might. But that's not sustainable IMO.

One thing is that gmp configure doesn't try to run those test programs,
because the configure rune doesn't indicate a cross-build, although it
is actually one.

> But what I'm not understanding - what did change with gcc 6
> here? There's surely no libc version dependency in the compiler,
> so whatever worked in older gcc for linking purposes should work
> here too.
> 

It's not it doesn't link anymore.

A sample test program:

   typedef unsigned short ac__type_sizeof_;
static long int longval () { return (long int) (sizeof
(ac__type_sizeof_)); }
static unsigned long int ulongval () { return (long int) (sizeof
(ac__type_sizeof_)); }
#include 
#include 
int
main ()
{

  FILE *f = fopen ("conftest.val", "w");
  if (! f)
return 1;
  if (((long int) (sizeof (ac__type_sizeof_))) < 0)
{
  long int i = longval ();
  if (i != ((long int) (sizeof (ac__type_sizeof_
return 1;
  fprintf (f, "%ld\n", i);
}
  else
{
  unsigned long int i = ulongval ();
  if (i != ((long int) (sizeof (ac__type_sizeof_
return 1;
  fprintf (f, "%lu\n", i);
}
  return ferror (f) || fclose (f) != 0;
  ;
  return 0;
}

ferror is a macro in newlib, which checks if one certain bit X is set. I
suppose the same bit X has a different semantics now in glibc, and then
fprintf (a function from glibc) happens to set bit X. This program will
then exit with non-zero and configure deems it failed to run.

Wei.
 
> Jan
> 

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

Re: [Xen-devel] [XTF PATCH] XSA-186: Work around suspected Broadwell TLB erratum

[Jan Beulich]

>>> On 28.10.16 at 14:39,  wrote:
> On 28/10/16 13:03, Jan Beulich wrote:
> On 28.10.16 at 12:36,  wrote:
>>> Signed-off-by: Andrew Cooper 
>> Reviewed-by: Jan Beulich 
>> (Maybe you want to drop the ...
>>
>>> --- a/tests/xsa-186/main.c
>>> +++ b/tests/xsa-186/main.c
>>> @@ -144,6 +144,29 @@ void test_main(void)
>>>  memcpy(stub, insn_buf_start, insn_buf_end - insn_buf_start);
>>>  
>>>  /*
>>> + * Work around suspected Broadwell TLB Erratum
>>> + *
>>> + * Occasionally, this test failes with:
>>> + *
>>> + *   --- Xen Test Framework ---
>>> + *   Environment: HVM 64bit (Long mode 4 levels)
>>> + *   XSA-186 PoC
>>> + *   **
>>> + *   PANIC: Unhandled exception at 0008:fffa
>>> + *   Vec 14 #PF[-I-sr-] %cr2 fffa
>>> + *   **
>>> + *
>>> + * on Broadwell hardware.  The mapping is definitely present as the
>>> + * memcpy() has already succeeded.  Inserting an invlpg resolves the
>>> + * issue, sugguesting that there is a race conditon between dTLB/iTLB
>> ... stray u which slipped into "suggesting".)
>>
>> Btw - would you mind trying something else: Instead of the INVLPG,
>> put a CPUID or some other serializing instruction in here. ISTR that
>> for self modifying code this is required, i.e. the CPU could have been
>> fetching instructions ahead of the memcpy(), and nothing would be
>> there to force it to drop what it has already executed speculatively,
>> including the exception token.
> 
> That is an interesting point, but still doesn't explain the symptoms. 
> If the icache wasn't flushed, we might get junk instructions and a #UD/#GP.

No. As the processor speculates the call, it won't be able to fetch
the target instruction and hence would insert an exception token
into the queue. There would be junk instruction bytes only if there
was a prior mapping for that page, but aiui a mapping for that
address gets established exactly once.

> However, in this case the fault is for an instruction fetch from a
> non-present page, not a failure to execute what it found there.
> 
> I expect a cpuid instruction would resolve the issue, but it also forces
> a vmexit which complicates the microarchitectural interactions here. 
> Something else, like executing an int3 will also serialise the pipeline,
> but not vmexit.  I will try and find some time to experiment.

You're in ring 0, aren't you? That gives you plenty of serializing
instructions which don't directly interact with the TLBs. An LLDT
with a zero selector might be the one with least side effects. And
in case you're not in ring 0, make up an interrupt frame and
execute an IRET.

Jan

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

Re: [Xen-devel] [XTF PATCH] XSA-186: Work around suspected Broadwell TLB erratum

[Andrew Cooper]

On 28/10/16 13:03, Jan Beulich wrote:
 On 28.10.16 at 12:36,  wrote:
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> (Maybe you want to drop the ...
>
>> --- a/tests/xsa-186/main.c
>> +++ b/tests/xsa-186/main.c
>> @@ -144,6 +144,29 @@ void test_main(void)
>>  memcpy(stub, insn_buf_start, insn_buf_end - insn_buf_start);
>>  
>>  /*
>> + * Work around suspected Broadwell TLB Erratum
>> + *
>> + * Occasionally, this test failes with:
>> + *
>> + *   --- Xen Test Framework ---
>> + *   Environment: HVM 64bit (Long mode 4 levels)
>> + *   XSA-186 PoC
>> + *   **
>> + *   PANIC: Unhandled exception at 0008:fffa
>> + *   Vec 14 #PF[-I-sr-] %cr2 fffa
>> + *   **
>> + *
>> + * on Broadwell hardware.  The mapping is definitely present as the
>> + * memcpy() has already succeeded.  Inserting an invlpg resolves the
>> + * issue, sugguesting that there is a race conditon between dTLB/iTLB
> ... stray u which slipped into "suggesting".)
>
> Btw - would you mind trying something else: Instead of the INVLPG,
> put a CPUID or some other serializing instruction in here. ISTR that
> for self modifying code this is required, i.e. the CPU could have been
> fetching instructions ahead of the memcpy(), and nothing would be
> there to force it to drop what it has already executed speculatively,
> including the exception token.

That is an interesting point, but still doesn't explain the symptoms. 
If the icache wasn't flushed, we might get junk instructions and a #UD/#GP.

However, in this case the fault is for an instruction fetch from a
non-present page, not a failure to execute what it found there.

I expect a cpuid instruction would resolve the issue, but it also forces
a vmexit which complicates the microarchitectural interactions here. 
Something else, like executing an int3 will also serialise the pipeline,
but not vmexit.  I will try and find some time to experiment.

~Andrew


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

Re: [Xen-devel] [PATCH v2 3/5] tasklet: Remove the old-softirq implementation.

[Jan Beulich]

>>> On 25.08.16 at 21:23,  wrote:
> With the new percpu tasklet (see "tasklet: Introduce per-cpu tasklet."
> and "tasklet: Add cross CPU feeding of per-cpu-tasklets") we have
> now in a place a working version of per-cpu softirq tasklets.
> 
> We can now remove the old implementation of the
> softirq tasklet. We also remove the temporary scaffolding
> of TASKLET_SOFTIRQ_PERCPU. Further removal of code will
> be done in "tasklet: Remove the old scaffolding" once the
> schedule tasklet code is in.
> 
> This could be squashed in "tasklet: Introduce per-cpu
> tasklet for softirq." but the author thought it would
> be an easier aid in understanding the code with these
> parts split out.

When you said something in the previous patch I tended to agree.
However, seeing this I'm not sure the split up isn't ending up worse
to look at than if you had switched over in one go, retaining e.g. ...

> --- a/xen/common/tasklet.c
> +++ b/xen/common/tasklet.c
> @@ -26,7 +26,6 @@ static bool_t tasklets_initialised;
>  DEFINE_PER_CPU(unsigned long, tasklet_work_to_do);
>  
>  static DEFINE_PER_CPU(struct list_head, tasklet_list);
> -static DEFINE_PER_CPU(struct list_head, softirq_tasklet_list);

... this original list name (I now can guess why in patch 1 you named
the new list the way you did, but for the end result I think this old
name is to be preferred, as what you add is not a list of softirqs).

> @@ -89,18 +88,14 @@ static void tasklet_enqueue(struct tasklet *t)
>  
>  list = &__get_cpu_var(softirq_list);
>  list_add_tail(>list, list);
> -raise_softirq(TASKLET_SOFTIRQ_PERCPU);
> +raise_softirq(TASKLET_SOFTIRQ);
>  
>  local_irq_restore(flags);
>  return;
>  }
>  if ( t->is_softirq )
>  {
> -struct list_head *list = _cpu(softirq_tasklet_list, cpu);
> -bool_t was_empty = list_empty(list);
> -list_add_tail(>list, list);
> -if ( was_empty )
> -cpu_raise_softirq(cpu, TASKLET_SOFTIRQ);
> +BUG();

I don't think you need the is_softirq flag anymore at this point,
which would eliminate this if() altogether.

Jan

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

Re: [Xen-devel] Stubdom GMP build failure for gcc 6

[Jan Beulich]

>>> On 28.10.16 at 14:10,  wrote:
> There have been a few reports on stubdom build failure with gcc 6
> toolchain. I spent some time yesterday to figure what went wrong. Here
> is what I found.
> 
> When building GMP library, its configure script generates small C
> programs to determine various aspects of the system. Unfortunately the
> build rune for it is incorrect, so the test program ends up consuming
> newlib headers while linking against the host glibc. It's amazing that
> this even worked in the past few years! :-)
> 
> Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
> -LXXX" doesn't work. It turns out that there is no crt generated in
> newlib. I'm not sure if that's because the newlib port is incomplete or
> I haven't discovered a way to teach it to generate one.

Considering that they can't reasonably try to run any of these
test programs (after all this is a cross build), wouldn't it suffice to
make up crt*.o just for the configure process, and just providing
the necessary symbols to make linking succeed? Agreed this, if
anything, makes the present situation even uglier, but it might
work.

But what I'm not understanding - what did change with gcc 6
here? There's surely no libc version dependency in the compiler,
so whatever worked in older gcc for linking purposes should work
here too.

Jan

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

[Xen-devel] [xtf test] 101733: all pass - PUSHED

[osstest service owner]

flight 101733 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101733/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  bba9529a79eefead64a4db97658f27a275d415ca
baseline version:
 xtf  322819a7a9bdee04a7d0a0168550293ab139d8fd

Last test of basis   101718  2016-10-27 11:13:31 Z1 days
Testing same since   101733  2016-10-28 00:42:20 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

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

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


Pushing revision :

+ branch=xtf
+ revision=bba9529a79eefead64a4db97658f27a275d415ca
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf 
bba9529a79eefead64a4db97658f27a275d415ca
+ branch=xtf
+ revision=bba9529a79eefead64a4db97658f27a275d415ca
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xbba9529a79eefead64a4db97658f27a275d415ca = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' 

[Xen-devel] Stubdom GMP build failure for gcc 6

[Wei Liu]

Hi all

There have been a few reports on stubdom build failure with gcc 6
toolchain. I spent some time yesterday to figure what went wrong. Here
is what I found.

When building GMP library, its configure script generates small C
programs to determine various aspects of the system. Unfortunately the
build rune for it is incorrect, so the test program ends up consuming
newlib headers while linking against the host glibc. It's amazing that
this even worked in the past few years! :-)

Unfortunately my attempt to fix it by providing LDFLAGS="-nostdlib
-LXXX" doesn't work. It turns out that there is no crt generated in
newlib. I'm not sure if that's because the newlib port is incomplete or
I haven't discovered a way to teach it to generate one.

So what should we do with this? I'm not sure if I can come up with a
non-intrusive patch quickly.  GMP is only used by tpm emulator, so for
the imminent 4.8 release I can write a patch to disable building that.

Ultimately we need to have a proper solution, because there can be other
breakages in the future. And I do wish users who need tpm emulator can
continue to use it. I don't have a clear answer as to how many people
care about this and how can we fix it.

Thoughts?

Wei.

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

Re: [Xen-devel] [XTF PATCH] XSA-186: Work around suspected Broadwell TLB erratum

[Jan Beulich]

>>> On 28.10.16 at 12:36,  wrote:
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
(Maybe you want to drop the ...

> --- a/tests/xsa-186/main.c
> +++ b/tests/xsa-186/main.c
> @@ -144,6 +144,29 @@ void test_main(void)
>  memcpy(stub, insn_buf_start, insn_buf_end - insn_buf_start);
>  
>  /*
> + * Work around suspected Broadwell TLB Erratum
> + *
> + * Occasionally, this test failes with:
> + *
> + *   --- Xen Test Framework ---
> + *   Environment: HVM 64bit (Long mode 4 levels)
> + *   XSA-186 PoC
> + *   **
> + *   PANIC: Unhandled exception at 0008:fffa
> + *   Vec 14 #PF[-I-sr-] %cr2 fffa
> + *   **
> + *
> + * on Broadwell hardware.  The mapping is definitely present as the
> + * memcpy() has already succeeded.  Inserting an invlpg resolves the
> + * issue, sugguesting that there is a race conditon between dTLB/iTLB

... stray u which slipped into "suggesting".)

Btw - would you mind trying something else: Instead of the INVLPG,
put a CPUID or some other serializing instruction in here. ISTR that
for self modifying code this is required, i.e. the CPU could have been
fetching instructions ahead of the memcpy(), and nothing would be
there to force it to drop what it has already executed speculatively,
including the exception token.

Jan

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

Re: [Xen-devel] Followup: HVMOP_altp2m_vcpu_enable_notify code example usage

[Tamas K Lengyel]

On Thu, Oct 27, 2016 at 12:45 AM, Andrew Cooper 
wrote:

> On 26/10/2016 20:37, Matt Leinhos wrote:
> > A while ago there was a thread by the same name in this group (see
> > https://lists.xen.org/archives/html/xen-devel/2016-08/msg02591.html).
> >
> > I've looked through the thread and did not see a resolution: do we have
> > an example handler for #VE - preferably on x86_64? I haven't found such
> > a handler in the xen code or through searches.
> >
> > I am attempting to use the altp2m API from a domU and need to handle #VE.
>
> A #VE handler is only interesting for a domU, knowing it is running
> under an altp2m-capable hypervisor.
>
> The hypervisor itself won't ever receive #VE from real hardware, which
> is why there is no example code in Xen.
>

Well, unless Xen is running in a nested setting ;)


>
> I don't know if there is any public example code, but a #VE handler in
> domU is intended to work very similarly to a plain #PF handler.  #VE
> specifically means "there is an EPT translation but the access failed
> for permission reasons, and the guest has elected to handle this fault
> itself".  It is then up to the domU kernel to decide what to do; whether
> to terminate the process/thread which cause the violation, or to alter
> the permissions and rerun the instruction.
>

Correct. The guest itself needs to issue the appropriate HVMOP hypercalls
to enable #VE and register the memory location where the trap info should
be stored at. The only caveat is that only permission faults in altp2m view
1-10 will generate a #VE in the domU, view 0 won't (at least when it is
emulated on hw without real #VE support).

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

Re: [Xen-devel] [PATCH v2 for-4.8] x86/hvm: Don't truncate the hvm hypercall index before range checking it

[Wei Liu]

On Thu, Oct 27, 2016 at 04:05:44PM +0100, Andrew Cooper wrote:
> c/s 5eeca68f introduced the 64bit ABI for HVM guests, and chose to explicitly
> truncate the index, despite the fact that the `mov $imm32, %eax` in the
> hypercall page already provides the expected truncation.
> 
> The truncation isn't very obvious, and is counterintuitive, seeing as all
> other 64bit parameters are passed without truncation.  It is also different to
> the PV ABI, which is otherwise identical.
> 
> As the hypercall page has always been present for HVM guests (and indeed, is
> basically mandatory to abstract away vendor differences), it is exceedingly
> unlikely that any code exists which enters hvm_do_hypercall() with upper bits
> set in %rax.
> 
> Therefore, take the opportunity to fix the ABI before it becomes impossible to
> fix.
> 
> While tweaking this area, fix one piece of trailing whitespace.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Release-acked-by: Wei Liu 

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

[Xen-devel] [XTF PATCH] XSA-186: Work around suspected Broadwell TLB erratum

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
 tests/xsa-186/main.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/tests/xsa-186/main.c b/tests/xsa-186/main.c
index f2bc8f6..fe7e98b 100644
--- a/tests/xsa-186/main.c
+++ b/tests/xsa-186/main.c
@@ -144,6 +144,29 @@ void test_main(void)
 memcpy(stub, insn_buf_start, insn_buf_end - insn_buf_start);
 
 /*
+ * Work around suspected Broadwell TLB Erratum
+ *
+ * Occasionally, this test failes with:
+ *
+ *   --- Xen Test Framework ---
+ *   Environment: HVM 64bit (Long mode 4 levels)
+ *   XSA-186 PoC
+ *   **
+ *   PANIC: Unhandled exception at 0008:fffa
+ *   Vec 14 #PF[-I-sr-] %cr2 fffa
+ *   **
+ *
+ * on Broadwell hardware.  The mapping is definitely present as the
+ * memcpy() has already succeeded.  Inserting an invlpg resolves the
+ * issue, sugguesting that there is a race conditon between dTLB/iTLB
+ * handling.
+ *
+ * Work around the issue for now, to avoid intermittent OSSTest failures
+ * from blocking pushes of unrelated changes.
+ */
+invlpg(stub);
+
+/*
  * Execute the stub.
  *
  * Intel CPUs are happy doing this for 32 and 64bit.  AMD CPUs are happy
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 2/5] tasklet: Add cross CPU feeding of per-cpu tasklets.

[Jan Beulich]

>>> On 25.08.16 at 21:23,  wrote:
> +static void percpu_tasklet_feed(void *arg)
> +{
> +unsigned long flags;
> +struct tasklet *t;
> +struct list_head *dst_list;
> +struct list_head *list = &__get_cpu_var(tasklet_feeder);
> +
> +spin_lock_irqsave(_lock, flags);
> +
> +if ( list_empty(list) )
> +goto out;

Instead of this, how about e.g. initializing t to NULL above and ...

> +while ( !list_empty(list) )
> +{
> +t = list_entry(list->next, struct tasklet, list);

[Intermediate note: list_first_entry(); I guess there also was at
least one such case in patch 1. Or perhaps even better
list_first_entry_or_null() and then this moved into the loop
condition.]

> +BUG_ON(!t->is_percpu);
> +list_del(>list);
> +
> +dst_list = &__get_cpu_var(softirq_list);
> +list_add_tail(>list, dst_list);
> +}
> +raise_softirq(TASKLET_SOFTIRQ_PERCPU);

... making this conditional upon t not being NULL? That would at
once ...

> +out:

... eliminate this label, which otherwise I would have to comment on.

Jan

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

Re: [Xen-devel] Broadwell TLB Erratum

[Jan Beulich]

>>> On 28.10.16 at 11:55,  wrote:
> On 27/10/16 19:26, osstest service owner wrote:
>> flight 101698 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/101698/ 
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-xtf-amd64-amd64-5   44 xtf/test-hvm64-xsa-186   fail REGR. vs. 
> 101673
> 
> --- Xen Test Framework ---
> Environment: HVM 64bit (Long mode 4 levels)
> XSA-186 PoC
> **
> PANIC: Unhandled exception at 0008:fffa
> Vec 14 #PF[-I-sr-] %cr2 fffa
> **
> 
> This is an issue I have seen before, and I think it is TLB erratum in
> Broadwell processors. Within XenServer, it has now been observed on one
> SDP and two different Broadwell servers from different vendors.
> 
> The first CPU I saw it on was
> 
> CPU Vendor: Intel, Family 6 (0x6), Model 71 (0x47), Stepping 1 (raw
> 00040671)
> 
> Nobbling-1, which this test ran on is
> 
> CPU Vendor: Intel, Family 6 (0x6), Model 79 (0x4f), Stepping 1 (raw
> 000406f1)
> 
> 
> The code in question sets up the mapping, memcpy()'s an instruction stub
> into place, then calls the stub.
> 
> This pagefault is from the call, after the memcpy() has succeeded,
> therefore proving the mapping is present in the dTLB.
> 
> The issue reproduces ~1 in 200 times, but can reliably be found in a
> minute or two. Inserting an invlpg instruction immediately before the
> call appears to resolve the issue (i.e. the tests run for ~1 hour
> without observing the issue).
> 
> Architecturally however, this invlpg should have no effect.  I think
> there is some race condition propagating TLB records to the L1 iTLB if
> it is already present in the L1 dTLB.
> 
> At the first time I discovered this, I checked the NDA Specification
> Update for the processor, and didn't find any published errata which
> matched the symptoms.

So until you/we hear back from Intel (which as we all know can take
a while), could you insert an INVLPG in the test, to eliminate these
(supposedly spurious) failures?

Jan

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

[Xen-devel] [ovmf test] 101729: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d1b757e2cd034e32676c5cc2d542f785e74f8c5d
baseline version:
 ovmf 0a18956d54cfe70b736b029c62ce53f29b903745

Last test of basis   101710  2016-10-27 04:21:41 Z1 days
Testing same since   101729  2016-10-27 21:49:45 Z0 days1 attempts


People who touched revisions under test:
  David Wei 
  Gary Lin 
  gdong1 
  Guo Dong 
  Jiewen Yao 
  Jordan Justen 
  Laszlo Ersek 
  Maurice Ma 
  Michael Kinney 
  Satya Yarlagadda 
  Star Zeng 
  Yao, Jiewen 
  Yarlagadda, Satya P 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=d1b757e2cd034e32676c5cc2d542f785e74f8c5d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
d1b757e2cd034e32676c5cc2d542f785e74f8c5d
+ branch=ovmf
+ revision=d1b757e2cd034e32676c5cc2d542f785e74f8c5d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xd1b757e2cd034e32676c5cc2d542f785e74f8c5d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : 

Re: [Xen-devel] [PATCH v6 00/11] implement vcpu preempted check

[Paolo Bonzini]

On 28/10/2016 10:11, Pan Xinhui wrote:
> change from v5:
>   spilt x86/kvm patch into guest/host part.
>   introduce kvm_write_guest_offset_cached.
>   fix some typos.
>   rebase patch onto 4.9.2

Acked-by: Paolo Bonzini 

Thanks,

Paolo

> change from v4:
>   spilt x86 kvm vcpu preempted check into two patches.
>   add documentation patch.
>   add x86 vcpu preempted check patch under xen
>   add s390 vcpu preempted check patch 
> change from v3:
>   add x86 vcpu preempted check patch
> change from v2:
>   no code change, fix typos, update some comments
> change from v1:
>   a simplier definition of default vcpu_is_preempted
>   skip mahcine type check on ppc, and add config. remove dedicated macro.
>   add one patch to drop overload of rwsem_spin_on_owner and 
> mutex_spin_on_owner. 
>   add more comments
>   thanks boqun and Peter's suggestion.
> 
> This patch set aims to fix lock holder preemption issues.
> 
> test-case:
> perf record -a perf bench sched messaging -g 400 -p && perf report
> 
> 18.09%  sched-messaging  [kernel.vmlinux]  [k] osq_lock
> 12.28%  sched-messaging  [kernel.vmlinux]  [k] rwsem_spin_on_owner
>  5.27%  sched-messaging  [kernel.vmlinux]  [k] mutex_unlock
>  3.89%  sched-messaging  [kernel.vmlinux]  [k] wait_consider_task
>  3.64%  sched-messaging  [kernel.vmlinux]  [k] _raw_write_lock_irq
>  3.41%  sched-messaging  [kernel.vmlinux]  [k] mutex_spin_on_owner.is
>  2.49%  sched-messaging  [kernel.vmlinux]  [k] system_call
> 
> We introduce interface bool vcpu_is_preempted(int cpu) and use it in some spin
> loops of osq_lock, rwsem_spin_on_owner and mutex_spin_on_owner.
> These spin_on_onwer variant also cause rcu stall before we apply this patch 
> set
> 
> We also have observed some performace improvements in uninx benchmark tests.
> 
> PPC test result:
> 1 copy - 0.94%
> 2 copy - 7.17%
> 4 copy - 11.9%
> 8 copy -  3.04%
> 16 copy - 15.11%
> 
> details below:
> Without patch:
> 
> 1 copy - File Write 4096 bufsize 8000 maxblocks  2188223.0 KBps  (30.0 s, 
> 1 samples)
> 2 copy - File Write 4096 bufsize 8000 maxblocks  1804433.0 KBps  (30.0 s, 
> 1 samples)
> 4 copy - File Write 4096 bufsize 8000 maxblocks  1237257.0 KBps  (30.0 s, 
> 1 samples)
> 8 copy - File Write 4096 bufsize 8000 maxblocks  1032658.0 KBps  (30.0 s, 
> 1 samples)
> 16 copy - File Write 4096 bufsize 8000 maxblocks   768000.0 KBps  (30.1 
> s, 1 samples)
> 
> With patch: 
> 
> 1 copy - File Write 4096 bufsize 8000 maxblocks  2209189.0 KBps  (30.0 s, 
> 1 samples)
> 2 copy - File Write 4096 bufsize 8000 maxblocks  1943816.0 KBps  (30.0 s, 
> 1 samples)
> 4 copy - File Write 4096 bufsize 8000 maxblocks  1405591.0 KBps  (30.0 s, 
> 1 samples)
> 8 copy - File Write 4096 bufsize 8000 maxblocks  1065080.0 KBps  (30.0 s, 
> 1 samples)
> 16 copy - File Write 4096 bufsize 8000 maxblocks   904762.0 KBps  (30.0 
> s, 1 samples)
> 
> X86 test result:
>   test-case   after-patch   before-patch
> Execl Throughput   |18307.9 lps  |11701.6 lps 
> File Copy 1024 bufsize 2000 maxblocks  |  1352407.3 KBps |   790418.9 KBps
> File Copy 256 bufsize 500 maxblocks|   367555.6 KBps |   222867.7 KBps
> File Copy 4096 bufsize 8000 maxblocks  |  3675649.7 KBps |  1780614.4 KBps
> Pipe Throughput| 11872208.7 lps  | 11855628.9 lps 
> Pipe-based Context Switching   |  1495126.5 lps  |  1490533.9 lps 
> Process Creation   |29881.2 lps  |28572.8 lps 
> Shell Scripts (1 concurrent)   |23224.3 lpm  |22607.4 lpm 
> Shell Scripts (8 concurrent)   | 3531.4 lpm  | 3211.9 lpm 
> System Call Overhead   | 10385653.0 lps  | 10419979.0 lps 
> 
> Christian Borntraeger (1):
>   s390/spinlock: Provide vcpu_is_preempted
> 
> Juergen Gross (1):
>   x86, xen: support vcpu preempted check
> 
> Pan Xinhui (9):
>   kernel/sched: introduce vcpu preempted check interface
>   locking/osq: Drop the overload of osq_lock()
>   kernel/locking: Drop the overload of {mutex,rwsem}_spin_on_owner
>   powerpc/spinlock: support vcpu preempted check
>   x86, paravirt: Add interface to support kvm/xen vcpu preempted check
>   KVM: Introduce kvm_write_guest_offset_cached
>   x86, kvm/x86.c: support vcpu preempted check
>   x86, kernel/kvm.c: support vcpu preempted check
>   Documentation: virtual: kvm: Support vcpu preempted check
> 
>  Documentation/virtual/kvm/msr.txt |  9 -
>  arch/powerpc/include/asm/spinlock.h   |  8 
>  arch/s390/include/asm/spinlock.h  |  8 
>  arch/s390/kernel/smp.c|  9 +++--
>  arch/s390/lib/spinlock.c  | 25 -
>  arch/x86/include/asm/paravirt_types.h |  2 ++
>  arch/x86/include/asm/spinlock.h   |  8 
>  arch/x86/include/uapi/asm/kvm_para.h  |  4 +++-
>  

[Xen-devel] Broadwell TLB Erratum

[Andrew Cooper]

On 27/10/16 19:26, osstest service owner wrote:
> flight 101698 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/101698/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-xtf-amd64-amd64-5   44 xtf/test-hvm64-xsa-186   fail REGR. vs. 
> 101673

--- Xen Test Framework ---
Environment: HVM 64bit (Long mode 4 levels)
XSA-186 PoC
**
PANIC: Unhandled exception at 0008:fffa
Vec 14 #PF[-I-sr-] %cr2 fffa
**

This is an issue I have seen before, and I think it is TLB erratum in
Broadwell processors. Within XenServer, it has now been observed on one
SDP and two different Broadwell servers from different vendors.

The first CPU I saw it on was

CPU Vendor: Intel, Family 6 (0x6), Model 71 (0x47), Stepping 1 (raw
00040671)

Nobbling-1, which this test ran on is

CPU Vendor: Intel, Family 6 (0x6), Model 79 (0x4f), Stepping 1 (raw
000406f1)


The code in question sets up the mapping, memcpy()'s an instruction stub
into place, then calls the stub.

This pagefault is from the call, after the memcpy() has succeeded,
therefore proving the mapping is present in the dTLB.

The issue reproduces ~1 in 200 times, but can reliably be found in a
minute or two. Inserting an invlpg instruction immediately before the
call appears to resolve the issue (i.e. the tests run for ~1 hour
without observing the issue).

Architecturally however, this invlpg should have no effect.  I think
there is some race condition propagating TLB records to the L1 iTLB if
it is already present in the L1 dTLB.

At the first time I discovered this, I checked the NDA Specification
Update for the processor, and didn't find any published errata which
matched the symptoms.

~Andrew

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

Re: [Xen-devel] [linux-4.1 test] 101715: regressions - FAIL

[Ian Jackson]

osstest service owner writes ("[linux-4.1 test] 101715: regressions - FAIL"):
> flight 101715 linux-4.1 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/101715/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 
> 101401
>  test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 
> 101401
>  test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 
> 101401
>  test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail in 101687 
> REGR. vs. 101401
> 
...
> version targeted for testing:
>  linux9ca365c0c8bdd8552ec064f0e696600cf7ea66dd
> baseline version:
>  linux91473db3a3257eacead8f4d84cf4bc96c447193f

Force pushed.

Ian.

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

[Xen-devel] Xen on Qualcomm

[Suresh Kanzariya]

Hi Team,

https://www.xenproject.org/component/allvideoshare/video/samsung-nexus10-dual-xen-androud.html

The above link stats that "Samsung will discuss the issues encountered
using Xen on a mobile device in this demanding use-case, and how the
changes for Xen for mobile can be contributed into the community."

So Just wanted to know where can I find that list of challenges !!

I am sure it will be not a straight forward documents or list but any
format will be fine as I am trying to port xen on Qualcomm plataform.

Please Help !!.

-Suresh
-- 
Regards,
Suresh
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Test Xen 4.8 RC4 not stable 27.10.16

[Wei Liu]

On Thu, Oct 27, 2016 at 11:01:50PM +0100, Juergen Schinker wrote:
> 
> 
> - On 27 Oct, 2016, at 09:53, Wei Liu wei.l...@citrix.com wrote:
> 
> > For the second part, xenstored.pid normally would be stored under
> > /var/run, which should be cleared whenever the system is booted [0].
> 
> I know but the /var/run/xenstored.pid  stays but anyway
> 

Please check the content of that file and see if there is really such
process in your system.

It is possible that some other init scripts are interfering with
systemd. I don't know.

> RC4 is not so stable - I have random freezes 
> 


Please try to extract guest / hypervisor log that contains text of
interest.

Wei.

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