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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

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

version targeted for testing:
 linuxa232591ba289a1a397e0005c9f276a126c1bc1b1
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  646 days
Failing since 59348  2015-07-10 04:24:05 Z  644 days  388 attempts
Testing same since   107443  2017-04-14 04:31:31 Z0 days2 attempts


8159 people touched revisions under test,
not listing them all

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

[Xen-devel] [linux-next test] 107449: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

[Stefano Stabellini]

On Fri, 14 Apr 2017, Stefano Stabellini wrote:
> Hi Paul,
> 
> The following commit in my qemu "next" branch breaks the build on arm
> and arm64:
> 
> commit 670271647ad15e9d937ced7a72c892349c709216
> Author: Paul Durrant 
> Date:   Tue Mar 7 10:55:34 2017 +
> 
> xen: use libxendevicemodel when available
> 
> See the appended build log. Sorry for not realizing it sooner.

As I imagined, this bug is easy to solve. It is reproducible on x86 too,
if you pass -DXC_WANT_COMPAT_DEVICEMODEL_API=1 to configure and
forcefully disable Xen 4.9 detection in the configure script.

If QEMU detects xen_ctrl_version = 480, the build will fail against Xen
4.9, even when -DXC_WANT_COMPAT_DEVICEMODEL_API=1 is specified.

The appended patch solves the problem. However, Xen 4.9 detection and
compilation remain broken.

---

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 274accc..b1f5f53 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -9,7 +9,6 @@
 #undef XC_WANT_COMPAT_EVTCHN_API
 #undef XC_WANT_COMPAT_GNTTAB_API
 #undef XC_WANT_COMPAT_MAP_FOREIGN_API
-#undef XC_WANT_COMPAT_DEVICEMODEL_API

 #include 
 #include 
