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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d93a10c02bd963cc11670a9e02ce396764838768
baseline version:
 ovmf 245cda6641ade1f1013c2d5c9c838f2706636828

Last test of basis   101486  2016-10-17 05:43:22 Z0 days
Testing same since   101498  2016-10-18 01:44:51 Z0 days1 attempts


People who touched revisions under test:
  Jeff Fan 

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



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

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

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

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


Pushing revision :

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm   6 xen-boot fail REGR. vs. 101443
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 101443
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 101443
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
101443
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 101443
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101443

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101443
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101443
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101443

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

version targeted for testing:
 qemuu0975b8b823a888d474fa33821dfe84e6904db197
baseline version:
 qemuu6aa5a3679449cdf0b6fe5a6829b22e642ded57fd

Last test of basis   101443  2016-10-14 11:22:23 Z3 days
Failing since101490  2016-10-17 11:14:12 Z0 days2 attempts
Testing same since   101494  2016-10-17 18:16:45 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Ashijeet Acharya 
  Benjamin Herrenschmidt 
  Cao jin 
  Cédric Le Goater 
  David Gibson 
  Dr. David Alan Gilbert 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  Juan Quintela 
  Laurent Vivier 
  Li Qiang 
  Michael Roth 
  Nikunj A Dadhania 
  Peter Maydell 
  Thomas Huth 

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

[Xen-devel] [PATCH 2/3] libxl: attach PCI device to qemu only after setting pciback/pcifront

[Marek Marczykowski-Górecki]

When qemu is running in stubdomain, handling "pci-ins" command will fail
if pcifront is not initialized already. Fix this by sending such command
only after confirming that pciback/front is running.

It is possible to handle this case in mini-os code, by delaying
"pci-ins" handling until pcifront_thread finishes devices discovery. But
the same problem most likely will apply to any other stubdomain
implementations when they come (Rumprun, Linux) - so better handle this
at libxl level.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl_pci.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 2ae1bc4..3805d30 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1195,6 +1195,7 @@ int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, 
libxl_device_pci *pcide
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
 unsigned int orig_vdev, pfunc_mask;
+char *be_path;
 libxl_device_pci *assigned;
 int num_assigned, i, rc;
 int stubdomid = 0;
@@ -1249,6 +1250,14 @@ int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, 
libxl_device_pci *pcide
 rc = do_pci_add(gc, stubdomid, _s, 0);
 if ( rc )
 goto out;
+/* wait for the device actually being connected, otherwise device model
+ * running there will fail to find the device */
+be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0",
+libxl__xs_get_dompath(gc, 0), stubdomid);
+rc = libxl__wait_for_backend(gc, be_path,
+GCSPRINTF("%d", XenbusStateConnected));
+if ( rc )
+goto out;
 }
 
 orig_vdev = pcidev->vdevfn & ~7U;
-- 
2.5.5


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

[Xen-devel] [PATCH 0/3] Fix PCI passthrough for HVM with stubdomain

[Marek Marczykowski-Górecki]

This series is follow up to previous attempts to fix this. Related threads:
 - http://markmail.org/thread/dwjcdfk3y7s5c5kl "PCI passthrough with stubdomain"
 - http://xen.markmail.org/thread/l7tvqcxbiyc2grvr "Json config and stubdomain"

With those patches applied, HVM finally have PCI devices working. Tested on
Linux 4.4.14 and Window 7 pro guests (both 64bit).


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

[Xen-devel] [PATCH 1/3] libxl: attach xen-pciback only to PV domains

[Marek Marczykowski-Górecki]

HVM domains use IOMMU and device model assistance for communicating with
PCI devices, xen-pcifront/pciback is used only in PV domains.
When HVM domain has device model in stubdomain, attaching xen-pciback to
the target domain itself is not only useless, but also may prevent
attaching xen-pciback to the stubdomain, effectively breaking PCI
passthrough.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl_pci.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 6f8f49c..2ae1bc4 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -,7 +,7 @@ out:
 }
 }
 
-if (!starting)
+if (!starting && !hvm)
 rc = libxl__device_pci_add_xenstore(gc, domid, pcidev, starting);
 else
 rc = 0;
@@ -1306,7 +1306,8 @@ static void libxl__add_pcidevs(libxl__egc *egc, libxl__ao 
*ao, uint32_t domid,
 }
 }
 
