[Xen-devel] [xen-4.10-testing test] 121756: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  d9756ca9802ace4037a84b947753e35ba634fd93
baseline version:
 xen  0f92968bcfa037c7747bc58b9e8a52603e52e182

Last test of basis   121045  2018-03-22 02:28:40 Z   14 days
Testing same since   121756  2018-04-04 00:17:39 Z1 days1 attempts


People who touched revisions under test:
  Julien Grall 
  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 118324

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-pvshim 7 xen-boot fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 

Re: [Xen-devel] Problem with Xen 4.7.5

[Steven Haigh]

On 2018-04-05 03:22, Ian Jackson wrote:


We have discovered a bug in Xen 4.7.5 (related to shadow paging).
This bug is a new regression compared to 4.7.4 and does not affect
other Xen releases.

We are investigating the problem.  For now, we recommend that users of
4.7.x do not upgrade to 4.7.5.

Apologies for the inconvenience.


Hi Ian,

I'm wondering if the severity of this is high enough that I should 
withdraw the 4.7.5 packages from my repos.


Is this a show-stopper? Security issue? Dom0 crash?

I released 4.7.5 packages within an hour of the 4.7.5 release 
announcement - so there are quite a few user systems that have already 
grabbed them.


--
Steven Haigh

? net...@crc.id.au ? http://www.crc.id.au
? +61 (3) 9001 6090? 0412 935 897

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

[Xen-devel] [PATCH 1/7] tools/libxc: fix strncpy size

[Marek Marczykowski-Górecki]

gcc-8 warns about possible truncation of trailing '\0'.
Final character is overridden by '\0' anyway, so don't bother to copy
it.

This fixes compile failure:

xc_pm.c: In function 'xc_set_cpufreq_gov':
xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size 
[-Werror=stringop-truncation]
 strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN);
 ^~~~
cc1: all warnings being treated as errors

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxc/xc_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxc/xc_pm.c b/tools/libxc/xc_pm.c
index 67e2418..6f8d548 100644
--- a/tools/libxc/xc_pm.c
+++ b/tools/libxc/xc_pm.c
@@ -305,7 +305,7 @@ int xc_set_cpufreq_gov(xc_interface *xch, int cpuid, char 
*govname)
 sysctl.cmd = XEN_SYSCTL_pm_op;
 sysctl.u.pm_op.cmd = SET_CPUFREQ_GOV;
 sysctl.u.pm_op.cpuid = cpuid;
-strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN);
+strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN - 1);
 scaling_governor[CPUFREQ_NAME_LEN - 1] = '\0';
 
 return xc_sysctl(xch, );
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 7/7] tools/kdd: mute spurious gcc warning

[Marek Marczykowski-Górecki]

gcc-8 complains:

kdd.c:698:13: error: 'memcpy' offset [-204, -717] is out of the bounds [0, 
216] of object 'ctrl' with type 'kdd_ctrl' {aka 'union '} 
[-Werror=array-bounds]
 memcpy(buf, ((uint8_t *)) + offset, len);
 ^
kdd.c: In function 'kdd_select_callback':
kdd.c:642:14: note: 'ctrl' declared here
 kdd_ctrl ctrl;
  ^~~~

But this is impossible - 'offset' is unsigned and correctly validated
few lines before.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/debugger/kdd/kdd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c
index 1bd5dd5..61d769e 100644
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -695,7 +695,10 @@ static void kdd_handle_read_ctrl(kdd_state *s)
 KDD_LOG(s, "Request outside of known control space\n");
 len = 0;
 } else {
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
 memcpy(buf, ((uint8_t *)) + offset, len);
+#pragma GCC diagnostic pop
 }
 }
 
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 0/7] Fix warnings found by gcc 8

[Marek Marczykowski-Górecki]

A few patches enabling build with gcc 8.

Marek Marczykowski-Górecki (7):
  tools/libxc: fix strncpy size
  tools/misc: fix hypothetical buffer overflow in xen-lowmemd
  tools/blktap2: fix hypothetical buffer overflow
  tools/blktap2: fix possible '\0' truncation
  tools/xenpmd: fix possible '\0' truncation
  tools/gdbsx: fix -Wstringop-truncation warning
  tools/kdd: mute spurious gcc warning

 tools/blktap2/drivers/block-qcow.c  |  3 ++-
 tools/blktap2/drivers/tapdisk-control.c |  5 +++--
 tools/blktap2/drivers/tapdisk-vbd.c |  3 ++-
 tools/blktap2/vhd/lib/vhd-util-read.c   |  2 +-
 tools/debugger/gdbsx/gx/gx_main.c   |  2 +-
 tools/debugger/kdd/kdd.c|  3 +++
 tools/libxc/xc_pm.c |  2 +-
 tools/misc/xen-lowmemd.c|  2 +-
 tools/xenpmd/xenpmd.c   | 12 
 9 files changed, 22 insertions(+), 12 deletions(-)

base-commit: eabb83121226d5a6a5a68da3a913ac0b5bb1e0cf
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 6/7] tools/gdbsx: fix -Wstringop-truncation warning

[Marek Marczykowski-Górecki]

gcc-8 complains:

gx_main.c: In function 'prepare_stop_reply':
gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul 
copying 6 bytes from a string of the same length [-Werror=stringop-truncation]
 strncpy(buf, "watch:", 6);
 ^

Since terminating '\0' isn't needed here at all, switch to memcpy.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/debugger/gdbsx/gx/gx_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/debugger/gdbsx/gx/gx_main.c 
b/tools/debugger/gdbsx/gx/gx_main.c
index a908c45..6dfa501 100644
--- a/tools/debugger/gdbsx/gx/gx_main.c
+++ b/tools/debugger/gdbsx/gx/gx_main.c
@@ -382,7 +382,7 @@ prepare_stop_reply(enum target_signal sig, char *buf, 
vcpuid_t vcpu)
 
 /* TBD: check if we stopped because of watchpoint */
 if (watchpoint_stop()) {
-strncpy(buf, "watch:", 6);
+memcpy(buf, "watch:", 6);
 buf += 6;
 /* TBD: **/
 }
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 4/7] tools/blktap2: fix possible '\0' truncation

[Marek Marczykowski-Górecki]

gcc-8 complains:

tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring':
tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the 
last format character [-Werror=format-truncation=]
   snprintf(params.name, sizeof(params.name) - 1, "%s", message);
 ^
tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into 
a destination of size 255
   snprintf(params.name, sizeof(params.name) - 1, "%s", message);
   ^

The "- 1" in buffer size should be actually applied to message, to leave
place for terminating '\0', not the other way around (truncate '\0' even
if it would fit).

In function 'tapdisk_control_open_image',
inlined from 'tapdisk_control_handle_request' at 
tapdisk-control.c:660:10:
tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals 
destination size [-Werror=stringop-truncation]
  strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN);
  ^~~~

In function 'tapdisk_control_create_socket',
inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9:
tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals 
destination size [-Werror=stringop-truncation]
  strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path));
  ^~~~

block-qcow.c: In function 'qcow_create':
block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals 
destination size [-Werror=stringop-truncation]
 strncpy(backing_filename, backing_file,
 ^~~
  sizeof(backing_filename));
  ~

I those cases, reduce size of copied string and make sure final '\0' is
added.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/blktap2/drivers/block-qcow.c  | 3 ++-
 tools/blktap2/drivers/tapdisk-control.c | 5 +++--
 tools/blktap2/drivers/tapdisk-vbd.c | 3 ++-
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/blktap2/drivers/block-qcow.c 
b/tools/blktap2/drivers/block-qcow.c
index b45bcaa..ae43922 100644
--- a/tools/blktap2/drivers/block-qcow.c
+++ b/tools/blktap2/drivers/block-qcow.c
@@ -1214,7 +1214,8 @@ int qcow_create(const char *filename, uint64_t total_size,
if (p && (p - backing_file) >= 2) {
/* URL like but exclude "c:" like filenames */
strncpy(backing_filename, backing_file,
-   sizeof(backing_filename));
+   sizeof(backing_filename) - 1);
+   backing_filename[sizeof(backing_filename) - 1] 
= '\0';
} else {
if (realpath(backing_file, backing_filename) == 
NULL ||
stat(backing_filename, ) != 0) {
diff --git a/tools/blktap2/drivers/tapdisk-control.c 
b/tools/blktap2/drivers/tapdisk-control.c
index 0b5cf3c..3ca5713 100644
--- a/tools/blktap2/drivers/tapdisk-control.c
+++ b/tools/blktap2/drivers/tapdisk-control.c
@@ -462,7 +462,8 @@ tapdisk_control_open_image(struct 
tapdisk_control_connection *connection,
 
params.capacity = image.size;
params.sector_size = image.secsize;
-   strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN);
+   strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN - 1);
+   params.name[BLKTAP2_MAX_MESSAGE_LEN - 1] = '\0';
 
err = ioctl(vbd->ring.fd, BLKTAP2_IOCTL_CREATE_DEVICE, );
if (err && errno != EEXIST) {
@@ -790,7 +791,7 @@ tapdisk_control_create_socket(char **socket_path)
}
 
memset(, 0, sizeof(saddr));
-   strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path));
+   strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path) - 1);
saddr.sun_family = AF_UNIX;
 
err = bind(td_control.socket,
diff --git a/tools/blktap2/drivers/tapdisk-vbd.c 
b/tools/blktap2/drivers/tapdisk-vbd.c
index fd4999a..842a427 100644
--- a/tools/blktap2/drivers/tapdisk-vbd.c
+++ b/tools/blktap2/drivers/tapdisk-vbd.c
@@ -1668,7 +1668,8 @@ out:
 
params.sector_size = image.secsize;
params.capacity= image.size;
-   snprintf(params.name, sizeof(params.name) - 1, "%s", message);
+   snprintf(params.name, sizeof(params.name),
+"%.*s", (int)sizeof(params.name) - 1, message);
 
ioctl(vbd->ring.fd, BLKTAP2_IOCTL_SET_PARAMS, );
td_flag_clear(vbd->state, TD_VBD_PAUSED);
-- 
git-series 0.9.1

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

[Xen-devel] [PATCH 3/7] tools/blktap2: fix hypothetical buffer overflow

[Marek Marczykowski-Górecki]

gcc-8 complains:

vhd-util-read.c: In function 'vhd_util_read':
vhd-util-read.c:50:24: error: '%lu' directive output may be truncated 
writing between 1 and 20 bytes into a region of size 15 
[-Werror=format-truncation=]
  snprintf(nbuf, nsize, "%" PRIu64, num);
^~~
vhd-util-read.c:50:25: note: format string is defined here
  snprintf(nbuf, nsize, "%" PRIu64, num);
vhd-util-read.c:50:24: note: directive argument in the range [0, 
18446744073709551614]
  snprintf(nbuf, nsize, "%" PRIu64, num);
^~~
vhd-util-read.c:50:2: note: 'snprintf' output between 2 and 21 bytes into a 
destination of size 15
  snprintf(nbuf, nsize, "%" PRIu64, num);
  ^~
vhd-util-read.c:43:24: error: '%#lx' directive output may be truncated 
writing between 1 and 18 bytes into a region of size 15 
[-Werror=format-truncation=]
  snprintf(nbuf, nsize, "%#" PRIx64 , num);
^~~~
vhd-util-read.c:43:25: note: format string is defined here
  snprintf(nbuf, nsize, "%#" PRIx64 , num);
vhd-util-read.c:43:24: note: directive argument in the range [0, 
18446744073709551614]
  snprintf(nbuf, nsize, "%#" PRIx64 , num);
^~~~
vhd-util-read.c:43:2: note: 'snprintf' output between 2 and 19 bytes into a 
destination of size 15
  snprintf(nbuf, nsize, "%#" PRIx64 , num);
  ^~~~

Make the buffer larger.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/blktap2/vhd/lib/vhd-util-read.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/blktap2/vhd/lib/vhd-util-read.c 
b/tools/blktap2/vhd/lib/vhd-util-read.c
index ac4d833..f290661 100644
--- a/tools/blktap2/vhd/lib/vhd-util-read.c
+++ b/tools/blktap2/vhd/lib/vhd-util-read.c
@@ -34,7 +34,7 @@
 #include "libvhd.h"
 #include "vhd-util.h"
 
-#define nsize 15
+#define nsize 24
 static char nbuf[nsize];
 
 static inline char *
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 2/7] tools/misc: fix hypothetical buffer overflow in xen-lowmemd

[Marek Marczykowski-Górecki]

gcc-8 complains:

xen-lowmemd.c: In function 'handle_low_mem':
xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing 
up to 511 bytes into a region of size 489 [-Werror=format-truncation=]
 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", 
data);
   ^~   
xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a 
destination of size 512
 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", 
data);
 
^~~~

In practice it wouldn't happen, because 'data' contains string
representation of 64-bit unsigned number (20 characters at most).
But place a limit to mute gcc warning.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/misc/xen-lowmemd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/misc/xen-lowmemd.c b/tools/misc/xen-lowmemd.c
index 865a54c..79ad34c 100644
--- a/tools/misc/xen-lowmemd.c
+++ b/tools/misc/xen-lowmemd.c
@@ -77,7 +77,7 @@ void handle_low_mem(void)
 if (!xs_write(xs_handle, XBT_NULL, 
 "/local/domain/0/memory/target", data, strlen(data)))
 {
-snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data);
+snprintf(error, BUFSZ,"Failed to write target %.24s to xenstore", 
data);
 perror(error);
 }
 }
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 5/7] tools/xenpmd: fix possible '\0' truncation

[Marek Marczykowski-Górecki]

gcc-8 complains:
xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size 
[-Werror=stringop-truncation]
 strncpy(info->oem_info, attrib_value, 32);
 ^
xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size 
[-Werror=stringop-truncation]
 strncpy(info->battery_type, attrib_value, 32);
 ^
xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size 
[-Werror=stringop-truncation]
 strncpy(info->serial_number, attrib_value, 32);
 ^~
xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size 
[-Werror=stringop-truncation]
 strncpy(info->model_number, attrib_value, 32);
 ^

Copy 31 chars, then make sure terminating '\0' is present. Those fields
are passed to strlen and as '%s' for snprintf later.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/xenpmd/xenpmd.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/xenpmd/xenpmd.c b/tools/xenpmd/xenpmd.c
index 689c8fd..56412a9 100644
--- a/tools/xenpmd/xenpmd.c
+++ b/tools/xenpmd/xenpmd.c
@@ -186,25 +186,29 @@ void set_attribute_battery_info(char *attrib_name,
 
 if ( strstr(attrib_name, "model number") ) 
 {
-strncpy(info->model_number, attrib_value, 32);
+strncpy(info->model_number, attrib_value, 31);
+info->model_number[31] = '\0';
 return;
 }
 
 if ( strstr(attrib_name, "serial number") ) 
 {
-strncpy(info->serial_number, attrib_value, 32);
+strncpy(info->serial_number, attrib_value, 31);
+info->serial_number[31] = '\0';
 return;
 }
 
 if ( strstr(attrib_name, "battery type") ) 
 {
-strncpy(info->battery_type, attrib_value, 32);
+strncpy(info->battery_type, attrib_value, 31);
+info->battery_type[31] = '\0';
 return;
 }
 
 if ( strstr(attrib_name, "OEM info") ) 
 {
-strncpy(info->oem_info, attrib_value, 32);
+strncpy(info->oem_info, attrib_value, 31);
+info->oem_info[31] = '\0';
 return;
 }
 
-- 
git-series 0.9.1

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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[André Przywara]

On 05/04/18 00:17, Amit Tomer wrote:
> Hi,
> 
>> Ah yes, if that works, we should. That bit is from the Linux BSP, isn't it?
> 
> Yes, it's from Linux BSP code only. Hope following is fine.
> 
> if ( reg & STATUS_TXFIFO_EMP )
> return TX_FIFO_SIZE;
> else if ( reg & STAT_TX_FIFO_HFL )

no else needed.
I'd write it like:
if (empty)
return FIFO_SIZE;

if (full)
return 0;

if (half)
return FIFO_SIZE / 2;

/* comment ... */
return 1;

Cheers,
Andre.

> return TX_FIFO_SIZE / 2;
> else if ( !(reg & STAT_TX_FIFO_FUL) )
> return 1;
> 
>return 0;
> 
> Thanks
> -Amit
> 


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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[Amit Tomer]

Hi,

> Ah yes, if that works, we should. That bit is from the Linux BSP, isn't it?

Yes, it's from Linux BSP code only. Hope following is fine.

if ( reg & STATUS_TXFIFO_EMP )
return TX_FIFO_SIZE;
else if ( reg & STAT_TX_FIFO_HFL )
return TX_FIFO_SIZE / 2;
else if ( !(reg & STAT_TX_FIFO_FUL) )
return 1;

   return 0;

Thanks
-Amit

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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[André Przywara]

On 04/04/18 23:25, Amit Tomer wrote:
> Hi,
> 
>> Just a nit, but it might be smarter to first check for the receive IRQ,
>> because not handling this might loose information. TX is less critical.
> 
> Ok, actually tried it ealier when  I was debugging the Rx path issue and
> that time it didn't work. May be I should try it again.
> 
> 
>> Similar to the earlyprintk behaviour we are a bit pessimistic here. I
>> don't know if there is a way to determine the number of free characters
>> in the FIFO, but we could at least return 1 if the FIFO is not full:
>>
>> if (fifo_empty)
>> return FIFO_SIZE;
>> if (!fifo_full)
>> return 1;
>> return 0;
> 
> Yeah, I thought of it initially like should we also return half the
> size of FIFO(16) when STAT_TX_FIFO_HFL bit is set ?

Ah yes, if that works, we should. That bit is from the Linux BSP, isn't it?

Cheers,
Andre.


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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[Amit Tomer]

Hi,

> Just a nit, but it might be smarter to first check for the receive IRQ,
> because not handling this might loose information. TX is less critical.

Ok, actually tried it ealier when  I was debugging the Rx path issue and
that time it didn't work. May be I should try it again.


> Similar to the earlyprintk behaviour we are a bit pessimistic here. I
> don't know if there is a way to determine the number of free characters
> in the FIFO, but we could at least return 1 if the FIFO is not full:
>
> if (fifo_empty)
> return FIFO_SIZE;
> if (!fifo_full)
> return 1;
> return 0;

Yeah, I thought of it initially like should we also return half the
size of FIFO(16) when STAT_TX_FIFO_HFL bit is set ?


Thanks
-Amit.

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

Re: [Xen-devel] [PATCH] ARM: new VGIC: evtchn: fix potential race in vcpu_mark_events_pending()

[Stefano Stabellini]

On Wed, 4 Apr 2018, Andre Przywara wrote:
> Hi,
> 
> On 04/04/18 01:04, Stefano Stabellini wrote:
> > On Tue, 3 Apr 2018, Julien Grall wrote:
> >> On 29/03/18 18:35, Stefano Stabellini wrote:
> >>> On Thu, 29 Mar 2018, Andre Przywara wrote:
>  Stefano pointed out the following situation:
>  --
>  1) vcpuA/cpuA is running, it has already handled the event, cleared
>  evtchn_upcall_pending and EOIed the event_irq but hasn't trapped into
>  Xen yet. It is still in guest mode.
> 
>  2) Xen on cpuB calls vcpu_mark_events_pending(vcpuA), then calls
>  vgic_inject_irq. However, because irq->line_level is high, it is not
>  injected.
> 
>  3) vcpuA has to wait until trapping into Xen, calling
>  vcpu_update_evtchn_irq, and going back to guest mode before receiving
>  the event. This is theoretically a very long time.
>  --
> 
>  Fix this by updating the state of our emulated IRQ line level inside
>  vcpu_mark_events_pending(), before trying to inject the new interrupt.
> 
>  Despite having two calls to vgic_inject_irq(), only one will actually do
>  something:
>  - If the emulated line level was already in sync with the actual flag,
> the VGIC ignores the first call, due to vgic_validate_injection().
>  - If the emulated line level was high, but the flag says it should have
> been low, vgic_inject_irq() will just update the line_level state.
>  - If the emulated line level was low, but the flags says it should have
> been high, we will inject the interrupt. The second call is then a
> NOP.
> 
>  Signed-off-by: Andre Przywara 
>  ---
>  Hi,
> 
>  this would ideally have been part of a former patch:
>  "[PATCH v3 06/39] ARM: evtchn: Handle level triggered IRQs correctly",
>  but this has been merged already, so this has to be a follow-up.
>  Ideally this would be merged before the final patch that introduces the
>  CONFIG_NEW_VGIC Kconfig symbol, so that the old code gets never compiled.
> 
>  Thanks,
>  Andre
> 
>    xen/arch/arm/domain.c | 11 +--
>    1 file changed, 9 insertions(+), 2 deletions(-)
> 
>  diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>  index 9688e62f78..11fa9002dc 100644
>  --- a/xen/arch/arm/domain.c
>  +++ b/xen/arch/arm/domain.c
>  @@ -947,10 +947,17 @@ void vcpu_mark_events_pending(struct vcpu *v)
>    int already_pending = test_and_set_bit(
>    0, (unsigned long *)_info(v, evtchn_upcall_pending));
>    -if ( already_pending )
>  -return;
>  +#ifdef CONFIG_NEW_VGIC
>  +/* Update the state of the current interrupt line. */
>  +vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq,
>  already_pending);
>    +/* Make the level IRQ pending. That's a NOP if it was already. */
>    vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
>  +#else
>  +/* Only signal the VGIC if it wasn't already pending. */
>  +if ( !already_pending )
>  +vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
>  +#endif
>    }
> >>>
> >>> The issue with this is that it is potentially racy, against vcpuA
> >>> trapping into Xen and executing vcpu_update_evtchn_irq, that also reads
> >>> evtchn_upcall_pending, then calls vgic_inject_irq. The last
> >>> vgic_inject_irq executed could be the one passing level = false, losing
> >>> the notification.
> >>>
> >>> I might have a better idea: what if we just vcpu_kick(v) and do nothing
> >>> else? There is no need to call vgic_inject_irq from here because the
> >>> other vcpu will take care of doing it for us after trapping into Xen
> >>> (vcpu_update_evtchn_irq). It also needs to trap into Xen anyway to be
> >>> able to receive the new event as soon as possible.
> >>>
> >>> The code would become:
> >>>
> >>>if ( already_pending )
> >>>return;
> >>>
> >>>vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
> >>>
> >>> #ifdef CONFIG_NEW_VGIC
> >>>vcpu_kick(v);
> >>> #endif
> >>>
> >>>
> >>> Note that vgic_inject_irq already does a vcpu_kick but only after
> >>> passing the vgic_validate_injection check, which would fail in this case
> >>> because irq->line_level is not up-to-date.
> >>>
> >>> What do you think?
> >>
> >> At the moment, the issue you describe is a non-issue because we set the EOI
> >> bit in the LR (see vgic_v2_populate_lr). So there are no need to kick the
> >> other vCPU as it would enter to Xen as soon as the event channel interrupt 
> >> is
> >> been eoied by the guest.
> >>
> >> Therefore, I believe we don't need to have a different version of
> >> vcpu_mark_events_pending for the new vGIC.
> > 
> > Ah! It makes sense.
> > 
> > Andre, why did you choose to set the EOI bit in the LR for 

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