@@ -154,6 +153,7 @@ static inline int xendevicemodel_set_mem_type(

 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 490 */

+#undef XC_WANT_COMPAT_DEVICEMODEL_API
 #include 

 #endif


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

[Xen-devel] [linux-arm-xen test] 107450: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 107450 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107450/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   6 xen-boot fail REGR. vs. 107176

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken in 107296 pass in 107450
 test-armhf-armhf-xl-multivcpu  3 host-install(3) broken pass in 107441
 test-armhf-armhf-xl-multivcpu  6 xen-bootfail in 107371 pass in 107296
 test-armhf-armhf-xl-credit2   6 xen-boot   fail pass in 107296
 test-armhf-armhf-libvirt-xsm  6 xen-boot   fail pass in 107296
 test-armhf-armhf-libvirt-raw  6 xen-boot   fail pass in 107296
 test-armhf-armhf-xl-xsm   6 xen-boot   fail pass in 107296
 test-armhf-armhf-libvirt  6 xen-boot   fail pass in 107296
 test-armhf-armhf-xl   6 xen-boot   fail pass in 107296
 test-armhf-armhf-xl-vhd   6 xen-boot   fail pass in 107296
 test-armhf-armhf-xl-rtds  6 xen-boot   fail pass in 107371

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail in 107296 like 
107176
 test-armhf-armhf-libvirt 13 saverestore-support-check fail in 107296 like 
107176

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2 12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 107296 never 
pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail in 107296 never 
pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail in 107296 
never pass
 test-armhf-armhf-xl 12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl 13 saverestore-support-check fail in 107296 never pass
 test-armhf-armhf-libvirt12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-xsm 13 saverestore-support-check fail in 107296 never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail in 107296 never 
pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 107296 never pass
 test-armhf-armhf-xl-vhd 11 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-vhd 12 saverestore-support-check fail in 107296 never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 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-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux9ceff47026d8db55dc9f133a40ae4042c71fcb13
baseline version:
 linux6878b2fa7229c9208a02d45f280c71389cba0617

Last test of basis   107176  2017-04-04 09:44:38 Z   10 days
Failing since107256  2017-04-07 00:24:43 Z7 days8 attempts
Testing same since   107296  2017-04-08 07:12:44 Z6 days7 attempts


10162 people touched revisions under test,
not listing them all

jobs:
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-arm64  pass
 build-armhf  

[Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

[Stefano Stabellini]

Hi Paul,

The following commit in my qemu "next" branch breaks the build on arm
and arm64:

commit 670271647ad15e9d937ced7a72c892349c709216
Author: Paul Durrant 
Date:   Tue Mar 7 10:55:34 2017 +

xen: use libxendevicemodel when available

See the appended build log. Sorry for not realizing it sooner.

Please note that up to now we have been unable to disentangle the PV
machine from the i386 emulator in QEMU.  Thus, on arm and arm64 we build
qemu with --target-list=i386-softmmu as we do on x86. Of course, the
xenfv machine cannot work on arm. Only the xenpv machine can be used.
However, the xenfv machine is still included in the build.

This means that we cannot break the xenfv machine build on arm and arm64.


Going into details, "xen: use libxendevicemodel when available" breaks
the build on arm and arm64 even with -DXC_WANT_COMPAT_DEVICEMODEL_API=1.
It breaks 4.8 compatibility which is a regression from QEMU's point of
view.


Why 4.8 compatibility? Because the previous commit:

commit 2a15d804eb0e4f8bc25738b6aec30a0142d5d293
Author: Paul Durrant 
Date:   Tue Mar 7 10:55:33 2017 +

configure: detect presence of libxendevicemodel

doesn't work properly on arm: Xen 4.9 is not detected. However, that is
not a regression per se.


We cannot break the QEMU build against Xen 4.9 with
-DXC_WANT_COMPAT_DEVICEMODEL_API=1 or older releases. That has to work,
but I guess it won't be too difficult to fix.

The difficulty is how to introduce proper Xen 4.9 and libxendevicemodel
support in QEMU. We either need to fix libxendevicemodel on arm
(although obviously is never going to be actually used at run time, but
it is necessary for the build), or we need to disentangle the xenpv
machine build from the xenfv machine build in QEMU. I prefer the latter
approach, of course.

I haven't dug into what is the problem with libxendevicemodel on arm.
Needless to say, if there is an issue on the Xen side, it might impact
the Xen 4.9 release.


For your information, you can download a free (as in beer) arm64
software model from ARM called "Foundation Model", see the Xen wiki for
instructions:

https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/FastModels

In addition, I think you can purchase access to ARM64 servers from
packet.net.


Thanks,

Stefano


---

In file included from /root/qemu/include/hw/xen/xen_backend.h:4:0,
 from hw/block/xen_disk.c:27:
/root/qemu/include/hw/xen/xen_common.h: In function 
‘xendevicemodel_create_ioreq_server’:
/root/qemu/include/hw/xen/xen_common.h:46:12: error: implicit declaration of 
function ‘xc_hvm_create_ioreq_server’ [-Werror=implicit-function-declaration]
 return xc_hvm_create_ioreq_server(dmod, domid, handle_bufioreq,
^
/root/qemu/include/hw/xen/xen_common.h:46:5: error: nested extern declaration 
of ‘xc_hvm_create_ioreq_server’ [-Werror=nested-externs]
 return xc_hvm_create_ioreq_server(dmod, domid, handle_bufioreq,
 ^
/root/qemu/include/hw/xen/xen_common.h: In function 
‘xendevicemodel_get_ioreq_server_info’:
/root/qemu/include/hw/xen/xen_common.h:55:12: error: implicit declaration of 
function ‘xc_hvm_get_ioreq_server_info’ [-Werror=implicit-function-declaration]
 return xc_hvm_get_ioreq_server_info(dmod, domid, id, ioreq_pfn,
^
/root/qemu/include/hw/xen/xen_common.h:55:5: error: nested extern declaration 
of ‘xc_hvm_get_ioreq_server_info’ [-Werror=nested-externs]
 return xc_hvm_get_ioreq_server_info(dmod, domid, id, ioreq_pfn,
 ^
/root/qemu/include/hw/xen/xen_common.h: In function 
‘xendevicemodel_map_io_range_to_ioreq_server’:
/root/qemu/include/hw/xen/xen_common.h:63:12: error: implicit declaration of 
function ‘xc_hvm_map_io_range_to_ioreq_server’ 
[-Werror=implicit-function-declaration]
 return xc_hvm_map_io_range_to_ioreq_server(dmod, domid, id, is_mmio,
^
/root/qemu/include/hw/xen/xen_common.h:63:5: error: nested extern declaration 
of ‘xc_hvm_map_io_range_to_ioreq_server’ [-Werror=nested-externs]
 return xc_hvm_map_io_range_to_ioreq_server(dmod, domid, id, is_mmio,
 ^
/root/qemu/include/hw/xen/xen_common.h: In function 
‘xendevicemodel_unmap_io_range_from_ioreq_server’:
/root/qemu/include/hw/xen/xen_common.h:71:12: error: implicit declaration of 
function ‘xc_hvm_unmap_io_range_from_ioreq_server’ 
[-Werror=implicit-function-declaration]
 return xc_hvm_unmap_io_range_from_ioreq_server(dmod, domid, id, is_mmio,
^
/root/qemu/include/hw/xen/xen_common.h:71:5: error: nested extern declaration 
of ‘xc_hvm_unmap_io_range_from_ioreq_server’ [-Werror=nested-externs]
 return xc_hvm_unmap_io_range_from_ioreq_server(dmod, domid, id, is_mmio,
 ^
/root/qemu/include/hw/xen/xen_common.h: In function 
‘xendevicemodel_map_pcidev_to_ioreq_server’:
/root/qemu/include/hw/xen/xen_common.h:79:12: error: implicit declaration of 
function ‘xc_hvm_map_pcidev_to_ioreq_server’ 

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

[Daniel Kiper]

On Fri, Apr 14, 2017 at 06:53:36PM +0200, Petr Tesarik wrote:
> On Tue, 11 Apr 2017 19:20:08 +0200
> Daniel Kiper  wrote:
> > On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
> >[...]
> > > Tested-by: Petr Tesarik 
> > >
> > > I copied the complete /proc/vmcore to a directory on disk. Exactly
> > > as expected, crash works both without the patch and with the patch, as
> > > it does not use VMCOREINFO at all (instead, crash obtains the
> > > information from kernel debuginfo directly).
> >
> > Thanks for doing the tests. I suppose that you have tested HVM guests.
>
> Not really. I crashed Dom0, which is in turn sent to the hypervisor, so
> the result is a complete host dump, including Xen hypervisor data and
> all domains.

OK.

> > IIRC, PV guests are not supported by crash right now due to p2m VMA
> > mapping. At least it was an issue some time ago. Is it still valid?
>
> Yes, this is correct. I tested this behaviour a few weeks ago.

Thanks for update.

> > Anyway, one guy in Oracle works on fix for that issue and I do review.
> > We are going to post it in 2-3 weeks.
>
> All right. FYI I do not plan to put much effort into it, as my focus has

OK.

> shifted towards libkdumpfile (https://github.com/ptesarik/libkdumpfile),
> and this library can open PV guest dump files without any issues.

Great! AIUI, it reminds my idea to make such think. However, I have not
have time to make it happen. Is it based on makedumpfile or written from
scratch? Do you plan support for Linux kernel dumps and/or Xen ones?

Daniel

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

[Xen-devel] [xen-4.4-testing test] 107448: regressions - FAIL

[osstest service owner]

flight 107448 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107448/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 107422 
REGR. vs. 106822

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl 4 host-ping-check-native fail in 107422 pass in 107448
 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 107422 pass in 107448
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 
107422 pass in 107448
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install fail pass in 107422
 test-armhf-armhf-xl   6 xen-boot   fail pass in 107439
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail pass in 107439
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 107439

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 107439 blocked in 
106822
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pae-invlpg~shadow fail like 106822
 test-xtf-amd64-amd64-3   44 xtf/test-hvm64-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-2   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-1   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-4   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-5   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-3   54 leak-check/check fail  like 106822
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106822
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106822
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106822

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 12 migrate-support-check fail in 107439 never pass
 test-armhf-armhf-xl 13 saverestore-support-check fail in 107439 never pass
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-3   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 

Re: [Xen-devel] EFI + tboot + Xen

[Daniel Kiper]

On Fri, Apr 14, 2017 at 04:17:54PM +0100, Andrew Cooper wrote:
> On 14/04/2017 15:54, Daniel Kiper wrote:
> > Hey,
> >
> > Has anybody tried to run EFI + tboot + Xen?
> > I have a feeling that it does not work because
> > tboot shuts down EFI boot services. However,
> > even if it works then efibootmgr is unusable
> > due to lack of EFI runtime services. Do we care?
> > Is it possible to make it work with full blown
> > EFI infrastructure available for Xen?
>
> Judging by
> http://hg.code.sf.net/p/tboot/code/file/9352e6391332/tboot/common/boot.S#l83
> it will be grub exiting boot services.  tboot needs rather more
> multiboot2 knowledge before it could participate in a hand-off to Xen
> while keeping boot services active.

Sure, it is not a problem. However, I was told that it was (not) done
deliberately because we cannot trust EFI due to lack of its measurement.
I am not sure it is true or not. I though that somebody played with tboot
and Xen and has some knowledge in that area. Anyway, I will investigate
this further. However, any knowledge sharing is greatly appreciated.

Daniel

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

Re: [Xen-devel] [PATCH] tests/xen-access: Added vm_event emulation tests

[Tamas K Lengyel]

On Fri, Apr 14, 2017 at 1:03 PM, Razvan Cojocaru 
wrote:

> On 04/14/2017 09:08 PM, Tamas K Lengyel wrote:
> >
> >
> > On Thu, Apr 13, 2017 at 4:20 AM, Razvan Cojocaru
> > > wrote:
> >
> > On 04/12/2017 08:11 PM, Tamas K Lengyel wrote:
> > >
> > >
> > > On Mon, Apr 10, 2017 at 3:44 AM, Razvan Cojocaru
> > > +emulate = 1;
> > > +memaccess = 1;
> > > +}
> > >  #if defined(__i386__) || defined(__x86_64__)
> > >  else if ( !strcmp(argv[0], "breakpoint") )
> > >  {
> > > @@ -536,7 +551,7 @@ int main(int argc, char *argv[])
> > >  }
> > >
> > >  rc = xc_set_mem_access(xch, domain_id, default_access,
> > > START_PFN,
> > > -   (xenaccess->max_gpfn -
> START_PFN) );
> > > +   emulate ? 1000 :
> > > (xenaccess->max_gpfn - START_PFN));
> > >
> > >
> > > Why only 1000? What if the domain has less then 1000?
> >
> > Because it will kill the guest to emulate everything, and the
> emulator
> > still can't handle all instructions (this is easy to see by using all
> > the guest's pages and looking at the output of xl dmesg with
> loglvl=all
> > guest_loglvl=all on the Xen command line).
> >
> >
> > So what's the guarantee that the emulator will work if you only do it
> > only up to the first 1000 pages? Seems totally arbitrary to me. If the
> > emulator can't handle all instructions then you would have to check that
> > the instruction for which you are returning the emulate flag is in the
> > list of instruction that can be handled.. Can such a list be derived
> > right now?
>
> If an instruction can't be emulated it will be shown as such in the ring
> buffer used by xl dmesg. Speaking of that, I'd like to, at some point,
> send a patch that sends a vm_event saying that emulation failed to
> userspace when that is the case, to give it a chance to do something
> else (for example use altp2m, or lift the page restrictions).
>

I think that would be a much needed addition to make this system more
robust.


>
> We can also probably go through the emulator code and build an exact
> list of all the officially supported instructions, but I believe that
> that would have to be manual work - I am not aware of a tool to extract
> them or a header file that lists them in some structure. I'd love to be
> wrong about this.
>
> As for your question, there's no guarantee that the emulator will
> work,obut that's not why I chose 1000. I chose that number because the
> application will get less EPT events, and the guest will not be bogged
> down by handling them. But in my experiments it's also less likely to
> hit unhandleable instructions in the first 1000 pages since those are
> usually used by the guest kernel, drivers, and so on, and are less
> likely to cause problems.
>
> In any case, I don't mind dropping the 1000 pages limit - I can always
> build a custom xen-access when I need it.
>

I don't mind setting it only for a 1000 in the test program, just wanted to
understand rationale behind it. I think a comment in the program explaining
what has been discussed here would also be helpful.

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

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

Last test of basis71193  2017-04-14 08:46:43 Z0 days
Testing same since71194  2017-04-14 16:48:53 Z0 days1 attempts


People who touched revisions under test:
  Hao Wu 
  Long Qin 
  Qin Long 
  Star Zeng 

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.


commit 0c9fc4b1679946f59efa1aaf11e2e9e1acab303d
Author: Long Qin 
Date:   Fri Apr 14 16:31:51 2017 +0800

CryptoPkg: Correct some minor issues in function comments

Correct some minor comment issues in BaseCryptLib.h and
CryptPkcs7Verify.c, including:
  - missed "out" in parameter property for ARC4 interfaces;
  - Wrong Comment tail in Pkcs7GetAttachedContent function

Cc: Ting Ye 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
Reviewed-by: Ye Ting 

commit 8b17683a27cfef7e70008dfccbc17a358ae33df1
Author: Star Zeng 
Date:   Tue Apr 11 09:55:51 2017 +0800

MdeModulePkg CapsuleApp: Add directory support

Current CapsuleApp only supports input/output file from rootdirectory.
If the CapsuleApp and related file are put into subdirectory,
below message will be shown when running the CapsuleApp in shell.

"CapsuleApp: capsule image (Capsule image file name) is not found."

This patch is to add directory support for CapsuleApp
by using shell protocol.

Cc: Jiewen Yao 
Cc: Feng Tian 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit 9c0e4db3db8d102812ca57f6225290c7ba079ad8
Author: Hao Wu 
Date:   Thu Mar 23 10:45:44 2017 +0800

IntelFrameworkPkg/UefiLib: Avoid mis-calculate of graphic console size

The commit adds check in function InternalPrintGraphic() to ensure that
the expression:

Blt->Width * Blt->Height * sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL)

will not overflow in the UINTN range.

The commit also adds an explicit UINT32 type cast for 'Blt->Width' to
avoid possible overflow in the int range for:

Blt->Width * Blt->Height

Since both Blt->Width and Blt->Height are of type UINT16. They will be
promoted to int (signed) first, and then perform the multiplication
operation. If the result of multiplication between Blt->Width and
Blt->Height exceeds the range of type int, a potential incorrect size will
be passed into function AllocateZeroPool().

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Liming Gao 

commit 458cd568b64a0e4159f85a31809e55657db23792
Author: Hao Wu 
Date:   Thu Mar 23 10:16:23 2017 +0800

MdePkg/UefiLib: Avoid mis-calculate of graphic console size

The commit adds check in function InternalPrintGraphic() to ensure that
the expression:

Blt->Width * Blt->Height * sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL)

will not overflow in the UINTN range.

The commit also adds an explicit UINT32 type cast for 'Blt->Width' to
avoid possible overflow in the int range for:

Blt->Width * Blt->Height
   

Re: [Xen-devel] [PATCH] tests/xen-access: Added vm_event emulation tests

[Razvan Cojocaru]

On 04/14/2017 09:08 PM, Tamas K Lengyel wrote:
> 
> 
> On Thu, Apr 13, 2017 at 4:20 AM, Razvan Cojocaru
> > wrote:
> 
> On 04/12/2017 08:11 PM, Tamas K Lengyel wrote:
> >
> >
> > On Mon, Apr 10, 2017 at 3:44 AM, Razvan Cojocaru
> > +emulate = 1;
> > +memaccess = 1;
> > +}
> >  #if defined(__i386__) || defined(__x86_64__)
> >  else if ( !strcmp(argv[0], "breakpoint") )
> >  {
> > @@ -536,7 +551,7 @@ int main(int argc, char *argv[])
> >  }
> >
> >  rc = xc_set_mem_access(xch, domain_id, default_access,
> > START_PFN,
> > -   (xenaccess->max_gpfn - START_PFN) );
> > +   emulate ? 1000 :
> > (xenaccess->max_gpfn - START_PFN));
> >
> >
> > Why only 1000? What if the domain has less then 1000?
> 
> Because it will kill the guest to emulate everything, and the emulator
> still can't handle all instructions (this is easy to see by using all
> the guest's pages and looking at the output of xl dmesg with loglvl=all
> guest_loglvl=all on the Xen command line).
> 
> 
> So what's the guarantee that the emulator will work if you only do it
> only up to the first 1000 pages? Seems totally arbitrary to me. If the
> emulator can't handle all instructions then you would have to check that
> the instruction for which you are returning the emulate flag is in the
> list of instruction that can be handled.. Can such a list be derived
> right now?

If an instruction can't be emulated it will be shown as such in the ring
buffer used by xl dmesg. Speaking of that, I'd like to, at some point,
send a patch that sends a vm_event saying that emulation failed to
userspace when that is the case, to give it a chance to do something
else (for example use altp2m, or lift the page restrictions).

We can also probably go through the emulator code and build an exact
list of all the officially supported instructions, but I believe that
that would have to be manual work - I am not aware of a tool to extract
them or a header file that lists them in some structure. I'd love to be
wrong about this.

As for your question, there's no guarantee that the emulator will
work,obut that's not why I chose 1000. I chose that number because the
application will get less EPT events, and the guest will not be bogged
down by handling them. But in my experiments it's also less likely to
hit unhandleable instructions in the first 1000 pages since those are
usually used by the guest kernel, drivers, and so on, and are less
likely to cause problems.

In any case, I don't mind dropping the 1000 pages limit - I can always
build a custom xen-access when I need it.


Thanks,
Razvan

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  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  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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  e412c03be25dee8202a440b973561afd8ab6d868
baseline version:
 xen  17cd6621688bce9972d924264fd7aba44c31

Last test of basis   107397  2017-04-12 13:22:43 Z2 days
Failing since107420  2017-04-13 06:29:23 Z1 days3 attempts
Testing same since   107446  2017-04-14 07:31:34 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chao Gao 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Luwei Kang 
  Praveen Kumar 
  Roger Pau Monné 
  Tim Deegan 
  Wei Liu 

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

[Xen-devel] Delivery Status Notification (Delay)

[f4da1594]

** Delivery incomplete **

There was a temporary problem delivering your message to 
curtiskwo...@gmail.com. Gmail will retry for 21 more hours. You'll be notified 
if the delivery fails permanently.



The response was:

Receive rate too high
Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2YAMHECCJDLIBAYAWYAKIAZAQHSMCCWMBLIA4UANQUEIGCIMBKMAZUZ4AAEAACA===@opayq.com
Arrival-Date: Wed, 12 Apr 2017 09:02:31 -0700 (PDT)
X-Original-Message-ID: 

Final-Recipient: rfc822; curtiskwong9@gmail.com
Action: delayed
Status: 4.0.0
Diagnostic-Code: smtp; Receive rate too high
Last-Attempt-Date: Fri, 14 Apr 2017 11:17:05 -0700 (PDT)
Will-Retry-Until: Sat, 15 Apr 2017 09:02:31 -0700 (PDT)


[Xen-changelog] [xen master] tools/insn-fuzz: Avoid making use of
Description: Message attachment
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH v3 2/2] xen: credit2: provide custom option to create

[Praveen Kumar]

On Fri, Mar 31, 2017 at 10:32:09AM +0200, Dario Faggioli wrote:
> On Fri, 2017-03-31 at 00:58 +0530, Praveen Kumar wrote:
> > The patch introduces a new command line option 'custom' that when 
> used will
> > create runqueue based upon the pCPU subset provide during bootup.
> > 
> "introduces a new, very flexible, way of arranging runqueues in
> Credit2. It allows to specify, explicitly and precisely, what pCPUs
> should belong to which runqueue"
> 
> Or something like this.
> 
> It's great that you've got the code working. I have some comments,
> though, on how it actually looks like.
> 
> > Signed-off-by: Praveen Kumar 
> > ---
> 
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -525,7 +525,7 @@ also slow in responding to load changes.
> >  The default value of `1 sec` is rather long.
> >  
> >  ### credit2\_runqueue
> > -> `= cpu | core | socket | node | all`
> > +> `= cpu | core | socket | node | all | custom`
> >  
> Err... but this is not really correct, right?
> 
> I mean, it's not that the user should use the word 'custom' here.
> 
> You probably want to use something like , and then define what
> that means below.
>  
> > @@ -543,6 +543,12 @@ Available alternatives, with their meaning, are:
> >  * `node`: one runqueue per each NUMA node of the host;
> >  * `all`: just one runqueue shared by all the logical pCPUs of
> >   the host
> > +* `custom`: one runqueue per subset. Example:
> > +credit2_runqueue=[[0,1,4,5][2,3,6,7][8,9,12,13][10,11,14
> > ,15]]
> >
> Maybe just use 2 (or at most 3) pCPUs per runqueue in the example. It'd
> make the line shorter and easier to read and understand.
> 

Sure, Will take care of the same.

> > +- pCPUs 0, 1, 4 and 5 belong to runqueue 0
> > +- pCPUs 2, 3, 6 and 7 belong to runqueue 1
> > +- pCPUs 8, 9, 12 and 13 belong to runqueue 2
> > +- pCPUs 10, 11, 14 and 15 belong to runqueue 3
> 
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @@ -330,18 +339,60 @@ integer_param("credit2_balance_over",
> > opt_overload_balance_tolerance);
> >  #define OPT_RUNQUEUE_SOCKET 2
> >  #define OPT_RUNQUEUE_NODE   3
> >  #define OPT_RUNQUEUE_ALL4
> > +#define OPT_RUNQUEUE_CUSTOM 5
> >  static const char *const opt_runqueue_str[] = {
> >  [OPT_RUNQUEUE_CPU] = "cpu",
> >  [OPT_RUNQUEUE_CORE] = "core",
> >  [OPT_RUNQUEUE_SOCKET] = "socket",
> >  [OPT_RUNQUEUE_NODE] = "node",
> > -[OPT_RUNQUEUE_ALL] = "all"
> > +[OPT_RUNQUEUE_ALL] = "all",
> > +[OPT_RUNQUEUE_CUSTOM] = "custom"
> >  };
> >  static int __read_mostly opt_runqueue = OPT_RUNQUEUE_SOCKET;
> >  
> > +static int __read_mostly custom_cpu_runqueue[NR_CPUS];
> > +
> I think this can be nr_cpu_ids (and be allocated dynamically during
> parsing).
> 

Had to use NR_CPUS to make compiler happy with "error:Variably modified 'types'
at file scope".

> > +#define GETTOKEN( token, len, start, end )   \
> > +{\
> > +char _tmp[len+1];\
> > +int _i;  \
> > +safe_strcpy(_tmp, start);\
> > +_tmp[len] = '\0';\
> > +for ( _i = 0; _tmp[_i] != '\0'; _i++ )   \
> > +token = ( ( token * 10 ) + ( _tmp[_i] - '0' ) ); \
> > +}
> > +
> If you really need this, make it 'static inline', as you do for other
> functions.
> 
> As a matter of fact, I don't think you need it, as, for instance, we do
> have simple_strtoul() (and some others). :-)
> 

True, will be replacing this with simple_strtoul()

> > +static inline int trim(const char *c, char *t, char elem)
> > +{
> > +int l = strlen(c);
> > +const char *x = c ;
> > +int i = 0;
> > +if ( !c || !t )
> > +return -1;
> > +while ( *x != '\0' && i < l )
> > +{
> > +if ( *x != elem )
> > +t[i++] = *x;
> > +x++;
> > +}
> > +t[i] = '\0';
> > +return 0;
> > +}
> > +
> Again, why we need this? Can't we just deal with invalid characters
> while parsing the string (by, e.g., either skipping them or aborting,
> depending on whether or not they're innocuous)?
> 
> > +static inline int getlen(char *start, char *end)
> > +{
> > +if ( ( start ) && ( end ) && ( end > start ) )
> > +return end-start;
> > +else
> > +return -1;
> > +}
> > +
> >
> Same.
> 
> >  static void parse_credit2_runqueue(const char *s)
> >  {
> >  unsigned int i;
> > +const char *s_end = NULL;
> > +char m[strlen(s)];
> > +char *_s = NULL;
> >  
> No '_' prefixed variable names, please. :-)
> 
> Also, what's m for?
> 
> > @@ -351,7 +402,115 @@ static void parse_credit2_runqueue(const char
> > *s)
> >  return;
> >  }
> >  }
> > +/*
> > + * At this 

Re: [Xen-devel] [PATCH] tests/xen-access: Added vm_event emulation tests

[Tamas K Lengyel]

On Thu, Apr 13, 2017 at 4:20 AM, Razvan Cojocaru 
wrote:

> On 04/12/2017 08:11 PM, Tamas K Lengyel wrote:
> >
> >
> > On Mon, Apr 10, 2017 at 3:44 AM, Razvan Cojocaru
> > > wrote:
> >
> > This patch adds support for testing instruction emulation when
> > required by the vm_event reply sent for MEM_ACCESS events. To this
> > end, it adds the "emulate_write" and "emulate_exec" parameters
> > that behave like the old "write" and "exec" parameters, except
> > instead of allowing writes / executes for a hit page, they emulate
> > the trigger instruction. The new parameters don't mark all of the
> > guest's pages, instead they stop at the arbitrary low limit of
> > the first 1000 pages - otherwise the guest would slow to a crawl.
> > Since the emulator is still incomplete and has trouble with
> > emulating competing writes in SMP scenarios, the new tests are
> > only meant for debugging issues.
> >
> > Signed-off-by: Razvan Cojocaru  > >
> > ---
> >  tools/tests/xen-access/xen-access.c | 38
> > -
> >  1 file changed, 29 insertions(+), 9 deletions(-)
> >
> > diff --git a/tools/tests/xen-access/xen-access.c
> > b/tools/tests/xen-access/xen-access.c
> > index ff4d289..0ba2e45 100644
> > --- a/tools/tests/xen-access/xen-access.c
> > +++ b/tools/tests/xen-access/xen-access.c
> > @@ -335,7 +335,7 @@ static void put_response(vm_event_t *vm_event,
> > vm_event_response_t *rsp)
> >
> >  void usage(char* progname)
> >  {
> > -fprintf(stderr, "Usage: %s [-m]  write|exec",
> progname);
> > +fprintf(stderr, "Usage: %s [-m] 
> > write|exec|emulate_write|emulate_exec", progname);
> >
> >
> > These options are only for x86, so they need to be moved into the #if
> > block below.
>
> Sure.
>
> >  #if defined(__i386__) || defined(__x86_64__)
> >  fprintf(stderr,
> > "|breakpoint|altp2m_write|altp2m_exec|debug|cpuid|desc_access");
> >  #elif defined(__arm__) || defined(__aarch64__)
> > @@ -369,6 +369,7 @@ int main(int argc, char *argv[])
> >  int debug = 0;
> >  int cpuid = 0;
> >  int desc_access = 0;
> > +int emulate = 0;
> >  uint16_t altp2m_view_id = 0;
> >
> >  char* progname = argv[0];
> > @@ -404,12 +405,26 @@ int main(int argc, char *argv[])
> >  after_first_access = XENMEM_access_rwx;
> >  memaccess = 1;
> >  }
> > +else if ( !strcmp(argv[0], "emulate_write") )
> > +{
> > +default_access = XENMEM_access_rx;
> > +after_first_access = XENMEM_access_rwx;
> >
> >
> > Setting after_first_access not needed.
>
> True. I got carried away with the copy-paste.
>
> > +emulate = 1;
> > +memaccess = 1;
> > +}
> >  else if ( !strcmp(argv[0], "exec") )
> >  {
> >  default_access = XENMEM_access_rw;
> >  after_first_access = XENMEM_access_rwx;
> >  memaccess = 1;
> >  }
> > +else if ( !strcmp(argv[0], "emulate_exec") )
> > +{
> > +default_access = XENMEM_access_rw;
> > +after_first_access = XENMEM_access_rwx;
> >
> >
> > Setting after_first_access not needed.
>
> Also true.
>
> > +emulate = 1;
> > +memaccess = 1;
> > +}
> >  #if defined(__i386__) || defined(__x86_64__)
> >  else if ( !strcmp(argv[0], "breakpoint") )
> >  {
> > @@ -536,7 +551,7 @@ int main(int argc, char *argv[])
> >  }
> >
> >  rc = xc_set_mem_access(xch, domain_id, default_access,
> > START_PFN,
> > -   (xenaccess->max_gpfn - START_PFN) );
> > +   emulate ? 1000 :
> > (xenaccess->max_gpfn - START_PFN));
> >
> >
> > Why only 1000? What if the domain has less then 1000?
>
> Because it will kill the guest to emulate everything, and the emulator
> still can't handle all instructions (this is easy to see by using all
> the guest's pages and looking at the output of xl dmesg with loglvl=all
> guest_loglvl=all on the Xen command line).
>

So what's the guarantee that the emulator will work if you only do it only
up to the first 1000 pages? Seems totally arbitrary to me. If the emulator
can't handle all instructions then you would have to check that the
instruction for which you are returning the emulate flag is in the list of
instruction that can be handled.. Can such a list be derived right now?

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

Re: [Xen-devel] [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend

[Stefano Stabellini]

On Fri, 14 Apr 2017, Juergen Gross wrote:
> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> > On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
> >> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> >>> From: Oleksandr Andrushchenko 
> >>>
> >>> For some use cases when Xen framebuffer/input backend
> >>> is not a part of Qemu it is required to disable it,
> >>> because of conflicting access to input/display devices.
> >>> Introduce additional configuration option for explicit
> >>> input/display control.
> >> In these cases when you don't want xenfb, why don't you just remove
> >> "vfb" from the xl config file? QEMU only starts the xenfb backend when
> >> requested by the toolstack.
> >>
> >> Is it because you have an alternative xenfb backend? If so, is it really
> >> fully xenfb compatible, or is it a different protocol? If it is a
> >> different protocol, I suggest you rename your frontend/backend PV device
> >> name to something different from "vfb".
> >>
> > Well, offending part is vkbd actually (for multi-touch
> > we run our own user-space backend which supports
> > kbd/ptr/mtouch), but vfb and vkbd is the same backend
> > in QEMU. So, I am ok for vfb, but just want vkbd off
> > So, there are 2 options:
> > 1. At compile time remove vkbd and still allow vfb
> > 2. Remove xenfb completely, if acceptable (this is my case)
> 
> What about adding a Xenstore entry for backend type and let qemu test
> for it being not present or containing "qemu"?

That is what we do for the console, using the xenstore node "type". QEMU
is "ioemu" while xenconsoled is "xenconsoled". Weirdly, instead of a
backend node, it is a read-only frontend node, see
tools/libxl/libxl_console.c:libxl__device_console_add.

Oleksandr, I am sorry to feature-creep this simple patch, but I think
Juergen is right. But we cannot do it just for one protocol. We need to
introduce a generic way to enable/disable backends in QEMU. Using a
xenstore node is OK.

We could do exactly the same as the PV console, thus "type" = "ioemu",
read-only, under the frontend xenstore directory. Or we could introduce
new nodes. I would probably go for "backend-type" = "qemu" under the
backend xenstore directory. I don't have a strong opinion about this. In
the example below I'll use the PV console convention.

For starters:

* libxl needs to write the "type" node to xenstore for *all* protocols.
  The "type" is not yet configurable.
* qemu reads them for all backends, proceeds if "type" = "ioemu"

These should be two simple patches. Stage 2:

* we add options in the xl config file to configure any backend, libxl
  set "type" accordingly (Maybe not *any*, but vif, vkbd, vfb could all
  have a "type". It is OK if you only add an option for vkbd.)
* non-QEMU backends, in particular Linux backends, also read the "type"
  node and proceed if it's "linux"

Does this sound OK to you?

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

[Xen-devel] [linux-4.9 test] 107444: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 107358
 build-amd64-xsm   5 xen-buildfail REGR. vs. 107358

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail pass in 
107437

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail  like 107313
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358

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-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-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
 test-amd64-i386-libvirt-xsm 12 migrate-support-check fail in 107437 never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail in 107437 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 107437 never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 107437 never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail in 107437 never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 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-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linuxcf2586e60ede2217d7f53a0585e27e1cca693600
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z3 days
Testing same since   107396  

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

[Petr Tesarik]

On Tue, 11 Apr 2017 19:20:08 +0200
Daniel Kiper  wrote:

> On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
>[...]
> > Tested-by: Petr Tesarik 
> >
> > I copied the complete /proc/vmcore to a directory on disk. Exactly
> > as expected, crash works both without the patch and with the patch, as
> > it does not use VMCOREINFO at all (instead, crash obtains the
> > information from kernel debuginfo directly).
> 
> Thanks for doing the tests. I suppose that you have tested HVM guests.

Not really. I crashed Dom0, which is in turn sent to the hypervisor, so
the result is a complete host dump, including Xen hypervisor data and
all domains.

> IIRC, PV guests are not supported by crash right now due to p2m VMA
> mapping. At least it was an issue some time ago. Is it still valid?

Yes, this is correct. I tested this behaviour a few weeks ago.

> Anyway, one guy in Oracle works on fix for that issue and I do review.
> We are going to post it in 2-3 weeks.

All right. FYI I do not plan to put much effort into it, as my focus has
shifted towards libkdumpfile (https://github.com/ptesarik/libkdumpfile),
and this library can open PV guest dump files without any issues.

Petr T

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

[Xen-devel] Delivery Status Notification (Delay)

[f4da1594]

** Delivery incomplete **

There was a temporary problem delivering your message to 
curtiskwo...@gmail.com. Gmail will retry for 22 more hours. You'll be notified 
if the delivery fails permanently.



Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2YAMHECCJDLIBAYAWYAKIAZAQHSMCCWMBLIA4UANQUEIGCIMBKMAZUZ4AAEAACA===@opayq.com
Arrival-Date: Wed, 12 Apr 2017 06:21:39 -0700 (PDT)
X-Original-Message-ID: 

Final-Recipient: rfc822; curtiskwong9@gmail.com
Action: delayed
Status: 4.0.0
Last-Attempt-Date: Fri, 14 Apr 2017 08:13:26 -0700 (PDT)
Will-Retry-Until: Sat, 15 Apr 2017 06:21:39 -0700 (PDT)


[Xen-changelog] [xen master] golang/xenlight: Add host-related
Description: Message attachment
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

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

Last test of basis   107440  2017-04-14 03:16:15 Z0 days
Testing same since   107447  2017-04-14 09:11:40 Z0 days1 attempts


People who touched revisions under test:
  Hao Wu 
  Long Qin 
  Qin Long 
  Star Zeng 

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=0c9fc4b1679946f59efa1aaf11e2e9e1acab303d
+ . ./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 
0c9fc4b1679946f59efa1aaf11e2e9e1acab303d
+ branch=ovmf
+ revision=0c9fc4b1679946f59efa1aaf11e2e9e1acab303d
+ . ./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.8-testing
+ '[' x0c9fc4b1679946f59efa1aaf11e2e9e1acab303d = 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] Delivery Status Notification (Delay)

[f4da1594]

** Delivery incomplete **

There was a temporary problem delivering your message to 
curtiskwo...@gmail.com. Gmail will retry for 22 more hours. You'll be notified 
if the delivery fails permanently.



Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2YAMHECCJDLIBAYAWYAKIAZAQHSMCCWMBLIA4UANQUEIGCIMBKMAZUZ4AAEAACA===@opayq.com
Arrival-Date: Wed, 12 Apr 2017 06:38:51 -0700 (PDT)
X-Original-Message-ID: 

Final-Recipient: rfc822; curtiskwong9@gmail.com
Action: delayed
Status: 4.0.0
Last-Attempt-Date: Fri, 14 Apr 2017 08:29:03 -0700 (PDT)
Will-Retry-Until: Sat, 15 Apr 2017 06:38:51 -0700 (PDT)


[Xen-changelog] [xen master] x86/svm: Introduce
Description: Message attachment
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu operations in libxc

[Lan, Tianyu]

Hi Paul:
Sorry for later response.

On 3/31/2017 3:57 AM, Chao Gao wrote:

On Wed, Mar 29, 2017 at 09:08:06AM +, Paul Durrant wrote:

-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
Chao Gao
Sent: 29 March 2017 01:40
To: Wei Liu 
Cc: Lan Tianyu ; Kevin Tian ;
Ian Jackson ; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu
operations in libxc

Tianyu is on vacation this two weeks, so I will try to address
some comments on this series.

On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote:

On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote:

From: Chao Gao 

In previous patch, we introduce a common vIOMMU layer. In our design,
we create/destroy vIOMMU through DMOP interface instead of creating

it

according to a config flag of domain. It makes it is possible
to create vIOMMU in device model or in tool stack.



I've not been following this closely so apologies if this has already been 
asked...

Why would you need to create a vIOMMU instance in an external device model.
Since the toolstack should be in control of the device model configuration why 
would it not know in advance that one was required?


I assume your question is why we don't create a vIOMMU instance via hypercall 
in toolstack.
I think creating in toolstack is also ok and is easier to be reused by pvh.

If Tianyu has no concern about this, will move this part to toolstack.


We can move create/destroy vIOMMU in the tool stack but we still need to 
add such dummy vIOMMU device model in Qemu to pass virtual device's DMA 
request into Xen hypervisor. Qemu is required to use DMOP hypercall and 
tool stack may use domctl hyercall. vIOMMU hypercalls will be divided 
into two part.


Domctl:
create, destroy and query.
DMOP:
vDev's DMA related operations.

Is this OK?



Thanks,
Chao



 Paul


The following toolstack code is to add XEN_DMOP_viommu_XXX syscalls:


Hypercalls, not syscalls.


 - query capabilities of vIOMMU emulated by Xen
 - create vIOMMU in Xen hypervisor with base address, capability
 - destroy vIOMMU specified by viommu_id

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 tools/libs/devicemodel/core.c   | 69

+

 tools/libs/devicemodel/include/xendevicemodel.h | 35 +
 tools/libs/devicemodel/libxendevicemodel.map|  3 ++
 tools/libxc/include/xenctrl_compat.h|  5 ++
 tools/libxc/xc_devicemodel_compat.c | 18 +++
 5 files changed, 130 insertions(+)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index a85cb49..aee1150 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c


Bear in mind that this library is stable, so whatever ends up here can
change in the future.

This is not saying the following code is problematic. It is just a
general FYI.

Obviously the toolstack side is going to follow the hypervisor
interface, so I will do a detailed review later.


Sure. If the hypervisor interface settles down, we can inform you.




+int xendevicemodel_viommu_destroy(
+xendevicemodel_handle *dmod, domid_t dom, uint32_t viommu_id);
 #endif /* __XEN_TOOLS__ */

 #endif /* XENDEVICEMODEL_H */