-if (d_config->num_pcidevs > 0) {
+if (d_config->num_pcidevs > 0
+&& d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV) {
 rc = libxl__create_pci_backend(gc, domid, d_config->pcidevs,
 d_config->num_pcidevs);
 if (rc < 0) {
-- 
2.5.5


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

[Xen-devel] [PATCH 3/3] libxl: don't try to manipulate json config for stubdomain

[Marek Marczykowski-Górecki]

Stubdomain do not have it's own config file - its configuration is
derived from target domains. Do not try to manipulate it when attaching
PCI device.

This bug prevented starting HVM with stubdomain and PCI passthrough
device attached.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl_pci.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 3805d30..5ad70c5 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -151,14 +151,18 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, 
uint32_t domid, libxl_d
 GCNEW(device);
 libxl__device_from_pcidev(gc, domid, pcidev, device);
 
-lock = libxl__lock_domain_userdata(gc, domid);
-if (!lock) {
-rc = ERROR_LOCK_FAIL;
-goto out;
-}
+/* Stubdomain config is derived from its target domain, it doesn't have
+   its own file */
+if (!libxl_is_stubdom(CTX, domid, NULL)) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
 
-rc = libxl__get_domain_configuration(gc, domid, _config);
-if (rc) goto out;
+rc = libxl__get_domain_configuration(gc, domid, _config);
+if (rc) goto out;
+}
 
 DEVICE_ADD(pci, pcidevs, domid, _saved, COMPARE_PCI, _config);
 
@@ -169,8 +173,10 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, 
uint32_t domid, libxl_d
 rc = libxl__xs_transaction_start(gc, );
 if (rc) goto out;
 
-rc = libxl__set_domain_configuration(gc, domid, _config);
-if (rc) goto out;
+if (lock) {
+rc = libxl__set_domain_configuration(gc, domid, _config);
+if (rc) goto out;
+}
 
 libxl__xs_writev(gc, t, be_path, libxl__xs_kvs_of_flexarray(gc, back));
 
-- 
2.5.5


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101493
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 
101493
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 101398 pass in 
101493
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101493
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101493
 test-armhf-armhf-xl-multivcpu  9 debian-install  fail in 101470 pass in 101493
 test-armhf-armhf-xl-credit2   6 xen-boot fail in 101487 pass in 101493
 test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail in 101487 pass 
in 101493
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 101398
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101398
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 101434
 test-amd64-i386-xl6 xen-boot   fail pass in 101470
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot   fail pass in 101487
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail pass in 101487
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail pass in 101487
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check  fail pass in 101487
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check  fail pass in 101487
 test-armhf-armhf-libvirt 13 saverestore-support-check  fail pass in 101487

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101398 never pass
 test-amd64-i386-libvirt-xsm 12 migrate-support-check fail in 101434 never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestore  fail in 101487 never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail in 101487 never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail in 101487 never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail in 101487 never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never 

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101484
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101484
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101484
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101484
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101484

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  05e379bd279768495cdc516f17a120e30dfbcca5
baseline version:
 xen  20295ab63ce7f57edca9c450602ac2dace1fc721

Last test of basis   101484  2016-10-17 01:58:09 Z0 days
Testing same since   101491  2016-10-17 13:43:51 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 

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

Re: [Xen-devel] [PATCH for-4.8 1/3] libacpi: fix arm64 build

[Stefano Stabellini]

On Mon, 17 Oct 2016, Wei Liu wrote:
> On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote:
> > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote:
> > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> > > > The arm64 build for libacpi was broken due to two reasons:
> > > > 
> > > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
> > > > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
> > > >made CONFIG_ARM disappear.
> > > > 
> > > > Fix those by:
> > > > 
> > > > 1. Correctly generate full path for dsdt_anaycpu_arm.c.
> > > > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
> > > >on settings in firmware/Rules.mk.
> > > > 
> > > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
> > > > accurate.
> > > > 
> > > > Reported-by: Julien Grall 
> > > > Signed-off-by: Wei Liu 
> > > > ---
> > > > Cc: Julien Grall 
> > > > Cc: Wei Chen 
> > > > Cc: Steve Capper 
> > > > Cc: Jan Beulich 
> > > > Cc: Boris Ostrovsky 
> > > > Cc: Shannon Zhao 
> > > > Cc: Stefano Stebellini 
> > > > 
> > > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
> > > > on arm64.
> > > > 
> > > > Would appreciate any build test report from ARM people.
> > > 
> > > I set up a chroot environment this morning and built arm64 Xen. It
> > > worked.
> > > 
> > > Since Jan and Julien are both away, I've taken the liberty of applying
> > > this patch with both my RM hat and tools maintainer hat on.
> > > 
> > > I have also applied patch #3 since it is rather trivial.
> > > 
> > > I will let Jan decide whether patch #2 is necessary.
> > > 
> > 
> > Thanks Wei,
> > I am trying to verify this patch, but I think I am running into another
> > issue with the libxl acpi support patches.
> > 
> > Essentially I'm getting namespace clashes with the following:
> >  * nonnull
> >  * noreturn
> >  * register_t
> > 
> > I think this is due to the following logic in the libxl/Makefile:
> > libxl_arm_acpi.o: libxl_arm_acpi.c
> > $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> > 
> > When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull
> > in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which
> > then eventually pulls in xen/include/xen/compiler.h which redefines key
> > information.
> > 
> > Which rootfs are you chrooting into for the testing?
> > (I've experienced build issues on Debian Jessie and Ubuntu Xenial running
> > in a Docker container).
> > 
> 
> qemu-debootstrap, sid, arm64.
> 
> I saw similar errors. But they went away after I `git clean -fffxx`
> the tree.
> 
> The fact that they went away somehow and Julien succeeded in building on
> variant of this patch made me think it was due to some issues in my
> environment.
> 
> > Cheers,
> > -- 
> > Steve
> > 
> > I build Xen via:
> > $ git clean -f -d -x
> > $ ./configure --with-xenstored=xenstored 
> > --with-system-qemu=/usr/local/bin/qemu-system-aarch64
> > $ make
> > 
> > My builds finish like this:
> > 
> > gcc -c -O1 -fno-omit-frame-pointer  -DBUILD_ID -g -fno-strict-aliasing 
> > -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement 
> > -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O0 -g3 
> > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF 
> > .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
> > -fno-optimize-sibling-calls  -Werror -Wno-format-zero-length 
> > -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral 
> > -I. -fPIC -pthread 
> > -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include 
> > -I/home/steven/xen/tools/libxl/../../tools/include 
> > -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include 
> > -I/home/steven/xen/tools/libxl/../../tools/include 
> > -I/home/steven/xen/tools/libxl/../../tools/libxc/include 
> > -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include 
> > -I/home/steven/xen/tools/libxl/../../tools/include 
> > -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include 
> > -I/home/steven/xen/tool
 s/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include 
-D__XEN_TOOLS__ -I/home/steven/xen/tools/libxl/../../tools/libxc/include 
-I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/xenstore/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/blktap2/control 

[Xen-devel] [BUG] XEN-4.8-rc2 sched-rtds does not accept settings

[Juergen Schinker]

Hey Meng XU 


xl -vf sched-rtds -v all -d 0 -p 2 -b 8000

whatever I set - the changes are not accepted and stay like you see further down

and the system feels very lame

Cpupool Pool-0: sched=RTDS
NameIDPeriodBudget
Domain-0 0 1  4000
zimbra   1 1  4000
ethereum-os  2 1  4000
mirot3 1  4000
wily 4 1  4000
 
host   : xen
release: 4.7.0-1-amd64
version: #1 SMP Debian 4.7.6-1 (2016-10-07)
machine: x86_64
nr_cpus: 4
max_cpu_id : 3
nr_nodes   : 1
cores_per_socket   : 2
threads_per_core   : 2
cpu_mhz: 2312
hw_caps: 
b7ebfbff:77bae3ff:28100800:0001:0001:0281::0100
virt_caps  : hvm hvm_directio
total_memory   : 32711
free_memory: 0
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 8
xen_extra  : .0-rc
xen_version: 4.8.0-rc
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler  : rtds
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Mon Oct 10 11:10:56 2016 -0700 git:68dc718
xen_commandline: placeholder sched=rtds iommu=1
cc_compiler: gcc (Debian 6.2.0-6) 6.2.0 20161010
cc_compile_by  : root
cc_compile_domain  : 
cc_compile_date: Sun Oct 16 23:56:56 BST 2016
build_id   : 847a9dd70ab5f581818fa9cc09ed609ce2b420d1
xend_config_format : 4

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

[Xen-devel] Debugging environment Update

[Tevin Mallory]

Hi Jesus,
How are you today? I hope you are doing well. Since running perceval on
windows was giving me to much trouble, I decided to change my OS to Ubuntu
and haven't had any troubles with it. I am currently working on getting the
data from the Xen git repo and should be finishing that up soon. Honestly
looking back I should have switched to Ubuntu sooner and saved us both some
time. If I run into any other issues I'll keep you posted, so far I am
doing pretty well.

Have a great day!
Tevin K. Mallory
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
faulting state in vmx_do_cpuid and hvmemul_cpuid. A new function,
hvm_check_cpuid_fault will check if cpuid faulting is enabled and the CPL > 0.
When it returns true, the cpuid handling functions will inject a GP(0). Notably
no hardware support for faulting on cpuid is necessary to emulate support with
an HVM guest.

On PV guests, hardware support is required so that userspace cpuid will trap
to Xen. Xen already enables cpuid faulting on supported CPUs for pv guests (that
aren't the control domain, see the comment in intel_ctxt_switch_levelling).
Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
do_general_protection). Once there we simply decline to emulate cpuid if the
CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
handle.

Signed-off-by: Kyle Huey 
---
 xen/arch/x86/hvm/emulate.c| 19 +++
 xen/arch/x86/hvm/hvm.c| 14 ++
 xen/arch/x86/hvm/vmx/vmx.c| 20 ++--
 xen/arch/x86/traps.c  | 34 ++
 xen/include/asm-x86/domain.h  |  3 +++
 xen/include/asm-x86/hvm/hvm.h |  1 +
 6 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 6ed7486..a713ff3 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1544,16 +1544,35 @@ static int hvmemul_wbinvd(
 
 static int hvmemul_cpuid(
 unsigned int *eax,
 unsigned int *ebx,
 unsigned int *ecx,
 unsigned int *edx,
 struct x86_emulate_ctxt *ctxt)
 {
+/*
+ * x86_emulate uses this function to query CPU features for its own 
internal
+ * use. Make sure we're actually emulating CPUID before emulating CPUID
+ * faulting.
+ */
+if ( ctxt->opcode == X86EMUL_OPC(0x0f, 0xa2) &&
+ hvm_check_cpuid_fault(current) ) {
+struct hvm_emulate_ctxt *hvmemul_ctxt =
+container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
+
+hvmemul_ctxt->exn_pending = 1;
+hvmemul_ctxt->trap.vector = TRAP_gp_fault;
+hvmemul_ctxt->trap.type = X86_EVENTTYPE_HW_EXCEPTION;
+hvmemul_ctxt->trap.error_code = 0;
+hvmemul_ctxt->trap.insn_len = 0;
+
+return X86EMUL_EXCEPTION;
+}
+
 hvm_funcs.cpuid_intercept(eax, ebx, ecx, edx);
 return X86EMUL_OKAY;
 }
 
 static int hvmemul_inject_hw_exception(
 uint8_t vector,
 int32_t error_code,
 struct x86_emulate_ctxt *ctxt)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 3c90ecd..cf81e64 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3675,16 +3675,30 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 hvm_cpuid(0x8001, NULL, NULL, NULL, &_edx);
 *eax |= (_edx & cpufeat_mask(X86_FEATURE_LM) ? vaddr_bits : 32) << 8;
 
 *ebx &= hvm_featureset[FEATURESET_e8b];
 break;
 }
 }
 
+bool hvm_check_cpuid_fault(struct vcpu *v)
+{
+struct segment_register sreg;
+
+if ( !v->arch.cpuid_fault )
+return false;
+
+hvm_get_segment_register(v, x86_seg_ss, );
+if ( sreg.attr.fields.dpl == 0 )
+return false;
+
+return true;
+}
+
 static uint64_t _hvm_rdtsc_intercept(void)
 {
 struct vcpu *curr = current;
 #if !defined(NDEBUG) || defined(CONFIG_PERF_COUNTERS)
 struct domain *currd = curr->domain;
 
 if ( currd->arch.vtsc )
 switch ( hvm_guest_x86_mode(curr) )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b9102ce..228c1b9 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2428,16 +2428,21 @@ static void vmx_cpuid_intercept(
 HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
 static int vmx_do_cpuid(struct cpu_user_regs *regs)
 {
 unsigned int eax, ebx, ecx, edx;
 unsigned int leaf, subleaf;
 
+if ( hvm_check_cpuid_fault(current) ) {
+hvm_inject_hw_exception(TRAP_gp_fault, 0);
+return 1;  /* Don't advance the guest IP! */
+}
+
 eax = regs->eax;
 ebx = regs->ebx;
 ecx = regs->ecx;
 edx = regs->edx;
 
 leaf = regs->eax;
 subleaf = regs->ecx;
 
@@ -2694,19 +2699,23 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
 case MSR_IA32_PEBS_ENABLE:
 case MSR_IA32_DS_AREA:
 if ( vpmu_do_rdmsr(msr, msr_content) )
 goto gp_fault;
 break;
 
 case MSR_INTEL_PLATFORM_INFO:
-if ( rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *msr_content) )
-goto gp_fault;
+*msr_content = MSR_PLATFORM_INFO_CPUID_FAULTING;
+break;
+
+case MSR_INTEL_MISC_FEATURES_ENABLES:
 *msr_content = 0;
+if ( current->arch.cpuid_fault )
+*msr_content |= MSR_MISC_FEATURES_CPUID_FAULTING;
 break;
 
 

[Xen-devel] [PATCH v4] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by providing constant results. Patches for support in the Linux kernel are in
flight, and we'd like to be able to use this feature on virtualized Linux
instances as well.

Changes since v3:
Patch 1:
- Added Reviewed-by lines.

Patch 2:
- Check cpuid_fault before getting the segment register to avoid unnecessary
  work.
- Move cpuid_fault checking logic for hvm domains into a new function
  hvm_check_cpuid_fault.
- Emulating cpuid faulting in the hvmemul code, being careful to emulate
  cpuid faulting only if we're actually emulating cpuid.


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

[Xen-devel] [PATCH v4 1/2] x86/Intel: Expose cpuid_faulting_enabled so it can be used elsewhere

[Kyle Huey]

While we're here, use bool instead of bool_t.

Signed-off-by: Kyle Huey 
Reviewed-by: Andrew Cooper 
Reviewed-by: Wei Liu 
---
 xen/arch/x86/cpu/intel.c| 9 +
 xen/include/asm-x86/cpuid.h | 3 +++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 7b60aaa..2e11662 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -13,34 +13,35 @@
 #include 
 #include 
 #include 
 
 #include "cpu.h"
 
 #define select_idle_routine(x) ((void)0)
 
-static bool_t __init probe_intel_cpuid_faulting(void)
+static bool __init probe_intel_cpuid_faulting(void)
 {
uint64_t x;
 
if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, x) ||
!(x & MSR_PLATFORM_INFO_CPUID_FAULTING))
return 0;
 
expected_levelling_cap |= LCAP_faulting;
levelling_caps |=  LCAP_faulting;
__set_bit(X86_FEATURE_CPUID_FAULTING, boot_cpu_data.x86_capability);
return 1;
 }
 
-static void set_cpuid_faulting(bool_t enable)
+DEFINE_PER_CPU(bool, cpuid_faulting_enabled);
+
+static void set_cpuid_faulting(bool enable)
 {
-   static DEFINE_PER_CPU(bool_t, cpuid_faulting_enabled);
-   bool_t *this_enabled = _cpu(cpuid_faulting_enabled);
+   bool *this_enabled = _cpu(cpuid_faulting_enabled);
uint32_t hi, lo;
 
ASSERT(cpu_has_cpuid_faulting);
 
if (*this_enabled == enable)
return;
 
rdmsr(MSR_INTEL_MISC_FEATURES_ENABLES, lo, hi);
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 8e3f639..2372474 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -59,16 +59,19 @@ struct cpuidmasks
 };
 
 /* Per CPU shadows of masking MSR values, for lazy context switching. */
 DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks);
 
 /* Default masking MSR values, calculated at boot. */
 extern struct cpuidmasks cpuidmask_defaults;
 