[Stefano Stabellini]

On Wed, 4 Apr 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 04/04/18 00:55, Stefano Stabellini wrote:
> > On Tue, 3 Apr 2018, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 16/03/18 17:15, Julien Grall wrote:
> > > > 
> > > > 
> > > > On 16/03/2018 16:56, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > > 
> > > > > On 16/03/2018 16:33, Stefano Stabellini wrote:
> > > > > > On Fri, 16 Mar 2018, Julien Grall wrote:
> > > > > > > Hi Stefano,
> > > > > > > 
> > > > > > > On 15/03/18 23:52, Stefano Stabellini wrote:
> > > > > > > > On Wed, 14 Mar 2018, Stefano Stabellini wrote:
> > > > > > > > > After looking at the test results, which are good for arm, and
> > > > > > > > > considering that master hasn't passed yet after 2 more days, I
> > > > > > > > > agree
> > > > > > > > > with Julien: I think we should not release 4.9.2 and 4.7.5
> > > > > > > > > without
> > > > > > > > > the
> > > > > > > > > arm64 spectre patches. At this point, I'll proceed to backport
> > > > > > > > > the
> > > > > > > > > patches now.
> > > > > > > > 
> > > > > > > > Julien, Andre,
> > > > > > > > 
> > > > > > > > Please give a look at the following branches:
> > > > > > > > 
> > > > > > > > git://xenbits.xen.org/people/sstabellini/xen-unstable.git
> > > > > > > > staging-4.7-spectre
> > > > > > > > git://xenbits.xen.org/people/sstabellini/xen-unstable.git
> > > > > > > > staging-4.8-spectre
> > > > > > > > git://xenbits.xen.org/people/sstabellini/xen-unstable.git
> > > > > > > > staging-4.9-spectre
> > > > > > > 
> > > > > > > For all of the tree above, as I said yesterday, I clearly don't
> > > > > > > want
> > > > > > > to see
> > > > > > > the smccc framework backport for Xen 4.9 and older. This is a
> > > > > > > massive
> > > > > > > changes
> > > > > > > of the interface that is not necessary for spectre. My main
> > > > > > > concern is
> > > > > > > making
> > > > > > > SMC instruction available to the guest.
> > > > > > > 
> > > > > > > It would be just sufficient to emulate the few SMCCC function ID
> > > > > > > we
> > > > > > > care in
> > > > > > > do_trap_psci (function can be renamed).
> > > > > > > 
> > > > > > > This is also clearly wrong to backport coding style or code
> > > > > > > non-justified code
> > > > > > > movement (sysreg) just to please the cherry-pick.
> > > > > > > 
> > > > > > > I am also worry to bump the version of the emulated PSCI (0.2 ->
> > > > > > > 1.0)
> > > > > > > for
> > > > > > > those releases. Some guests may rely on a specific version and may
> > > > > > > now
> > > > > > > crashes.
> > > > > > > 
> > > > > > > Overall, the right way to support spectre in earlier releases is
> > > > > > > custom patch
> > > > > > > and only do minimal modification.
> > > > > > > 
> > > > > > > > git://xenbits.xen.org/people/sstabellini/xen-unstable.git
> > > > > > > > staging-4.10-spectre
> > > > > > > 
> > > > > > > The patches below should not be part of spectre nor backport to
> > > > > > > 4.10:
> > > > > > >     - 82e29c87dc7f4f2a7e2f111c3646479da21a910a "ARM: remove
> > > > > > > unneeded
> > > > > > > gic.h
> > > > > > > inclusions"
> > > > > > >     - 79563717c9dd5383abcf0ba94d813de9b42e3793 "xen/arm: psci:
> > > > > > > Prefix
> > > > > > > with
> > > > > > > static any functions not exported"
> > > > > > >     - 6d0e9b21b1f7213c1994cc2d636448ee2d5372c2 "xen/arm: vpsci:
> > > > > > > Update
> > > > > > > the
> > > > > > > return type for MIGRATE_INFO_TYPE"
> > > > > > > 
> > > > > > > The patches below should not be part of spectre but candidate to
> > > > > > > 4.10:
> > > > > > >     - c2d70f77cc7987be164cd87b76459782497fc540 "xen/arm: vpsci:
> > > > > > > Rework
> > > > > > > the logic
> > > > > > > to start AArch32 vCPU in Thumb mode"
> > > > > > > 
> > > > > > > You will also want to backport [1] which address a relaxation of
> > > > > > > the
> > > > > > > ARM_SMCCC_ARCH_WORKAROUND_1.
> > > > > > 
> > > > > > I understand your concerns, in that case could you please provide
> > > > > > the
> > > > > > git branches?
> > > > > 
> > > > > That will have to wait when I have spare cycle. Most likely somewhere
> > > > > in
> > > > > April when I am done from the Xen 4.11 patches and back from holidays.
> > > > > 
> > > > > So It is probably the right time to put into contribution stakeholders
> > > > > who
> > > > > are using those Xen 4.* stable releases.
> > > > 
> > > > To be clear, for Xen 4.10 it is just a matter of dropping the 3 patches
> > > > I
> > > > suggested. There are actually no clash with the current code.
> > > 
> > > Gentle ping. Is there anything blocking to get those patches in Xen 4.10?
> > 
> > Done! Thanks for the ping!
> 
> It looks like the commit 6b270fae7ad462687550a875f714bff18d764416 "xen/arm:
> Relax ARM_SMCCC_ARCH_WORKAROUND_1 discovery" is missing in Xen 4.10.

Well spotted! The commit is missing from all my original backports as
well. I pushed the cherry-pick to staging-4.10, as well as the other
backports in my xen-unstable tree (staging-4.9-spectre

[Xen-devel] [PATCH v6 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

   https://xenbits.xen.org/docs/unstable/misc/pvh.html

This patch enables Qemu to use that same entry point for booting KVM
guests.

Signed-off-by: Maran Wilson 
Suggested-by: Konrad Rzeszutek Wilk 
Suggested-by: Boris Ostrovsky 
Tested-by: Boris Ostrovsky 
---
 arch/x86/Kbuild   |  2 +-
 arch/x86/Kconfig  |  8 
 arch/x86/platform/pvh/Makefile|  4 ++--
 arch/x86/platform/pvh/enlighten.c | 43 +--
 4 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 2089e4414300..c625f57472f7 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,7 +7,7 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
-obj-$(CONFIG_XEN_PVH) += platform/pvh/
+obj-$(CONFIG_PVH) += platform/pvh/
 
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e3b836d7ad09..1e6d83e181b5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -787,6 +787,14 @@ config PVH
  This option enables the PVH entry point for guest virtual machines
  as specified in the x86/HVM direct boot ABI.
 
+config KVM_GUEST_PVH
+   bool "Support for running as a KVM PVH guest"
+   depends on KVM_GUEST
+   select PVH
+   ---help---
+ This option enables starting KVM guests via the PVH entry point as
+ specified in the x86/HVM direct boot ABI.
+
 config KVM_DEBUG_FS
bool "Enable debug information for KVM Guests in debugfs"
depends on KVM_GUEST && DEBUG_FS
diff --git a/arch/x86/platform/pvh/Makefile b/arch/x86/platform/pvh/Makefile
index 9fd25efcd2a3..5dec5067c9fb 100644
--- a/arch/x86/platform/pvh/Makefile
+++ b/arch/x86/platform/pvh/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 OBJECT_FILES_NON_STANDARD_head.o := y
 
-obj-$(CONFIG_XEN_PVH) += enlighten.o
-obj-$(CONFIG_XEN_PVH) += head.o
+obj-$(CONFIG_PVH) += enlighten.o
+obj-$(CONFIG_PVH) += head.o
diff --git a/arch/x86/platform/pvh/enlighten.c 
b/arch/x86/platform/pvh/enlighten.c
index efbceba8db4f..815a09ad625c 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -8,6 +8,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include 
 #include 
 
@@ -40,11 +43,28 @@ void __init __weak mem_map_via_hcall(struct boot_params 
*ptr __maybe_unused)
BUG();
 }
 
-static void __init init_pvh_bootparams(void)
+static void __init init_pvh_bootparams(bool xen_guest)
 {
memset(_bootparams, 0, sizeof(pvh_bootparams));
 
-   mem_map_via_hcall(_bootparams);
+   if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
+   struct hvm_memmap_table_entry *ep;
+   int i;
+
+   ep = __va(pvh_start_info.memmap_paddr);
+   pvh_bootparams.e820_entries = pvh_start_info.memmap_entries;
+
+   for (i = 0; i < pvh_bootparams.e820_entries ; i++, ep++) {
+   pvh_bootparams.e820_table[i].addr = ep->addr;
+   pvh_bootparams.e820_table[i].size = ep->size;
+   pvh_bootparams.e820_table[i].type = ep->type;
+   }
+   } else if (xen_guest) {
+   mem_map_via_hcall(_bootparams);
+   } else {
+   /* Non-xen guests are not supported by version 0 */
+   BUG();
+   }
 
if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
@@ -75,7 +95,7 @@ static void __init init_pvh_bootparams(void)
 * environment (i.e. hardware_subarch 0).
 */
pvh_bootparams.hdr.version = 0x212;
-   pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
+   pvh_bootparams.hdr.type_of_loader = ((xen_guest ? 0x9 : 0xb) << 4) | 0;
 
x86_init.acpi.get_root_pointer = pvh_get_root_pointer;
 }
@@ -90,13 +110,10 @@ void __init __weak xen_pvh_init(void)
BUG();
 }
 
-/*
- * When we add support for other hypervisors like Qemu/KVM, this routine can
- * selectively invoke the appropriate initialization based on guest type.
- */
-static void hypervisor_specific_init(void)
+static void hypervisor_specific_init(bool xen_guest)
 {
-   xen_pvh_init();
+   if (xen_guest)
+   xen_pvh_init();
 }
 
 /*
@@ -105,13 +122,17 @@ static void hypervisor_specific_init(void)
  */
 

[Xen-devel] [PATCH v6 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.

Signed-off-by: Maran Wilson 
---
 include/xen/interface/hvm/start_info.h | 63 +-
 1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/include/xen/interface/hvm/start_info.h 
b/include/xen/interface/hvm/start_info.h
index 648415976ead..50af9ea2ff1e 100644
--- a/include/xen/interface/hvm/start_info.h
+++ b/include/xen/interface/hvm/start_info.h
@@ -33,7 +33,7 @@
  *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
  *|| ("xEn3" with the 0x80 bit of the "E" set).
  *  4 ++
- *| version| Version of this structure. Current version is 0. New
+ *| version| Version of this structure. Current version is 1. New
  *|| versions are guaranteed to be backwards-compatible.
  *  8 ++
  *| flags  | SIF_xxx flags.
@@ -48,6 +48,15 @@
  * 32 ++
  *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
  * 40 ++
+ *| memmap_paddr   | Physical address of the (optional) memory map. Only
+ *|| present in version 1 and newer of the structure.
+ * 48 ++
+ *| memmap_entries | Number of entries in the memory map table. Zero
+ *|| if there is no memory map being provided. Only
+ *|| present in version 1 and newer of the structure.
+ * 52 ++
+ *| reserved   | Version 1 and newer only.
+ * 56 ++
  *
  * The layout of each entry in the module structure is the following:
  *
@@ -62,13 +71,51 @@
  *| reserved   |
  * 32 ++
  *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest. See XEN_HVM_MEMMAP_TYPE_* values below.
+ * 20 +|
+ *| reserved   |
+ * 24 ++
+ *
  * The address and sizes are always a 64bit little endian unsigned integer.
  *
  * NB: Xen on x86 will always try to place all the data below the 4GiB
  * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:  Initial implementation.
+ *
+ * Version 1:  Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of the hvm_start_info struct. These new
+ * fields can be used to pass a memory map to the guest. The
+ * memory map is optional and so guests that understand version 1
+ * of the structure must check that memmap_entries is non-zero
+ * before trying to read the memory map.
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
+/*
+ * The values used in the type field of the memory map table entries are
+ * defined below and match the Address Range Types as defined in the "System
+ * Address Map Interfaces" section of the ACPI Specification. Please refer to
+ * section 15 in version 6.2 of the ACPI spec: http://uefi.org/specifications
+ */
+#define XEN_HVM_MEMMAP_TYPE_RAM   1
+#define XEN_HVM_MEMMAP_TYPE_RESERVED  2
+#define XEN_HVM_MEMMAP_TYPE_ACPI  3
+#define XEN_HVM_MEMMAP_TYPE_NVS   4
+#define XEN_HVM_MEMMAP_TYPE_UNUSABLE  5
+#define XEN_HVM_MEMMAP_TYPE_DISABLED  6
+#define XEN_HVM_MEMMAP_TYPE_PMEM  7
+
 /*
  * C representation of the x86/HVM start info layout.
  *
@@ -86,6 +133,13 @@ struct hvm_start_info {
 uint64_t cmdline_paddr; /* Physical address of the command line. */
 uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
 /* structure.*/
+/* All following fields only present in version 1 and newer */
+uint64_t memmap_paddr;  /* Physical address of an array of   */
+/* hvm_memmap_table_entry.   */
+uint32_t memmap_entries;/* Number of entries in the memmap table.*/
+/* Value will be zero if there is no memory  */
+/* map being provided.   */
+uint32_t reserved;  /* Must be zero. */
 };
 
 struct hvm_modlist_entry {
@@ -95,4 +149,11 @@ struct hvm_modlist_entry {
 uint64_t reserved;
 };
 
+struct hvm_memmap_table_entry {
+uint64_t addr;  /* Base address of the memory region */
+

[Xen-devel] [PATCH v6 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common file

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests. Moving it out of the common file
is going to allow us to compile kernels in the future without CONFIG_XEN
that are still capable of being booted as a Qemu/KVM guest via the PVH
entry point.

Signed-off-by: Maran Wilson 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Juergen Gross 
---
 arch/x86/platform/pvh/enlighten.c | 28 
 arch/x86/xen/enlighten_pvh.c  | 18 +-
 2 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/arch/x86/platform/pvh/enlighten.c 
b/arch/x86/platform/pvh/enlighten.c
index 74ff1c3d2789..edcff7de0529 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -80,26 +80,38 @@ static void __init init_pvh_bootparams(void)
x86_init.acpi.get_root_pointer = pvh_get_root_pointer;
 }
 
+/*
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide the required override for this routine.
+ */
+void __init __weak xen_pvh_init(void)
+{
+   xen_raw_printk("Error: Missing xen PVH initialization\n");
+   BUG();
+}
+
+/*
+ * When we add support for other hypervisors like Qemu/KVM, this routine can
+ * selectively invoke the appropriate initialization based on guest type.
+ */
+static void hypervisor_specific_init(void)
+{
+   xen_pvh_init();
+}
+
 /*
  * This routine (and those that it might call) should not use
  * anything that lives in .bss since that segment will be cleared later.
  */
 void __init xen_prepare_pvh(void)
 {
-   u32 msr;
-   u64 pfn;
-
if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
pvh_start_info.magic);
BUG();
}
 
-   xen_pvh = 1;
-
-   msr = cpuid_ebx(xen_cpuid_base() + 2);
-   pfn = __pa(hypercall_page);
-   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+   hypervisor_specific_init();
 
init_pvh_bootparams();
 }
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index c5409c1f259f..08fc63d14ae5 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,4 +1,9 @@
-#include 
+#include 
+
+#include 
+
+#include 
+#include 
 
 /*
  * PVH variables.
@@ -8,3 +13,14 @@
  */
 bool xen_pvh __attribute__((section(".data"))) = 0;
 
+void __init xen_pvh_init(void)
+{
+   u32 msr;
+   u64 pfn;
+
+   xen_pvh = 1;
+
+   msr = cpuid_ebx(xen_cpuid_base() + 2);
+   pfn = __pa(hypercall_page);
+   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+}
-- 
2.16.1


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

[Xen-devel] [PATCH v6 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other hypervisors like Qemu/KVM,
a new mechanism will be added that allows the guest to get the memory
map without needing to use hypercalls.

For Xen guests, the hypercall approach will still be supported. In
preparation for adding support for other hypervisors, we can move the
code that uses hypercalls into the Xen specific file. This will allow us
to compile kernels in the future without CONFIG_XEN that are still capable
of being booted as a Qemu/KVM guest via the PVH entry point.

Signed-off-by: Maran Wilson 
Reviewed-by: Juergen Gross 
---
 arch/x86/platform/pvh/enlighten.c | 28 ++--
 arch/x86/xen/enlighten_pvh.c  | 20 
 2 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/arch/x86/platform/pvh/enlighten.c 
b/arch/x86/platform/pvh/enlighten.c
index edcff7de0529..efbceba8db4f 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -8,9 +8,6 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #include 
 #include 
 
@@ -30,21 +27,24 @@ static u64 pvh_get_root_pointer(void)
return pvh_start_info.rsdp_paddr;
 }
 
