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

2017-10-27 Thread osstest service owner 
flight 115295 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115295/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114644
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114644

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  10 debian-install   fail in 115272 pass in 115295
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 115272 pass in 
115295
 test-armhf-armhf-xl-arndale   6 xen-install  fail in 115272 pass in 115295
 test-armhf-armhf-xl-cubietruck  6 xen-install  fail pass in 115272
 test-armhf-armhf-xl-multivcpu  6 xen-install   fail pass in 115272

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 115272 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 115272 
never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 115272 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 115272 
never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114644
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114644
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114644
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114644
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114644
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114644
 test-amd64-amd64-examine  4 memdisk-try-append   fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  03dd1e2a5414faf86f743ae96c2b63dbc81f27f6
baseline version:
 xen  24fb44e971a62b345c7b6ca3c03b454a1e150abe

Last test of basis   114644  2017-10-17 10:49:11 Z   10 days
Failing since114670  2017-10-18 05:03:38 Z   10 days   14 attempts
Testing same since   115235  2017-10-25 19:25:31 Z2 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Chao Gao 
  David Esler

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

2017-10-27 Thread osstest service owner 
flight 115290 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115290/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 114658
 test-armhf-armhf-xl-arndale   7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 114682
 build-amd64-pvops 6 kernel-build fail REGR. vs. 114682
 test-armhf-armhf-xl-xsm   7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-xl-credit2   7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-libvirt-xsm  7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-libvirt-raw  7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-libvirt  7 xen-boot fail REGR. vs. 114682
 test-armhf-armhf-xl-cubietruck  7 xen-boot   fail REGR. vs. 114682
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail REGR. vs. 114682

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  7 xen-boot fail REGR. vs. 114682

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-examine  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 114682
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux36ef71cae353f88fd6e095e2aaa3e5953af1685d
baseline version:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   114796  2017-10-20 09:26:55 Z

[Xen-devel] [PATCH] xen/pt: Set is_express to avoid out-of-bounds write

2017-10-27 Thread Simon Gaiser 
The passed-through device might be an express device. In this case the
old code allocated a too small emulated config space in
pci_config_alloc() since pci_config_size() returned the size for a
non-express device. This leads to an out-of-bound write in
xen_pt_config_reg_init(), which sometimes results in crashes. So set
is_express as already done for KVM in vfio-pci.

Shortened ASan report:

==17512==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x61141648 at pc 0x55e0fdac51ff bp 0x7ffe4af07410 sp 0x7ffe4af07408
WRITE of size 2 at 0x61141648 thread T0
#0 0x55e0fdac51fe in memcpy /usr/include/x86_64-linux-gnu/bits/string3.h:53
#1 0x55e0fdac51fe in stw_he_p include/qemu/bswap.h:330
#2 0x55e0fdac51fe in stw_le_p include/qemu/bswap.h:379
#3 0x55e0fdac51fe in pci_set_word include/hw/pci/pci.h:490
#4 0x55e0fdac51fe in xen_pt_config_reg_init hw/xen/xen_pt_config_init.c:1991
#5 0x55e0fdac51fe in xen_pt_config_init hw/xen/xen_pt_config_init.c:2067
#6 0x55e0fdabcf4d in xen_pt_realize hw/xen/xen_pt.c:830
#7 0x55e0fdf59666 in pci_qdev_realize hw/pci/pci.c:2034
#8 0x55e0fdda7d3d in device_set_realized hw/core/qdev.c:914
[...]

0x61141648 is located 8 bytes to the right of 256-byte region 
[0x61141540,0x61141640)
allocated by thread T0 here:
#0 0x7ff596a94bb8 in __interceptor_calloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9bb8)
#1 0x7ff57da66580 in g_malloc0 
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x50580)
#2 0x55e0fdda7d3d in device_set_realized hw/core/qdev.c:914
[...]

Signed-off-by: Simon Gaiser 
---

I found this by debugging crashes and I'm not familiar with this code,
so I'm not sure if this has no unintended side effects.

 hw/xen/xen_pt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index b6d71bb52a..90ffd45e7d 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -946,6 +946,7 @@ static void xen_pci_passthrough_class_init(ObjectClass 
*klass, void *data)
 k->exit = xen_pt_unregister_device;
 k->config_read = xen_pt_pci_read_config;
 k->config_write = xen_pt_pci_write_config;
+k->is_express = 1; /* We might be */
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
 dc->desc = "Assign an host PCI device with Xen";
 dc->props = xen_pci_passthrough_properties;
-- 
2.15.0.rc1


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

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

2017-10-27 Thread osstest service owner 
flight 115299 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115299/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507

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

[Xen-devel] [linux-3.18 test] 115289: tolerable FAIL - PUSHED

2017-10-27 Thread osstest service owner 
flight 115289 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115289/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114843
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114843
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114843
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114843
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114843
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114843
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114843
 test-amd64-amd64-examine  4 memdisk-try-append   fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxb44ef85f9033720e7ec6aa7bc9536b9e4b09719a
baseline version:
 linux6f457819e8343ae097b7122a57694d26d4ce13b0

Last test of basis   114843  2017-10-21 15:24:32 Z6 days
Testing same since   115289  2017-10-27 08:53:22 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alexander Drozdov 
  Andrey Konovalov 
  Arend van Spriel 
  Arnd Bergmann 
  Ben Hutchings 
  Christoph Biedl 
  Cong Wang 
  David Howells 
  David S. Miller 
  Eric Biggers 
  Felipe Balbi 
  Greg Kroah-Hartman 
  Gregory CLEMENT 
  Hans de Goede 
  Helge Deller 
  Ignacy

Re: [Xen-devel] Booting signed xen.efi through shim

2017-10-27 Thread Tamas K Lengyel 
On Fri, Sep 22, 2017 at 5:11 PM, Daniel Kiper  wrote:
> On Fri, Sep 22, 2017 at 02:25:46AM -0600, Jan Beulich wrote:
>> >>> On 22.09.17 at 00:46,  wrote:
>> > One piece that I see still missing is the Xen command line parameters
>> > not being verified. It would be ideal to have the option to get that
>> > set during compile time as well, similar to Linux's CONFIG_CMDLINE
>> > option, to avoid for example getting iommu or XSM being turned off by
>> > someone with physical access.
>>
>> We do have CMDLINE and CMDLINE_OVERRIDE. But for someone
>> with physical access it would likely also be possible to avoid secure
>> boot altogether?
>
> Another solutions is here: 
> http://lists.gnu.org/archive/html/grub-devel/2017-07/msg3.html
> It is TPM based and WIP. It requires verifiers framework which should
> be posted on grub-devel soon. Or you can add your own method based
> on verifiers. Patches are welcome...
>
> Have a nice weekend,
>
> Daniel

There is an additional problem with Xen.efi being measured into TPM2
devices through the shim. The shim uses the PE_COFF_IMAGE flag when
calling TPM2's HashLogExtendEvent function. At least on my Dell
ultrabook this causes the TPM to return EFI_UNSUPPORTED error, which
according to the spec means "If the Flags bitmap has the PE_COFF_IMAGE
bit SET but the PE/COFF image is corrupt or not understood the
function shall return EFI_UNSUPPORTED". As by default the shim ignores
TPM errors (yikes!) and the verification step works, xen can
successfully boot afterwards, but AFAICT without a measurement being
stored in TPM2. At the moment unfortunately I have no idea why TPM2
have a problem interpreting Xen.efi properly. For now an easy "fix" is
to just have the shim call without PE_COFF_IMAGE flag. If anyone else
has a TPM2 device, it might be worthwhile double-checking whether it's
just a problem with my specific TPM or if it's a problem with
Xen.efi's PE/COFF header.

Tamas

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

Re: [Xen-devel] [PATCH v2] xen: support 52 bit physical addresses in pv guests

2017-10-27 Thread Boris Ostrovsky 



On 10/27/2017 01:49 PM, Juergen Gross wrote:

Physical addresses on processors supporting 5 level paging can be up to
52 bits wide. For a Xen pv guest running on such a machine those
physical addresses have to be supported in order to be able to use any
memory on the machine even if the guest itself does not support 5 level
paging.

So when reading/writing a MFN from/to a pte don't use the kernel's
PTE_PFN_MASK but a new XEN_PTE_MFN_MASK allowing full 40 bit wide MFNs.

Signed-off-by: Juergen Gross 


Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

2017-10-27 Thread Stefano Stabellini 
On Fri, 27 Oct 2017, Julien Grall wrote:
> On 27/10/17 08:27, Hao, Xudong wrote:
> > This bug exist much long time, there are many discussion last year but not a
> > solution then. I call out it now because there is a fix in qemu upstream:
> > commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
> > Author: Roger Pau Monne 
> > Date:   Thu Aug 24 16:07:03 2017 +0100
> > 
> >  xen/pt: allow QEMU to request MSI unmasking at bind time
> > 
> > The fix is not in qemu-xen tree yet, when will qemu-xen sync this fix? Is it
> > possible to catch Xen 4.10's qemu-xen?
> 
> I will let Stefano and Anthony providing feedback before giving a release-ack
> here.

Yes, I think we should backport the commit as it fixes a genuine bug.
The backport is not risk-free but it only affects PCI Passthrough. Also
the commit has been in QEMU for 2 months now.


> > 
> > BTW, mail report bug is direct but not easy to track, I took much time to
> > search this BUG report mail. @Lars, is there plan to introduce any bug
> > system for Xen?
> 
> We recently introduced Jira ([1]) to track features and bugs.
> 
> [1] https://xenproject.atlassian.net/projects/XEN/issues.
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

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

[Xen-devel] [PATCH] hw/display/xenfb: Simulate auto-repeat key events

2017-10-27 Thread Liang Yan 
New tigervnc server changes the way to send long pressed key,
from "down up down up ..." to "down down ... up". So we insert
an up event after each key down event to simulate auto-repeat
key events for xen keyboard frontend driver.

Signed-off-by: Liang Yan 
---
 hw/display/xenfb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 8e2547ac05..a5f787a3f3 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -292,6 +292,9 @@ static void xenfb_key_event(void *opaque, int scancode)
 }
 trace_xenfb_key_event(opaque, scancode2linux[scancode], down);
 xenfb_send_key(xenfb, down, scancode2linux[scancode]);
+if (down) { /* simulate auto-repeat key events */
+xenfb_send_key(xenfb, 0, scancode2linux[scancode]);
+}
 }
 
 /*
-- 
2.14.2


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

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

2017-10-27 Thread Julien Grall 
On 27 Oct 2017 20:59, "Stefano Stabellini"  wrote:

On Fri, 27 Oct 2017, Julien Grall wrote:
> Hi,
>
> Just answering to dom0 been 1:1 domain.
>
> On 24/10/17 22:33, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2017, Volodymyr Babchuk wrote:
> > > > For this series, I think we need a way to specify which domains can
talk
> > > > to TEE, so that we can only allow it for a specific subset of
DomUs. I
> > > > would probably use XSM for that.
> > > I am afraid, this is not possible. As other domains aren't 1:1 mapped,
> > > I need to have special translation code in mediator. Actually, I'm
> > > writing it rigth now to test my changes in OP-TEE. But event this is
> > > not enought for decent OP-TEE support.
> > > What can be done right now: 100% Dom0-only support with vanilla
> > > OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
> > > even simplier task, so I can throw out some code from this patch
> > > series. On other hand, in the future this will lead to sutiation when
> > > two mediators for the same TEE shall be supported: one, simple, in
> > > XEN, another, fully-functional in stubdom.
> >
> > I think it is fine to support OP-TEE only in Dom0 to begin with.
> >
> > Ideally, it would be in Dom0 for convenience and speed and the OP-TEE
> > capability would be specified as an XSM label. Ideally, it would not be
> > only in Dom0 because it is tied to the 1:1 map, but I understand now
> > that it is a requirement. I still think that the XSM label would be good
> > to have even if today it cannot be changed as only Dom0 is 1:1.
>
> I thought a bit more about Dom0 been a 1:1 domain. It is only true for
Device
> Memory and the initial RAM allocated for Dom0.
>
> Dom0 may balloon out some pages because it has to map region belonging to
> other domain. Those regions will not be 1:1 mapped and translation will be
> needed if used.
>
> The problem is very similar to DMA in dom0. I can't see any reason to not
use
> those regions with OP-TEE. Am I wrong here?

I think you are right. For DMA, Dom0 is expected to use the swiotlb-xen
driver to solve the problem, because it is a genuine use case to have
foreign grants involved in a DMA operation.

For OP-TEE, I don't think we need to support this case? Xen could fail
the request if it involves a page that is not 1:1 mapped?


You would need to introspect the message in order to know that. So
supporting non 1:1 mapped page would not be more difficult.

This assuming that you know when you OP-TEE is done with the page.

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

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

2017-10-27 Thread osstest service owner 
flight 115303 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115303/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  bb2c1a1cc98a22e2d4c14b18421aa7be6c2adf0d
baseline version:
 xen  6c1a029aef07f6962716a5a7b3d6b942281f4e4e

Last test of basis   115301  2017-10-27 15:04:56 Z0 days
Testing same since   115303  2017-10-27 18:08:19 Z0 days1 attempts


People who touched revisions under test:
  Andre Przywara 
  Bhupinder Thakur 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

2017-10-27 Thread Stefano Stabellini 
On Fri, 27 Oct 2017, Julien Grall wrote:
> Hi,
> 
> Just answering to dom0 been 1:1 domain.
> 
> On 24/10/17 22:33, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2017, Volodymyr Babchuk wrote:
> > > > For this series, I think we need a way to specify which domains can talk
> > > > to TEE, so that we can only allow it for a specific subset of DomUs. I
> > > > would probably use XSM for that.
> > > I am afraid, this is not possible. As other domains aren't 1:1 mapped,
> > > I need to have special translation code in mediator. Actually, I'm
> > > writing it rigth now to test my changes in OP-TEE. But event this is
> > > not enought for decent OP-TEE support.
> > > What can be done right now: 100% Dom0-only support with vanilla
> > > OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
> > > even simplier task, so I can throw out some code from this patch
> > > series. On other hand, in the future this will lead to sutiation when
> > > two mediators for the same TEE shall be supported: one, simple, in
> > > XEN, another, fully-functional in stubdom.
> > 
> > I think it is fine to support OP-TEE only in Dom0 to begin with.
> > 
> > Ideally, it would be in Dom0 for convenience and speed and the OP-TEE
> > capability would be specified as an XSM label. Ideally, it would not be
> > only in Dom0 because it is tied to the 1:1 map, but I understand now
> > that it is a requirement. I still think that the XSM label would be good
> > to have even if today it cannot be changed as only Dom0 is 1:1.
> 
> I thought a bit more about Dom0 been a 1:1 domain. It is only true for Device
> Memory and the initial RAM allocated for Dom0.
> 
> Dom0 may balloon out some pages because it has to map region belonging to
> other domain. Those regions will not be 1:1 mapped and translation will be
> needed if used.
> 
> The problem is very similar to DMA in dom0. I can't see any reason to not use
> those regions with OP-TEE. Am I wrong here?

I think you are right. For DMA, Dom0 is expected to use the swiotlb-xen
driver to solve the problem, because it is a genuine use case to have
foreign grants involved in a DMA operation.

For OP-TEE, I don't think we need to support this case? Xen could fail
the request if it involves a page that is not 1:1 mapped?

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

Re: [Xen-devel] [PATCH 12/16] osstest: add script to install build dependencies on FreeBSD

2017-10-27 Thread Ian Jackson 
Roger Pau Monne writes ("[PATCH 12/16] osstest: add script to install build 
dependencies on FreeBSD"):
> Since at the moment osstest only builds FreeBSD on FreeBSD, there are
> no dependencies to install. Just mark the host as ready to share.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 14/16] osstest: add support for FreeBSD buildjobs to sg-run-job

2017-10-27 Thread Ian Jackson 
Roger Pau Monne writes ("[PATCH 14/16] osstest: add support for FreeBSD 
buildjobs to sg-run-job"):
> Add support and introduce a FreeBSD build job to sg-run-job.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 04/16] osstest: introduce host_shared_mark_ready

2017-10-27 Thread Ian Jackson 
Roger Pau Monne writes ("[PATCH 04/16] osstest: introduce 
host_shared_mark_ready"):
> That allows marking a host as ready to be shared. Replace the current
> callers that open-code it.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v13:
>  - s/resource_shared_mark_ready/host_shared_mark_ready/.
>  - First argument of jobdb_resource_shared_mark_ready must be 'host'.

Although it would be good to mention that you are fixing a bug here,
to wit the $ho->{Ident} to 'host' change.

Acked-by: Ian Jackson 

Thanks,
Ian.

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

[Xen-devel] [PATCH v2] xen: support 52 bit physical addresses in pv guests

2017-10-27 Thread Juergen Gross 
Physical addresses on processors supporting 5 level paging can be up to
52 bits wide. For a Xen pv guest running on such a machine those
physical addresses have to be supported in order to be able to use any
memory on the machine even if the guest itself does not support 5 level
paging.

So when reading/writing a MFN from/to a pte don't use the kernel's
PTE_PFN_MASK but a new XEN_PTE_MFN_MASK allowing full 40 bit wide MFNs.

Signed-off-by: Juergen Gross 
---
V2:
- use __sme_clr() to clear any SME bit from MFN (Boris Ostrovsky)
---
 arch/x86/include/asm/xen/page.h | 11 ++-
 arch/x86/xen/mmu_pv.c   |  4 ++--
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 07b6531813c4..90e91003fd9d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -26,6 +26,15 @@ typedef struct xpaddr {
phys_addr_t paddr;
 } xpaddr_t;
 
+#ifdef CONFIG_X86_64
+#define XEN_PHYSICAL_MASK  __sme_clr((1UL << 52) - 1)
+#else
+#define XEN_PHYSICAL_MASK  __PHYSICAL_MASK
+#endif
+
+#define XEN_PTE_MFN_MASK   ((pteval_t)(((signed long)PAGE_MASK) & \
+   XEN_PHYSICAL_MASK))
+
 #define XMADDR(x)  ((xmaddr_t) { .maddr = (x) })
 #define XPADDR(x)  ((xpaddr_t) { .paddr = (x) })
 
@@ -277,7 +286,7 @@ static inline unsigned long bfn_to_local_pfn(unsigned long 
mfn)
 
 static inline unsigned long pte_mfn(pte_t pte)
 {
-   return (pte.pte & PTE_PFN_MASK) >> PAGE_SHIFT;
+   return (pte.pte & XEN_PTE_MFN_MASK) >> PAGE_SHIFT;
 }
 
 static inline pte_t mfn_pte(unsigned long page_nr, pgprot_t pgprot)
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 71495f1a86d7..9d9cc3870722 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -315,7 +315,7 @@ void xen_ptep_modify_prot_commit(struct mm_struct *mm, 
unsigned long addr,
 static pteval_t pte_mfn_to_pfn(pteval_t val)
 {
if (val & _PAGE_PRESENT) {
-   unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
+   unsigned long mfn = (val & XEN_PTE_MFN_MASK) >> PAGE_SHIFT;
unsigned long pfn = mfn_to_pfn(mfn);
 
pteval_t flags = val & PTE_FLAGS_MASK;
@@ -1735,7 +1735,7 @@ static unsigned long __init m2p(phys_addr_t maddr)
 {
phys_addr_t paddr;
 
-   maddr &= PTE_PFN_MASK;
+   maddr &= XEN_PTE_MFN_MASK;
paddr = mfn_to_pfn(maddr >> PAGE_SHIFT) << PAGE_SHIFT;
 
return paddr;
-- 
2.12.3


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

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

2017-10-27 Thread Igor Druzhinin 
On 16/02/17 11:15, Jan Beulich wrote:
> When __context_switch() is being bypassed during original context
> switch handling, the vCPU "owning" the VMCS partially loses control of
> it: It will appear non-running to remote CPUs, and hence their attempt
> to pause the owning vCPU will have no effect on it (as it already
> looks to be paused). At the same time the "owning" CPU will re-enable
> interrupts eventually (the lastest when entering the idle loop) and
> hence becomes subject to IPIs from other CPUs requesting access to the
> VMCS. As a result, when __context_switch() finally gets run, the CPU
> may no longer have the VMCS loaded, and hence any accesses to it would
> fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().
> 
> Similarly, when __context_switch() is being bypassed also on the second
> (switch-in) path, VMCS ownership may have been lost and hence needs
> re-establishing. Since there's no existing hook to put this in, add a
> new one.
> 
> Reported-by: Kevin Mayer 
> Reported-by: Anshul Makkar 
> Signed-off-by: Jan Beulich 
> ---
> v2: Drop the spin loop from vmx_vmc_reload(). Use the function in
> vmx_do_resume() instead of open coding it there (requiring the
> ASSERT()s to be adjusted/dropped). Drop the new
> ->ctxt_switch_same() hook.
> 
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -552,6 +552,20 @@ static void vmx_load_vmcs(struct vcpu *v
>  local_irq_restore(flags);
>  }
>  
> +void vmx_vmcs_reload(struct vcpu *v)
> +{
> +/*
> + * As we may be running with interrupts disabled, we can't acquire
> + * v->arch.hvm_vmx.vmcs_lock here. However, with interrupts disabled
> + * the VMCS can't be taken away from us anymore if we still own it.
> + */
> +ASSERT(v->is_running || !local_irq_is_enabled());
> +if ( v->arch.hvm_vmx.vmcs_pa == this_cpu(current_vmcs) )
> +return;
> +
> +vmx_load_vmcs(v);
> +}
> +
>  int vmx_cpu_up_prepare(unsigned int cpu)
>  {
>  /*
> @@ -1678,10 +1692,7 @@ void vmx_do_resume(struct vcpu *v)
>  bool_t debug_state;
>  
>  if ( v->arch.hvm_vmx.active_cpu == smp_processor_id() )
> -{
> -if ( v->arch.hvm_vmx.vmcs_pa != this_cpu(current_vmcs) )
> -vmx_load_vmcs(v);
> -}
> +vmx_vmcs_reload(v);
>  else
>  {
>  /*
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -936,6 +937,18 @@ static void vmx_ctxt_switch_from(struct
>  if ( unlikely(!this_cpu(vmxon)) )
>  return;
>  
> +if ( !v->is_running )
> +{
> +/*
> + * When this vCPU isn't marked as running anymore, a remote pCPU's
> + * attempt to pause us (from vmx_vmcs_enter()) won't have a reason
> + * to spin in vcpu_sleep_sync(), and hence that pCPU might have taken
> + * away the VMCS from us. As we're running with interrupts disabled,
> + * we also can't call vmx_vmcs_enter().
> + */
> +vmx_vmcs_reload(v);
> +}
> +
>  vmx_fpu_leave(v);
>  vmx_save_guest_msrs(v);
>  vmx_restore_host_msrs();
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -174,6 +174,7 @@ void vmx_destroy_vmcs(struct vcpu *v);
>  void vmx_vmcs_enter(struct vcpu *v);
>  bool_t __must_check vmx_vmcs_try_enter(struct vcpu *v);
>  void vmx_vmcs_exit(struct vcpu *v);
> +void vmx_vmcs_reload(struct vcpu *v);
>  
>  #define CPU_BASED_VIRTUAL_INTR_PENDING0x0004
>  #define CPU_BASED_USE_TSC_OFFSETING   0x0008
> 