+/* Whether or not cpuid faulting is available for the current domain. */
+DECLARE_PER_CPU(bool, cpuid_faulting_enabled);
+
 #endif /* __ASSEMBLY__ */
 #endif /* !__X86_CPUID_H__ */
 
 /*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
  * c-basic-offset: 4

base-commit: 20295ab63ce7f57edca9c450602ac2dace1fc721
-- 
2.10.1


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

Re: [Xen-devel] New ipxe tarball

[Boris Ostrovsky]

On 10/17/2016 11:35 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: New ipxe tarball"):
>> But (as you said below) we should be able to fetch the file that the
>> Makefile references. (I didn't realize it was never put up there because
>> presumably git clone worked until the DNS hiccup here).
> I've arranged for an apparently-correct file to be in the right place,
> and it seems to WTFM.  (I checked the file's contents corresponded to
> the git commit in Config.mk but have not verified the provenance of
> that git commit hash.)
>
> Ian.


Thanks. I did a sample build and run and it looks good for me too (I
verified that I pulled the tarball)


-boris

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

[Xen-devel] [qemu-mainline test] 101490: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  3 host-install(3)  broken REGR. vs. 101443
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 101443
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 101443
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101443

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  3 host-install(3)broken REGR. vs. 101443
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101443
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101443
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101443

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

version targeted for testing:
 qemuu4378caf59edf6df796b9ad3174e5703fd25a781c
baseline version:
 qemuu6aa5a3679449cdf0b6fe5a6829b22e642ded57fd

Last test of basis   101443  2016-10-14 11:22:23 Z3 days
Testing same since   101490  2016-10-17 11:14:12 Z0 days1 attempts


People who touched revisions under test:
  Ashijeet Acharya 
  Cao jin 
  Dr. David Alan Gilbert 
  Eric Blake 
  Juan Quintela 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

On Mon, Oct 17, 2016 at 9:39 AM, Andrew Cooper
 wrote:
> On 17/10/16 17:28, Kyle Huey wrote:
>> On Mon, Oct 17, 2016 at 5:34 AM, Andrew Cooper
>>  wrote:
>>> On 14/10/16 20:36, Kyle Huey wrote:
 On Fri, Oct 14, 2016 at 10:18 AM, Andrew Cooper
  wrote:
> On a slightly separate note, as you have just been a successful
> guinea-pig for XTF, how did you find it?  It is a very new (still
> somewhat in development) system but the project is looking to try and
> improve regression testing in this way, especially for new features.  I
> welcome any feedback.
>>> FWIW, I have just done some library improvements and rebased the test.
>>>
 It's pretty slick.  Much better than what Linux has ;)

 I do think it's a bit confusing that xtf_has_fep is false on PV guests.
>>> Now you point it out, I can see how it would be confusing.  This is due
>>> to the history of FEP.
>>>
>>> The sequence `ud2; .ascii 'xen'; cpuid` has been around ages (it
>>> predates faulting and hardware with mask/override MSRs), and is used by
>>> PV guests to specifically request Xen's CPUID information, rather than
>>> getting the real hardware information.
>>>
>>> There is also an rdtscp variant for PV guests, used for virtual TSC modes.
>>>
>>> In Xen 4.5, I introduced the same prefix to HVM guests, but for
>>> arbitrary instructions.  This was for the express purpose of testing the
>>> x86 instruction emulator.
>>>
>>> As a result, CPUID in PV guests is the odd case out.
>>>
 It might also be nice to (at least optionally) have xtf_assert(cond,
 message) so instead of

 if ( cond )
 xtf_failure(message);

 you can write

 xtf_assert(!cond, message);

 A bonus of doing this is that the framework could actually count how
 many checks were run.  So for the HVM tests (which don't run the FEP
 bits) instead of getting "Test result: SKIP" you could say "Test
 result: 9 PASS 1 SKIP" or something similar.
>>> Boot with "hvm_fep" on the command line and the tests should end up
>>> reporting success.
>> They do not, because the hvm_fep code calls vmx_cpuid_intercept (not
>> vmx_do_cpuid) so it skips the faulting check.  The reason I did this
>> in vmx_do_cpuid originally is that hvm_efer_valid also calls
>> vmx_cpuid_intercept and that should not fault.
>>
>> I could push the cpuid faulting code down into vmx_cpuid_intercept,
>> give it a non-void return value so it can tell its callees not to
>> advance the IP in this situation, and make hvm_efer_valid save, clear,
>> and restore the cpuid_fault flag on the vcpu to call
>> vmx_cpuid_intercept.  Though it's not immediately obvious to me that
>> hvm_efer_valid is always called with v == current.  Do you think it's
>> worth it for this testing code?
>
> This isn't just for testing code.  It also means that cpuid faulting
> support won't work with introspected domains, which can also end up
> emulating cpuid instructions because of restricted execute permissions
> on a page.
>
> The hvm_efer_valid() tangle can't be untangled at the moment; the use of
> vmx_cpuid_intercept() is deliberate to provide accurate behaviour with
> the handling on EFER_SCE.
>
> Your best bet here is to put a faulting check in hvmemul_cpuid() as well.

That's not quite what we want either, because hvmemul_cpuid will also
be called when clzero is emulated.

- Kyle

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

Re: [Xen-devel] Outreachy golang bindings planning

[Ronald Rojas]

On Wed, Oct 12, 2016 at 12:49:18PM +0100, George Dunlap wrote:
> Hey Ronald,
> 
> My ultimate vision for the libxl golang project is to have the following:
> 
> - Golang bindings for all core libxl functionality
> - A test program which exersises as much of that functionality as is
> reasonable
> 
> The C libxl library has two components: parts that are written by hand
> (such as libxl.h and libxl_*.c), and parts that are generated
> programmatically by the IDL compiler (such as _libxl_types.h and
> _libxl_types.c).  I think the end goal should be to extend the IDL to
> generate at least the Golang types, and probably a lot of the "helper"
> methods as well (such as ${TYPE}.String() or ${TYPE}.FromString()).
> 
> But before diving into the I think it makes sense to first implement a
> core set of functionality by hand, to see what the shape of the library
> looks like, then implement the type-generation part of the IDL.  Other
> things we might do with the IDL, such as generation of utility methods,
> we can add in at later points as well.
> 
> At the bottom of this mail, I've got all the libxl functions from
> libxl.h sorted into what seems to me a useful order to start working on
> things.
> 
> I list here the "headers".  This is a *lot* of functionality; I very
> greatly doubt that it will be possible to get all of it implemented and
> tested during the internship.  I'd much rather have a decent core set of
> functionality with a really good testing than attempt to get all the
> functions "implemented" in a way which nobody knows if it works.
> 
> If we can get the basic IDL working, and stuff implemented and
> well-tested through "Secondary host operations", I think the internship
> will have been a solid success.  If we get through "Devices: PCI", I
> think it will have been a wild success. :-)
> 

It looks like due to the large timezone difference that we have I'm not able to
catch you on #xen-devel a lot of the time so I may start relying on email 
a bit more, anyway...

I made a quick timeline in a google doc that outlines what I think I can 
accomplish during the duration of the Outreachy internship which I will link 
below(1). I gave it a fairly optimistic view of what could be done so that if 
anything happens, like an emergency or maybe something is harder then expected,
enough should still be accomplished during the internship period so that it'll 
still be considered a success. Feel free to edit it however you want. 

Since the application would have been due later today, October 17 7:00PM UTC, 
I tentatively submitted the application. It can be edited until November 8th 
so if you think I should change anything let me know and I'll do that as soon
as I can. I'm not sure if you can view my application now but I will provide
a link to a google doc that will have exactly what I submitted on my 
application(2). You should be able to edit it if you want to. 
 
Notes on school:
I have most of my midterms next week so I probably won't be able to contribute 
much then. I will try to finish all of the major problems this week, like 
finalizing the application and the project timeline. Then in two weeks I will 
have the time to do some more work, like creating the Makefile for the golang 
binding project. 

Links:
(1) 
https://docs.google.com/document/d/1X1Xyb8YBGcBsfDH1oDsUPQM8lwCLYrJQmgV52HStY6o/edit?usp=sharing
(2) 
https://docs.google.com/document/d/1yfVc5eJlIeQYiccuvu6YMLUm4_uGJOypOYjM_zmd6HQ/edit?usp=sharing

Thanks, 
Ronald Rojas

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

Re: [Xen-devel] [PATCH for-4.8 1/3] libacpi: fix arm64 build

[Wei Liu]

On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote:
> On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote:
> > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> > > The arm64 build for libacpi was broken due to two reasons:
> > > 
> > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
> > > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
> > >made CONFIG_ARM disappear.
> > > 
> > > Fix those by:
> > > 
> > > 1. Correctly generate full path for dsdt_anaycpu_arm.c.
> > > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
> > >on settings in firmware/Rules.mk.
> > > 
> > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
> > > accurate.
> > > 
> > > Reported-by: Julien Grall 
> > > Signed-off-by: Wei Liu 
> > > ---
> > > Cc: Julien Grall 
> > > Cc: Wei Chen 
> > > Cc: Steve Capper 
> > > Cc: Jan Beulich 
> > > Cc: Boris Ostrovsky 
> > > Cc: Shannon Zhao 
> > > Cc: Stefano Stebellini 
> > > 
> > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
> > > on arm64.
> > > 
> > > Would appreciate any build test report from ARM people.
> > 
> > I set up a chroot environment this morning and built arm64 Xen. It
> > worked.
> > 
> > Since Jan and Julien are both away, I've taken the liberty of applying
> > this patch with both my RM hat and tools maintainer hat on.
> > 
> > I have also applied patch #3 since it is rather trivial.
> > 
> > I will let Jan decide whether patch #2 is necessary.
> > 
> 
> Thanks Wei,
> I am trying to verify this patch, but I think I am running into another
> issue with the libxl acpi support patches.
> 
> Essentially I'm getting namespace clashes with the following:
>  * nonnull
>  * noreturn
>  * register_t
> 
> I think this is due to the following logic in the libxl/Makefile:
> libxl_arm_acpi.o: libxl_arm_acpi.c
> $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> 
> When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull
> in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which
> then eventually pulls in xen/include/xen/compiler.h which redefines key
> information.
> 
> Which rootfs are you chrooting into for the testing?
> (I've experienced build issues on Debian Jessie and Ubuntu Xenial running
> in a Docker container).
> 

qemu-debootstrap, sid, arm64.

I saw similar errors. But they went away after I `git clean -fffxx`
the tree.

The fact that they went away somehow and Julien succeeded in building on
variant of this patch made me think it was due to some issues in my
environment.

> Cheers,
> -- 
> Steve
> 
> I build Xen via:
> $ git clean -f -d -x
> $ ./configure --with-xenstored=xenstored 
> --with-system-qemu=/usr/local/bin/qemu-system-aarch64
> $ make
> 
> My builds finish like this:
> 
> gcc -c -O1 -fno-omit-frame-pointer  -DBUILD_ID -g -fno-strict-aliasing 
> -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement 
> -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O0 -g3 
> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF 
> .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
> -fno-optimize-sibling-calls  -Werror -Wno-format-zero-length 
> -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral 
> -I. -fPIC -pthread 
> -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include 
> -I/home/steven/xen/tools/libxl/../../tools/include 
> -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include 
> -I/home/steven/xen/tools/libxl/../../tools/include 
> -I/home/steven/xen/tools/libxl/../../tools/libxc/include 
> -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include 
> -I/home/steven/xen/tools/libxl/../../tools/include 
> -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include 
> -I/home/steven/xen/tools/libxl/../../tools/include 
> -I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ 
> -I/home/steven/xen/tools/libxl/../../tools/libxc/include 
> -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include 
> -I/home/steven/xen/tools/libxl/../../tools/include 
> -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include 
> -I/home/steven/xen/tools/libxl/../../tools/include 
> -I/home/steven/xen/tools/libxl/../../tools/include 
> -I/home/steven/xen/tools/libxl/../../tools/xenstore/include 
> -I/home/steven/xen/tools/libxl/../../tools/include 
> -I/home/steven/xen/tools/libxl/../../tools/blktap2/control 
> -I/home/steven/xen/tools/libxl/../../tools/blktap2/include 
> -I/home/steven/xen/tools/libxl/../../tools/include  -Wshadow -include 
> /home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/include/ -o 
> libxl_arm_acpi.o libxl_arm_acpi.c
> In file included from 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101487
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 
101487
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 101398 pass in 
101487
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101487
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101487
 test-armhf-armhf-xl-multivcpu  9 debian-install  fail in 101470 pass in 101487
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 101398
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101398
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 101434
 test-amd64-i386-xl6 xen-boot   fail pass in 101470
 test-armhf-armhf-xl-credit2   6 xen-boot   fail pass in 101483
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeat  fail pass in 101483

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101398 never pass
 test-amd64-i386-libvirt-xsm 12 migrate-support-check fail in 101434 never pass
 test-armhf-armhf-xl-credit2 12 migrate-support-check fail in 101434 never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 101434 never 
pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 

[Xen-devel] [distros-debian-sid test] 67893: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-sid-netboot-pygrub  9 debian-di-install  fail like 67854
 test-amd64-i386-i386-sid-netboot-pvgrub  9 debian-di-install   fail like 67854
 test-amd64-amd64-amd64-sid-netboot-pvgrub  9 debian-di-install fail like 67854
 test-armhf-armhf-armhf-sid-netboot-pygrub  9 debian-di-install fail like 67854
 test-amd64-amd64-i386-sid-netboot-pygrub  9 debian-di-install  fail like 67854

baseline version:
 flight   67854

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



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] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 17/10/16 17:28, Kyle Huey wrote:
> On Mon, Oct 17, 2016 at 5:34 AM, Andrew Cooper
>  wrote:
>> On 14/10/16 20:36, Kyle Huey wrote:
>>> On Fri, Oct 14, 2016 at 10:18 AM, Andrew Cooper
>>>  wrote:
 On a slightly separate note, as you have just been a successful
 guinea-pig for XTF, how did you find it?  It is a very new (still
 somewhat in development) system but the project is looking to try and
 improve regression testing in this way, especially for new features.  I
 welcome any feedback.
>> FWIW, I have just done some library improvements and rebased the test.
>>
>>> It's pretty slick.  Much better than what Linux has ;)
>>>
>>> I do think it's a bit confusing that xtf_has_fep is false on PV guests.
>> Now you point it out, I can see how it would be confusing.  This is due
>> to the history of FEP.
>>
>> The sequence `ud2; .ascii 'xen'; cpuid` has been around ages (it
>> predates faulting and hardware with mask/override MSRs), and is used by
>> PV guests to specifically request Xen's CPUID information, rather than
>> getting the real hardware information.
>>
>> There is also an rdtscp variant for PV guests, used for virtual TSC modes.
>>
>> In Xen 4.5, I introduced the same prefix to HVM guests, but for
>> arbitrary instructions.  This was for the express purpose of testing the
>> x86 instruction emulator.
>>
>> As a result, CPUID in PV guests is the odd case out.
>>
>>> It might also be nice to (at least optionally) have xtf_assert(cond,
>>> message) so instead of
>>>
>>> if ( cond )
>>> xtf_failure(message);
>>>
>>> you can write
>>>
>>> xtf_assert(!cond, message);
>>>
>>> A bonus of doing this is that the framework could actually count how
>>> many checks were run.  So for the HVM tests (which don't run the FEP
>>> bits) instead of getting "Test result: SKIP" you could say "Test
>>> result: 9 PASS 1 SKIP" or something similar.
>> Boot with "hvm_fep" on the command line and the tests should end up
>> reporting success.
> They do not, because the hvm_fep code calls vmx_cpuid_intercept (not
> vmx_do_cpuid) so it skips the faulting check.  The reason I did this
> in vmx_do_cpuid originally is that hvm_efer_valid also calls
> vmx_cpuid_intercept and that should not fault.
>
> I could push the cpuid faulting code down into vmx_cpuid_intercept,
> give it a non-void return value so it can tell its callees not to
> advance the IP in this situation, and make hvm_efer_valid save, clear,
> and restore the cpuid_fault flag on the vcpu to call
> vmx_cpuid_intercept.  Though it's not immediately obvious to me that
> hvm_efer_valid is always called with v == current.  Do you think it's
> worth it for this testing code?

This isn't just for testing code.  It also means that cpuid faulting
support won't work with introspected domains, which can also end up
emulating cpuid instructions because of restricted execute permissions
on a page.

The hvm_efer_valid() tangle can't be untangled at the moment; the use of
vmx_cpuid_intercept() is deliberate to provide accurate behaviour with
the handling on EFER_SCE.

Your best bet here is to put a faulting check in hvmemul_cpuid() as well.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

On Mon, Oct 17, 2016 at 5:34 AM, Andrew Cooper
 wrote:
> On 14/10/16 20:36, Kyle Huey wrote:
>> On Fri, Oct 14, 2016 at 10:18 AM, Andrew Cooper
>>  wrote:
>>> On a slightly separate note, as you have just been a successful
>>> guinea-pig for XTF, how did you find it?  It is a very new (still
>>> somewhat in development) system but the project is looking to try and
>>> improve regression testing in this way, especially for new features.  I
>>> welcome any feedback.
>
> FWIW, I have just done some library improvements and rebased the test.
>
>> It's pretty slick.  Much better than what Linux has ;)
>>
>> I do think it's a bit confusing that xtf_has_fep is false on PV guests.
>
> Now you point it out, I can see how it would be confusing.  This is due
> to the history of FEP.
>
> The sequence `ud2; .ascii 'xen'; cpuid` has been around ages (it
> predates faulting and hardware with mask/override MSRs), and is used by
> PV guests to specifically request Xen's CPUID information, rather than
> getting the real hardware information.
>
> There is also an rdtscp variant for PV guests, used for virtual TSC modes.
>
> In Xen 4.5, I introduced the same prefix to HVM guests, but for
> arbitrary instructions.  This was for the express purpose of testing the
> x86 instruction emulator.
>
> As a result, CPUID in PV guests is the odd case out.
>
>>
>> It might also be nice to (at least optionally) have xtf_assert(cond,
>> message) so instead of
>>
>> if ( cond )
>> xtf_failure(message);
>>
>> you can write
>>
>> xtf_assert(!cond, message);
>>
>> A bonus of doing this is that the framework could actually count how
>> many checks were run.  So for the HVM tests (which don't run the FEP
>> bits) instead of getting "Test result: SKIP" you could say "Test
>> result: 9 PASS 1 SKIP" or something similar.
>
> Boot with "hvm_fep" on the command line and the tests should end up
> reporting success.

They do not, because the hvm_fep code calls vmx_cpuid_intercept (not
vmx_do_cpuid) so it skips the faulting check.  The reason I did this
in vmx_do_cpuid originally is that hvm_efer_valid also calls
vmx_cpuid_intercept and that should not fault.

I could push the cpuid faulting code down into vmx_cpuid_intercept,
give it a non-void return value so it can tell its callees not to
advance the IP in this situation, and make hvm_efer_valid save, clear,
and restore the cpuid_fault flag on the vcpu to call
vmx_cpuid_intercept.  Though it's not immediately obvious to me that
hvm_efer_valid is always called with v == current.  Do you think it's
worth it for this testing code?

- Kyle

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  44a14c95e3b2dd1c676eac104354b53dbf6324a4
baseline version:
 xen  05e379bd279768495cdc516f17a120e30dfbcca5

Last test of basis   101489  2016-10-17 11:01:03 Z0 days
Testing same since   101492  2016-10-17 14:01:37 Z0 days1 attempts


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

Re: [Xen-devel] New ipxe tarball

[Ian Jackson]

Boris Ostrovsky writes ("Re: New ipxe tarball"):
> But (as you said below) we should be able to fetch the file that the
> Makefile references. (I didn't realize it was never put up there because
> presumably git clone worked until the DNS hiccup here).

I've arranged for an apparently-correct file to be in the right place,
and it seems to WTFM.  (I checked the file's contents corresponded to
the git commit in Config.mk but have not verified the provenance of
that git commit hash.)

Ian.

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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[Sander Eikelenboom]

Thursday, October 13, 2016, 4:43:31 PM, you wrote:

> Hi Jan / Wei,

> Took a while before i had the chance to fiddle some more to find the actual 
> culprit.
> After analyzing the output of xl -v create somewhat more i came to the 
> insight it was probably Qemu and not Xen causing the fault.

> As a test I just used a qemu-xen binary build with xen-4.6.0 booting up a 
> guest with
> direct kernel boot mode on xen-unstable. And that old qemu binary works fine.

> After testing i can conclude, Jan was right, the bisection was a red herring,
> the problem is caused by some change in Qemu and not by something in the Xen 
> tree.
> (strange thing is that for as far as i know i did a "make distclean" between 
> every build (taking a lot of time), which should have pulled a fresh qemu-xen 
> tree and therefor the bisection should have lead to a commit with a Config.mk 
> hash change for qemu-xen version.)

> Will see if i can find some more time and bisect qemu and find the culprit.

> --
> Sander


Unfortunately i have to give up on this issue, for me it's impossible to bisect 
this 
issue with my present git-foo.

The first try with bisection of the whole xen-tree seems to have hit the issue 
that the 
qemu-revision that gets pulled on a fresh build is "master" during the whole
dev period. That creates havoc when trying to bisect, since you are testing 
combinations that were never developed (nor auto tested) in that combination
(especially when a xen-tree and qemu-tree change have a dependency like Roger's 
"xen: fix usage of xc_domain_create in domain builder")

While trying to bisect only qemu (keeping xen itself on RELEASE-4.6.0 and 
seabios on rel-1.8.2) it get stuck on issues with that tree.
Between 4.6.0 and 4.7.0 the qemu tree switched from 
git://xenbits.xen.org/qemu-upstream-4.6-testing.git
to git://xenbits.xen.org/qemu-xen.git),after that there seem to have 
been a lot of merges going back and forth and to me it seems a mess (but as i 
said it could also be a lack of git-foo). I tried by manual bisecting, removing 
and cloning trees again etc. but that doesn't suffice, it's all going no-where.
(while the known good build (plain RELEASE-4.6.0) always works, so it doesn't 
seem to be some random problem)

So perhaps some dev can at least verify that the issue is there (since 4.7.0)
and put it on the "known broken" list of things.

--
Sander


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

Re: [Xen-devel] [PATCH for-4.8 1/3] libacpi: fix arm64 build

[Steve Capper]

On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote:
> On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> > The arm64 build for libacpi was broken due to two reasons:
> > 
> > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
> > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
> >made CONFIG_ARM disappear.
> > 
> > Fix those by:
> > 
> > 1. Correctly generate full path for dsdt_anaycpu_arm.c.
> > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
> >on settings in firmware/Rules.mk.
> > 
> > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
> > accurate.
> > 
> > Reported-by: Julien Grall 
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Julien Grall 
> > Cc: Wei Chen 
> > Cc: Steve Capper 
> > Cc: Jan Beulich 
> > Cc: Boris Ostrovsky 
> > Cc: Shannon Zhao 
> > Cc: Stefano Stebellini 
> > 
> > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
> > on arm64.
> > 
> > Would appreciate any build test report from ARM people.
> 
> I set up a chroot environment this morning and built arm64 Xen. It
> worked.
> 
> Since Jan and Julien are both away, I've taken the liberty of applying
> this patch with both my RM hat and tools maintainer hat on.
> 
> I have also applied patch #3 since it is rather trivial.
> 
> I will let Jan decide whether patch #2 is necessary.
> 

Thanks Wei,
I am trying to verify this patch, but I think I am running into another
issue with the libxl acpi support patches.

Essentially I'm getting namespace clashes with the following:
 * nonnull
 * noreturn
 * register_t

I think this is due to the following logic in the libxl/Makefile:
libxl_arm_acpi.o: libxl_arm_acpi.c
$(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c

When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull
in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which
then eventually pulls in xen/include/xen/compiler.h which redefines key
information.

Which rootfs are you chrooting into for the testing?
(I've experienced build issues on Debian Jessie and Ubuntu Xenial running
in a Docker container).

Cheers,
-- 
Steve

I build Xen via:
$ git clean -f -d -x
$ ./configure --with-xenstored=xenstored 
--with-system-qemu=/usr/local/bin/qemu-system-aarch64
$ make

My builds finish like this:

gcc -c -O1 -fno-omit-frame-pointer  -DBUILD_ID -g -fno-strict-aliasing 
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O0 -g3 
-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF 
.libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
-fno-optimize-sibling-calls  -Werror -Wno-format-zero-length 
-Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. 
-fPIC -pthread -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/libxc/include 
-I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ 
-I/home/steven/xen/tools/libxl/../../tools/libxc/include 
-I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/xenstore/include 
-I/home/steven/xen/tools/libxl/../../tools/include 
-I/home/steven/xen/tools/libxl/../../tools/blktap2/control 
-I/home/steven/xen/tools/libxl/../../tools/blktap2/include 
-I/home/steven/xen/tools/libxl/../../tools/include  -Wshadow -include 
/home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/include/ -o 
libxl_arm_acpi.o libxl_arm_acpi.c
In file included from /usr/include/linux/types.h:4:0,
 from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19,
 from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27,
 from /usr/include/signal.h:332,
 from libxl_internal.h:30,
 from libxl_arm.h:17,
 from libxl_arm_acpi.c:19:
../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t'
 typedef u64 register_t;
 ^
In file included from /usr/include/uuid/uuid.h:38:0,
 from 

Re: [Xen-devel] [OSSTEST PATCH v2] README: Be less confusing about Tftp settings

[Konrad Rzeszutek Wilk]

On Mon, Oct 17, 2016 at 03:11:55PM +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 
> CC: Konrad Rzeszutek Wilk 

CCing Marcos.
> ---
> v2: Give the scope-free version as the basic explanation
> ---
>  README | 40 +++-
>  1 file changed, 23 insertions(+), 17 deletions(-)
> 
> diff --git a/README b/README
> index 01c4c96..07d 100644
> --- a/README
> +++ b/README
> @@ -390,7 +390,7 @@ HostProp__RebootTimeExtra
>  
>  HostProp__TftpScope
> Defines the Tftp scope (i.e. subnet) where this host resides. See
> -   "TftpFoo_ and TftpFoo" below.
> +   "TftpFoo_ and TftpFoo" below.  The default is "default".
>  
>  HostProp__NtpServer
> NTP server to use.  You should probably have your own local
> @@ -490,30 +490,36 @@ DebianNonfreeFirmware
>grep-dctrl (for example because it's not Debian) then you must set
>this to the empty string, by writing  DebianNonfreeFirmware=''
>  
> -TftpFoo_ and TftpFoo
> +Tftp*
> +   Settings related to the tftp server:
>  
> -Describes various properties relating to Tftp in a given ,
> -where a  is a given subnet, DHCP server etc. Valid
> -properties are:
> -
> -Path  The path to the root of the directory which is exposed 
> by
> +TftpPath  The path to the root of the directory which is exposed 
> by
>the tftpserver (e.g. /tftpboot).
> -TmpDirA directory under `Path' to use for temporary files.
> +TftpTmpDirA directory under `Path' to use for temporary files.
>  
> -PxeDirThe path under `Path' to the PXE configuration 
> directory
> +TftpPxeDirThe path under `Path' to the PXE configuration 
> directory
>(e.g. pxelinux.cfg)
> -PxeGroup  The Unix group which should own files under `PxeDir'.
> -PxeTemplates  See TftpPxeTemplates
> -PxeTemplatesReal
> +TftpPxeGroup  The Unix group which should own files under `PxeDir'.
> +TftpPxeTemplates  See TftpPxeTemplates
> +TftpPxeTemplatesReal
>  
> -DiBaseThe path under `Path' to the root of the debian
> +TftpDiBaseThe path under `Path' to the root of the debian
>installer images.
> -GrubBase  The path under `Path' to the root of the grub
> +TftpGrubBase  The path under `Path' to the root of the grub
>EFI PXE images.
>  
> -For hosts in scope "default", TftpFoo_default (if set) takes
> -precedence over TftpFoo.  TftpFoo is used when the setting Foo is
> -not defined for the host's scope.
> +Tftp_
> +
> +It is possible to have multiple subnets, DHCP servers, tftp
> +servers, etc.  Each one is a , referenced by
> +HostProp__TftpScope.
> +
> +For hosts in scope , Tftp_ (if set) takes
> +precedence over each Tftp listed above.
> +
> +So for hosts in scope "default" (including ones without an

s/So for/For/

s/scope/the scope/ ?

> +explicit TftpScope) Tftp is used whenever
> +Tftp_default is not defined.
>  
>  TftpPxeTemplates
>  List (space-separated) of template filenames for writing
> -- 
> 2.1.4
> 

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

[Xen-devel] [OSSTEST PATCH v2] README: Be less confusing about Tftp settings

[Ian Jackson]

Signed-off-by: Ian Jackson 
CC: Konrad Rzeszutek Wilk 
---
v2: Give the scope-free version as the basic explanation
---
 README | 40 +++-
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/README b/README
index 01c4c96..07d 100644
--- a/README
+++ b/README
@@ -390,7 +390,7 @@ HostProp__RebootTimeExtra
 
 HostProp__TftpScope
Defines the Tftp scope (i.e. subnet) where this host resides. See
-   "TftpFoo_ and TftpFoo" below.
+   "TftpFoo_ and TftpFoo" below.  The default is "default".
 
 HostProp__NtpServer
NTP server to use.  You should probably have your own local
@@ -490,30 +490,36 @@ DebianNonfreeFirmware
   grep-dctrl (for example because it's not Debian) then you must set
   this to the empty string, by writing  DebianNonfreeFirmware=''
 
-TftpFoo_ and TftpFoo
+Tftp*
+   Settings related to the tftp server:
 
-Describes various properties relating to Tftp in a given ,
-where a  is a given subnet, DHCP server etc. Valid
-properties are:
-
-Path  The path to the root of the directory which is exposed by
+TftpPath  The path to the root of the directory which is exposed by
   the tftpserver (e.g. /tftpboot).
-TmpDirA directory under `Path' to use for temporary files.
+TftpTmpDirA directory under `Path' to use for temporary files.
 
-PxeDirThe path under `Path' to the PXE configuration directory
+TftpPxeDirThe path under `Path' to the PXE configuration directory
   (e.g. pxelinux.cfg)
-PxeGroup  The Unix group which should own files under `PxeDir'.
-PxeTemplates  See TftpPxeTemplates
-PxeTemplatesReal
+TftpPxeGroup  The Unix group which should own files under `PxeDir'.
+TftpPxeTemplates  See TftpPxeTemplates
+TftpPxeTemplatesReal
 
-DiBaseThe path under `Path' to the root of the debian
+TftpDiBaseThe path under `Path' to the root of the debian
   installer images.
-GrubBase  The path under `Path' to the root of the grub
+TftpGrubBase  The path under `Path' to the root of the grub
   EFI PXE images.
 
-For hosts in scope "default", TftpFoo_default (if set) takes
-precedence over TftpFoo.  TftpFoo is used when the setting Foo is
-not defined for the host's scope.
+Tftp_
+
+It is possible to have multiple subnets, DHCP servers, tftp
+servers, etc.  Each one is a , referenced by
+HostProp__TftpScope.
+
+For hosts in scope , Tftp_ (if set) takes
+precedence over each Tftp listed above.
+
+So for hosts in scope "default" (including ones without an
+explicit TftpScope) Tftp is used whenever
+Tftp_default is not defined.
 
 TftpPxeTemplates
 List (space-separated) of template filenames for writing
-- 
2.1.4


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

Re: [Xen-devel] [OSSTEST PATCH] README: Document Webspace* parameters better

[Konrad Rzeszutek Wilk]

On Mon, Oct 17, 2016 at 02:54:34PM +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 
> CC: Konrad Rzeszutek Wilk 

Cc-ing Marcos.

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  README | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/README b/README
> index 4ff7e8d..01c4c96 100644
> --- a/README
> +++ b/README
> @@ -549,8 +549,31 @@ NetNameServers
>  WebspaceFile
>  WebspaceUrl
>  WebspaceCommon
> +
> +   osstest needs to be able to make files visible to test boxes via
> +   HTTP.  That is, osstest will write them as local files
> +  
> +   (which should be a directory and end in /), and then expect
> +   the test boxes to retrieve them via HTTP GET from
> +  
> +   (which should therefore start "http://;).
> +
> +   The defaults are
> +  WebspaceFile $HOME/public_html/
> +  WebspaceUrl http:///~/
> +  WebspaceCommon osstest/
> +   which will work if you have an Apache with public_html directories
> +   enabled.
> +
>  WebspaceLog
>  
> +   osstest needs to be able to read the webserver log, to see when the
> +   test box retrieves the files mentioned above.  You may need to make
> +   the logs world-readable (or put your user account in the `adm'
> +   group).
> +
> +   The default is /var/log/apache2/access.log
> +
>  
>  
>  Some of the config settings relevant to the production setup
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] New ipxe tarball

[Boris Ostrovsky]

On 10/17/2016 07:12 AM, Ian Jackson wrote:
> Wei Liu writes ("Re: New ipxe tarball"):
>> On Sun, Oct 16, 2016 at 06:10:47AM -0700, Boris Ostrovsky wrote:
>>> Looks like new ipxe tarball disappeared from xenbits:
> It was never there.
>
>>> ostr:/tmp$  /usr/bin/wget -c -O _ipxe.tar.gz 
>>> http://xenbits.xen.org/xen-extfiles/ipxe-git-827dd1bfee67daa683935ce65316f7e0f057fe1c.tar.gz
>>> --2016-10-16 09:07:20--  
>>> http://xenbits.xen.org/xen-extfiles/ipxe-git-827dd1bfee67daa683935ce65316f7e0f057fe1c.tar.gz
>>> Resolving xenbits.xen.org (xenbits.xen.org)... 104.239.192.120
>>> Connecting to xenbits.xen.org (xenbits.xen.org)|104.239.192.120|:80... 
>>> connected.
>>> HTTP request sent, awaiting response... 404 Not Found
>>> 2016-10-16 09:07:20 ERROR 404: Not Found.
>>>
>>> ostr:/tmp$ 
>>>
>>> I can see the previous version (ipxe-git-9a93db3...) but not the new one.
> The code (AFAICT from looking at tools/firmware/etherboot/Makefile)
> first tries to download the tarball, and if that fails, uses git
> clone.
>
> Does the lack of the tarball cause your actual build to fail ?

Yes it did but now that I looked at the logs more carefully it failed
because both wget *and* clone failed, the latter was due to DNS lookup
failure, most likely some sort of intermittent error since it didn't
happen on a subsequent build this morning.

But (as you said below) we should be able to fetch the file that the
Makefile references. (I didn't realize it was never put up there because
presumably git clone worked until the DNS hiccup here).

-boris


>
> I think it's probably sensible to retain this "try tarball first"
> arrangement but we should provide a tarball at least for tag mentioned
> in the release versions of Xen.
>
> Wei, are we expecting to update IPXE_GIT_TAG again ?
>
> Ian.


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

[Xen-devel] [OSSTEST PATCH] README: Be less confusing about Tftp settings

[Ian Jackson]

Signed-off-by: Ian Jackson 
CC: Konrad Rzeszutek Wilk 
---
 README | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 01c4c96..2bd8955 100644
--- a/README
+++ b/README
@@ -493,8 +493,8 @@ DebianNonfreeFirmware
 TftpFoo_ and TftpFoo
 
 Describes various properties relating to Tftp in a given ,
-where a  is a given subnet, DHCP server etc. Valid
-properties are:
+where a  is a given subnet, DHCP server etc.  Valid
+settings (ie, valid "Foo"s) are:
 
 Path  The path to the root of the directory which is exposed by
   the tftpserver (e.g. /tftpboot).
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH] README: Document Webspace* parameters better

[Ian Jackson]

Signed-off-by: Ian Jackson 
CC: Konrad Rzeszutek Wilk 
---
 README | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/README b/README
index 4ff7e8d..01c4c96 100644
--- a/README
+++ b/README
@@ -549,8 +549,31 @@ NetNameServers
 WebspaceFile
 WebspaceUrl
 WebspaceCommon
+
+   osstest needs to be able to make files visible to test boxes via
+   HTTP.  That is, osstest will write them as local files
+  
+   (which should be a directory and end in /), and then expect
+   the test boxes to retrieve them via HTTP GET from
+  
+   (which should therefore start "http://;).
+
+   The defaults are
+  WebspaceFile $HOME/public_html/
+  WebspaceUrl http:///~/
+  WebspaceCommon osstest/
+   which will work if you have an Apache with public_html directories
+   enabled.
+
 WebspaceLog
 
+   osstest needs to be able to read the webserver log, to see when the
+   test box retrieves the files mentioned above.  You may need to make
+   the logs world-readable (or put your user account in the `adm'
+   group).
+
+   The default is /var/log/apache2/access.log
+
 
 
 Some of the config settings relevant to the production setup
-- 
2.1.4


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 245cda6641ade1f1013c2d5c9c838f2706636828
baseline version:
 ovmf 4dd8787a20e2b74cfcc297253f237e0ac86c9289

Last test of basis67891  2016-10-16 22:21:10 Z0 days
Testing same since67894  2016-10-17 10:51:23 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 
  Yonghong Zhu 

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



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

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

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


Push not applicable.


commit 245cda6641ade1f1013c2d5c9c838f2706636828
Author: Yonghong Zhu 
Date:   Thu Oct 13 15:59:06 2016 +0800

BaseTools: Update sign tool to make MonotonicCount *after* Payload

The WIN_CERTIFICATE_UEFI_GUID AuthInfo defined in the UEFI spec
mentioned that It is a signature across the image data and the
Monotonic Count value. After clarification, we do the signature
calculation, we put MonotonicCount after Payload.

Cc: Liming Gao 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 
Reviewed-by: Jiewen Yao 
Tested-by: Jiewen Yao 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  05e379bd279768495cdc516f17a120e30dfbcca5
baseline version:
 xen  20295ab63ce7f57edca9c450602ac2dace1fc721

Last test of basis   101458  2016-10-14 18:01:32 Z2 days
Testing same since   101489  2016-10-17 11:01:03 Z0 days1 attempts


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

Re: [Xen-devel] [PATCH v3 2/2] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 14/10/16 20:47, Kyle Huey wrote:
> On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
> faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
> hardware support for faulting on cpuid is necessary to emulate support with an
> HVM guest.
>
> On PV guests, hardware support is required so that userspace cpuid will trap
> to xen. Xen already enables cpuid faulting on supported CPUs for pv guests 
> (that

to Xen.

> aren't the control domain, see the comment in intel_ctxt_switch_levelling).
> Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
> do_general_protection). Once there we simply decline to emulate cpuid if the
> CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
> handle.
>
> Signed-off-by: Kyle Huey 
> ---
>  xen/arch/x86/hvm/vmx/vmx.c   | 24 ++--
>  xen/arch/x86/traps.c | 34 ++
>  xen/include/asm-x86/domain.h |  3 +++
>  3 files changed, 59 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index b9102ce..c038393 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2427,16 +2427,25 @@ static void vmx_cpuid_intercept(
>  
>  HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
>  }
>  
>  static int vmx_do_cpuid(struct cpu_user_regs *regs)
>  {
>  unsigned int eax, ebx, ecx, edx;
>  unsigned int leaf, subleaf;
> +struct segment_register sreg;
> +struct vcpu *v = current;
> +
> +hvm_get_segment_register(v, x86_seg_ss, );
> +if ( v->arch.cpuid_fault && sreg.attr.fields.dpl > 0 )
> +{
> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> +return 1; /* Don't advance the guest IP! */
> +}