diff --git a/tools/libs/devicemodel/libxendevicemodel.map

b/tools/libs/devicemodel/libxendevicemodel.map

index 45c773e..c2e0968 100644
--- a/tools/libs/devicemodel/libxendevicemodel.map
+++ b/tools/libs/devicemodel/libxendevicemodel.map
@@ -17,6 +17,9 @@ VERS_1.0 {
xendevicemodel_modified_memory;
xendevicemodel_set_mem_type;
xendevicemodel_inject_event;
+   xendevicemodel_viommu_query_cap;
+   xendevicemodel_viommu_create;
+   xendevicemodel_viommu_destroy;
xendevicemodel_restrict;
xendevicemodel_close;


I suppose this series is going to miss 4.9.

Please add these functions to VERS_1.1.


Yes. We will fix this.




local: *; /* Do not expose anything by default */
diff --git a/tools/libxc/include/xenctrl_compat.h

b/tools/libxc/include/xenctrl_compat.h

index 040e7b2..315c45d 100644
--- a/tools/libxc/include/xenctrl_compat.h
+++ b/tools/libxc/include/xenctrl_compat.h
@@ -164,6 +164,11 @@ int xc_hvm_set_mem_type(
 int xc_hvm_inject_trap(
 xc_interface *xch, domid_t domid, int vcpu, uint8_t vector,
 uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2);
+int xc_viommu_query_cap(xc_interface *xch, domid_t dom, uint64_t

*cap);

+int xc_viommu_create(
+xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t cap,
+uint32_t *viommu_id);
+int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t

viommu_id);


 #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */

diff --git 

[Xen-devel] [PATCH v3 1/9] mm: Separate free page chunk merging into its own routine

[Boris Ostrovsky]

This is needed for subsequent changes to memory scrubbing.

Signed-off-by: Boris Ostrovsky 
---

Changes in v3:
* Simplify merge_and_free_buddy() (and drop can_merge())

 xen/common/page_alloc.c |   74 ++-
 1 files changed, 41 insertions(+), 33 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9e41fb4..6fe55ee 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -919,11 +919,50 @@ static int reserve_offlined_page(struct page_info *head)
 return count;
 }
 
+/* Returns new buddy head. */
+static struct page_info *
+merge_and_free_buddy(struct page_info *pg, unsigned int node,
+ unsigned int zone, unsigned int order)
+{
+ASSERT(spin_is_locked(_lock));
+
+/* Merge chunks as far as possible. */
+while ( order < MAX_ORDER )
+{
+unsigned long mask = 1UL << order;
+struct page_info *buddy;
+
+if ( (page_to_mfn(pg) & mask) )
+buddy = pg - mask; /* Merge with predecessor block. */
+else
+buddy = pg + mask; /* Merge with successor block. */
+
+if ( !mfn_valid(_mfn(page_to_mfn(buddy))) ||
+ !page_state_is(buddy, free) ||
+ (PFN_ORDER(buddy) != order) ||
+ (phys_to_nid(page_to_maddr(buddy)) != node) )
+break;
+
+page_list_del(buddy, (node, zone, order));
+
+/* Adjust current buddy head if we merged backwards. */
+if ( buddy < pg )
+pg = buddy;
+
+order++;
+}
+
+PFN_ORDER(pg) = order;
+page_list_add_tail(pg, (node, zone, order));
+
+return pg;
+}
+
 /* Free 2^@order set of pages. */
 static void free_heap_pages(
 struct page_info *pg, unsigned int order)
 {
-unsigned long mask, mfn = page_to_mfn(pg);
+unsigned long mfn = page_to_mfn(pg);
 unsigned int i, node = phys_to_nid(page_to_maddr(pg)), tainted = 0;
 unsigned int zone = page_to_zone(pg);
 
@@ -970,38 +1009,7 @@ static void free_heap_pages(
 midsize_alloc_zone_pages = max(
 midsize_alloc_zone_pages, total_avail_pages / MIDSIZE_ALLOC_FRAC);
 
-/* Merge chunks as far as possible. */
-while ( order < MAX_ORDER )
-{
-mask = 1UL << order;
-
-if ( (page_to_mfn(pg) & mask) )
-{
-/* Merge with predecessor block? */
-if ( !mfn_valid(_mfn(page_to_mfn(pg-mask))) ||
- !page_state_is(pg-mask, free) ||
- (PFN_ORDER(pg-mask) != order) ||
- (phys_to_nid(page_to_maddr(pg-mask)) != node) )
-break;
-pg -= mask;
-page_list_del(pg, (node, zone, order));
-}
-else
-{
-/* Merge with successor block? */
-if ( !mfn_valid(_mfn(page_to_mfn(pg+mask))) ||
- !page_state_is(pg+mask, free) ||
- (PFN_ORDER(pg+mask) != order) ||
- (phys_to_nid(page_to_maddr(pg+mask)) != node) )
-break;
-page_list_del(pg + mask, (node, zone, order));
-}
-
-order++;
-}
-
-PFN_ORDER(pg) = order;
-page_list_add_tail(pg, (node, zone, order));
+pg = merge_and_free_buddy(pg, node, zone, order);
 
 if ( tainted )
 reserve_offlined_page(pg);
-- 
1.7.1


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

[Xen-devel] [PATCH v3 8/9] mm: Print number of unscrubbed pages in 'H' debug handler

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Wei Liu 
---
 xen/common/page_alloc.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 514a4a1..dd6f248 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2296,6 +2296,13 @@ static void dump_heap(unsigned char key)
 printk("heap[node=%d][zone=%d] -> %lu pages\n",
i, j, avail[i][j]);
 }
+
+for ( i = 0; i < MAX_NUMNODES; i++ )
+{
+if ( !node_need_scrub[i] )
+continue;
+printk("Node %d has %lu unscrubbed pages\n", i, node_need_scrub[i]);
+}
 }
 
 static __init int register_heap_trigger(void)