+/*
+ * Xen guests are able to obtain the memory map from the hypervisor via the
+ * HYPERVISOR_memory_op hypercall.
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide an override for this routine to do
+ * just that.
+ */
+void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
+{
+   xen_raw_printk("Error: Could not find memory map\n");
+   BUG();
+}
+
 static void __init init_pvh_bootparams(void)
 {
-   struct xen_memory_map memmap;
-   int rc;
-
memset(_bootparams, 0, sizeof(pvh_bootparams));
 
-   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
-   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
-   rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
-   if (rc) {
-   xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
-   BUG();
-   }
-   pvh_bootparams.e820_entries = memmap.nr_entries;
+   mem_map_via_hcall(_bootparams);
 
if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 08fc63d14ae5..00658d4bc4f4 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,10 +1,15 @@
 #include 
 
+#include 
+
 #include 
+#include 
 
 #include 
 #include 
 
+#include 
+
 /*
  * PVH variables.
  *
@@ -24,3 +29,18 @@ void __init xen_pvh_init(void)
pfn = __pa(hypercall_page);
wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
 }
+
+void __init mem_map_via_hcall(struct boot_params *boot_params_p)
+{
+   struct xen_memory_map memmap;
+   int rc;
+
+   memmap.nr_entries = ARRAY_SIZE(boot_params_p->e820_table);
+   set_xen_guest_handle(memmap.buffer, boot_params_p->e820_table);
+   rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
+   if (rc) {
+   xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
+   BUG();
+   }
+   boot_params_p->e820_entries = memmap.nr_entries;
+}
-- 
2.16.1


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

[Xen-devel] [PATCH v6 3/7] xen/pvh: Create a new file for Xen specific PVH code

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The first step in that direction is to create a new file that will
eventually hold the Xen specific routines.

Signed-off-by: Maran Wilson 
---
 arch/x86/platform/pvh/enlighten.c |  5 ++---
 arch/x86/xen/Makefile |  1 +
 arch/x86/xen/enlighten_pvh.c  | 10 ++
 3 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/xen/enlighten_pvh.c

diff --git a/arch/x86/platform/pvh/enlighten.c 
b/arch/x86/platform/pvh/enlighten.c
index aa1c6a6831a9..74ff1c3d2789 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -17,10 +17,9 @@
 /*
  * PVH variables.
  *
- * xen_pvh pvh_bootparams and pvh_start_info need to live in data segment
- * since they are used after startup_{32|64}, which clear .bss, are invoked.
+ * pvh_bootparams and pvh_start_info need to live in the data segment since
+ * they are used after startup_{32|64}, which clear .bss, are invoked.
  */
-bool xen_pvh __attribute__((section(".data"))) = 0;
 struct boot_params pvh_bootparams __attribute__((section(".data")));
 struct hvm_start_info pvh_start_info __attribute__((section(".data")));
 
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index f1b850607212..ae5c6f1f0fe0 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -20,6 +20,7 @@ obj-y := enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
 obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o \
p2m.o enlighten_pv.o mmu_pv.o
+obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
new file mode 100644
index ..c5409c1f259f
--- /dev/null
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -0,0 +1,10 @@
+#include 
+
+/*
+ * PVH variables.
+ *
+ * The variable xen_pvh needs to live in the data segment since it is used
+ * after startup_{32|64} is invoked, which will clear the .bss segment.
+ */
+bool xen_pvh __attribute__((section(".data"))) = 0;
+
-- 
2.16.1


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

[Xen-devel] [PATCH v6 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Maran Wilson]

Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files sitting at a higher level in the tree.

This patch is not introducing any code or functional changes, just moving
files from one location to another.

Signed-off-by: Maran Wilson 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 MAINTAINERS| 1 +
 arch/x86/Kbuild| 2 ++
 arch/x86/platform/pvh/Makefile | 5 +
 arch/x86/{xen/enlighten_pvh.c => platform/pvh/enlighten.c} | 0
 arch/x86/{xen/xen-pvh.S => platform/pvh/head.S}| 0
 arch/x86/xen/Makefile  | 3 ---
 6 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/platform/pvh/Makefile
 rename arch/x86/{xen/enlighten_pvh.c => platform/pvh/enlighten.c} (100%)
 rename arch/x86/{xen/xen-pvh.S => platform/pvh/head.S} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 65ab509e4a42..52afae73beab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15189,6 +15189,7 @@ L:  xen-devel@lists.xenproject.org (moderated for 
non-subscribers)
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
 S: Supported
 F: arch/x86/xen/
+F: arch/x86/platform/pvh/
 F: drivers/*/xen-*front.c
 F: drivers/xen/
 F: arch/x86/include/asm/xen/
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 0038a2d10a7a..2089e4414300 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,6 +7,8 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
+obj-$(CONFIG_XEN_PVH) += platform/pvh/
+
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
 
diff --git a/arch/x86/platform/pvh/Makefile b/arch/x86/platform/pvh/Makefile
new file mode 100644
index ..9fd25efcd2a3
--- /dev/null
+++ b/arch/x86/platform/pvh/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+OBJECT_FILES_NON_STANDARD_head.o := y
+
+obj-$(CONFIG_XEN_PVH) += enlighten.o
+obj-$(CONFIG_XEN_PVH) += head.o
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/platform/pvh/enlighten.c
similarity index 100%
rename from arch/x86/xen/enlighten_pvh.c
rename to arch/x86/platform/pvh/enlighten.c
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/platform/pvh/head.S
similarity index 100%
rename from arch/x86/xen/xen-pvh.S
rename to arch/x86/platform/pvh/head.S
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index d83cb5478f54..f1b850607212 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -1,6 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 OBJECT_FILES_NON_STANDARD_xen-asm_$(BITS).o := y
-OBJECT_FILES_NON_STANDARD_xen-pvh.o := y
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not profile debug and lowlevel utilities
@@ -21,7 +20,6 @@ obj-y := enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
 obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o \
p2m.o enlighten_pv.o mmu_pv.o
-obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
@@ -33,4 +31,3 @@ obj-$(CONFIG_XEN_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_XEN_DOM0) += vga.o
 obj-$(CONFIG_SWIOTLB_XEN)  += pci-swiotlb-xen.o
 obj-$(CONFIG_XEN_EFI)  += efi.o
-obj-$(CONFIG_XEN_PVH)  += xen-pvh.o
-- 
2.16.1


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

[Xen-devel] [PATCH v6 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

In order to pave the way for hypervisors other than Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from CONFIG_XEN.

Signed-off-by: Maran Wilson 
---
 arch/x86/Kconfig  | 6 ++
 arch/x86/kernel/head_64.S | 2 +-
 arch/x86/xen/Kconfig  | 3 ++-
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 27fede438959..e3b836d7ad09 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -781,6 +781,12 @@ config KVM_GUEST
  underlying device model, the host provides the guest with
  timing infrastructure such as time of day, and system time
 
+config PVH
+   bool "Support for running PVH guests"
+   ---help---
+ This option enables the PVH entry point for guest virtual machines
+ as specified in the x86/HVM direct boot ABI.
+
 config KVM_DEBUG_FS
bool "Enable debug information for KVM Guests in debugfs"
depends on KVM_GUEST && DEBUG_FS
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 48385c1074a5..d83f2b110b47 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -385,7 +385,7 @@ NEXT_PAGE(early_dynamic_pgts)
 
.data
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 NEXT_PGD_PAGE(init_top_pgt)
.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
.orginit_top_pgt + L4_PAGE_OFFSET*8, 0
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index c1f98f32c45f..5fccee76f44d 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -74,6 +74,7 @@ config XEN_DEBUG_FS
  Enabling this option may incur a significant performance overhead.
 
 config XEN_PVH
-   bool "Support for running as a PVH guest"
+   bool "Support for running as a Xen PVH guest"
depends on XEN && XEN_PVHVM && ACPI
+   select PVH
def_bool n
-- 
2.16.1


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

[Xen-devel] [PATCH v6 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

   https://xenbits.xen.org/docs/unstable/misc/pvh.html

This patch series would enable Qemu to use that same entry point for
booting KVM guests.

Changes from v5:

 * The interface changes to the x86/HVM start info layout have
   now been accepted into the Xen tree.
 * Rebase and merge upstream PVH file changes.
 * (Patch 6) Synced up to the final version of the header file that was
 acked and pulled into the Xen tree.
 * (Patch 1) Fixed typo and removed redundant "def_bool n" line.

Changes from v4:

Note: I've withheld Juergen's earlier "Reviewed-by" tags from patches
1 and 7 since there were minor changes (mostly just addition of
CONFIG_KVM_GUEST_PVH as requested) that came afterwards.

 * Changed subject prefix from RFC to PATCH
 * Added CONFIG_KVM_GUEST_PVH as suggested
 * Relocated the PVH common files to
   arch/x86/platform/pvh/{enlighten.c,head.S}
 * Realized I also needed to move the objtool override for those files
 * Updated a few code comments per reviewer feedback
 * Sent out a patch of the hvm_start_info struct changes against the Xen
   tree since that is the canonical copy of the header. Discussions on
   that thread have resulted in some (non-functional) updates to
   start_info.h (patch 6/7) and those changes are reflected here as well
   in order to keep the files in sync. The header file has since been
   ack'ed for the Xen tree by Jan Beulich.

Changes from v3:

 * Implemented Juergen's suggestion for refactoring and moving the PVH
   code so that CONFIG_XEN is no longer required for booting KVM guests
   via the PVH entry point.
   Functionally, nothing has changed from V3 really, but the patches
   look completely different now because of all the code movement and
   refactoring. Some of these patches can be combined, but I've left
   them very small in some cases to make the refactoring and code
   movement easier to review.
   My approach for refactoring has been to create a PVH entry layer that
   still has understanding and knowledge about Xen vs non-Xen guest types
   so that it can make run time decisions to handle either case, as
   opposed to going all the way and re-writing it to be a completely
   hypervisor agnostic and architecturally pure layer that is separate
   from guest type details. The latter seemed a bit overkill in this
   situation. And I've handled the complexity of having to support
   Qemu/KVM boot of kernels compiled with or without CONFIG_XEN via a
   pair of xen specific __weak routines that can be overridden in kernels
   that support Xen guests. Importantly, the __weak routines are for
   xen specific code only (not generic "guest type" specific code) so
   there is no clashing between xen version of the strong routine and,
   say, a KVM version of the same routine. But I'm sure there are many
   ways to skin this cat, so I'm open to alternate suggestions if there
   is a compelling reason for not using __weak in this situation.

Changes from v2:

 * All structures (including memory map table entries) are padded and
   aligned to an 8 byte boundary.

 * Removed the "packed" attributes and made changes to comments as
   suggested by Jan.

Changes from v1:

 * Adopted Paolo's suggestion for defining a v2 PVH ABI that includes the
   e820 map instead of using the second module entry to pass the table.

 * Cleaned things up a bit to reduce the number of xen vs non-xen special
   cases.


Maran Wilson (7):
  xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH
  xen/pvh: Move PVH entry code out of Xen specific tree
  xen/pvh: Create a new file for Xen specific PVH code
  xen/pvh: Move Xen specific PVH VM initialization out of common file
  xen/pvh: Move Xen code for getting mem map via hcall out of common
file
  xen/pvh: Add memory map pointer to hvm_start_info struct
  KVM: x86: Allow Qemu/KVM to use PVH entry point

 MAINTAINERS |   1 +
 arch/x86/Kbuild |   2 +
 arch/x86/Kconfig|  14 +++
 arch/x86/kernel/head_64.S   |   2 +-
 arch/x86/platform/pvh/Makefile  |   5 +
 arch/x86/platform/pvh/enlighten.c   | 138 
 arch/x86/{xen/xen-pvh.S => platform/pvh/head.S} |   0
 arch/x86/xen/Kconfig|   3 +-
 arch/x86/xen/Makefile   |   2 -
 arch/x86/xen/enlighten_pvh.c|  94 +++-
 include/xen/interface/hvm/start_info.h  |  63 ++-
 11 files changed, 242 insertions(+), 82 deletions(-)
 create mode 

[Xen-devel] [xen-unstable test] 121749: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  broken
 test-amd64-i386-xl-qemut-win7-amd64 broken
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 121272
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 121272

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt   4 host-install(4)  broken pass in 121721
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 121721 
pass in 121749
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
121721

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  9383de210e747f15d0fd10ade89e35d543fbc4e8
baseline version:
 xen  90eff18cc5e16e0749605d88092ecfa4ab126c8f

Last test of basis   121776  2018-04-04 12:02:04 Z0 days
Testing same since   121791  2018-04-04 15:01:25 Z0 days1 attempts


People who touched revisions under test:
  Petre Pircalabu 
  Razvan Cojocaru 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  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 :

To xenbits.xen.org:/home/xen/git/xen.git
   90eff18cc5..9383de210e  9383de210e747f15d0fd10ade89e35d543fbc4e8 -> smoke

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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[Andre Przywara]

Hi,

On 03/04/18 14:49, Amit Singh Tomar wrote:
> This patch adds driver for UART controller found on Armada 3700 SoC.
> 
> There is no reference manuals available for 3700 SoC in public and it
> is derived by looking at Linux driver[1].
> 
> [1]https://github.com/torvalds/linux/blob/master/drivers/tty/serial/mvebu-uart.c
> 
> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since v1:
> * Addressed Wei Liu's comments
> * Addressed Andre's comments.
> Changes since RFC:
> * Addressed Julien's comments.
> ---
>  xen/drivers/char/Kconfig  |   8 ++
>  xen/drivers/char/Makefile |   1 +
>  xen/drivers/char/mvebu-uart.c | 290 
> ++
>  3 files changed, 299 insertions(+)
>  create mode 100644 xen/drivers/char/mvebu-uart.c
> 
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index fb53dd8..6bf2730 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -12,6 +12,14 @@ config HAS_CADENCE_UART
> This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
> based board, say Y.
>  
> +config HAS_MVEBU
> +bool
> +default y
> +depends on ARM_64
> +help
> +  This selects the Marvell MVEBU UART. if you have an ARMADA 3700
> +  based board, say Y.
> +

This should be *hard* tabs in this file. If you have configured vim to
use soft tabs instead, try :set noexpandtab
For the last two lines use one hard tab and two spaces.

>  config HAS_PL011
>   bool
>   default y
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index 0d48b16..b68c330 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_HAS_NS16550) += ns16550.o
>  obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
>  obj-$(CONFIG_HAS_PL011) += pl011.o
>  obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
> +obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
>  obj-$(CONFIG_HAS_OMAP) += omap-uart.o
>  obj-$(CONFIG_HAS_SCIF) += scif-uart.o
>  obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
> diff --git a/xen/drivers/char/mvebu-uart.c b/xen/drivers/char/mvebu-uart.c
> new file mode 100644
> index 000..b2059f3
> --- /dev/null
> +++ b/xen/drivers/char/mvebu-uart.c
> @@ -0,0 +1,290 @@
> +/*
> + * xen/drivers/char/mvebu3700-uart.c
> + *
> + * Driver for Marvell MVEBU UART.
> + *
> + * Copyright (c) 2018, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets */
> +#define UART_RX_REG 0x00
> +
> +#define UART_TX_REG 0x04
> +
> +#define UART_CTRL_REG   0x08
> +#define CTRL_TXFIFO_RST BIT(15)
> +#define CTRL_RXFIFO_RST BIT(14)
> +#define CTRL_TX_RDY_INT BIT(5)
> +#define CTRL_RX_RDY_INT BIT(4)
> +#define CTRL_BRK_DET_INTBIT(3)
> +#define CTRL_FRM_ERR_INTBIT(2)
> +#define CTRL_PAR_ERR_INTBIT(1)
> +#define CTRL_OVR_ERR_INTBIT(0)
> +#define CTRL_RX_INT (CTRL_BRK_DET_INT | CTRL_FRM_ERR_INT | \
> + CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)

that should be CTRL_ERR_INT