Thinking about it, the segment register query can be skipped in the
likely case that faulting isn't enabled.  Could this be re-arranged to:

if ( v->arch.cpuid_fault )
{
struct segment_register sreg;

hvm_get_segment_register(v, x86_seg_ss, );
if ( sreg.attr.fields.dpl > 0 )
{
hvm_inject_hw_exception(TRAP_gp_fault, 0);
return 1; /* Don't advance the guest IP! */
}
}

With these two minor issues taken care of, Reviewed-by: Andrew Cooper


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  89e5eba167fff21d51e5eb5dbcee55ebc129d2e9
baseline version:
 xtf  c184f0dddc9d8136b9bf0f81909cac3682b3c16f

Last test of basis   101455  2016-10-14 14:43:06 Z2 days
Testing same since   101488  2016-10-17 10:44:25 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v3 1/2] x86/Intel: Expose cpuid_faulting_enabled so it can be used elsewhere

[Wei Liu]

On Fri, Oct 14, 2016 at 12:47:35PM -0700, Kyle Huey wrote:
> While we're here, use bool instead of bool_t.
> 
> Signed-off-by: Kyle Huey 

FWIW:
Reviewed-by: Wei Liu 

(since I happened to read this series per Andrew's request)

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

[Xen-devel] [xen-unstable test] 101484: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm   6 xen-boot fail in 101475 pass in 101484
 test-armhf-armhf-xl  11 guest-startfail pass in 101475
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat  fail pass in 101475

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101475
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101475
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101475
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101475
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101475

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl 12 migrate-support-check fail in 101475 never pass
 test-armhf-armhf-xl 13 saverestore-support-check fail in 101475 never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  20295ab63ce7f57edca9c450602ac2dace1fc721
baseline version:
 xen  20295ab63ce7f57edca9c450602ac2dace1fc721

Last test of basis   101484  2016-10-17 01:58:09 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17091 days0 attempts

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

Re: [Xen-devel] [PATCH v3 1/2] x86/Intel: Expose cpuid_faulting_enabled so it can be used elsewhere

[Andrew Cooper]

On 14/10/16 20:47, Kyle Huey wrote:
> While we're here, use bool instead of bool_t.
>
> Signed-off-by: Kyle Huey 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 14/10/16 20:36, Kyle Huey wrote:
> On Fri, Oct 14, 2016 at 10:18 AM, Andrew Cooper
>  wrote:
>> On a slightly separate note, as you have just been a successful
>> guinea-pig for XTF, how did you find it?  It is a very new (still
>> somewhat in development) system but the project is looking to try and
>> improve regression testing in this way, especially for new features.  I
>> welcome any feedback.

FWIW, I have just done some library improvements and rebased the test.

> It's pretty slick.  Much better than what Linux has ;)
>
> I do think it's a bit confusing that xtf_has_fep is false on PV guests.

Now you point it out, I can see how it would be confusing.  This is due
to the history of FEP.

The sequence `ud2; .ascii 'xen'; cpuid` has been around ages (it
predates faulting and hardware with mask/override MSRs), and is used by
PV guests to specifically request Xen's CPUID information, rather than
getting the real hardware information.

There is also an rdtscp variant for PV guests, used for virtual TSC modes.

In Xen 4.5, I introduced the same prefix to HVM guests, but for
arbitrary instructions.  This was for the express purpose of testing the
x86 instruction emulator.

As a result, CPUID in PV guests is the odd case out.

>
> It might also be nice to (at least optionally) have xtf_assert(cond,
> message) so instead of
>
> if ( cond )
> xtf_failure(message);
>
> you can write
>
> xtf_assert(!cond, message);
>
> A bonus of doing this is that the framework could actually count how
> many checks were run.  So for the HVM tests (which don't run the FEP
> bits) instead of getting "Test result: SKIP" you could say "Test
> result: 9 PASS 1 SKIP" or something similar.

Boot with "hvm_fep" on the command line and the tests should end up
reporting success.

It is a deliberate design choice to have a single result from a single
run of the test kernel, and is a design inherited from XenServer's
internal testing system (which runs ~10k machine hours of testing every
single day).

During development, I can see the attraction of having a unittest style
report, but it becomes counterproductive at larger scale.  Subdividing
the specific failures is not helpful for the high level view, so is
omitted to simply status reporting.

Once a test is developed and stable, it should always be reporting
SUCCESS; anything else indicates an issue to be fixed.  When
investigating failures, the actual text of the failure message is the
important bit of information.

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/2] x86/Intel: virtualize support for cpuid faulting