-- 
1.7.1


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

[Xen-devel] [PATCH v3 3/9] mm: Scrub pages in alloc_heap_pages() if needed

[Boris Ostrovsky]

When allocating pages in alloc_heap_pages() first look for clean pages. If none
is found then retry, take pages marked as unscrubbed and scrub them.

Note that we shouldn't find unscrubbed pages in alloc_heap_pages() yet. However,
this will become possible when we stop scrubbing from free_heap_pages() and
instead do it from idle loop.

Signed-off-by: Boris Ostrovsky 
---
 xen/common/page_alloc.c |   96 ++
 1 files changed, 71 insertions(+), 25 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9dcf6ee..055654d 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -700,34 +700,17 @@ static struct page_info *alloc_heap_pages(
 unsigned int order, unsigned int memflags,
 struct domain *d)
 {
-unsigned int i, j, zone = 0, nodemask_retry = 0;
-nodeid_t first_node, node = MEMF_get_node(memflags), req_node = node;
+unsigned int i, j, zone, nodemask_retry;
+nodeid_t first_node, node, req_node;
 unsigned long request = 1UL << order;
 struct page_info *pg;
-nodemask_t nodemask = (d != NULL ) ? d->node_affinity : node_online_map;
-bool_t need_tlbflush = 0;
+nodemask_t nodemask;
+bool need_scrub, need_tlbflush = false, use_unscrubbed = false;
 uint32_t tlbflush_timestamp = 0;
 
 /* Make sure there are enough bits in memflags for nodeID. */
 BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t)));
 
-if ( node == NUMA_NO_NODE )
-{
-if ( d != NULL )
-{
-node = next_node(d->last_alloc_node, nodemask);
-if ( node >= MAX_NUMNODES )
-node = first_node(nodemask);
-}
-if ( node >= MAX_NUMNODES )
-node = cpu_to_node(smp_processor_id());
-}
-first_node = node;
-
-ASSERT(node < MAX_NUMNODES);
-ASSERT(zone_lo <= zone_hi);
-ASSERT(zone_hi < NR_ZONES);
-
 if ( unlikely(order > MAX_ORDER) )
 return NULL;
 
@@ -741,7 +724,10 @@ static struct page_info *alloc_heap_pages(
   total_avail_pages + tmem_freeable_pages()) &&
   ((memflags & MEMF_no_refcount) ||
!d || d->outstanding_pages < request) )
-goto not_found;
+{
+spin_unlock(_lock);
+return NULL;
+}
 
 /*
  * TMEM: When available memory is scarce due to tmem absorbing it, allow
@@ -754,6 +740,28 @@ static struct page_info *alloc_heap_pages(
  tmem_freeable_pages() )
 goto try_tmem;
 
+ again:
+
+nodemask_retry = 0;
+nodemask = (d != NULL ) ? d->node_affinity : node_online_map;
+node = req_node = MEMF_get_node(memflags);
+if ( node == NUMA_NO_NODE )
+{
+if ( d != NULL )
+{
+node = next_node(d->last_alloc_node, nodemask);
+if ( node >= MAX_NUMNODES )
+node = first_node(nodemask);
+}
+if ( node >= MAX_NUMNODES )
+node = cpu_to_node(smp_processor_id());
+}
+first_node = node;
+
+ASSERT(node < MAX_NUMNODES);
+ASSERT(zone_lo <= zone_hi);
+ASSERT(zone_hi < NR_ZONES);
+
 /*
  * Start with requested node, but exhaust all node memory in requested 
  * zone before failing, only calc new node value if we fail to find memory 
@@ -769,8 +777,16 @@ static struct page_info *alloc_heap_pages(
 
 /* Find smallest order which can satisfy the request. */
 for ( j = order; j <= MAX_ORDER; j++ )
+{
 if ( (pg = page_list_remove_head((node, zone, j))) )
-goto found;
+{
+if ( (order == 0) || use_unscrubbed ||
+ !pg->u.free.dirty_head )
+goto found;
+
+page_list_add_tail(pg, (node, zone, j));
+}
+}
 } while ( zone-- > zone_lo ); /* careful: unsigned zone may wrap */
 
 if ( (memflags & MEMF_exact_node) && req_node != NUMA_NO_NODE )
@@ -809,16 +825,32 @@ static struct page_info *alloc_heap_pages(
 }
 
  not_found:
+/*
+ * If we couldn't find clean page let's search again and this time
+ * take unscrubbed pages if available.
+ */
+if ( !use_unscrubbed )
+{
+use_unscrubbed = true;
+goto again;
+}
+
 /* No suitable memory blocks. Fail the request. */
 spin_unlock(_lock);
 return NULL;
 
  found: 
+need_scrub = pg->u.free.dirty_head;
+
 /* We may have to halve the chunk a number of times. */
 while ( j != order )
 {
-PFN_ORDER(pg) = --j;
-page_list_add(pg, (node, zone, j));
+/*
+ * Some of the sub-chunks may be clean but we will mark them
+ * as dirty (if need_scrub is set) to avoid traversing the
+ * array here.
+ */
+page_list_add_scrub(pg, node, zone, --j, need_scrub);
 pg += 1 << j;
 }
 
@@ -832,6 +864,20 @@ static 

[Xen-devel] [PATCH v3 5/9] mm: Do not discard already-scrubbed pages if softirqs are pending

[Boris Ostrovsky]

While scrubbing from idle loop, check for softirqs every 256 pages.
If softirq is pending, don't scrub any further and merge the
partially-scrubbed buddy back into heap by breaking the clean portion
into smaller power-of-2 chunks. Then repeat the same process for the
dirty part.