> +
> +#define UART_STATUS_REG 0x0c
> +#define STATUS_TXFIFO_EMP   BIT(13)
> +#define STATUS_TX_RDY   BIT(5)
> +#define STATUS_RX_RDY   BIT(4)
> +#define STATUS_BRK_DET  BIT(3)
> +#define STATUS_FRM_ERR  BIT(2)
> +#define STATUS_PAR_ERR  BIT(1)
> +#define STATUS_OVR_ERR  BIT(0)
> +#define STATUS_BRK_ERR  (STATUS_BRK_DET | STATUS_FRM_ERR | \
> +STATUS_PAR_ERR | STATUS_OVR_ERR)
> +
> +#define TX_FIFO_SIZE32
> +
> +static struct mvebu3700_uart {
> +unsigned int irq;
> +void __iomem *regs;
> +struct irqaction irqaction;
> +struct vuart_info vuart;
> +} mvebu3700_com = {0};
> +
> +#define mvebu3700_read(uart, off)   readl((uart)->regs + off)
> +#define mvebu3700_write(uart, off, val) writel(val, (uart->regs) + off)
> +
> +static void mvebu3700_uart_interrupt(int irq, void *data,
> + struct cpu_user_regs *regs)
> +{
> +struct serial_port *port = data;
> +struct mvebu3700_uart *uart = port->uart;
> +

Re: [Xen-devel] [PATCH v3] libxl: add libxl_domain_suspend_only to simply suspend a domain, without saving it

[Wei Liu]

On Wed, Apr 04, 2018 at 07:01:12PM +0200, Marek Marczykowski-Górecki wrote:
> Similar functionality to libxl_domain_suspend(), but do not save domains
> state to any file. Only suspend the domain and keep it in suspended
> shutdown state (do not destroy it). Such domain can be later woken up
> with libxl_domain_resume. The main reason for this functionality is to
> suspend the host while some domains are running, potentially holding PCI
> devices. This will give a chance to a driver in such a domain to
> properly suspend the device.
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> Signed-off-by: Marcus of Wetware Labs 


Acked-by: Wei Liu 

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

[Xen-devel] Problem with Xen 4.7.5

[Ian Jackson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We have discovered a bug in Xen 4.7.5 (related to shadow paging).
This bug is a new regression compared to 4.7.4 and does not affect
other Xen releases.

We are investigating the problem.  For now, we recommend that users of
4.7.x do not upgrade to 4.7.5.

Apologies for the inconvenience.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaxQnmAAoJEIP+FMlX6CvZhLwIAIPMOX75gmmJC9OAmgdTQ5dD
Lf99hXTg9EPENIWRy/UuHTqXLC5QiNLY5a5vWISsdzo2QAX7TpxcVmNNqOFLbCxX
D+2fjMlK7ZCvNyi+/hvRt5IAlEdA1MVGAiRzmwFUYBmf4CBJjkAVk1agyUhw4Umh
UaXCT9j1ZSVUgVsULG18/sFzU6r+8DEgqZa1Kgo4DuPRUgvt/jBw1iEpVBWYZJrv
n77ok1rMQoa3RU03hj2Np9Dli7ToV1gHcgzmExfFtML9/ptMjRC5kbk+ObxmABI9
pZamW2JNO6tozOfA/TEQocQHypz3LY3zBBK52CCSzS9X3vXtjaPvj4qlvhTQBPU=
=S8di
-END PGP SIGNATURE-

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

[Xen-devel] [PATCH v3] libxl: add libxl_domain_suspend_only to simply suspend a domain, without saving it

[Marek Marczykowski-Górecki]

Similar functionality to libxl_domain_suspend(), but do not save domains
state to any file. Only suspend the domain and keep it in suspended
shutdown state (do not destroy it). Such domain can be later woken up
with libxl_domain_resume. The main reason for this functionality is to
suspend the host while some domains are running, potentially holding PCI
devices. This will give a chance to a driver in such a domain to
properly suspend the device.

Signed-off-by: Marek Marczykowski-Górecki 
Signed-off-by: Marcus of Wetware Labs 

---
Changes in v3:
 - unbundle functionality to separate libxl_domain_suspend_only function
 - changed title from "libxl: allow libxl_domain_suspend to simply
   suspend a domain, without saving it"
Changes in v2:
 - drop double initialization of dsps fields (libxl__domain_suspend_init
   is called)
 - use LIBXL_SUSPEND_NO_SAVE flag instead of fd=-1
---
 tools/libxl/libxl.h| 16 
 tools/libxl/libxl_domain.c | 34 ++
 2 files changed, 50 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index eca0ea2c50..8936e742eb 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -832,6 +832,14 @@ typedef struct libxl__ctx libxl_ctx;
 #endif
 
 /*
+ * LIBXL_HAVE_DOMAIN_SUSPEND_ONLY
+ *
+ * If this is defined, function libxl_domains_suspend_only() is available.
+ */
+
+#define LIBXL_HAVE_DOMAIN_SUSPEND_ONLY 1
+
+/*
  * LIBXL_HAVE_DEVICE_PCI_SEIZE
  *
  * If this is defined, then the libxl_device_pci struct will contain
@@ -1470,6 +1478,14 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, 
int fd,
 #define LIBXL_SUSPEND_DEBUG 1
 #define LIBXL_SUSPEND_LIVE 2
 
+/*
+ * Only suspend domain, do not save its state to file, do not destroy it.
+ * Suspended domain can be resumed with libxl_domain_resume()
+ */
+int libxl_domain_suspend_only(libxl_ctx *ctx, uint32_t domid,
+ const libxl_asyncop_how *ao_how)
+ LIBXL_EXTERNAL_CALLERS_ONLY;
+
 /* @param suspend_cancel [from xenctrl.h:xc_domain_resume( @param fast )]
  *   If this parameter is true, use co-operative resume. The guest
  *   must support this.
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 13b1c73d40..533bcdf240 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -523,6 +523,40 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, 
int fd, int flags,
 return AO_CREATE_FAIL(rc);
 }
 
+static void domain_suspend_empty_cb(libxl__egc *egc,
+  libxl__domain_suspend_state *dss, int rc)
+{
+STATE_AO_GC(dss->ao);
+libxl__ao_complete(egc,ao,rc);
+}
+
+int libxl_domain_suspend_only(libxl_ctx *ctx, uint32_t domid,
+  const libxl_asyncop_how *ao_how)
+{
+AO_CREATE(ctx, domid, ao_how);
+libxl__domain_suspend_state *dsps;
+int rc;
+
+libxl_domain_type type = libxl__domain_type(gc, domid);
+if (type == LIBXL_DOMAIN_TYPE_INVALID) {
+rc = ERROR_FAIL;
+goto out_err;
+}
+
+GCNEW(dsps);
+dsps->ao = ao;
+dsps->domid = domid;
+dsps->type = type;
+rc = libxl__domain_suspend_init(egc, dsps, type);
+if (rc < 0) goto out_err;
+dsps->callback_common_done = domain_suspend_empty_cb;
+libxl__domain_suspend(egc, dsps);
+return AO_INPROGRESS;
+
+ out_err:
+return AO_CREATE_FAIL(rc);
+}
+
 int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid)
 {
 int ret;
-- 
2.13.6


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  086cad25a948e54cf84319f94c1799cbcf6b4d97
baseline version:
 xtf  067488fa25621c6a566e2f555fcb5a1088f7abb7

Last test of basis   120303  2018-03-07 12:13:30 Z   28 days
Testing same since   121750  2018-04-03 18:31:58 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 :

To xenbits.xen.org:/home/xen/git/xtf.git
   067488f..086cad2  086cad25a948e54cf84319f94c1799cbcf6b4d97 -> 
xen-tested-master

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

[Xen-devel] [xen-4.6-testing test] 121744: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
119227

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 121420 pass 
in 121744
 test-armhf-armhf-xl-credit2  12 guest-start  fail in 121720 pass in 121744
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 121720 
pass in 121744
 test-armhf-armhf-xl-rtds  6 xen-install  fail in 121720 pass in 121744
 test-xtf-amd64-amd64-1   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 121420
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 121420
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 121720
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail pass in 121720

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 121420 like 
119187
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 121420 like 
119227
 test-armhf-armhf-xl-rtds 12 guest-start fail in 121420 like 119227
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 119187
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119227
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119227
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119227
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119227
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119227
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119227
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119227
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119227
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119227
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 

Re: [Xen-devel] Patches for stable

[Juergen Gross]

On 04/04/18 17:42, Greg KH wrote:
> On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote:
>> On 04/04/18 16:46, Greg KH wrote:
>>> On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
 On 04/04/18 16:27, Greg KH wrote:
> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
>> Please add the patches:
>>
>> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
>> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
>> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
>>
>> to the 4.15 and 4.16 stable kernels.
>>
>> Those patches are needed to boot Linux as PVH guest on recent Xen.
>
> So a new feature?  Why is that ok for stable kernels?

 It works for kernels since at least 4.11 on Xen 4.10.
>>>
>>> Great, so what commit caused this to fail?
>>>
>>> So far, in reading those commits, it sounds like they are "make Linux
>>> work again due to changes in Xen".  That sounds like a pretty bad thing
>>> that Xen did, why do we have to fix up their mess?
>>
>> Xen did nothing bad. It was the "old" kernel implementation which relied
>> on an assumption which happened to be true by accident. Xen had to be
>> changed in order to enable grub2 to support PVH mode.
>>
>> The PVH interface specifies that the RSDP address is available via the
>> start_info structure handed over to the PVH boot entry. The Linux kernel
>> didn't look at that address, but used the legacy method scanning low
>> memory for the RSDP table. As soon as Xen moved the RSDP to a higher
>> address (which is covered by the PVH interface specification) the kernel
>> could no longer be booted.
>>
>> So it was clearly a fault of the kernel not complying to the PVH
>> specification.
> 
> But it worked previously, so you can't fault Linux here :)
> 
> How many other operating systems broke with this change?

None.

BSD did it correctly. I guess Mini-OS doesn't count, as it is mostly
Xen-internal, but it was not hit by this change.

> Not at all.  We have a working kernel here.  Xen changed and broke
> working Linux systems.  Now I understand the goal of wanting to also
> change Linux to work properly, but these changes are really a new
> feature addition if you read the patches.

We have a working kernel just by luck. Would your reasoning be the same
if the kernel would use an EFI runtime service wrong and an EFI update
would lead to a crash?

> So why can't Xen just tell all Linux users to update to a more modern
> kernel, i.e. 4.17.y and newer, in order to run with the new Xen kernel
> if they want to enforce this previously working behavior?  Why does
> Linux have to be the one to change here?

I wanted to have those patches in 4.15, but problems with grub2 (not the
upstream version, but multiple distro versions) and the Meltdown/Spectre
desaster pushed them back to 4.17.


Juergen

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

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[Chao Gao]

On Wed, Apr 04, 2018 at 04:45:32PM +0100, Roger Pau Monné wrote:
>On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>> ... the same page with other registers which are not relevant to MSI-X. Xen
>> marks pages where PBA resides as read-only. When assigning such devices to
>> guest, device driver writes MSI-X irrelevant registers on those pages would
>> lead to an EPT violation and the guest is destroyed because no handler is
>> registered for those address range. In order to make guest capable to use 
>> such
>> kind of devices, trapping very frequent write accesses is not a good idea for
>> it would significantly impact the performance.
>> 
>> This patch provides a workaround with caveat. Specifically, an option is
>> introduced to specify a list of devices. For those devices, Xen doesn't
>> control the access right to pages where PBA resides. Hence, guest device
>> driver is able to write those pages and functions well. Note that adding an
>> untrusted device to this option may endanger security of the entire system.
>
>This is a clear violation of the MSI-X spec. Out of curiosity, which

Yes, that's why we have this patch -- to workaround a hardware issue.

>device is it that places random registers in the same page as the PBA?

According to the commit [1], Mellanox MT27500 series, ConnectX-3 VF.
And, a generation of Intel's Omni-Path.

[1]:https://git.qemu.org/?p=qemu.git;a=commit;h=95239e162518dc6577164be3d9a789aba7f591a3

Could you help to give some comments? :).

Thanks
Chao

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

Re: [Xen-devel] [PATCH v2] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

[Ian Jackson]

Marek Marczykowski-Górecki writes ("Re: [PATCH v2] libxl: allow 
libxl_domain_suspend to simply suspend a domain, without saving it"):
> Fine with me too.
> 
> Should I add also #define HAVE_DOMAIN_SUSPEND_ONLY or such?

Yes.

Thanks, and sorry to quibble about these kind of details.

Ian.

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

Re: [Xen-devel] [PATCH v2 2/2] xen/arm: Add Marvell ARMADA 3700 early printk support

[Andre Przywara]

Hi,

one more thing ...

On 04/04/18 16:34, Andre Przywara wrote:
> Hi,
> 
> On 03/04/18 14:49, Amit Singh Tomar wrote:



>> diff --git a/xen/arch/arm/arm64/debug-mvebu.inc 
>> b/xen/arch/arm/arm64/debug-mvebu.inc
>> new file mode 100644
>> index 000..ac48889
>> --- /dev/null
>> +++ b/xen/arch/arm/arm64/debug-mvebu.inc
>> @@ -0,0 +1,50 @@
>> +/*
>> + * xen/drivers/char/mvebu3700-uart.c

This is not the file name.

>> + *
>> + * Driver for Marvell MVEBU UART.

and this should read: "Marvell MVEBU UART specific debug code"

Cheers,
Andre.

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

Re: [Xen-devel] [PATCH v2] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

[Marek Marczykowski-Górecki]

On Wed, Apr 04, 2018 at 04:45:51PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Re: [PATCH v2] libxl: allow 
> libxl_domain_suspend to simply suspend a domain, without saving it"):
> > On Wed, Mar 28, 2018 at 12:20:25PM +0100, Ian Jackson wrote:
> > > I agree that libxl_domain_suspend is an unfortunate name, but can't we
> > > come up with an alternative new name ?  It does seem odd to bundle
> > > this into _save.
> > 
> > libxl_domain_just_suspend ?
> 
> How about libxl_domain_suspend_only ?

Fine with me too.

Should I add also #define HAVE_DOMAIN_SUSPEND_ONLY or such?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 6/7] add mspin_sleep function to time manager

[Pawel Wieczorkiewicz]

From: Paul Semel 

Signed-off-by: Paul Semel 

cr https://code.amazon.com/reviews/CR-786227
---
 common/time.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/common/time.c b/common/time.c
index 6aa1648..7577694 100644
--- a/common/time.c
+++ b/common/time.c
@@ -138,6 +138,20 @@ static inline void spin_sleep(uint64_t t)
 nspin_sleep(nsec);
 }
 
+#if defined(__i386__)
+static inline void mspin_sleep(uint32_t t)
+#else
+static inline void mspin_sleep(uint64_t t)
+#endif
+{
+#if defined(__i386__)
+uint32_t nsec = t * 100;
+#else
+uint64_t nsec = t * 100ul;
+#endif
+nspin_sleep(nsec);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.16.2

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


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

[Xen-devel] [PATCH 2/7] add current_time function to time manager

[Pawel Wieczorkiewicz]

From: Paul Semel 

this function returns the "epoch" time

Signed-off-by: Paul Semel 

cr https://code.amazon.com/reviews/CR-786224
---
 common/time.c  | 16 
 include/xtf/time.h |  4 
 2 files changed, 20 insertions(+)

diff --git a/common/time.c b/common/time.c
index 11ac168..37a9faf 100644
--- a/common/time.c
+++ b/common/time.c
@@ -76,6 +76,22 @@ uint64_t since_boot_time(void)
 return system_time;
 }
 
+/* This function return the epoch time (number of seconds elapsed
+ * since Juanary 1, 1970) */
+#if defined(__i386__)
+uint32_t current_time(void)
+#else
+uint64_t current_time(void)
+#endif
+{
+#if defined(__i386__)
+uint32_t seconds = shared_info.wc_sec;
+#else
+uint64_t seconds = ((uint64_t)shared_info.wc_sec_hi << 32) | 
shared_info.wc_sec;
+#endif
+return seconds + (since_boot_time() / 10);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index 15cbd48..a8c10eb 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -18,8 +18,12 @@
 #if defined(__i386__)
 /* Time from boot in nanoseconds */
 uint32_t since_boot_time(void);
+
+uint32_t current_time(void);
 #else
 uint64_t since_boot_time(void);
+
+uint64_t current_time(void);
 #endif
 
 #endif /* XTF_TIME_H */
-- 
2.16.2

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


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

[Xen-devel] [PATCH 3/7] add gettimeofday function to time managment

[Pawel Wieczorkiewicz]

From: Paul Semel 

Signed-off-by: Paul Semel 

cr https://code.amazon.com/reviews/CR-786225
---
 common/time.c  | 14 ++
 include/xtf/time.h | 12 
 2 files changed, 26 insertions(+)

diff --git a/common/time.c b/common/time.c
index 37a9faf..c80bc11 100644
--- a/common/time.c
+++ b/common/time.c
@@ -92,6 +92,20 @@ uint64_t current_time(void)
 return seconds + (since_boot_time() / 10);
 }
 
+/* The POSIX gettimeofday syscall normally takes a second argument, which is
+ * the timezone (struct timezone). However, it sould be NULL because linux
+ * doesn't use it anymore. So we need for us to add it in this function
+ */
+int gettimeofday(struct timeval *tp)
+{
+if (!tp)
+return -1;
+
+tp->sec = current_time();
+tp->nsec = shared_info.wc_nsec + (since_boot_time() % 10);
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index a8c10eb..16356eb 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -8,6 +8,16 @@
 
 #include 
 
+struct timeval {
+#if !defined(__i386__)
+uint64_t sec;
+uint64_t nsec;
+#else
+uint32_t sec;
+uint32_t nsec;
+#endif
+};
+
 #define rdtscp(tsc) {\
 uint32_t lo, hi;\
 __asm__ volatile("rdtsc": "=a"(lo), "=d"(hi));\
@@ -26,6 +36,8 @@ uint64_t since_boot_time(void);
 uint64_t current_time(void);
 #endif
 
+int gettimeofday(struct timeval *tp);
+
 #endif /* XTF_TIME_H */
 
 /*
-- 
2.16.2

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


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

[Xen-devel] [PATCH 4/7] add nspin_sleep function to time manager

[Pawel Wieczorkiewicz]

From: Paul Semel 

Signed-off-by: Paul Semel 

cr https://code.amazon.com/reviews/CR-836539
---
 common/time.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/common/time.c b/common/time.c
index c80bc11..db28d78 100644
--- a/common/time.c
+++ b/common/time.c
@@ -106,6 +106,24 @@ int gettimeofday(struct timeval *tp)
 return 0;
 }
 
+#if defined(__i386__)
+static inline void nspin_sleep(uint32_t t)
+#else
+static inline void nspin_sleep(uint64_t t)
+#endif
+{
+#if defined(__i386__)
+uint32_t curr = since_boot_time();
+uint32_t end = curr + t;
+#else
+uint64_t curr = since_boot_time();
+uint64_t end = curr + t;
+#endif
+
+while ( curr < end )
+curr = since_boot_time();
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.16.2

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


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

[Xen-devel] [PATCH 1/7] introduce time managment in xtf

[Pawel Wieczorkiewicz]

From: Paul Semel 

this file is introduce to be able to implement an inter domain
communication protocol over xenstore. For synchronization purpose, we do
really want to be able to "control" time

common/time.c: since_boot_time gets the time in nanoseconds from the
moment the VM has booted

Signed-off-by: Paul Semel 

cr https://code.amazon.com/reviews/CR-786223
---
 build/files.mk |  1 +
 common/time.c  | 87 ++
 include/xtf/time.h | 35 ++
 3 files changed, 123 insertions(+)
 create mode 100644 common/time.c
 create mode 100644 include/xtf/time.h

diff --git a/build/files.mk b/build/files.mk
index 46b42d6..55ed1ca 100644
--- a/build/files.mk
+++ b/build/files.mk
@@ -16,6 +16,7 @@ obj-perarch += $(ROOT)/common/libc/vsnprintf.o
 obj-perarch += $(ROOT)/common/report.o
 obj-perarch += $(ROOT)/common/setup.o
 obj-perarch += $(ROOT)/common/xenbus.o
+obj-perarch += $(ROOT)/common/time.o
 
 obj-perenv += $(ROOT)/arch/x86/decode.o
 obj-perenv += $(ROOT)/arch/x86/desc.o
diff --git a/common/time.c b/common/time.c
new file mode 100644
index 000..11ac168
--- /dev/null
+++ b/common/time.c
@@ -0,0 +1,87 @@
+#include 
+#include 
+#include 
+
+/* This function was taken from mini-os source code */
+/* It returns ((delta << shift) * mul_frac) >> 32 */
+static inline uint64_t scale_delta(uint64_t delta, uint32_t mul_frac, int 
shift)
+{
+uint64_t product;
+#ifdef __i386__
+uint32_t tmp1, tmp2;
+#endif
+
+if ( shift < 0 )
+delta >>= -shift;
+else
+delta <<= shift;
+
+#ifdef __i386__
+__asm__ (
+"mul  %5   ; "
+"mov  %4,%%eax ; "
+"mov  %%edx,%4 ; "
+"mul  %5   ; "
+"add  %4,%%eax ; "
+"xor  %5,%5; "
+"adc  %5,%%edx ; "
+: "=A" (product), "=r" (tmp1), "=r" (tmp2)
+: "a" ((uint32_t)delta), "1" ((uint32_t)(delta >> 32)), "2" 
(mul_frac) );
+#else
+__asm__ (
+"mul %%rdx ; shrd $32,%%rdx,%%rax"
+: "=a" (product) : "0" (delta), "d" ((uint64_t)mul_frac) );
+#endif
+
+return product;
+}
+
+
+#if defined(__i386__)
+uint32_t since_boot_time(void)
+#else
+uint64_t since_boot_time(void)
+#endif
+{
+uint64_t tsc;
+uint32_t version, wc_version;
+#if defined(__i386__)
+uint32_t system_time;
+#else
+uint64_t system_time;
+#endif
+uint64_t old_tsc;
+
+do
+{
+do
+{
+wc_version = shared_info.wc_version ;
+version = shared_info.vcpu_info[0].time.version;
+} while ( (version & 1) == 1 || (wc_version & 1) == 1);
+
+system_time = shared_info.vcpu_info[0].time.system_time;
+old_tsc = shared_info.vcpu_info[0].time.tsc_timestamp;
+} while (
+version != shared_info.vcpu_info[0].time.version ||
+wc_version != shared_info.wc_version
+);
+
+rdtscp(tsc);
+
+system_time += scale_delta(tsc - old_tsc,
+   shared_info.vcpu_info[0].time.tsc_to_system_mul,
+   shared_info.vcpu_info[0].time.tsc_shift);
+
+return system_time;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/xtf/time.h b/include/xtf/time.h
new file mode 100644
index 000..15cbd48
--- /dev/null
+++ b/include/xtf/time.h
@@ -0,0 +1,35 @@
+/**
+ * @file include/xtf/time.h
+ *
+ * Time management
+ */
+#ifndef XTF_TIME_H
+# define XTF_TIME_H
+
+#include 
+
+#define rdtscp(tsc) {\
+uint32_t lo, hi;\
+__asm__ volatile("rdtsc": "=a"(lo), "=d"(hi));\
+tsc = ((uint64_t)hi << 32) | lo;\
+}
+
+
+#if defined(__i386__)
+/* Time from boot in nanoseconds */
+uint32_t since_boot_time(void);
+#else
+uint64_t since_boot_time(void);
+#endif
+
+#endif /* XTF_TIME_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.16.2

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


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

[Xen-devel] [PATCH 7/7] add sleep, msleep and NOW() macros to time manager

[Pawel Wieczorkiewicz]

From: Paul Semel 

Signed-off-by: Paul Semel 

cr https://code.amazon.com/reviews/CR-786228
---
 common/time.c  | 18 ++
 include/xtf/time.h | 16 
 2 files changed, 34 insertions(+)

diff --git a/common/time.c b/common/time.c
index 7577694..2bd4e7f 100644
--- a/common/time.c
+++ b/common/time.c
@@ -152,6 +152,24 @@ static inline void mspin_sleep(uint64_t t)
 nspin_sleep(nsec);
 }
 
+#if defined(__i386__)
+void sleep(uint32_t t)
+#else
+void sleep(uint64_t t)
+#endif
+{
+spin_sleep(t);
+}
+
+#if defined(__i386__)
+void msleep(uint32_t t)
+#else
+void msleep(uint64_t t)
+#endif
+{
+mspin_sleep(t);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/include/xtf/time.h b/include/xtf/time.h
index 16356eb..252263a 100644
--- a/include/xtf/time.h
+++ b/include/xtf/time.h
@@ -30,14 +30,30 @@ struct timeval {
 uint32_t since_boot_time(void);
 
 uint32_t current_time(void);
+
+/* This function takes seconds in parameter */
+void sleep(uint32_t f);
+
+/* Be careful, this function takes milliseconds in parameter,
+ * not microseconds !
+ */
+void msleep(uint32_t f);
 #else
 uint64_t since_boot_time(void);
 
 uint64_t current_time(void);
+
+void sleep(uint64_t f);
+
+void msleep(uint64_t f);
 #endif
 
 int gettimeofday(struct timeval *tp);
 
+
+/* This returns the current epoch time */
+#define NOW() current_time()
+
 #endif /* XTF_TIME_H */
 
 /*
-- 
2.16.2

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


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

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[Roger Pau Monné]

On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
> ... the same page with other registers which are not relevant to MSI-X. Xen
> marks pages where PBA resides as read-only. When assigning such devices to
> guest, device driver writes MSI-X irrelevant registers on those pages would
> lead to an EPT violation and the guest is destroyed because no handler is
> registered for those address range. In order to make guest capable to use such
> kind of devices, trapping very frequent write accesses is not a good idea for
> it would significantly impact the performance.
> 
> This patch provides a workaround with caveat. Specifically, an option is
> introduced to specify a list of devices. For those devices, Xen doesn't
> control the access right to pages where PBA resides. Hence, guest device
> driver is able to write those pages and functions well. Note that adding an
> untrusted device to this option may endanger security of the entire system.

This is a clear violation of the MSI-X spec. Out of curiosity, which
device is it that places random registers in the same page as the PBA?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

[Ian Jackson]

Marek Marczykowski-Górecki writes ("Re: [PATCH v2] libxl: allow 
libxl_domain_suspend to simply suspend a domain, without saving it"):
> On Wed, Mar 28, 2018 at 12:20:25PM +0100, Ian Jackson wrote:
> > I agree that libxl_domain_suspend is an unfortunate name, but can't we
> > come up with an alternative new name ?  It does seem odd to bundle
> > this into _save.
> 
> libxl_domain_just_suspend ?

How about libxl_domain_suspend_only ?

Ian.

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

Re: [Xen-devel] [PATCH v2] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

[Marek Marczykowski-Górecki]

On Wed, Mar 28, 2018 at 12:20:25PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2] libxl: allow libxl_domain_suspend to simply 
> suspend a domain, without saving it"):
> > On Wed, Mar 14, 2018 at 03:36:08PM +0100, Marek Marczykowski-Górecki wrote:
> > > When LIBXL_SUSPEND_NO_SAVE flag is set, no savefile will be written, but
> > > the domain will still be suspended (but not destroyed). The main reason
> > > for this functionality is to suspend the host while some domains are
> > > running, potentially holding PCI devices. This will give a chance to a
> > > driver in such a domain to properly suspend the device.
> > > 
> ...
> > > Signed-off-by: Marek Marczykowski-Górecki 
> > > 
> > > Signed-off-by: Marcus of Wetware Labs 
> > 
> > The code and idea look fine.
> > 
> > I would like to give Ian a chance to voice his opinion (he's currently
> > away).
> 
> The API does seem a bit odd.  The intent is then that the domain will
> be un-suspended afterwards ?  This doesn't seem to be documented
> AFAICT in your patch.

Yes, there is already libxl_domain_resume for that.

> I don't think I agree with this part of the reaoning:
> 
> > > It would be better to have a separate function for this, but in fact it
> > > should be named libxl_domain_suspend, then the current one renamed to
> > > libxl_domain_save. Since that would break API compatibility, keep it in
> > > the same function.
> 
> I agree that libxl_domain_suspend is an unfortunate name, but can't we
> come up with an alternative new name ?  It does seem odd to bundle
> this into _save.

libxl_domain_just_suspend ?
It isn't bundling it into _save. There is no _save function - that's the
problem.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Patches for stable

[Greg KH]

On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote:
> On 04/04/18 16:46, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
> >> On 04/04/18 16:27, Greg KH wrote:
> >>> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
>  Please add the patches:
> 
>  commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
>  commit dfc9327ab7c99bc13e12106448615efba833886b upstream
>  commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> 
>  to the 4.15 and 4.16 stable kernels.
> 
>  Those patches are needed to boot Linux as PVH guest on recent Xen.
> >>>
> >>> So a new feature?  Why is that ok for stable kernels?
> >>
> >> It works for kernels since at least 4.11 on Xen 4.10.
> > 
> > Great, so what commit caused this to fail?
> > 
> > So far, in reading those commits, it sounds like they are "make Linux
> > work again due to changes in Xen".  That sounds like a pretty bad thing
> > that Xen did, why do we have to fix up their mess?
> 
> Xen did nothing bad. It was the "old" kernel implementation which relied
> on an assumption which happened to be true by accident. Xen had to be
> changed in order to enable grub2 to support PVH mode.
> 
> The PVH interface specifies that the RSDP address is available via the
> start_info structure handed over to the PVH boot entry. The Linux kernel
> didn't look at that address, but used the legacy method scanning low
> memory for the RSDP table. As soon as Xen moved the RSDP to a higher
> address (which is covered by the PVH interface specification) the kernel
> could no longer be booted.
> 
> So it was clearly a fault of the kernel not complying to the PVH
> specification.

But it worked previously, so you can't fault Linux here :)

How many other operating systems broke with this change?

>  In PVH mode there is no guarantee the kernel can find the RSDP table
>  at the legacy location in low memory, which is a requirement for the
>  kernel to boot successful without those patches.
> >>>
> >>> Why not just use newer kernels for new Xen features?  This really
> >>> doesn't look like a bugfix to me, does it to you?
> >>
> >> It does. A working setup will no longer work if Xen version is upgraded
> >> to 4.11.
> > 
> > Why isn't this a regression in Xen that they fix?  Why are we
> > responsible for adding new kernel features to work on newer versions of
> > Xen and backport them to older kernels?
> 
> In case a Linux user program relies on undocumented behavior of the
> kernel (e.g. a register being non-zero on return from a syscall), does
> the kernel have to support that behavior eternally? I don't think so.

Yes, the kernel does have to support it.  It's called "do not break
working systems", or as some like to call it, the "Cambridge Promise"
that we made to userspace well over a decade ago at a kernel summit in
Cambridge.

We do this all the time, sometimes going through great gyrations in
order to achieve it.  Or sometimes we just "wait it out" and delay 4+
years to make these types of changes to allow everyone to update their
userspace programs before we make a change like this.

It's part of the job of running a good software project by not breaking
user's systems.  I suggest that Xen also adopt this same behavior if
they want to keep a happy userbase.  Otherwise we can just tell everyone
to go use KVM :)

> This is a similar case.

Not at all.  We have a working kernel here.  Xen changed and broke
working Linux systems.  Now I understand the goal of wanting to also
change Linux to work properly, but these changes are really a new
feature addition if you read the patches.

So why can't Xen just tell all Linux users to update to a more modern
kernel, i.e. 4.17.y and newer, in order to run with the new Xen kernel
if they want to enforce this previously working behavior?  Why does
Linux have to be the one to change here?

thanks,

greg k-h

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

Re: [Xen-devel] [PATCH v2 2/2] xen/arm: Add Marvell ARMADA 3700 early printk support

[Andre Przywara]

Hi,

On 03/04/18 14:49, Amit Singh Tomar wrote:
> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since v1:
> * Removed header file dependency. 
> 
> ---
>  docs/misc/arm/early-printk.txt |  1 +
>  xen/arch/arm/Rules.mk  |  1 +
>  xen/arch/arm/arm64/debug-mvebu.inc | 50 
> ++
>  3 files changed, 52 insertions(+)
>  create mode 100644 xen/arch/arm/arm64/debug-mvebu.inc
> 
> diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
> index 20a8af8..f765f59 100644
> --- a/docs/misc/arm/early-printk.txt
> +++ b/docs/misc/arm/early-printk.txt
> @@ -41,6 +41,7 @@ the name of the machine:
>- juno: printk with pl011 on Juno platform
>- lager: printk with SCIF0 on Renesas R-Car H2 processors
>- midway: printk with the pl011 on Calxeda Midway processors
> +  - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
>- omap5432: printk with UART3 on TI OMAP5432 processors
>- rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
>- seattle: printk with pl011 for AMD Seattle processor
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index b66c19f..f264592 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -36,6 +36,7 @@ EARLY_PRINTK_hikey960   := pl011,0xfff32000
>  EARLY_PRINTK_juno   := pl011,0x7ff8
>  EARLY_PRINTK_lager  := scif,0xe6e6
>  EARLY_PRINTK_midway := pl011,0xfff36000
> +EARLY_PRINTK_mvebu  := mvebu,0xd0012000
>  EARLY_PRINTK_omap5432   := 8250,0x4802,2
>  EARLY_PRINTK_rcar3  := scif,0xe6e88000
>  EARLY_PRINTK_seattle:= pl011,0xe101
> diff --git a/xen/arch/arm/arm64/debug-mvebu.inc 
> b/xen/arch/arm/arm64/debug-mvebu.inc
> new file mode 100644
> index 000..ac48889
> --- /dev/null
> +++ b/xen/arch/arm/arm64/debug-mvebu.inc
> @@ -0,0 +1,50 @@
> +/*
> + * xen/drivers/char/mvebu3700-uart.c
> + *
> + * Driver for Marvell MVEBU UART.
> + *
> + * Copyright (c) 2018, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#define UART_STATUS_REG 0xc 

There is a trailing space in this line. Also you could use 0x0c instead
to match the line below.

> +#define UART_TX_REG 0x04
> +
> +/*
> + * MVEBU UART wait UART to be ready to transmit
> + * xb: register which contains the UART base address
> + * c: scratch register
> + */
> +.macro early_uart_ready xb c
> +1:
> +ldrh   w\c, [\xb, #UART_STATUS_REG]  /* <- status register */
> +tstw\c, #(1 << 13)/* <- Check TXFIFO EMP 
> bit */

I don't think it's necessary to check for the FIFO being empty. Do as
the Linux driver does: Check for !full. So use bit 11 here and negate
the branch condition below. Will test this later tonight.

And while you are on it: Can you please align the comments, also make
sure they don't break the line (for instance just remove the " <- ")?

Cheers,
Andre.

> +beq1b/* <- Wait for the UART to be 
> ready */
> +.endm
> +
> +/*
> + * MVEBU UART transmit character
> + * xb: register which contains the UART base address
> + * wt: register which contains the character to transmit
> + */
> +.macro early_uart_transmit xb wt
> + strb  \wt, [\xb, #UART_TX_REG]
> +.endm
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */
> 

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

[Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[Chao Gao]

... the same page with other registers which are not relevant to MSI-X. Xen
marks pages where PBA resides as read-only. When assigning such devices to
guest, device driver writes MSI-X irrelevant registers on those pages would
lead to an EPT violation and the guest is destroyed because no handler is
registered for those address range. In order to make guest capable to use such
kind of devices, trapping very frequent write accesses is not a good idea for
it would significantly impact the performance.

This patch provides a workaround with caveat. Specifically, an option is
introduced to specify a list of devices. For those devices, Xen doesn't
control the access right to pages where PBA resides. Hence, guest device
driver is able to write those pages and functions well. Note that adding an
untrusted device to this option may endanger security of the entire system.

Signed-off-by: Chao Gao 
---
 docs/misc/xen-command-line.markdown | 10 +
 xen/arch/x86/msi.c  |  7 --
 xen/drivers/passthrough/pci.c   | 45 +++--
 xen/include/asm-x86/msi.h   |  1 +
 4 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index b353352..e382513 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
 
 > Default: `on`
 
+### pba\_quirk
+> `= List of [:]:.
+
+Specify a list of SBDF of devices. When assigning devices in this list to
+guest, reading or writing the page where MSI-X PBA resides are allowed.
+This option provides a workaround for nonstandard PCI devices whose
+MSI-X PBA shares the same 4K-byte page with other registers. Note that
+adding an untrusted device to this option would undermine security of
+the entire system.
+
 ### pci
 > `= {no-}serr | {no-}perr`
 
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 5567990..2abf2cf 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -992,7 +992,9 @@ static int msix_capability_init(struct pci_dev *dev,
 if ( rangeset_add_range(mmio_ro_ranges, msix->table.first,
 msix->table.last) )
 WARN();
-if ( rangeset_add_range(mmio_ro_ranges, msix->pba.first,
+
+if ( !msix->pba_quirk_enabled &&
+ rangeset_add_range(mmio_ro_ranges, msix->pba.first,
 msix->pba.last) )
 WARN();
 
@@ -1139,7 +1141,8 @@ static void _pci_cleanup_msix(struct arch_msix *msix)
 if ( rangeset_remove_range(mmio_ro_ranges, msix->table.first,
msix->table.last) )
 WARN();
-if ( rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
+if ( !msix->pba_quirk_enabled &&
+ rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
msix->pba.last) )
 WARN();
 }
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1db69d5..cd765ef 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -184,6 +184,38 @@ static int __init parse_phantom_dev(const char *str)
 }
 custom_param("pci-phantom", parse_phantom_dev);
 
+static struct pba_quirk_dev {
+uint32_t sbdf;
+} pba_quirk_devs[8];
+static unsigned int nr_pba_quirk_devs;
+
+static int __init parse_pba_quirk(const char *str)
+{
+unsigned int seg, bus, dev, func;
+
+for ( ; ; )
+{
+if ( nr_pba_quirk_devs >= ARRAY_SIZE(pba_quirk_devs) )
+return -E2BIG;
+
+str = parse_pci(str, , , , );
+if ( !str )
+return -EINVAL;
+
+pba_quirk_devs[nr_pba_quirk_devs++].sbdf = PCI_SBDF(seg, bus, dev,
+func);
+if ( *str == ',' )
+str++;
+else if ( !*str )
+break;
+else
+return -EINVAL;
+}
+
+return 0;
+}
+custom_param("pba_quirk", parse_pba_quirk);
+
 static u16 __read_mostly command_mask;
 static u16 __read_mostly bridge_ctl_mask;
 
@@ -300,6 +332,7 @@ static void check_pdev(const struct pci_dev *pdev)
 
 static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
 {
+unsigned int i;
 struct pci_dev *pdev;
 
 list_for_each_entry ( pdev, >alldevs_list, alldevs_list )
@@ -328,6 +361,16 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 
bus, u8 devfn)
 }
 spin_lock_init(>table_lock);
 pdev->msix = msix;
+
+for ( i = 0; i < nr_pba_quirk_devs; i++ )
+{
+if ( pba_quirk_devs[i].sbdf == PCI_SBDF3(pseg->nr, bus, devfn) )
+{
+pdev->msix->pba_quirk_enabled = true;
+printk(XENLOG_WARNING "Enable PBA quirk for 
%04x:%02x:%02x.%u\n",
+   pseg->nr, bus, PCI_SLOT(devfn), 

Re: [Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[Juergen Gross]

On 04/04/18 17:00, M A Young wrote:
> On Wed, 4 Apr 2018, Ajay Garg wrote:
> 
>> Thanks Michael for the reply.
>>
>> I want to give this patch a try, as the symptoms look identical.
>> However, I see no xen-head.S when I clone the repo from
>> git://xenbits.xen.org/xen.git
>>
>> What am I missing?
> 
> The patch is for the xen code in the kernel. It was accepted in the kernel 
> upstream (in 4.15.5 and probably backported to other maintained kernels) 
> so you probably just need a kernel less than a month old, but as has 
> already been said, the kernel may not be the problem.

And the symptoms are completely different (well, at least for me).

Ajay's crash is due to an illegal instruction, so probably a BUG().

The patch above fixes an early page fault in the kernel.


Juergen

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

Re: [Xen-devel] Patches for stable

[Juergen Gross]

On 04/04/18 16:46, Greg KH wrote:
> On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
>> On 04/04/18 16:27, Greg KH wrote:
>>> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
 Please add the patches:

 commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
 commit dfc9327ab7c99bc13e12106448615efba833886b upstream
 commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream

 to the 4.15 and 4.16 stable kernels.

 Those patches are needed to boot Linux as PVH guest on recent Xen.
>>>
>>> So a new feature?  Why is that ok for stable kernels?
>>
>> It works for kernels since at least 4.11 on Xen 4.10.
> 
> Great, so what commit caused this to fail?
> 
> So far, in reading those commits, it sounds like they are "make Linux
> work again due to changes in Xen".  That sounds like a pretty bad thing
> that Xen did, why do we have to fix up their mess?

Xen did nothing bad. It was the "old" kernel implementation which relied
on an assumption which happened to be true by accident. Xen had to be
changed in order to enable grub2 to support PVH mode.

The PVH interface specifies that the RSDP address is available via the
start_info structure handed over to the PVH boot entry. The Linux kernel
didn't look at that address, but used the legacy method scanning low
memory for the RSDP table. As soon as Xen moved the RSDP to a higher
address (which is covered by the PVH interface specification) the kernel
could no longer be booted.

So it was clearly a fault of the kernel not complying to the PVH
specification.

> 
 In PVH mode there is no guarantee the kernel can find the RSDP table
 at the legacy location in low memory, which is a requirement for the
 kernel to boot successful without those patches.
>>>
>>> Why not just use newer kernels for new Xen features?  This really
>>> doesn't look like a bugfix to me, does it to you?
>>
>> It does. A working setup will no longer work if Xen version is upgraded
>> to 4.11.
> 
> Why isn't this a regression in Xen that they fix?  Why are we
> responsible for adding new kernel features to work on newer versions of
> Xen and backport them to older kernels?

In case a Linux user program relies on undocumented behavior of the
kernel (e.g. a register being non-zero on return from a syscall), does
the kernel have to support that behavior eternally? I don't think so.
This is a similar case.


Juergen

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

Re: [Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[M A Young]

On Wed, 4 Apr 2018, Ajay Garg wrote:

> Thanks Michael for the reply.
> 
> I want to give this patch a try, as the symptoms look identical.
> However, I see no xen-head.S when I clone the repo from
> git://xenbits.xen.org/xen.git
> 
> What am I missing?

The patch is for the xen code in the kernel. It was accepted in the kernel 
upstream (in 4.15.5 and probably backported to other maintained kernels) 
so you probably just need a kernel less than a month old, but as has 
already been said, the kernel may not be the problem.

Michael Young

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

Re: [Xen-devel] Make coverity results public

[Wei Liu]

On Wed, Apr 04, 2018 at 03:47:44PM +0100, Lars Kurth wrote:
> 
> On 28/03/2018, 19:23, "George Dunlap"  wrote:
> 
> > 
> > Lars, if you don't object I'm going to open up the results. And I will
> > leave the task to update the contribution guide webpage to you. :-)
> 
> I'd wait at least until EOD Thursday. :-)
> 
> Sure. I am assuming this is public now?

Yes, it is supposed to be public. But Roger says he still can't access
it. I have sent an email to admin@coverity, but they haven't come back.

We should definitely update our policy document.

Wei.

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

Re: [Xen-devel] Make coverity results public

[Lars Kurth]

On 28/03/2018, 19:23, "George Dunlap"  wrote:

> 
> Lars, if you don't object I'm going to open up the results. And I will
> leave the task to update the contribution guide webpage to you. :-)

I'd wait at least until EOD Thursday. :-)

Sure. I am assuming this is public now?
Lars

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

Re: [Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[Ajay Garg]

Thanks Michael for the reply.

I want to give this patch a try, as the symptoms look identical.
However, I see no xen-head.S when I clone the repo from
git://xenbits.xen.org/xen.git

What am I missing?


Thanks and Regards,
Ajay

>
> It is a kernel problem under some compile conditions. See for example
> https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00010.html
> and the patch at
> https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00045.html
>
> Michael Young

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

Re: [Xen-devel] Patches for stable

[Greg KH]

On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
> On 04/04/18 16:27, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
> >> Please add the patches:
> >>
> >> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
> >> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
> >> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> >>
> >> to the 4.15 and 4.16 stable kernels.
> >>
> >> Those patches are needed to boot Linux as PVH guest on recent Xen.
> > 
> > So a new feature?  Why is that ok for stable kernels?
> 
> It works for kernels since at least 4.11 on Xen 4.10.

Great, so what commit caused this to fail?

So far, in reading those commits, it sounds like they are "make Linux
work again due to changes in Xen".  That sounds like a pretty bad thing
that Xen did, why do we have to fix up their mess?

> >> In PVH mode there is no guarantee the kernel can find the RSDP table
> >> at the legacy location in low memory, which is a requirement for the
> >> kernel to boot successful without those patches.
> > 
> > Why not just use newer kernels for new Xen features?  This really
> > doesn't look like a bugfix to me, does it to you?
> 
> It does. A working setup will no longer work if Xen version is upgraded
> to 4.11.

Why isn't this a regression in Xen that they fix?  Why are we
responsible for adding new kernel features to work on newer versions of
Xen and backport them to older kernels?

thanks,

greg k-h

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

Re: [Xen-devel] Patches for stable

[Juergen Gross]

On 04/04/18 16:27, Greg KH wrote:
> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
>> Please add the patches:
>>
>> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
>> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
>> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
>>
>> to the 4.15 and 4.16 stable kernels.
>>
>> Those patches are needed to boot Linux as PVH guest on recent Xen.
> 
> So a new feature?  Why is that ok for stable kernels?

It works for kernels since at least 4.11 on Xen 4.10.

> 
>> In PVH mode there is no guarantee the kernel can find the RSDP table
>> at the legacy location in low memory, which is a requirement for the
>> kernel to boot successful without those patches.
> 
> Why not just use newer kernels for new Xen features?  This really
> doesn't look like a bugfix to me, does it to you?

It does. A working setup will no longer work if Xen version is upgraded
to 4.11.


Juergen

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

Re: [Xen-devel] Patches for stable

[Greg KH]

On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
> Please add the patches:
> 
> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> 
> to the 4.15 and 4.16 stable kernels.
> 
> Those patches are needed to boot Linux as PVH guest on recent Xen.

So a new feature?  Why is that ok for stable kernels?

> In PVH mode there is no guarantee the kernel can find the RSDP table
> at the legacy location in low memory, which is a requirement for the
> kernel to boot successful without those patches.

Why not just use newer kernels for new Xen features?  This really
doesn't look like a bugfix to me, does it to you?

thanks,

greg k-h

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  90eff18cc5e16e0749605d88092ecfa4ab126c8f
baseline version:
 xen  913acc1aa019054742217926dea0827e7a9df02e

Last test of basis   121752  2018-04-03 19:01:08 Z0 days
Testing same since   121776  2018-04-04 12:02:04 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  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 :

To xenbits.xen.org:/home/xen/git/xen.git
   913acc1aa0..90eff18cc5  90eff18cc5e16e0749605d88092ecfa4ab126c8f -> smoke

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

[Xen-devel] [OSSTEST PATCH] crontabs: Add warning not to just "crontab -e"

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 crontab   | 4 
 crontab-cambridge | 4 
 2 files changed, 8 insertions(+)

diff --git a/crontab b/crontab
index 3c8c8cc..e7f2ad3 100755
--- a/crontab
+++ b/crontab
@@ -1,6 +1,10 @@
 #!/bin/bash ./mg-crontab-install
 #@@ osst...@osstest.test-lab.xenproject.org
 
+##
+# This file is maintained in osstest.git - DO NOT EDIT ELSEWHERE #
+##
+
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 MAILTO=osstest-ad...@xenproject.org
 # mh   dom mon dow command
diff --git a/crontab-cambridge b/crontab-cambridge
index 3c197de..a6c29af 100755
--- a/crontab-cambridge
+++ b/crontab-cambridge
@@ -1,6 +1,10 @@
 #!/bin/bash ./mg-crontab-install
 #@@ osst...@osstest.xs.citrite.net
 
+##
+# This file is maintained in osstest.git - DO NOT EDIT ELSEWHERE #
+##
+
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 MAILTO=ian.jack...@citrix.com,ian.campb...@eu.citrix.com
 # mh   dom mon dow command
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] ARM: new VGIC: evtchn: fix potential race in vcpu_mark_events_pending()

[Andre Przywara]

Hi,

On 04/04/18 01:04, Stefano Stabellini wrote:
> On Tue, 3 Apr 2018, Julien Grall wrote:
>> On 29/03/18 18:35, Stefano Stabellini wrote:
>>> On Thu, 29 Mar 2018, Andre Przywara wrote:
 Stefano pointed out the following situation:
 --
 1) vcpuA/cpuA is running, it has already handled the event, cleared
 evtchn_upcall_pending and EOIed the event_irq but hasn't trapped into
 Xen yet. It is still in guest mode.

 2) Xen on cpuB calls vcpu_mark_events_pending(vcpuA), then calls
 vgic_inject_irq. However, because irq->line_level is high, it is not
 injected.

 3) vcpuA has to wait until trapping into Xen, calling
 vcpu_update_evtchn_irq, and going back to guest mode before receiving
 the event. This is theoretically a very long time.
 --

 Fix this by updating the state of our emulated IRQ line level inside
 vcpu_mark_events_pending(), before trying to inject the new interrupt.

 Despite having two calls to vgic_inject_irq(), only one will actually do
 something:
 - If the emulated line level was already in sync with the actual flag,
the VGIC ignores the first call, due to vgic_validate_injection().
 - If the emulated line level was high, but the flag says it should have
been low, vgic_inject_irq() will just update the line_level state.
 - If the emulated line level was low, but the flags says it should have
been high, we will inject the interrupt. The second call is then a
NOP.

 Signed-off-by: Andre Przywara 
 ---
 Hi,

 this would ideally have been part of a former patch:
 "[PATCH v3 06/39] ARM: evtchn: Handle level triggered IRQs correctly",
 but this has been merged already, so this has to be a follow-up.
 Ideally this would be merged before the final patch that introduces the
 CONFIG_NEW_VGIC Kconfig symbol, so that the old code gets never compiled.

 Thanks,
 Andre

   xen/arch/arm/domain.c | 11 +--
   1 file changed, 9 insertions(+), 2 deletions(-)

 diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
 index 9688e62f78..11fa9002dc 100644
 --- a/xen/arch/arm/domain.c
 +++ b/xen/arch/arm/domain.c
 @@ -947,10 +947,17 @@ void vcpu_mark_events_pending(struct vcpu *v)
   int already_pending = test_and_set_bit(
   0, (unsigned long *)_info(v, evtchn_upcall_pending));
   -if ( already_pending )
 -return;
 +#ifdef CONFIG_NEW_VGIC
 +/* Update the state of the current interrupt line. */
 +vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq,
 already_pending);
   +/* Make the level IRQ pending. That's a NOP if it was already. */
   vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
 +#else
 +/* Only signal the VGIC if it wasn't already pending. */
 +if ( !already_pending )
 +vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
 +#endif
   }
>>>
>>> The issue with this is that it is potentially racy, against vcpuA
>>> trapping into Xen and executing vcpu_update_evtchn_irq, that also reads
>>> evtchn_upcall_pending, then calls vgic_inject_irq. The last
>>> vgic_inject_irq executed could be the one passing level = false, losing
>>> the notification.
>>>
>>> I might have a better idea: what if we just vcpu_kick(v) and do nothing
>>> else? There is no need to call vgic_inject_irq from here because the
>>> other vcpu will take care of doing it for us after trapping into Xen
>>> (vcpu_update_evtchn_irq). It also needs to trap into Xen anyway to be
>>> able to receive the new event as soon as possible.
>>>
>>> The code would become:
>>>
>>>if ( already_pending )
>>>return;
>>>
>>>vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
>>>
>>> #ifdef CONFIG_NEW_VGIC
>>>vcpu_kick(v);
>>> #endif
>>>
>>>
>>> Note that vgic_inject_irq already does a vcpu_kick but only after
>>> passing the vgic_validate_injection check, which would fail in this case
>>> because irq->line_level is not up-to-date.
>>>
>>> What do you think?
>>
>> At the moment, the issue you describe is a non-issue because we set the EOI
>> bit in the LR (see vgic_v2_populate_lr). So there are no need to kick the
>> other vCPU as it would enter to Xen as soon as the event channel interrupt is
>> been eoied by the guest.
>>
>> Therefore, I believe we don't need to have a different version of
>> vcpu_mark_events_pending for the new vGIC.
> 
> Ah! It makes sense.
> 
> Andre, why did you choose to set the EOI bit in the LR for non-hardware
> interrupts? If it came up in previous email exchanges, my apologies.

So for hardware mapped level IRQs it goes like this:
1) The host ACKs the IRQ, making it active & pending on the GIC side.
2) We inject it as pending into the guest, with the HW bit set.
3) 

[Xen-devel] [linux-4.9 test] 121738: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linuxf080bba272b1e3f9bbf0b6c1acef3efaf16b631d
baseline version:
 linuxc44cfe06dfe2a5f54527e87a48c92a6595d070cc

Last test of basis   121371  2018-03-30 07:18:09 Z5 days
Testing same since   121522  2018-03-31 19:05:52 Z3 days3 attempts


People who touched revisions under test:
  Alexey Kodanev 
  Arkadi Sharshevsky 
  Arvind Yadav 
  

Re: [Xen-devel] Xen development link

[Praveen Kumar]

On Wed, Apr 4, 2018 at 5:17 PM, Lars Kurth  wrote:
> Hi Praveen,
>
> On 4 Apr 2018, at 12:42, Praveen Kumar  wrote:
>
> On Wed, Apr 4, 2018 at 3:50 PM, Roger Pau Monné 
> wrote:
>
> On Wed, Apr 04, 2018 at 02:40:45PM +0530, Praveen Kumar wrote:
>
> On Wed, Apr 4, 2018 at 2:32 PM, Praveen Kumar 
> wrote:
>
> On Wed, Apr 4, 2018 at 1:11 PM, Roger Pau Monné 
> wrote:
>
> On Wed, Apr 04, 2018 at 10:08:29AM +0530, Praveen Kumar wrote:
>
> Hi,
>
> I came across Xen development link (
> https://xenorg.uservoice.com/forums/172169-xen-development ) which was
> lastly updated in Jul 2017 ( around ).
> This looks great to me, but just wanted to check if we are still
> following and updating the ideas ? Or is there any other link / forum,
> where we update and share.
>
>
> I think some maintainers use:
>
> https://xenproject.atlassian.net/projects/XEN/board
>
> Is this a closed / private portal ?
>
>
> What do you mean by closed?
>
> I can access it just fine without being logged in at all. AFAIK this
> is to be used by maintainers to track items.
>
>
> True, I am able to access the page. But tried the login option with my
> email ( kpraveen.lkml@gmail.
>
>
> com),
> which mentioned access denied ! So thought of asking in the forum.
>
> I was in a opinion that, there will be more details w.r.t. the items
> mentioned, which will be shown,
> when an individual login :-)
>
>
> The amount of information in the public/private instance is identical.
> A lot of the tickets are just headlines, depending on which maintainer added
> it.
>
> Primarily only maintainers get write access, unless there is a very good
> reason why someone else should have access.
>
> If that's not the case, and we can get the access, can you please
> guide whom to request for,
> as I am not able to get the administrator's email / link to approach
>
>
> Adding Lars.
>
>
> I would prefer if we didn't add non-maintainers, as this makes it hard to
> maintain a list of why has access and why.
>
> I came across Xen development link (
> https://xenorg.uservoice.com/forums/172169-xen-development ) which was
> lastly updated in Jul 2017 ( around ).
> This looks great to me, but just wanted to check if we are still
> following and updating the ideas ? Or is there any other link / forum,
> where we update and share.
>
>
> We tend to review the list at the beginning of a release cycle, and copy
> interesting items to the Atlassian board

Sure Lars ! That helps. Thanks.

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

Re: [Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[Jason Andryuk]

On Wed, Apr 4, 2018 at 6:25 AM, Juergen Gross  wrote:
> On 04/04/18 12:07, M A Young wrote:
>> On Wed, 4 Apr 2018, Ajay Garg wrote:
>>
>>> Since I failed to get a single reply on my original issue as per
>>> https://lists.xenproject.org/archives/html/minios-devel/2018-04/msg4.html,
>>> so I had no option but to try on a newer xen version.
>>>
>>> So, I created  a  new virtualbox-guest, and followed the steps as per
>>> https://blog.werk21.de/en/2018/02/08/build-xen-hypervisor-410-and-xen-tools-ubuntu-1604-pvh
>>>
>>> Now, when start the guest with Xen-hypervisor enabled, it does not come up.
>>> I took serial-logs at bootup time, they are as follows :
>>>
>>> #
>>>  Xen 4.10.1-pre
>>> (XEN) Xen version 4.10.1-pre (ajay@) (gcc (Ubuntu
>>> 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609) debug=n  Wed Apr  4 12:54:58
>>> IST 2018
>>> (XEN) Latest ChangeSet: Tue Mar 20 14:23:14 2018 +0100 git:0f92968
>>> (XEN) Bootloader: GRUB 2.02~beta2-36ubuntu3.17
>>> (XEN) Command line: placeholder console=com1 com1=115200,8n1
>>> loglvl=all guest_loglvl=all
>>> (XEN) Xen image load base address: 0
>>> (XEN) Video information:
>>> (XEN)  VGA is text mode 80x25, font 8x16
>>> (XEN) Disc information:
>>> (XEN)  Found 1 MBR signatures
>>> (XEN)  Found 1 EDD information structures
>>> (XEN) Xen-e820 RAM map:
>>> (XEN)   - 0009fc00 (usable)
>>> (XEN)  0009fc00 - 000a (reserved)
>>> (XEN)  000f - 0010 (reserved)
>>> (XEN)  0010 - bfff (usable)
>>> (XEN)  bfff - c000 (ACPI data)
>>> (XEN)  fec0 - fec01000 (reserved)
>>> (XEN)  fee0 - fee01000 (reserved)
>>> (XEN)  fffc - 0001 (reserved)
>>> (XEN) New Xen image base address: 0xbf80
>>> (XEN) System RAM: 3071MB (3145276kB)
>>> (XEN) ACPI: RSDP 000E, 0024 (r2 VBOX  )
>>> (XEN) ACPI: XSDT BFFF0030, 003C (r1 VBOX   VBOXXSDT1 ASL61)
>>> (XEN) ACPI: FACP BFFF00F0, 00F4 (r4 VBOX   VBOXFACP1 ASL61)
>>> (XEN) ACPI: DSDT BFFF0470, 21FF (r2 VBOX   VBOXBIOS2 INTL 20160108)
>>> (XEN) ACPI: FACS BFFF0200, 0040
>>> (XEN) ACPI: APIC BFFF0240, 0054 (r2 VBOX   VBOXAPIC1 ASL61)
>>> (XEN) ACPI: SSDT BFFF02A0, 01CC (r1 VBOX   VBOXCPUT2 INTL 20160108)
>>> (XEN) No NUMA configuration found
>>> (XEN) Faking a node at -bfff
>>> (XEN) Domain heap initialised
>>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 142 (0x8e), Stepping 9
>>> (raw 000806e9)
>>> (XEN) found SMP MP-table at 0009fff0
>>> (XEN) DMI 2.5 present.
>>> (XEN) Using APIC driver default
>>> (XEN) ACPI: PM-Timer IO Port: 0x4008 (32 bits)
>>> (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:4004,1:0], pm1x_evt[1:4000,1:0]
>>> (XEN) ACPI: wakeup_vec[bfff020c], vec_size[20]
>>> (XEN) ACPI: Local APIC address 0xfee0
>>> (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
>>> (XEN) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
>>> (XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
>>> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>>> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
>>> (XEN) ACPI: IRQ0 used by override.
>>> (XEN) ACPI: IRQ2 used by override.
>>> (XEN) ACPI: IRQ9 used by override.
>>> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
>>> (XEN) ERST table was not found
>>> (XEN) Using ACPI (MADT) for SMP configuration information
>>> (XEN) SMP: Allowing 1 CPUs (0 hotplug CPUs)
>>> (XEN) IRQ limits: 24 GSI, 184 MSI/MSI-X
>>> (XEN) Not enabling x2APIC: depends on iommu_supports_eim.
>>> (XEN) xstate: size: 0x440 and states: 0x7
>>> (XEN) CPU0: No MCE banks present. Machine check support disabled
>>> (XEN) Speculative mitigation facilities:
>>> (XEN)   Compiled-in support: INDIRECT_THUNK
>>> (XEN) BTI mitigations: Thunk RETPOLINE, Others: RSB_NATIVE RSB_VMEXIT
>>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>>> (XEN) Platform timer is 3.579MHz ACPI PM Timer
>>> (XEN) Detected 2712.035 MHz processor.
>>> (XEN) Initing memory sharing.
>>> (XEN) alt table 82d080421798 -> 82d080423244
>>> (XEN) I/O virtualisation disabled
>>> (XEN) nr_sockets: 1
>>> (XEN) ENABLING IO-APIC IRQs
>>> (XEN)  -> Using new ACK method
>>> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>>> (XEN) Allocated console ring of 16 KiB.
>>> (XEN) Brought up 1 CPUs
>>> (XEN) build-id: 0734050809e0cb9f52e65322a0d3911d082e348b
>>> (XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'.
>>> (XEN) ACPI sleep modes: S3
>>> (XEN) VPMU: disabled
>>> (XEN) xenoprof: Initialization failed. Intel processor family 6 model
>>> 142 is not supported
>>> (XEN) Dom0 has maximum 208 PIRQs
>>> (XEN) NX (Execute Disable) protection active
>>> (XEN) *** LOADING DOMAIN 0 ***
>>> (XEN)  Xen  kernel: 64-bit, lsb, compat32

Re: [Xen-devel] [PATCH v11] x86/altp2m: support for setting restrictions for an array of pages

[George Dunlap]

On 03/30/2018 04:39 PM, Petre Pircalabu wrote:
> From: Razvan Cojocaru 
> 
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2m subsystem, which could only set page restrictions for one
> page at a time. This patch addresses the gap.
> 
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
> hence with the original altp2m design, where domains are allowed - with the
> proper altp2m access rights - to alter these settings), in the absence of an
> official position on the issue from the original altp2m designers.
> 
> Signed-off-by: Razvan Cojocaru 
> Signed-off-by: Petre Pircalabu 
> Acked-by: Wei Liu 

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] Xen development link

[Lars Kurth]

Hi Praveen,

> On 4 Apr 2018, at 12:42, Praveen Kumar  wrote:
> 
> On Wed, Apr 4, 2018 at 3:50 PM, Roger Pau Monné  > wrote:
>> On Wed, Apr 04, 2018 at 02:40:45PM +0530, Praveen Kumar wrote:
>>> On Wed, Apr 4, 2018 at 2:32 PM, Praveen Kumar  
>>> wrote:
 On Wed, Apr 4, 2018 at 1:11 PM, Roger Pau Monné  
 wrote:
> On Wed, Apr 04, 2018 at 10:08:29AM +0530, Praveen Kumar wrote:
>> Hi,
>> 
>> I came across Xen development link (
>> https://xenorg.uservoice.com/forums/172169-xen-development ) which was
>> lastly updated in Jul 2017 ( around ).
>> This looks great to me, but just wanted to check if we are still
>> following and updating the ideas ? Or is there any other link / forum,
>> where we update and share.
> 
> I think some maintainers use:
> 
> https://xenproject.atlassian.net/projects/XEN/board
> 
>>> Is this a closed / private portal ?
>> 
>> What do you mean by closed?
>> 
>> I can access it just fine without being logged in at all. AFAIK this
>> is to be used by maintainers to track items.
> 
> True, I am able to access the page. But tried the login option with my
> email ( kpraveen.lkml@gmail. 
> com ),
> which mentioned access denied ! So thought of asking in the forum.
> 
> I was in a opinion that, there will be more details w.r.t. the items
> mentioned, which will be shown,
> when an individual login :-)

The amount of information in the public/private instance is identical.
A lot of the tickets are just headlines, depending on which maintainer added it.

Primarily only maintainers get write access, unless there is a very good reason 
why someone else should have access.

>>> If that's not the case, and we can get the access, can you please
>>> guide whom to request for,
>>> as I am not able to get the administrator's email / link to approach
>> 
>> Adding Lars.

I would prefer if we didn't add non-maintainers, as this makes it hard to 
maintain a list of why has access and why.

> I came across Xen development link (
> https://xenorg.uservoice.com/forums/172169-xen-development 
>  ) which was
> lastly updated in Jul 2017 ( around ).
> This looks great to me, but just wanted to check if we are still
> following and updating the ideas ? Or is there any other link / forum,
> where we update and share.

We tend to review the list at the beginning of a release cycle, and copy 
interesting items to the Atlassian board

Lars

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

Re: [Xen-devel] [PATCH v4 8/8] x86: avoid double CR3 reload when switching to guest user mode

[Juergen Gross]

On 19/03/18 14:41, Jan Beulich wrote:
> When XPTI is active, the CR3 load in restore_all_guest is sufficient
> when switching to user mode, improving in particular system call and
> page fault exit paths for the guest.
> 
> Signed-off-by: Jan Beulich 
> Tested-by: Juergen Gross 
> Reviewed-by: Juergen Gross 

I've done some more simple performance tests with some of the patches
with xpti=false and xpti=true. Data is always elapsed time, system time
and user time in seconds for a make -j 4 in dom0 with 4 vcpus, stddev
in braces, based on 5 runs each (I tried 30 runs, but the result didn't
really change):

xpti=false
no patch:  89.96 ( 2.84)   97.05 ( 2.39)  178.64 ( 1.55)
Jan p1:90.65 ( 2.57)   99.50 ( 3.85)  180.35 ( 2.44)
Jan p5:91.33 ( 0.89)   99.72 ( 2.56)  180.97 ( 1.71)
Jan p6:90.86 ( 2.59)   97.09 ( 2.59)  177.85 ( 2.35)
Jan p7:90.72 ( 2.84)  100.10 ( 4.60)  179.85 ( 2.61)
Jan p8:88.59 ( 0.71)   96.31 ( 2.14)  178.47 ( 0.86)

xpti=true
no patch: 113.42 ( 3.13)  165.99 ( 3.89)  180.99 ( 1.63)
Jan p1:   111.69 ( 3.15)  163.63 ( 3.61)  181.22 ( 1.93)
Jan p5:   114.76 ( 2.28)  167.15 ( 4.67)  181.13 ( 1.75)
Jan p6:   116.85 ( 2.35)  168.73 ( 3.68)  181.27 ( 1.98)
Jan p7:   115.37 ( 2.71)  166.96 ( 4.41)  180.82 ( 1.98)
Jan p8:   114.85 ( 2.83)  167.08 ( 5.00)  181.27 ( 1.85)

Summing it up: performance isn't really changing for any of the patches.


Juergen

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

Re: [Xen-devel] [PATCH] x86/hvm/ioreq: fix out of bounds access in error path

[Andrew Cooper]

On 04/04/18 12:11, Paul Durrant wrote:
>> -Original Message-
>> From: Wei Liu [mailto:wei.l...@citrix.com]
>> Sent: 04 April 2018 12:03
>> To: Xen-devel 
>> Cc: Wei Liu ; Jan Beulich ;
>> Andrew Cooper ; Paul Durrant
>> 
>> Subject: [PATCH] x86/hvm/ioreq: fix out of bounds access in error path
>>
>> It is possible to call the error path with i pointing beyond the end
>> of the array.
>>
>> There is another bug that if there is already a default ioreq server,
>> the code will actually sets the element to NULL, hence leaking memory.
>>
>> Move setting NULL to where it is needed.
>>
>> Coverity-ID: 1433777
>> Signed-off-by: Wei Liu 
> Reviewed-by: Paul Durrant 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86/hvm/ioreq: fix out of bounds access in error path

[Paul Durrant]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 04 April 2018 12:03
> To: Xen-devel 
> Cc: Wei Liu ; Jan Beulich ;
> Andrew Cooper ; Paul Durrant
> 
> Subject: [PATCH] x86/hvm/ioreq: fix out of bounds access in error path
> 
> It is possible to call the error path with i pointing beyond the end
> of the array.
> 
> There is another bug that if there is already a default ioreq server,
> the code will actually sets the element to NULL, hence leaking memory.
> 
> Move setting NULL to where it is needed.
> 
> Coverity-ID: 1433777
> Signed-off-by: Wei Liu 

Reviewed-by: Paul Durrant 

> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Paul Durrant 
> ---
>  xen/arch/x86/hvm/ioreq.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 9435291e87..2275278305 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -811,7 +811,10 @@ int hvm_create_ioreq_server(struct domain *d, bool
> is_default,
> 
>  rc = hvm_ioreq_server_init(s, d, bufioreq_handling, i);
>  if ( rc )
> +{
> +set_ioreq_server(d, i, NULL);
>  goto fail;
> +}
> 
>  if ( i == DEFAULT_IOSERVID )
>  hvm_ioreq_server_enable(s);
> @@ -825,8 +828,6 @@ int hvm_create_ioreq_server(struct domain *d, bool
> is_default,
>  return 0;
> 
>   fail:
> -set_ioreq_server(d, i, NULL);
> -
>  spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
>  domain_unpause(d);
> 
> --
> 2.11.0


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

[Xen-devel] Xen 4.7.5 and 4.9.2 released

[Lars Kurth]

All,

I am pleased to announce the releases of Xen 4.7.5 and Xen 4.9.2. These are
available immediately from their git repositories and Xen Project download 
pages (where a list of changes can also be found).

We recommend all users of the 4.7 and 4.9 stable series to update to these
latest point releases.

Xen 4.7.5
=

http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7
(tag RELEASE-4.7.5) 

http://www.xenproject.org/downloads/xen-archives/xen-project-47-series/xen-475.html


Xen 4.9.2
=

http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9
(tag RELEASE-4.9.2) 

http://www.xenproject.org/downloads/xen-archives/xen-project-49-series/xen-492.html


Regards, Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] x86/hvm/ioreq: fix out of bounds access in error path

[Wei Liu]

It is possible to call the error path with i pointing beyond the end
of the array.

There is another bug that if there is already a default ioreq server,
the code will actually sets the element to NULL, hence leaking memory.

Move setting NULL to where it is needed.

Coverity-ID: 1433777
Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
 xen/arch/x86/hvm/ioreq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 9435291e87..2275278305 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -811,7 +811,10 @@ int hvm_create_ioreq_server(struct domain *d, bool 
is_default,
 
 rc = hvm_ioreq_server_init(s, d, bufioreq_handling, i);
 if ( rc )
+{
+set_ioreq_server(d, i, NULL);
 goto fail;
+}
 
 if ( i == DEFAULT_IOSERVID )
 hvm_ioreq_server_enable(s);
@@ -825,8 +828,6 @@ int hvm_create_ioreq_server(struct domain *d, bool 
is_default,
 return 0;
 
  fail:
-set_ioreq_server(d, i, NULL);
-
 spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
 domain_unpause(d);
 
-- 
2.11.0


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

[Xen-devel] [xen-unstable-coverity test] 121767: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  913acc1aa019054742217926dea0827e7a9df02e
baseline version:
 xen  6bbcb226cebac90f8ce5ac901e000bfd3ad783c5

Last test of basis   121636  2018-04-01 09:20:32 Z3 days
Testing same since   121767  2018-04-04 09:39:19 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Daniel De Graaf 
  Jan Beulich 
  Julien Grall 
  Maran Wilson 
  Paul Durrant 
  Roger Pau Monne 
  Roger Pau Monné 
  Stefano Stabellini 
  Stefano Stabellini 
  Wei Liu 

jobs:
 coverity-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 :

To xenbits.xen.org:/home/xen/git/xen.git
   6bbcb226ce..913acc1aa0  913acc1aa019054742217926dea0827e7a9df02e -> 
coverity-tested/smoke

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

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

[Lars Kurth]

Alright,
these are now at 
* 
https://xenproject.org/downloads/xen-archives/xen-project-47-series/xen-475.html
* 
https://xenproject.org/downloads/xen-archives/xen-project-49-series/xen-492.html
Blog post and mails will follow shortly (as Jan is OO today)
Regards
Lars

On 04/04/2018, 11:37, "Lars Kurth"  wrote:

Folks,
I have not created the webpages for these. The script I am using to 
generate these depends on a script in xsa.git, which fails at the moment due to 
a missing new package dependency that I can't resolve as I don't have root 
access
Lars 

On 04/04/2018, 10:59, "Julien Grall"  wrote:

Hi Stefano,

On 04/04/18 00:55, Stefano Stabellini wrote:
> On Tue, 3 Apr 2018, Julien Grall wrote:
>> Hi,
>>
>> On 16/03/18 17:15, Julien Grall wrote:
>>>
>>>
>>> On 16/03/2018 16:56, Julien Grall wrote:
 Hi Stefano,

 On 16/03/2018 16:33, Stefano Stabellini wrote:
> On Fri, 16 Mar 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 15/03/18 23:52, Stefano Stabellini wrote:
>>> On Wed, 14 Mar 2018, Stefano Stabellini wrote:
 After looking at the test results, which are good for arm, and
 considering that master hasn't passed yet after 2 more days, I
 agree
 with Julien: I think we should not release 4.9.2 and 4.7.5 
without
 the
 arm64 spectre patches. At this point, I'll proceed to backport 
the
 patches now.
>>>
>>> Julien, Andre,
>>>
>>> Please give a look at the following branches:
>>>
>>> git://xenbits.xen.org/people/sstabellini/xen-unstable.git
>>> staging-4.7-spectre
>>> git://xenbits.xen.org/people/sstabellini/xen-unstable.git
>>> staging-4.8-spectre
>>> git://xenbits.xen.org/people/sstabellini/xen-unstable.git
>>> staging-4.9-spectre
>>
>> For all of the tree above, as I said yesterday, I clearly don't 
want
>> to see
>> the smccc framework backport for Xen 4.9 and older. This is a 
massive
>> changes
>> of the interface that is not necessary for spectre. My main 
concern is
>> making
>> SMC instruction available to the guest.
>>
>> It would be just sufficient to emulate the few SMCCC function ID 
we
>> care in
>> do_trap_psci (function can be renamed).
>>
>> This is also clearly wrong to backport coding style or code
>> non-justified code
>> movement (sysreg) just to please the cherry-pick.
>>
>> I am also worry to bump the version of the emulated PSCI (0.2 -> 
1.0)
>> for
>> those releases. Some guests may rely on a specific version and 
may now
>> crashes.
>>
>> Overall, the right way to support spectre in earlier releases is
>> custom patch
>> and only do minimal modification.
>>
>>> git://xenbits.xen.org/people/sstabellini/xen-unstable.git
>>> staging-4.10-spectre
>>
>> The patches below should not be part of spectre nor backport to 
4.10:
>> - 82e29c87dc7f4f2a7e2f111c3646479da21a910a "ARM: remove 
unneeded
>> gic.h
>> inclusions"
>> - 79563717c9dd5383abcf0ba94d813de9b42e3793 "xen/arm: psci: 
Prefix
>> with
>> static any functions not exported"
>> - 6d0e9b21b1f7213c1994cc2d636448ee2d5372c2 "xen/arm: vpsci: 
Update
>> the
>> return type for MIGRATE_INFO_TYPE"
>>
>> The patches below should not be part of spectre but candidate to 
4.10:
>> - c2d70f77cc7987be164cd87b76459782497fc540 "xen/arm: vpsci: 
Rework
>> the logic
>> to start AArch32 vCPU in Thumb mode"
>>
>> You will also want to backport [1] which address a relaxation of 
the
>> ARM_SMCCC_ARCH_WORKAROUND_1.
>
> I understand your concerns, in that case could you please provide 
the
> git branches?

 That will have to wait when I have spare cycle. Most likely 
somewhere in
 April when I am done from the Xen 4.11 patches and back from 
holidays.

 So It is probably the right time to put into contribution 
stakeholders who
 are using those Xen 4.* stable releases.
>>>
>>> To be clear, for Xen 4.10 it is just a matter of dropping the 3 
patches I
>>> suggested. There 

[Xen-devel] [libvirt test] 121735: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 libvirt  849b6a7b6a2fa8207af0ff1160edc8baf109213a
baseline version:
 libvirt  439c27b1ae35e0daab6e86fc6320ea1682a3aabd

Last test of basis   121707  2018-04-02 04:20:30 Z2 days
Testing same since   121735  2018-04-03 04:27:24 Z1 days1 attempts


People who touched revisions under test:
  John Ferlan 
  Kashyap Chamarthy 

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



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

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

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

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


Not 

Re: [Xen-devel] Xen development link

[Praveen Kumar]

On Wed, Apr 4, 2018 at 3:50 PM, Roger Pau Monné  wrote:
> On Wed, Apr 04, 2018 at 02:40:45PM +0530, Praveen Kumar wrote:
>> On Wed, Apr 4, 2018 at 2:32 PM, Praveen Kumar  
>> wrote:
>> > On Wed, Apr 4, 2018 at 1:11 PM, Roger Pau Monné  
>> > wrote:
>> >> On Wed, Apr 04, 2018 at 10:08:29AM +0530, Praveen Kumar wrote:
>> >>> Hi,
>> >>>
>> >>> I came across Xen development link (
>> >>> https://xenorg.uservoice.com/forums/172169-xen-development ) which was
>> >>> lastly updated in Jul 2017 ( around ).
>> >>> This looks great to me, but just wanted to check if we are still
>> >>> following and updating the ideas ? Or is there any other link / forum,
>> >>> where we update and share.
>> >>
>> >> I think some maintainers use:
>> >>
>> >> https://xenproject.atlassian.net/projects/XEN/board
>> >>
>> Is this a closed / private portal ?
>
> What do you mean by closed?
>
> I can access it just fine without being logged in at all. AFAIK this
> is to be used by maintainers to track items.

True, I am able to access the page. But tried the login option with my
email ( kpraveen.l...@gmail.com),
which mentioned access denied ! So thought of asking in the forum.

I was in a opinion that, there will be more details w.r.t. the items
mentioned, which will be shown,
when an individual login :-)

>
>> If that's not the case, and we can get the access, can you please
>> guide whom to request for,
>> as I am not able to get the administrator's email / link to approach
>
> Adding Lars.
>

Regards,

~Praveen

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

Re: [Xen-devel] [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

[Daniel Kiper]

On Tue, Apr 03, 2018 at 10:00:52AM -0700, James Bottomley wrote:
> On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote:
> > On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote:

[...]

> > > This looks like a bad idea: you're duplicating the secure boot
> > > check in
> > >
> > > drivers/firmware/efi/libstub/secureboot.c
> > >
> > > Which is an implementation of policy.  If we have to have policy in
> > > the kernel, it should really only be in one place to prevent drift;
> > > why can't you simply use the libstub efi_get_secureboot() so we're
> > > not duplicating the implementation of policy?
> >
> > Well, here is the first version of this patch:
> > https://lkml.org/lkml/2018/1/9/496 Ard did not like it. I was not
> > happy too. In general both approaches are not perfect. More you can
> > find in the discussion around this patchset. If you have better idea
> > how to do that I am happy to implement it.
>
> One way might be simply to have the pre exit-boot-services code lay
> down a variable containing the state which you pick up, rather than you

Do you mean variable in kernel proper or something like that? If yes this
is not possible. EFI Linux stub is not executed in Xen dom0. All UEFI
infrastructure is owned and operated by Xen. Dom0 kernel can access some
stuff in UEFI, including variables, via hypercall. However, when dom0
runs only UEFI runtime services are available.

> calling efi code separately and trying to use the insecure RT

I am not sure why they are insecure.

> variables.  That way there's a uniform view of the internal kernel
> secure boot state that everyone can use.

That would be perfect but I have a feeling that in form proposed above
it is not possible.

Daniel

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

[Xen-devel] Patches for stable

[Juergen Gross]

Please add the patches:

commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
commit dfc9327ab7c99bc13e12106448615efba833886b upstream
commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream

to the 4.15 and 4.16 stable kernels.

Those patches are needed to boot Linux as PVH guest on recent Xen.
In PVH mode there is no guarantee the kernel can find the RSDP table
at the legacy location in low memory, which is a requirement for the
kernel to boot successful without those patches.

For kernel 4.14 I'll send a slightly modified version of the patches
soon.


Juergen

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

Re: [Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[Juergen Gross]

On 04/04/18 12:07, M A Young wrote:
> On Wed, 4 Apr 2018, Ajay Garg wrote:
> 
>> Since I failed to get a single reply on my original issue as per
>> https://lists.xenproject.org/archives/html/minios-devel/2018-04/msg4.html,
>> so I had no option but to try on a newer xen version.
>>
>> So, I created  a  new virtualbox-guest, and followed the steps as per
>> https://blog.werk21.de/en/2018/02/08/build-xen-hypervisor-410-and-xen-tools-ubuntu-1604-pvh
>>
>> Now, when start the guest with Xen-hypervisor enabled, it does not come up.
>> I took serial-logs at bootup time, they are as follows :
>>
>> #
>>  Xen 4.10.1-pre
>> (XEN) Xen version 4.10.1-pre (ajay@) (gcc (Ubuntu
>> 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609) debug=n  Wed Apr  4 12:54:58
>> IST 2018
>> (XEN) Latest ChangeSet: Tue Mar 20 14:23:14 2018 +0100 git:0f92968
>> (XEN) Bootloader: GRUB 2.02~beta2-36ubuntu3.17
>> (XEN) Command line: placeholder console=com1 com1=115200,8n1
>> loglvl=all guest_loglvl=all
>> (XEN) Xen image load base address: 0
>> (XEN) Video information:
>> (XEN)  VGA is text mode 80x25, font 8x16
>> (XEN) Disc information:
>> (XEN)  Found 1 MBR signatures
>> (XEN)  Found 1 EDD information structures
>> (XEN) Xen-e820 RAM map:
>> (XEN)   - 0009fc00 (usable)
>> (XEN)  0009fc00 - 000a (reserved)
>> (XEN)  000f - 0010 (reserved)
>> (XEN)  0010 - bfff (usable)
>> (XEN)  bfff - c000 (ACPI data)
>> (XEN)  fec0 - fec01000 (reserved)
>> (XEN)  fee0 - fee01000 (reserved)
>> (XEN)  fffc - 0001 (reserved)
>> (XEN) New Xen image base address: 0xbf80
>> (XEN) System RAM: 3071MB (3145276kB)
>> (XEN) ACPI: RSDP 000E, 0024 (r2 VBOX  )
>> (XEN) ACPI: XSDT BFFF0030, 003C (r1 VBOX   VBOXXSDT1 ASL61)
>> (XEN) ACPI: FACP BFFF00F0, 00F4 (r4 VBOX   VBOXFACP1 ASL61)
>> (XEN) ACPI: DSDT BFFF0470, 21FF (r2 VBOX   VBOXBIOS2 INTL 20160108)
>> (XEN) ACPI: FACS BFFF0200, 0040
>> (XEN) ACPI: APIC BFFF0240, 0054 (r2 VBOX   VBOXAPIC1 ASL61)
>> (XEN) ACPI: SSDT BFFF02A0, 01CC (r1 VBOX   VBOXCPUT2 INTL 20160108)
>> (XEN) No NUMA configuration found
>> (XEN) Faking a node at -bfff
>> (XEN) Domain heap initialised
>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 142 (0x8e), Stepping 9
>> (raw 000806e9)
>> (XEN) found SMP MP-table at 0009fff0
>> (XEN) DMI 2.5 present.
>> (XEN) Using APIC driver default
>> (XEN) ACPI: PM-Timer IO Port: 0x4008 (32 bits)
>> (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:4004,1:0], pm1x_evt[1:4000,1:0]
>> (XEN) ACPI: wakeup_vec[bfff020c], vec_size[20]
>> (XEN) ACPI: Local APIC address 0xfee0
>> (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
>> (XEN) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
>> (XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
>> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
>> (XEN) ACPI: IRQ0 used by override.
>> (XEN) ACPI: IRQ2 used by override.
>> (XEN) ACPI: IRQ9 used by override.
>> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
>> (XEN) ERST table was not found
>> (XEN) Using ACPI (MADT) for SMP configuration information
>> (XEN) SMP: Allowing 1 CPUs (0 hotplug CPUs)
>> (XEN) IRQ limits: 24 GSI, 184 MSI/MSI-X
>> (XEN) Not enabling x2APIC: depends on iommu_supports_eim.
>> (XEN) xstate: size: 0x440 and states: 0x7
>> (XEN) CPU0: No MCE banks present. Machine check support disabled
>> (XEN) Speculative mitigation facilities:
>> (XEN)   Compiled-in support: INDIRECT_THUNK
>> (XEN) BTI mitigations: Thunk RETPOLINE, Others: RSB_NATIVE RSB_VMEXIT
>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> (XEN) Platform timer is 3.579MHz ACPI PM Timer
>> (XEN) Detected 2712.035 MHz processor.
>> (XEN) Initing memory sharing.
>> (XEN) alt table 82d080421798 -> 82d080423244
>> (XEN) I/O virtualisation disabled
>> (XEN) nr_sockets: 1
>> (XEN) ENABLING IO-APIC IRQs
>> (XEN)  -> Using new ACK method
>> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>> (XEN) Allocated console ring of 16 KiB.
>> (XEN) Brought up 1 CPUs
>> (XEN) build-id: 0734050809e0cb9f52e65322a0d3911d082e348b
>> (XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'.
>> (XEN) ACPI sleep modes: S3
>> (XEN) VPMU: disabled
>> (XEN) xenoprof: Initialization failed. Intel processor family 6 model
>> 142 is not supported
>> (XEN) Dom0 has maximum 208 PIRQs
>> (XEN) NX (Execute Disable) protection active
>> (XEN) *** LOADING DOMAIN 0 ***
>> (XEN)  Xen  kernel: 64-bit, lsb, compat32
>> (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x2957000
>> (XEN) PHYSICAL MEMORY ARRANGEMENT:
>> (XEN)  Dom0 alloc.:   b400->b800 

Re: [Xen-devel] Xen development link

[Roger Pau Monné]

On Wed, Apr 04, 2018 at 02:40:45PM +0530, Praveen Kumar wrote:
> On Wed, Apr 4, 2018 at 2:32 PM, Praveen Kumar  wrote:
> > On Wed, Apr 4, 2018 at 1:11 PM, Roger Pau Monné  
> > wrote:
> >> On Wed, Apr 04, 2018 at 10:08:29AM +0530, Praveen Kumar wrote:
> >>> Hi,
> >>>
> >>> I came across Xen development link (
> >>> https://xenorg.uservoice.com/forums/172169-xen-development ) which was
> >>> lastly updated in Jul 2017 ( around ).
> >>> This looks great to me, but just wanted to check if we are still
> >>> following and updating the ideas ? Or is there any other link / forum,
> >>> where we update and share.
> >>
> >> I think some maintainers use:
> >>
> >> https://xenproject.atlassian.net/projects/XEN/board
> >>
> Is this a closed / private portal ?

What do you mean by closed?

I can access it just fine without being logged in at all. AFAIK this
is to be used by maintainers to track items.

> If that's not the case, and we can get the access, can you please
> guide whom to request for,
> as I am not able to get the administrator's email / link to approach

Adding Lars.

Roger.

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

Re: [Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[M A Young]

On Wed, 4 Apr 2018, Ajay Garg wrote:

> Since I failed to get a single reply on my original issue as per
> https://lists.xenproject.org/archives/html/minios-devel/2018-04/msg4.html,
> so I had no option but to try on a newer xen version.
> 
> So, I created  a  new virtualbox-guest, and followed the steps as per
> https://blog.werk21.de/en/2018/02/08/build-xen-hypervisor-410-and-xen-tools-ubuntu-1604-pvh
> 
> Now, when start the guest with Xen-hypervisor enabled, it does not come up.
> I took serial-logs at bootup time, they are as follows :
> 
> #
>  Xen 4.10.1-pre
> (XEN) Xen version 4.10.1-pre (ajay@) (gcc (Ubuntu
> 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609) debug=n  Wed Apr  4 12:54:58
> IST 2018
> (XEN) Latest ChangeSet: Tue Mar 20 14:23:14 2018 +0100 git:0f92968
> (XEN) Bootloader: GRUB 2.02~beta2-36ubuntu3.17
> (XEN) Command line: placeholder console=com1 com1=115200,8n1
> loglvl=all guest_loglvl=all
> (XEN) Xen image load base address: 0
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)   - 0009fc00 (usable)
> (XEN)  0009fc00 - 000a (reserved)
> (XEN)  000f - 0010 (reserved)
> (XEN)  0010 - bfff (usable)
> (XEN)  bfff - c000 (ACPI data)
> (XEN)  fec0 - fec01000 (reserved)
> (XEN)  fee0 - fee01000 (reserved)
> (XEN)  fffc - 0001 (reserved)
> (XEN) New Xen image base address: 0xbf80
> (XEN) System RAM: 3071MB (3145276kB)
> (XEN) ACPI: RSDP 000E, 0024 (r2 VBOX  )
> (XEN) ACPI: XSDT BFFF0030, 003C (r1 VBOX   VBOXXSDT1 ASL61)
> (XEN) ACPI: FACP BFFF00F0, 00F4 (r4 VBOX   VBOXFACP1 ASL61)
> (XEN) ACPI: DSDT BFFF0470, 21FF (r2 VBOX   VBOXBIOS2 INTL 20160108)
> (XEN) ACPI: FACS BFFF0200, 0040
> (XEN) ACPI: APIC BFFF0240, 0054 (r2 VBOX   VBOXAPIC1 ASL61)
> (XEN) ACPI: SSDT BFFF02A0, 01CC (r1 VBOX   VBOXCPUT2 INTL 20160108)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at -bfff
> (XEN) Domain heap initialised
> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 142 (0x8e), Stepping 9
> (raw 000806e9)
> (XEN) found SMP MP-table at 0009fff0
> (XEN) DMI 2.5 present.
> (XEN) Using APIC driver default
> (XEN) ACPI: PM-Timer IO Port: 0x4008 (32 bits)
> (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:4004,1:0], pm1x_evt[1:4000,1:0]
> (XEN) ACPI: wakeup_vec[bfff020c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee0
> (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> (XEN) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: IRQ0 used by override.
> (XEN) ACPI: IRQ2 used by override.
> (XEN) ACPI: IRQ9 used by override.
> (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> (XEN) ERST table was not found
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) SMP: Allowing 1 CPUs (0 hotplug CPUs)
> (XEN) IRQ limits: 24 GSI, 184 MSI/MSI-X
> (XEN) Not enabling x2APIC: depends on iommu_supports_eim.
> (XEN) xstate: size: 0x440 and states: 0x7
> (XEN) CPU0: No MCE banks present. Machine check support disabled
> (XEN) Speculative mitigation facilities:
> (XEN)   Compiled-in support: INDIRECT_THUNK
> (XEN) BTI mitigations: Thunk RETPOLINE, Others: RSB_NATIVE RSB_VMEXIT
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Platform timer is 3.579MHz ACPI PM Timer
> (XEN) Detected 2712.035 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) alt table 82d080421798 -> 82d080423244
> (XEN) I/O virtualisation disabled
> (XEN) nr_sockets: 1
> (XEN) ENABLING IO-APIC IRQs
> (XEN)  -> Using new ACK method
> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
> (XEN) Allocated console ring of 16 KiB.
> (XEN) Brought up 1 CPUs
> (XEN) build-id: 0734050809e0cb9f52e65322a0d3911d082e348b
> (XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'.
> (XEN) ACPI sleep modes: S3
> (XEN) VPMU: disabled
> (XEN) xenoprof: Initialization failed. Intel processor family 6 model
> 142 is not supported
> (XEN) Dom0 has maximum 208 PIRQs
> (XEN) NX (Execute Disable) protection active
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN)  Xen  kernel: 64-bit, lsb, compat32
> (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x2957000
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   b400->b800 (715309 pages
> to be allocated)
> (XEN)  Init. ramdisk: bc915000->bf7ffed9
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf c4172f80051effc62f3eceeeced4c0b66a80eb94
baseline version:
 ovmf 5b91bf82c67b586b9588cbe4bbffa1588f6b5926

Last test of basis   121710  2018-04-02 06:30:22 Z2 days
Testing same since   121741  2018-04-03 09:47:46 Z0 days1 attempts


People who touched revisions under test:
  Carsey, Jaben 
  Jaben Carsey 

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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   5b91bf82c6..c4172f8005  c4172f80051effc62f3eceeeced4c0b66a80eb94 -> 
xen-tested-master

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

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

[Lars Kurth]

Folks,
I have not created the webpages for these. The script I am using to generate 
these depends on a script in xsa.git, which fails at the moment due to a 
missing new package dependency that I can't resolve as I don't have root access
Lars 

On 04/04/2018, 10:59, "Julien Grall"  wrote:

Hi Stefano,

On 04/04/18 00:55, Stefano Stabellini wrote:
> On Tue, 3 Apr 2018, Julien Grall wrote:
>> Hi,
>>
>> On 16/03/18 17:15, Julien Grall wrote:
>>>
>>>
>>> On 16/03/2018 16:56, Julien Grall wrote:
 Hi Stefano,

 On 16/03/2018 16:33, Stefano Stabellini wrote:
> On Fri, 16 Mar 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 15/03/18 23:52, Stefano Stabellini wrote:
>>> On Wed, 14 Mar 2018, Stefano Stabellini wrote:
 After looking at the test results, which are good for arm, and
 considering that master hasn't passed yet after 2 more days, I
 agree
 with Julien: I think we should not release 4.9.2 and 4.7.5 without
 the
 arm64 spectre patches. At this point, I'll proceed to backport the
 patches now.
>>>
>>> Julien, Andre,
>>>
>>> Please give a look at the following branches:
>>>
>>> git://xenbits.xen.org/people/sstabellini/xen-unstable.git
>>> staging-4.7-spectre
>>> git://xenbits.xen.org/people/sstabellini/xen-unstable.git
>>> staging-4.8-spectre
>>> git://xenbits.xen.org/people/sstabellini/xen-unstable.git
>>> staging-4.9-spectre
>>
>> For all of the tree above, as I said yesterday, I clearly don't want
>> to see
>> the smccc framework backport for Xen 4.9 and older. This is a massive
>> changes
>> of the interface that is not necessary for spectre. My main concern 
is
>> making
>> SMC instruction available to the guest.
>>
>> It would be just sufficient to emulate the few SMCCC function ID we
>> care in
>> do_trap_psci (function can be renamed).
>>
>> This is also clearly wrong to backport coding style or code
>> non-justified code
>> movement (sysreg) just to please the cherry-pick.
>>
>> I am also worry to bump the version of the emulated PSCI (0.2 -> 1.0)
>> for
>> those releases. Some guests may rely on a specific version and may 
now
>> crashes.
>>
>> Overall, the right way to support spectre in earlier releases is
>> custom patch
>> and only do minimal modification.
>>
>>> git://xenbits.xen.org/people/sstabellini/xen-unstable.git
>>> staging-4.10-spectre
>>
>> The patches below should not be part of spectre nor backport to 4.10:
>> - 82e29c87dc7f4f2a7e2f111c3646479da21a910a "ARM: remove unneeded
>> gic.h
>> inclusions"
>> - 79563717c9dd5383abcf0ba94d813de9b42e3793 "xen/arm: psci: Prefix
>> with
>> static any functions not exported"
>> - 6d0e9b21b1f7213c1994cc2d636448ee2d5372c2 "xen/arm: vpsci: 
Update
>> the
>> return type for MIGRATE_INFO_TYPE"
>>
>> The patches below should not be part of spectre but candidate to 
4.10:
>> - c2d70f77cc7987be164cd87b76459782497fc540 "xen/arm: vpsci: 
Rework
>> the logic
>> to start AArch32 vCPU in Thumb mode"
>>
>> You will also want to backport [1] which address a relaxation of the
>> ARM_SMCCC_ARCH_WORKAROUND_1.
>
> I understand your concerns, in that case could you please provide the
> git branches?

 That will have to wait when I have spare cycle. Most likely somewhere 
in
 April when I am done from the Xen 4.11 patches and back from holidays.

 So It is probably the right time to put into contribution stakeholders 
who
 are using those Xen 4.* stable releases.
>>>
>>> To be clear, for Xen 4.10 it is just a matter of dropping the 3 patches 
I
>>> suggested. There are actually no clash with the current code.
>>
>> Gentle ping. Is there anything blocking to get those patches in Xen 4.10?
> 
> Done! Thanks for the ping!

It looks like the commit 6b270fae7ad462687550a875f714bff18d764416 
"xen/arm: Relax ARM_SMCCC_ARCH_WORKAROUND_1 discovery" is missing in Xen 
4.10.

Cheers,

-- 
Julien Grall


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

[Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[Ajay Garg]

Since I failed to get a single reply on my original issue as per
https://lists.xenproject.org/archives/html/minios-devel/2018-04/msg4.html,
so I had no option but to try on a newer xen version.

So, I created  a  new virtualbox-guest, and followed the steps as per
https://blog.werk21.de/en/2018/02/08/build-xen-hypervisor-410-and-xen-tools-ubuntu-1604-pvh

Now, when start the guest with Xen-hypervisor enabled, it does not come up.
I took serial-logs at bootup time, they are as follows :

#
 Xen 4.10.1-pre
(XEN) Xen version 4.10.1-pre (ajay@) (gcc (Ubuntu
5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609) debug=n  Wed Apr  4 12:54:58
IST 2018
(XEN) Latest ChangeSet: Tue Mar 20 14:23:14 2018 +0100 git:0f92968
(XEN) Bootloader: GRUB 2.02~beta2-36ubuntu3.17
(XEN) Command line: placeholder console=com1 com1=115200,8n1
loglvl=all guest_loglvl=all
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009fc00 (usable)
(XEN)  0009fc00 - 000a (reserved)
(XEN)  000f - 0010 (reserved)
(XEN)  0010 - bfff (usable)
(XEN)  bfff - c000 (ACPI data)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  fffc - 0001 (reserved)
(XEN) New Xen image base address: 0xbf80
(XEN) System RAM: 3071MB (3145276kB)
(XEN) ACPI: RSDP 000E, 0024 (r2 VBOX  )
(XEN) ACPI: XSDT BFFF0030, 003C (r1 VBOX   VBOXXSDT1 ASL61)
(XEN) ACPI: FACP BFFF00F0, 00F4 (r4 VBOX   VBOXFACP1 ASL61)
(XEN) ACPI: DSDT BFFF0470, 21FF (r2 VBOX   VBOXBIOS2 INTL 20160108)
(XEN) ACPI: FACS BFFF0200, 0040
(XEN) ACPI: APIC BFFF0240, 0054 (r2 VBOX   VBOXAPIC1 ASL61)
(XEN) ACPI: SSDT BFFF02A0, 01CC (r1 VBOX   VBOXCPUT2 INTL 20160108)
(XEN) No NUMA configuration found
(XEN) Faking a node at -bfff
(XEN) Domain heap initialised
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 142 (0x8e), Stepping 9
(raw 000806e9)
(XEN) found SMP MP-table at 0009fff0
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x4008 (32 bits)
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:4004,1:0], pm1x_evt[1:4000,1:0]
(XEN) ACPI: wakeup_vec[bfff020c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 1 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 184 MSI/MSI-X
(XEN) Not enabling x2APIC: depends on iommu_supports_eim.
(XEN) xstate: size: 0x440 and states: 0x7
(XEN) CPU0: No MCE banks present. Machine check support disabled
(XEN) Speculative mitigation facilities:
(XEN)   Compiled-in support: INDIRECT_THUNK
(XEN) BTI mitigations: Thunk RETPOLINE, Others: RSB_NATIVE RSB_VMEXIT
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Detected 2712.035 MHz processor.
(XEN) Initing memory sharing.
(XEN) alt table 82d080421798 -> 82d080423244
(XEN) I/O virtualisation disabled
(XEN) nr_sockets: 1
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Allocated console ring of 16 KiB.
(XEN) Brought up 1 CPUs
(XEN) build-id: 0734050809e0cb9f52e65322a0d3911d082e348b
(XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'.
(XEN) ACPI sleep modes: S3
(XEN) VPMU: disabled
(XEN) xenoprof: Initialization failed. Intel processor family 6 model
142 is not supported
(XEN) Dom0 has maximum 208 PIRQs
(XEN) NX (Execute Disable) protection active
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x2957000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   b400->b800 (715309 pages
to be allocated)
(XEN)  Init. ramdisk: bc915000->bf7ffed9
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 8100->82957000
(XEN)  Init. ramdisk: ->
(XEN)  Phys-Mach map: 0080->0080005ac8c0
(XEN)  Start info:82957000->829574b4
(XEN)  Xenstore ring: 

[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  55e0590e4bed56db0ea628826409572c94c54ebf
  Bug not present: ca45928e46e300c5de70a779c2a84d1f0e77b8d2
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/121764/


  commit 55e0590e4bed56db0ea628826409572c94c54ebf
  Author: Wei Liu 
  Date:   Tue Mar 27 17:20:50 2018 +0100
  
  Config.mk: update mini-os commit
  
  Signed-off-by: Wei Liu 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install
 --summary-out=tmp/121764.bisection-summary --basis-template=121272 
--blessings=real,real-bisect xen-unstable 
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 121721 fail [host=italia0] / 121307 [host=baroque0] 121272 [host=elbling0] 
121059 [host=elbling1] 120988 [host=baroque1] 120943 [host=chardonnay0] 120859 
[host=pinot0] 120253 [host=huxelrebe1] 120189 [host=pinot1] 120120 
[host=chardonnay1] 120076 [host=chardonnay0] 120037 [host=fiano0] 120001 
[host=elbling0] 119970 [host=huxelrebe0] 119879 [host=italia1] 119785 
[host=baroque1] 119713 [host=pinot0] 119651 [host=huxelrebe1] 119592 
[host=elbling1] 119521 [host=baroque0] 119451 ok.
Failure / basis pass flights: 121721 / 119451
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c44cfe06dfe2a5f54527e87a48c92a6595d070cc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
641f9ce2fab1b85479c564d9b27dfeb18a93ed87
Basis pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
24470b99c1671dca531c2cf5747eda2f8892ecbc
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#7f3bd8db99746a60bcae1ec4059a4756d19b63c2-c44cfe06dfe2a5f54527e87a48c92a6595d070cc
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#2b033e396f4fa0981bae1213cdacd15775655a97-5c3fdee026a204a59cb392e43a313ab558de9682
 
git://xenbits.xen.org/xen.git#24470b99c1671dca531c2cf5747eda2f8892ecbc-641f9ce2fab1b85479c564d9b27dfeb18a93ed87
adhoc-revtuple-generator: tree discontiguous: linux-pvops
Loaded 5096 nodes in revision graph
Searching for test results:
 119451 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
24470b99c1671dca531c2cf5747eda2f8892ecbc
 119521 [host=baroque0]
 119592 [host=elbling1]
 119651 [host=huxelrebe1]
 119713 [host=pinot0]
 119785 [host=baroque1]
 119970 [host=huxelrebe0]
 119879 [host=italia1]
 120001 [host=elbling0]
 120076 [host=chardonnay0]
 120037 [host=fiano0]
 120189 [host=pinot1]
 120120 [host=chardonnay1]
 120287 [host=pinot0]
 120253 [host=huxelrebe1]
 120405 [host=pinot0]
 120626 [host=pinot0]
 120767 [host=pinot0]
 120859 [host=pinot0]
 120943 [host=chardonnay0]
 120988 [host=baroque1]
 121059 [host=elbling1]
 121272 [host=elbling0]
 121307 [host=baroque0]
 121322 fail irrelevant
 121342 fail irrelevant
 121404 fail irrelevant
 121682 fail c44cfe06dfe2a5f54527e87a48c92a6595d070cc 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
6bbcb226cebac90f8ce5ac901e000bfd3ad783c5
 121699 blocked irrelevant
 121709 pass irrelevant
 121719 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 

Re: [Xen-devel] Xen development link

[Praveen Kumar]

On Wed, Apr 4, 2018 at 2:32 PM, Praveen Kumar  wrote:
> On Wed, Apr 4, 2018 at 1:11 PM, Roger Pau Monné  wrote:
>> On Wed, Apr 04, 2018 at 10:08:29AM +0530, Praveen Kumar wrote:
>>> Hi,
>>>
>>> I came across Xen development link (
>>> https://xenorg.uservoice.com/forums/172169-xen-development ) which was
>>> lastly updated in Jul 2017 ( around ).
>>> This looks great to me, but just wanted to check if we are still
>>> following and updating the ideas ? Or is there any other link / forum,
>>> where we update and share.
>>
>> I think some maintainers use:
>>
>> https://xenproject.atlassian.net/projects/XEN/board
>>
Is this a closed / private portal ?
If that's not the case, and we can get the access, can you please
guide whom to request for,
as I am not able to get the administrator's email / link to approach

Thanks in advance.

Regards,

~Praveen.

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

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

[Julien Grall]

Hi Stefano,

On 04/04/18 00:55, Stefano Stabellini wrote:

On Tue, 3 Apr 2018, Julien Grall wrote:

Hi,

On 16/03/18 17:15, Julien Grall wrote:



On 16/03/2018 16:56, Julien Grall wrote:

Hi Stefano,

On 16/03/2018 16:33, Stefano Stabellini wrote:

On Fri, 16 Mar 2018, Julien Grall wrote:

Hi Stefano,

On 15/03/18 23:52, Stefano Stabellini wrote:

On Wed, 14 Mar 2018, Stefano Stabellini wrote:

After looking at the test results, which are good for arm, and
considering that master hasn't passed yet after 2 more days, I
agree
with Julien: I think we should not release 4.9.2 and 4.7.5 without
the
arm64 spectre patches. At this point, I'll proceed to backport the
patches now.


Julien, Andre,

Please give a look at the following branches:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git
staging-4.7-spectre
git://xenbits.xen.org/people/sstabellini/xen-unstable.git
staging-4.8-spectre
git://xenbits.xen.org/people/sstabellini/xen-unstable.git
staging-4.9-spectre


For all of the tree above, as I said yesterday, I clearly don't want
to see
the smccc framework backport for Xen 4.9 and older. This is a massive
changes
of the interface that is not necessary for spectre. My main concern is
making
SMC instruction available to the guest.

It would be just sufficient to emulate the few SMCCC function ID we
care in
do_trap_psci (function can be renamed).

This is also clearly wrong to backport coding style or code
non-justified code
movement (sysreg) just to please the cherry-pick.

I am also worry to bump the version of the emulated PSCI (0.2 -> 1.0)
for
those releases. Some guests may rely on a specific version and may now
crashes.

Overall, the right way to support spectre in earlier releases is
custom patch
and only do minimal modification.


git://xenbits.xen.org/people/sstabellini/xen-unstable.git
staging-4.10-spectre


The patches below should not be part of spectre nor backport to 4.10:
    - 82e29c87dc7f4f2a7e2f111c3646479da21a910a "ARM: remove unneeded
gic.h
inclusions"
    - 79563717c9dd5383abcf0ba94d813de9b42e3793 "xen/arm: psci: Prefix
with
static any functions not exported"
    - 6d0e9b21b1f7213c1994cc2d636448ee2d5372c2 "xen/arm: vpsci: Update
the
return type for MIGRATE_INFO_TYPE"

The patches below should not be part of spectre but candidate to 4.10:
    - c2d70f77cc7987be164cd87b76459782497fc540 "xen/arm: vpsci: Rework
the logic
to start AArch32 vCPU in Thumb mode"

You will also want to backport [1] which address a relaxation of the
ARM_SMCCC_ARCH_WORKAROUND_1.


I understand your concerns, in that case could you please provide the
git branches?


That will have to wait when I have spare cycle. Most likely somewhere in
April when I am done from the Xen 4.11 patches and back from holidays.

So It is probably the right time to put into contribution stakeholders who
are using those Xen 4.* stable releases.


To be clear, for Xen 4.10 it is just a matter of dropping the 3 patches I
suggested. There are actually no clash with the current code.


Gentle ping. Is there anything blocking to get those patches in Xen 4.10?


Done! Thanks for the ping!


It looks like the commit 6b270fae7ad462687550a875f714bff18d764416 
"xen/arm: Relax ARM_SMCCC_ARCH_WORKAROUND_1 discovery" is missing in Xen 
4.10.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen development link

[Praveen Kumar]

On Wed, Apr 4, 2018 at 1:11 PM, Roger Pau Monné  wrote:
> On Wed, Apr 04, 2018 at 10:08:29AM +0530, Praveen Kumar wrote:
>> Hi,
>>
>> I came across Xen development link (
>> https://xenorg.uservoice.com/forums/172169-xen-development ) which was
>> lastly updated in Jul 2017 ( around ).
>> This looks great to me, but just wanted to check if we are still
>> following and updating the ideas ? Or is there any other link / forum,
>> where we update and share.
>
> I think some maintainers use:
>
> https://xenproject.atlassian.net/projects/XEN/board
>
> To track items. There's also Juergen Xen 4.11 development update
> emails, like:
>
> https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg02050.html
>
> But that's quite release focused.

Thank you Roger !

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

Re: [Xen-devel] [PATCH v11] x86/altp2m: support for setting restrictions for an array of pages

[Razvan Cojocaru]

On 03/30/2018 06:39 PM, Petre Pircalabu wrote:
> From: Razvan Cojocaru 
> 
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2m subsystem, which could only set page restrictions for one
> page at a time. This patch addresses the gap.
> 
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
> hence with the original altp2m design, where domains are allowed - with the
> proper altp2m access rights - to alter these settings), in the absence of an
> official position on the issue from the original altp2m designers.
> 
> Signed-off-by: Razvan Cojocaru 
> Signed-off-by: Petre Pircalabu 
> Acked-by: Wei Liu 

George, should we have added your Reviewed-by with addressing your
comments in this version?


Thanks,
Razvan

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

Re: [Xen-devel] [RFC PATCH] Make Security Policy Doc ready to become a CNA

[Lars Kurth]

Ian,
can we agree on a final URL for the generated docs (the ones generated from 
SUPPORT.md). That would enable me to send out a new series
Lars

From: Lars Kurth 
Date: Wednesday, 21 March 2018 at 09:18
To: George Dunlap 
Cc: Lars Kurth , xen-devel 
, "committ...@xenproject.org" 
, "secur...@xenproject.org" 
Subject: Re: [RFC PATCH] Make Security Policy Doc ready to become a CNA




On 20 Mar 2018, at 17:38, George Dunlap 
> wrote:

On 03/19/2018 04:37 PM, Lars Kurth wrote:

And this time with patch: note to myself - never try sendmail with --compose 
again (-;

This patch contains a proposal to change 
https://xenproject.org/security-policy.html
such that it points to SUPPORT.md. Having scope and process information is 
necessary
to become a CNA. This is the last piece, before formally asking to become a CNA.

To make the review of this easier, I based it on xenbits:/larsk/governance.git
(contains the pandoc as published today and the html)

Regards
Lars
---
[PATCH] Make Security Policy Doc ready to become a CNA

To become a CNA, we need to more clearly specifiy the scope of
security support. This change updates the document and points
to SUPPORT.md and pages generated from SUPPORT.md

Expected changes:
- Resend once the URL that is currently open has been agreed
 with Ian Jackson

Signed-off-by: Lars Kurth >
---
security-policy.pandoc | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/security-policy.pandoc b/security-policy.pandoc
index 5783183..22e274b 100644
--- a/security-policy.pandoc
+++ b/security-policy.pandoc
@@ -19,6 +19,14 @@ Scope of this process

This process primarily covers the [Xen Hypervisor
Project](index.php?option=com_content=article=82:xen-hypervisor=80:developers=484).
+Specific information about features with security support can be found in
+
+1.  [SUPPORT.md](http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md)
+in the releases' tar ball and its xen.git tree and on
+[web pages generated from the SUPPORT.md file](add URL)

Not sure we should include the direct (ugly) link.  Other than that
looks OK to me.

No strong opinion either way. There is no real harm in having it and it's just 
a link on the final document
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen development link

[Roger Pau Monné]

On Wed, Apr 04, 2018 at 10:08:29AM +0530, Praveen Kumar wrote:
> Hi,
> 
> I came across Xen development link (
> https://xenorg.uservoice.com/forums/172169-xen-development ) which was
> lastly updated in Jul 2017 ( around ).
> This looks great to me, but just wanted to check if we are still
> following and updating the ideas ? Or is there any other link / forum,
> where we update and share.

I think some maintainers use:

https://xenproject.atlassian.net/projects/XEN/board

To track items. There's also Juergen Xen 4.11 development update
emails, like:

https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg02050.html

But that's quite release focused.

Roger.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1   fail REGR. vs. 120095
 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 120095

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

version targeted for testing:
 qemuuf184de7553272223d6af731d7d623a7cebf710b5
baseline version:
 qemuu6697439794f72b3501ee16bb95d16854f9981421

Last test of basis   120095  2018-02-28 13:46:33 Z   34 days
Failing since120146  2018-03-02 10:10:57 Z   32 days   21 attempts
Testing same since   121644  2018-04-01 10:43:14 Z2 days3 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alex Bennée 
  Alex Williamson 
  Alexey Kardashevskiy 
  Alistair Francis 
  Alistair Francis 
  Andrew Jones 
  Andrey Smirnov 
  Anton 

Re: [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvhv2-amd

[Juergen Gross]

On 03/04/18 18:55, Sander Eikelenboom wrote:
> On 03/04/18 12:29, Juergen Gross wrote:
>> On 03/04/18 12:19, osstest service owner wrote:
>>> branch xen-unstable
>>> xenbranch xen-unstable
>>> job test-amd64-amd64-xl-pvhv2-amd
>>> testid guest-start
>>>
>>> Tree: linux 
>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>> Tree: xen git://xenbits.xen.org/xen.git
>>>
>>> *** Found and reproduced problem changeset ***
>>>
>>>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>   Bug introduced:  4a5733771e6f33918eba07b584e564a67ac1
>>>   Bug not present: 1c2e0f9e4f263714db917eb54f8d1c2d1463ed4c
>>>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118498/
>>>
>>>
>>>   commit 4a5733771e6f33918eba07b584e564a67ac1
>>>   Author: Juergen Gross 
>>>   Date:   Fri Dec 1 15:14:07 2017 +0100
>>>   
>>>   libxl: put RSDP for PVH guest near 4GB
>>>   
>>>   Instead of locating the RSDP table below 1MB put it just below 4GB
>>>   like the rest of the ACPI tables in case of PVH guests. This will
>>>   avoid punching more holes than necessary into the memory map.
>>>   
>>>   Signed-off-by: Juergen Gross 
>>>   Acked-by: Wei Liu 
>>>   Reviewed-by: Roger Pau Monné 
>>
>> The corresponding Linux kernel patch just made it upstream.
>>
>>
>> Juergen
> 
> Hi Juergen,
> 
> Are those kernel patches heading for linux-stable as well ?

That was the plan. They'll probably need some adjustments.

> 
> I ask this, because it would be nice to be able to use PVH on Xen 4.11 
> release with a distro kernel
> (4.9 or 4.14 stable for instance for Debian).
> PVH worked fine with xen-4.11-to-be up until this commit, so the kernel 
> patches fix this (non-kernel) regression.

This _is_ a kernel regression as the kernel didn't comply to the
PVH ABI. It relied on a not guaranteed behavior of Xen.


Juergen

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

Re: [Xen-devel] [PATCH v4 1/8] x86: NOP out XPTI entry/exit code when it's not in use

[Juergen Gross]

On 03/04/18 19:48, Juergen Gross wrote:
> On 19/03/18 14:37, Jan Beulich wrote:
>> Introduce a synthetic feature flag to use alternative instruction
>> patching to NOP out all code on entry/exit paths. Having NOPs here is
>> generally better than using conditional branches.
>>
>> Also change the limit on the number of bytes we can patch in one go to
>> that resulting from the encoding in struct alt_instr - there's no point
>> reducing it below that limit, and without a check being in place that
>> the limit isn't actually exceeded, such an artificial boundary is a
>> latent risk.
>>
>> Signed-off-by: Jan Beulich 
> 
> Just did a parallel make of the hypervisor with and without the patch,
> with xpti=true and with xpti=false (values in braces are stddev).

The unpatched version was configured differently than the patched one.
So the real numbers are:

   elapsed system  user
unpatched, xpti=false:  89.96 ( 8.07)   97.05 ( 5.69)  178.64 ( 2.39)
unpatched, xpti=true : 113.42 ( 9.80)  165.99 (15.10)  180.99 ( 2.66)
patched,   xpti=false:  90.65 ( 6.63)   99.50 (14.79)  180.35 ( 5.97)
patched,   xpti=true : 111.69 ( 9.93)  163.63 (13.05)  181.22 ( 3.71)

So the XPTI case is a little bit faster with the patch, while the
non-XPTI case is a little bit slower.

Juergen

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