[Wei Liu]

On Fri, Oct 14, 2016 at 12:47:36PM -0700, Kyle Huey wrote:
> On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
> faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
> hardware support for faulting on cpuid is necessary to emulate support with an
> HVM guest.
> 
> On PV guests, hardware support is required so that userspace cpuid will trap
> to xen. Xen already enables cpuid faulting on supported CPUs for pv guests 
> (that
> aren't the control domain, see the comment in intel_ctxt_switch_levelling).
> Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
> do_general_protection). Once there we simply decline to emulate cpuid if the
> CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
> handle.
> 
> Signed-off-by: Kyle Huey 

Andrew expressed the desire of taking this patch into 4.8. After reading
the description and code in detail, I think this patch falls into the
"nice-to-have" category.

The main risk here is this patch doesn't have architecturally correct
behaviour. I would like to see an ack or review from VT maintainers to
make this patch eligible for acceptance.

Another thing to consider is timing. We plan to cut RC3 before Friday
this week, so if this patch can be acked and becomes part of RC3 I'm
fine with applying it. If not, we shall revisit the situation when it is
acked.

Wei.

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

Re: [Xen-devel] [PATCH] tools/xl: Use %u for uint32_t domids

[Wei Liu]

On Sun, Oct 16, 2016 at 08:16:32PM -0400, Ronald Rojas wrote:
> domid is normally represented by uint32_t, but many format
> strings in xl_cmdimpl.c use %d when printing, which is signed.
> Use %u instead to print the unsigned integer domid.
> 
> Signed-off-by: Ronald Rojas 