Signed-off-by: Boris Ostrovsky 
---
 xen/common/page_alloc.c |   78 ++
 1 files changed, 64 insertions(+), 14 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index fcd7308..0b2dff1 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -996,7 +996,7 @@ static int reserve_offlined_page(struct page_info *head)
 static struct page_info *
 merge_and_free_buddy(struct page_info *pg, unsigned int node,
  unsigned int zone, unsigned int order,
- bool need_scrub)
+ bool need_scrub, bool is_frag)
 {
 ASSERT(spin_is_locked(_lock));
 
@@ -1011,7 +1011,15 @@ merge_and_free_buddy(struct page_info *pg, unsigned int 
node,
 if ( (page_to_mfn(pg) & mask) )
 buddy = pg - mask; /* Merge with predecessor block. */
 else
-buddy = pg + mask; /* Merge with successor block. */
+{
+/*
+ * Merge with successor block.
+ * Only un-fragmented buddy can be merged forward.
+ */
+if ( is_frag )
+break;
+buddy = pg + mask;
+}
 
 if ( !mfn_valid(_mfn(page_to_mfn(buddy))) ||
  !page_state_is(buddy, free) ||
@@ -1093,12 +1101,15 @@ static unsigned int node_to_scrub(bool get_node)
 bool scrub_free_pages(void)
 {
 struct page_info *pg;
-unsigned int zone, order;
-unsigned long i;
+unsigned int zone, order, scrub_order;
+unsigned long i, num_processed, start, end;
 unsigned int cpu = smp_processor_id();
-bool preempt = false;
+bool preempt = false, is_frag;
 nodeid_t node;
 
+/* Scrubbing granularity. */
+#define SCRUB_CHUNK_ORDER  8
+
 /*
  * Don't scrub while dom0 is being constructed since we may
  * fail trying to call map_domain_page() from scrub_one_page().
@@ -1123,25 +1134,64 @@ bool scrub_free_pages(void)
 if ( !pg->u.free.dirty_head )
 break;
 
-for ( i = 0; i < (1UL << order); i++)
+scrub_order = MIN(order, SCRUB_CHUNK_ORDER);
+num_processed = 0;
+is_frag = false;
+while ( num_processed < (1UL << order) )
 {
-if ( test_bit(_PGC_need_scrub, [i].count_info) )
+for ( i = num_processed;
+  i < num_processed + (1UL << scrub_order); i++ )
 {
-scrub_one_page([i]);
-pg[i].count_info &= ~PGC_need_scrub;
-node_need_scrub[node]--;
+if ( test_bit(_PGC_need_scrub, [i].count_info) )
+{
+scrub_one_page([i]);
+pg[i].count_info &= ~PGC_need_scrub;
+node_need_scrub[node]--;
+}
 }
+
+num_processed += (1UL << scrub_order);
 if ( softirq_pending(cpu) )
 {
 preempt = true;
+is_frag = (num_processed < (1UL << order));
 break;
 }
 }
 
-if ( i == (1UL << order) )
+start = 0;
+end = num_processed;
+
+page_list_del(pg, (node, zone, order));
+
+/* Merge clean pages */
+while ( start < end )
+{
+/*
+ * Largest power-of-two chunk starting @start,
+ * not greater than @end
+ */
+unsigned chunk_order = flsl(end - start) - 1;
+struct page_info *ppg = [start];
+
+PFN_ORDER(ppg) = chunk_order;
+merge_and_free_buddy(ppg, node, zone, chunk_order, false, 
is_frag);
+start += (1UL << chunk_order);
+}
+
+/* Merge unscrubbed pages */
+while ( end < (1UL << order) )
 {
-page_list_del(pg, (node, zone, order));
-merge_and_free_buddy(pg, node, zone, order, false);
+/*
+ * Largest power-of-two chunk starting @end, not crossing
+ * next power-of-two boundary
+ */
+unsigned chunk_order = ffsl(end) - 1;
+struct page_info *ppg = [end];
+
+PFN_ORDER(ppg) = chunk_order;
+   

[Xen-devel] [PATCH v3 6/9] spinlock: Introduce spin_lock_cb()

[Boris Ostrovsky]

While waiting for a lock we may want to periodically run some
code. This code may, for example, allow the caller to release
resources held by it that are no longer needed in the critical
section protected by the lock.

Specifically, this feature will be needed by scrubbing code where
the scrubber, while waiting for heap lock to merge back clean
pages, may be requested by page allocator (which is currently
holding the lock) to abort merging and release the buddy page head
that the allocator wants.

We could use spin_trylock() but since it doesn't take lock ticket
it may take long time until the lock is taken. Instead we add
spin_lock_cb() that allows us to grab the ticket abd execute a
callback while waiting.

Since we may be sleeping in the lock until it is released we need a
mechanism that will make sure that the callback has a chance to run.
We add spin_lock_kick() that will wake up the waiter.

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Integrate smp_mb into spin_lock_kick()

 xen/common/spinlock.c  |9 -
 xen/include/xen/spinlock.h |8 
 2 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 2a06406..3c1caae 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -129,7 +129,7 @@ static always_inline u16 observe_head(spinlock_tickets_t *t)
 return read_atomic(>head);
 }
 
-void _spin_lock(spinlock_t *lock)
+void inline _spin_lock_cb(spinlock_t *lock, void (*cb)(void *), void *data)
 {
 spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
 LOCK_PROFILE_VAR;
@@ -140,6 +140,8 @@ void _spin_lock(spinlock_t *lock)
 while ( tickets.tail != observe_head(>tickets) )
 {
 LOCK_PROFILE_BLOCK;
+if ( unlikely(cb) )
+cb(data);
 arch_lock_relax();
 }
 LOCK_PROFILE_GOT;
@@ -147,6 +149,11 @@ void _spin_lock(spinlock_t *lock)
 arch_lock_acquire_barrier();
 }
 
+void _spin_lock(spinlock_t *lock)
+{
+ _spin_lock_cb(lock, NULL, NULL);
+}
+
 void _spin_lock_irq(spinlock_t *lock)
 {
 ASSERT(local_irq_is_enabled());
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index c1883bd..91bfb95 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -153,6 +153,7 @@ typedef struct spinlock {
 #define spin_lock_init(l) (*(l) = (spinlock_t)SPIN_LOCK_UNLOCKED)
 
 void _spin_lock(spinlock_t *lock);
+void _spin_lock_cb(spinlock_t *lock, void (*cond)(void *), void *data);
 void _spin_lock_irq(spinlock_t *lock);
 unsigned long _spin_lock_irqsave(spinlock_t *lock);
 
@@ -169,6 +170,7 @@ void _spin_lock_recursive(spinlock_t *lock);
 void _spin_unlock_recursive(spinlock_t *lock);
 
 #define spin_lock(l)  _spin_lock(l)
+#define spin_lock_cb(l, c, d) _spin_lock_cb(l, c, d)
 #define spin_lock_irq(l)  _spin_lock_irq(l)
 #define spin_lock_irqsave(l, f) \
 ({  \
@@ -190,6 +192,12 @@ void _spin_unlock_recursive(spinlock_t *lock);
 1 : ({ local_irq_restore(flags); 0; }); \
 })
 
+#define spin_lock_kick(l)   \
+({  \
+smp_mb();   \
+arch_lock_signal(); \
+})
+
 /* Ensure a lock is quiescent between two critical operations. */
 #define spin_barrier(l)   _spin_barrier(l)
 
-- 
1.7.1


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

[Xen-devel] [PATCH v3 0/9] Memory scrubbing from idle loop

[Boris Ostrovsky]

When a domain is destroyed the hypervisor must scrub domain's pages before
giving them to another guest in order to prevent leaking the deceased
guest's data. Currently this is done during guest's destruction, possibly
causing very lengthy cleanup process.

This series adds support for scrubbing released pages from idle loop,
making guest destruction significantly faster. For example, destroying a
1TB guest can now be completed in 40+ seconds as opposed to about 9 minutes
using existing scrubbing algorithm.

Briefly, the new algorithm places dirty pages at the end of heap's page list
for each node/zone/order to avoid having to scan full list while searching
for dirty pages. One processor form each node checks whether the node has any
dirty pages and, if such pages are found, scrubs them. Scrubbing itself
happens without holding heap lock so other users may access heap in the
meantime. If while idle loop is scrubbing a particular chunk of pages this
chunk is requested by the heap allocator, scrubbing is immediately stopped.

On the allocation side, alloc_heap_pages() first tries to satisfy allocation
request using only clean pages. If this is not possible, the search is
repeated and dirty pages are scrubbed by the allocator.

This series is somewhat based on earlier work by Bob Liu.

V1:
* Only set PGC_need_scrub bit for the buddy head, thus making it unnecessary
  to scan whole buddy
* Fix spin_lock_cb()
* Scrub CPU-less nodes
* ARM support. Note that I have not been able to test this, only built the
  binary
* Added scrub test patch (last one). Not sure whether it should be considered
  for committing but I have been running with it.

V2:
* merge_chunks() returns new buddy head
* scrub_free_pages() returns softirq pending status in addition to (factored 
out)
  status of unscrubbed memory
* spin_lock uses inlined spin_lock_cb()
* scrub debugging code checks whole page, not just the first word.

V3:
* Keep dirty bit per page
* Simplify merge_chunks() (now merge_and_free_buddy())
* When scrubbing memmory-only nodes try to find the closest node.

Deferred:
* Per-node heap locks. In addition to (presumably) improving performance in
  general, once they are available we can parallelize scrubbing further by
  allowing more than one core per node to do idle loop scrubbing.
* AVX-based scrubbing
* Use idle loop scrubbing during boot.


Boris Ostrovsky (9):
  mm: Separate free page chunk merging into its own routine
  mm: Place unscrubbed pages at the end of pagelist
  mm: Scrub pages in alloc_heap_pages() if needed
  mm: Scrub memory from idle loop
  mm: Do not discard already-scrubbed pages if softirqs are pending
  spinlock: Introduce spin_lock_cb()
  mm: Keep pages available for allocation while scrubbing
  mm: Print number of unscrubbed pages in 'H' debug handler
  mm: Make sure pages are scrubbed

 xen/Kconfig.debug  |7 +
 xen/arch/arm/domain.c  |   13 +-
 xen/arch/x86/domain.c  |3 +-
 xen/common/page_alloc.c|  529 ++--
 xen/common/spinlock.c  |9 +-
 xen/include/asm-arm/mm.h   |   10 +
 xen/include/asm-x86/mm.h   |   10 +
 xen/include/xen/mm.h   |1 +
 xen/include/xen/spinlock.h |8 +
 9 files changed, 513 insertions(+), 77 deletions(-)


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

[Xen-devel] [PATCH v3 9/9] mm: Make sure pages are scrubbed

[Boris Ostrovsky]

Add a debug Kconfig option that will make page allocator verify
that pages that were supposed to be scrubbed are, in fact, clean.

Signed-off-by: Boris Ostrovsky 
---
 xen/Kconfig.debug   |7 ++
 xen/common/page_alloc.c |   49 ++-
 2 files changed, 55 insertions(+), 1 deletions(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 689f297..f3bf9a9 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -114,6 +114,13 @@ config DEVICE_TREE_DEBUG
  logged in the Xen ring buffer.
  If unsure, say N here.
 
+config SCRUB_DEBUG
+bool "Page scrubbing test"
+default DEBUG
+---help---
+  Verify that pages that need to be scrubbed before being allocated to
+  a guest are indeed scrubbed.
+
 endif # DEBUG || EXPERT
 
 endmenu
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index dd6f248..18c80d7 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -694,6 +694,31 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 page_list_add(pg, (node, zone, order));
 }
 
+#define SCRUB_BYTE_PATTERN 0xc2c2c2c2c2c2c2c2
+#ifdef CONFIG_SCRUB_DEBUG
+static void poison_one_page(struct page_info *pg)
+{
+mfn_t mfn = _mfn(page_to_mfn(pg));
+uint64_t *ptr;
+
+ptr = map_domain_page(mfn);
+*ptr = ~SCRUB_BYTE_PATTERN;
+unmap_domain_page(ptr);
+}
+
+static void check_one_page(struct page_info *pg)
+{
+mfn_t mfn = _mfn(page_to_mfn(pg));
+uint64_t *ptr;
+unsigned i;
+
+ptr = map_domain_page(mfn);
+for ( i = 0; i < PAGE_SIZE / sizeof (*ptr); i++ )
+ASSERT(ptr[i] == SCRUB_BYTE_PATTERN);
+unmap_domain_page(ptr);
+}
+#endif /* CONFIG_SCRUB_DEBUG */
+
 static void check_and_stop_scrub(struct page_info *head)
 {
 if ( head->u.free.scrub_state & PAGE_SCRUBBING )
@@ -912,6 +937,11 @@ static struct page_info *alloc_heap_pages(
  * guest can control its own visibility of/through the cache.
  */
 flush_page_to_ram(page_to_mfn([i]));
+
+#ifdef CONFIG_SCRUB_DEBUG
+if ( d && !is_idle_domain(d) )
+check_one_page([i]);
+#endif
 }
 
 spin_unlock(_lock);
@@ -1341,6 +1371,11 @@ static void free_heap_pages(
 pg[i].count_info |= PGC_need_scrub;
 
 node_need_scrub[node] += (1UL << order);
+
+#ifdef CONFIG_SCRUB_DEBUG
+for ( i = 0; i < (1 << order); i++ )
+poison_one_page([i]);
+#endif
 }
 
 pg = merge_and_free_buddy(pg, node, zone, order, need_scrub, false);
@@ -1637,6 +1672,14 @@ static void init_heap_pages(
 nr_pages -= n;
 }
 
+#ifdef CONFIG_SCRUB_DEBUG
+/*
+ * These pages get into heap and are allocated to dom0 before
+ * boot scrub happens.
+ * Not scrubbing them here will cause failure in check_one_page().
+ */
+scrub_one_page(pg + i);
+#endif
 free_heap_pages(pg + i, 0, false);
 }
 }
@@ -2170,6 +2213,9 @@ void free_domheap_pages(struct page_info *pg, unsigned 
int order)
 {
 BUG_ON((pg[i].u.inuse.type_info & PGT_count_mask) != 0);
 arch_free_heap_page(d, [i]);
+#ifdef CONFIG_SCRUB_DEBUG
+scrub_one_page([i]);
+#endif
 }
 
 drop_dom_ref = !domain_adjust_tot_pages(d, -(1 << order));
@@ -2273,7 +2319,8 @@ void scrub_one_page(struct page_info *pg)
 
 #ifndef NDEBUG
 /* Avoid callers relying on allocations returning zeroed pages. */
-unmap_domain_page(memset(__map_domain_page(pg), 0xc2, PAGE_SIZE));
+unmap_domain_page(memset(__map_domain_page(pg),
+ SCRUB_BYTE_PATTERN & 0xff, PAGE_SIZE));
 #else
 /* For a production build, clear_page() is the fastest way to scrub. */
 clear_domain_page(_mfn(page_to_mfn(pg)));
-- 
1.7.1


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

[Xen-devel] [PATCH v3 2/9] mm: Place unscrubbed pages at the end of pagelist

[Boris Ostrovsky]

. so that it's easy to find pages that need to be scrubbed (those pages are
now marked with _PGC_need_scrub bit).

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Keep dirty bit per page, add dirty_head to page_info that indicates whether
  the buddy has dirty pages.
* Make page_list_add_scrub() set buddy's page order
* Data type adjustments (int -> unsigned)

 xen/common/page_alloc.c  |  119 +
 xen/include/asm-arm/mm.h |6 ++
 xen/include/asm-x86/mm.h |6 ++
 3 files changed, 110 insertions(+), 21 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 6fe55ee..9dcf6ee 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -383,6 +383,8 @@ typedef struct page_list_head 
heap_by_zone_and_order_t[NR_ZONES][MAX_ORDER+1];
 static heap_by_zone_and_order_t *_heap[MAX_NUMNODES];
 #define heap(node, zone, order) ((*_heap[node])[zone][order])
 
+static unsigned long node_need_scrub[MAX_NUMNODES];
+
 static unsigned long *avail[MAX_NUMNODES];
 static long total_avail_pages;
 
@@ -678,6 +680,20 @@ static void check_low_mem_virq(void)
 }
 }
 
+/* Pages that need scrub are added to tail, otherwise to head. */
+static void page_list_add_scrub(struct page_info *pg, unsigned int node,
+unsigned int zone, unsigned int order,
+bool need_scrub)
+{
+PFN_ORDER(pg) = order;
+pg->u.free.dirty_head = need_scrub;
+
+if ( need_scrub )
+page_list_add_tail(pg, (node, zone, order));
+else
+page_list_add(pg, (node, zone, order));
+}
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
 unsigned int zone_lo, unsigned int zone_hi,
@@ -802,7 +818,7 @@ static struct page_info *alloc_heap_pages(
 while ( j != order )
 {
 PFN_ORDER(pg) = --j;
-page_list_add_tail(pg, (node, zone, j));
+page_list_add(pg, (node, zone, j));
 pg += 1 << j;
 }
 
@@ -851,11 +867,14 @@ static int reserve_offlined_page(struct page_info *head)
 int zone = page_to_zone(head), i, head_order = PFN_ORDER(head), count = 0;
 struct page_info *cur_head;
 int cur_order;
+bool need_scrub;
 
 ASSERT(spin_is_locked(_lock));
 
 cur_head = head;
 
+head->u.free.dirty_head = false;
+
 page_list_del(head, (node, zone, head_order));
 
 while ( cur_head < (head + (1 << head_order)) )
@@ -892,8 +911,16 @@ static int reserve_offlined_page(struct page_info *head)
 {
 merge:
 /* We don't consider merging outside the head_order. */
-page_list_add_tail(cur_head, (node, zone, cur_order));
-PFN_ORDER(cur_head) = cur_order;
+
+/* See if any of the pages need scrubbing. */
+need_scrub = false;
+for ( i = 0; i < (1 << cur_order); i++ )
+if ( test_bit(_PGC_need_scrub, _head[i].count_info) )
+{
+need_scrub = true;
+break;
+}
+page_list_add_scrub(cur_head, node, zone, cur_order, 
need_scrub);
 cur_head += (1 << cur_order);
 break;
 }
@@ -922,10 +949,13 @@ static int reserve_offlined_page(struct page_info *head)
 /* Returns new buddy head. */
 static struct page_info *
 merge_and_free_buddy(struct page_info *pg, unsigned int node,
- unsigned int zone, unsigned int order)
+ unsigned int zone, unsigned int order,
+ bool need_scrub)
 {
 ASSERT(spin_is_locked(_lock));
 
+pg->u.free.dirty_head = false;
+
 /* Merge chunks as far as possible. */
 while ( order < MAX_ORDER )
 {
@@ -944,6 +974,8 @@ merge_and_free_buddy(struct page_info *pg, unsigned int 
node,
 break;
 
 page_list_del(buddy, (node, zone, order));
+need_scrub |= buddy->u.free.dirty_head;
+buddy->u.free.dirty_head = false;
 
 /* Adjust current buddy head if we merged backwards. */
 if ( buddy < pg )
@@ -952,15 +984,56 @@ merge_and_free_buddy(struct page_info *pg, unsigned int 
node,
 order++;
 }
 
-PFN_ORDER(pg) = order;
-page_list_add_tail(pg, (node, zone, order));
+page_list_add_scrub(pg, node, zone, order, need_scrub);
 
 return pg;
 }
 
+static void scrub_free_pages(unsigned int node)
+{
+struct page_info *pg;
+unsigned int zone, order;
+unsigned long i;
+
+ASSERT(spin_is_locked(_lock));
+
+if ( !node_need_scrub[node] )
+return;
+
+for ( zone = 0; zone < NR_ZONES; zone++ )
+{
+order = MAX_ORDER;
+do {
+while ( !page_list_empty((node, zone, order)) )
+{
+/* Unscrubbed pages are always at the end of the list. */
+pg = page_list_last((node, zone, order));
+ 

[Xen-devel] [PATCH v3 7/9] mm: Keep pages available for allocation while scrubbing

[Boris Ostrovsky]

Instead of scrubbing pages while holding heap lock we can mark
buddy's head as being scrubbed and drop the lock temporarily.
If someone (most likely alloc_heap_pages()) tries to access
this chunk it will signal the scrubber to abort scrub by setting
head's PAGE_SCRUB_ABORT bit. The scrubber checks this bit after
processing each page and stops its work as soon as it sees it.

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Adjusted page_info's scrub_state definitions but kept them as binary
  flags since I think having both PAGE_SCRUBBING and PAGE_SCRUB_ABORT
  bits set make sense.

 xen/common/page_alloc.c  |   92 ++---
 xen/include/asm-arm/mm.h |4 ++
 xen/include/asm-x86/mm.h |4 ++
 3 files changed, 93 insertions(+), 7 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 0b2dff1..514a4a1 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -694,6 +694,17 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 page_list_add(pg, (node, zone, order));
 }
 
+static void check_and_stop_scrub(struct page_info *head)
+{
+if ( head->u.free.scrub_state & PAGE_SCRUBBING )
+{
+head->u.free.scrub_state |= PAGE_SCRUB_ABORT;
+spin_lock_kick();
+while ( ACCESS_ONCE(head->u.free.scrub_state) & PAGE_SCRUB_ABORT )
+cpu_relax();
+}
+}
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
 unsigned int zone_lo, unsigned int zone_hi,
@@ -780,10 +791,15 @@ static struct page_info *alloc_heap_pages(
 {
 if ( (pg = page_list_remove_head((node, zone, j))) )
 {
-if ( (order == 0) || use_unscrubbed ||
- !pg->u.free.dirty_head )
+if ( !pg->u.free.dirty_head )
 goto found;
 
+if ( (order == 0) || use_unscrubbed )
+{
+check_and_stop_scrub(pg);
+goto found;
+}
+
 page_list_add_tail(pg, (node, zone, j));
 }
 }
@@ -921,6 +937,8 @@ static int reserve_offlined_page(struct page_info *head)
 
 head->u.free.dirty_head = false;
 
+check_and_stop_scrub(head);
+
 page_list_del(head, (node, zone, head_order));
 
 while ( cur_head < (head + (1 << head_order)) )
@@ -1027,6 +1045,9 @@ merge_and_free_buddy(struct page_info *pg, unsigned int 
node,
  (phys_to_nid(page_to_maddr(buddy)) != node) )
 break;
 
+if ( buddy->u.free.scrub_state & PAGE_SCRUBBING )
+break;
+
 page_list_del(buddy, (node, zone, order));
 need_scrub |= buddy->u.free.dirty_head;
 buddy->u.free.dirty_head = false;
@@ -1098,14 +1119,35 @@ static unsigned int node_to_scrub(bool get_node)
 return closest;
 }
 
+struct scrub_wait_state {
+struct page_info *pg;
+bool drop;
+};
+
+static void scrub_continue(void *data)
+{
+struct scrub_wait_state *st = data;
+
+if ( st->drop )
+return;
+
+if ( st->pg->u.free.scrub_state & PAGE_SCRUB_ABORT )
+{
+/* There is a waiter for this buddy. Release it. */
+st->drop = true;
+st->pg->u.free.scrub_state = 0;
+}
+}
+
 bool scrub_free_pages(void)
 {
 struct page_info *pg;
 unsigned int zone, order, scrub_order;
-unsigned long i, num_processed, start, end;
+unsigned long i, num_processed, start, end, dirty_cnt;
 unsigned int cpu = smp_processor_id();
 bool preempt = false, is_frag;
 nodeid_t node;
+struct scrub_wait_state st;
 
 /* Scrubbing granularity. */
 #define SCRUB_CHUNK_ORDER  8
@@ -1134,8 +1176,13 @@ bool scrub_free_pages(void)
 if ( !pg->u.free.dirty_head )
 break;
 
+ASSERT(!pg->u.free.scrub_state);
+pg->u.free.scrub_state = PAGE_SCRUBBING;
+
+spin_unlock(_lock);
+
 scrub_order = MIN(order, SCRUB_CHUNK_ORDER);
-num_processed = 0;
+num_processed = dirty_cnt = 0;
 is_frag = false;
 while ( num_processed < (1UL << order) )
 {
@@ -1145,8 +1192,24 @@ bool scrub_free_pages(void)
 if ( test_bit(_PGC_need_scrub, [i].count_info) )
 {
 scrub_one_page([i]);
+/*
+ * We can modify count_info without holding heap
+ * lock since we effectively locked this buddy by
+ * setting its scrub_state.
+ */
 pg[i].count_info &= ~PGC_need_scrub;
-node_need_scrub[node]--;
+dirty_cnt++;
+ 

[Xen-devel] [PATCH v3 4/9] mm: Scrub memory from idle loop

[Boris Ostrovsky]

Instead of scrubbing pages during guest destruction (from
free_heap_pages()) do this opportunistically, from the idle loop.

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* If memory-only nodes exist, select the closest one for scrubbing
* Don't scrub from idle loop until we reach SYS_STATE_active.

 xen/arch/arm/domain.c   |   13 --
 xen/arch/x86/domain.c   |3 +-
 xen/common/page_alloc.c |   98 +-
 xen/include/xen/mm.h|1 +
 4 files changed, 98 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 76310ed..38d6331 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -46,13 +46,16 @@ void idle_loop(void)
 if ( cpu_is_offline(smp_processor_id()) )
 stop_cpu();
 
-local_irq_disable();
-if ( cpu_is_haltable(smp_processor_id()) )
+if ( !scrub_free_pages() )
 {
-dsb(sy);
-wfi();
+local_irq_disable();
+if ( cpu_is_haltable(smp_processor_id()) )
+{
+dsb(sy);
+wfi();
+}
+local_irq_enable();
 }
-local_irq_enable();
 
 do_tasklet();
 do_softirq();
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 90e2b1f..a5f62b5 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -118,7 +118,8 @@ static void idle_loop(void)
 {
 if ( cpu_is_offline(smp_processor_id()) )
 play_dead();
-(*pm_idle)();
+if ( !scrub_free_pages() )
+(*pm_idle)();
 do_tasklet();
 do_softirq();
 /*
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 055654d..fcd7308 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1035,16 +1035,82 @@ merge_and_free_buddy(struct page_info *pg, unsigned int 
node,
 return pg;
 }
 
-static void scrub_free_pages(unsigned int node)
+static nodemask_t node_scrubbing;
+
+static unsigned int node_to_scrub(bool get_node)
+{
+nodeid_t node = cpu_to_node(smp_processor_id()), local_node;
+nodeid_t closest = NUMA_NO_NODE;
+u8 dist, shortest = 0xff;
+
+if ( node == NUMA_NO_NODE )
+node = 0;
+
+if ( node_need_scrub[node] &&
+ (!get_node || !node_test_and_set(node, node_scrubbing)) )
+return node;
+
+/*
+ * See if there are memory-only nodes that need scrubbing and choose
+ * the closest one.
+ */
+local_node = node;
+while ( 1 )
+{
+do {
+node = cycle_node(node, node_online_map);
+} while ( !cpumask_empty(_to_cpumask(node)) &&
+  (node != local_node) );
+
+if ( node == local_node )
+break;
+
+if ( node_need_scrub[node] )
+{
+if ( !get_node )
+return node;
+
+if ( !node_test_and_set(node, node_scrubbing) )
+{
+dist = __node_distance(local_node, node);
+if ( (dist < shortest) || (dist == NUMA_NO_DISTANCE) )
+{
+/* Release previous node. */
+if ( closest != NUMA_NO_NODE )
+node_clear(closest, node_scrubbing);
+shortest = dist;
+closest = node;
+}
+else
+node_clear(node, node_scrubbing);
+}
+}
+}
+
+return closest;
+}
+
+bool scrub_free_pages(void)
 {
 struct page_info *pg;
 unsigned int zone, order;
 unsigned long i;
+unsigned int cpu = smp_processor_id();
+bool preempt = false;
+nodeid_t node;
 
-ASSERT(spin_is_locked(_lock));
+/*
+ * Don't scrub while dom0 is being constructed since we may
+ * fail trying to call map_domain_page() from scrub_one_page().
+ */
+if ( system_state < SYS_STATE_active )
+return false;
+ 
+node = node_to_scrub(true);
+if ( node == NUMA_NO_NODE )
+return false;
 
-if ( !node_need_scrub[node] )
-return;
+spin_lock(_lock);
 
 for ( zone = 0; zone < NR_ZONES; zone++ )
 {
@@ -1065,16 +1131,29 @@ static void scrub_free_pages(unsigned int node)
 pg[i].count_info &= ~PGC_need_scrub;
 node_need_scrub[node]--;
 }
+if ( softirq_pending(cpu) )
+{
+preempt = true;
+break;
+}
 }
 
-page_list_del(pg, (node, zone, order));
-merge_and_free_buddy(pg, node, zone, order, false);
+if ( i == (1UL << order) )
+{
+page_list_del(pg, (node, zone, order));
+merge_and_free_buddy(pg, node, zone, order, false);
+}
 
-   

[Xen-devel] PVH Dom0 Intel IOMMU issues

[Roger Pau Monné]

Hello,

Although PVHv2 Dom0 is not yet finished, I've been trying the current code on
different hardware, and found that with pre-Haswell Intel hardware PVHv2 Dom0
completely freezes the box when calling iommu_hwdom_init in dom0_construct_pvh.
OTOH the same doesn't happen when using a newer CPU (ie: haswell or newer).

I'm not able to debug that in any meaningful way because the box seems to lock
up completely, even the watchdog NMI stops working. Here is the boot log, up to
the point where it freezes:

(XEN) Xen version 4.9-unstable (root@) (FreeBSD clang version 3.9.0 
(tags/RELEASE_390/final 280324) (based on LLVM 3.9.0)) debug=y  Fri Apr 14 
16:15:35 BST 2017
(XEN) Latest ChangeSet:
(XEN) Console output is synchronous.
(XEN) Bootloader: FreeBSD Loader
(XEN) Command line: dom0_mem=4096M dom0=pvh com1=115200,8n1 console=com1,vga 
guest_loglvl=all loglvl=all iommu=debug,verbose sync_console
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0008dc00 (usable)
(XEN)  0008dc00 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 18ebb000 (usable)
(XEN)  18ebb000 - 18fe8000 (ACPI NVS)
(XEN)  18fe8000 - 18fe9000 (usable)
(XEN)  18fe9000 - 1900 (ACPI NVS)
(XEN)  1900 - 1dffd000 (usable)
(XEN)  1dffd000 - 1e00 (ACPI data)
(XEN)  1e00 - ac784000 (usable)
(XEN)  ac784000 - ac818000 (reserved)
(XEN)  ac818000 - ad80 (usable)
(XEN)  b000 - b400 (reserved)
(XEN)  fed2 - fed4 (reserved)
(XEN)  fed5 - fed9 (reserved)
(XEN)  ffa0 - ffa4 (reserved)
(XEN)  0001 - 00025000 (usable)
(XEN) New Xen image base address: 0xad20
(XEN) ACPI: RSDP 000FE300, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 1DFFEE18, 0074 (r1 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: FACP 18FEFD98, 00F4 (r4 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: DSDT 18FA9018, 6373 (r1 DELLCBX3   0 INTL 20091112)
(XEN) ACPI: FACS 18FF1F40, 0040
(XEN) ACPI: APIC 1DFFDC18, 0158 (r2 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: MCFG 18FFED18, 003C (r1 A M I  OEMMCFG.  6222004 MSFT   97)
(XEN) ACPI: TCPA 18FFEC98, 0032 (r20 0)
(XEN) ACPI: SSDT 18FF0A98, 0306 (r1 DELLTP  TPM 3000 INTL 20091112)
(XEN) ACPI: HPET 18FFEC18, 0038 (r1 A M I   PCHHPET  6222004 AMI.3)
(XEN) ACPI: BOOT 18FFEB98, 0028 (r1 DELL   CBX3  6222004 AMI 10013)
(XEN) ACPI: SSDT 18FB0018, 36FFE (r2  INTELCpuPm 4000 INTL 20091112)
(XEN) ACPI: SLIC 18FEEC18, 0176 (r3 DELLCBX3 6222004 MSFT10013)
(XEN) ACPI: DMAR 18FF1B18, 0094 (r1 A M I   OEMDMAR1 INTL1)
(XEN) System RAM: 8149MB (8345288kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -00025000
(XEN) Domain heap initialised
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 45 (0x2d), Stepping 7 (raw 
000206d7)
(XEN) found SMP MP-table at 000f1db0
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408 (32 bits)
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 18ffdf40/18ff1f40, 
using 32
(XEN) ACPI: wakeup_vec[18ffdf4c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x09] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0b] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0c] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0d] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0e] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x0f] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x10] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x11] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x12] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x13] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x14] disabled)
(XEN) ACPI: LAPIC 

Re: [Xen-devel] Looking for some input: Alpine Linux Bug #6962, apparently broken pv-grub in 3.5

[Wei Liu]

On Fri, Apr 14, 2017 at 05:03:41PM +0200, Florian Heigl wrote:
> Hi everyone!
> 
> last month I hit a weird bug with PV-Grub in AlpineLinux 3.5
> Basically, after updating PV-Grub you can no longer boot your VMs unless 
> they’re on an ext2 partition.
> This also happened to others and apparently also on Gentoo.
> 
> Natanael Copa has been kind enough to dig in, but it’s gotten to a point 
> where I’m uncertain if you guys did give up on PV-Grub or something.
> Is there a known regression? Is anything deprecated?
> 
> It would be very kind if a Xen dev could have a look here:
> 
> https://bugs.alpinelinux.org/issues/6962#change-19135
> 
> (Please CC on replies or put in the bug tracker)
> 

Please make a request to Jan Beulich or Ian Jackson to backport the
stubdom fix to 4.7 if it solves the "Error 9" booting problem.

As for the ext4 issue, it is trickier because it's going to be a
non-trivial patch. It certainly requires a deep understanding of ext4.
We would certainly be happy to accept patch(es) for that.

Wei.

> Thanks for any input, and happy easter holidays / good weekend!
> Florian
> ___
> 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] EFI + tboot + Xen

[Andrew Cooper]

On 14/04/2017 15:54, Daniel Kiper wrote:
> Hey,
>
> Has anybody tried to run EFI + tboot + Xen?
> I have a feeling that it does not work because
> tboot shuts down EFI boot services. However,
> even if it works then efibootmgr is unusable
> due to lack of EFI runtime services. Do we care?
> Is it possible to make it work with full blown
> EFI infrastructure available for Xen?

Judging by
http://hg.code.sf.net/p/tboot/code/file/9352e6391332/tboot/common/boot.S#l83
it will be grub exiting boot services.  tboot needs rather more
multiboot2 knowledge before it could participate in a hand-off to Xen
while keeping boot services active.

~Andrew

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

[Xen-devel] Looking for some input: Alpine Linux Bug #6962, apparently broken pv-grub in 3.5

[Florian Heigl]

Hi everyone!

last month I hit a weird bug with PV-Grub in AlpineLinux 3.5
Basically, after updating PV-Grub you can no longer boot your VMs unless 
they’re on an ext2 partition.
This also happened to others and apparently also on Gentoo.

Natanael Copa has been kind enough to dig in, but it’s gotten to a point where 
I’m uncertain if you guys did give up on PV-Grub or something.
Is there a known regression? Is anything deprecated?

It would be very kind if a Xen dev could have a look here:

https://bugs.alpinelinux.org/issues/6962#change-19135

(Please CC on replies or put in the bug tracker)

Thanks for any input, and happy easter holidays / good weekend!
Florian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-install fail baseline untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

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

version targeted for testing:
 linuxa232591ba289a1a397e0005c9f276a126c1bc1b1
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  645 days
Failing since 59348  2015-07-10 04:24:05 Z  644 days  387 attempts
Testing same since   107443  2017-04-14 04:31:31 Z0 days1 attempts


8159 people touched revisions under test,
not listing them all

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

[Xen-devel] EFI + tboot + Xen

[Daniel Kiper]

Hey,

Has anybody tried to run EFI + tboot + Xen?
I have a feeling that it does not work because
tboot shuts down EFI boot services. However,
even if it works then efibootmgr is unusable
due to lack of EFI runtime services. Do we care?
Is it possible to make it work with full blown
EFI infrastructure available for Xen?

Daniel

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

Re: [Xen-devel] [stable-4.9: PATCH] xen: revert commit 72a9b186292

[Boris Ostrovsky]

On 04/14/2017 05:17 AM, Greg KH wrote:
> On Thu, Apr 13, 2017 at 03:06:53PM +0200, Juergen Gross wrote:
>> Revert commit 72a9b186292 ("xen: Remove event channel notification
>> through Xen PCI platform device") as the original analysis was wrong
>> that all the removed code isn't in use any more.
>>
>> It is still necessary for old Xen versions (< 4.0) and for being able
>> to run the Linux kernel as dom0 in a nested Xen environment.
> What is the commit id of this revert in Linus's tree?

It hasn't been reverted in Linus tree yet --- there were some changes in
Xen code in 4.11 that make the revert not a mechanical operation and we
are somewhat hesitant to have a patch this late in the release cycle.

-boris

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

[Xen-devel] [linux-arm-xen test] 107441: regressions - FAIL

[osstest service owner]

flight 107441 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107441/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   6 xen-boot fail REGR. vs. 107176

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken in 107296 pass in 107441
 test-armhf-armhf-xl-multivcpu  6 xen-boot  fail pass in 107296
 test-armhf-armhf-xl-credit2   6 xen-boot   fail pass in 107296
 test-armhf-armhf-libvirt-xsm  6 xen-boot   fail pass in 107296
 test-armhf-armhf-libvirt-raw  6 xen-boot   fail pass in 107296
 test-armhf-armhf-xl-xsm   6 xen-boot   fail pass in 107296
 test-armhf-armhf-libvirt  6 xen-boot   fail pass in 107296
 test-armhf-armhf-xl   6 xen-boot   fail pass in 107296
 test-armhf-armhf-xl-vhd   6 xen-boot   fail pass in 107296
 test-armhf-armhf-xl-rtds  6 xen-boot   fail pass in 107371

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail in 107296 like 
107176
 test-armhf-armhf-libvirt 13 saverestore-support-check fail in 107296 like 
107176

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2 12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 107296 never 
pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail in 107296 never 
pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail in 107296 
never pass
 test-armhf-armhf-xl 12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl 13 saverestore-support-check fail in 107296 never pass
 test-armhf-armhf-libvirt12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-xsm 13 saverestore-support-check fail in 107296 never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail in 107296 never 
pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 107296 never pass
 test-armhf-armhf-xl-vhd 11 migrate-support-check fail in 107296 never pass
 test-armhf-armhf-xl-vhd 12 saverestore-support-check fail in 107296 never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 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-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux9ceff47026d8db55dc9f133a40ae4042c71fcb13
baseline version:
 linux6878b2fa7229c9208a02d45f280c71389cba0617

Last test of basis   107176  2017-04-04 09:44:38 Z   10 days
Failing since107256  2017-04-07 00:24:43 Z7 days7 attempts
Testing same since   107296  2017-04-08 07:12:44 Z6 days6 attempts


10162 people touched revisions under test,
not listing them all

jobs:
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-arm64  pass
 build-armhf  pass
 build-arm64-libvirt   

Re: [Xen-devel] [PATCH v16 7/9] x86: make Xen early boot code relocatable

[Daniel Kiper]

On Thu, Apr 13, 2017 at 09:44:17PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 13, 2017 at 04:11:25PM +0200, Daniel Kiper wrote:
> > On Fri, Apr 07, 2017 at 05:23:33AM -0600, Jan Beulich wrote:
> > > >>> On 21.02.17 at 20:19,  wrote:
> > > > Every multiboot protocol (regardless of version) compatible image must
> > > > specify its load address (in ELF or multiboot header). Multiboot 
> > > > protocol
> > > > compatible loader have to load image at specified address. However, 
> > > > there
> > > > is no guarantee that the requested memory region (in case of Xen it 
> > > > starts
> > > > at 2 MiB and ends at ~5 MiB) where image should be loaded initially is 
> > > > a RAM
> > > > and it is free (legacy BIOS platforms are merciful for Xen but I found 
> > > > at
> > > > least one EFI platform on which Xen load address conflicts with EFI boot
> > > > services; it is Dell PowerEdge R820 with latest firmware). To cope with 
> > > > that
> > > > problem we must make Xen early boot code relocatable and help boot 
> > > > loader to
> > > > relocate image in proper way by suggesting, not requesting specific load
> > > > addresses as it is right now, allowed address ranges. This patch does
> > > > former.
> > > > It does not add multiboot2 protocol interface which is done in "x86: add
> > > > multiboot2 protocol support for relocatable images" patch.
> > > >
> > > > This patch changes following things:
> > > >   - %esi register is used as a storage for Xen image load base address;
> > > > it is mostly unused in early boot code and preserved during C 
> > > > functions
> > > > calls in 32-bit mode,
> > > >   - %fs is used as base for Xen data relative addressing in 32-bit code
> > > > if it is possible; %esi is used for that thing during error printing
> > > > because it is not always possible to properly and efficiently
> > > > initialize %fs.
> > > >
> > > > Signed-off-by: Daniel Kiper 
> > >
> > > Reviewed-by: Jan Beulich 
> >
> > It looks that everything passed through test gate and landed in master.
> > So, this way we have full multiboot2 support in Xen. This means that
> > you can boot Xen using GRUB2 on EFI platforms.
> >
> > I would like to thank everybody who helped me to make it happen.
> > Especially Jan who patiently reviewed whole series many times
> > and replied for my stupid questions.
>
> 

Cheers!

> Yey! Congrats!

Thank you.

Daniel

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e06179889586c37101e2900e7f52be9f0da12cda
baseline version:
 ovmf d63ed30bb508f46ec304cf1431a67c8f9f2fe0bf

Last test of basis71191  2017-04-13 21:16:40 Z0 days
Testing same since71193  2017-04-14 08:46:43 Z0 days1 attempts


People who touched revisions under test:
  Liming Gao 

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


commit e06179889586c37101e2900e7f52be9f0da12cda
Author: Liming Gao 
Date:   Thu Apr 13 15:08:07 2017 +0800

MdeModulePkg DxeCore: Fix issue to print GUID value %g without pointer

https://bugzilla.tianocore.org/show_bug.cgi?id=474

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Star Zeng 

commit 2c8d2545f59bf00f0b2460dbeabee6645d130d3e
Author: Liming Gao 
Date:   Fri Apr 14 00:13:06 2017 +0800

MdeModulePkg BrotliLib: Fix the regression logic issue in loop

In V2, change logic to avoid use mtf[-1] style to get value.

Roll back to previous logic, and use point + offset to get byte value.

Cc: Bell Song 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Bell Song 

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

Re: [Xen-devel] [PATCH v16 7/9] x86: make Xen early boot code relocatable

[Daniel Kiper]

On Thu, Apr 13, 2017 at 02:43:22PM -0500, Doug Goldstein wrote:
> On 4/13/17 9:11 AM, Daniel Kiper wrote:
> > On Fri, Apr 07, 2017 at 05:23:33AM -0600, Jan Beulich wrote:
> > On 21.02.17 at 20:19,  wrote:
> >>> Every multiboot protocol (regardless of version) compatible image must
> >>> specify its load address (in ELF or multiboot header). Multiboot protocol
> >>> compatible loader have to load image at specified address. However, there
> >>> is no guarantee that the requested memory region (in case of Xen it starts
> >>> at 2 MiB and ends at ~5 MiB) where image should be loaded initially is a 
> >>> RAM
> >>> and it is free (legacy BIOS platforms are merciful for Xen but I found at
> >>> least one EFI platform on which Xen load address conflicts with EFI boot
> >>> services; it is Dell PowerEdge R820 with latest firmware). To cope with 
> >>> that
> >>> problem we must make Xen early boot code relocatable and help boot loader 
> >>> to
> >>> relocate image in proper way by suggesting, not requesting specific load
> >>> addresses as it is right now, allowed address ranges. This patch does
> >>> former.
> >>> It does not add multiboot2 protocol interface which is done in "x86: add
> >>> multiboot2 protocol support for relocatable images" patch.
> >>>
> >>> This patch changes following things:
> >>>   - %esi register is used as a storage for Xen image load base address;
> >>> it is mostly unused in early boot code and preserved during C 
> >>> functions
> >>> calls in 32-bit mode,
> >>>   - %fs is used as base for Xen data relative addressing in 32-bit code
> >>> if it is possible; %esi is used for that thing during error printing
> >>> because it is not always possible to properly and efficiently
> >>> initialize %fs.
> >>>
> >>> Signed-off-by: Daniel Kiper 
> >>
> >> Reviewed-by: Jan Beulich 
> >
> > It looks that everything passed through test gate and landed in master.
> > So, this way we have full multiboot2 support in Xen. This means that
> > you can boot Xen using GRUB2 on EFI platforms.
> >
> > I would like to thank everybody who helped me to make it happen.
> > Especially Jan who patiently reviewed whole series many times
> > and replied for my stupid questions.
> >
> > Daniel
>
> Congrats Daniel.

Thank you.

Daniel

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

[Xen-devel] [PATCH for-4.9] oxenstored: remove "_proc" in names

[Wei Liu]

They aren't limited to proc file system anymore. Use more generic names.

No functional change.

Signed-off-by: Wei Liu 
---
This is a follow-up patch for "oxenstored: make it work on FreeBSD".

Cc: Ian Jackson 
Cc: d...@recoil.org
Cc: christian.lin...@citrix.com
Cc: jonathan.lud...@citrix.com
Cc: Roger Pau Monné 
---
 tools/ocaml/xenstored/define.ml  | 4 ++--
 tools/ocaml/xenstored/domains.ml | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/ocaml/xenstored/define.ml b/tools/ocaml/xenstored/define.ml
index 15b03e539f..f3d8cd6ddc 100644
--- a/tools/ocaml/xenstored/define.ml
+++ b/tools/ocaml/xenstored/define.ml
@@ -19,13 +19,13 @@ open Unix_syscalls
 let xenstored_major = 1
 let xenstored_minor = 0
 
-let xenstored_proc_kva =
+let xenstored_kva =
   let info = Unix_syscalls.uname () in
   match info.sysname with
   | "Linux" -> "/proc/xen/xsd_kva"
   | "FreeBSD" -> "/dev/xen/xenstored"
   | _ -> "nonexistent"
-let xenstored_proc_port =
+let xenstored_port =
   let info = Unix_syscalls.uname () in
   match info.sysname with
   | "Linux" -> "/proc/xen/xsd_port"
diff --git a/tools/ocaml/xenstored/domains.ml b/tools/ocaml/xenstored/domains.ml
index fdae298613..572c9fb091 100644
--- a/tools/ocaml/xenstored/domains.ml
+++ b/tools/ocaml/xenstored/domains.ml
@@ -130,8 +130,8 @@ let create xc doms domid mfn port =
 let create0 doms =
let port, interface =
(
-   let port = Utils.read_file_single_integer 
Define.xenstored_proc_port
-   and fd = Unix.openfile Define.xenstored_proc_kva
+   let port = Utils.read_file_single_integer 
Define.xenstored_port
+   and fd = Unix.openfile Define.xenstored_kva
   [ Unix.O_RDWR ] 0o600 in
let interface = Xenmmap.mmap fd Xenmmap.RDWR 
Xenmmap.SHARED
  (Xenmmap.getpagesize()) 0 in
-- 
2.11.0


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

[Xen-devel] [PATCH for-4.9 0/2] oxenstored: make it work on FreeBSD

[Wei Liu]

I managed to remove almost all Linux-ism in my previous work to make all paths
configurable.

The last bits missing are the two device node paths.

Unfortunately there is an easy way to determine system name in the standard
library so I wrote a wrapper for uname syscall.

I think this is a good candidate for inclusion in 4.9. I wouldn't be too
disappointed if they don't end up there though. I will let Julien decide.

Cc: Ian Jackson  
   
Cc: d...@recoil.org 
   
Cc: christian.lin...@citrix.com 
   
Cc: jonathan.lud...@citrix.com  
   
Cc: Roger Pau Monné    
Cc: Julien Grall 

Wei Liu (2):
  oxenstored: add an Unix syscall C extension
  oxenstored: make it work on FreeBSD

 tools/ocaml/xenstored/Makefile  |  9 --
 tools/ocaml/xenstored/define.ml | 16 --
 tools/ocaml/xenstored/unix_syscalls.ml  | 29 ++
 tools/ocaml/xenstored/unix_syscalls.mli | 29 ++
 tools/ocaml/xenstored/unix_syscalls_stubs.c | 46 +
 5 files changed, 124 insertions(+), 5 deletions(-)
 create mode 100644 tools/ocaml/xenstored/unix_syscalls.ml
 create mode 100644 tools/ocaml/xenstored/unix_syscalls.mli
 create mode 100644 tools/ocaml/xenstored/unix_syscalls_stubs.c

-- 
2.11.0


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

[Xen-devel] [PATCH for-4.9 2/2] oxenstored: make it work on FreeBSD

[Wei Liu]

Call the uname syscall to determine sysname and return device names
accordingly.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: d...@recoil.org
Cc: christian.lin...@citrix.com
Cc: jonathan.lud...@citrix.com
Cc: Roger Pau Monné 
---
 tools/ocaml/xenstored/define.ml | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/ocaml/xenstored/define.ml b/tools/ocaml/xenstored/define.ml
index 5a604d1bea..15b03e539f 100644
--- a/tools/ocaml/xenstored/define.ml
+++ b/tools/ocaml/xenstored/define.ml
@@ -14,11 +14,23 @@
  * GNU Lesser General Public License for more details.
  *)
 
+open Unix_syscalls
+
 let xenstored_major = 1
 let xenstored_minor = 0
 
-let xenstored_proc_kva = "/proc/xen/xsd_kva"
-let xenstored_proc_port = "/proc/xen/xsd_port"
+let xenstored_proc_kva =
+  let info = Unix_syscalls.uname () in
+  match info.sysname with
+  | "Linux" -> "/proc/xen/xsd_kva"
+  | "FreeBSD" -> "/dev/xen/xenstored"
+  | _ -> "nonexistent"
+let xenstored_proc_port =
+  let info = Unix_syscalls.uname () in
+  match info.sysname with
+  | "Linux" -> "/proc/xen/xsd_port"
+  | "FreeBSD" -> "/dev/xen/xenstored"
+  | _ -> "nonexistent"
 
 let xs_daemon_socket = Paths.xen_run_stored ^ "/socket"
 let xs_daemon_socket_ro = Paths.xen_run_stored ^ "/socket_ro"
-- 
2.11.0


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

[Xen-devel] [PATCH for-4.9 1/2] oxenstored: add an Unix syscall C extension

[Wei Liu]

Currently there is only uname syscall in it.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: d...@recoil.org
Cc: christian.lin...@citrix.com
Cc: jonathan.lud...@citrix.com
Cc: Roger Pau Monné 
---
 tools/ocaml/xenstored/Makefile  |  9 --
 tools/ocaml/xenstored/unix_syscalls.ml  | 29 ++
 tools/ocaml/xenstored/unix_syscalls.mli | 29 ++
 tools/ocaml/xenstored/unix_syscalls_stubs.c | 46 +
 4 files changed, 110 insertions(+), 3 deletions(-)
 create mode 100644 tools/ocaml/xenstored/unix_syscalls.ml
 create mode 100644 tools/ocaml/xenstored/unix_syscalls.mli
 create mode 100644 tools/ocaml/xenstored/unix_syscalls_stubs.c

diff --git a/tools/ocaml/xenstored/Makefile b/tools/ocaml/xenstored/Makefile
index d23883683d..cfd4d81b9e 100644
--- a/tools/ocaml/xenstored/Makefile
+++ b/tools/ocaml/xenstored/Makefile
@@ -18,12 +18,14 @@ OCAMLINCLUDE += \
-I $(OCAML_TOPLEVEL)/libs/xc \
-I $(OCAML_TOPLEVEL)/libs/eventchn
 
-LIBS = syslog.cma syslog.cmxa select.cma select.cmxa
+LIBS = syslog.cma syslog.cmxa select.cma select.cmxa unix_syscalls.cma 
unix_syscalls.cmxa
 syslog_OBJS = syslog
 syslog_C_OBJS = syslog_stubs
 select_OBJS = select
 select_C_OBJS = select_stubs
-OCAML_LIBRARY = syslog select
+unix_syscalls_C_OBJS = unix_syscalls_stubs
+unix_syscalls_OBJS = unix_syscalls
+OCAML_LIBRARY = syslog select unix_syscalls
 
 LIBS += systemd.cma systemd.cmxa
 systemd_OBJS = systemd
@@ -58,13 +60,14 @@ OBJS = paths \
process \
xenstored
 
-INTF = symbol.cmi trie.cmi syslog.cmi systemd.cmi select.cmi
+INTF = symbol.cmi trie.cmi syslog.cmi systemd.cmi select.cmi unix_syscalls.cmi
 
 XENSTOREDLIBS = \
unix.cmxa \
-ccopt -L -ccopt . syslog.cmxa \
-ccopt -L -ccopt . systemd.cmxa \
-ccopt -L -ccopt . select.cmxa \
+   -ccopt -L -ccopt . unix_syscalls.cmxa \
-ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/mmap 
$(OCAML_TOPLEVEL)/libs/mmap/xenmmap.cmxa \
-ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/eventchn 
$(OCAML_TOPLEVEL)/libs/eventchn/xeneventchn.cmxa \
-ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/xc 
$(OCAML_TOPLEVEL)/libs/xc/xenctrl.cmxa \
diff --git a/tools/ocaml/xenstored/unix_syscalls.ml 
b/tools/ocaml/xenstored/unix_syscalls.ml
new file mode 100644
index 00..b52a07967d
--- /dev/null
+++ b/tools/ocaml/xenstored/unix_syscalls.ml
@@ -0,0 +1,29 @@
+(*
+ * unix_syscalls.ml
+ *
+ * Stubs for unix syscalls
+ *
+ * Copyright (C) 2017  Wei Liu 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License, version 2.1, as published by the Free Software Foundation.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ *)
+
+type utsname = {
+  sysname:  string;
+  nodename: string;
+  release:  string;
+  version:  string;
+  machine:  string;
+}
+
+external uname : unit -> utsname = "unix_uname"
diff --git a/tools/ocaml/xenstored/unix_syscalls.mli 
b/tools/ocaml/xenstored/unix_syscalls.mli
new file mode 100644
index 00..8e9adaf0a4
--- /dev/null
+++ b/tools/ocaml/xenstored/unix_syscalls.mli
@@ -0,0 +1,29 @@
+(*
+ * unix_syscalls.mli
+ *
+ * Stubs for unix syscalls
+ *
+ * Copyright (C) 2017  Wei Liu 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License, version 2.1, as published by the Free Software Foundation.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ *)
+
+type utsname = {
+  sysname:  string;
+  nodename: string;
+  release:  string;
+  version:  string;
+  machine:  string;
+}
+
+external uname : unit -> utsname = "unix_uname"
diff --git a/tools/ocaml/xenstored/unix_syscalls_stubs.c 
b/tools/ocaml/xenstored/unix_syscalls_stubs.c
new file mode 100644
index 00..1cd46d0834
--- /dev/null
+++ b/tools/ocaml/xenstored/unix_syscalls_stubs.c
@@ -0,0 +1,46 @@
+/*
+ * unix_syscalls_stub.c
+ *
+ * Stubs for unix syscalls
+ *
+ * Copyright (C) 2017  Wei Liu 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify 

Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson  wrote:
> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV 
> display device driver interface"):
>> After internal discussion we think that putting positions and
>> z-orders of virtual connectors to the Xen store and libxl
>> configuration is not so good idea. Because their composition depends
>> on an application and usage. We consider automotive usage.  For
>> example one of domain drives navigation system and depends on
>> scenario the navigation window position and size can be changed. In
>> that case on the host should be an instance of window manager or
>> something like that.  The window manager will decide where to put
>> the virtual displays.
>
> Right.
>
>> If it is ok, following is libxl/xl configuration proposal:
>
> This looks much better to me.  (See of course Wei's point about the
> connector list ambiguity.)
>
> Can you sketch out what the rest of the system does, then ?
> Presumably there has to be a different control protocol to your
> backend, to tell it where to put the actual displays.  I think it
> would be good if that protocol were the same for different use cases,
> and documented somewhere.

Well, yes there will be some protocol to communicate with the window manager.
We consider to use wayland and weston as display system.
The idea is the backend and other applications on the host render content onto
wayland surfaces. Each surface will have  a unique identifier or attribute
(like multimedia, navigation etc.). The window manager based on these
attributes, configured policies and scenarios will set positions and geometries
for the surfaces.

> So for example, when a window manager moves a window, how is the
> backend told where to display the guest output ?

The backend will create the wayland surface and tell the window manager
the attribute it has. All rest will be done by the window manager.

> Your final patches should come with changese to the xl.cfg
> documentation, but I think we can still discuss this in generalities
> for now and then the text you write in your emails or example comments
> will make a good starting point for the xl.cfg documentation.

In my opinion the details how the virtual displays are placed on the host
should be separated from xl configuration. Because it really depends on
backend implementation. We have generalized display protocol (displif.h).
There could be different frontend/backend implementations and each
implementation will require its own configuration.
That's why in xl.cfg should be only parameters related to display protocol
namely resolutions of virtual connectors.


> Thanks,
> Ian.

-- 
Best Regards,
Oleksandr Grytsov.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 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 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  8e09663f7ff70b10a560746f17897d2c67c8460d
baseline version:
 libvirt  bdcf6e481072d9d98a0dc60f08572340d55fb48f

Last test of basis   107417  2017-04-13 04:31:55 Z1 days
Testing same since   107442  2017-04-14 04:27:41 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  John Ferlan 
  Ján Tomko 
  Peter Krempa 
  Shivaprasad G Bhat 
  Wang King 
  Wim ten Have 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsfail
 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-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 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 

[Xen-devel] [distros-debian-jessie test] 71192: tolerable trouble: blocked/broken/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-jessie-netboot-pygrub  1 build-check(1) blocked n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 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   71160

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-arm64-arm64-armhf-jessie-netboot-pygrub blocked 
 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

Re: [Xen-devel] [stable-4.9: PATCH] xen: revert commit 72a9b186292

[Greg KH]

On Thu, Apr 13, 2017 at 03:06:53PM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more.
> 
> It is still necessary for old Xen versions (< 4.0) and for being able
> to run the Linux kernel as dom0 in a nested Xen environment.

What is the commit id of this revert in Linus's tree?

thanks,

greg k-h

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

[Xen-devel] [xen-4.4-testing test] 107439: regressions - FAIL

[osstest service owner]

flight 107439 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107439/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 107422 
REGR. vs. 106822

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl 4 host-ping-check-native fail in 107422 pass in 107439
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 107422 pass 
in 107439
 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 107422 pass in 107439
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 
107422 pass in 107439
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install fail pass in 107422

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail blocked in 106822
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pae-invlpg~shadow fail like 106822
 test-xtf-amd64-amd64-3   44 xtf/test-hvm64-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-2   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-1   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-4   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-5   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-3   54 leak-check/check fail  like 106822
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106822
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106822
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106822

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-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-3   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   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
 test-armhf-armhf-libvirt 11 guest-start  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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl

Re: [Xen-devel] [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend

[Juergen Gross]

On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko 
>>>
>>> For some use cases when Xen framebuffer/input backend
>>> is not a part of Qemu it is required to disable it,
>>> because of conflicting access to input/display devices.
>>> Introduce additional configuration option for explicit
>>> input/display control.
>> In these cases when you don't want xenfb, why don't you just remove
>> "vfb" from the xl config file? QEMU only starts the xenfb backend when
>> requested by the toolstack.
>>
>> Is it because you have an alternative xenfb backend? If so, is it really
>> fully xenfb compatible, or is it a different protocol? If it is a
>> different protocol, I suggest you rename your frontend/backend PV device
>> name to something different from "vfb".
>>
> Well, offending part is vkbd actually (for multi-touch
> we run our own user-space backend which supports
> kbd/ptr/mtouch), but vfb and vkbd is the same backend
> in QEMU. So, I am ok for vfb, but just want vkbd off
> So, there are 2 options:
> 1. At compile time remove vkbd and still allow vfb
> 2. Remove xenfb completely, if acceptable (this is my case)

What about adding a Xenstore entry for backend type and let qemu test
for it being not present or containing "qemu"?


Juergen

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e06179889586c37101e2900e7f52be9f0da12cda
baseline version:
 ovmf d63ed30bb508f46ec304cf1431a67c8f9f2fe0bf

Last test of basis   107425  2017-04-13 11:45:49 Z0 days
Testing same since   107440  2017-04-14 03:16:15 Z0 days1 attempts


People who touched revisions under test:
  Liming Gao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 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=e06179889586c37101e2900e7f52be9f0da12cda
+ . ./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 
e06179889586c37101e2900e7f52be9f0da12cda
+ branch=ovmf
+ revision=e06179889586c37101e2900e7f52be9f0da12cda
+ . ./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.8-testing
+ '[' xe06179889586c37101e2900e7f52be9f0da12cda = 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
++ : 

Re: [Xen-devel] [PATCH v3] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

[Tian, Kevin]

> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Monday, February 6, 2017 7:33 PM
> 
> On Fri, 2017-01-27 at 10:36 -0500, Konrad Rzeszutek Wilk wrote:
> > . snip ..
> > >
> > > >
> > > > Signed-off-by: David Woodhouse 
> > > Reviewed-by: Jan Beulich 
> > >
> > > But before committing I'd prefer to have a VMX maintainer ack
> > > too.
> > Who is gone until Feb yth (Spring festival in China).
> 
> Not sure what number that 'y' was supposed to be, but I see Kevin
> posting today... :)
> 
> Would also be very good to have a definitive answer about the safety of
> mixing WC and UC on MMIO mappings on Intel hardware.

answer is yes, it's safe.

Thanks
Kevin

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  6 xen-bootfail REGR. vs. 107397

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  7a481bfa4f6a623e87a4bac3b50a5ef5924d9f2c
baseline version:
 xen  17cd6621688bce9972d924264fd7aba44c31

Last test of basis   107397  2017-04-12 13:22:43 Z1 days
Failing since107420  2017-04-13 06:29:23 Z1 days2 attempts
Testing same since   107438  2017-04-13 21:23:55 Z0 days1 attempts


People who touched revisions under test:
  Chao Gao 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Luwei Kang 
  Praveen Kumar 
  Roger Pau Monné 
  Wei Liu 

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

Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup

[Bhupinder Thakur]

Hi Stefano,

On 12 April 2017 at 03:37, Stefano Stabellini  wrote:
> On Tue, 11 Apr 2017, Bhupinder Thakur wrote:
>> Hi,
>>
>> Kindly let me know if my understanding is correct.
>>
>> Using a domctl API will allow us to keep the vUART configuration
>> flexible. Currently, we can operate on one ring-buf PFN and an event
>> channel port only for a single vUART but if we use DOMCTL interface,
>> then we can effectively get/set multiple event channel ports/multiple
>> PFNs from/to Xen in a single domctl call.
>>
>> I am not clear who will be the caller of this domctl API. Is it
>> xenconsoled or the toolstack? Currently, xenconsoled reads the
>> ring-buf PFN and event channel from the xenstore, which is populated
>> by the toolstack.
>
> The caller could be either, but I think it would make sense for it to be
> xenconsoled to cut the middle-man (xl).
>
I see the issue with Xenconsoled getting the PFN using a DOMCTL API.

PFN is allocated in alloc_magic_pages() which is part of
libxenguest.so and the DOMCTL API is part of libxenctrl.so. As per my
understanding, libxenguest.so has dependency on libxenctrl.so but not
the other way round.So I am not sure how libxenctrl can call into
libxenguest to get the PFN.

If the DOMCTL API is called from libxenguest then I can get the PFN easily.

Regards,
Bhupinder

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

[Xen-devel] [linux-4.9 test] 107437: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 107358

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 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-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linuxcf2586e60ede2217d7f53a0585e27e1cca693600
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z3 days
Testing same since   107396  2017-04-12 11:15:19 Z1 days3 attempts


People who touched revisions under test:
  Adrian Hunter 
  Alan Stern 
  Alberto Aguirre 
  Alex Deucher 
  Alex Williamson 
  Alex Wood 
  Alexander Polakov 
  Alexander Polyakov 
  Andrew Morton 
  Andrey Smetanin 
  Andy Gross 
  Andy Shevchenko 
  Arend van Spriel 
  Arnd Bergmann 
  Aurelien Aptel 
  Baoyou Xie 
  Bartosz Golaszewski 
  Bastien Nocera 
  Ben Segall 
  Benjamin Herrenschmidt 
  Benjamin Tissoires 
  Bjorn Helgaas 
  Bjørn Mork 
  Boris Brezillon 
  Brian Norris 
  bseg...@google.com 
  Calvin Owens 

Re: [Xen-devel] [PATCH 3/3] x86/HVM: don't uniformly report "MMIO" for various forms of failed emulation

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, April 13, 2017 10:54 PM
> 
> This helps distingushing the call paths leading there.
> 
> Signed-off-by: Jan Beulich 
> 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 2/3] VMX: don't blindly enable descriptor table exiting control

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, April 13, 2017 10:53 PM
> 
> This is an optional feature and hence we should check for it before
> use.
> 
> Signed-off-by: Jan Beulich 
> 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend

[Oleksandr Andrushchenko]

On 04/14/2017 03:12 AM, Stefano Stabellini wrote:

On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

For some use cases when Xen framebuffer/input backend
is not a part of Qemu it is required to disable it,
because of conflicting access to input/display devices.
Introduce additional configuration option for explicit
input/display control.

In these cases when you don't want xenfb, why don't you just remove
"vfb" from the xl config file? QEMU only starts the xenfb backend when
requested by the toolstack.

Is it because you have an alternative xenfb backend? If so, is it really
fully xenfb compatible, or is it a different protocol? If it is a
different protocol, I suggest you rename your frontend/backend PV device
name to something different from "vfb".


Well, offending part is vkbd actually (for multi-touch
we run our own user-space backend which supports
kbd/ptr/mtouch), but vfb and vkbd is the same backend
in QEMU. So, I am ok for vfb, but just want vkbd off
So, there are 2 options:
1. At compile time remove vkbd and still allow vfb
2. Remove xenfb completely, if acceptable (this is my case)

Signed-off-by: Oleksandr Andrushchenko 
---
  configure | 18 ++
  hw/display/Makefile.objs  |  2 +-
  hw/xen/xen_backend.c  |  2 ++
  hw/xenpv/xen_machine_pv.c |  4 
  4 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 476210b1b93f..b805cb908f03 100755
--- a/configure
+++ b/configure
@@ -220,6 +220,7 @@ xen=""
  xen_ctrl_version=""
  xen_pv_domain_build="no"
  xen_pci_passthrough=""
+xen_fb_backend=""
  linux_aio=""
  cap_ng=""
  attr=""
@@ -909,6 +910,10 @@ for opt do
;;
--enable-xen-pv-domain-build) xen_pv_domain_build="yes"
;;
+  --disable-xen-fb-backend) xen_fb_backend="no"
+  ;;
+  --enable-xen-fb-backend) xen_fb_backend="yes"
+  ;;
--disable-brlapi) brlapi="no"
;;
--enable-brlapi) brlapi="yes"
@@ -1368,6 +1373,7 @@ disabled with --disable-FEATURE, default is enabled if 
available:
virtfs  VirtFS
xen xen backend driver support
xen-pci-passthrough
+  xen-fb-backend  framebuffer/input backend support
brlapi  BrlAPI (Braile)
curlcurl connectivity
fdt fdt device tree
@@ -2213,6 +2219,15 @@ if test "$xen_pv_domain_build" = "yes" &&
   "which requires Xen support."
  fi
  
+if test "$xen_fb_backend" != "no"; then

+   if test "$xen" = "yes"; then
+ xen_fb_backend=yes
+   else
+ error_exit "User requested feature Xen framebufer backend support" \
+" but this feature requires Xen support."
+   fi
+fi
+
  ##
  # Sparse probe
  if test "$sparse" != "no" ; then
@@ -5444,6 +5459,9 @@ if test "$xen" = "yes" ; then
if test "$xen_pv_domain_build" = "yes" ; then
  echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
fi
+  if test "$xen_fb_backend" = "yes" ; then
+echo "CONFIG_XEN_FB_BACKEND=y" >> $config_host_mak
+  fi
  fi
  if test "$linux_aio" = "yes" ; then
echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 063889beaf4a..f5ec97ed4f48 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -5,7 +5,7 @@ common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o
  common-obj-$(CONFIG_PL110) += pl110.o
  common-obj-$(CONFIG_SSD0303) += ssd0303.o
  common-obj-$(CONFIG_SSD0323) += ssd0323.o
-common-obj-$(CONFIG_XEN_BACKEND) += xenfb.o
+common-obj-$(CONFIG_XEN_FB_BACKEND) += xenfb.o
  
  common-obj-$(CONFIG_VGA_PCI) += vga-pci.o

  common-obj-$(CONFIG_VGA_ISA) += vga-isa.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index d1190041ae12..5146cbba6ca5 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -582,7 +582,9 @@ void xen_be_register_common(void)
  xen_set_dynamic_sysbus();
  
  xen_be_register("console", _console_ops);

+#ifdef CONFIG_XEN_FB_BACKEND
  xen_be_register("vkbd", _kbdmouse_ops);
+#endif
  xen_be_register("qdisk", _blkdev_ops);
  #ifdef CONFIG_USB_LIBUSB
  xen_be_register("qusb", _usb_ops);
diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 79aef4ecc37b..b731344c3f0a 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -68,7 +68,9 @@ static void xen_init_pv(MachineState *machine)
  }
  
  xen_be_register_common();

+#ifdef CONFIG_XEN_FB_BACKEND
  xen_be_register("vfb", _framebuffer_ops);
+#endif
  xen_be_register("qnic", _netdev_ops);
  
  /* configure framebuffer */

@@ -95,8 +97,10 @@ static void xen_init_pv(MachineState *machine)
  /* config cleanup hook */
  atexit(xen_config_cleanup);
  
+#ifdef CONFIG_XEN_FB_BACKEND

  /* setup framebuffer */
  xen_init_display(xen_domid);
+#endif
  }
  
  static void xenpv_machine_init(MachineClass *mc)

--