Hi Jan,

I'm not entirely sure if it's something related but the end result looks
similar to the issue that this patch solved. We are now getting reports of
a similar race condition with the following stack trace on 4.7.1 with this
patch backported but I'm pretty sure this should be the case for master
as well:

(XEN) [480198.570165] Xen call trace:
(XEN) [480198.570168][] 
vmx.c#arch/x86/hvm/vmx/vmx.o.unlikely+0x136/0x1a8
(XEN) [480198.570171][] 
domain.c#__context_switch+0x10c/0x3a4
(XEN) [480198.570176][] __sync_local_execstate+0x35/0x51
(XEN) [480198.570179][] invalidate_interrupt+0x40/0x73
(XEN) [480198.570183][] do_IRQ+0x8c/0x5cb
(XEN) [480198.570186][] common_interrupt+0x5f/0x70
(XEN) [480198.570189][] vpmu_destroy+0/0x100
(XEN) [480198.570192][] vmx.c#vmx_vcpu_destroy+0x21/0x30
(XEN) [480198.570195][] hvm_vcpu_destroy+0x70/0x77
(XEN) [480198.570197][] vcpu_destroy+0x5d/0x72
(XEN) [480198.570201][] 
domain.c#complete_domain_destroy+0x49/0x182
(XEN) [480198.570204][] 
rcupdate.c#rcu_process_callbacks+0x141/0x1a3
(XEN) [480198.570207][] softirq.c#__do_softirq+0x75/0x80
(XEN) [480198.570209][] process_pending_softirqs+0xe/0x10
(XEN) [480198.570212][] mwait-idle.c#mwait_idle+0xf5/0x2c3
(XEN) [480198.570214][] vmx_intr_assist+0x3bf/0x4f2
(XEN) [480198.570216][]

Re: [Xen-devel] [PATCH][tip] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init()

2017-10-27 Thread Juergen Gross 
On 27/10/17 18:02, Dou Liyang wrote:
> Commit:
> 
>   9043442b43b1 ("locking/paravirt: Use new static key for controlling
>   call of virt_spin_lock()")
> 
> set the static virt_spin_lock_key to a value before jump_label_init()
> has been called, which will result in a WARN().
> 
> Move the native_pv_lock_init() into xx_smp_prepare_cpus(). Make the
> setup later to avoid the WARN().
> 
> Reported-by: Juergen Gross 
> Suggested-by: Juergen Gross 
> Signed-off-by: Dou Liyang 
> ---
>  arch/x86/kernel/smpboot.c | 3 ++-
>  arch/x86/xen/smp_pv.c | 2 ++
>  arch/x86/xen/spinlock.c   | 6 --
>  3 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index aed1460..6b1335a 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1323,6 +1323,8 @@ void __init native_smp_prepare_cpus(unsigned int 
> max_cpus)
>   pr_info("CPU0: ");
>   print_cpu_info(_data(0));
>  
> + native_pv_lock_init();
> +
>   uv_system_init();
>  
>   set_mtrr_aps_delayed_init();
> @@ -1350,7 +1352,6 @@ void __init native_smp_prepare_boot_cpu(void)
>   /* already set me in cpu_online_mask in boot_cpu_init() */
>   cpumask_set_cpu(me, cpu_callout_mask);
>   cpu_set_state_online(me);
> - native_pv_lock_init();
>  }
>  
>  void __init native_smp_cpus_done(unsigned int max_cpus)
> diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
> index 5147140..570b2bc 100644
> --- a/arch/x86/xen/smp_pv.c
> +++ b/arch/x86/xen/smp_pv.c
> @@ -236,6 +236,8 @@ static void __init xen_pv_smp_prepare_cpus(unsigned int 
> max_cpus)
>   xen_raw_printk(m);
>   panic(m);
>   }
> + native_pv_lock_init();
> +

This can be removed, as for a Xen domain native_pv_lock_init() is a nop.

With that:

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH][tip] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init()

2017-10-27 Thread Juergen Gross 
On 27/10/17 19:09, Vitaly Kuznetsov wrote:
> Boris Petkov  writes:
> 
>> On October 27, 2017 6:02:00 PM GMT+02:00, Dou Liyang 
>>  wrote:
>>> Commit:
>>>
>>>  9043442b43b1 ("locking/paravirt: Use new static key for controlling
>>>  call of virt_spin_lock()")
>>>
>>> set the static virt_spin_lock_key to a value before jump_label_init()
>>> has been called, which will result in a WARN().
>>>
>>> Move the native_pv_lock_init() into xx_smp_prepare_cpus(). Make the
>>> setup later to avoid the WARN().
>>>
>>> Reported-by: Juergen Gross 
>>> Suggested-by: Juergen Gross 
>>> Signed-off-by: Dou Liyang 
>>> ---
>>> arch/x86/kernel/smpboot.c | 3 ++-
>>> arch/x86/xen/smp_pv.c | 2 ++
>>> arch/x86/xen/spinlock.c   | 6 --
>>> 3 files changed, 8 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>>> index aed1460..6b1335a 100644
>>> --- a/arch/x86/kernel/smpboot.c
>>> +++ b/arch/x86/kernel/smpboot.c
>>> @@ -1323,6 +1323,8 @@ void __init native_smp_prepare_cpus(unsigned int
>>> max_cpus)
>>> pr_info("CPU0: ");
>>> print_cpu_info(_data(0));
>>>
>>> +   native_pv_lock_init();
>>> +
>>> uv_system_init();
>>>
>>> set_mtrr_aps_delayed_init();
>>> @@ -1350,7 +1352,6 @@ void __init native_smp_prepare_boot_cpu(void)
>>> /* already set me in cpu_online_mask in boot_cpu_init() */
>>> cpumask_set_cpu(me, cpu_callout_mask);
>>> cpu_set_state_online(me);
>>> -   native_pv_lock_init();
>>> }
>>>
>>> void __init native_smp_cpus_done(unsigned int max_cpus)
>>> diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
>>> index 5147140..570b2bc 100644
>>> --- a/arch/x86/xen/smp_pv.c
>>> +++ b/arch/x86/xen/smp_pv.c
>>> @@ -236,6 +236,8 @@ static void __init xen_pv_smp_prepare_cpus(unsigned
>>> int max_cpus)
>>> xen_raw_printk(m);
>>> panic(m);
>>> }
>>> +   native_pv_lock_init();
>>> +
>>> xen_init_lock_cpu(0);
>>>
>>> smp_store_boot_cpu_info();
>>> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
>>> index e8ab80a..1e1462d 100644
>>> --- a/arch/x86/xen/spinlock.c
>>> +++ b/arch/x86/xen/spinlock.c
>>> @@ -81,8 +81,11 @@ void xen_init_lock_cpu(int cpu)
>>> int irq;
>>> char *name;
>>>
>>> -   if (!xen_pvspin)
>>> +   if (!xen_pvspin) {
>>> +   if (cpu == 0)
>>> +   static_branch_disable(_spin_lock_key);
>>
>> This is assuming CPU 0 is the boot cpu. I think you want 
>> boot_cpu_data.cpu_index here or whatever is used on xen to identify the BSP 
>> reliably. 
> 
> It seems both PV and PVHVM call xen_init_lock_cpu(0) so 0 here is
> Linux's idea of CPU id, not Xen's.
> 
> In case Xen's idea is needed xen_vcpu_id mapping should be used. But I
> don't think it's the case here.
> 

Correct.


Juergen

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

Re: [Xen-devel] [PATCH] tools/hotplug: create XEN_LOG_DIR at runtime

2017-10-27 Thread Wei Liu 
On Fri, Oct 27, 2017 at 07:52:37PM +0300, Andrii Anisov wrote:
> From: Andrii Anisov 
> 
> /var/log could be a tmpfs mount point, so create xen subfolder at runtime.
> 
> Signed-off-by: Andrii Anisov 
> Reviewed-by: Volodymyr Babchuk 
> Reviewed-by: Oleksandr Andrushchenko 

Acked-by: Wei Liu 

Julien I think we should apply this for 4.10.

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

Re: [Xen-devel] [PATCH] tools/xenstored: Check number of strings passed to do_control()

2017-10-27 Thread Juergen Gross 
On 27/10/17 18:32, Pawel Wieczorkiewicz wrote:
> It is possible to send a zero-string message body to xenstore's
> XS_CONTROL handling function. Then the number of strings is used
> for an array allocation. This leads to a crash in strcmp() in a
> CONTROL sub-command invocation loop.
> The output of xs_count_string() should be verified and all 0 or
> negative values should be rejected with an EINVAL. At least the
> sub-command name must be specified.
> 
> The xenstore crash can only be triggered from within dom0 (there
> is a check in do_control() rejecting all non-dom0 requests with
> an EACCES).
> 
> Testing: reproduced with the following command:
> python -c 'print 16*"\x00"' | nc -U $XENSTORED_RUNDIR/socket
> 
> Signed-off-by: Pawel Wieczorkiewicz 
> Reviewed-by: Martin Pohlack 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v5.1 2/8] xen: restrict: use xentoolcore_restrict_all

2017-10-27 Thread Stefano Stabellini 
On Fri, 27 Oct 2017, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH v5.1 2/8] xen: restrict: use 
> xentoolcore_restrict_all"):
> > On Fri, 20 Oct 2017, Ian Jackson wrote:
> ...
> > > Drop individual use of xendevicemodel_restrict and
> > > xenforeignmemory_restrict.  These are not actually effective in this
> > > version of qemu, because qemu has a large number of fds open onto
> > > various Xen control devices.
> ...
> > Wait, if the compat stub returns error, and this patch removed the code
> > to check for ENOTTY, doesn't it prevent any QEMU compiled against older
> > Xen from working?
> > 
> > Or am I missing something?
> 
> You are right, but this is intended.  The paragraph I quote in the
> commit message above is intended to explain.
> 
> That is: without xentoolcore_restrict_all, -xen-domid-restrict is a
> booby-trap.  It does not actually prevent a compromised qemu from
> doing anything.  So there is no reason to pass it in such a
> configuration.  If you do pass it it is better for the domain startup
> to fail, than for it to carry on without the restriction.
> 
> The only reason I am not saying someone should be issuing an advisory
> is that this feature was never supported by any of the Xen toolstacks.

Ah, right. And libxl has never passed -xen-domid-restrict in previous
releases, so we are OK.

Acked-by: Stefano Stabellini 

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

Re: [Xen-devel] [PATCH][tip] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init()

2017-10-27 Thread Vitaly Kuznetsov 
Boris Petkov  writes:

> On October 27, 2017 6:02:00 PM GMT+02:00, Dou Liyang 
>  wrote:
>>Commit:
>>
>>  9043442b43b1 ("locking/paravirt: Use new static key for controlling
>>  call of virt_spin_lock()")
>>
>>set the static virt_spin_lock_key to a value before jump_label_init()
>>has been called, which will result in a WARN().
>>
>>Move the native_pv_lock_init() into xx_smp_prepare_cpus(). Make the
>>setup later to avoid the WARN().
>>
>>Reported-by: Juergen Gross 
>>Suggested-by: Juergen Gross 
>>Signed-off-by: Dou Liyang 
>>---
>> arch/x86/kernel/smpboot.c | 3 ++-
>> arch/x86/xen/smp_pv.c | 2 ++
>> arch/x86/xen/spinlock.c   | 6 --
>> 3 files changed, 8 insertions(+), 3 deletions(-)
>>
>>diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>>index aed1460..6b1335a 100644
>>--- a/arch/x86/kernel/smpboot.c
>>+++ b/arch/x86/kernel/smpboot.c
>>@@ -1323,6 +1323,8 @@ void __init native_smp_prepare_cpus(unsigned int
>>max_cpus)
>>  pr_info("CPU0: ");
>>  print_cpu_info(_data(0));
>> 
>>+ native_pv_lock_init();
>>+
>>  uv_system_init();
>> 
>>  set_mtrr_aps_delayed_init();
>>@@ -1350,7 +1352,6 @@ void __init native_smp_prepare_boot_cpu(void)
>>  /* already set me in cpu_online_mask in boot_cpu_init() */
>>  cpumask_set_cpu(me, cpu_callout_mask);
>>  cpu_set_state_online(me);
>>- native_pv_lock_init();
>> }
>> 
>> void __init native_smp_cpus_done(unsigned int max_cpus)
>>diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
>>index 5147140..570b2bc 100644
>>--- a/arch/x86/xen/smp_pv.c
>>+++ b/arch/x86/xen/smp_pv.c
>>@@ -236,6 +236,8 @@ static void __init xen_pv_smp_prepare_cpus(unsigned
>>int max_cpus)
>>  xen_raw_printk(m);
>>  panic(m);
>>  }
>>+ native_pv_lock_init();
>>+
>>  xen_init_lock_cpu(0);
>> 
>>  smp_store_boot_cpu_info();
>>diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
>>index e8ab80a..1e1462d 100644
>>--- a/arch/x86/xen/spinlock.c
>>+++ b/arch/x86/xen/spinlock.c
>>@@ -81,8 +81,11 @@ void xen_init_lock_cpu(int cpu)
>>  int irq;
>>  char *name;
>> 
>>- if (!xen_pvspin)
>>+ if (!xen_pvspin) {
>>+ if (cpu == 0)
>>+ static_branch_disable(_spin_lock_key);
>
> This is assuming CPU 0 is the boot cpu. I think you want 
> boot_cpu_data.cpu_index here or whatever is used on xen to identify the BSP 
> reliably. 

It seems both PV and PVHVM call xen_init_lock_cpu(0) so 0 here is
Linux's idea of CPU id, not Xen's.

In case Xen's idea is needed xen_vcpu_id mapping should be used. But I
don't think it's the case here.

-- 
  Vitaly

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

[Xen-devel] [PATCH 14/16] osstest: add support for FreeBSD buildjobs to sg-run-job

2017-10-27 Thread Roger Pau Monne 
Add support and introduce a FreeBSD build job to sg-run-job.

Signed-off-by: Roger Pau Monné 
---
Changes since v13:
 - Run ts-build-prep-freebsd for FreeBSD build host setup.

Changes since v5:
 - Add a '+' to the arguments passed to ts-freebsd-set-hostflags, so
   they are hidden from testid.

Changes since v4:
 - Use a switch in allocate-build-host.

Changes since v3:
 - New in this version (split from existing patch).
---
 sg-run-job | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/sg-run-job b/sg-run-job
index 17cf6c4a..bb59b109 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -683,6 +683,7 @@ proc need-hosts/build-kern {}   { return 
BUILD_LINUX }
 proc need-hosts/build-libvirt {}{ return BUILD_LINUX }
 proc need-hosts/build-rumprun {}{ return BUILD_LINUX }
 proc need-hosts/build-xtf {}{ return BUILD_LINUX }
+proc need-hosts/build-freebsd {}{ return BUILD_FREEBSD }
 
 proc run-job/build {} {
 run-ts . = ts-xen-build
@@ -709,8 +710,16 @@ proc run-job/build-xtf {} {
 run-ts . = ts-xtf-build
 }
 
+proc run-job/build-freebsd {} {
+run-ts . = ts-freebsd-build
+}
+
 proc allocate-build-host {ostype} {
 global jobinfo
+switch -exact $ostype {
+FREEBSD { run-ts broken = ts-freebsd-set-hostflags + --share host }
+default {}
+}
 run-ts broken = ts-hosts-allocate + host
 }
 proc prepare-build-host-linux {} {
@@ -719,6 +728,12 @@ proc prepare-build-host-linux {} {
 run-ts . host-build-prep ts-xen-build-prep
 }
 
+proc prepare-build-host-freebsd {} {
+global jobinfo
+run-ts broken host-install(*) ts-freebsd-host-install
+run-ts . host-build-prep ts-build-prep-freebsd
+}
+
 proc need-hosts/coverity {} { return BUILD_LINUX }
 proc run-job/coverity {} {
 run-ts . = ts-coverity-build + host
-- 
2.13.5 (Apple Git-94)


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

[Xen-devel] [PATCH 04/16] osstest: introduce host_shared_mark_ready

2017-10-27 Thread Roger Pau Monne 
That allows marking a host as ready to be shared. Replace the current
callers that open-code it.

Signed-off-by: Roger Pau Monné 
---
Changes since v13:
 - s/resource_shared_mark_ready/host_shared_mark_ready/.
 - First argument of jobdb_resource_shared_mark_ready must be 'host'.

Changes since v4:
 - New in this version.
---
 Osstest/TestSupport.pm  | 9 -
 ts-freebsd-host-install | 4 ++--
 ts-xen-build-prep   | 4 ++--
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index c7cc8108..f28c8e4a 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -134,7 +134,7 @@ BEGIN {
   guest_editconfig_nocd
   host_install_postboot_complete
   target_core_dump_setup
-  sha256file
+  sha256file host_shared_mark_ready
   );
 %EXPORT_TAGS = ( );
 
@@ -2815,4 +2815,11 @@ sub sha256file ($;$) {
 return $truncate ? substr($digest, 0, $truncate) : $digest;
 }
 
+sub host_shared_mark_ready($$) {
+my ($ho,$sharetype) = @_;
+
+$mjobdb->jobdb_resource_shared_mark_ready('host', $ho->{Name},
+  $sharetype);
+}
+
 1;
diff --git a/ts-freebsd-host-install b/ts-freebsd-host-install
index bfc693a1..735f7ff0 100755
--- a/ts-freebsd-host-install
+++ b/ts-freebsd-host-install
@@ -279,5 +279,5 @@ setup_netboot_local($ho);
 # Proceed with the install
 install();
 
-resource_shared_mark_ready($ho, "build-freebsd-".
-sha256file("$path_prefix/install.img", 16));
+host_shared_mark_ready($ho, "build-freebsd-".
+sha256file("$path_prefix/install.img", 16));
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 3e98364a..22a3ce66 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -273,5 +273,5 @@ if (!$ho->{Flags}{'no-reinstall'}) {
 ccache_setup();
 gitcache_setup();
 }
-$mjobdb->jobdb_resource_shared_mark_ready
-   ($ho->{Ident}, $ho->{Name}, "build-".$ho->{Suite}."-".$r{arch});
+
+host_shared_mark_ready($ho, "build-".$ho->{Suite}."-".$r{arch});
-- 
2.13.5 (Apple Git-94)


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

[Xen-devel] [PATCH v14 00/16] osstest: initial FreeBSD support

2017-10-27 Thread Roger Pau Monne 
Hello,

These are the remaining FreeBSD host setup patches. I've only sent the
ones that changed or are new in this version.

Branch can be found at:

git://xenbits.xen.org/people/royger/osstest.git freebsd_v14

Thanks, Roger.

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

[Xen-devel] [PATCH 12/16] osstest: add script to install build dependencies on FreeBSD

2017-10-27 Thread Roger Pau Monne 
Since at the moment osstest only builds FreeBSD on FreeBSD, there are
no dependencies to install. Just mark the host as ready to share.

Signed-off-by: Roger Pau Monné 
---
 ts-build-prep-freebsd   | 37 +
 ts-freebsd-host-install |  3 ---
 2 files changed, 37 insertions(+), 3 deletions(-)
 create mode 100755 ts-build-prep-freebsd

diff --git a/ts-build-prep-freebsd b/ts-build-prep-freebsd
new file mode 100755
index ..1d78a3e1
--- /dev/null
+++ b/ts-build-prep-freebsd
@@ -0,0 +1,37 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2017 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program 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 Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+use strict qw(vars);
+use DBI;
+use POSIX;
+
+unshift @INC, qw(.);
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+our ($whhost) = @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+exit 0 if $ho->{SharedReady};
+
+our $path_prefix = $r{"freebsd_distpath"} ||
+   get_stashed("path_freebsddist", $r{"freebsdbuildjob"});
+
+host_shared_mark_ready($ho, "build-freebsd-".
+sha256file("$path_prefix/install.img", 16));
diff --git a/ts-freebsd-host-install b/ts-freebsd-host-install
index 735f7ff0..447a5076 100755
--- a/ts-freebsd-host-install
+++ b/ts-freebsd-host-install
@@ -278,6 +278,3 @@ setup_netboot_local($ho);
 
 # Proceed with the install
 install();
-
-host_shared_mark_ready($ho, "build-freebsd-".
-sha256file("$path_prefix/install.img", 16));
-- 
2.13.5 (Apple Git-94)


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

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

2017-10-27 Thread osstest service owner 
flight 115301 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115301/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  6c1a029aef07f6962716a5a7b3d6b942281f4e4e
baseline version:
 xen  26a896cde21c6d03de367190034fcc150b1bf2d8

Last test of basis   115298  2017-10-27 12:02:56 Z0 days
Testing same since   115301  2017-10-27 15:04:56 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Roger Pau Monne 
  Roger Pau Monné 
  Ross Lagerwall 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [PATCH] tools/hotplug: create XEN_LOG_DIR at runtime

2017-10-27 Thread Andrii Anisov 
From: Andrii Anisov 

/var/log could be a tmpfs mount point, so create xen subfolder at runtime.

Signed-off-by: Andrii Anisov 
Reviewed-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko 
---
 tools/hotplug/Linux/init.d/xencommons.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/hotplug/Linux/init.d/xencommons.in 
b/tools/hotplug/Linux/init.d/xencommons.in
index a6a40d6..ec42b05 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -58,6 +58,7 @@ do_start () {
 
mkdir -p ${XEN_RUN_DIR}
mkdir -p ${XEN_LOCK_DIR}
+   mkdir -p ${XEN_LOG_DIR}
 
@XEN_SCRIPT_DIR@/launch-xenstore || exit 1
 
-- 
2.7.4


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

Re: [Xen-devel] [PATCH][tip] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init()

2017-10-27 Thread Boris Petkov 
On October 27, 2017 6:02:00 PM GMT+02:00, Dou Liyang 
 wrote:
>Commit:
>
>  9043442b43b1 ("locking/paravirt: Use new static key for controlling
>  call of virt_spin_lock()")
>
>set the static virt_spin_lock_key to a value before jump_label_init()
>has been called, which will result in a WARN().
>
>Move the native_pv_lock_init() into xx_smp_prepare_cpus(). Make the
>setup later to avoid the WARN().
>
>Reported-by: Juergen Gross 
>Suggested-by: Juergen Gross 
>Signed-off-by: Dou Liyang 
>---
> arch/x86/kernel/smpboot.c | 3 ++-
> arch/x86/xen/smp_pv.c | 2 ++
> arch/x86/xen/spinlock.c   | 6 --
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
>diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>index aed1460..6b1335a 100644
>--- a/arch/x86/kernel/smpboot.c
>+++ b/arch/x86/kernel/smpboot.c
>@@ -1323,6 +1323,8 @@ void __init native_smp_prepare_cpus(unsigned int
>max_cpus)
>   pr_info("CPU0: ");
>   print_cpu_info(_data(0));
> 
>+  native_pv_lock_init();
>+
>   uv_system_init();
> 
>   set_mtrr_aps_delayed_init();
>@@ -1350,7 +1352,6 @@ void __init native_smp_prepare_boot_cpu(void)
>   /* already set me in cpu_online_mask in boot_cpu_init() */
>   cpumask_set_cpu(me, cpu_callout_mask);
>   cpu_set_state_online(me);
>-  native_pv_lock_init();
> }
> 
> void __init native_smp_cpus_done(unsigned int max_cpus)
>diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
>index 5147140..570b2bc 100644
>--- a/arch/x86/xen/smp_pv.c
>+++ b/arch/x86/xen/smp_pv.c
>@@ -236,6 +236,8 @@ static void __init xen_pv_smp_prepare_cpus(unsigned
>int max_cpus)
>   xen_raw_printk(m);
>   panic(m);
>   }
>+  native_pv_lock_init();
>+
>   xen_init_lock_cpu(0);
> 
>   smp_store_boot_cpu_info();
>diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
>index e8ab80a..1e1462d 100644
>--- a/arch/x86/xen/spinlock.c
>+++ b/arch/x86/xen/spinlock.c
>@@ -81,8 +81,11 @@ void xen_init_lock_cpu(int cpu)
>   int irq;
>   char *name;
> 
>-  if (!xen_pvspin)
>+  if (!xen_pvspin) {
>+  if (cpu == 0)
>+  static_branch_disable(_spin_lock_key);

This is assuming CPU 0 is the boot cpu. I think you want 
boot_cpu_data.cpu_index here or whatever is used on xen to identify the BSP 
reliably. 


-- 
Sent from a small device: formatting sux and brevity is inevitable. 

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

[Xen-devel] [OSSTEST PATCH 1/2] resource_shared_mark_ready: Fix for non-`host' idents; fix $sharetype

2017-10-27 Thread Ian Jackson 
$ho->{Ident} is completely wrong here.  That, ultimately, is going to
be restype.  But restype must be the fixed value `host'.  If this
function were called with a $ho whose Ident was `src_host' or
something, it would fail because hosts are all restype `host' in the
datanase, of course.

Also `$resource' here is the wrong variable name.  This is actually
the $sharetype (as is evident from jobdb_resource_shared_mark_ready
and what is now executive_resource_shared_mark_ready).

CC: Roger Pau Monné 
Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 75f5a26..85ed57a 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2859,10 +2859,10 @@ sub sha256file ($;$) {
 }
 
 sub resource_shared_mark_ready($$) {
-my ($ho,$resource) = @_;
+my ($ho,$sharetype) = @_;
 
-$mjobdb->jobdb_resource_shared_mark_ready($ho->{Ident}, $ho->{Name},
-  $resource);
+$mjobdb->jobdb_resource_shared_mark_ready('host', $ho->{Name},
+  $sharetype);
 }
 
 1;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 2/2] host_shared_mark_ready: rename from resource_shared_mark_ready

2017-10-27 Thread Ian Jackson 
This function only works on resource of restype `host'.  Ie, hosts.

Signed-off-by: Ian Jackson 
CC: Roger Pau Monné 
---
 Osstest/TestSupport.pm  | 4 ++--
 ts-freebsd-host-install | 4 ++--
 ts-xen-build-prep   | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 85ed57a..c9dada3 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -134,7 +134,7 @@ BEGIN {
   guest_editconfig_nocd
   host_install_postboot_complete
   target_core_dump_setup
-  sha256file resource_shared_mark_ready
+  sha256file host_shared_mark_ready
   );
 %EXPORT_TAGS = ( );
 
@@ -2858,7 +2858,7 @@ sub sha256file ($;$) {
 return $truncate ? substr($digest, 0, $truncate) : $digest;
 }
 
-sub resource_shared_mark_ready($$) {
+sub host_shared_mark_ready($$) {
 my ($ho,$sharetype) = @_;
 
 $mjobdb->jobdb_resource_shared_mark_ready('host', $ho->{Name},
diff --git a/ts-freebsd-host-install b/ts-freebsd-host-install
index bfc693a..caec993 100755
--- a/ts-freebsd-host-install
+++ b/ts-freebsd-host-install
@@ -279,5 +279,5 @@ setup_netboot_local($ho);
 # Proceed with the install
 install();
 
-resource_shared_mark_ready($ho, "build-freebsd-".
-sha256file("$path_prefix/install.img", 16));
+host_shared_mark_ready($ho, "build-freebsd-".
+  sha256file("$path_prefix/install.img", 16));
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 776866d..22a3ce6 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -274,4 +274,4 @@ if (!$ho->{Flags}{'no-reinstall'}) {
 gitcache_setup();
 }
 
-resource_shared_mark_ready($ho, "build-".$ho->{Suite}."-".$r{arch});
+host_shared_mark_ready($ho, "build-".$ho->{Suite}."-".$r{arch});
-- 
2.1.4


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

Re: [Xen-devel] [PATCH for-4.10] tools/xenstored: Check number of strings passed to do_control()

2017-10-27 Thread Ian Jackson 
Pawel Wieczorkiewicz writes ("[PATCH] tools/xenstored: Check number of strings 
passed to do_control()"):
> It is possible to send a zero-string message body to xenstore's
> XS_CONTROL handling function. Then the number of strings is used
> for an array allocation. This leads to a crash in strcmp() in a
> CONTROL sub-command invocation loop.
> The output of xs_count_string() should be verified and all 0 or
> negative values should be rejected with an EINVAL. At least the
> sub-command name must be specified.
> 
> The xenstore crash can only be triggered from within dom0 (there
> is a check in do_control() rejecting all non-dom0 requests with
> an EACCES).

Acked-by: Ian Jackson 

(Added the for-4.10 tag to the Subject.)

Ian.

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

[Xen-devel] [PATCH] tools/xenstored: Check number of strings passed to do_control()

2017-10-27 Thread Pawel Wieczorkiewicz 
It is possible to send a zero-string message body to xenstore's
XS_CONTROL handling function. Then the number of strings is used
for an array allocation. This leads to a crash in strcmp() in a
CONTROL sub-command invocation loop.
The output of xs_count_string() should be verified and all 0 or
negative values should be rejected with an EINVAL. At least the
sub-command name must be specified.

The xenstore crash can only be triggered from within dom0 (there
is a check in do_control() rejecting all non-dom0 requests with
an EACCES).

Testing: reproduced with the following command:
python -c 'print 16*"\x00"' | nc -U $XENSTORED_RUNDIR/socket

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Martin Pohlack 
---
 tools/xenstore/xenstored_control.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/xenstore/xenstored_control.c 
b/tools/xenstore/xenstored_control.c
index 7c14911..e4b8aa9 100644
--- a/tools/xenstore/xenstored_control.c
+++ b/tools/xenstore/xenstored_control.c
@@ -184,6 +184,8 @@ int do_control(struct connection *conn, struct 
buffered_data *in)
return EACCES;
 
num = xs_count_strings(in->buffer, in->used);
+   if (num < 1)
+   return EINVAL;
vec = talloc_array(in, char *, num);
if (!vec)
return ENOMEM;
-- 
1.8.3.1

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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

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

2017-10-27 Thread osstest service owner 
flight 115282 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115282/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115247
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115247
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115247
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  418a100290ffe7f3ce944af719b495eff9d2acb5
baseline version:
 libvirt  f4973d1ea88b2e807fc2c52a5fc281a1c289d50e

Last test of basis   115247  2017-10-26 04:21:06 Z1 days
Testing same since   115282  2017-10-27 04:20:37 Z0 days1 attempts


People who touched revisions under test:
  Christian Ehrhardt 
  Dawid Zamirski 
  Dawid Zamirski 
  Jim Fehlig 
  Jiri Denemark 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=418a100290ffe7f3ce944af719b495eff9d2acb5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 ']'
++

Re: [Xen-devel] [PATCH v6 07/20] osstest: introduce resource_shared_mark_ready

2017-10-27 Thread Ian Jackson 
Roger Pau Monne writes ("[PATCH v6 07/20] osstest: introduce 
resource_shared_mark_ready"):
> That allows marking a host as ready to be shared. Replace the current
> caller that open-codes it.
...
> -$mjobdb->jobdb_resource_shared_mark_ready
> -   ($ho->{Ident}, $ho->{Name}, "build-".$ho->{Suite}."-".$r{arch});
> +

Well.  On trying to build something on top of this, I notice that
$ho->{Ident} is completely wrong here.  That, ultimately, is going to
be restype.  But restype must be the fixed value `host'.

> +sub resource_shared_mark_ready($$) {
> +my ($ho,$resource) = @_;
> +
> +$mjobdb->jobdb_resource_shared_mark_ready($ho->{Ident}, $ho->{Name},
> +  $resource);
> +}

And this function `resource_shared_mark_ready' only marks hosts ready
- since it takea $ho.

I propose to send you a followup patch which renames your new
resource_shared_mark_ready to host_shared_mark_ready, and passes
'host' instead of $ho->{Ident}.  Alternatively I can wait for you to
do this, if that would be disruptive to you.

Also `$resource' here is the wrong variable name.  This is actually
the $sharetype (as is evident from jobdb_resource_shared_mark_ready
and what is now executive_resource_shared_mark_ready.  That is a bug
which is introduced in your patch.  Would you like to respin this as
you are about to rebase this onto what is about to become master,
anyway ?

Thanks,
Ian.

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

[Xen-devel] [PATCH][tip] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init()

2017-10-27 Thread Dou Liyang 
Commit:

  9043442b43b1 ("locking/paravirt: Use new static key for controlling
  call of virt_spin_lock()")

set the static virt_spin_lock_key to a value before jump_label_init()
has been called, which will result in a WARN().

Move the native_pv_lock_init() into xx_smp_prepare_cpus(). Make the
setup later to avoid the WARN().

Reported-by: Juergen Gross 
Suggested-by: Juergen Gross 
Signed-off-by: Dou Liyang 
---
 arch/x86/kernel/smpboot.c | 3 ++-
 arch/x86/xen/smp_pv.c | 2 ++
 arch/x86/xen/spinlock.c   | 6 --
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index aed1460..6b1335a 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1323,6 +1323,8 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
pr_info("CPU0: ");
print_cpu_info(_data(0));
 
+   native_pv_lock_init();
+
uv_system_init();
 
set_mtrr_aps_delayed_init();
@@ -1350,7 +1352,6 @@ void __init native_smp_prepare_boot_cpu(void)
/* already set me in cpu_online_mask in boot_cpu_init() */
cpumask_set_cpu(me, cpu_callout_mask);
cpu_set_state_online(me);
-   native_pv_lock_init();
 }
 
 void __init native_smp_cpus_done(unsigned int max_cpus)
diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 5147140..570b2bc 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -236,6 +236,8 @@ static void __init xen_pv_smp_prepare_cpus(unsigned int 
max_cpus)
xen_raw_printk(m);
panic(m);
}
+   native_pv_lock_init();
+
xen_init_lock_cpu(0);
 
smp_store_boot_cpu_info();
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index e8ab80a..1e1462d 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -81,8 +81,11 @@ void xen_init_lock_cpu(int cpu)
int irq;
char *name;
 
-   if (!xen_pvspin)
+   if (!xen_pvspin) {
+   if (cpu == 0)
+   static_branch_disable(_spin_lock_key);
return;
+   }
 
WARN(per_cpu(lock_kicker_irq, cpu) >= 0, "spinlock on CPU%d exists on 
IRQ%d!\n",
 cpu, per_cpu(lock_kicker_irq, cpu));
@@ -130,7 +133,6 @@ void __init xen_init_spinlocks(void)
 
if (!xen_pvspin) {
printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
-   static_branch_disable(_spin_lock_key);
return;
}
printk(KERN_DEBUG "xen: PV spinlocks enabled\n");
-- 
2.5.5




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

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

2017-10-27 Thread osstest service owner 
flight 115279 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115279/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114682

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114682
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114682
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114682
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114682
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 114682
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114682
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114682
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass

version targeted for testing:
 linux15f859ae5c43c7f0a064ed92d33f7a5bc5de6de0
baseline version:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb

Last test of basis   114682  2017-10-18 09:54:11 Z9 days
Failing since114781  2017-10-20 01:00:47 Z7 days   12 attempts
Testing same since   115279  2017-10-27 02:14:18 Z0 days1 attempts


343 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

2017-10-27 Thread Paul Durrant 
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@linaro.org]
> Sent: 27 October 2017 12:46
> To: Jan Beulich ; Paul Durrant
> 
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-de...@lists.xenproject.org;
> Konrad Rzeszutek Wilk ; Daniel De Graaf
> ; Tim (Xen.org) 
> Subject: Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add
> HYPERVISOR_memory_op to acquire guest resources
> 
> Hi,
> 
> On 26/10/17 16:39, Jan Beulich wrote:
>  On 26.10.17 at 17:32,  wrote:
> >> On 26/10/17 16:26, Jan Beulich wrote:
> >> On 17.10.17 at 15:24,  wrote:
>  +/* IN/OUT - If the tools domain is PV then, upon return, frame_list
>  + *  will be populated with the MFNs of the resource.
>  + *  If the tools domain is HVM then it is expected that, on
>  + *  entry, frame_list will be populated with a list of GFNs
>  + *  that will be mapped to the MFNs of the resource.
>  + *  If -EIO is returned then the frame_list has only been
>  + *  partially mapped and it is up to the caller to unmap all
>  + *  the GFNs.
>  + *  This parameter may be NULL if nr_frames is 0.
>  + */
>  +XEN_GUEST_HANDLE(xen_ulong_t) frame_list;
> >>>
> >>> This is still xen_ulong_t, which I can live with, but then you shouldn't
> >>> copy into / out of arrays of other types in acquire_resource() (the
> >>> more that this is common code, and iirc xen_ulong_t and
> >>> unsigned long aren't the same thing on ARM32).
> >>
> >> xen_ulong_t is always 64-bit on Arm (32-bit and 64-bit). But shouldn't
> >> we use xen_pfn_t here?
> >
> > I had put this question up earlier, but iirc Paul didn't like it.
> 
> I'd like to understand why Paul doesn't like it. We should never assume
> that a frame fit in xen_ulong_t. xen_pfn_t was exactly introduced for
> that purpose.

My reservation is whether xen_pfn_t is intended to hold either gfns or mfns, 
since this hypercall uses the same array for both. If it suitable then I am 
happy to change it, but Andrew led me to believe otherwise.

  Paul

> 
> Cheers,
> 
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

2017-10-27 Thread NathanStuder 


On 10/09/2017 10:14 AM, Lars Kurth wrote:
> 
>> On 27 Sep 2017, at 13:57, Robert VanVossen 
>>  wrote:
>>
>>
>>
>> On 9/26/2017 3:12 AM, Dario Faggioli wrote:
>>> [Cc-list modified by removing someone and adding someone else]
>>>
>>> On Mon, 2017-09-25 at 16:10 -0700, Stefano Stabellini wrote:
 On Mon, 11 Sep 2017, George Dunlap wrote:
> +### RTDS based Scheduler
> +
> +Status: Experimental
> +
> +A soft real-time CPU scheduler built to provide guaranteed CPU
> capacity to guest VMs on SMP hosts
> +
> +### ARINC653 Scheduler
> +
> +Status: Supported, Not security supported
> +
> +A periodically repeating fixed timeslice scheduler. Multicore
> support is not yet implemented.
> +
> +### Null Scheduler
> +
> +Status: Experimental
> +
> +A very simple, very static scheduling policy 
> +that always schedules the same vCPU(s) on the same pCPU(s). 
> +It is designed for maximum determinism and minimum overhead
> +on embedded platforms.
> 
> ...
> 
>>> Actually, the best candidate for gaining security support, is IMO
>>> ARINC. Code is also rather simple and "stable" (hasn't changed in the
>>> last... years!) and it's used by DornerWorks' people for some of their
>>> projects (I think?). It's also not tested in OSSTest, though, and
>>> considering how special purpose it is, I think we're not totally
>>> comfortable marking it as Sec-Supported, without feedback from the
>>> maintainers.
>>>
>>> George, Josh, Robert?
>>>
>>
>> Yes, we do still use the ARINC653 scheduler. Since it is so simple, it hasn't
>> really needed any modifications in the last couple years.
>>
>> We are not really sure what kind of feedback you are looking from us in 
>> regards
>> to marking it sec-supported, but would be happy to try and answer any 
>> questions.
>> If you have any specific questions or requests, we can discuss it internally 
>> and
>> get back to you.
> 
> I think there are two sets of issues: one around testing, which Dario 
> outlined.
> 
> For example, if you had some test harnesses that could be run on Xen release 
> candidates, which verify that the scheduler works as expected, that would
> help. It would imply a commitment to run the tests on release candidates.

We have an internal Xen test harness that we use to test the scheduler, but I
assume you would like it converted to use OSSTest instead, so that the
tests could be integrated into the main test suite someday?

> 
> The second question is what happens if someone reported a security issue on
> the scheduler. The security team would not have the capability to fix issues 
> in 
> the ARINC scheduler: so it would be necessary to pull in an expert under 
> embargo to help triage the issue, fix the issue and prove that the fix works. 
> This 
> would most likely require "the expert" to work to the timeline of the security
> team (which may require prioritising it over other work), as once a security 
> issue 
> has been reported, the reporter may insist on a disclosure schedule. If we 
> didn't 
> have a fix in time, because we don't get expert bandwidth, we could be forced 
> to 
> disclose an XSA without a fix.

We can support this and have enough staff familiar with the scheduler that
prioritizing security issues shouldn't be a problem.  The maintainers (Robbie
and Josh) can triage issues if and when the time comes, but if you need a more
dedicated "expert" for this type of issue, then that would likely be me.

Sorry for the relatively late response.

 Nate

> 
> Does this make sense?
> 
> Lars
> 
> 
> 
> ___
> 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] Xen 4.6 Hypervisor Fails to Boot and is Hanged in "Turning on Paging"

2017-10-27 Thread Doug Goldstein 
On 10/27/17 7:41 AM, Julien Grall wrote:
> Hi,
> 
> On 27/10/17 08:23, Srini wrote:
>> Xen 4.6 Hypervisor Fails to Boot and is Hanged in "Turning on Paging":
> 
> Again, as I already said on embedded-pv-devel ML, why are you using Xen
> 4.6? It was released 2 years ago and supported anymore.

I have an idea why see below..

> 
> You should try Xen 4.9 first and report if it still does not work.

Agreed.


>> EVM : TI DRA7XX OMAP5
>> Xen versions - 4.6
>> Uboot version - 2016.05
>> Kernel Version - 4.4
>> Dev Host - 14.04

14.04 here would imply he's running some Ubuntu for ARM build. Ubuntu
14.04 shipped with Xen 4.6.

-- 
Doug Goldstein

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

Re: [Xen-devel] [PATCH v2 1/2] x86/boot: fix early error display

2017-10-27 Thread Doug Goldstein 
On 10/27/17 1:37 AM, Jan Beulich wrote:
 On 26.10.17 at 23:05,  wrote:
>> On 10/18/17 4:50 AM, Jan Beulich wrote:
>> On 17.10.17 at 23:41,  wrote:
 From: David Esler 

 In 9180f5365524 a change was made to the send_chr function to take in
 C-strings and print out a character at a time until a NULL was
 encountered. However there is no code to increment the current character
 position resulting in an endless loop of the first character. This adds
 a simple increment.
>>>
>>> This description is not accurate (it should have changed together with
>>> the change to how you fix the issue) - with VGA the increment does
>>> happen. Hence "display" in the title is perhaps also at least misleading.
>>> I would be fine to adjust both while committing (and then adding my
>>> R-b), but feel free to propose an alternative.
>>
>> Jan,
>>
>> Can you queue this for 4.9 as well? That's where we ran into the issue
>> in the first place.
> 
> That how I did understand it, so I've queued this already, but for
> it to become eligible to applying to 4.9 it first needs to pass the
> push gate on master.
> 
> Jan
> 

Of course. I didn't mean to imply this should jump any existing process.
I had just realized that I didn't explicitly mention versions in my
original email and I just wanted to make sure I was explicit instead of
assuming.

Thanks again.
-- 
Doug Goldstein

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

[Xen-devel] [PATCH] x86/cpuid: Enable new SSE/AVX/AVX512 cpu features

2017-10-27 Thread Yang Zhong 
Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
need expose to guest.wq

The bit definition:
CPUID.(EAX=7,ECX=0):ECX[bit 06] AVX512VBMI2
CPUID.(EAX=7,ECX=0):ECX[bit 08] GFNI
CPUID.(EAX=7,ECX=0):ECX[bit 09] VAES
CPUID.(EAX=7,ECX=0):ECX[bit 10] VPCLMULQDQ
CPUID.(EAX=7,ECX=0):ECX[bit 11] AVX512VNNI
CPUID.(EAX=7,ECX=0):ECX[bit 12] AVX512_BITALG

The release document ref below link:
https://software.intel.com/sites/default/files/managed/c5/15/\
architecture-instruction-set-extensions-programming-reference.pdf

Signed-off-by: Yang Zhong 
---
 docs/man/xl.cfg.pod.5.in|  3 ++-
 tools/libxl/libxl_cpuid.c   |  6 ++
 tools/misc/xen-cpuid.c  | 13 +++--
 xen/include/public/arch-x86/cpufeatureset.h |  6 ++
 xen/tools/gen-cpuid.py  |  3 ++-
 5 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index b7b91d8..d056768 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1731,7 +1731,8 @@ perfctr_core perfctr_nb pge pku popcnt pse pse36 psn 
rdrand rdseed rdtscp rtm
 sha skinit smap smep smx ss sse sse2 sse3 sse4.1 sse4.2 sse4_1 sse4_2 sse4a
 ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate
 svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc tsc-deadline tsc_adjust
-umip vme vmx wdt x2apic xop xsave xtpr
+umip vme vmx wdt x2apic xop xsave xtpr avx512_vbmi2 gfni vaes vpclmulqdq
+avx512_vnni avx512_bitalg
 
 
 The xend syntax is a list of values in the form of
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index e692b61..614991f 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -199,6 +199,12 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*cpuid, const char* str)
 {"umip", 0x0007,  0, CPUID_REG_ECX,  2,  1},
 {"pku",  0x0007,  0, CPUID_REG_ECX,  3,  1},
 {"ospke",0x0007,  0, CPUID_REG_ECX,  4,  1},
+{"avx512_vbmi2", 0x0007,  0, CPUID_REG_ECX,  6,  1},
+{"gfni", 0x0007,  0, CPUID_REG_ECX,  8,  1},
+{"vaes", 0x0007,  0, CPUID_REG_ECX,  9,  1},
+{"vpclmulqdq",   0x0007,  0, CPUID_REG_ECX, 10,  1},
+{"avx512_vnni",  0x0007,  0, CPUID_REG_ECX, 11,  1},
+{"avx512_bitalg",0x0007,  0, CPUID_REG_ECX, 12,  1},
 
 {"avx512-4vnniw",0x0007,  0, CPUID_REG_EDX,  2,  1},
 {"avx512-4fmaps",0x0007,  0, CPUID_REG_EDX,  3,  1},
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 106be0f..985deea 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -120,12 +120,13 @@ static const char *str_Da1[32] =
 
 static const char *str_7c0[32] =
 {
-[ 0] = "prechwt1", [ 1] = "avx512vbmi",
-[ 2] = "REZ",  [ 3] = "pku",
-[ 4] = "ospke",
-
-[5 ... 13] = "REZ",
-
+[ 0] = "prechwt1", [ 1] = "avx512vbmi",
+[ 2] = "REZ",  [ 3] = "pku",
+[ 4] = "ospke",[ 5] = "REZ",
+[ 6] = "avx512_vbmi2", [ 7] = "REZ",
+[ 8] = "gfni", [ 9] = "vaes",
+[10] = "vpclmulqdq",   [11] = "avx512_vnni",
+[12] = "avx512_bitalg",[13] = "REZ",
 [14] = "avx512_vpopcntdq",
 
 [15 ... 31] = "REZ",
diff --git a/xen/include/public/arch-x86/cpufeatureset.h 
b/xen/include/public/arch-x86/cpufeatureset.h
index 0ee3ea3..bb24b79 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -228,6 +228,12 @@ XEN_CPUFEATURE(AVX512VBMI,6*32+ 1) /*A  AVX-512 Vector 
Byte Manipulation Ins
 XEN_CPUFEATURE(UMIP,  6*32+ 2) /*S  User Mode Instruction Prevention */
 XEN_CPUFEATURE(PKU,   6*32+ 3) /*H  Protection Keys for Userspace */
 XEN_CPUFEATURE(OSPKE, 6*32+ 4) /*!  OS Protection Keys Enable */
+XEN_CPUFEATURE(AVX512_VBMI2,  6*32+ 6) /*A  addition AVX-512 VBMI Instructions 
*/
+XEN_CPUFEATURE(GFNI,  6*32+ 8) /*A  Galois Field New Instructions */
+XEN_CPUFEATURE(VAES,  6*32+ 9) /*A  Vector AES instructions */
+XEN_CPUFEATURE(VPCLMULQDQ,6*32+ 10) /*A  vector PCLMULQDQ instructions */
+XEN_CPUFEATURE(AVX512_VNNI,   6*32+ 11) /*A  Vector Neural Network 
Instructions */
+XEN_CPUFEATURE(AVX512_BITALG, 6*32+ 12) /*A  support for VPOPCNT[B,W] and 
VPSHUFBITQMB*/
 XEN_CPUFEATURE(AVX512_VPOPCNTDQ, 6*32+14) /*A  POPCNT for vectors of DW/QW */
 XEN_CPUFEATURE(RDPID, 6*32+22) /*A  RDPID instruction */
 
diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index 9ec4486..be8df48 100755
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -255,7 +255,8 @@ def crunch_numbers(state):
 # top of AVX512F
 AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD,
   AVX512BW, AVX512VL, AVX512VBMI, AVX512_4VNNIW,
-

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

2017-10-27 Thread osstest service owner 
flight 115298 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115298/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  26a896cde21c6d03de367190034fcc150b1bf2d8
baseline version:
 xen  03dd1e2a5414faf86f743ae96c2b63dbc81f27f6

Last test of basis   115217  2017-10-25 12:05:00 Z2 days
Testing same since   115298  2017-10-27 12:02:56 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Juergen Gross 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

2017-10-27 Thread Andre Przywara 
Hi,

On 25/10/17 09:22, Manish Jaggi wrote:
>
>
> On 10/23/2017 7:27 PM, Andre Przywara wrote:
>> Hi Manish,
>>
>> On 12/10/17 22:03, Manish Jaggi wrote:
>>> ACPI/IORT Support in Xen.
>>> --
>>>
>>> I had sent out patch series [0] to hide smmu from Dom0 IORT. Extending
>>> the scope
>>> and including all that is required to support ACPI/IORT in Xen.
>>> Presenting for review
>>> first _draft_ of design of ACPI/IORT support in Xen. Not complete
>>> though.
>>>
>>> Discussed is the parsing and generation of IORT table for Dom0 and
>>> DomUs.
>>> It is proposed that IORT be parsed and the information in saved into xen
>>> data-structure
>>> say host_iort_struct and is reused by all xen subsystems like ITS / SMMU
>>> etc.
>>>
>>> Since this is first draft is open to technical comments, modifications
>>> and suggestions. Please be open and feel free to add any missing points
>>> / additions.
>>>
>>> 1. What is IORT. What are its components ?
>>> 2. Current Support in Xen
>>> 3. IORT for Dom0
>>> 4. IORT for DomU
>>> 5. Parsing of IORT in Xen
>>> 6. Generation of IORT
>>> 7. Future Work and TODOs
>>>
>>> 1. What is IORT. What are its components ?
>>> 
>>> IORT refers to Input Output remapping table. It is essentially used
>>> to find
>>> information about the IO topology (PCIRC-SMMU-ITS) and relationships
>>> between
>>> devices.
>>>
>>> A general structure of IORT is has nodes which have information about
>>> PCI RC,
>>> SMMU, ITS and Platform devices. Using an IORT table relationship between
>>> RID -> StreamID -> DeviceId can be obtained. More specifically which
>>> device is
>>> behind which SMMU and which interrupt controller, this topology is
>>> described in
>>> IORT Table.
>>>
>>> RID is a requester ID in PCI context,
>>> StreamID is the ID of the device in SMMU context,
>>> DeviceID is the ID programmed in ITS.
>>>
>>> For a non-pci device RID could be simply an ID.
>>>
>>> Each iort_node contains an ID map array to translate from one ID into
>>> another.
>>> IDmap Entry {input_range, output_range, output_node_ref, id_count}
>>> This array is present in PCI RC node,SMMU node, Named component node etc
>>> and can reference to a SMMU or ITS node.
>>>
>>> 2. Current Support of IORT
>>> ---
>>> Currently Xen passes host IORT table to dom0 without any modifications.
>>> For DomU no IORT table is passed.
>>>
>>> 3. IORT for Dom0
>>> -
>>> IORT for Dom0 is prepared by xen and it is fairly similar to the host
>>> iort.
>>> However few nodes could be removed removed or modified. For instance
>>> - host SMMU nodes should not be present
>>> - ITS group nodes are same as host iort but, no stage2 mapping is done
>>> for them.
>> What do you mean with stage2 mapping?
> Please ignore this line. Copy paste error. Read it as follows
>
> - ITS group nodes are same as host iort.
> (though I would modify the same as in next draft)
>
>>
>>> - platform nodes (named components) may be selectively present depending
>>> on the case where xen is using some. This could be controlled by  xen
>>> command
>>> line.
>> Mmh, I am not so sure platform devices described in the IORT (those
>> which use MSIs!) are so much different from PCI devices here. My
>> understanding is those platform devices are network adapters, for
>> instance, for which Xen has no use.
> ok.
>> So I would translate "Named Components" or "platform devices" as devices
>> just not using the PCIe bus (so no config space and no (S)BDF), but
>> being otherwise the same from an ITS or SMMU point of view.
> Correct.
>>> - More items : TODO
>> I think we agreed upon rewriting the IORT table instead of patching it?
> yes. In fact if you look at my patch v2 on IORT SMMU hiding, it was
> _rewriting_ most of Dom0 IORT and not patching it.

I was just after the wording above:
"IORT for Dom0 is prepared by xen and it is fairly similar to the host
iort. However few nodes could be removed removed or modified."
... which sounds a bit like you alter the h/w IORT.
It would be good to clarify this by explicitly mentioning the
parsing/generation cycle, as this is a fundamental design decision.

> We can have a IRC discussion on this.
>
> I think apart from rewriting, the other tasks which were required that
> are handled in this epic task
> - parse IORT and save in xen internal data structures
> - common code to generate IORT for dom0/domU
> - All xen code that parses IORT multiple times use now the xen internal
> data structures.

Yes, that sounds about right.

> (I have explained this in this mail below)
>> So to some degree your statements are true, but when we rewrite the IORT
>> table without SMMUs (and possibly without other components like the
>> PMUs), it would be kind of a stretch to call it "fairly similar to the
>> host IORT". I think "based on the host IORT" would be more precise.
> Yes. Based on host IORT is better,thanks.
>>
>>> 4. IORT for DomU
>>>

[Xen-devel] HiKey 960 (ARM 64) rcu_preempt detected stalls

2017-10-27 Thread John P. McDermott (USN Civilian) 
Xen Developers,

Attempting to run Xen on a second generation (has switches instead of jumpers) 
HiKey 960, following the guidance on the Xen wiki. Everything builds, flashes, 
and runs as expected up to the point shown below. Xen hangs in a loop detecting 
rcu_preempt stalls. The specific CPU is not significant, as it varies from boot 
to boot. I have let this run for an hour and Xen never gets out of this loop. 
In this state, Xen is responsive to an initial serial attention sequence of 
ctrl-As. It successfully drops into the keyhandler mode and the help keyhandler 
works fine, but if you try any other keyhandler, Xen crashes.

I asked a colleague to try this on a second HiKey 960, using a different 
cross-compile host, and she gets exactly the same result.

Sincerely,

John

………..

Booting `Xen'


Loading driver at 0x000B87F3000 EntryPoint=0x000B88990C8
Loading driver at 0x000B87F3000 EntryPoint=0x000B88990C8 
Using modules provided by bootloader in FDT
Xen 4.10.0-rc (c/s Mon Oct 16 15:14:16 2017 +0100 git:24fb44e971) EFI loader
 Xen 4.10.0-rc
(XEN) Xen version 4.10.0-rc (m...@fw5540.net) (aarch64-linux-gnu-gcc (Linaro 
GCC 7.1-2017.05) 7.1.1 20170510) debug=y  Fri Oct 27 08:58:09 EDT 2017
(XEN) Latest ChangeSet: Mon Oct 16 15:14:16 2017 +0100 git:24fb44e971
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN)   Processor Features:  
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1122 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using PSCI-1.0 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1920 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=e82b1000
(XEN) gic_cpu_addr=e82b2000
(XEN) gic_hyp_addr=e82b4000
(XEN) gic_vcpu_addr=e82b6000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 384 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) Bringing up CPU1
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
(XEN) CPU 3 booted.
(XEN) Bringing up CPU4
(XEN) CPU 4 booted.
(XEN) Bringing up CPU5
(XEN) CPU 5 booted.
(XEN) Bringing up CPU6
(XEN) CPU 6 booted.
(XEN) Bringing up CPU7
(XEN) CPU 7 booted.
(XEN) Brought up 8 CPUs
(XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
(XEN) I/O virtualisation disabled
(XEN) build-id: d34b11f07b634270d6ce4d49a1110fb777f4a16e
(XEN) alternatives: Patching with alt table 400bced0 -> 400bd3a4
(XEN) grant_table.c:1688:IDLEv0 Expanding d0 grant table from 0 to 1 frames
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ b8917000
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x002000-0x003000 (256MB)
(XEN) BANK[1] 0x00a000-0x00b000 (256MB)
(XEN) Grant table range: 0x00bfe0-0x00bfe4
(XEN) Loading zImage from b8917000 to 2008-21133a00
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x2800-0x28008f9d
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
(XEN) ...done.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) ***
(XEN) PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR NOW
(XEN) ***
(XEN) 3... 2... 1... 
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to 
Xen)
(XEN) Freed 272kB init memory.
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER28
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER32
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER36
(XEN) d0v0:

Re: [Xen-devel] [PATCH for-4.10 1/9] gcov: return ENOSYS for unimplemented gcov domctl

2017-10-27 Thread Julien Grall 

Hi,

On 27/10/17 14:59, Ian Jackson wrote:

Roger Pau Monne writes ("[PATCH for-next 1/9] gcov: return ENOSYS for unimplemented 
gcov domctl"):

Signed-off-by: Roger Pau Monné 

...

  default:
-ret = -EINVAL;
+ret = -ENOSYS;
  break;
  }


Reviewed-by: Ian Jackson 

I think this is a bugfix which should go into 4.10.  Julien ?
(Subject line changed by me.)


Yes I agree.

Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.10 1/9] gcov: return ENOSYS for unimplemented gcov domctl

2017-10-27 Thread Ian Jackson 
Roger Pau Monne writes ("[PATCH for-next 1/9] gcov: return ENOSYS for 
unimplemented gcov domctl"):
> Signed-off-by: Roger Pau Monné 
...
>  default:
> -ret = -EINVAL;
> +ret = -ENOSYS;
>  break;
>  }

Reviewed-by: Ian Jackson 

I think this is a bugfix which should go into 4.10.  Julien ?
(Subject line changed by me.)

Ian.

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

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

2017-10-27 Thread Wei Liu 
On Thu, Oct 26, 2017 at 05:25:36PM +0200, Olaf Hering wrote:
> An upcoming change in systemd will mount xenfs right away, along with
> all other system mounts. This improves the detection of the
> virtualization environment, which is currently racy. Some parts of
> systemd rely on the presence of /proc/xen/capabilities, which will only
> exist if xenfs is mounted. Since xenfs is mounted by the proc-xen.mount
> unit, it will be processed very late. Other units may be processed
> earlier, and if they make use of ConditionVirtualization*= failures may
> occour.
> 
> Unfortunately mounting xenfs by systemd as an API filesystem will lead
> to errors when proc-xen.mount is processed. Since that mount point
> already exists the unit is considered as failed, and other units that
> depend on proc-xen.mount will not start. To avoid this the existing
> proc-xen.mount will be converted into proc-xen.service, which just
> mounts xenfs manually. All dependencies are updated by this change.
> 
> The existing conditionals in proc-xen.mount will prevent failures with
> existing systemd based installations:
> ConditionPathExists=!/proc/xen/capabilities will prevent execution with
> a new systemd that mounts xenfs. And this conditional, in combination
> with ConditionPathExists=/proc/xen, will trigger execution with an old
> systemd.
> 
> An absolute path to the mount binary has to be used. /bin/mount is
> expected to be universally available, nowaways it is a symlink to
> /usr/bin/mount.
> 
> Signed-off-by: Olaf Hering 

The code itself looks OK at a glance.

What is unsaid is that we need to backport this to older Xen releases so
that old Xen can work with new systemd.

Ian and Jan?

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

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

2017-10-27 Thread Julien Grall 

Hi,

Just answering to dom0 been 1:1 domain.

On 24/10/17 22:33, Stefano Stabellini wrote:

On Tue, 24 Oct 2017, Volodymyr Babchuk wrote:

For this series, I think we need a way to specify which domains can talk
to TEE, so that we can only allow it for a specific subset of DomUs. I
would probably use XSM for that.

I am afraid, this is not possible. As other domains aren't 1:1 mapped,
I need to have special translation code in mediator. Actually, I'm
writing it rigth now to test my changes in OP-TEE. But event this is
not enought for decent OP-TEE support.
What can be done right now: 100% Dom0-only support with vanilla
OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
even simplier task, so I can throw out some code from this patch
series. On other hand, in the future this will lead to sutiation when
two mediators for the same TEE shall be supported: one, simple, in
XEN, another, fully-functional in stubdom.


I think it is fine to support OP-TEE only in Dom0 to begin with.

Ideally, it would be in Dom0 for convenience and speed and the OP-TEE
capability would be specified as an XSM label. Ideally, it would not be
only in Dom0 because it is tied to the 1:1 map, but I understand now
that it is a requirement. I still think that the XSM label would be good
to have even if today it cannot be changed as only Dom0 is 1:1.


I thought a bit more about Dom0 been a 1:1 domain. It is only true for 
Device Memory and the initial RAM allocated for Dom0.


Dom0 may balloon out some pages because it has to map region belonging 
to other domain. Those regions will not be 1:1 mapped and translation 
will be needed if used.


The problem is very similar to DMA in dom0. I can't see any reason to 
not use those regions with OP-TEE. Am I wrong here?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.10 v2 0/5] tools/dombuilder: Fixes and improvements to grant handling

2017-10-27 Thread Julien Grall 

Hi Juergen,

On 25/10/17 08:08, Juergen Gross wrote:

On 24/10/17 18:06, Julien Grall wrote:

Hi,

I think this is 4.10 material (particularly patch #5). Juergen, would it
be possible get the some feedback on this series?


Patch 5: Reviewed-by: Juergen Gross 


Thank you!

For the series:

Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/vpmu: Remove unnecessary call to do_interrupt()

2017-10-27 Thread Julien Grall 



On 25/10/17 11:30, Andrew Cooper wrote:

On 25/10/17 00:30, Boris Ostrovsky wrote:

This call was left during PVHv1 removal (commit 33e5c32559e1 ("x86:
remove PVHv1 code")):

-if ( is_pvh_vcpu(sampling) &&
- !(vpmu_mode & XENPMU_MODE_ALL) &&
+if ( !(vpmu_mode & XENPMU_MODE_ALL) &&
   !vpmu->arch_vpmu_ops->do_interrupt(regs) )
  return;

As result of this extra call VPMU no longer works for PV guests on Intel
because we effectively lose value of MSR_CORE_PERF_GLOBAL_STATUS.

Signed-off-by: Boris Ostrovsky 


Reviewed-by: Andrew Cooper 


---
This should also go into 4.9


Agreed, and therefore makes it a 4.10 candidate at this point.


Release-acked-by: Julien Grall 

Cheers,



~Andrew



  xen/arch/x86/cpu/vpmu.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index fd2fcac..7baf461 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -227,10 +227,6 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
  if ( !vpmu->xenpmu_data )
  return;
  
-if ( !(vpmu_mode & XENPMU_MODE_ALL) &&

- !vpmu->arch_vpmu_ops->do_interrupt(regs) )
-return;
-
  if ( vpmu_is_set(vpmu, VPMU_CACHED) )
  return;
  



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



--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 2/2] arm/xen: vpl011: Fix SBSA UART interrupt assertion

2017-10-27 Thread Julien Grall 

Hi Stefano,

On 26/10/17 00:50, Stefano Stabellini wrote:

On Tue, 24 Oct 2017, Andre Przywara wrote:

From: Bhupinder Thakur 

With the current SBSA UART emulation, streaming larger amounts of data
(as caused by "find /", for instance) can lead to character loses.

 ^ losses



This is due to the OUT ring buffer getting full, because we change the
TX interrupt bit only when the FIFO is actually full, and not already
when it's half-way filled, as the Linux driver expects.
The SBSA spec does not explicitly state this, but we assume that an
SBSA compliant UART uses the PL011 default "interrupt FIFO level select
register" value of "1/2 way". The Linux driver certainly makes this
assumption, so it expect to be able to write a number of characters
after the TX interrupt line has been asserted.
On a similar issue we have the same wrong behaviour on the receive side.
However changing the RX interrupt to trigger on reaching half of the FIFO
level will lead to lag, because the guest would not be notified of incoming
characters until the FIFO is half way filled. This leads to inacceptible
lags when typing on a terminal.
Real hardware solves this issue by using the "receive timeout
interrupt" (RTI), which is triggered when character reception stops for
32 baud cycles. As we cannot and do not want to emulate any timing here,
we slightly abuse the timeout interrupt to notify the guest of new
characters: when a new character comes in, the RTI is asserted, when
the FIFO is cleared, the interrupt gets cleared.

So this patch changes the emulated interrupt trigger behaviour to come
as close to real hardware as possible: the RX and TX interrupt trigger
when the FIFO gets half full / half empty, and the RTI interrupt signals
new incoming characters.

[Andre: reword commit message, introduce receive timeout interrupt, add
 comments]

Signed-off-by: Bhupinder Thakur 
Reviewed-by: Andre Przywara 
Signed-off-by: Andre Przywara 


This is good, only minor cosmetic comments.

Acked-by: Stefano Stabellini 


Julien, can we have the release-ack?


Sure. For the 2 patches:

Release-acked-by: Julien Grall 

Cheers,






---
  xen/arch/arm/vpl011.c| 131 ++-
  xen/include/asm-arm/vpl011.h |   2 +
  2 files changed, 94 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 0b0743679f..6d02406acf 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -18,6 +18,9 @@
  
  #define XEN_WANT_FLEX_CONSOLE_RING 1
  
+/* We assume the PL011 default of "1/2 way" for the FIFO trigger level. */

+#define SBSA_UART_FIFO_LEVEL (SBSA_UART_FIFO_SIZE / 2)
+
  #include 
  #include 
  #include 
@@ -93,24 +96,37 @@ static uint8_t vpl011_read_data(struct domain *d)
   */
  if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) > 0 )
  {
+unsigned int fifo_level;
+
  data = intf->in[xencons_mask(in_cons, sizeof(intf->in))];
  in_cons += 1;
  smp_mb();
  intf->in_cons = in_cons;
+
+fifo_level = xencons_queued(in_prod, in_cons, sizeof(intf->in));


This is only cosmetics but can we call xencons_queued only once? See the `if' 
just above.



+/* If the FIFO is now empty, we clear the receive timeout interrupt. */
+if ( fifo_level == 0 )
+{
+vpl011->uartfr |= RXFE;
+vpl011->uartris &= ~RTI;
+}
+
+/* If the FIFO is more than half empty, we clear the RX interrupt. */
+if ( fifo_level < sizeof(intf->in) - SBSA_UART_FIFO_LEVEL )
+vpl011->uartris &= ~RXI;
+
+vpl011_update_interrupt_status(d);
  }
  else
  gprintk(XENLOG_ERR, "vpl011: Unexpected IN ring buffer empty\n");
  
-if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) == 0 )

-{
-vpl011->uartfr |= RXFE;
-vpl011->uartris &= ~RXI;
-}
-
+/*
+ * We have consumed a character or the FIFO was empty, so clear the
+ * "FIFO full" bit.
+ */
  vpl011->uartfr &= ~RXFF;
  
-vpl011_update_interrupt_status(d);

-
  VPL011_UNLOCK(d, flags);
  
  /*

@@ -122,6 +138,24 @@ static uint8_t vpl011_read_data(struct domain *d)
  return data;
  }
  
+static void vpl011_update_tx_fifo_status(struct vpl011 *vpl011,

+ unsigned int fifo_level)
+{
+struct xencons_interface *intf = vpl011->ring_buf;
+unsigned int fifo_threshold = sizeof(intf->out) - SBSA_UART_FIFO_LEVEL;
+
+BUILD_BUG_ON(sizeof (intf->out) < SBSA_UART_FIFO_SIZE);
+
+/*
+ * Set the TXI bit only when there is space for fifo_size/2 bytes which
+ * is the trigger level for asserting/de-assterting the TX interrupt.
+ */
+if ( fifo_level <=

Re: [Xen-devel] Xen 4.6 Hypervisor Fails to Boot and is Hanged in "Turning on Paging"

2017-10-27 Thread Julien Grall 

Hi,

On 27/10/17 08:23, Srini wrote:

Xen 4.6 Hypervisor Fails to Boot and is Hanged in "Turning on Paging":


Again, as I already said on embedded-pv-devel ML, why are you using Xen 
4.6? It was released 2 years ago and supported anymore.


You should try Xen 4.9 first and report if it still does not work.

Cheers,




EVM : TI DRA7XX OMAP5
Xen versions - 4.6
Uboot version - 2016.05
Kernel Version - 4.4
Dev Host - 14.04
Output :- Turn on Paging error

Please find the below logs:-

Welcome to minicom 2.5

OPTIONS: I18n
Compiled on May  2 2011, 10:05:24.
Port /dev/ttyUSB0

Press CTRL-A Z for help on special keys


U-Boot SPL 2016.05-gc8a0b5ceb8 (Aug 31 2017 - 13:18:46)
DRA752-GP ES1.0
no pinctrl for hs200_1_8v
no pinctrl for ddr_1_8v
*** Warning - bad CRC, using default environment

Trying to boot from MMC1
spl: falcon_args_file not set in environment, falling back to default
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img
reading u-boot.img
reading u-boot.img


U-Boot 2016.05-gc8a0b5ceb8 (Aug 31 2017 - 13:18:46 +0530)

CPU  : DRA752-GP ES1.0
Model: TI DRA742
Board: DRA74x EVM REV D.0
DRAM:  1.5 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - bad CRC, using default environment

GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
part_get_info_efi: *** ERROR: Invalid GPT ***
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
part_get_info_efi: *** ERROR: Invalid Backup GPT ***
ERROR: cannot find partition: 'userdata'

at arch/arm/cpu/armv7/omap-common/utils.c:195/mmc_get_part_size()
Warning: fastboot.userdata_size: unable to calc
SCSI:  SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
Found 0 device(s).
Net:
Warning: ethernet@48484000 using MAC address from ROM
eth0: ethernet@48484000
Hit any key to stop autoboot:  0
=> Ok
Unknown command 'Ok' - try 'help'
=>
Unknown command 'Ok' - try 'help'
=>
Unknown command 'Ok' - try 'help'
=>
Unknown command 'Ok' - try 'help'
=>
Unknown command 'Ok' - try 'help'
=>
Unknown command 'Ok' - try 'help'
=> setenv dtb_addr_r 0x825f
=> setenv xen_addr_r 0x9000
=> setenv kernel_addr_r 0xa000
=> setenv xen_bootargs 'sync_console console=dtuart dtuart=serial2'
=> setenv dom0_bootargs 'console=hvc0,115200n8 earlyprintk=xen debug
ignore_loglevel root=/dev/mmcblk0p2 rw rootwait fixrtc'
=> fatload mmc 0:1 $dtb_addr_r dra7-evm.dtb
reading dra7-evm.dtb
** Unable to read file dra7-evm.dtb **
=> fatload mmc 0:1 $dtb_addr_r devicetree-zImage-dra7-evm.dtb
reading devicetree-zImage-dra7-evm.dtb
108295 bytes read in 8 ms (12.9 MiB/s)
=> fatload mmc 0:1 $xen_addr_r xen-uImage
reading xen-uImage
820176 bytes read in 22 ms (35.6 MiB/s)
=> fatload mmc 0:1 $kernel_addr_r zImage
reading zImage
3551760 bytes read in 85 ms (39.8 MiB/s)
=> fdt addr $dtb_addr_r
=> fdt resize
=> fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
=> fdt resize
=> fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\"
=> fdt mknode /chosen modules
=> fdt set /chosen/modules '#address-cells' <1>
=> fdt set /chosen/modules '#size-cells' <1>
=> fdt mknode /chosen/modules module@0
=> fdt set /chosen/modules/module@0 compatible xen,linux-zimage
xen,multiboot-module
=> fdt set /chosen/modules/module@0 reg <$kernel_addr_r 0xa0>
=> bootm $xen_addr_r - $dtb_addr_r
## Booting kernel from Legacy Image at 9000 ...
Image Name:   XEN
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:820112 Bytes = 800.9 KiB
Load Address: 9000
Entry Point:  9000
Verifying Checksum ... OK
## Flattened Device Tree blob at 825f
Booting using the fdt blob at 0x825f
Loading Kernel Image ... OK
reserving fdt memory region: addr=825f size=1b000
Loading Device Tree to 8ffe2000, end 8fff ... OK

Starting kernel ...

- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -

  CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.5| VT102 |  Offline




--
Sent from: http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html

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



--
Julien Grall

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

Re: [Xen-devel] Some Xen pci-passthrough questions

2017-10-27 Thread Boris Ostrovsky 



On 10/27/2017 04:16 AM, Sander Eikelenboom wrote:

On 27/10/17 00:30, Boris Ostrovsky wrote:

On 10/26/2017 04:48 PM, Sander Eikelenboom wrote:

- Enabling the xen pt logging in qemu spit out some things, i wonder if they 
are normal:

 qemu-system-i386: -serial pty: char device redirected to /dev/pts/16 
(label serial0)
 [00:05.0] xen_pt_realize: Assigning real physical device 08:00.0 to 
devfn 0x28
 [00:05.0] xen_pt_register_regions: IO region 0 registered 
(size=0x2000 base_addr=0xfe1fe000 type: 0x4)

 Are these somehow expected / benign (they also occur when pci passthrough 
is succesful) ?:
 [00:05.0] xen_pt_config_reg_init: Offset 0x000e mismatch! 
Emulated=0x0080, host=0x, syncing to 0x0080.
 [00:05.0] xen_pt_config_reg_init: Offset 0x0010 mismatch! 
Emulated=0x, host=0xfe1fe004, syncing to 0xfe1fe004.
 [00:05.0] xen_pt_config_reg_init: Offset 0x0052 mismatch! 
Emulated=0x, host=0x4803, syncing to 0x0003.
 [00:05.0] xen_pt_config_reg_init: Offset 0x0072 mismatch! 
Emulated=0x, host=0x0086, syncing to 0x0080.
 [00:05.0] xen_pt_config_reg_init: Offset 0x00a4 mismatch! 
Emulated=0x, host=0x8fc0, syncing to 0x8fc0.
 [00:05.0] xen_pt_config_reg_init: Offset 0x00b2 mismatch! 
Emulated=0x, host=0x1012, syncing to 0x1012.

 [00:05.0] xen_pt_msix_init: get MSI-X table BAR base 0xfe1fe000
 [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8
 [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8, 
PCI_MSIX_ENTRY_SIZE = 0x10,  msix->table_offset_adjust = 0,  msix->table_base = 
0xfe1fe000
 [00:05.0] xen_pt_msix_init: Error: Can't map physical MSI-X table: 
Invalid argument
That's mmap() of /dev/mem failing:

mmap(NULL,
  total_entries * PCI_MSIX_ENTRY_SIZE +
msix->table_offset_adjust,
  PROT_READ,
  MAP_SHARED | MAP_LOCKED,
  fd,
  msix->table_base + table_off - msix->table_offset_adjust);


Are you running with Craig Bergstrom's patch?

Yes sorry for not being clear (and using the log of running with the
mmap patch), i specifically meant the "mismatch!" lines, although they
also appear in the working case (without the patch) so they probably
aren't an issue, but still thought it wouldn't hurt to ask :).


I believe these warnings are expected. At least in the case of BAR 
(offset 0x10) I can see that qemu initializes emulated register to 0 
(xen_pt_bar_reg_init()) which would not match what the actual HW has. 
But I'll let Antony or Stefan confirm that. (I do think the warnings 
look a bit too alarmist so perhaps they can be softened somewhat)


And as far as Craig's patch is concerned we know it's broken and will be 
reverted.


-boris

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

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

2017-10-27 Thread osstest service owner 
flight 115280 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115280/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507
 build-armhf-pvops 6 kernel-build fail REGR. vs. 114507

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

Re: [Xen-devel] [PATCH v1 4/5] tools: libxendevicemodel: Provide xendevicemodel_add_to_physmap

2017-10-27 Thread Ross Lagerwall 

On 10/27/2017 12:45 PM, Wei Liu wrote:

On Fri, Oct 20, 2017 at 10:22:55AM +0100, Paul Durrant wrote:

...

 CFLAGS   += -Werror -Wmissing-prototypes
diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index b66d4f9..2a23077 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -564,6 +564,23 @@ int xendevicemodel_shutdown(
 return xendevicemodel_op(dmod, domid, 1, , sizeof(op));
 }

+int xendevicemodel_add_to_physmap(
+xendevicemodel_handle *dmod, domid_t domid, uint64_t idx, uint64_t
gpfn)


Do you really want this to be single page? Populating VRAM is not going to be 
fast if you need to make 16MB / 4K hypercalls to do it.


This. Since we're introducing a new interface please consider giving it
the ability to batch.



Yes indeed. I sent a v2 of this patch series a few days ago which 
changes it to operate on a range.


--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v1 4/5] tools: libxendevicemodel: Provide xendevicemodel_add_to_physmap

2017-10-27 Thread Wei Liu 
On Fri, Oct 20, 2017 at 10:22:55AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> > Ross Lagerwall
> > Sent: 18 October 2017 15:04
> > To: Xen-devel 
> > Cc: Ross Lagerwall ; Ian Jackson
> > ; Wei Liu 
> > Subject: [Xen-devel] [PATCH v1 4/5] tools: libxendevicemodel: Provide
> > xendevicemodel_add_to_physmap
> > 
> > Signed-off-by: Ross Lagerwall 
> > ---
> >  tools/libs/devicemodel/Makefile |  2 +-
> >  tools/libs/devicemodel/core.c   | 17 +
> >  tools/libs/devicemodel/include/xendevicemodel.h | 13 +
> >  tools/libs/devicemodel/libxendevicemodel.map|  5 +
> >  4 files changed, 36 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libs/devicemodel/Makefile
> > b/tools/libs/devicemodel/Makefile
> > index 342371a..5b2df7a 100644
> > --- a/tools/libs/devicemodel/Makefile
> > +++ b/tools/libs/devicemodel/Makefile
> > @@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
> >  include $(XEN_ROOT)/tools/Rules.mk
> > 
> >  MAJOR= 1
> > -MINOR= 1
> > +MINOR= 2
> >  SHLIB_LDFLAGS += -Wl,--version-script=libxendevicemodel.map
> > 
> >  CFLAGS   += -Werror -Wmissing-prototypes
> > diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
> > index b66d4f9..2a23077 100644
> > --- a/tools/libs/devicemodel/core.c
> > +++ b/tools/libs/devicemodel/core.c
> > @@ -564,6 +564,23 @@ int xendevicemodel_shutdown(
> >  return xendevicemodel_op(dmod, domid, 1, , sizeof(op));
> >  }
> > 
> > +int xendevicemodel_add_to_physmap(
> > +xendevicemodel_handle *dmod, domid_t domid, uint64_t idx, uint64_t
> > gpfn)
> 
> Do you really want this to be single page? Populating VRAM is not going to be 
> fast if you need to make 16MB / 4K hypercalls to do it.

This. Since we're introducing a new interface please consider giving it
the ability to batch.

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

Re: [Xen-devel] [linux-linus test] 115244: regressions - FAIL

2017-10-27 Thread Roger Pau Monné 
On Fri, Oct 27, 2017 at 01:46:24AM +, osstest service owner wrote:
> flight 115244 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/115244/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 
> 114682

This seems to be the failure that we have been seeing in the Mass colo
also.

>  test-amd64-i386-libvirt-qcow2 10 debian-di-install   fail REGR. vs. 
> 114682

This is due to a network failure AFAICT:

Configure the package manager
-

!! ERROR: Cannot access repository

The repository on ftp.debian.org couldn't be accessed, so its updates will not 
be made available to you at this time. You should investigate this later.

Commented out entries for ftp.debian.org have been added to the 
/etc/apt/sources.list file.
[Press enter to continue] 

Roger.

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

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

2017-10-27 Thread osstest service owner 
flight 115275 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115275/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114814

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114814
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114814
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114814
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux4d4a6a3f8a12602ce8dc800123715fe7b5c1c3a1
baseline version:
 linux5d7a76acad403638f635c918cc63d1d44ffa4065

Last test of basis   114814  2017-10-20 20:51:56 Z6 days
Testing same since   114845  2017-10-21 16:14:17 Z5 days   10 attempts


People who touched revisions under test:
  Alex Deucher 
  Alexandre Belloni 
  Andrew Morton 
  Anoob Soman 
  Arnd Bergmann 
  Bart Van Assche 
  Ben Skeggs 
  Bin Liu 
  Borislav Petkov 
  Christoph Lameter 
  Christophe JAILLET 
  Coly Li 
  Dan Carpenter 
  David Rientjes 
  David S. Miller 
  Dennis Dalessandro 
  Dmitry V. Levin 
  Doug Ledford 
  Easwar Hariharan 
  Emmanuel

Re: [Xen-devel] [PATCH v2] libxc: remove stale error check for domain size in xc_sr_save_x86_hvm.c

2017-10-27 Thread Julien Grall 

Hi,

On 26/10/17 12:03, Wei Liu wrote:

On Thu, Oct 26, 2017 at 09:15:46AM +0100, Julien Grall wrote:

Hi Juergen,

On 10/26/2017 08:31 AM, Juergen Gross wrote:

On 24/10/17 12:09, Andrew Cooper wrote:

On 23/10/17 11:20, Juergen Gross wrote:

On 06/10/17 15:30, Julien Grall wrote:

Hi,

On 27/09/17 15:36, Wei Liu wrote:

On Tue, Sep 26, 2017 at 02:02:56PM +0200, Juergen Gross wrote:

Long ago domains to be saved were limited to 1TB size due to the
migration stream v1 limitations which used a 32 bit value for the
PFN and the frame type (4 bits) leaving only 28 bits for the PFN.

Migration stream V2 uses a 64 bit value for this purpose, so there
is no need to refuse saving (or migrating) domains larger than 1 TB.

For 32 bit toolstacks there is still a size limit, as domains larger
than about 1TB will lead to an exhausted virtual address space of the
saving process. So keep the test for 32 bit, but don't base it on the
page type macros. As a migration could lead to the situation where a
32 bit toolstack would have to handle such a large domain (in case the
sending side is 64 bit) the same test should be added for restoring a
domain.

Signed-off-by: Juergen Gross 

I will leave this to Andrew.

I don't really have an opinion here.


I will wait Andrew feedback before giving a release ack on this patch.

Andrew?


Sorry - this completely fell off my radar.

This is probably fine overall.


Julien, are you fine with the patch now?


I don't see any formal ack on this patch. Can we get one?



Acked-by: Wei Liu 


Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [adhoc test] 115230: all pass

2017-10-27 Thread Julien Grall 

Hi Jan,

On 26/10/17 11:47, Jan Beulich wrote:

On 25.10.17 at 20:53,  wrote:

[adhoc adhoc] 
harness 8f16840: MaxUmask: enforce a maximum umask value
115230: all pass

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


I assume this having been an ad hoc flight explains why I can't
access the logs? Could you perhaps adjust the permissions?


They are now published. Sorry for that.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/2] x86: further GS handling fixes

2017-10-27 Thread Julien Grall 

Hi,

On 26/10/17 08:30, Jan Beulich wrote:

1: don't latch wrong (stale) GS base addresses
2: fix asm() constraint for GS selector update

Patch 1 is strictly a bug fix. Patch 2 could be considered a merely
cosmetic change, as there's no known bad effect from the wrong
constraint so far, but personally I think it should nevertheless be
considered for 4.10.

Signed-off-by: Jan Beulich 


For the both:

Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

2017-10-27 Thread Julien Grall 

Hi,

On 26/10/17 16:39, Jan Beulich wrote:

On 26.10.17 at 17:32,  wrote:

On 26/10/17 16:26, Jan Beulich wrote:

On 17.10.17 at 15:24,  wrote:

+/* IN/OUT - If the tools domain is PV then, upon return, frame_list
+ *  will be populated with the MFNs of the resource.
+ *  If the tools domain is HVM then it is expected that, on
+ *  entry, frame_list will be populated with a list of GFNs
+ *  that will be mapped to the MFNs of the resource.
+ *  If -EIO is returned then the frame_list has only been
+ *  partially mapped and it is up to the caller to unmap all
+ *  the GFNs.
+ *  This parameter may be NULL if nr_frames is 0.
+ */
+XEN_GUEST_HANDLE(xen_ulong_t) frame_list;


This is still xen_ulong_t, which I can live with, but then you shouldn't
copy into / out of arrays of other types in acquire_resource() (the
more that this is common code, and iirc xen_ulong_t and
unsigned long aren't the same thing on ARM32).


xen_ulong_t is always 64-bit on Arm (32-bit and 64-bit). But shouldn't
we use xen_pfn_t here?


I had put this question up earlier, but iirc Paul didn't like it.


I'd like to understand why Paul doesn't like it. We should never assume 
that a frame fit in xen_ulong_t. xen_pfn_t was exactly introduced for 
that purpose.


Cheers,

--
Julien Grall

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

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

2017-10-27 Thread osstest service owner 
flight 115272 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115272/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114644
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114644

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  10 debian-install fail pass in 115235
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 115235
 test-armhf-armhf-xl-arndale   6 xen-installfail pass in 115235

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 115235 never pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 115235 never 
pass
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 115235 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 115235 never 
pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114644
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114644
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114644
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114644
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114644
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114644
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  03dd1e2a5414faf86f743ae96c2b63dbc81f27f6
baseline version:
 xen  24fb44e971a62b345c7b6ca3c03b454a1e150abe

Last test of basis   114644  2017-10-17 10:49:11 Z9 days
Failing since114670  2017-10-18 05:03:38 Z9 days   13 attempts
Testing same since   115235  2017-10-25 19:25:31 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Chao Gao 
  David Esler 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monne 
  Roger Pau Monné

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

2017-10-27 Thread Julien Grall 

Hi,

On 27/10/17 08:27, Hao, Xudong wrote:

This bug exist much long time, there are many discussion last year but not a 
solution then. I call out it now because there is a fix in qemu upstream:
commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
Author: Roger Pau Monne 
Date:   Thu Aug 24 16:07:03 2017 +0100

 xen/pt: allow QEMU to request MSI unmasking at bind time

The fix is not in qemu-xen tree yet, when will qemu-xen sync this fix? Is it 
possible to catch Xen 4.10's qemu-xen?


I will let Stefano and Anthony providing feedback before giving a 
release-ack here.




BTW, mail report bug is direct but not easy to track, I took much time to 
search this BUG report mail. @Lars, is there plan to introduce any bug system 
for Xen?


We recently introduced Jira ([1]) to track features and bugs.

[1] https://xenproject.atlassian.net/projects/XEN/issues.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5.1 8/8] configure: do_compiler: Dump some extra info under bash

2017-10-27 Thread Ian Jackson 
Stefano Stabellini writes ("Re: [PATCH v5.1 8/8] configure: do_compiler: Dump 
some extra info under bash"):
> CC'ing the maintainers for this.

Thanks, but scripts/get_maintainer.pl seems to print different
information for me... (see my other mail)

Ian.

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

Re: [Xen-devel] [PATCH v5.1 7/8] os-posix: Provide new -runas : facility

2017-10-27 Thread Ian Jackson 
Stefano Stabellini writes ("Re: [PATCH v5.1 7/8] os-posix: Provide new -runas 
: facility"):
> CC'ing the maintainers (scripts/get_maintainer.pl is your friend)

I don't know what your scripts/get_maintainer.pl does, but mine
says:

  get_maintainer.pl: No maintainers found, printing recent contributors.
  get_maintainer.pl: Do not blindly cc: them on patches!  Use common sense.

  Anthony PERARD  (commit_signer:1/2=50%)
  Paolo Bonzini  
(commit_signer:1/2=50%,commit_signer:11/57=19%)
  Ian Jackson  (commit_signer:1/2=50%)
  Michael Tokarev  (commit_signer:12/57=21%)
  Eric Blake  (commit_signer:10/57=18%)
  Thomas Huth  (commit_signer:8/57=14%)
  Markus Armbruster  (commit_signer:8/57=14%)
  qemu-de...@nongnu.org (open list:POSIX)

I have added Paolo, Markus and Daniel Berrange to the CCs of my patch
on the basis that they have commented already...

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v5.1 2/8] xen: restrict: use xentoolcore_restrict_all

2017-10-27 Thread Ian Jackson 
Stefano Stabellini writes ("Re: [PATCH v5.1 2/8] xen: restrict: use 
xentoolcore_restrict_all"):
> On Fri, 20 Oct 2017, Ian Jackson wrote:
...
> > Drop individual use of xendevicemodel_restrict and
> > xenforeignmemory_restrict.  These are not actually effective in this
> > version of qemu, because qemu has a large number of fds open onto
> > various Xen control devices.
...
> Wait, if the compat stub returns error, and this patch removed the code
> to check for ENOTTY, doesn't it prevent any QEMU compiled against older
> Xen from working?
> 
> Or am I missing something?

You are right, but this is intended.  The paragraph I quote in the
commit message above is intended to explain.

That is: without xentoolcore_restrict_all, -xen-domid-restrict is a
booby-trap.  It does not actually prevent a compromised qemu from
doing anything.  So there is no reason to pass it in such a
configuration.  If you do pass it it is better for the domain startup
to fail, than for it to carry on without the restriction.

The only reason I am not saying someone should be issuing an advisory
is that this feature was never supported by any of the Xen toolstacks.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v5.1 6/8] xen: destroy_hvm_domain: Try xendevicemodel_shutdown

2017-10-27 Thread Ian Jackson 
Stefano Stabellini writes ("Re: [PATCH v5.1 6/8] xen: destroy_hvm_domain: Try 
xendevicemodel_shutdown"):
> On Fri, 20 Oct 2017, Ian Jackson wrote:
> > xc_interface_open etc. is not going to work if we have dropped
> > privilege, but xendevicemodel_shutdown will if everything is new
> > enough.
> > 
> > xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so
> > provide a stub for earlier versions.
...
> > +if (xen_dmod) {
> > +rc = xendevicemodel_shutdown(xen_dmod, xen_domid, reason);
> > +if (!rc) {
> > +return;
> > +}
> > +perror("xendevicemodel_shutdown failed");
> 
> I don't think is a good idea to print an error because this is actually
> a normal condition when QEMU is build and run against an older Xen.
> Users might get confused when looking at the logs.

Oh.  Yes.  I wrote this before I provided the fallback stub in
xen_common.h, and therefore before I properly understood the approach
taken to fallbacks.  The fallback logic here is not correct.

> But it would be correct to print an error if errno != ENOTTY.

Indeed.

I have changed it to read like this:

if (xen_dmod) {
rc = xendevicemodel_shutdown(xen_dmod, xen_domid, reason);
if (!rc) {
return;
}
if (errno != ENOTTY /* old Xen */)
perror("xendevicemodel_shutdown failed");
/* well, try the old thing then */
}

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v5.1 1/8] xen: link against xentoolcore

2017-10-27 Thread Ian Jackson 
Stefano Stabellini writes ("Re: [PATCH v5.1 1/8] xen: link against 
xentoolcore"):
> On Fri, 20 Oct 2017, Ian Jackson wrote:
> >then
> > -  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
> > +  xen_stable_libs="-lxendevicemodel $xen_stable_libs -lxentoolcore"
> 
> Is it on purpose that -lxentoolcore is at the end of this string rather
> than before $xen_stable_libs?

Yes.  xentoolcore is required by the other libraries, and this is
therefore the correct ordering for situations where the link order
matters.

> In any case
> 
> Acked-by: Stefano Stabellini 

Thanks,
Ian.

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

Re: [Xen-devel] Xen 4.10.0 RC1 test result

2017-10-27 Thread Andrew Cooper 
On 27/10/17 09:28, Hao, Xudong wrote:
>
> We performed Xen 4.10 RC1 testing on Intel Xeon Skylake, Broadwell
> server, Intel Atom Denverton platforms, verified many functional
> features, which include new features Local MCE, L2 CAT and UMIP on Xen
> 4.10. We’d like to share the result out.
>
>  
>
> Most of features passed to testing on Xen 4.10 RC1, VT-d, RAS and
> nested has some bugs.
>
> VT-d:
>
> [BUG] win2008 guest cannot get ip through sriov
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg127433.html
>
>  
>
> RAS:
>
> [BUG] xen-mceinj tool testing cause dom0 crash
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html
>
>  
>
> Nested:
>
> Nested status is better than Xen 4.9.0, KVM on Xen, HyperV on Xen
> works, while Xen on Xen, VMware on Xen fail.
> https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen
>

Do you have any further details on your HyperV scenarios, in particular
versions of HyperV and the hardware involved, and guests booted under
HyperV?

XenServers current nested-virt testing status shows a rather bleaker
picture.

More modern version of Windows Server fail to initialise the HyperV
role, because Xen doesn't advertise Virtual NMI support to L1.  (One
version, Server 2012 R2 I believe, indicates the same, but with a BSOD
instead).  Older versions still do actually boot successfully.

When booting windows guests under nested HyperV, old versions appear to
be stable with a single one-vcpu guest, but unstable with multiple vcpus
or multiple single-vcpu guests.  The instability here is a VMEntry
failure trying to inject an NMI, and occurs because HyperV and Xen
disagree on whether to use Virtual NMI, resulting in HyperV thinking
virtual NMI is disabled, but it is actually enabled in hardware.

When booting windows guests under more modern nested HyperV, the guest
is crashing because of a pagefault when trying to access the APIC page. 
We haven't tracked down the cause of this, but I expect it is something
to do with emulating instruction while in nested vcpu context.

Thanks,

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

Re: [Xen-devel] [RFC XEN PATCH v3 02/39] x86_64/mm: drop redundant MFN to page conventions in cleanup_frame_table()

2017-10-27 Thread Andrew Cooper 
On 27/10/17 07:58, Chao Peng wrote:
> On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote:
>> Replace pdx_to_page(pfn_to_pdx(pfn)) by mfn_to_page(pfn), which is
>> identical to the former.
> Looks good to me.

Is that a Reviewed-by: then?

>
> Chao
>> Signed-off-by: Haozhong Zhang 
>> ---
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 

Reviewed-by: Andrew Cooper 

Given that this is a trivial cleanup patch, I will include it in the
x86-next branch I am maintaining until the 4.11 release window opens.

~Andrew

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

Re: [Xen-devel] Xen 4.10.0 RC1 test result

2017-10-27 Thread Jan Beulich 
>>> On 27.10.17 at 10:28,  wrote:
> RAS:
> [BUG] xen-mceinj tool testing cause dom0 crash 
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html 

Please can you provide helpful links? This doesn't point to the
beginning of the thread, and the mail archive chosen doesn't
appear to have an easy way to go back to the head of a
thread. And when I go through the parts of the thread which
are easily accessible there, it looks like you've never followed
up on the additional information (log) request. This way I don't
see how we can make progress there. Plus, looking over the
Cc lists there, Linux maintainers also don't appear to have
been involved at any time.

Jan


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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

2017-10-27 Thread Hao, Xudong 
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, October 27, 2017 4:38 PM
> To: Julien Grall ; Anthony PERARD
> ; Hao, Xudong ;
> sstabell...@kernel.org
> Cc: Lars Kurth ; Wei Liu ; Quan Xu
> ; Kang, Luwei ; Zhang,
> PengtaoX ; Xen-devel  de...@lists.xenproject.org>
> Subject: RE: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov
> 
> >>> On 27.10.17 at 09:27,  wrote:
> > This bug exist much long time, there are many discussion last year but
> > not a solution then. I call out it now because there is a fix in qemu 
> > upstream:
> > commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
> > Author: Roger Pau Monne 
> > Date:   Thu Aug 24 16:07:03 2017 +0100
> >
> > xen/pt: allow QEMU to request MSI unmasking at bind time
> >
> > The fix is not in qemu-xen tree yet, when will qemu-xen sync this fix?
> > Is it possible to catch Xen 4.10's qemu-xen?
> 
> Well, the question shouldn't have been directed at Quan or me - at this point 
> it
> would need to be sorted out between the qemu maintainers (Stefano and
> Anthony) and the release manager (Julien).
> 
Yes, Thanks to point out it. I just replied this mail (default is you two), and 
CC the two qemu maintainers and Julien.


Thanks,
-Xudong

> Jan


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

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

2017-10-27 Thread Platform Team regression test user 
flight 72360 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72360/

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-pvops 2 hosts-allocate   broken like 72334
 build-arm64   2 hosts-allocate   broken like 72334
 build-arm64-pvops 3 capture-logs broken like 72334
 build-arm64   3 capture-logs broken like 72334
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 migrate-support-check fail 
like 72334
 test-armhf-armhf-armhf-jessie-netboot-pygrub 13 saverestore-support-check fail 
like 72334

baseline version:
 flight   72334

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] [BUG] win2008 guest cannot get ip through sriov

2017-10-27 Thread Jan Beulich 
>>> On 27.10.17 at 09:27,  wrote:
> This bug exist much long time, there are many discussion last year but not a 
> solution then. I call out it now because there is a fix in qemu upstream:
> commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
> Author: Roger Pau Monne 
> Date:   Thu Aug 24 16:07:03 2017 +0100
> 
> xen/pt: allow QEMU to request MSI unmasking at bind time
> 
> The fix is not in qemu-xen tree yet, when will qemu-xen sync this fix? Is it 
> possible to catch Xen 4.10's qemu-xen?

Well, the question shouldn't have been directed at Quan or me -
at this point it would need to be sorted out between the qemu
maintainers (Stefano and Anthony) and the release manager
(Julien).

Jan


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

[Xen-devel] Xen 4.10.0 RC1 test result

2017-10-27 Thread Hao, Xudong 
We performed Xen 4.10 RC1 testing on Intel Xeon Skylake, Broadwell server, 
Intel Atom Denverton platforms, verified many functional features, which 
include new features Local MCE, L2 CAT and UMIP on Xen 4.10. We'd like to share 
the result out.

Most of features passed to testing on Xen 4.10 RC1, VT-d, RAS and nested has 
some bugs.
VT-d:
[BUG] win2008 guest cannot get ip through sriov 
https://www.mail-archive.com/xen-devel@lists.xen.org/msg127433.html

RAS:
[BUG] xen-mceinj tool testing cause dom0 crash 
https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html

Nested:
Nested status is better than Xen 4.9.0, KVM on Xen, HyperV on Xen works, while 
Xen on Xen, VMware on Xen fail. 
https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen


Features

Test Result

Local MCE

Pass

L2 CAT

Pass

UMIP

Pass

AVX512

Pass

Protection keys

Pass

Altp2m

Pass

RDT(CMT, CAT, CDP, MBM)

Pass

VT-d PI

Pass

XSAVES

Pass

MPX

Pass

PML (Page-modification Logging)

Pass

Nested

Buggy

VT-d/SR-IOV

Buggy

RAS

Buggy

ACPI

Pass



Best Regards,
Xudong







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

Re: [Xen-devel] Some Xen pci-passthrough questions

2017-10-27 Thread Sander Eikelenboom 
On 27/10/17 00:30, Boris Ostrovsky wrote:
> On 10/26/2017 04:48 PM, Sander Eikelenboom wrote:
>> Hi Boris / Andrew,
>>
>> In the aftermath of the linux mmap path I have some questions regarding 
>> pci-passthrough:
>>
>> - Is pci-passthrough in combination with an auto-ballooning dom0 supposed to 
>> be a supported combination ?
> 
> I thought it is. I haven't done passthrough recently (and can't do it
> right now) but I when I did I am pretty sure I was running with
> auto-ballooning dom0.
> 
> Our production does passthrough but they always run with dom0's memory
> limited.
> 

Ok, at least it's not a clear "nope", so i will have a go again in a
couple of days and report back.

>>
>> I have used dom0_maxmem settings for dom0 since ages and that works fine 
>> and stable, 
>> but while doing some testing around the linux mmap patch i also thought 
>> to try an auto-ballooning dom0.
>>
>> That ended up in a crashing PV guest with pci-passthrough and a strange 
>> error on two HVM's with pci-passthrough,
>> about vcpu's (while no configurations where changed).
>>
>> So if it is supported i probably have some more testing and reporting to 
>> do ...
>>
>>
>> - While adding some extra logging and enabling the logging on xen pt in qemu,
>>   i wonder if it wouldn't be beneficial to have at least some basic logging 
>> permanently enabled ? 
>>
>> - Enabling the xen pt logging in qemu spit out some things, i wonder if they 
>> are normal:
>>
>> qemu-system-i386: -serial pty: char device redirected to /dev/pts/16 
>> (label serial0)
>> [00:05.0] xen_pt_realize: Assigning real physical device 08:00.0 to 
>> devfn 0x28
>> [00:05.0] xen_pt_register_regions: IO region 0 registered 
>> (size=0x2000 base_addr=0xfe1fe000 type: 0x4)
>>
>> Are these somehow expected / benign (they also occur when pci 
>> passthrough is succesful) ?:
>> [00:05.0] xen_pt_config_reg_init: Offset 0x000e mismatch! 
>> Emulated=0x0080, host=0x, syncing to 0x0080.
>> [00:05.0] xen_pt_config_reg_init: Offset 0x0010 mismatch! 
>> Emulated=0x, host=0xfe1fe004, syncing to 0xfe1fe004.
>> [00:05.0] xen_pt_config_reg_init: Offset 0x0052 mismatch! 
>> Emulated=0x, host=0x4803, syncing to 0x0003.
>> [00:05.0] xen_pt_config_reg_init: Offset 0x0072 mismatch! 
>> Emulated=0x, host=0x0086, syncing to 0x0080.
>> [00:05.0] xen_pt_config_reg_init: Offset 0x00a4 mismatch! 
>> Emulated=0x, host=0x8fc0, syncing to 0x8fc0.
>> [00:05.0] xen_pt_config_reg_init: Offset 0x00b2 mismatch! 
>> Emulated=0x, host=0x1012, syncing to 0x1012.
>>
>> [00:05.0] xen_pt_msix_init: get MSI-X table BAR base 0xfe1fe000
>> [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8
>> [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8, 
>> PCI_MSIX_ENTRY_SIZE = 0x10,  msix->table_offset_adjust = 0,  
>> msix->table_base = 0xfe1fe000
>> [00:05.0] xen_pt_msix_init: Error: Can't map physical MSI-X table: 
>> Invalid argument
> 
> That's mmap() of /dev/mem failing:
> 
> mmap(NULL,
>  total_entries * PCI_MSIX_ENTRY_SIZE +
> msix->table_offset_adjust,
>  PROT_READ,
>  MAP_SHARED | MAP_LOCKED,
>  fd,
>  msix->table_base + table_off - msix->table_offset_adjust);
> 
> 
> Are you running with Craig Bergstrom's patch?

Yes sorry for not being clear (and using the log of running with the
mmap patch), i specifically meant the "mismatch!" lines, although they
also appear in the working case (without the patch) so they probably
aren't an issue, but still thought it wouldn't hurt to ask :).




> -boris
> 
> 
>> [00:05.0] xen_pt_msix_size_init: Error: Internal error: Invalid 
>> xen_pt_msix_init.
>> Failed to initialize 12/15, type = 0x1, rc: -22
>> [00:05.0] xen_pt_msi_set_enable: disabling MSI.
>>
>> This crash seems to indicate the above disabling of MSI isn't handled 
>> well enough to prevent this from happening: 
>> *** Error in `/usr/local/lib/xen/bin/qemu-system-i386': corrupted 
>> size vs. prev_size: 0x55ce13565570 ***
>> === Backtrace: =
>> /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f700ab7ebcb]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f700ab84f96]
>> 
>>
>> --
>> Sander
> 


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

Re: [Xen-devel] [RFC XEN PATCH v3 03/39] x86_64/mm: avoid cleaning the unmapped frame table

2017-10-27 Thread Chao Peng 
On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote:
> cleanup_frame_table() initializes the entire newly added frame table
> to all -1's. If it's called after extend_frame_table() failed to map
> the entire frame table, the initialization will hit a page fault.
> 
> Move the cleanup of partially mapped frametable to
> extend_frame_table(),
> which has enough knowledge of the mapping status.

Overall the patch fixed the issue. But I guess you can achieve this with
less change. For example, you can use info->cur to pass the last mapped
pfn and only memset those mapped chuncks.

Chao

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

Re: [Xen-devel] [PATCH v3 1/1] xen/time: do not decrease steal time after live migration on xen

2017-10-27 Thread Juergen Gross 
On 27/10/17 09:40, Dongli Zhang wrote:
> Hi Juergen,
> 
> On 10/27/2017 03:31 PM, Juergen Gross wrote:
>> On 27/10/17 09:16, Dongli Zhang wrote:
>>> Hi Boris,
>>>
>>> On 10/25/2017 11:12 PM, Boris Ostrovsky wrote:
 On 10/25/2017 02:45 AM, Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
> derived from previous return value of xen_steal_clock().
>
> For instance, steal time of each vcpu is 335 before live migration.
>
> cpu  198 0 368 200064 1962 0 0 1340 0 0
> cpu0 38 0 81 50063 492 0 0 335 0 0
> cpu1 65 0 97 49763 634 0 0 335 0 0
> cpu2 38 0 81 50098 462 0 0 335 0 0
> cpu3 56 0 107 50138 374 0 0 335 0 0
>
> After live migration, steal time is reduced to 312.
>
> cpu  200 0 370 200330 1971 0 0 1248 0 0
> cpu0 38 0 82 50123 500 0 0 312 0 0
> cpu1 65 0 97 49832 634 0 0 312 0 0
> cpu2 39 0 82 50167 462 0 0 312 0 0
> cpu3 56 0 107 50207 374 0 0 312 0 0
>
> Since runstate times are cumulative and cleared during xen live migration
> by xen hypervisor, the idea of this patch is to accumulate runstate times
> to global percpu variables before live migration suspend. Once guest VM is
> resumed, xen_get_runstate_snapshot_cpu() would always return the sum of 
> new
> runstate times and previously accumulated times stored in global percpu
> variables.
>
> Similar and more severe issue would impact prior linux 4.8-4.10 as
> discussed by Michael Las at
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
> which would overflow steal time and lead to 100% st usage in top command
> for linux 4.8-4.10. A backport of this patch would fix that issue.
>
> References: 
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
> Signed-off-by: Dongli Zhang 
>
> ---
> Changed since v1:
>   * relocate modification to xen_get_runstate_snapshot_cpu
>
> Changed since v2:
>   * accumulate runstate times before live migration
>
> ---
>  drivers/xen/manage.c  |  1 +
>  drivers/xen/time.c| 19 +++
>  include/xen/xen-ops.h |  1 +
>  3 files changed, 21 insertions(+)
>
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index c425d03..9aa2955 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -72,6 +72,7 @@ static int xen_suspend(void *data)
>   }
>  
>   gnttab_suspend();
> + xen_accumulate_runstate_time();
>   xen_arch_pre_suspend();
>  
>   /*
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index ac5f23f..6df3f82 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -19,6 +19,8 @@
>  /* runstate info updated by Xen */
>  static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
>  
> +static DEFINE_PER_CPU(u64[4], old_runstate_time);
> +
>  /* return an consistent snapshot of 64-bit time/counter value */
>  static u64 get64(const u64 *p)
>  {
> @@ -52,6 +54,7 @@ static void xen_get_runstate_snapshot_cpu(struct 
> vcpu_runstate_info *res,
>  {
>   u64 state_time;
>   struct vcpu_runstate_info *state;
> + int i;
>  
>   BUG_ON(preemptible());
>  
> @@ -64,6 +67,22 @@ static void xen_get_runstate_snapshot_cpu(struct 
> vcpu_runstate_info *res,
>   rmb();  /* Hypervisor might update data. */
>   } while (get64(>state_entry_time) != state_time ||
>(state_time & XEN_RUNSTATE_UPDATE));
> +
> + for (i = 0; i < 4; i++)
> + res->time[i] += per_cpu(old_runstate_time, cpu)[i];
> +}
> +
> +void xen_accumulate_runstate_time(void)
> +{
> + struct vcpu_runstate_info state;
> + int cpu;
> +
> + for_each_possible_cpu(cpu) {
> + xen_get_runstate_snapshot_cpu(, cpu);
> + memcpy(per_cpu(old_runstate_time, cpu),
> + state.time,
> + 4 * sizeof(u64));

 sizeof(old_runstate_time). (I think this should work for per_cpu variables)

> + }

 Hmm.. This may not perform as intended if we are merely checkpointing
 (or pausing) the guest (i.e. if HYPERVISOR_suspend() returns 1). We will
 double-account for the last interval that the guest has run.

 I'd rather not have yet another per-cpu variable but I can't think of
 anything else. Perhaps you or others can come up with something better.
>>>
>>> I have 3 options so far.
>>>
>>> The 1st option is to another per-cpu variable while you do not like it.
>>>
>>> The 2nd option is to borrow from what do_stolen_accounting()

Re: [Xen-devel] [PATCH v3 1/1] xen/time: do not decrease steal time after live migration on xen

2017-10-27 Thread Dongli Zhang 
Hi Juergen,

On 10/27/2017 03:31 PM, Juergen Gross wrote:
> On 27/10/17 09:16, Dongli Zhang wrote:
>> Hi Boris,
>>
>> On 10/25/2017 11:12 PM, Boris Ostrovsky wrote:
>>> On 10/25/2017 02:45 AM, Dongli Zhang wrote:
 After guest live migration on xen, steal time in /proc/stat
 (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
 xen_steal_lock() might be less than this_rq()->prev_steal_time which is
 derived from previous return value of xen_steal_clock().

 For instance, steal time of each vcpu is 335 before live migration.

 cpu  198 0 368 200064 1962 0 0 1340 0 0
 cpu0 38 0 81 50063 492 0 0 335 0 0
 cpu1 65 0 97 49763 634 0 0 335 0 0
 cpu2 38 0 81 50098 462 0 0 335 0 0
 cpu3 56 0 107 50138 374 0 0 335 0 0

 After live migration, steal time is reduced to 312.

 cpu  200 0 370 200330 1971 0 0 1248 0 0
 cpu0 38 0 82 50123 500 0 0 312 0 0
 cpu1 65 0 97 49832 634 0 0 312 0 0
 cpu2 39 0 82 50167 462 0 0 312 0 0
 cpu3 56 0 107 50207 374 0 0 312 0 0

 Since runstate times are cumulative and cleared during xen live migration
 by xen hypervisor, the idea of this patch is to accumulate runstate times
 to global percpu variables before live migration suspend. Once guest VM is
 resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
 runstate times and previously accumulated times stored in global percpu
 variables.

 Similar and more severe issue would impact prior linux 4.8-4.10 as
 discussed by Michael Las at
 https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
 which would overflow steal time and lead to 100% st usage in top command
 for linux 4.8-4.10. A backport of this patch would fix that issue.

 References: 
 https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
 Signed-off-by: Dongli Zhang 

 ---
 Changed since v1:
   * relocate modification to xen_get_runstate_snapshot_cpu

 Changed since v2:
   * accumulate runstate times before live migration

 ---
  drivers/xen/manage.c  |  1 +
  drivers/xen/time.c| 19 +++
  include/xen/xen-ops.h |  1 +
  3 files changed, 21 insertions(+)

 diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
 index c425d03..9aa2955 100644
 --- a/drivers/xen/manage.c
 +++ b/drivers/xen/manage.c
 @@ -72,6 +72,7 @@ static int xen_suspend(void *data)
}
  
gnttab_suspend();
 +  xen_accumulate_runstate_time();
xen_arch_pre_suspend();
  
/*
 diff --git a/drivers/xen/time.c b/drivers/xen/time.c
 index ac5f23f..6df3f82 100644
 --- a/drivers/xen/time.c
 +++ b/drivers/xen/time.c
 @@ -19,6 +19,8 @@
  /* runstate info updated by Xen */
  static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
  
 +static DEFINE_PER_CPU(u64[4], old_runstate_time);
 +
  /* return an consistent snapshot of 64-bit time/counter value */
  static u64 get64(const u64 *p)
  {
 @@ -52,6 +54,7 @@ static void xen_get_runstate_snapshot_cpu(struct 
 vcpu_runstate_info *res,
  {
u64 state_time;
struct vcpu_runstate_info *state;
 +  int i;
  
BUG_ON(preemptible());
  
 @@ -64,6 +67,22 @@ static void xen_get_runstate_snapshot_cpu(struct 
 vcpu_runstate_info *res,
rmb();  /* Hypervisor might update data. */
} while (get64(>state_entry_time) != state_time ||
 (state_time & XEN_RUNSTATE_UPDATE));
 +
 +  for (i = 0; i < 4; i++)
 +  res->time[i] += per_cpu(old_runstate_time, cpu)[i];
 +}
 +
 +void xen_accumulate_runstate_time(void)
 +{
 +  struct vcpu_runstate_info state;
 +  int cpu;
 +
 +  for_each_possible_cpu(cpu) {
 +  xen_get_runstate_snapshot_cpu(, cpu);
 +  memcpy(per_cpu(old_runstate_time, cpu),
 +  state.time,
 +  4 * sizeof(u64));
>>>
>>> sizeof(old_runstate_time). (I think this should work for per_cpu variables)
>>>
 +  }
>>>
>>> Hmm.. This may not perform as intended if we are merely checkpointing
>>> (or pausing) the guest (i.e. if HYPERVISOR_suspend() returns 1). We will
>>> double-account for the last interval that the guest has run.
>>>
>>> I'd rather not have yet another per-cpu variable but I can't think of
>>> anything else. Perhaps you or others can come up with something better.
>>
>> I have 3 options so far.
>>
>> The 1st option is to another per-cpu variable while you do not like it.
>>
>> The 2nd option is to borrow from what do_stolen_accounting() used to do. 
>> Compute
>> the delta of current and previous time and do nothing if delta is less than 
>> 0.
>> The drawback of this option is guest might

[Xen-devel] [GIT PULL] xen: fixes for 4.14-rc7

2017-10-27 Thread Juergen Gross 
Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.14c-rc7-tag

xen: fixes for 4.14-rc7

It contains:
- a fix for the Xen gntdev device repairing an issue in case of partial
  failure of mapping multiple pages of another domain
- a fix of a regression in the Xen balloon driver introduced in 4.13
- a build fix for Xen on ARM which will trigger e.g. for Linux RT
- a maintainers update for pvops (not really Xen, but carrying through
  this tree just for convenience)

Thanks.

Juergen

 MAINTAINERS   |  1 -
 arch/arm/xen/p2m.c|  2 +-
 drivers/xen/gntdev.c  |  2 +-
 drivers/xen/xen-balloon.c | 19 +--
 4 files changed, 15 insertions(+), 9 deletions(-)

Juergen Gross (3):
  xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()
  xen: fix booting ballooned down hvm guest
  maintainers: drop Chris Wright from pvops

Sebastian Andrzej Siewior (1):
  arm/xen: don't inclide rwlock.h directly.

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

Re: [Xen-devel] [PATCH v3 1/1] xen/time: do not decrease steal time after live migration on xen

2017-10-27 Thread Juergen Gross 
On 27/10/17 09:16, Dongli Zhang wrote:
> Hi Boris,
> 
> On 10/25/2017 11:12 PM, Boris Ostrovsky wrote:
>> On 10/25/2017 02:45 AM, Dongli Zhang wrote:
>>> After guest live migration on xen, steal time in /proc/stat
>>> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
>>> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
>>> derived from previous return value of xen_steal_clock().
>>>
>>> For instance, steal time of each vcpu is 335 before live migration.
>>>
>>> cpu  198 0 368 200064 1962 0 0 1340 0 0
>>> cpu0 38 0 81 50063 492 0 0 335 0 0
>>> cpu1 65 0 97 49763 634 0 0 335 0 0
>>> cpu2 38 0 81 50098 462 0 0 335 0 0
>>> cpu3 56 0 107 50138 374 0 0 335 0 0
>>>
>>> After live migration, steal time is reduced to 312.
>>>
>>> cpu  200 0 370 200330 1971 0 0 1248 0 0
>>> cpu0 38 0 82 50123 500 0 0 312 0 0
>>> cpu1 65 0 97 49832 634 0 0 312 0 0
>>> cpu2 39 0 82 50167 462 0 0 312 0 0
>>> cpu3 56 0 107 50207 374 0 0 312 0 0
>>>
>>> Since runstate times are cumulative and cleared during xen live migration
>>> by xen hypervisor, the idea of this patch is to accumulate runstate times
>>> to global percpu variables before live migration suspend. Once guest VM is
>>> resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
>>> runstate times and previously accumulated times stored in global percpu
>>> variables.
>>>
>>> Similar and more severe issue would impact prior linux 4.8-4.10 as
>>> discussed by Michael Las at
>>> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
>>> which would overflow steal time and lead to 100% st usage in top command
>>> for linux 4.8-4.10. A backport of this patch would fix that issue.
>>>
>>> References: 
>>> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
>>> Signed-off-by: Dongli Zhang 
>>>
>>> ---
>>> Changed since v1:
>>>   * relocate modification to xen_get_runstate_snapshot_cpu
>>>
>>> Changed since v2:
>>>   * accumulate runstate times before live migration
>>>
>>> ---
>>>  drivers/xen/manage.c  |  1 +
>>>  drivers/xen/time.c| 19 +++
>>>  include/xen/xen-ops.h |  1 +
>>>  3 files changed, 21 insertions(+)
>>>
>>> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
>>> index c425d03..9aa2955 100644
>>> --- a/drivers/xen/manage.c
>>> +++ b/drivers/xen/manage.c
>>> @@ -72,6 +72,7 @@ static int xen_suspend(void *data)
>>> }
>>>  
>>> gnttab_suspend();
>>> +   xen_accumulate_runstate_time();
>>> xen_arch_pre_suspend();
>>>  
>>> /*
>>> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
>>> index ac5f23f..6df3f82 100644
>>> --- a/drivers/xen/time.c
>>> +++ b/drivers/xen/time.c
>>> @@ -19,6 +19,8 @@
>>>  /* runstate info updated by Xen */
>>>  static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
>>>  
>>> +static DEFINE_PER_CPU(u64[4], old_runstate_time);
>>> +
>>>  /* return an consistent snapshot of 64-bit time/counter value */
>>>  static u64 get64(const u64 *p)
>>>  {
>>> @@ -52,6 +54,7 @@ static void xen_get_runstate_snapshot_cpu(struct 
>>> vcpu_runstate_info *res,
>>>  {
>>> u64 state_time;
>>> struct vcpu_runstate_info *state;
>>> +   int i;
>>>  
>>> BUG_ON(preemptible());
>>>  
>>> @@ -64,6 +67,22 @@ static void xen_get_runstate_snapshot_cpu(struct 
>>> vcpu_runstate_info *res,
>>> rmb();  /* Hypervisor might update data. */
>>> } while (get64(>state_entry_time) != state_time ||
>>>  (state_time & XEN_RUNSTATE_UPDATE));
>>> +
>>> +   for (i = 0; i < 4; i++)
>>> +   res->time[i] += per_cpu(old_runstate_time, cpu)[i];
>>> +}
>>> +
>>> +void xen_accumulate_runstate_time(void)
>>> +{
>>> +   struct vcpu_runstate_info state;
>>> +   int cpu;
>>> +
>>> +   for_each_possible_cpu(cpu) {
>>> +   xen_get_runstate_snapshot_cpu(, cpu);
>>> +   memcpy(per_cpu(old_runstate_time, cpu),
>>> +   state.time,
>>> +   4 * sizeof(u64));
>>
>> sizeof(old_runstate_time). (I think this should work for per_cpu variables)
>>
>>> +   }
>>
>> Hmm.. This may not perform as intended if we are merely checkpointing
>> (or pausing) the guest (i.e. if HYPERVISOR_suspend() returns 1). We will
>> double-account for the last interval that the guest has run.
>>
>> I'd rather not have yet another per-cpu variable but I can't think of
>> anything else. Perhaps you or others can come up with something better.
> 
> I have 3 options so far.
> 
> The 1st option is to another per-cpu variable while you do not like it.
> 
> The 2nd option is to borrow from what do_stolen_accounting() used to do. 
> Compute
> the delta of current and previous time and do nothing if delta is less than 0.
> The drawback of this option is guest might wait for the new time to catch up
> with previous time.

This could be a rather long time. I don't think this is the way to go.

> The 3rd option is to check the return

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

2017-10-27 Thread Hao, Xudong 
This bug exist much long time, there are many discussion last year but not a 
solution then. I call out it now because there is a fix in qemu upstream:
commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
Author: Roger Pau Monne 
Date:   Thu Aug 24 16:07:03 2017 +0100

xen/pt: allow QEMU to request MSI unmasking at bind time

The fix is not in qemu-xen tree yet, when will qemu-xen sync this fix? Is it 
possible to catch Xen 4.10's qemu-xen?

BTW, mail report bug is direct but not easy to track, I took much time to 
search this BUG report mail. @Lars, is there plan to introduce any bug system 
for Xen?


Thanks,
-Xudong


> -Original Message-
> From: Xu, Quan
> Sent: Wednesday, June 8, 2016 5:12 PM
> To: Jan Beulich ; Hao, Xudong 
> Cc: Wei Liu ; Zhang, PengtaoX
> ; Xen-devel 
> Subject: RE: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov
> 
> On June 07, 2016 3:50 PM, Jan Beulich  wrote:
> > >>> On 07.06.16 at 07:52,  wrote:
> > > -vf PT is not working for win2008: the logs:
> > >qemu-dm-win2k8.log -- qemu log, vf PT for win2008.
> > >xen-win2k8.log -- xen log, vf PT for win2008.
> >
> > Hmm, that's very little output. In particular neither qemu nor Xen see
> > _any_ writes to the MSI-X table (without which interrupts obviously
> > can't get enabled for that device).
> >
> > Albeit - even in the SLES case only qemu sees such writes, so I'll
> > have to check if I made a mistake with the debugging patch.
> >
> 
> Jan,  do you have any other suggestions on how could I dig into this issue?
> 
> Quan

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

[Xen-devel] Xen 4.6 Hypervisor Fails to Boot and is Hanged in "Turning on Paging"

2017-10-27 Thread Srini 




















Xen 4.6 Hypervisor Fails to Boot and is Hanged in "Turning on Paging":


EVM : TI DRA7XX OMAP5
Xen versions - 4.6
Uboot version - 2016.05
Kernel Version - 4.4
Dev Host - 14.04
Output :- Turn on Paging error

Please find the below logs:-

Welcome to minicom 2.5

OPTIONS: I18n 
Compiled on May  2 2011, 10:05:24.
Port /dev/ttyUSB0

Press CTRL-A Z for help on special keys


U-Boot SPL 2016.05-gc8a0b5ceb8 (Aug 31 2017 - 13:18:46)
DRA752-GP ES1.0
no pinctrl for hs200_1_8v
no pinctrl for ddr_1_8v
*** Warning - bad CRC, using default environment

Trying to boot from MMC1
spl: falcon_args_file not set in environment, falling back to default
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img
reading u-boot.img
reading u-boot.img


U-Boot 2016.05-gc8a0b5ceb8 (Aug 31 2017 - 13:18:46 +0530)

CPU  : DRA752-GP ES1.0
Model: TI DRA742
Board: DRA74x EVM REV D.0
DRAM:  1.5 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - bad CRC, using default environment

GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
part_get_info_efi: *** ERROR: Invalid GPT ***
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
part_get_info_efi: *** ERROR: Invalid Backup GPT ***
ERROR: cannot find partition: 'userdata'

at arch/arm/cpu/armv7/omap-common/utils.c:195/mmc_get_part_size()
Warning: fastboot.userdata_size: unable to calc
SCSI:  SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
scanning bus for devices...
Found 0 device(s).
Net:   
Warning: ethernet@48484000 using MAC address from ROM
eth0: ethernet@48484000
Hit any key to stop autoboot:  0 
=> Ok
Unknown command 'Ok' - try 'help'
=> 
Unknown command 'Ok' - try 'help'
=> 
Unknown command 'Ok' - try 'help'
=> 
Unknown command 'Ok' - try 'help'
=> 
Unknown command 'Ok' - try 'help'
=> 
Unknown command 'Ok' - try 'help'
=> setenv dtb_addr_r 0x825f
=> setenv xen_addr_r 0x9000
=> setenv kernel_addr_r 0xa000
=> setenv xen_bootargs 'sync_console console=dtuart dtuart=serial2'
=> setenv dom0_bootargs 'console=hvc0,115200n8 earlyprintk=xen debug
ignore_loglevel root=/dev/mmcblk0p2 rw rootwait fixrtc'
=> fatload mmc 0:1 $dtb_addr_r dra7-evm.dtb
reading dra7-evm.dtb
** Unable to read file dra7-evm.dtb **
=> fatload mmc 0:1 $dtb_addr_r devicetree-zImage-dra7-evm.dtb   

reading devicetree-zImage-dra7-evm.dtb
108295 bytes read in 8 ms (12.9 MiB/s)
=> fatload mmc 0:1 $xen_addr_r xen-uImage
reading xen-uImage
820176 bytes read in 22 ms (35.6 MiB/s)
=> fatload mmc 0:1 $kernel_addr_r zImage
reading zImage
3551760 bytes read in 85 ms (39.8 MiB/s)
=> fdt addr $dtb_addr_r
=> fdt resize
=> fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
=> fdt resize
=> fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\"
=> fdt mknode /chosen modules
=> fdt set /chosen/modules '#address-cells' <1>
=> fdt set /chosen/modules '#size-cells' <1>
=> fdt mknode /chosen/modules module@0
=> fdt set /chosen/modules/module@0 compatible xen,linux-zimage
xen,multiboot-module
=> fdt set /chosen/modules/module@0 reg <$kernel_addr_r 0xa0>
=> bootm $xen_addr_r - $dtb_addr_r
## Booting kernel from Legacy Image at 9000 ...
   Image Name:   XEN
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:820112 Bytes = 800.9 KiB
   Load Address: 9000
   Entry Point:  9000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 825f
   Booting using the fdt blob at 0x825f
   Loading Kernel Image ... OK
   reserving fdt memory region: addr=825f size=1b000
   Loading Device Tree to 8ffe2000, end 8fff ... OK

Starting kernel ...

- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -

 CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.5| VT102 |  Offline
  




--
Sent from: http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html

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

Re: [Xen-devel] [PATCH v3 1/1] xen/time: do not decrease steal time after live migration on xen

2017-10-27 Thread Dongli Zhang 
Hi Boris,

On 10/25/2017 11:12 PM, Boris Ostrovsky wrote:
> On 10/25/2017 02:45 AM, Dongli Zhang wrote:
>> After guest live migration on xen, steal time in /proc/stat
>> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
>> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
>> derived from previous return value of xen_steal_clock().
>>
>> For instance, steal time of each vcpu is 335 before live migration.
>>
>> cpu  198 0 368 200064 1962 0 0 1340 0 0
>> cpu0 38 0 81 50063 492 0 0 335 0 0
>> cpu1 65 0 97 49763 634 0 0 335 0 0
>> cpu2 38 0 81 50098 462 0 0 335 0 0
>> cpu3 56 0 107 50138 374 0 0 335 0 0
>>
>> After live migration, steal time is reduced to 312.
>>
>> cpu  200 0 370 200330 1971 0 0 1248 0 0
>> cpu0 38 0 82 50123 500 0 0 312 0 0
>> cpu1 65 0 97 49832 634 0 0 312 0 0
>> cpu2 39 0 82 50167 462 0 0 312 0 0
>> cpu3 56 0 107 50207 374 0 0 312 0 0
>>
>> Since runstate times are cumulative and cleared during xen live migration
>> by xen hypervisor, the idea of this patch is to accumulate runstate times
>> to global percpu variables before live migration suspend. Once guest VM is
>> resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
>> runstate times and previously accumulated times stored in global percpu
>> variables.
>>
>> Similar and more severe issue would impact prior linux 4.8-4.10 as
>> discussed by Michael Las at
>> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
>> which would overflow steal time and lead to 100% st usage in top command
>> for linux 4.8-4.10. A backport of this patch would fix that issue.
>>
>> References: 
>> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
>> Signed-off-by: Dongli Zhang 
>>
>> ---
>> Changed since v1:
>>   * relocate modification to xen_get_runstate_snapshot_cpu
>>
>> Changed since v2:
>>   * accumulate runstate times before live migration
>>
>> ---
>>  drivers/xen/manage.c  |  1 +
>>  drivers/xen/time.c| 19 +++
>>  include/xen/xen-ops.h |  1 +
>>  3 files changed, 21 insertions(+)
>>
>> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
>> index c425d03..9aa2955 100644
>> --- a/drivers/xen/manage.c
>> +++ b/drivers/xen/manage.c
>> @@ -72,6 +72,7 @@ static int xen_suspend(void *data)
>>  }
>>  
>>  gnttab_suspend();
>> +xen_accumulate_runstate_time();
>>  xen_arch_pre_suspend();
>>  
>>  /*
>> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
>> index ac5f23f..6df3f82 100644
>> --- a/drivers/xen/time.c
>> +++ b/drivers/xen/time.c
>> @@ -19,6 +19,8 @@
>>  /* runstate info updated by Xen */
>>  static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
>>  
>> +static DEFINE_PER_CPU(u64[4], old_runstate_time);
>> +
>>  /* return an consistent snapshot of 64-bit time/counter value */
>>  static u64 get64(const u64 *p)
>>  {
>> @@ -52,6 +54,7 @@ static void xen_get_runstate_snapshot_cpu(struct 
>> vcpu_runstate_info *res,
>>  {
>>  u64 state_time;
>>  struct vcpu_runstate_info *state;
>> +int i;
>>  
>>  BUG_ON(preemptible());
>>  
>> @@ -64,6 +67,22 @@ static void xen_get_runstate_snapshot_cpu(struct 
>> vcpu_runstate_info *res,
>>  rmb();  /* Hypervisor might update data. */
>>  } while (get64(>state_entry_time) != state_time ||
>>   (state_time & XEN_RUNSTATE_UPDATE));
>> +
>> +for (i = 0; i < 4; i++)
>> +res->time[i] += per_cpu(old_runstate_time, cpu)[i];
>> +}
>> +
>> +void xen_accumulate_runstate_time(void)
>> +{
>> +struct vcpu_runstate_info state;
>> +int cpu;
>> +
>> +for_each_possible_cpu(cpu) {
>> +xen_get_runstate_snapshot_cpu(, cpu);
>> +memcpy(per_cpu(old_runstate_time, cpu),
>> +state.time,
>> +4 * sizeof(u64));
> 
> sizeof(old_runstate_time). (I think this should work for per_cpu variables)
> 
>> +}
> 
> Hmm.. This may not perform as intended if we are merely checkpointing
> (or pausing) the guest (i.e. if HYPERVISOR_suspend() returns 1). We will
> double-account for the last interval that the guest has run.
> 
> I'd rather not have yet another per-cpu variable but I can't think of
> anything else. Perhaps you or others can come up with something better.

I have 3 options so far.

The 1st option is to another per-cpu variable while you do not like it.

The 2nd option is to borrow from what do_stolen_accounting() used to do. Compute
the delta of current and previous time and do nothing if delta is less than 0.
The drawback of this option is guest might wait for the new time to catch up
with previous time.

The 3rd option is to check the return value of HYPERVISOR_suspend() to different
if this is a migration of checkpointing. As we will double-account the runstate
time for checkpointing, why not just divide it by 2? The drawback of this option
is the result is not

Re: [Xen-devel] Some Xen pci-passthrough questions

2017-10-27 Thread Jan Beulich 
>>> On 26.10.17 at 22:48,  wrote:
> - While adding some extra logging and enabling the logging on xen pt in 
> qemu,
>   i wonder if it wouldn't be beneficial to have at least some basic logging 
> permanently enabled ? 

For this end everything further down you would better have added
the qemu maintainers. I've now put them on Cc.

Jan

> - Enabling the xen pt logging in qemu spit out some things, i wonder if they 
> are normal:
> 
> qemu-system-i386: -serial pty: char device redirected to /dev/pts/16 
> (label serial0)
> [00:05.0] xen_pt_realize: Assigning real physical device 08:00.0 to 
> devfn 0x28
> [00:05.0] xen_pt_register_regions: IO region 0 registered 
> (size=0x2000 base_addr=0xfe1fe000 type: 0x4)
> 
> Are these somehow expected / benign (they also occur when pci 
> passthrough is succesful) ?:
> [00:05.0] xen_pt_config_reg_init: Offset 0x000e mismatch! 
> Emulated=0x0080, host=0x, syncing to 0x0080.
> [00:05.0] xen_pt_config_reg_init: Offset 0x0010 mismatch! 
> Emulated=0x, host=0xfe1fe004, syncing to 0xfe1fe004.
> [00:05.0] xen_pt_config_reg_init: Offset 0x0052 mismatch! 
> Emulated=0x, host=0x4803, syncing to 0x0003.
> [00:05.0] xen_pt_config_reg_init: Offset 0x0072 mismatch! 
> Emulated=0x, host=0x0086, syncing to 0x0080.
> [00:05.0] xen_pt_config_reg_init: Offset 0x00a4 mismatch! 
> Emulated=0x, host=0x8fc0, syncing to 0x8fc0.
> [00:05.0] xen_pt_config_reg_init: Offset 0x00b2 mismatch! 
> Emulated=0x, host=0x1012, syncing to 0x1012.
> 
> [00:05.0] xen_pt_msix_init: get MSI-X table BAR base 0xfe1fe000
> [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8
> [00:05.0] xen_pt_msix_init: table_off = 0x1000, total_entries = 8, 
> PCI_MSIX_ENTRY_SIZE = 0x10,  msix->table_offset_adjust = 0,  msix->table_base 
> = 
> 0xfe1fe000
> [00:05.0] xen_pt_msix_init: Error: Can't map physical MSI-X table: 
> Invalid argument
> [00:05.0] xen_pt_msix_size_init: Error: Internal error: Invalid 
> xen_pt_msix_init.
> Failed to initialize 12/15, type = 0x1, rc: -22
> [00:05.0] xen_pt_msi_set_enable: disabling MSI.
> 
> This crash seems to indicate the above disabling of MSI isn't handled 
> well enough to prevent this from happening: 
> *** Error in `/usr/local/lib/xen/bin/qemu-system-i386': corrupted 
> size vs. prev_size: 0x55ce13565570 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f700ab7ebcb]
> /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f700ab84f96]
> 
> 
> --
> Sander
> 
> ___
> 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] ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

2017-10-27 Thread Jan Beulich 
>>> On 26.10.17 at 21:29,  wrote:
> On 26/10/17 19:49, Craig Bergstrom wrote:
>> Sander, thanks for the details, they've been very useful.
>> 
>> I suspect that your host system's mem=2048M parameter is causing the
>> problem.  Any chance you can confirm by removing the parameter and
>> running the guest code path?
> 
> I removed it, but kept the hypervisor limiting dom0 memory to 2046M intact 
> (in grub using the xen bootcmd: 
> "multiboot   /xen-4.10.gz  dom0_mem=2048M,max:2048M ."
> 
> Unfortunately that doesn't change anything, the guest still fails to start 
> with the same errors.
> 
>> More specifically, since you're telling the kernel that it's high
>> memory address is at 2048M and your device is at 0xfe1fe000 (~4G), the
>> new mmap() limits are preventing you from mapping addresses that are
>> explicitly disallowed by the parameter.
>> 
> 
> Which would probably mean the current patch prohibits hard limiting the dom0 
> memory to a certain value (below 4G)
> at least in combination with PCI-passthrough. So the only thing left would 
> be to have no hard memory restriction on dom0
> and rely on auto-ballooning, but I'm not a great fan of that.

Plus - how would things work with any RAM size if the PCI BAR was
a 64-bit one, pointing somewhere high up beyond 4Gb?

Jan


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

Re: [Xen-devel] [PATCH 5/5 v2] xenconsole: Define and use a macro XEN_INVALID_PFN instead of -1

2017-10-27 Thread Bhupinder Thakur 
On 27 October 2017 at 12:34, Bhupinder Thakur
 wrote:
> Hi Wei,
>
> On 26 October 2017 at 16:56, Wei Liu  wrote:
>> On Wed, Oct 25, 2017 at 02:57:08PM +0530, Bhupinder Thakur wrote:
>>> xenconsole will use a new macro XEN_INVALID_PFN instead of -1 for 
>>> initializing ring-ref.
>>
>> Can you please paste in the error if the compilation fails with -1?
>>
>> The way this series is arranged make me wonder if the compilation is
>> broken half way. We should avoid that.
> It is not breaking the compilation. Since the type of ring_ref is
> changed to xen_pfn_t (which is an unsigned value) assigning -1
> appeared to be confusing. For better clarity, XEN_INVALID_PFN is
> introduced.

I will update the commit message accordingly.

Regards,
Bhupinder

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

Re: [Xen-devel] [PATCH 5/5 v2] xenconsole: Define and use a macro XEN_INVALID_PFN instead of -1

2017-10-27 Thread Bhupinder Thakur 
Hi Wei,

On 26 October 2017 at 16:56, Wei Liu  wrote:
> On Wed, Oct 25, 2017 at 02:57:08PM +0530, Bhupinder Thakur wrote:
>> xenconsole will use a new macro XEN_INVALID_PFN instead of -1 for 
>> initializing ring-ref.
>
> Can you please paste in the error if the compilation fails with -1?
>
> The way this series is arranged make me wonder if the compilation is
> broken half way. We should avoid that.
It is not breaking the compilation. Since the type of ring_ref is
changed to xen_pfn_t (which is an unsigned value) assigning -1
appeared to be confusing. For better clarity, XEN_INVALID_PFN is
introduced.

Regards,
Bhupinder

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

Re: [Xen-devel] [RFC XEN PATCH v3 01/39] x86_64/mm: fix the PDX group check in mem_hotadd_check()

2017-10-27 Thread Haozhong Zhang 
On 10/27/17 14:49 +0800, Chao Peng wrote:
> On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote:
> > The current check refuses the hot-plugged memory that falls in one
> > unused PDX group, which should be allowed.
> 
> Looks reasonable to me. The only thing I can think of is you can double
> check if the following find_next_zero_bit/find_next_bit will still
> work. 

The first check in mem_hotadd_check() ensures spfn < epfn, so sidx <=
eidx here. Compared with the previous code, the only added case is
sidx == eidx, which is what this patch intends to allow and tested.

Haozhong

> 
> Chao
> > 
> > Signed-off-by: Haozhong Zhang 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> >  xen/arch/x86/x86_64/mm.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> > 
> > diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> > index 11746730b4..6c5221f90c 100644
> > --- a/xen/arch/x86/x86_64/mm.c
> > +++ b/xen/arch/x86/x86_64/mm.c
> > @@ -1296,12 +1296,8 @@ static int mem_hotadd_check(unsigned long spfn,
> > unsigned long epfn)
> >  return 0;
> >  
> >  /* Make sure the new range is not present now */
> > -sidx = ((pfn_to_pdx(spfn) + PDX_GROUP_COUNT - 1)  &
> > ~(PDX_GROUP_COUNT - 1))
> > -/ PDX_GROUP_COUNT;
> > +sidx = (pfn_to_pdx(spfn) & ~(PDX_GROUP_COUNT - 1)) /
> > PDX_GROUP_COUNT;
> >  eidx = (pfn_to_pdx(epfn - 1) & ~(PDX_GROUP_COUNT - 1)) /
> > PDX_GROUP_COUNT;
> > -if (sidx >= eidx)
> > -return 0;
> > -
> >  s = find_next_zero_bit(pdx_group_valid, eidx, sidx);
> >  if ( s > eidx )
> >  return 0;

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

Re: [Xen-devel] [RFC XEN PATCH v3 02/39] x86_64/mm: drop redundant MFN to page conventions in cleanup_frame_table()

2017-10-27 Thread Chao Peng 
On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote:
> Replace pdx_to_page(pfn_to_pdx(pfn)) by mfn_to_page(pfn), which is
> identical to the former.

Looks good to me.

Chao
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/x86_64/mm.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index 6c5221f90c..c93383d7d9 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -720,12 +720,11 @@ static void cleanup_frame_table(struct
> mem_hotadd_info *info)
>  spfn = info->spfn;
>  epfn = info->epfn;
>  
> -sva = (unsigned long)pdx_to_page(pfn_to_pdx(spfn));
> -eva = (unsigned long)pdx_to_page(pfn_to_pdx(epfn));
> +sva = (unsigned long)mfn_to_page(spfn);
> +eva = (unsigned long)mfn_to_page(epfn);
>  
>  /* Intialize all page */
> -memset(mfn_to_page(spfn), -1,
> -   (unsigned long)mfn_to_page(epfn) - (unsigned
> long)mfn_to_page(spfn));
> +memset((void *)sva, -1, eva - sva);
>  
>  while (sva < eva)
>  {

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

Re: [Xen-devel] [RFC XEN PATCH v3 01/39] x86_64/mm: fix the PDX group check in mem_hotadd_check()

2017-10-27 Thread Chao Peng 
On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote:
> The current check refuses the hot-plugged memory that falls in one
> unused PDX group, which should be allowed.

Looks reasonable to me. The only thing I can think of is you can double
check if the following find_next_zero_bit/find_next_bit will still
work. 

Chao
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/x86_64/mm.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index 11746730b4..6c5221f90c 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -1296,12 +1296,8 @@ static int mem_hotadd_check(unsigned long spfn,
> unsigned long epfn)
>  return 0;
>  
>  /* Make sure the new range is not present now */
> -sidx = ((pfn_to_pdx(spfn) + PDX_GROUP_COUNT - 1)  &
> ~(PDX_GROUP_COUNT - 1))
> -/ PDX_GROUP_COUNT;
> +sidx = (pfn_to_pdx(spfn) & ~(PDX_GROUP_COUNT - 1)) /
> PDX_GROUP_COUNT;
>  eidx = (pfn_to_pdx(epfn - 1) & ~(PDX_GROUP_COUNT - 1)) /
> PDX_GROUP_COUNT;
> -if (sidx >= eidx)
> -return 0;
> -
>  s = find_next_zero_bit(pdx_group_valid, eidx, sidx);
>  if ( s > eidx )
>  return 0;

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

Re: [Xen-devel] [PATCH v2 1/2] x86/boot: fix early error display

2017-10-27 Thread Jan Beulich 
>>> On 26.10.17 at 23:05,  wrote:
> On 10/18/17 4:50 AM, Jan Beulich wrote:
> On 17.10.17 at 23:41,  wrote:
>>> From: David Esler 
>>>
>>> In 9180f5365524 a change was made to the send_chr function to take in
>>> C-strings and print out a character at a time until a NULL was
>>> encountered. However there is no code to increment the current character
>>> position resulting in an endless loop of the first character. This adds
>>> a simple increment.
>> 
>> This description is not accurate (it should have changed together with
>> the change to how you fix the issue) - with VGA the increment does
>> happen. Hence "display" in the title is perhaps also at least misleading.
>> I would be fine to adjust both while committing (and then adding my
>> R-b), but feel free to propose an alternative.
> 
> Jan,
> 
> Can you queue this for 4.9 as well? That's where we ran into the issue
> in the first place.

That how I did understand it, so I've queued this already, but for
it to become eligible to applying to 4.9 it first needs to pass the
push gate on master.

Jan


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