Acked + applied.

Congratulations on getting your first contribution into Xen.

Wei. 

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

Re: [Xen-devel] New ipxe tarball

[Wei Liu]

On Mon, Oct 17, 2016 at 12:12:06PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: New ipxe tarball"):
> > On Sun, Oct 16, 2016 at 06:10:47AM -0700, Boris Ostrovsky wrote:
> > > Looks like new ipxe tarball disappeared from xenbits:
> 
> It was never there.
> 
> > > ostr:/tmp$  /usr/bin/wget -c -O _ipxe.tar.gz 
> > > http://xenbits.xen.org/xen-extfiles/ipxe-git-827dd1bfee67daa683935ce65316f7e0f057fe1c.tar.gz
> > > --2016-10-16 09:07:20--  
> > > http://xenbits.xen.org/xen-extfiles/ipxe-git-827dd1bfee67daa683935ce65316f7e0f057fe1c.tar.gz
> > > Resolving xenbits.xen.org (xenbits.xen.org)... 104.239.192.120
> > > Connecting to xenbits.xen.org (xenbits.xen.org)|104.239.192.120|:80... 
> > > connected.
> > > HTTP request sent, awaiting response... 404 Not Found
> > > 2016-10-16 09:07:20 ERROR 404: Not Found.
> > > 
> > > ostr:/tmp$ 
> > > 
> > > I can see the previous version (ipxe-git-9a93db3...) but not the new one.
> 
> The code (AFAICT from looking at tools/firmware/etherboot/Makefile)
> first tries to download the tarball, and if that fails, uses git
> clone.
> 

Yes.

> Does the lack of the tarball cause your actual build to fail ?
> 
> I think it's probably sensible to retain this "try tarball first"
> arrangement but we should provide a tarball at least for tag mentioned
> in the release versions of Xen.
> 

I agree.

> Wei, are we expecting to update IPXE_GIT_TAG again ?
> 

No, not for this release.

I expect ipxe to be configurable just like qemu in the next release.

Wei.

> Ian.

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

Re: [Xen-devel] New ipxe tarball

[Ian Jackson]

Wei Liu writes ("Re: New ipxe tarball"):
> On Sun, Oct 16, 2016 at 06:10:47AM -0700, Boris Ostrovsky wrote:
> > Looks like new ipxe tarball disappeared from xenbits:

It was never there.

> > ostr:/tmp$  /usr/bin/wget -c -O _ipxe.tar.gz 
> > http://xenbits.xen.org/xen-extfiles/ipxe-git-827dd1bfee67daa683935ce65316f7e0f057fe1c.tar.gz
> > --2016-10-16 09:07:20--  
> > http://xenbits.xen.org/xen-extfiles/ipxe-git-827dd1bfee67daa683935ce65316f7e0f057fe1c.tar.gz
> > Resolving xenbits.xen.org (xenbits.xen.org)... 104.239.192.120
> > Connecting to xenbits.xen.org (xenbits.xen.org)|104.239.192.120|:80... 
> > connected.
> > HTTP request sent, awaiting response... 404 Not Found
> > 2016-10-16 09:07:20 ERROR 404: Not Found.
> > 
> > ostr:/tmp$ 
> > 
> > I can see the previous version (ipxe-git-9a93db3...) but not the new one.

The code (AFAICT from looking at tools/firmware/etherboot/Makefile)
first tries to download the tarball, and if that fails, uses git
clone.

Does the lack of the tarball cause your actual build to fail ?

I think it's probably sensible to retain this "try tarball first"
arrangement but we should provide a tarball at least for tag mentioned
in the release versions of Xen.

Wei, are we expecting to update IPXE_GIT_TAG again ?

Ian.

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

Re: [Xen-devel] [osstest test] 101467: regressions - FAIL

[Ian Jackson]

osstest service owner writes ("[osstest test] 101467: regressions - FAIL"):
> flight 101467 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/101467/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 
> 101410
>  test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 
> 101410
>  test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
> 101410
>  test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 
> 101410

This is due to fixing the saverestore-support-check to not pass when
in fact save/restore is not supported, on ARM.  Previously these steps
would pass but the actual save/restore step would fail, aborting the
whole job (and calling the whole job a fail).

I am going to force push this.  This will result in false
"regressions" in all the other branches which will need to be force
pushed.

Ian.

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

Re: [Xen-devel] [PATCH for-4.8 1/3] libacpi: fix arm64 build

[Wei Liu]

On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote:
> The arm64 build for libacpi was broken due to two reasons:
> 
> 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c.
> 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which
>made CONFIG_ARM disappear.
> 
> Fix those by:
> 
> 1. Correctly generate full path for dsdt_anaycpu_arm.c.
> 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely
>on settings in firmware/Rules.mk.
> 
> While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more
> accurate.
> 
> Reported-by: Julien Grall 
> Signed-off-by: Wei Liu 
> ---
> Cc: Julien Grall 
> Cc: Wei Chen 
> Cc: Steve Capper 
> Cc: Jan Beulich 
> Cc: Boris Ostrovsky 
> Cc: Shannon Zhao 
> Cc: Stefano Stebellini 
> 
> Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant
> on arm64.
> 
> Would appreciate any build test report from ARM people.

I set up a chroot environment this morning and built arm64 Xen. It
worked.

Since Jan and Julien are both away, I've taken the liberty of applying
this patch with both my RM hat and tools maintainer hat on.

I have also applied patch #3 since it is rather trivial.

I will let Jan decide whether patch #2 is necessary.

Wei.

> ---
>  tools/libacpi/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
> index db7a3a9..24eb0c2 100644
> --- a/tools/libacpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@ -13,12 +13,12 @@
>  #
>  
>  XEN_ROOT = $(CURDIR)/../..
> -include $(XEN_ROOT)/tools/firmware/Rules.mk
> +include $(XEN_ROOT)/tools/Rules.mk
>  
>  MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>  
>  C_SRC-$(GPL) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
> -C_SRC-$(CONFIG_ARM) = $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
> +C_SRC-$(CONFIG_ARM_64) = dsdt_anycpu_arm.c
>  C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_pvh.c $(C_SRC-y))
>  H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
> ssdt_tpm.h)
>  
> -- 
> 2.1.4
> 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 245cda6641ade1f1013c2d5c9c838f2706636828
baseline version:
 ovmf 4dd8787a20e2b74cfcc297253f237e0ac86c9289

Last test of basis   101481  2016-10-16 20:15:30 Z0 days
Testing same since   101486  2016-10-17 05:43:22 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 
  Yonghong Zhu 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] ANNOUNCEMENT] Xen 4.8 RC2 FULL SUCCESS 13.10.16

[Wei Liu]

On Sat, Oct 15, 2016 at 11:17:06AM +0100, Juergen Schinker wrote:
[...]
> 
> 
> how would I know that a new security patch is available?
> 

Keep an eye on https://xenbits.xen.org/xsa/

> 
> 
> next I test the new credit2 and RTDS scheduler yay
> 
[...]
> 
> would it make sense to give every VM all cpu cores and balance via scheduler 
> with differet weightings?

Play with it however you like.

Wei.

> 
> J

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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Quan Xu)]

On October 11, 2016 7:11 PM, Xuquan < xuqu...@huawei.com > wrote:
>On October 11, 2016 3:49 PM, Tian, Kevin 
>>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>>> Sent: Monday, October 10, 2016 6:49 PM
>>>
>>> On October 10, 2016 5:40 PM, Jan Beulich < jbeul...@suse.com > wrote:
>>> >> >>> On 20.09.16 at 15:30,  wrote:
>>> >> > --- a/xen/arch/x86/hvm/vlapic.c
>>> >> > +++ b/xen/arch/x86/hvm/vlapic.c
>>> >> > @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic
>>> >> > *vlapic) void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)  
>>> >> > {
>>> >> >  struct domain *d = vlapic_domain(vlapic);
>>> >> > +struct vcpu *v = vlapic_vcpu(vlapic);
>>> >> > +struct hvm_intack pt_intack;
>>> >> > +
>>> >> > +pt_intack.vector = vector;
>>> >> > +pt_intack.source = hvm_intsrc_lapic;
>>> >> > +pt_intr_post(v, pt_intack);
>>> >>
>>> >> This also sits on the EOI LAPIC register write path, i.e. the
>>> >> change then also affects non-apicv environments.
>>> >
>>> >The new logic should be entered only when EOI-induced exit happens.
>>> >
>>> 
>>>  Yes, more that the EOI-induced exit is conditional,
>>>  specifically, the bitmap is set by vmx_set_eoi_exit_bitmap().
>>>  Jan, what do you think? While I recall from v1 discussion, you
>>>  have the same comment. We can dig it deep..
>>> >>>
>>> >>>See my reply to Kevin sent a minute ago. As I'm not sure what
>>> >>>Kevin means to state with several of his responses, I can't
>>> >>>properly respond for now. And then what you say doesn't really
>>> >>>address my concern - things being conditional elsewhere doesn't
>>> >>>mean we won't get here too in the non-apicv case, at least not in
>>> >>>a way that I can follow
>>right away.
>>> >>
>>> >> Jan, any idea now?
>>> >
>>> >I don't think there was anything left open on the other sub-thread;
>>> >if there is, please point out specific aspects which are still unclear.
>>> >
>>>
>>> Sorry, I overlooked the other sub-thread after holiday(10.1-10.7)..
>>> I will read it again..
>>>
>>> Quan
>>
>>Is there any discussion after 10.1? I didn't see it.
>>
>>Back to the main open before holiday - multiple EOIs may come to clear
>>irq_issued before guest actually handles the very vpt injection
>>(possible if vpt vector is shared with other sources). I don't see a
>>good solution on that open... :/
>>
>>We've discussed various options which all fail in one or another place
>>- either miss an injection, or incur undesired injections.
>>Possibly we should consider another direction - fall back to non-apicv
>>path when we see vpt vector pending but it's not the highest one.
>>
>>Original condition to enter virtual intr delivery:
>>  else if ( cpu_has_vmx_virtual_intr_delivery &&
>>  intack.source != hvm_intsrc_pic &&
>>  intack.source != hvm_intsrc_vector )
>>
>>now new condition:
>>  else if ( cpu_has_vmx_virtual_intr_delivery &&
>>  intack.source != hvm_intsrc_pic &&
>>  intack.source != hvm_intsrc_vector &&
>>  (pt_vector == -1 || intack.vector == pt_vector) )
>>
>>Thoughts?
>>
>Kevin,
>When I try to fix it as your suggestion, I cannot boot the guest, with below
>message(from xl dmesg):

with Kevin's patch, the hypervisor always calls ' vmx_inject_extint() -> 
__vmx_inject_exception()' to inject exception, then vm-entry on loop..
the interrupt (PT or IPI, or others) can't deliver to guest..

and so far, we suppress MSR-based APIC suggestion when having APIC-V by 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=7f2e992b824ec62a2818e64390ac2ccfbd74e6b7
so I think we couldn't fallback to non-apicv dynamically here..

Quan



>(d1) HVM Loader
>(d1) Detected Xen v4.8-unstable
>(d1) Xenbus rings @0xfeffc000, event channel 1
>(d1) System requested SeaBIOS
>(d1) CPU speed is 2394 MHz
>(d1) Relocating guest memory for lowmem MMIO space disabled
>(XEN) irq.c:275: Dom1 PCI link 0 changed 0 -> 5
>(d1) PCI-ISA link 0 routed to IRQ5
>(XEN) irq.c:275: Dom1 PCI link 1 changed 0 -> 10
>(d1) PCI-ISA link 1 routed to IRQ10
>(XEN) irq.c:275: Dom1 PCI link 2 changed 0 -> 11
>(d1) PCI-ISA link 2 routed to IRQ11
>(XEN) irq.c:275: Dom1 PCI link 3 changed 0 -> 5
>(d1) PCI-ISA link 3 routed to IRQ5
>(d1) pci dev 01:3 INTA->IRQ10
>(d1) pci dev 02:0 INTA->IRQ11
>(d1) RAM in high memory; setting high_mem resource base to 20f80
>(d1) pci dev 03:0 bar 10 size 00200: 0f008
>(d1) pci dev 02:0 bar 14 size 00100: 0f208
>(d1) pci dev 03:0 bar 30 size 1: 0f300
>(d1) pci dev 03:0 bar 14 size 01000: 0f301
>(d1) pci dev 02:0 bar 10 size 00100: 0c001
>(d1) pci dev 01:1 bar 20 size 00010: 0c101
>(d1) Multiprocessor initialisation:
>(d1)  - CPU0 ... 46-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
>(d1)  - CPU1 ... 46-bit phys ... fixed MTRRs ... var MTRRs 

Re: [Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 14/10/16 20:28, Kyle Huey wrote:
>> :) I am now curious as to which bit I missed.
> I made these changes.
>
> - Kyle
>
> ---
>  tests/cpuid-faulting/main.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tests/cpuid-faulting/main.c b/tests/cpuid-faulting/main.c
> index 3e782a2..221567d 100644
> --- a/tests/cpuid-faulting/main.c
> +++ b/tests/cpuid-faulting/main.c
> @@ -37,36 +37,39 @@ bool ex_record_fault_ebx(struct cpu_regs *regs,
>  }
>  
>  unsigned int stub_rdmsr(uint32_t idx, uint64_t *val)
>  {
>  unsigned int fault = 0;
>  uint32_t lo, hi;
>  
>  *val = 0;
> -asm volatile("1: rdmsr; 2:"
> +asm volatile("1: rdmsr;"
> + "xor %%ebx, %%ebx; 2:"
>   _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_ebx)
>   : "=a" (lo), "=d" (hi), "=" (fault)

Ah - this should be +b rather than =, which avoids modifying the assembly.

>   : "c" (idx));
>  
>  if ( !fault )
>  *val = (((uint64_t)hi) << 32) | lo;
>  
>  return fault;
>  }
>  
>  unsigned int stub_wrmsr(uint32_t idx, uint64_t val)
>  {
>  unsigned int fault = 0;
>  
> -asm volatile("1: rdmsr; 2:"
> +asm volatile("1: wrmsr;"

Oops.

~Andrew

> "xor %%ebx, %%ebx; 2:"
>   _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_ebx)
>   : "=" (fault)
>   : "c" (idx), "a" ((uint32_t)val),
> -   "d" ((uint32_t)(val >> 32)));
> +   "d" ((uint32_t)(val >> 32))
> + : "memory");
>  
>  return fault;
>  }
>  
>  unsigned long stub_cpuid(void)
>  {
>  unsigned int fault = 0;
>  
>
> base-commit: 0342fd279b05d0c2e31c8418fcffcdc9e48eb42f


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

Re: [Xen-devel] New ipxe tarball

[Wei Liu]

Ian might be able to help with this.

On Sun, Oct 16, 2016 at 06:10:47AM -0700, Boris Ostrovsky wrote:
> Looks like new ipxe tarball disappeared from xenbits:
> 
> ostr:/tmp$  /usr/bin/wget -c -O _ipxe.tar.gz 
> http://xenbits.xen.org/xen-extfiles/ipxe-git-827dd1bfee67daa683935ce65316f7e0f057fe1c.tar.gz
> --2016-10-16 09:07:20--  
> http://xenbits.xen.org/xen-extfiles/ipxe-git-827dd1bfee67daa683935ce65316f7e0f057fe1c.tar.gz
> Resolving xenbits.xen.org (xenbits.xen.org)... 104.239.192.120
> Connecting to xenbits.xen.org (xenbits.xen.org)|104.239.192.120|:80... 
> connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2016-10-16 09:07:20 ERROR 404: Not Found.
> 
> ostr:/tmp$ 
> 
> 
> I can see the previous version (ipxe-git-9a93db3...) but not the new one.
> 
> 
> -boris

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

Re: [Xen-devel] [PATCH] tools/xl: Use %u for uint32_t domids

[George Dunlap]

On Mon, Oct 17, 2016 at 12:31 AM, Ronald Rojas  wrote:
> domid is normally represented by uint32_t, but many format
> strings in xl_cmdimpl.c use %d when printing, which is signed.
> Use %u instead to print the unsigned integer domid.
>
> Signed-off-by: Ronald Rojas 
> ---

Hey Ronald!  Just to answer the question you asked on IRC about
mis-typing the e-mail address:

Sending it again is fine, but something which would have been simpler
would be to reply to the original message, including all the current
recipients, and adding in the person whom you meant to CC in the first
place.  All the maintainers are actually on the mailing list, and will
have received the original e-mail -- the CC is just to make it easier
for them to spot that there's something they need to look at. :-)

While we're at it, there's another tip for sending mail:

1. If anywhere in your commit message you have a line starting with
"CC:", `git send-email` will automatically CC that person.  e.g.:

CC: Ian Jackson 

2. If you put it below a line starting with `---` (as just above),
then those lines will automatically be removed when the person
committing it imports it into git.

So if you structure your commit message like this in git:

tools/xl: Do foo

Slightly longer description here

Signed-off-by: xxx
---
CC: George Dunlap 
CC: ...

Then you don't need to re-type the e-mail addresses every time you
re-send a new version of the patch.

Peace,
 -George


>  tools/libxl/xl_cmdimpl.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index cb43c00..b154e36 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2674,7 +2674,7 @@ static int preserve_domain(uint32_t *r_domid, 
> libxl_event *event,
>
>  libxl_uuid_generate(_uuid);
>
> -LOG("Preserving domain %d %s with suffix%s",
> +LOG("Preserving domain %u %s with suffix%s",
>  *r_domid, d_config->c_info.name, strtime);
>  rc = libxl_domain_preserve(ctx, *r_domid, _config->c_info,
> strtime, new_uuid);
> @@ -2758,7 +2758,7 @@ static int domain_wait_event(uint32_t domid, 
> libxl_event **event_r)
>  for (;;) {
>  ret = libxl_event_wait(ctx, event_r, LIBXL_EVENTMASK_ALL, 0,0);
>  if (ret) {
> -LOG("Domain %d, failed to get event, quitting (rc=%d)", domid, 
> ret);
> +LOG("Domain %u, failed to get event, quitting (rc=%d)", domid, 
> ret);
>  return ret;
>  }
>  if ((*event_r)->domid != domid) {
> @@ -3108,7 +3108,7 @@ start:
>  }
>  need_daemon = 0;
>  }
> -LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
> +LOG("Waiting for domain %s (domid %u) to die [pid %ld]",
>  d_config.c_info.name, domid, (long)getpid());
>
>  ret = libxl_evenable_domain_death(ctx, domid, 0, );
> @@ -3134,7 +3134,7 @@ start:
>  switch (event->type) {
>
>  case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
> -LOG("Domain %d has shut down, reason code %d 0x%x", domid,
> +LOG("Domain %u has shut down, reason code %d 0x%x", domid,
>  event->u.domain_shutdown.shutdown_reason,
>  event->u.domain_shutdown.shutdown_reason);
>  switch (handle_domain_death(, event, _config)) {
> @@ -3198,7 +3198,7 @@ start:
>  }
>
>  case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
> -LOG("Domain %d has been destroyed.", domid);
> +LOG("Domain %u has been destroyed.", domid);
>  libxl_event_free(ctx, event);
>  ret = 0;
>  goto out;
> @@ -3442,7 +3442,7 @@ static int set_memory_max(uint32_t domid, const char 
> *mem)
>  }
>
>  if (libxl_domain_setmaxmem(ctx, domid, memorykb)) {
> -fprintf(stderr, "cannot set domid %d static max memory to : %s\n", 
> domid, mem);
> +fprintf(stderr, "cannot set domid %u static max memory to : %s\n", 
> domid, mem);
>  return EXIT_FAILURE;
>  }
>
> @@ -3476,7 +3476,7 @@ static int set_memory_target(uint32_t domid, const char 
> *mem)
>  }
>
>  if (libxl_set_memory_target(ctx, domid, memorykb, 0, /* enforce */ 1)) {
> -fprintf(stderr, "cannot set domid %d dynamic max memory to : %s\n", 
> domid, mem);
> +fprintf(stderr, "cannot set domid %u dynamic max memory to : %s\n", 
> domid, mem);
>  return EXIT_FAILURE;
>  }
>
> @@ -4133,7 +4133,7 @@ static void shutdown_domain(uint32_t domid,
>  {
>  int rc;
>
> -fprintf(stderr, "Shutting down domain %d\n", domid);
> +fprintf(stderr, "Shutting down domain %u\n", domid);
>  rc=libxl_domain_shutdown(ctx, domid);
>  if (rc == ERROR_NOPARAVIRT) {
>  if (fallback_trigger) {
> @@ -4165,7 +4165,7 @@ static void reboot_domain(uint32_t domid, 
> 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101483
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 
101483
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 101398 pass in 
101483
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101483
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101483
 test-armhf-armhf-xl-multivcpu  9 debian-install  fail in 101470 pass in 101483
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 101398
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101398
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 101434
 test-amd64-i386-xl6 xen-boot   fail pass in 101470

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101398 never pass
 test-amd64-i386-libvirt-xsm 12 migrate-support-check fail in 101434 never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH v5 5/7] VT-d: No need to set irq affinity for posted format IRTE

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, October 12, 2016 9:56 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: Re: [PATCH v5 5/7] VT-d: No need to set irq affinity for posted 
> format
> IRTE
> 
> >>> On 11.10.16 at 02:57,  wrote:
> > --- a/xen/drivers/passthrough/vtd/intremap.c
> > +++ b/xen/drivers/passthrough/vtd/intremap.c
> > @@ -547,6 +547,49 @@ static int remap_entry_to_msi_msg(
> >  return 0;
> >  }
> >
> > +static bool_t pi_can_suppress_irte_update(struct iremap_entry *new,
> 
> bool (and true/false respectively) please.
> 
> And then the function name suggests that no modification gets done
> here (and hence the first parameter could be const too), yet the
> implementation does otherwise (and I don't understand why).

The idea here is that if the old IRTE is in posted format and fields like
'fpd', 'sid', 'sq', or 'svt' is going to be changed , we need to use these
new values for the new_ire, while we still need to use the old values
of other fields in IRTE, so this function returns the new irte in its first
 parameter it we cannot suppress the update. I try to do it in this
function.

> 
> > +const struct iremap_entry *old)
> > +{
> > +bool_t ret = 1;
> > +u16 fpd, sid, sq, svt;
> > +
> > +if ( !old->remap.p || !old->remap.im )
> > +return 0;
> > +
> > +fpd = new->post.fpd;
> > +sid = new->post.sid;
> > +sq = new->post.sq;
> > +svt = new->post.svt;
> > +
> > +*new = *old;
> > +
> > +if ( fpd != old->post.fpd )
> > +{
> > +new->post.fpd = fpd;
> > +ret = 0;
> > +}
> > +
> > +if ( sid != old->post.sid )
> > +{
> > +new->post.sid = sid;
> > +ret = 0;
> > +}
> > +
> > +if ( sq != old->post.sq )
> > +{
> > +new->post.sq = sq;
> > +ret = 0;
> > +}
> > +
> > +if ( svt != old->post.svt )
> > +{
> > +new->post.svt = svt;
> > +ret = 0;
> > +}
> 
> What's the selection of the fields based on? Namely, what about
> vector, pda_l, and pda_h?

These filed are the common field between posted format and remapped format.
'vector' field has different meaning in the two formant, pda_l and pda_h is only
for posted format. As mentioned above, the purpose of this function is to find
whether use need to update this common field in posted format, if it is, we need
to use them and reuse the old value of other fields (pda_l, pda_h, vector, 
etc.).
since we need to suppress affinity related update for posted format.

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [PATCH v7 00/11] grub-xen: support booting huge pv-domains

[Daniel Kiper]

On Tue, Oct 11, 2016 at 04:00:58PM +0200, Juergen Gross wrote:
> On 04/07/16 12:53, Daniel Kiper wrote:
> > On Mon, Jul 04, 2016 at 12:33:17PM +0200, Juergen Gross wrote:
> >> On 12/05/16 07:35, Juergen Gross wrote:
> >>> Gentle ping...
> >>
> >> Okay, now 4 months since posting the last version. Could it please be
> >> included in a more timely manner?
> > 
> > Juergen and others, please be patient a bit longer. GNU, current maintainer,
> > others and I are working on improving GRUB2 maintenance. It will take some
> > time (2-4 weeks). We will drop more info when everything is established.
> > 
> > Stay tuned...
> 
> Okay, 14 weeks have passed since then. Anything new?

I am clearing my backlog and I am going to commit all waiting patches,
including yours, in 2-3 weeks. Sorry for delays.

Daniel

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

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

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, October 12, 2016 9:45 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: Re: [PATCH v5 4/7] VMX: Make sure PI is in proper state before 
> install
> the hooks
> 
> >>> On 11.10.16 at 02:57,  wrote:
> >  static void pi_desc_init(struct vcpu *v)
> >  {
> > -uint32_t dest;
> > -
> >  v->arch.hvm_vmx.pi_desc.nv = posted_intr_vector;
> >
> > -dest = cpu_physical_id(v->processor);
> > -
> > -if ( x2apic_enabled )
> > -v->arch.hvm_vmx.pi_desc.ndst = dest;
> > -else
> > -v->arch.hvm_vmx.pi_desc.ndst = MASK_INSR(dest,
> PI_xAPIC_NDST_MASK);
> > +/*
> > + * Mark NDST as invalid, then we can use this invalid value as a
> > + * marker to whether update NDST or not in vmx_pi_hooks_assign().
> > + */
> > +v->arch.hvm_vmx.pi_desc.ndst = 0x;
> 
> I think I had at the same time asked to make this a #define, so the
> two (currently) instance can be connected together.

Sorry, Maybe I didn't get that. Do you mean I need to define a Macro
for 0x, so we can use it here and in vmx.c?

Thanks,
Feng

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