Re: [Xen-devel] Debugging Windows HVM crashes on Ryzen 3xxx series CPUs.
On 25.10.19 19:01, Andrew Cooper wrote: On 24/10/2019 12:57, Steven Haigh wrote: Hi all, I've managed to get the git master version of Xen on this affected system and tries to boot a Windows Server 2016 system. It crashes as per normal. I managed to get these logs, but I'm not quite sure what else to do to debug this issue further. After a collaborative debugging session on IRC, we've identified the problem. Here is a summary. https://www.reddit.com/r/Amd/comments/ckr5f4/amd_ryzen_3000_series_linux_support_and/ is concerning KVM, but it identified that the TOPOEXT feature was important to getting windows to boot. Xen doesn't currently offer TOPOEXT to guests at all. Fixing this is on the TODO list along with the rest of the topology representation swamp. On a hunch, I offered up a XenServer patch which we are still using, in lieu of fixing topology properly. It is logically a revert of ca2eee92df44 as that change wasn't migration safe. With this patch in place, windows works fine. However, I don't think the patch is appropriate to take into 4.13. Furthermore, there is no chance of getting the topology work sorted in the remaining 4.13 timeframe. I'm at a loss for ideas, other than release note it as broken and make fixing it a blocker for 4.14. Thoughts? What about a domain config entry defaulting to "off" selecting the topology modification in libxc you provided for the test? That would just require to add a bool parameter to xc_cpuid_apply_policy(). It might even be possible to select the setting on the affected hardware automatically. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 143153: regressions - trouble: blocked/fail
flight 143153 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/143153/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501 Tests which did not succeed, but are not blocking: build-amd64-xen-freebsd 1 build-check(1) blocked n/a build-amd64-freebsd-again 1 build-check(1) blocked n/a version targeted for testing: freebsd f58c2171d878d3402bc4fa05d0bbe8e7a6c24e31 baseline version: freebsd 14aef6dfca96006e52b8fb920bde7c612ba58b79 Last test of basis 141501 2019-09-20 09:19:51 Z 35 days Failing since141701 2019-09-23 09:19:41 Z 32 days 14 attempts Testing same since 143153 2019-10-25 09:19:50 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> ae alc Alek Pinchuk allanjude ambrisko andrew asomers avg bapt bdragon bdrewery br brooks brueffer bz cem chs cognet cperciva cy dab daichi dchagin dim dougm emaste erj eugen gallatin gjb glebius gonzo grembo grog hrs hselasky ian imp Jacob Keller jeff jhb jhibbits jilles jkim jlh jmg jtl kaktus kan karels kevans kib kp lstewart luporl lwhsu manu marius markj mav mckusick mhorne mjg mm mmacy mmel np olivier oshogbo philip phk Piotr Pietruszewski ray rmacklem royger rrs rstone samm schweikh scottl sef sjg tijl Tom Caputi trasz tsoome tuexen vangyzen vmaffione yuripv Zach Vargas jobs: build-amd64-freebsd-againblocked build-amd64-freebsd fail build-amd64-xen-freebsd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 13362 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-xsm
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-xsm testid xen-boot 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: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 13b86bc4cd648eae69fdcf3d04b2750c76350053 Bug not present: 223cea6a4f0552b86fb25e3b8bbd00469816cd7a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/143182/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-xsm.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-xsm.xen-boot --summary-out=tmp/143182.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-amd64-i386-xl-xsm xen-boot Searching for failure / basis pass: 143087 fail [host=fiano0] / 138849 ok. Failure / basis pass flights: 143087 / 138849 (tree with no url: minios) 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: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest 13b86bc4cd648eae69fdcf3d04b2750c76350053 c530a75c1e6a472b0eb9558310b518f0dfcd8860 53b1dd1036df3839d46bb150f7a8b2037390093a d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 120996f147131eca8af90e30c900bc14bc824d9f 518c935fac4d30b3ec35d4b6add82b17b7d7aca3 Basis pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a c530a75c1e6a472b0eb9558310b518f0dfcd8860 d031fc07eb83c9d13bff3ebac25da458d5a47917 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 843cec0de800a5f925f8071a7f58f3fb1c6b6eb6 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#223cea6a4f0552b86fb25e3b8bbd00469816cd7a-13b86bc4cd648eae69fdcf3d04b2750c76350053 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#d031fc07eb83c9d13bff3ebac25da458d5a47917-53b1dd1036df3839d46bb150f7a8b2037390093a git://xenbits.xen.org/qemu-xen-traditional.\ git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/osstest/seabios.git#30f1e41f04fb4c715d27f987f003cfc31c9ff4f3-120996f147131eca8af90e30c900bc14bc824d9f git://xenbits.xen.org/xen.git#843cec0de800a5f925f8071a7f58f3fb1c6b6eb6-518c935fac4d30b3ec35d4b6add82b17b7d7aca3 adhoc-revtuple-generator: tree discontiguous: linux-2.6 adhoc-revtuple-generator: tree discontiguous: qemu-xen Loaded 3003 nodes in revision graph Searching for test results: 138780 [host=italia1] 138813 [host=albana1] 138849 pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a c530a75c1e6a472b0eb9558310b518f0dfcd8860 d031fc07eb83c9d13bff3ebac25da458d5a47917 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 843cec0de800a5f925f8071a7f58f3fb1c6b6eb6 138897 pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a c530a75c1e6a472b0eb9558310b518f0dfcd8860 d031fc07eb83c9d13bff3ebac25da458d5a47917 d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 843cec0de800a5f925f8071a7f58f3fb1c6b6eb6 138878 fail irrelevant 138899 pass irrelevant 138900 pass irrelevant 138901 pass irrelevant 138902 fail irrelevant 138879 pass irrelevant 138962 fail irrelevant 139003 fail irrelevant 139068 fail irrelevant 139134 fail irrelevant 139237 fail irrelevant 139223 fail irrelevant 139257 fail irrelevant 139324 fail irrelevant 139306 fail irrelevant 139286 fail irrelevant 139338 fail irrelevant 139361 fail irrelevant 139383 fail irrelevant 139408 fail irrelevant 139478 fail irrelevant 139532 fail irrelevant 139584 fail irrelevant 139555 fail irrelevant 139687 fail irrelevant 139616 fail irrelevant 139669 fail irrelevant 139711 fail
[Xen-devel] [PATCH] tools/ocaml: Fix build error with Arch Linux
gcc (GCC) 9.2.0 complains:
xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’:
xentoollog_stubs.c:93:16: error: initialization discards ‘const’ qualifier from
pointer target type [-Werror=discarded-qualifiers]
93 | value *func = caml_named_value(xtl->vmessage_cb) ;
|^~~~
Signed-off-by: Petre Pircalabu
---
tools/ocaml/libs/xentoollog/xentoollog_stubs.c | 4 ++--
tools/ocaml/libs/xl/xenlight_stubs.c | 20 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/ocaml/libs/xentoollog/xentoollog_stubs.c
b/tools/ocaml/libs/xentoollog/xentoollog_stubs.c
index aadc3d1..1f73f26 100644
--- a/tools/ocaml/libs/xentoollog/xentoollog_stubs.c
+++ b/tools/ocaml/libs/xentoollog/xentoollog_stubs.c
@@ -90,7 +90,7 @@ static void stub_xtl_ocaml_vmessage(struct xentoollog_logger
*logger,
CAMLparam0();
CAMLlocalN(args, 4);
struct caml_xtl *xtl = (struct caml_xtl*)logger;
- value *func = caml_named_value(xtl->vmessage_cb) ;
+ const value *func = caml_named_value(xtl->vmessage_cb) ;
char *msg;
if (func == NULL)
@@ -120,7 +120,7 @@ static void stub_xtl_ocaml_progress(struct
xentoollog_logger *logger,
CAMLparam0();
CAMLlocalN(args, 5);
struct caml_xtl *xtl = (struct caml_xtl*)logger;
- value *func = caml_named_value(xtl->progress_cb) ;
+ const value *func = caml_named_value(xtl->progress_cb) ;
if (func == NULL)
caml_raise_sys_error(caml_copy_string("Unable to find
callback"));
diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c
b/tools/ocaml/libs/xl/xenlight_stubs.c
index ff16b87..1181971 100644
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -75,7 +75,7 @@ static void failwith_xl(int error, char *fname)
{
CAMLparam0();
CAMLlocal1(arg);
- static value *exc = NULL;
+ static const value *exc = NULL;
/* First time around, lookup by name */
if (!exc)
@@ -424,7 +424,7 @@ void async_callback(libxl_ctx *ctx, int rc, void
*for_callback)
caml_leave_blocking_section();
CAMLparam0();
CAMLlocal2(error, tmp);
- static value *func = NULL;
+ static const value *func = NULL;
value *p = (value *) for_callback;
if (func == NULL) {
@@ -1133,7 +1133,7 @@ value stub_libxl_xen_console_read_start(value ctx, value
clear)
static void raise_eof(void)
{
- static value *exc = NULL;
+ static const value *exc = NULL;
/* First time around, lookup by name */
if (!exc)
@@ -1274,7 +1274,7 @@ int fd_register(void *user, int fd, void
**for_app_registration_out,
CAMLparam0();
CAMLlocalN(args, 4);
int ret = 0;
- static value *func = NULL;
+ static const value *func = NULL;
value *p = (value *) user;
value *for_app;
@@ -1317,7 +1317,7 @@ int fd_modify(void *user, int fd, void
**for_app_registration_update,
CAMLparam0();
CAMLlocalN(args, 4);
int ret = 0;
- static value *func = NULL;
+ static const value *func = NULL;
value *p = (value *) user;
value *for_app = *for_app_registration_update;
@@ -1356,7 +1356,7 @@ void fd_deregister(void *user, int fd, void
*for_app_registration)
caml_leave_blocking_section();
CAMLparam0();
CAMLlocalN(args, 3);
- static value *func = NULL;
+ static const value *func = NULL;
value *p = (value *) user;
value *for_app = for_app_registration;
@@ -1398,7 +1398,7 @@ int timeout_register(void *user, void
**for_app_registration_out,
CAMLlocal2(sec, usec);
CAMLlocalN(args, 4);
int ret = 0;
- static value *func = NULL;
+ static const value *func = NULL;
value *p = (value *) user;
struct timeout_handles *handles;
@@ -1450,7 +1450,7 @@ int timeout_modify(void *user, void
**for_app_registration_update,
CAMLlocal1(for_app_update);
CAMLlocalN(args, 2);
int ret = 0;
- static value *func = NULL;
+ static const value *func = NULL;
value *p = (value *) user;
struct timeout_handles *handles = *for_app_registration_update;
@@ -1566,7 +1566,7 @@ void event_occurs(void *user, libxl_event *event)
CAMLparam0();
CAMLlocalN(args, 2);
struct user_with_ctx *c_user = (struct user_with_ctx *) user;
- static value *func = NULL;
+ static const value *func = NULL;
if (func == NULL) {
/* First time around, lookup by name */
@@ -1589,7 +1589,7 @@ void disaster(void *user, libxl_event_type type,
CAMLparam0();
CAMLlocalN(args, 4);
struct user_with_ctx *c_user = (struct user_with_ctx *) user;
- static value *func = NULL;
+ static const value *func = NULL;
if (func == NULL) {
/* First time around,
[Xen-devel] [qemu-mainline test] 143143: regressions - FAIL
flight 143143 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/143143/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 142915 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 142915 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142915 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142915 test-armhf-armhf-xl-rtds 12 guest-start fail like 142915 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142915 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142915 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 142915 test-amd64-i386-xl-pvshim12 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-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 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-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-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-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 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-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-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-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: qemuu58560ad254fbda71d4daa6622d71683190070ee2 baseline version: qemuue9d42461920f6f40f4d847a5ba18e90d095ed0b9 Last test of basis 142915 2019-10-19 14:49:41 Z6 days Failing since143030 2019-10-22 11:08:39 Z3 days5 attempts Testing same since 143143 2019-10-25 05:29:45 Z0 days1 attempts People who touched revisions under test: Alexey Kardashevskiy Andreas Schwab Andrew Jones Cornelia Huck Cédric Le Goater David Gibson David Hildenbrand Eduardo Habkost Eric Blake
[Xen-devel] [XEN PATCH 2/3] read a grubenv file if it is next to the grub.cfg file
When a grub.cfg file is found this patch checks if there is grubenv
file in the same directory as the grub.cfg file. If there is it
passes the contents to parse().
Signed-off-by: Michael Young
---
tools/pygrub/src/pygrub | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index ce7ab0eb8c..53a0803817 100755
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -457,10 +457,25 @@ class Grub:
# limit read size to avoid pathological cases
buf = f.read(FS_READ_MAX)
del f
-if sys.version_info[0] < 3:
-self.cf.parse(buf)
+# check for a grubenv file next to the grub.cfg file
+(fdir, fsep, ffile) = self.cf.filename.rpartition("/")
+if fdir != "" and ffile == "grub.cfg":
+fenv = fdir + "/grubenv"
else:
-self.cf.parse(buf.decode())
+fenv = ""
+if fenv != "" and fs.file_exists(fenv):
+fenvf = fs.open_file(fenv)
+grubenv = fenvf.read(FS_READ_MAX)
+del fenvf
+if sys.version_info[0] < 3:
+self.cf.parse(buf, grubenv)
+else:
+self.cf.parse(buf.decode(), grubenv.decode())
+else:
+if sys.version_info[0] < 3:
+self.cf.parse(buf)
+else:
+self.cf.parse(buf.decode())
def image_index(self):
if isinstance(self.cf.default, int):
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [XEN PATCH 1/3] set default kernel from grubenv next_entry or saved_entry
This patch reads the contents of a grubenv file if available, and
uses the value of next_entry (in preference) or of saved_entry to
set the default kernel if there is a matching title or if it is a
number. If either next_entry or saved_entry is set and neither is
used then the default is set to 0.
Signed-off-by: Michael Young
---
tools/pygrub/src/GrubConf.py | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
index 73f1bbed2f..1fc68cadb2 100644
--- a/tools/pygrub/src/GrubConf.py
+++ b/tools/pygrub/src/GrubConf.py
@@ -368,7 +368,7 @@ class Grub2ConfigFile(_GrubConfigFile):
def new_image(self, title, lines):
return Grub2Image(title, lines)
-def parse(self, buf = None):
+def parse(self, buf = None, grubenv = None):
if buf is None:
if self.filename is None:
raise ValueError("No config file defined to parse!")
@@ -379,10 +379,17 @@ class Grub2ConfigFile(_GrubConfigFile):
else:
lines = buf.split("\n")
+if grubenv is not None:
+lines = grubenv.split("\n") + lines
+
in_function = False
img = None
title = ""
menu_level=0
+img_count=0
+saved_entry = ""
+next_entry = ""
+entry_matched = False
for l in lines:
l = l.strip()
# skip blank lines
@@ -408,6 +415,13 @@ class Grub2ConfigFile(_GrubConfigFile):
raise RuntimeError("syntax error: cannot nest menuentry
(%d %s)" % (len(img),img))
img = []
title = title_match.group(1)
+if title == next_entry:
+setattr(self, 'default', img_count)
+entry_matched = True
+if title == saved_entry and not entry_matched:
+setattr(self, 'default', img_count)
+entry_matched = True
+img_count += 1
continue
if l.startswith("submenu"):
@@ -432,6 +446,14 @@ class Grub2ConfigFile(_GrubConfigFile):
(com, arg) = grub_exact_split(l, 2)
+if com == "next_entry":
+next_entry = arg
+continue
+
+if com == "saved_entry":
+saved_entry = arg
+continue
+
if com == "set":
(com,arg) = grub2_handle_set(arg)
@@ -448,6 +470,13 @@ class Grub2ConfigFile(_GrubConfigFile):
pass
else:
logging.warning("Unknown directive %s" %(com,))
+
+if next_entry.isdigit():
+setattr(self, 'default', next_entry)
+elif saved_entry.isdigit() and not entry_matched:
+setattr(self, 'default', saved_entry)
+elif (next_entry != "" or saved_entry != "") and not entry_matched:
+setattr(self, 'default', 0)
if img is not None:
raise RuntimeError("syntax error: end of file with open
menuentry(%d %s)" % (len(img),img))
--
2.21.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [XEN PATCH 3/3] Example Fedora 31 grub.cfg and grubenv files
This patch adds an example grub.cfg and grubenv file for reference
Signed-off-by: Michael Young
---
tools/pygrub/examples/fedora-31.grub.cfg | 200 +++
tools/pygrub/examples/fedora-31.grubenv | 5 +
2 files changed, 205 insertions(+)
create mode 100644 tools/pygrub/examples/fedora-31.grub.cfg
create mode 100644 tools/pygrub/examples/fedora-31.grubenv
diff --git a/tools/pygrub/examples/fedora-31.grub.cfg
b/tools/pygrub/examples/fedora-31.grub.cfg
new file mode 100644
index 00..9ce38d43b7
--- /dev/null
+++ b/tools/pygrub/examples/fedora-31.grub.cfg
@@ -0,0 +1,200 @@
+#
+# DO NOT EDIT THIS FILE
+#
+# It is automatically generated by grub2-mkconfig using templates
+# from /etc/grub.d and settings from /etc/default/grub
+#
+
+### BEGIN /etc/grub.d/00_header ###
+set pager=1
+
+if [ -f ${config_directory}/grubenv ]; then
+ load_env -f ${config_directory}/grubenv
+elif [ -s $prefix/grubenv ]; then
+ load_env
+fi
+if [ "${next_entry}" ] ; then
+ set default="${next_entry}"
+ set next_entry=
+ save_env next_entry
+ set boot_once=true
+else
+ set default="${saved_entry}"
+fi
+
+if [ x"${feature_menuentry_id}" = xy ]; then
+ menuentry_id_option="--id"
+else
+ menuentry_id_option=""
+fi
+
+export menuentry_id_option
+
+if [ "${prev_saved_entry}" ]; then
+ set saved_entry="${prev_saved_entry}"
+ save_env saved_entry
+ set prev_saved_entry=
+ save_env prev_saved_entry
+ set boot_once=true
+fi
+
+function savedefault {
+ if [ -z "${boot_once}" ]; then
+saved_entry="${chosen}"
+save_env saved_entry
+ fi
+}
+
+function load_video {
+ if [ x$feature_all_video_module = xy ]; then
+insmod all_video
+ else
+insmod efi_gop
+insmod efi_uga
+insmod ieee1275_fb
+insmod vbe
+insmod vga
+insmod video_bochs
+insmod video_cirrus
+ fi
+}
+
+terminal_output console
+if [ x$feature_timeout_style = xy ] ; then
+ set timeout_style=menu
+ set timeout=5
+# Fallback normal timeout code in case the timeout_style feature is
+# unavailable.
+else
+ set timeout=5
+fi
+### END /etc/grub.d/00_header ###
+
+### BEGIN /etc/grub.d/01_users ###
+if [ -f ${prefix}/user.cfg ]; then
+ source ${prefix}/user.cfg
+ if [ -n "${GRUB2_PASSWORD}" ]; then
+set superusers="root"
+export superusers
+password_pbkdf2 root ${GRUB2_PASSWORD}
+ fi
+fi
+### END /etc/grub.d/01_users ###
+
+### BEGIN /etc/grub.d/08_fallback_counting ###
+insmod increment
+# Check if boot_counter exists and boot_success=0 to activate this behaviour.
+if [ -n "${boot_counter}" -a "${boot_success}" = "0" ]; then
+ # if countdown has ended, choose to boot rollback deployment,
+ # i.e. default=1 on OSTree-based systems.
+ if [ "${boot_counter}" = "0" -o "${boot_counter}" = "-1" ]; then
+set default=1
+set boot_counter=-1
+ # otherwise decrement boot_counter
+ else
+decrement boot_counter
+ fi
+ save_env boot_counter
+fi
+### END /etc/grub.d/08_fallback_counting ###
+
+### BEGIN /etc/grub.d/10_linux ###
+menuentry 'Fedora (5.3.6-300.fc31.x86_64) 31 (Thirty One)' --class fedora
--class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option
'gnulinux-5.3.6-300.fc31.x86_64-advanced-1dec723d-4bdf-461a-a09b-e71ba5974892' {
+ load_video
+ set gfxpayload=keep
+ insmod gzio
+ insmod part_msdos
+ insmod ext2
+ set root='hd0,msdos1'
+ if [ x$feature_platform_search_hint = xy ]; then
+ search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1'
00c6a44a-1624-4c8f-bd08-bc66ea59edbe
+ else
+ search --no-floppy --fs-uuid --set=root
00c6a44a-1624-4c8f-bd08-bc66ea59edbe
+ fi
+ linux /vmlinuz-5.3.6-300.fc31.x86_64
root=/dev/mapper/fedora_localhost--live-root ro
resume=/dev/mapper/fedora_localhost--live-swap
rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb
quiet
+ initrd /initramfs-5.3.6-300.fc31.x86_64.img
+}
+menuentry 'Fedora (0-rescue-fbc80dcce05d4a1a9b9a7951232a4eeb) 31 (Thirty One)'
--class fedora --class gnu-linux --class gnu --class os --unrestricted
$menuentry_id_option
'gnulinux-0-rescue-fbc80dcce05d4a1a9b9a7951232a4eeb-advanced-1dec723d-4bdf-461a-a09b-e71ba5974892'
{
+ load_video
+ insmod gzio
+ insmod part_msdos
+ insmod ext2
+ set root='hd0,msdos1'
+ if [ x$feature_platform_search_hint = xy ]; then
+ search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1'
00c6a44a-1624-4c8f-bd08-bc66ea59edbe
+ else
+ search --no-floppy --fs-uuid --set=root
00c6a44a-1624-4c8f-bd08-bc66ea59edbe
+ fi
+ linux /vmlinuz-0-rescue-fbc80dcce05d4a1a9b9a7951232a4eeb
root=/dev/mapper/fedora_localhost--live-root ro
resume=/dev/mapper/fedora_localhost--live-swap
rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb
quiet
+ initrd /initramfs-0-rescue-fbc80dcce05d4a1a9b9a7951232a4eeb.img
+}
+
+### END /etc/grub.d/10_linux ###
+
+### BEGIN
[Xen-devel] [XEN PATCH 0/3] read grubenv and set default from it
This series of patches is to improve the parsing by pygrub of grub configuration on Fedora. The current result of parsing is generally that the second kernel listed is set as the default due to a set default=1 line in grub.cfg which is only intended to be reached after repeated boot failures. The patches read the grubenv file (which consists of key=value lines padded to 1024 characters by # characters) to get the values of next_entry and saved_entry, which can be a kernel string or an order number. Unfortunately, for Fedora 31 at least, this is often a BLS-style string so it isn't necessarily useful. The patches use the value of next_entry or of saved_entry to set the default kernel or sets it to the first kernel listed if those values are set but not used. Michael Young (3): set default kernel from grubenv next_entry or saved_entry read a grubenv file if it is next to the grub.cfg file Example Fedora 31 grub.cfg and grubenv files tools/pygrub/examples/fedora-31.grub.cfg | 200 +++ tools/pygrub/examples/fedora-31.grubenv | 5 + tools/pygrub/src/GrubConf.py | 31 +++- tools/pygrub/src/pygrub | 21 ++- 4 files changed, 253 insertions(+), 4 deletions(-) create mode 100644 tools/pygrub/examples/fedora-31.grub.cfg create mode 100644 tools/pygrub/examples/fedora-31.grubenv -- 2.21.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 143178: tolerable all pass - PUSHED
flight 143178 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/143178/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen df663157c638d9778fa3ada9859f968fb240 baseline version: xen ecec150ab5ed6055fc06dcdd6d2c65a4f832abc0 Last test of basis 143165 2019-10-25 15:00:37 Z0 days Testing same since 143178 2019-10-25 19:01:13 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Marek Marczykowski-Górecki 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-amd64pass 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 ecec150ab5..df6631 df663157c638d9778fa3ada9859f968fb240 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 143140: regressions - FAIL
flight 143140 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/143140/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 143023 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 143023 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 143023 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 143023 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 143023 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 143023 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 143023 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 143023 test-arm64-arm64-libvirt 12 guest-start fail REGR. vs. 143023 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 143023 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 143023 test-arm64-arm64-libvirt-qcow2 10 debian-di-install fail REGR. vs. 143023 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 143023 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 143023 version targeted for testing: libvirt bf0e7bdeeb790bc6ba5732623be0d9ff26a5961a baseline version: libvirt 2cff65e4c60ed7b3c0c6a97d526d1f8d52c0e919 Last test of basis 143023 2019-10-22 04:19:26 Z3 days Failing since143051 2019-10-23 04:18:57 Z2 days3 attempts Testing same since 143140 2019-10-25 04:18:46 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Eric Blake Ján Tomko Maya Rashish Michal Privoznik Pavel Hrdina Peter Krempa jobs: build-amd64-xsm pass build-arm64-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 fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmfail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-libvirt fail test-arm64-arm64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-libvirt-pairfail test-amd64-i386-libvirt-pair fail test-arm64-arm64-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-amd64-libvirt-vhd fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1191 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec
On 10/25/19 17:40, Jan Beulich wrote: > On 25.10.2019 17:27, Andrew Cooper wrote: >> On 25/10/2019 13:34, Jan Beulich wrote: >>> On 25.10.2019 14:10, Andrew Cooper wrote: The two choices to unblock 4.13 are this patch, or the previous version which made CONFIG_HARDEN_BRANCH depend on BROKEN, which was even more disliked. >>> Option 3 is to have just the config option, for people to turn this >>> off if they feel like doing so. >> Yes, but no. A facade of security is worse than no security, and I >> don't consider doing that an acceptable solution in this case. > But I thought we all agree that this is something that's presumably > going to remain incomplete (as in not provably complete) altogether > anyway. It's just that without the change here it's far more > incomplete then with it. > > In any event I think we should (also) have an opinion from the people > who had originally contributed this logic. You didn't Cc anyone of > them; I've added at least Norbert now. Thanks for adding me. I had a quick look into the discussion. Only making adding lfence statements around conditionals depending on config BROKEN does not help, as it would still need to be always_inline to work as expected, correct? Hence, in my opinion, this patch does the right thing to benefit from the lfences that are placed after evaluation conditionals. From a "is this lfence required" point of view, we have been able to trigger loads where the lfence has not been present, and could not reproduce any more once we added the lfence statements on both branches after the conditional jump. Best, Norbert > > Jan Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.4 test] 143138: regressions - FAIL
flight 143138 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/143138/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-pvshim 12 guest-start fail in 142901 pass in 143138 test-amd64-i386-libvirt-pair 21 guest-start/debian fail in 142901 pass in 143138 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 142901 pass in 143138 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 142901 pass in 143138 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 142901 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-arm64-arm64-examine 8 reboot fail never pass test-arm64-arm64-xl-credit2 7 xen-boot fail never pass test-arm64-arm64-xl-seattle 7 xen-boot fail never pass test-arm64-arm64-xl-xsm 7 xen-boot fail never pass test-arm64-arm64-libvirt-xsm 7 xen-boot fail never pass test-arm64-arm64-xl-credit1 7 xen-boot fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 7 xen-boot fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-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-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 7 xen-boot fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop 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-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail
[Xen-devel] [xen-unstable-smoke test] 143165: tolerable all pass - PUSHED
flight 143165 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/143165/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen ecec150ab5ed6055fc06dcdd6d2c65a4f832abc0 baseline version: xen 64b5d83460af4654b88c6598ede7e74dd37dce2e Last test of basis 143151 2019-10-25 09:02:46 Z0 days Testing same since 143165 2019-10-25 15:00:37 Z0 days1 attempts People who touched revisions under test: Marek Marczykowski-Górecki Roger Pau Monné 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-amd64pass 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 64b5d83460..ecec150ab5 ecec150ab5ed6055fc06dcdd6d2c65a4f832abc0 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 143133: regressions - FAIL
flight 143133 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/143133/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-livepatch7 xen-boot fail REGR. vs. 142750 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 142750 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142750 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142750 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142750 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142750 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142750 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 142750 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 142750 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142750 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142750 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142750 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-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-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 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-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen
[Xen-devel] [RFC XEN PATCH for-4.13 2/4] libxl: Introduce libxl__ev_qmplock
This lock will be used to prevent concurrent access the QEMU's QMP
socket. It is based on libxl__ev_devlock implementation and have the
same properties.
There is one addition to the ev_devlock API,
libxl__ev_qmplock_dispose, which allow to cancel the lock operation
while it is in Active state.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.c | 31 ++-
tools/libxl/libxl_internal.h | 14 ++
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 0750b69cba61..afbb01c5722f 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -583,17 +583,25 @@ void libxl__ev_devlock_init(libxl__ev_devlock *lock)
lock->held = false;
}
+static void ev_lock_lock(libxl__egc *egc, libxl__ev_devlock *lock,
+ const char *userdata_userid);
static void ev_lock_prepare_fork(libxl__egc *egc, libxl__ev_devlock *lock);
static void ev_lock_child_callback(libxl__egc *egc, libxl__ev_child *child,
pid_t pid, int status);
void libxl__ev_devlock_lock(libxl__egc *egc, libxl__ev_devlock *lock)
+{
+ev_lock_lock(egc, lock, "libxl-device-changes-lock");
+}
+
+static void ev_lock_lock(libxl__egc *egc, libxl__ev_devlock *lock,
+ const char *userdata_userid)
{
STATE_AO_GC(lock->ao);
const char *lockfile;
lockfile = libxl__userdata_path(gc, lock->domid,
-"libxl-device-changes-lock", "l");
+userdata_userid, "l");
if (!lockfile) goto out;
lock->path = libxl__strdup(NOGC, lockfile);
@@ -757,6 +765,27 @@ void libxl__ev_devlock_unlock(libxl__gc *gc,
libxl__ev_devlock *lock)
libxl__ev_devlock_init(lock);
}
+void libxl__ev_qmplock_init(libxl__ev_qmplock *lock)
+{
+libxl__ev_devlock_init(lock);
+}
+
+void libxl__ev_qmplock_lock(libxl__egc *egc, libxl__ev_qmplock *lock)
+{
+ev_lock_lock(egc, lock, "qmp-socket-lock");
+}
+
+void libxl__ev_qmplock_unlock(libxl__gc *gc, libxl__ev_qmplock *lock)
+{
+libxl__ev_devlock_unlock(gc, lock);
+}
+
+void libxl__ev_qmplock_dispose(libxl__gc *gc, libxl__ev_qmplock *lock)
+{
+libxl__ev_child_kill(lock->ao, >child);
+libxl__ev_devlock_unlock(gc, lock);
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5823890703ad..115c79d034d4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -197,6 +197,7 @@ typedef struct libxl__device_type libxl__device_type;
typedef struct libxl__json_object libxl__json_object;
typedef struct libxl__carefd libxl__carefd;
typedef struct libxl__ev_devlock libxl__ev_devlock;
+typedef struct libxl__ev_devlock libxl__ev_qmplock;
typedef struct libxl__dm_resume_state libxl__dm_resume_state;
typedef struct libxl__ao_device libxl__ao_device;
typedef struct libxl__multidev libxl__multidev;
@@ -4725,6 +4726,19 @@ _hidden void libxl__ev_devlock_init(libxl__ev_devlock *);
_hidden void libxl__ev_devlock_lock(libxl__egc *, libxl__ev_devlock *);
_hidden void libxl__ev_devlock_unlock(libxl__gc *, libxl__ev_devlock *);
+/* libxl__ev_qmplock
+ *
+ * See "Lock for device hotplug, qmp_lock." as it is similar but is used
+ * to regulate access the QEMU's QMP socket.
+ *
+ * libxl__ev_qmplock_dispose: Idle/Active/LockAcquired -> Idle
+ * The callback will not be called anymore.
+ */
+_hidden void libxl__ev_qmplock_init(libxl__ev_qmplock *);
+_hidden void libxl__ev_qmplock_lock(libxl__egc *, libxl__ev_qmplock *);
+_hidden void libxl__ev_qmplock_unlock(libxl__gc *, libxl__ev_qmplock *);
+_hidden void libxl__ev_qmplock_dispose(libxl__gc *, libxl__ev_qmplock *);
+
/* Send control commands over xenstore and wait for an Ack. */
_hidden int libxl__domain_pvcontrol(libxl__egc *egc,
libxl__xswait_state *pvcontrol,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC XEN PATCH for-4.13 0/4] Fix: libxl workaround, multiple connection to single QMP socket
Patch series available in this git branch: https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.fix-ev_qmp-multi-connect-v1 Hi, QEMU's QMP socket doesn't allow multiple concurrent connection. Also, it listen() on the socket with a `backlog' of only 1. On Linux at least, once that backlog is filled connect() will return EAGAIN if the socket fd is non-blocking. libxl may attempt many concurrent connect() attempt if for example a guest is started with several PCI passthrough devices, and a connect() failure lead to a failure to start the guest. Since we can't change the listen()'s `backlog' that QEMU use, we need other ways to workaround the issue. This patch series introduce a lock to acquire before attempting to connect() to the QMP socket. Since the lock might be held for to long, the series also introduce a way to cancel the acquisition of the lock, this means killing the process that tries to get the lock. Alternatively to this craziness, it might be possible to increase the `backlog' value by having libxl opening the QMP socket on behalf of QEMU. But this is only possible with a recent version of QEMU (2.12 or newer, released in Apr 2018, or qemu-xen-4.12 or newer). It would involve to discover QEMU's capability before we start the DM, which libxl isn't capable yet. Cheers, Anthony PERARD (4): libxl: Introduce libxl__ev_child_kill libxl: Introduce libxl__ev_qmplock libxl: libxl__ev_qmp_send now takes an egc libxl_qmp: Have a lock for QMP socket access tools/libxl/libxl_disk.c| 6 +-- tools/libxl/libxl_dm.c | 8 ++-- tools/libxl/libxl_dom_save.c| 2 +- tools/libxl/libxl_dom_suspend.c | 2 +- tools/libxl/libxl_domain.c | 8 ++-- tools/libxl/libxl_event.c | 3 +- tools/libxl/libxl_fork.c| 55 tools/libxl/libxl_internal.c| 31 +- tools/libxl/libxl_internal.h| 53 +-- tools/libxl/libxl_pci.c | 8 ++-- tools/libxl/libxl_qmp.c | 75 + tools/libxl/libxl_usb.c | 28 ++-- 12 files changed, 219 insertions(+), 60 deletions(-) -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC XEN PATCH for-4.13 1/4] libxl: Introduce libxl__ev_child_kill
Allow to kill a child and deregister the callback associated with it.
The death isn't immediate will need to be collected later, so the
ev_child machinery register its own callback.
libxl__ev_child_kill() might be called by an AO operation that is
finishing/cleaning up without a chance for libxl to be notified of the
child death (via SIGCHLD). So it is possible that the application
calls libxl_ctx_free() while there are still child around. To avoid
the application getting unexpected SIGCHLD, the libxl__ao responsible
for killing a child will have to wait until it has been properly
reaped.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_event.c| 3 +-
tools/libxl/libxl_fork.c | 55
tools/libxl/libxl_internal.h | 8 ++
3 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 0370b6acdd1c..f57c16da1fd9 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1891,7 +1891,8 @@ static bool ao_work_outstanding(libxl__ao *ao)
* decrement progress_reports_outstanding, and call
* libxl__ao_complete_check_progress_reports.
*/
-return !ao->complete || ao->progress_reports_outstanding;
+return !ao->complete || ao->progress_reports_outstanding
+|| ao->outstanding_killed_child;
}
void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index eea3d5d4e68e..d99d40107f71 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -678,6 +678,61 @@ int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const
char *what) {
return rc;
}
+typedef struct ev_child_killed {
+libxl__ao *ao;
+libxl__ev_child ch;
+} ev_child_killed;
+static void deregistered_child_callback(libxl__egc *, libxl__ev_child *,
+pid_t, int status);
+
+/*
+ * Allow to send a SIGKILL signal to a child and deregister the death
+ * callback.
+ * state: Active/Idle -> Idle
+ */
+void libxl__ev_child_kill(libxl__ao *ao, libxl__ev_child *ch)
+{
+AO_GC;
+
+if (!libxl__ev_child_inuse(ch))
+return;
+
+pid_t pid = ch->pid;
+
+ev_child_killed *new_ch = GCNEW(new_ch);
+new_ch->ao = ao;
+new_ch->ch.pid = pid;
+new_ch->ch.callback = deregistered_child_callback;
+LIBXL_LIST_INSERT_HEAD(>children, _ch->ch, entry);
+ao->outstanding_killed_child++;
+
+LIBXL_LIST_REMOVE(ch, entry);
+ch->pid = -1;
+int r = kill(pid, SIGKILL);
+if (r)
+LOGE(ERROR, "failed to kill child [%ld]",
+ (unsigned long)pid);
+}
+
+static void deregistered_child_callback(libxl__egc *egc,
+libxl__ev_child *ch,
+pid_t pid,
+int status)
+{
+ev_child_killed *ck = CONTAINER_OF(ch, *ck, ch);
+EGC_GC;
+
+if (status) {
+libxl_report_child_exitstatus(CTX, XTL_ERROR,
+ "killed fork (dying as expected)",
+ pid, status);
+} else {
+LOG(DEBUG, "killed child exit cleanly, unexpected");
+}
+ck->ao->outstanding_killed_child--;
+libxl__ao_complete_check_progress_reports(egc, ck->ao);
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d2d5af746b50..5823890703ad 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -727,6 +727,7 @@ struct libxl__ao {
libxl__poller *poller;
uint32_t domid;
LIBXL_TAILQ_ENTRY(libxl__ao) entry_for_callback;
+int outstanding_killed_child;
};
#define LIBXL_INIT_GC(gc,ctx) do{ \
@@ -1168,6 +1169,13 @@ static inline int libxl__ev_child_inuse(const
libxl__ev_child *childw_out)
* message>". */
_hidden int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const char *what);
+/*
+ * Allow to send a SIGKILL signal to a child and deregister the death
+ * callback.
+ * state: Active/Idle -> Idle
+ */
+_hidden void libxl__ev_child_kill(libxl__ao *ao, libxl__ev_child *ch);
+
/*
* Other event-handling support provided by the libxl event core to
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC XEN PATCH for-4.13 3/4] libxl: libxl__ev_qmp_send now takes an egc
No functionnal changes.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_disk.c| 6 +++---
tools/libxl/libxl_dm.c | 8
tools/libxl/libxl_dom_save.c| 2 +-
tools/libxl/libxl_dom_suspend.c | 2 +-
tools/libxl/libxl_domain.c | 8
tools/libxl/libxl_internal.h| 2 +-
tools/libxl/libxl_pci.c | 8
tools/libxl/libxl_qmp.c | 10 +-
tools/libxl/libxl_usb.c | 28
9 files changed, 39 insertions(+), 35 deletions(-)
diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index 733ad284c866..7cbee3953320 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -776,7 +776,7 @@ static void cdrom_insert_lock_acquired(libxl__egc *egc,
QMP_PARAMETERS_SPRINTF(, "device", "ide-%i", devid);
cis->qmp.callback = cdrom_insert_ejected;
-rc = libxl__ev_qmp_send(gc, >qmp, "eject", args);
+rc = libxl__ev_qmp_send(egc, >qmp, "eject", args);
if (rc) goto out;
} else {
cdrom_insert_ejected(egc, >qmp, NULL, 0); /* must be last */
@@ -884,7 +884,7 @@ static void cdrom_insert_ejected(libxl__egc *egc,
libxl_disk_format_to_string(disk->format),
disk->pdev_path);
qmp->callback = cdrom_insert_addfd_cb;
-rc = libxl__ev_qmp_send(gc, qmp, "add-fd", args);
+rc = libxl__ev_qmp_send(egc, qmp, "add-fd", args);
if (rc) goto out;
has_callback = true;
} else {
@@ -938,7 +938,7 @@ static void cdrom_insert_addfd_cb(libxl__egc *egc,
libxl__qmp_param_add_string(gc, , "arg",
libxl__qemu_disk_format_string(disk->format));
qmp->callback = cdrom_insert_inserted;
-rc = libxl__ev_qmp_send(gc, qmp, "change", args);
+rc = libxl__ev_qmp_send(egc, qmp, "change", args);
out:
if (rc)
cdrom_insert_done(egc, cis, rc); /* must be last */
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index c00356a2f16a..47cf6dda7ec1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2650,7 +2650,7 @@ void libxl__spawn_local_dm(libxl__egc *egc,
libxl__dm_spawn_state *dmss)
dmss->qmp.callback = device_model_qmp_cb;
dmss->qmp.domid = domid;
dmss->qmp.payload_fd = -1;
-rc = libxl__ev_qmp_send(gc, >qmp, "query-status", NULL);
+rc = libxl__ev_qmp_send(egc, >qmp, "query-status", NULL);
if (rc) goto out_close;
}
@@ -2808,7 +2808,7 @@ static void device_model_spawn_outcome(libxl__egc *egc,
dmss->qmp.domid = dmss->guest_domid;
dmss->qmp.payload_fd = -1;
dmss->qmp.callback = device_model_postconfig_chardev;
-rc = libxl__ev_qmp_send(gc, >qmp, "query-chardev", NULL);
+rc = libxl__ev_qmp_send(egc, >qmp, "query-chardev", NULL);
if (rc) goto out;
return;
}
@@ -2880,7 +2880,7 @@ static void device_model_postconfig_chardev(libxl__egc
*egc,
}
qmp->callback = device_model_postconfig_vnc;
-rc = libxl__ev_qmp_send(gc, qmp, "query-vnc", NULL);
+rc = libxl__ev_qmp_send(egc, qmp, "query-vnc", NULL);
if (rc) goto out;
return;
@@ -2940,7 +2940,7 @@ static void device_model_postconfig_vnc(libxl__egc *egc,
if (vnc && vnc->passwd) {
qmp->callback = device_model_postconfig_vnc_passwd;
libxl__qmp_param_add_string(gc, , "password", vnc->passwd);
-rc = libxl__ev_qmp_send(gc, qmp, "change-vnc-password", args);
+rc = libxl__ev_qmp_send(egc, qmp, "change-vnc-password", args);
if (rc) goto out;
return;
}
diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
index e70aa1585976..65610e6055a7 100644
--- a/tools/libxl/libxl_dom_save.c
+++ b/tools/libxl/libxl_dom_save.c
@@ -226,7 +226,7 @@ static void domain_suspend_switch_qemu_xen_logdirty
qmp->payload_fd = -1;
qmp->callback = switch_qemu_xen_logdirty_done;
libxl__qmp_param_add_bool(gc, , "enable", enable);
-rc = libxl__ev_qmp_send(gc, qmp, "xen-set-global-dirty-log", args);
+rc = libxl__ev_qmp_send(egc, qmp, "xen-set-global-dirty-log", args);
if (rc) goto out;
return;
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 248dbc33e384..940ac334f4b1 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -545,7 +545,7 @@ void libxl__dm_resume(libxl__egc *egc,
qmp->domid = domid;
qmp->callback = dm_resume_qmp_done;
qmp->payload_fd = -1;
-rc = libxl__ev_qmp_send(gc, qmp, "cont", NULL);
+rc = libxl__ev_qmp_send(egc, qmp, "cont", NULL);
if (rc) goto out;
break;
default:
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 9d0eb5aed11d..621df32c5dd8 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1600,7 +1600,7 @@ int libxl_set_vcpuonline(libxl_ctx
[Xen-devel] [RFC XEN PATCH for-4.13 4/4] libxl_qmp: Have a lock for QMP socket access
FIXME: The case where something failed when trying to acquired the
lock isn't handled yet.
This patch workaround the fact that it's not possible to connect
multiple time to a single QMP socket. QEMU listen on the socket with
a backlog value of 1, which mean that on Linux when concurrent thread
call connect() on the socket, they get EAGAIN.
To work around this, we use a new lock.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_internal.h | 29 ++--
tools/libxl/libxl_qmp.c | 65 +---
2 files changed, 71 insertions(+), 23 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ef6655587b79..d650188586e9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -364,6 +364,18 @@ struct libxl__ev_child {
LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
};
+struct libxl__ev_devlock {
+/* filled by user */
+libxl__ao *ao;
+libxl_domid domid;
+void (*callback)(libxl__egc *, libxl__ev_devlock *, int rc);
+/* private to libxl__ev_devlock* */
+libxl__ev_child child;
+char *path; /* path of the lock file itself */
+int fd;
+bool held;
+};
+
/*
* QMP asynchronous calls
*
@@ -428,6 +440,8 @@ _hidden void libxl__ev_qmp_dispose(libxl__gc *gc,
libxl__ev_qmp *ev);
typedef enum {
/* initial state */
qmp_state_disconnected = 1,
+/* waiting for lock */
+qmp_state_waiting_lock,
/* connected to QMP socket, waiting for greeting message */
qmp_state_connecting,
/* qmp_capabilities command sent, waiting for reply */
@@ -461,6 +475,7 @@ struct libxl__ev_qmp {
libxl__carefd *cfd;
libxl__ev_fd efd;
libxl__qmp_state state;
+libxl__ev_qmplock lock;
int id;
int next_id;/* next id to use */
/* receive buffer */
@@ -4686,6 +4701,9 @@ static inline const char *libxl__qemu_qmp_path(libxl__gc
*gc, int domid)
* which may take a significant amount time.
* It is to be acquired by an ao event callback.
*
+ * If libxl__ev_devlock is needed, it should be acquired while every
+ * libxl__ev_qmp are Idle for the current domain.
+ *
* It is to be acquired when adding/removing devices or making changes
* to them when this is a slow operation and json_lock isn't appropriate.
*
@@ -4711,17 +4729,6 @@ static inline const char *libxl__qemu_qmp_path(libxl__gc
*gc, int domid)
* callback: When called: Active -> LockAcquired (on error: Idle)
*The callback is only called once.
*/
-struct libxl__ev_devlock {
-/* filled by user */
-libxl__ao *ao;
-libxl_domid domid;
-void (*callback)(libxl__egc *, libxl__ev_devlock *, int rc);
-/* private to libxl__ev_devlock* */
-libxl__ev_child child;
-char *path; /* path of the lock file itself */
-int fd;
-bool held;
-};
_hidden void libxl__ev_devlock_init(libxl__ev_devlock *);
_hidden void libxl__ev_devlock_lock(libxl__egc *, libxl__ev_devlock *);
_hidden void libxl__ev_devlock_unlock(libxl__gc *, libxl__ev_devlock *);
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f0e0b50bd1c5..1ac50a95a42d 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1084,6 +1084,7 @@ static void dm_state_saved(libxl__egc *egc, libxl__ev_qmp
*ev,
*
* qmp_state External cfdefd id rx_buf* tx_buf* msg*
* disconnected Idle NULL Idlereset freefreefree
+ * waiting_lock Active open Idlereset usedfreeset
* connecting Active open IN reset usedfreeset
* cap.negActive open IN|OUT sent usedcap_neg set
* cap.negActive open IN sent usedfreeset
@@ -1153,6 +1154,10 @@ static void qmp_ev_ensure_reading_writing(libxl__gc *gc,
libxl__ev_qmp *ev)
{
short events = POLLIN;
+if (ev->state == qmp_state_waiting_lock)
+/* We can't modifie the efd yet, as it isn't registered. */
+return;
+
if (ev->tx_buf)
events |= POLLOUT;
else if ((ev->state == qmp_state_waiting_reply) && ev->msg)
@@ -1168,9 +1173,13 @@ static void qmp_ev_set_state(libxl__gc *gc,
libxl__ev_qmp *ev,
switch (new_state) {
case qmp_state_disconnected:
break;
-case qmp_state_connecting:
+case qmp_state_waiting_lock:
assert(ev->state == qmp_state_disconnected);
break;
+case qmp_state_connecting:
+assert(ev->state == qmp_state_disconnected ||
+ ev->state == qmp_state_waiting_lock);
+break;
case qmp_state_capability_negotiation:
assert(ev->state == qmp_state_connecting);
break;
@@ -1231,20 +1240,20 @@ static int
qmp_error_class_to_libxl_error_code(libxl__gc *gc,
/* Setup connection */
-static int qmp_ev_connect(libxl__gc *gc, libxl__ev_qmp *ev)
+static void qmp_ev_lock_aquired(libxl__egc *, libxl__ev_qmplock *, int rc);
+
+static int qmp_ev_connect(libxl__egc *egc,
Re: [Xen-devel] Debugging Windows HVM crashes on Ryzen 3xxx series CPUs.
On 24/10/2019 12:57, Steven Haigh wrote: > Hi all, > > I've managed to get the git master version of Xen on this affected > system and tries to boot a Windows Server 2016 system. It crashes as > per normal. > > I managed to get these logs, but I'm not quite sure what else to do to > debug this issue further. After a collaborative debugging session on IRC, we've identified the problem. Here is a summary. https://www.reddit.com/r/Amd/comments/ckr5f4/amd_ryzen_3000_series_linux_support_and/ is concerning KVM, but it identified that the TOPOEXT feature was important to getting windows to boot. Xen doesn't currently offer TOPOEXT to guests at all. Fixing this is on the TODO list along with the rest of the topology representation swamp. On a hunch, I offered up a XenServer patch which we are still using, in lieu of fixing topology properly. It is logically a revert of ca2eee92df44 as that change wasn't migration safe. With this patch in place, windows works fine. However, I don't think the patch is appropriate to take into 4.13. Furthermore, there is no chance of getting the topology work sorted in the remaining 4.13 timeframe. I'm at a loss for ideas, other than release note it as broken and make fixing it a blocker for 4.14. Thoughts? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] italia1 Re: [xen-unstable test] 143061: regressions - trouble: broken/fail/pass [and 1 more messages]
osstest service owner writes ("[linux-linus test] 143128: regressions -
trouble: broken/fail/pass"):
> flight 143128 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/143128/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 4 host-install(4) broken
> REGR. vs. 133580
> test-amd64-i386-xl-qemuu-win10-i386 4 host-install(4) broken REGR. vs.
> 133580
This was italia1 again. I haven't looked at the detailed logs but
http://logs.test-lab.xenproject.org/osstest/results/host/italia1.html
shows two further periods of `host-install(4) broken'.
I have unblessed it. I think we must consider its PDU port bust and
arrange to have it moved to a new port.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 1/5] make-flight: Rework arch_branch_filter_callback slightly
On 25.10.19 17:48, Ian Jackson wrote: Now we have two lists of things not supported on ARM: one of branches where that's inherent in the branch somehow, and one for those where the kernel is simply too old. The latter are going to differ between armhf and arm64. No functional change. (Verified with standalone-generate-dump-flight-runvars.) Signed-off-by: Ian Jackson For the complete series: Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 143128: regressions - trouble: broken/fail/pass
flight 143128 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/143128/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken test-amd64-i386-xl-qemuu-win10-i386 broken test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 4 host-install(4) broken REGR. vs. 133580 test-amd64-i386-xl-qemuu-win10-i386 4 host-install(4) broken REGR. vs. 133580 test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 133580 test-armhf-armhf-xl-rtds 15 guest-stop fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 133580 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 133580 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 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-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl
[Xen-devel] [OSSTEST PATCH 5/5] other_revision_job_suffix: disregard recursive FreeBSD builds
We aren't actually interested in bisecting the FreeBSD
version (usually, the anointed version) which was used as the platform
for the failed builds. We are thereby making the assumption that any
build failure (or indeed test failure) is the result in changes to the
recent FreeBSD being actually built or used, not the version being
used as a build host.
Achieve ignoring this by having other_revision_job_suffix return a new
magic new value DISCARD, which all callers must know means `skip
this one'. There are three call sites:
In cs-bisection-step:flight_rmap, we skip those rows in the Perl
loop. (We can't skip them conveniently in the SQL because we can't
refer to the column `othrev'; we'd have to duplicate the expression,
or have a subquery. This doesn't seem likely to matter much.)
In cs-bisection-step:preparejob, we always compare the returned suffix
with a fixed value (which eventually came from the previous call). So
DISCARD will never match. No change is needed here.
In Osstest.pm:main_revision_job_cond, we compare the returned suffix
with ''. Again, it will never match and no change is needed.
I have checked that now a cs-bisection-step run chooses a single
FreeBSD master commit to try to build.
CC: Roger Pau Monné
Signed-off-by: Ian Jackson
---
Osstest.pm| 2 +-
cs-bisection-step | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Osstest.pm b/Osstest.pm
index d6c1b709..27136bc9 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -380,7 +380,7 @@ sub other_revision_job_suffix ($$$) {
(CASE
WHEN ($jobfield) LIKE 'build-%-prev' THEN '${separator}prev'
WHEN (($jobfield) LIKE 'build-%-freebsd'
- AND $refrunvar = 'freebsdbuildjob') THEN '${separator}recurse'
+ AND $refrunvar = 'freebsdbuildjob') THEN 'DISCARD'
ELSE ''
END)
END
diff --git a/cs-bisection-step b/cs-bisection-step
index 48208e46..16227234 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -254,6 +254,7 @@ END
my $mixed=0;
my (@ttreenames, @ttreeurls, @trevisions);
while ($row= $sth->fetchrow_hashref()) {
+next if $row->{othrev} eq 'DISCARD';
$row->{longname} =~ m/^tree_/ or die "$row->{longname} ?";
my $name= $'; #'
print DEBUG " $flight.$row->{job} uval=$row->{uval}".
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 1/5] make-flight: Rework arch_branch_filter_callback slightly
Now we have two lists of things not supported on ARM: one of branches
where that's inherent in the branch somehow, and one for those where
the kernel is simply too old. The latter are going to differ between
armhf and arm64.
No functional change.
(Verified with standalone-generate-dump-flight-runvars.)
Signed-off-by: Ian Jackson
---
make-flight | 7 ++-
mfi-common | 4
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/make-flight b/make-flight
index 020ad5f1..f90fe77c 100755
--- a/make-flight
+++ b/make-flight
@@ -189,8 +189,13 @@ arch_branch_filter_callback () {
linux-3.4) return 1;;
linux-3.10) return 1;;
linux-3.14) return 1;;
+esac
+;;
+ esac
+ case "$arch" in
+ arm*)
+case "$branch" in
linux-mingo-tip-master) return 1;;
-linux-*) ;;
qemu-upstream-4.2-testing) return 1;;
qemu-upstream-4.3-testing) return 1;;
qemu-upstream-4.4-testing) return 1;;
diff --git a/mfi-common b/mfi-common
index 7c03ffd4..b40f057e 100644
--- a/mfi-common
+++ b/mfi-common
@@ -288,6 +288,10 @@ create_build_jobs () {
"
;;
arm64)
+ case "$branch" in
+ linux-3.*-testing) continue;;
+ linux-4.[0-4]-testing) continue;;
+ esac
case "$xenbranch" in
xen-3.*-testing) continue;;
xen-4.[0-6]-testing) continue;;
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 4/5] adhoc-revtuple-generator: Bisecting over 5000 commits
Rather than merely 1000. Right now we have a troublesome FreeBSD
build problem which needs this!
Signed-off-by: Ian Jackson
---
adhoc-revtuple-generator | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/adhoc-revtuple-generator b/adhoc-revtuple-generator
index be3f3755..ac0f2463 100755
--- a/adhoc-revtuple-generator
+++ b/adhoc-revtuple-generator
@@ -553,7 +553,7 @@ sub main () {
my @trees_continuous;
foreach my $tree (@trees) {
my $gen= tree_get_gen($tree);
-my $count= 1000;
+my $count= 5000;
my $found= 0;
my $top= undef;
while ($count-- > 0) {
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 3/5] power_cycle_sleep: Change default sleep to 15s
5s is so short that when a host fails to respond we aren't sure if it
was just very idle and ran off its PSU's internal energy storage for
that period.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6b0ee7a2..9c99ee17 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1097,7 +1097,7 @@ sub power_reboot_attempts ($$$;$$) {
sub power_cycle_sleep ($) {
my ($ho) = @_;
-my $to = get_host_property($ho, 'power-cycle-time', 5);
+my $to = get_host_property($ho, 'power-cycle-time', 15);
logm("power-cycle: waiting ${to}s");
sleep($to);
}
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 2/5] make-flight: Drop arm64 with Linux before 4.10
The driver for the laxtons' network cards is not in 4.4 (and that's
quite old). Our ThunderX's may even require something more recent but
we will cross that bridge when we see it.
Effect is to drop the following jobs:
linux-4.1 *arm64*
linux-4.4 *arm64*
linux-4.9 *arm64*
(Checked by eyeballing standalone-generate-dump-flight-runvars diff.)
CC: Julien Grall
CC: Stefano Stabellini
Signed-off-by: Ian Jackson
Acked-by: Julien Grall
---
make-flight | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/make-flight b/make-flight
index f90fe77c..be620c6d 100755
--- a/make-flight
+++ b/make-flight
@@ -183,7 +183,7 @@ job_create_test_filter_callback () {
arch_branch_filter_callback () {
local arch=$1
case "$arch" in
- arm*)
+ armhf)
case "$branch" in
linux-3.0) return 1;;
linux-3.4) return 1;;
@@ -191,6 +191,12 @@ arch_branch_filter_callback () {
linux-3.14) return 1;;
esac
;;
+ arm64)
+case "$branch" in
+linux-3.*) return 1;;
+linux-4.?) return 1;;
+esac
+;;
esac
case "$arch" in
arm*)
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec
On 25.10.2019 17:27, Andrew Cooper wrote: > On 25/10/2019 13:34, Jan Beulich wrote: >> On 25.10.2019 14:10, Andrew Cooper wrote: >>> The two choices to unblock 4.13 are this patch, or the previous version >>> which made CONFIG_HARDEN_BRANCH depend on BROKEN, which was even more >>> disliked. >> Option 3 is to have just the config option, for people to turn this >> off if they feel like doing so. > > Yes, but no. A facade of security is worse than no security, and I > don't consider doing that an acceptable solution in this case. But I thought we all agree that this is something that's presumably going to remain incomplete (as in not provably complete) altogether anyway. It's just that without the change here it's far more incomplete then with it. In any event I think we should (also) have an opinion from the people who had originally contributed this logic. You didn't Cc anyone of them; I've added at least Norbert now. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec
On 25/10/2019 13:34, Jan Beulich wrote: > On 25.10.2019 14:10, Andrew Cooper wrote: >> On 25/10/2019 13:03, Jan Beulich wrote: >>> On 23.10.2019 15:58, Andrew Cooper wrote: evaluate_nospec() is incredibly fragile, and this is one giant bodge. To correctly protect jumps, the generated code needs to be of the form: cmp/test jcc 1f lfence ... 1: lfence ... Critically, the lfence must be at the head of both basic blocks, later in the instruction stream than the conditional jump in need of protection. When a static inline is involved, the optimiser decides to be clever and rearranges the code as: pred: lfence ret call pred cmp $0, %eax jcc 1f ... 1: ... which breaks the speculative safety. >>> Aiui "pred" is a non-inlined static inline here. >> Correct, although it actually applies to anything which the compiler >> chose to out of line, perhaps even as a side effect of CSE pass. > Not sure if you're alluding to such, but I've never seen the compiler > out-of-line something that wasn't a function (or perhaps a specialization > of one) at the source level. I've seen it with LTO in both Clang and GCC, where the compilers can safely reason about the lack of side effects in function calls. > This is the transitive set of predicates which I can spot which need protecting. There are probably ones I've missed. Personally, I'm -1 for this approach, but the only other option for 4.13 is to revert it all to unbreak livepatching. >>> To unbreak livepatching, aiui what you need is symbol disambiguation, >>> a patch for which has been sent. >> Correct, but.. >> >>> With this I think we should focus on >>> code generation aspects here. I'm fine ack-ing the code changes with >>> a modified description. But since you're -1 for this, I'm not sure in >>> the first place that we want to go this route. >> ... without this change, l1tf-barrier/branch-hardening is still broken, >> and a performance overhead. > Well, it has less of an effect, but it's still better than without any > of this altogether. I certainly don't agree with this conclusion. > In some cases code generation is correct, I agree with this, but ... > and in some other cases code generation is at least such that the window size > gets shrunk. ... this isn't accurate. In the case that out-of-lining happens, you get an lfence earlier in the instruction stream, which serialises an unrelated bit of logic (hence the perf hit), and does nothing for the speculation window which the evaluate_nospec() was intending to protect. > >> The two choices to unblock 4.13 are this patch, or the previous version >> which made CONFIG_HARDEN_BRANCH depend on BROKEN, which was even more >> disliked. > Option 3 is to have just the config option, for people to turn this > off if they feel like doing so. Yes, but no. A facade of security is worse than no security, and I don't consider doing that an acceptable solution in this case. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/VT-d: Misc initialisation cleanup
On 24.10.19 19:27, Andrew Cooper wrote: * Initialise all spinlock fields together * No need for an atomic set_bit() to initialise domid_bitmap * Avoid using partial-line printk()'s. * Style fixes (too many, and too few spaces) No functional change. Signed-off-by: Andrew Cooper Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/3] Optionally call EFI SetVirtualAddressMap()
On 24.10.19 05:45, Marek Marczykowski-Górecki wrote: Workaround buggy UEFI accessing boot services memory after ExitBootServices(). Patches discussed here: https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00701.html In addition to the tests below, I've tested kexec on xen.efi with this option enabled and it (still) works. Test results on few laptops: Thinkpad x230, firmware version 2.77: - without the patch: crashes on RS call (mapbs helps) - with patch: works - same with xen.efi and MB2 Librem 14 v1, firmware version (AMI) ARUD026 (06/18/2015): - without the patch: works - with the patch: works - same with xen.efi and MB2 Dell Latitude E6420, firmware version A21: this machine requires efi=attr=uc workaround - without the patch: dom0 hangs before sending any message to the console (even with earlyprintk=xen etc) - with the patch: crashes before dom0 prints anything: mm.c:896:d0v0 non-privileged attempt to map MMIO space 2c2c2c2c2c - same with xen.efi and MB2 Thinkpad W540: - without the patch: crashes on RS call (only efi=no-rs helps) - with patch: works - tested only with MB2 Thinkpad X1 Carbon gen5, firmware version 1.22 (2017-07-04): - without the patch: works - with patch: works - tested only xen.efi Thinkpad P52, firmware version 1.25 (2018-04-15): - without the patch (MB2): hangs on RS call (mapbs helps) - without the patch (xen.efi): works(?!) - with the patch: works - tested with xen.efi and MB2 Tested-by: Marek Marczykowski-Górecki Dell Latitude 5580, firmware 1.16.0 - without the patch: works - with patch: works - tested only xen.efi Tested-by: Jason Andryuk Changes in v2: - fix boot with xen.efi (efi_memmap at this point still needs to be accessed via physical address). TBH, I don't understand why previous version worked with MB2 - is directmap mapped at this point? Changes in v4: - reword commit messages, drop mentions of kexec - new patch (3) Cc: Juergen Gross Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Cc: Jason Andryuk Marek Marczykowski-Górecki (3): efi: remove old SetVirtualAddressMap() arrangement xen/efi: optionally call SetVirtualAddressMap() xen/efi: use directmap to access runtime services table xen/common/Kconfig | 10 - xen/common/efi/boot.c| 52 +++-- xen/common/efi/runtime.c | 19 +++ 3 files changed, 44 insertions(+), 37 deletions(-) base-commit: 7a4e674905b3cbbe48e81c3222361a7f3579 For the series: Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] x86/altp2m: Add hypercall to create a new view and set sve bits
On 25.10.2019 17:36, Alexandru Stefan ISAILA wrote:
>
>
> On 23.10.2019 14:58, Roger Pau Monné wrote:
>> On Wed, Oct 23, 2019 at 09:11:54AM +, Alexandru Stefan ISAILA wrote:
>>>
>>>
>>> On 03.09.2019 20:24, Tamas K Lengyel wrote:
On Tue, Sep 3, 2019 at 9:53 AM Jan Beulich wrote:
>
> On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.h
>> @@ -244,6 +244,7 @@ struct xen_hvm_altp2m_view {
>> /* Create view only: default access type
>> * NOTE: currently ignored */
>> uint16_t hvmmem_default_access; /* xenmem_access_t */
>> +uint8_t set_sve; /* bool value */
>> };
>
> This interface is, given the right configuration, available to
> guests. Hence you can't simply add a field here. Just consider
> what happens for an existing caller when there is random data
> in the field you now assign a meaning.
Perhaps instead of extending the HVMOP it would make more sense to
just add a xl config option that defines the "default" sve bit for
altp2m views in the domain?
>>>
>>> Adding a xl config option will not work for systems that do use xl.
>>> There is a need that this will work in all cases.
>>
>> I assume that such option would be implemented using a DOMCTL, which
>> can also be used by other toolstacks. I however have no idea whether
>> this is a suitable interface or not for this feature.
>>
>
> I think that having a HVMOP_altp2m_get_suppress_ve_multi and letting the
HVMOP_altp2m_set_suppress_ve_multi (sorry for the typo)
> caller provide the start gfn and the nr of pages to have the sve bits
> set will provide a good solution for init an dfor further development.
>
> I will go on this way for version 2 if everyone is ok with this.
>
> Thanks,
> Alex
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
>
> This email was scanned by Bitdefender
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] x86/altp2m: Add hypercall to create a new view and set sve bits
On 23.10.2019 14:58, Roger Pau Monné wrote:
> On Wed, Oct 23, 2019 at 09:11:54AM +, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 03.09.2019 20:24, Tamas K Lengyel wrote:
>>> On Tue, Sep 3, 2019 at 9:53 AM Jan Beulich wrote:
On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -244,6 +244,7 @@ struct xen_hvm_altp2m_view {
>/* Create view only: default access type
> * NOTE: currently ignored */
>uint16_t hvmmem_default_access; /* xenmem_access_t */
> +uint8_t set_sve; /* bool value */
>};
This interface is, given the right configuration, available to
guests. Hence you can't simply add a field here. Just consider
what happens for an existing caller when there is random data
in the field you now assign a meaning.
>>>
>>> Perhaps instead of extending the HVMOP it would make more sense to
>>> just add a xl config option that defines the "default" sve bit for
>>> altp2m views in the domain?
>>>
>>
>> Adding a xl config option will not work for systems that do use xl.
>> There is a need that this will work in all cases.
>
> I assume that such option would be implemented using a DOMCTL, which
> can also be used by other toolstacks. I however have no idea whether
> this is a suitable interface or not for this feature.
>
I think that having a HVMOP_altp2m_get_suppress_ve_multi and letting the
caller provide the start gfn and the nr of pages to have the sve bits
set will provide a good solution for init an dfor further development.
I will go on this way for version 2 if everyone is ok with this.
Thanks,
Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 10/10] ioreq: provide support for long-running operations...
On 30.09.2019 15:32, Roger Pau Monne wrote: > ...and switch vPCI to use this infrastructure for long running > physmap modification operations. > > This allows to get rid of the vPCI specific modifications done to > handle_hvm_io_completion and allows generalizing the support for > long-running operations to other internal ioreq servers. Such support > is implemented as a specific handler that can be registers by internal > ioreq servers and that will be called to check for pending work. > Returning true from this handler will prevent the vcpu from running > until the handler returns false. Is the mentioning of a special handler stale from perhaps a different earlier implementation? Unless I'm overlooking / misunderstanding something here, with this adjusted ... > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/3] xen/efi: optionally call SetVirtualAddressMap()
On 24.10.2019 05:45, Marek Marczykowski-Górecki wrote:
> Some UEFI implementations are not happy about lack of
> SetVirtualAddressMap() call. Likely abuse the address map change
> notification to do things beyond the necessary ConvertPointer() calls.
> Specifically, wihtout the SetVirtualAddressMap() call, some access
> EfiBootServices{Code,Data}, or even totally unmapped areas. Example
> crash of GetVariable() call on Thinkpad W540:
>
> Xen call trace:
>[<0080>] 0080
>[<8c2b0398edaa>] 8c2b0398edaa
>
> Pagetable walk from 858483a1:
>L4[0x1ff] =
>
>
> Panic on CPU 0:
> FATAL PAGE FAULT
> [error_code=0002]
> Faulting linear address: 858483a1
>
>
> Fix this by calling SetVirtualAddressMap() runtime service, giving it
> 1:1 map for areas marked as needed during runtime. The address space in
> which EFI runtime services are called is unchanged, but UEFI view of it
> may be.
> Since it's fairly late in Xen 4.13 development cycle, disable it
> by default and hide behind EXPERT.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/3] efi: remove old SetVirtualAddressMap() arrangement
On 24.10.2019 05:45, Marek Marczykowski-Górecki wrote: > Remove unused (#ifdef-ed out) code. Reviving it in its current shape > won't fly because: > - SetVirtualAddressMap() needs to be called with 1:1 mapping, which >isn't the case at this time > - it uses directmap, which may go away soon > - it uses directmap, which is mapped with NX, breaking EfiRuntimeServicesCode > > No functional change. > > Signed-off-by: Marek Marczykowski-Górecki > Acked-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 3/3] xen/efi: use directmap to access runtime services table
On 24.10.2019 05:45, Marek Marczykowski-Górecki wrote: > Do not require switching page tables to access (static) information in > the runtime services table itself, use directmap for this. This allows > exiting early from XEN_EFI_query_capsule_capabilities, > XEN_EFI_update_capsule and XEN_EFI_query_variable_info (in case of not > supported call) without all the impact of page table switch. > > Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Jan Beulich As said I would have preferred this to be patch 1 of the series. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Tagging livepatch-build-tools.git with Xen releases
Andrew Cooper writes ("Re: [Xen-devel] Tagging livepatch-build-tools.git with
Xen releases"):
> On 25/10/2019 13:27, Ross Lagerwall wrote:
> > On 10/25/19 12:05 PM, Lars Kurth wrote:
> >> Hi all,
> >>
> >> I am wondering whether we should tag livepatch-build-tools.git with
> >> Xen releases
> >>
> >
> > I thought this had been discussed before but I can't find anything in
> > my archives.
>
> I recall a discussion at the time as well.
>
> > IMO livepatch-build-tools is a separate tool that doesn't need to move
> > in lockstep with Xen. I would always recommend using the tip commit
> > since bugs often get fixed around the time that patching is needed.
> > Therefore I don't see any value in tagging it for the time being.
>
> +2 to not being in lockstep. It helps massively with downstream usability.
We can still tag things with Xen release versions just to designate
what we consider part of the overall project release, without implying
that the two need to be in lockstep.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: issue deprecation warning for 32-bit pv guest
On 10/25/19 3:38 AM, Juergen Gross wrote:
> Support for the kernel as Xen 32-bit PV guest will soon be removed.
> Issue a warning when booted as such.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
> ---
> arch/x86/xen/enlighten_pv.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 58f79ab32358..5bfea374a160 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -117,6 +117,14 @@ static void __init xen_banner(void)
> printk(KERN_INFO "Xen version: %d.%d%s%s\n",
> version >> 16, version & 0x, extra.extraversion,
> xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? "
> (preserve-AD)" : "");
> +
> +#ifdef CONFIG_X86_32
> + pr_warn("WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
> WARNING!\n"
> + "Support for running as 32-bit PV-guest under Xen will soon be
> removed\n"
> + "from the Linux kernel!\n"
> + "Please use either a 64-bit kernel or switch to HVM or PVH
> mode!\n"
> + "WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
> WARNING!\n");
> +#endif
> }
>
> static void __init xen_pv_init_platform(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 7/7] x86/nospec: Optimise array_index_mask_nospec() for power-of-2 arrays
On 25.10.2019 14:58, Andrew Cooper wrote:
> On 25/10/2019 13:24, Jan Beulich wrote:
>> On 23.10.2019 15:58, Andrew Cooper wrote:
>>> @@ -21,9 +28,15 @@ static inline unsigned long
>>> array_index_mask_nospec(unsigned long index,
>>> {
>>> unsigned long mask;
>>>
>>> -asm volatile ( "cmp %[size], %[index]; sbb %[mask], %[mask];"
>>> - : [mask] "=r" (mask)
>>> - : [size] "g" (size), [index] "r" (index) );
>>> +if ( __builtin_constant_p(size) && IS_POWER_OF_2(size) )
>>> +{
>>> +mask = size - 1;
>>> +OPTIMIZER_HIDE_VAR(mask);
>> I can't seem to be able to figure why you need this.
>
> Because I found cases where the AND was elided by the compiler entirely
> without it.
Would you mind mentioning this in the description, or in a comment?
>>> --- a/xen/include/xen/config.h
>>> +++ b/xen/include/xen/config.h
>>> @@ -75,6 +75,7 @@
>>> #define GB(_gb) (_AC(_gb, ULL) << 30)
>>>
>>> #define IS_ALIGNED(val, align) (((val) & ((align) - 1)) == 0)
>>> +#define IS_POWER_OF_2(val) ((val) && IS_ALIGNED(val, val))
>> While the risk may seem low for someone to pass an expression with
>> side effect here, evaluating "val" up to three times here doesn't
>> look very desirable.
>
> That is easy to fix.
>
>> As a minor remark, without considering representation I'd expect
>> an expression IS_ALIGNED(val, val) to consistently produce "true"
>> for all non-zero values. E.g. 3 is certainly "aligned" on a
>> boundary of 3.
>
> IS_ALIGNED() comes with an expectation of being against a power of 2,
> because otherwise you'd need a DIV instruction for the general case.
>
> Some users can't cope with a compile time check.
>
>> Finally this may want guarding against use on signed types - at
>> the very least it looks to produce the wrong answer for e.g.
>> INT_MIN or LONG_MIN. I.e. perhaps the expression to the left of
>> && wants to be (val) > 0.
>
> How about the above expansion fix becoming:
>
> ({
> unsigned typeof(val) _val = val;
> _val && (_val & (_val - 1)) == 0;
> })
Well, if the "unsigned typeof()" construct works - why not (with
"val" properly parenthesized, and preferable the leading underscore
changed to a trailing one).
> This check makes no sense on negative numbers.
Of course not, but someone might use it on a signed type and get
back true when it was supposed to be false, just because the value
used ended up being a negative number.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 0/4] iommu: fixes for interrupt remapping enabling
On Fri, Oct 25, 2019 at 03:19:57PM +0200, Jan Beulich wrote: > On 15.10.2019 17:47, Roger Pau Monne wrote: > > Hello, > > > > The following series contain fixes for issues found when enabling > > interrupt remapping and the IO-APIC already has unmasked pins. While I'm > > not aware of any system malfunctioning (apart from reporting IOMMU > > interrupt remapping faults) I think it would be nice to have those in > > 4.13. > > > > The series can also be found at: > > > > git://xenbits.xen.org/people/royger/xen.git iommu_intr_v3 > > > > Thanks, Roger. > > > > Roger Pau Monne (4): > > iommu/amd: support all delivery modes with x2APIC > > x2APIC: simplify resume > > x2APIC: translate IO-APIC entries when enabling the IOMMU > > iommu: translate IO-APIC pins when enabling interrupt remapping > > As mentioned in reply to #1, I think that one should go last. The > other three are ready to be committed, but I'd like to double check > that there's no dependency of any of them on the 1st. I think #1 is fully independent of the rest of the series, and the other three can be committed regardless of #1. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 0/4] iommu: fixes for interrupt remapping enabling
On 15.10.2019 17:47, Roger Pau Monne wrote: > Hello, > > The following series contain fixes for issues found when enabling > interrupt remapping and the IO-APIC already has unmasked pins. While I'm > not aware of any system malfunctioning (apart from reporting IOMMU > interrupt remapping faults) I think it would be nice to have those in > 4.13. > > The series can also be found at: > > git://xenbits.xen.org/people/royger/xen.git iommu_intr_v3 > > Thanks, Roger. > > Roger Pau Monne (4): > iommu/amd: support all delivery modes with x2APIC > x2APIC: simplify resume > x2APIC: translate IO-APIC entries when enabling the IOMMU > iommu: translate IO-APIC pins when enabling interrupt remapping As mentioned in reply to #1, I think that one should go last. The other three are ready to be committed, but I'd like to double check that there's no dependency of any of them on the 1st. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/4] iommu/amd: support all delivery modes with x2APIC
On 15.10.2019 17:47, Roger Pau Monne wrote:
> Current AMD IOMMU code will attempt to create remapping entries for
> all IO-APIC pins, regardless of the delivery mode. AMD IOMMU
> implementation doesn't support remapping entries for IO-APIC pins with
> delivery mode set to SMI, MNI, INIT or ExtINT, instead those entries
Nit: "NMI"
> are not translated provided the right bits are set in the device table
> entry.
>
> This change checks whether the device table entry has the correct bits
> set in order to delivery the requested interrupt or a warning message
> is printed. It also translates the 32bit destination field into a
> physical or logical IO-APIC entry format. Note that if the 32bit
> destination cannot fit into the legacy format a message is printed and
> the entry is masked.
>
> Signed-off-by: Roger Pau Monné
For this to have an effect on firmware initialized RTEs, it also
requires patch 4 aiui. In fact I think it should be _only_ this
case where we allow delivery modes other than fixed and lowest
priority ("arbitrated" in AMD terminology). Hence I think this
patch wants to go last in the series, and the code be changed to
reject runtime requests to fiddle with non-"normal" delivery
modes (this may go further and actually disallow changing such
RTEs at runtime alongside disallowing their production).
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -439,6 +439,80 @@ int __init amd_iommu_setup_ioapic_remapping(void)
> return 0;
> }
>
> +void setup_forced_ioapic_rte(unsigned int apic, unsigned int pin,
> + struct amd_iommu *iommu,
> + struct IO_APIC_route_entry *rte)
> +{
> +unsigned int idx = ioapic_id_to_index(IO_APIC_ID(apic));
> +struct amd_iommu_dte *table = iommu->dev_table.buffer;
> +unsigned int req_id, dest, offset;
> +union irte_ptr entry;
> +
> +ASSERT(x2apic_enabled);
> +
> +if ( idx == MAX_IO_APICS )
Better >= ?
> +{
> +rte->mask = true;
> +return;
> +}
> +
> +req_id = get_intremap_requestor_id(ioapic_sbdf[idx].seg,
> + ioapic_sbdf[idx].bdf);
> +
> +switch ( rte->delivery_mode )
> +{
> +case dest_SMI:
> +break;
Don't you want to check the sys_mgt field here, along the lines of the
other ones below?
> +#define DEL_CHECK(type, dte_field) \
> +case dest_ ## type: \
> +if ( !table[req_id].dte_field ) \
> +printk(XENLOG_WARNING \
> + STR(type) " on IO-APIC %u pin %u will be aborted\n", \
> + apic, pin); \
> +break;
Please omit the final ; here, such that ...
> +DEL_CHECK(NMI, nmi_pass);
> +DEL_CHECK(INIT, init_pass);
> +DEL_CHECK(ExtINT, ext_int_pass);
... the ones here become an actual requirement.
> +#undef DEL_CHECK
> +
> +default:
> +ASSERT_UNREACHABLE();
> +return;
> +}
> +
> +offset = ioapic_sbdf[idx].pin_2_idx[pin];
> +if ( offset >= INTREMAP_MAX_ENTRIES )
> +{
> +rte->mask = true;
> +return;
> +}
> +
> +entry = get_intremap_entry(iommu, req_id, offset);
> +dest = get_full_dest(entry.ptr128);
> +
> +#define SET_DEST(name, dest_mask) {
> \
> +if ( dest & ~(dest_mask) )
> \
> +{
> \
> +printk(XENLOG_WARNING
> \
> + "IO-APIC %u pin %u " STR(name) " destination (%x) > %x\n",
> \
> + apic, pin, dest, dest_mask);
> \
> +rte->mask = true;
> \
> +return;
> \
> +}
> \
> +rte->dest.name.name ## _dest = dest;
> \
> +}
> +
> +if ( rte->dest_mode )
> +SET_DEST(physical, 0xf)
> +else
> +SET_DEST(logical, 0xff)
This reads as if the code was broken. Please add () around the outermost
{} of the macro, allowing you to put ; here. Or otherwise, just like
above for DEL_CHECK(), omit the {} as well as the final semicolon.
Furthermore - are you sure about this distinction? See e.g.
update_intremap_entry_from_ioapic() and
amd_iommu_setup_ioapic_remapping(), which unilaterally use
rte->dest.logical.logical_dest. Likewise io_apic.c's SET_DEST() users,
which generally pass "logical" for as middle argument. I thought one of
my half way recent patches (IRQ handling or
Re: [Xen-devel] [PATCH v3 7/7] x86/nospec: Optimise array_index_mask_nospec() for power-of-2 arrays
On 25/10/2019 13:24, Jan Beulich wrote:
> On 23.10.2019 15:58, Andrew Cooper wrote:
>> This optimisation is not safe on ARM, because some CPUs do data value
>> speculation, which is why the CSDB barrer was introduced.
> So if an x86 CPU appeared which did so too, it would immediately be
> unsafe as well aiui. I.e. we'd have to again go and fix the logic.
> Not to be taken as an outright objection, but to perhaps prompt
> further consideration.
Actually any masking approach, even cmp/sbb, would be unsafe so I
suppose this note isn't accurate.
I'm aware of one x86 plan for data value speculation, which was delayed
indefinitely following the fallout from Spectre/Meltdown, especially as
L1TF at its core is a speculative address prediction bug. Suffice it to
say that the vendors are aware that any plans along these lines will
need to be done with great care.
>
>> --- a/xen/include/asm-x86/nospec.h
>> +++ b/xen/include/asm-x86/nospec.h
>> @@ -7,13 +7,20 @@
>> #include
>>
>> /**
>> - * array_index_mask_nospec() - generate a mask that is ~0UL when the
>> - * bounds check succeeds and 0 otherwise
>> + * array_index_mask_nospec() - generate a mask to bound an array index
>> + * which is safe even under adverse speculation.
>> * @index: array element index
>> * @size: number of elements in array
>> *
>> - * Returns:
>> + * In general, returns:
>> * 0 - (index < size)
>> + *
>> + * This yeild ~0UL in within-bounds case, and 0 in the out-of-bounds
> Nit: "yields"?
Oops yes.
>
>> @@ -21,9 +28,15 @@ static inline unsigned long
>> array_index_mask_nospec(unsigned long index,
>> {
>> unsigned long mask;
>>
>> -asm volatile ( "cmp %[size], %[index]; sbb %[mask], %[mask];"
>> - : [mask] "=r" (mask)
>> - : [size] "g" (size), [index] "r" (index) );
>> +if ( __builtin_constant_p(size) && IS_POWER_OF_2(size) )
>> +{
>> +mask = size - 1;
>> +OPTIMIZER_HIDE_VAR(mask);
> I can't seem to be able to figure why you need this.
Because I found cases where the AND was elided by the compiler entirely
without it.
>
>> --- a/xen/include/xen/config.h
>> +++ b/xen/include/xen/config.h
>> @@ -75,6 +75,7 @@
>> #define GB(_gb) (_AC(_gb, ULL) << 30)
>>
>> #define IS_ALIGNED(val, align) (((val) & ((align) - 1)) == 0)
>> +#define IS_POWER_OF_2(val) ((val) && IS_ALIGNED(val, val))
> While the risk may seem low for someone to pass an expression with
> side effect here, evaluating "val" up to three times here doesn't
> look very desirable.
That is easy to fix.
> As a minor remark, without considering representation I'd expect
> an expression IS_ALIGNED(val, val) to consistently produce "true"
> for all non-zero values. E.g. 3 is certainly "aligned" on a
> boundary of 3.
IS_ALIGNED() comes with an expectation of being against a power of 2,
because otherwise you'd need a DIV instruction for the general case.
Some users can't cope with a compile time check.
> Finally this may want guarding against use on signed types - at
> the very least it looks to produce the wrong answer for e.g.
> INT_MIN or LONG_MIN. I.e. perhaps the expression to the left of
> && wants to be (val) > 0.
How about the above expansion fix becoming:
({
unsigned typeof(val) _val = val;
_val && (_val & (_val - 1)) == 0;
})
This check makes no sense on negative numbers.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Tagging livepatch-build-tools.git with Xen releases
On 25.10.2019 14:27, Ross Lagerwall wrote: > On 10/25/19 12:05 PM, Lars Kurth wrote: >> Hi all, >> >> I am wondering whether we should tag livepatch-build-tools.git with Xen >> releases >> > > I thought this had been discussed before but I can't find anything in my > archives. Iirc this was on a meeting, not in mail. And I agree with not tagging. In fact I've been wondering if tagging of e.g. mini-os really makes sense. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec
On 25.10.2019 14:10, Andrew Cooper wrote: > On 25/10/2019 13:03, Jan Beulich wrote: >> On 23.10.2019 15:58, Andrew Cooper wrote: >>> evaluate_nospec() is incredibly fragile, and this is one giant bodge. >>> >>> To correctly protect jumps, the generated code needs to be of the form: >>> >>> cmp/test >>> jcc 1f >>> lfence >>> ... >>> 1: lfence >>> ... >>> >>> Critically, the lfence must be at the head of both basic blocks, later in >>> the >>> instruction stream than the conditional jump in need of protection. >>> >>> When a static inline is involved, the optimiser decides to be clever and >>> rearranges the code as: >>> >>> pred: >>> lfence >>> >>> ret >>> >>> call pred >>> cmp $0, %eax >>> jcc 1f >>> ... >>> 1: ... >>> >>> which breaks the speculative safety. >> Aiui "pred" is a non-inlined static inline here. > > Correct, although it actually applies to anything which the compiler > chose to out of line, perhaps even as a side effect of CSE pass. Not sure if you're alluding to such, but I've never seen the compiler out-of-line something that wasn't a function (or perhaps a specialization of one) at the source level. >>> This is the transitive set of predicates which I can spot which need >>> protecting. There are probably ones I've missed. Personally, I'm -1 for >>> this >>> approach, but the only other option for 4.13 is to revert it all to unbreak >>> livepatching. >> To unbreak livepatching, aiui what you need is symbol disambiguation, >> a patch for which has been sent. > > Correct, but.. > >> With this I think we should focus on >> code generation aspects here. I'm fine ack-ing the code changes with >> a modified description. But since you're -1 for this, I'm not sure in >> the first place that we want to go this route. > > ... without this change, l1tf-barrier/branch-hardening is still broken, > and a performance overhead. Well, it has less of an effect, but it's still better than without any of this altogether. In some cases code generation is correct, and in some other cases code generation is at least such that the window size gets shrunk. > The two choices to unblock 4.13 are this patch, or the previous version > which made CONFIG_HARDEN_BRANCH depend on BROKEN, which was even more > disliked. Option 3 is to have just the config option, for people to turn this off if they feel like doing so. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Tagging livepatch-build-tools.git with Xen releases
On 25/10/2019 13:27, Ross Lagerwall wrote: > On 10/25/19 12:05 PM, Lars Kurth wrote: >> Hi all, >> >> I am wondering whether we should tag livepatch-build-tools.git with >> Xen releases >> > > I thought this had been discussed before but I can't find anything in > my archives. I recall a discussion at the time as well. > > IMO livepatch-build-tools is a separate tool that doesn't need to move > in lockstep with Xen. I would always recommend using the tip commit > since bugs often get fixed around the time that patching is needed. > Therefore I don't see any value in tagging it for the time being. +2 to not being in lockstep. It helps massively with downstream usability. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 05/24] golang/xenlight: define KeyValueList builtin type
> Ok, in that case let’s just leave the struct empty. Ok, sounds like a plan. > I think we basically have three options: > > 1. Try to arrange it so that the “zero” values correspond to “default” values > in libxl; i.e., have DevID 0 -> libxl_devid -1, DevID 1 -> libxl_devid 0, > > 2. Add NewStructType functions > > 3. Add .Init() methods to structs > > #1 I think is probably too risky; so 2 or 3 (or maybe both) will probably be > needed. The NewStructType() seems to be more standard. But I’m open so > suggestions. :-) Option 2 is certainly the standard, and best to avoid confusing .Init() functions with the special function init(). I'll work on the implementation as soon as we get this series done :) -NR ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Tagging livepatch-build-tools.git with Xen releases
On 10/25/19 12:05 PM, Lars Kurth wrote: Hi all, I am wondering whether we should tag livepatch-build-tools.git with Xen releases I thought this had been discussed before but I can't find anything in my archives. IMO livepatch-build-tools is a separate tool that doesn't need to move in lockstep with Xen. I would always recommend using the tip commit since bugs often get fixed around the time that patching is needed. Therefore I don't see any value in tagging it for the time being. Thanks, -- Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 7/7] x86/nospec: Optimise array_index_mask_nospec() for power-of-2 arrays
On 23.10.2019 15:58, Andrew Cooper wrote:
> This optimisation is not safe on ARM, because some CPUs do data value
> speculation, which is why the CSDB barrer was introduced.
So if an x86 CPU appeared which did so too, it would immediately be
unsafe as well aiui. I.e. we'd have to again go and fix the logic.
Not to be taken as an outright objection, but to perhaps prompt
further consideration.
> --- a/xen/include/asm-x86/nospec.h
> +++ b/xen/include/asm-x86/nospec.h
> @@ -7,13 +7,20 @@
> #include
>
> /**
> - * array_index_mask_nospec() - generate a mask that is ~0UL when the
> - * bounds check succeeds and 0 otherwise
> + * array_index_mask_nospec() - generate a mask to bound an array index
> + * which is safe even under adverse speculation.
> * @index: array element index
> * @size: number of elements in array
> *
> - * Returns:
> + * In general, returns:
> * 0 - (index < size)
> + *
> + * This yeild ~0UL in within-bounds case, and 0 in the out-of-bounds
Nit: "yields"?
> @@ -21,9 +28,15 @@ static inline unsigned long
> array_index_mask_nospec(unsigned long index,
> {
> unsigned long mask;
>
> -asm volatile ( "cmp %[size], %[index]; sbb %[mask], %[mask];"
> - : [mask] "=r" (mask)
> - : [size] "g" (size), [index] "r" (index) );
> +if ( __builtin_constant_p(size) && IS_POWER_OF_2(size) )
> +{
> +mask = size - 1;
> +OPTIMIZER_HIDE_VAR(mask);
I can't seem to be able to figure why you need this.
> --- a/xen/include/xen/config.h
> +++ b/xen/include/xen/config.h
> @@ -75,6 +75,7 @@
> #define GB(_gb) (_AC(_gb, ULL) << 30)
>
> #define IS_ALIGNED(val, align) (((val) & ((align) - 1)) == 0)
> +#define IS_POWER_OF_2(val) ((val) && IS_ALIGNED(val, val))
While the risk may seem low for someone to pass an expression with
side effect here, evaluating "val" up to three times here doesn't
look very desirable.
As a minor remark, without considering representation I'd expect
an expression IS_ALIGNED(val, val) to consistently produce "true"
for all non-zero values. E.g. 3 is certainly "aligned" on a
boundary of 3.
Finally this may want guarding against use on signed types - at
the very least it looks to produce the wrong answer for e.g.
INT_MIN or LONG_MIN. I.e. perhaps the expression to the left of
&& wants to be (val) > 0.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next v3 6/7] x86/nospec: Move array_index_mask_nospec() into nospec.h
On 23.10.2019 15:58, Andrew Cooper wrote: > system.h isn't an appropriate place to live, now that asm/nospec.h exists. > This should arguably have been part of c/s db591d6e76e > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec
On 25/10/2019 13:03, Jan Beulich wrote: > On 23.10.2019 15:58, Andrew Cooper wrote: >> evaluate_nospec() is incredibly fragile, and this is one giant bodge. >> >> To correctly protect jumps, the generated code needs to be of the form: >> >> cmp/test >> jcc 1f >> lfence >> ... >> 1: lfence >> ... >> >> Critically, the lfence must be at the head of both basic blocks, later in the >> instruction stream than the conditional jump in need of protection. >> >> When a static inline is involved, the optimiser decides to be clever and >> rearranges the code as: >> >> pred: >> lfence >> >> ret >> >> call pred >> cmp $0, %eax >> jcc 1f >> ... >> 1: ... >> >> which breaks the speculative safety. > Aiui "pred" is a non-inlined static inline here. Correct, although it actually applies to anything which the compiler chose to out of line, perhaps even as a side effect of CSE pass. > There's no "optimiser decides > to be clever" in this case imo - it all is a result of not inlining, when the > construct in evaluate_nospec() is specifically assuming this wouldn't happen. > Therefore I continue to think that the description is misleading. > >> Any use of evaluate_nospec() needs all static inline predicates which use it >> to be declared always_inline to prevent the optimiser having the flexibility >> to generate unsafe code. > I agree with this part. > >> Signed-off-by: Andrew Cooper >> --- >> CC: George Dunlap >> CC: Ian Jackson >> CC: Jan Beulich >> CC: Konrad Rzeszutek Wilk >> CC: Stefano Stabellini >> CC: Wei Liu >> CC: Julien Grall >> CC: Juergen Gross >> >> This is the transitive set of predicates which I can spot which need >> protecting. There are probably ones I've missed. Personally, I'm -1 for >> this >> approach, but the only other option for 4.13 is to revert it all to unbreak >> livepatching. > To unbreak livepatching, aiui what you need is symbol disambiguation, > a patch for which has been sent. Correct, but.. > With this I think we should focus on > code generation aspects here. I'm fine ack-ing the code changes with > a modified description. But since you're -1 for this, I'm not sure in > the first place that we want to go this route. ... without this change, l1tf-barrier/branch-hardening is still broken, and a performance overhead. The two choices to unblock 4.13 are this patch, or the previous version which made CONFIG_HARDEN_BRANCH depend on BROKEN, which was even more disliked. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/7] x86/nospec: Rename and rework l1tf-barrier as branch-harden
On 23.10.2019 15:58, Andrew Cooper wrote: > l1tf-barrier is an inappropriate name, and came about because of restrictions > on could be discussed publicly when the patches were proposed. > > In practice, it is for general Spectre v1 mitigations, and is necessary in all > cases. An adversary which can control speculation in Xen can leak data in > cross-core (BCBS, etc) or remote (NetSpectre) scenarios - the problem is not > limited to just L1TF with HT active. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich > In principle it should be tristate and being disabled by default on parts > which don't speculate, but it is too late in 4.13 to organise this. And the fundamental issue is correctly compiling the conditions under which to default to true and false respectively? I ask because if it was not this then I wouldn't see what hindering factor there is to make this tristate right away. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 3/7] xen/nospec: Introduce CONFIG_SPECULATIVE_HARDEN_BRANCH
On 23.10.2019 15:58, Andrew Cooper wrote: > Just as with CONFIG_SPECULATIVE_HARDEN_ARRAY, branch hardening should be > configurable at compile time. > > The previous CONFIG_HVM was a consequence of what could be discussed publicly > at the time the patches were submitted, and wasn't actually correct. Later > patches will make further corrections. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 143151: tolerable all pass - PUSHED
flight 143151 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/143151/ 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 64b5d83460af4654b88c6598ede7e74dd37dce2e baseline version: xen 333d7412796e8fd485bfbb79180a520f7e08bc27 Last test of basis 143127 2019-10-24 22:04:53 Z0 days Testing same since 143151 2019-10-25 09:02:46 Z0 days1 attempts People who touched revisions under test: Andrew Cooper George Dunlap Jan Beulich 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-amd64pass 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 333d741279..64b5d83460 64b5d83460af4654b88c6598ede7e74dd37dce2e -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec
On 23.10.2019 15:58, Andrew Cooper wrote: > evaluate_nospec() is incredibly fragile, and this is one giant bodge. > > To correctly protect jumps, the generated code needs to be of the form: > > cmp/test > jcc 1f > lfence > ... > 1: lfence > ... > > Critically, the lfence must be at the head of both basic blocks, later in the > instruction stream than the conditional jump in need of protection. > > When a static inline is involved, the optimiser decides to be clever and > rearranges the code as: > > pred: > lfence > > ret > > call pred > cmp $0, %eax > jcc 1f > ... > 1: ... > > which breaks the speculative safety. Aiui "pred" is a non-inlined static inline here. There's no "optimiser decides to be clever" in this case imo - it all is a result of not inlining, when the construct in evaluate_nospec() is specifically assuming this wouldn't happen. Therefore I continue to think that the description is misleading. > Any use of evaluate_nospec() needs all static inline predicates which use it > to be declared always_inline to prevent the optimiser having the flexibility > to generate unsafe code. I agree with this part. > Signed-off-by: Andrew Cooper > --- > CC: George Dunlap > CC: Ian Jackson > CC: Jan Beulich > CC: Konrad Rzeszutek Wilk > CC: Stefano Stabellini > CC: Wei Liu > CC: Julien Grall > CC: Juergen Gross > > This is the transitive set of predicates which I can spot which need > protecting. There are probably ones I've missed. Personally, I'm -1 for this > approach, but the only other option for 4.13 is to revert it all to unbreak > livepatching. To unbreak livepatching, aiui what you need is symbol disambiguation, a patch for which has been sent. With this I think we should focus on code generation aspects here. I'm fine ack-ing the code changes with a modified description. But since you're -1 for this, I'm not sure in the first place that we want to go this route. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 05/24] golang/xenlight: define KeyValueList builtin type
> On Oct 24, 2019, at 8:54 PM, Nick Rosbrook wrote:
>
>> So we *could* actually just `type KeyValueList struct { }`, and punt on
>> all these initialization questions until such time as it turns out that
>> they're needed.
>
> If there is no clear need for this type to be implemented in the Go
> package, then I would be in favor of not doing so. IMO, a smaller,
> more focused package is ideal.
Ok, in that case let’s just leave the struct empty.
>
>> On the other hand, I think we may need to actually think about
>> initializing structures. You've carefully coded DefBool such that the
>> "zero" value is undefined; but for DevId, for instance, the "initial"
>> value is supposed to be -1; but the way it's coded, an uninitialized Go
>> structure will end up as 0, which may be a valid devid.
>>
>> [...]
>>
>> Anyway, perhaps we can think about structure initialization, and
>> implement it after we do the basic structure / marshalling implementaiton.
>
> That's probably best. However, at a quick glance it seems like it
> would be pretty straight-forward to generate NewStructType functions
> analogous to libxl_struct_type_init, if that's the desired behavior.
I think we basically have three options:
1. Try to arrange it so that the “zero” values correspond to “default” values
in libxl; i.e., have DevID 0 -> libxl_devid -1, DevID 1 -> libxl_devid 0,
2. Add NewStructType functions
3. Add .Init() methods to structs
#1 I think is probably too risky; so 2 or 3 (or maybe both) will probably be
needed. The NewStructType() seems to be more standard. But I’m open so
suggestions. :-)
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 288 v3 (CVE-2019-17343) - x86: Inconsistent PV IOMMU discipline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2019-17343 / XSA-288 version 3 x86: Inconsistent PV IOMMU discipline UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = In order for a PV domain to set up DMA from a passed-through device to one of its pages, the page must be mapped in the IOMMU. On the other hand, before a PV page may be used as a "special" page type (such as a pagetable or descriptor table), it _must not_ be writable in the IOMMU (otherwise a malicious guest could DMA arbitrary page tables into the memory, bypassing Xen's safety checks); and Xen's current rule is to have such pages not in the IOMMU at all. Until now, in order to accomplish this, the code has borrowed HVM domain's "physmap" concept: When a page is assigned to a guest, guess_physmap_add_entry() is called, which for PV guests, will create a writable IOMMU mapping; and when a page is removed, guest_physmap_remove_entry() is called, which will remove the mapping. Additionally, when a page gains the PGT_writable page type, the page will be added into the IOMMU; and when the page changes away from a PGT_writable type, the page will be removed from the IOMMU. Unfortunately, borrowing the "physmap" concept from HVM domains is problematic. HVM domains have a lock on their p2m tables, ensuring synchronization between modifications to the p2m; and all hypercall parameters must first be translated through the p2m before being used. Trying to mix this locked-and-gated approach with PV's lock-free approach leads to several races and inconsistencies. IMPACT == An untrusted PV domain with access to a physical device can DMA into its own pagetables, leading to privilege escalation. VULNERABLE SYSTEMS == Only x86 systems are vulnerable. ARM systems are not vulnerable. Only systems where PV guests are given direct access to physical devices (PCI pass-through) are vulnerable. Systems with only HVM guests, or systems which do not use PCI pass-through, are not vulnerable. MITIGATION == Only assigning devices to HVM guests will avoid these vulnerabilities. CREDITS === This issue was discovered by Paul Durrant of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa288.patch xen-unstable xsa288-4.11.patch Xen 4.11.x, Xen 4.10.x xsa288-4.9.patch Xen 4.9.x xsa288-4.8.patch Xen 4.8.x xsa288-4.7.patch Xen 4.7.x $ sha256sum xsa288* 7254f0ce791b5543aec68643ec47e2bcf7823650949c7eb32db5122591f12e8c xsa288.meta e1159cb5c1c5a01b28753739b6a78b555ebe4b920cae766db47e0f2a1a21c188 xsa288.patch e9986ceda84e7391c27d80fd541a0e5edf1eadef302a560b4e445ca9bad4c56e xsa288-4.7.patch 14856543ccaa5b3db2a209d25637ed025f2eb940294d0cd07e03f56630a9e5af xsa288-4.8.patch df5e4a367f58491d54c778e2997142792c881d4f7b5a2a1d3339d2a3f1abafe5 xsa288-4.9.patch 58ba46b4814695dc34beaa5fb644931253bd0b0c6a8dc843c735beec152ae722 xsa288-4.11.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl2y19AMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZmCoH/3PTKQLGVnhe5iGtXVgfbb1h+vz/8t/BATDFgreL LXSvxxK42FZ+inbr/qz/NUPS21yISOUu9agqWFzTq5qYpU1E4+FybwdjvIHBE6tG 16gFjHYfawvA3QAPndaZR8vdWVqOEu/YdhOSa7m9vRiUnxh2B44nX0oT/bXuGdKv pyKrQk91hpeWPXxWzJ2k1hy1+/I+eEDxLvauvVaIulO/0bQyMTWcCDRCYdzShJEp njdVj3+4ZvvNbtc4zrWmVtfyZfMLWFdYwCTcTQ7Gy0b9wVmGhD1UhZsgXd4i8H2Z 62HfUOesi7yO2OtI1T08GaRFoo9ArcUbyEKvxTGW5Iyh6NE= =EvlR -END PGP SIGNATURE- xsa288.meta Description: Binary data xsa288.patch Description: Binary data xsa288-4.7.patch Description: Binary data xsa288-4.8.patch Description: Binary data xsa288-4.9.patch Description: Binary data xsa288-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 300 v3 (CVE-2019-17351) - Linux: No grant table and foreign mapping limits
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17351 / XSA-300
version 3
Linux: No grant table and foreign mapping limits
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
Virtual device backends and device models running in domain 0, or
other backend driver domains, need to be able to map guest memory
(either via grant mappings, or via the foreign mapping interface).
Inside Xen, mapped grants are tracked by the maptrack structure. The
size of this structure is chosen during domain creation, and has a
fixed upper bound for the lifetime of the domain.
For Linux to keep track of these mappings, it needs to have a page
structure for each one. In practice the number of page structures is
usually limited. In PV guests, a range of pfns are typically set
aside at boot ("pre-ballooned") for this purpose. For HVM/PVH and Arm
guests, no memory is set aside to begin with. In either case, when
more of this "foreign / grant map pfn space" is needed, Linux will
balloon out extra pages to use for this purpose.
Unfortunately, in Linux, there are no limits, either on the total
amount of memory which the domain will attempt to balloon out, nor on
the amount of "foreign / grant map" memory which any individual guest
can consume.
For Linux userspace backends (e.g. QEMU) which use /dev/xen/gnttab or
/proc/xen/gnttab, there is an arbitrary mapping limit which, if hit,
will prevent further mappings from being established.
As a result, a malicious guest may be able to, with crafted requests,
cause a backend Linux domain to either:
1) Fill the maptrack table in Xen and/or hit the userspace limit.
This will starve I/O from other guests served by the same backend.
2) Balloon out sufficient RAM to cause it to swap excessively, or run
completely out of memory. This may starve all operations from the
domain, including I/O from other guests, or may cause a crash of
the domain.
IMPACT
==
Guest may be able to crash backend Linux domains, or starve operations
inside the domain, including the processing of guest I/O requests
(Guest Denial-of-Service).
If the backend is domain 0, which is the most common configuration,
then host-wide operations may be starved, or the host may crash (Host
Denial-of-Service).
VULNERABLE SYSTEMS
==
All versions of Linux are vulnerable. Only Linux guests acting as
backend domains for other guests may be exploited.
All Arm domains are vulnerable, as are x86 PVH/HVM guests. The
vulnerability of x86 PV guests depends on how they were configured at
boot.
MITIGATION
==
PV guests can be constructed with "pre-ballooned" memory, by building
it with maxmem > memory. See `man 5 xl.cfg` for full details of these
two parameters.
For PV dom0, these are controlled by Xen's "dom0_mem=$X,max:$Y"
command line parameter.
The larger the difference between memory and maxmem, the more space
Linux has to fill with grant/foreign mappings before it will start
ballooning out real memory to satisfy further mapping requests. This
makes the attack more difficult to accomplish.
CREDITS
===
This issue was discovered by Julien Grall of ARM.
RESOLUTION
==
Applying the appropriate attached patch resolves the backend memory
exhaustion issue.
NOTE: This does NOT fix the guest starvation issue. Fixing fixing
this issue is more complex, and it was determined that it was better
to work on a robust fix for the issue in public. This advisory will
be updated when fixes are available.
xsa300-linux-5.2.patch Linux 4.4 ... 5.2
$ sha256sum xsa300*
9c8a9aec52b147f8e8ef41444e1dd11803bacf3bd4d0f6efa863b16f7a9621ac
xsa300-linux-5.2.patch
$
NOTE ON LACK OF EMBARGO
===
The lack of predisclosure is due to a short schedule set by the
discoverer, and efforts to resolve the advisory wording.
-BEGIN PGP SIGNATURE-
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl2y2AYMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ1zEH/0EshvAErWXqQzUnuqxyCeCOPnVtTbnGRDBR4B62
znE6Kbu449nh7qnkqyRGQxwGgdKnsFPDbXuQJb1hyjSl1Ph+u5KbA3aDcIxNy4d0
y0gumH8tcW+ag1P9Z9geACrRT+1dJ7RiMfi+IaBA7nD3raYUtHLdGrAHGTxX1B3u
k3kXjP5pyXl96u9zCAd4lOe6hLnQr3gaPrBdDDkF+ArY8WO8+XaTqKPH0YsdrHxA
kexqH3Ts9sBO+YC7LZdF9Q54K91xOfzwmmmZUTL99pJhzAAl4fwh/ZZj/rRZhC58
FnRy0lL7D2lFyhzlPIrXk+sjuu4tS/ZslQKk14Q7etcXGFQ=
=rVDQ
-END PGP SIGNATURE-
xsa300-linux-5.2.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 294 v3 (CVE-2019-17348) - x86 shadow: Insufficient TLB flushing when using PCID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2019-17348 / XSA-294 version 3 x86 shadow: Insufficient TLB flushing when using PCID UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Use of Process Context Identifiers (PCID) was introduced into Xen in order to improve performance after XSA-254 (and in particular its Meltdown sub-issue). This enablement implied changes to the TLB flushing logic. One aspect which was overlooked is the safety of switching between shadow pagetables, which previously relied on the unconditional flushing of a write to CR3. With PCID enabled, a switch of shadow pagetable for a 64bit PV guest fails to invalidate the linear mappings of the previous shadow pagetable. As a result, subsequent accesses to the shadow pagetables may be deemed to be safe by the shadow logic (based on the old shadow pagetable) but fault when made in practice. IMPACT == Malicious 64bit PV guests may be able to cause a host crash (Denial of Service). Additionally, vulnerable configurations are unstable even in the absence of an attack. VULNERABLE SYSTEMS == Only x86 systems are vulnerable. ARM systems are not vulnerable. Only systems running 64-bit x86 PV guests are vulnerable. Systems running only x86 HVM or PVH or 32bit PV guests are not vulnerable. Only systems with at least one PCID-enabled PV guest are vulnerable. Systems where PCID or INVPCID are unavailable or entirely disabled are not vulnerable. Note that PCID is enabled by default for both 64-bit dom0 and 64-bit domU when hardware supports it. PCID acceleration has been backported to the following versions: - Xen 4.11.x, - Xen 4.10.2 and onwards, - Xen 4.9.3 and onwards, - Xen 4.8.4 and onwards, - Xen 4.7.6. MITIGATION == Running only HVM or PVH guests will avoid this vulnerability. Disabling use of PCID entirely, by passing "pcid=0" or "invpcid=0" as a command line option to the hypervisor, will also avoid this vulnerability (albeit re-introducing the XPTI performance regression use of PCID was intended to reduce). CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa294/unstable.patch xen-unstable xsa294/4.11.patch Xen 4.11.x xsa294/4.10.patch Xen 4.10.x xsa294/4.9.patchXen 4.9.x xsa294/4.8.patchXen 4.8.x xsa294/4.7.patchXen 4.7.x $ sha256sum xsa294*/* c10b7b79a2067cc6d95e40bc78ee8fddaf31f8614bb183fdd5f00e4272e08a0e xsa294/4.7.patch 3ac1c3caf01feaf341e977fcbae691f2e4425aa9691f2dfa66795acfe823d76e xsa294/4.8.patch a8dfc8b2d2f0d0865b70fb0051f9d5a80a6c7456d004957a0155d989ec875611 xsa294/4.9.patch c6fe1e0173b665a88cbab423737dcb060eed1f634f9bca880d9ddfa2ac855d03 xsa294/4.10.patch 61a341510f45c0cf63a7438645f5c2b3ab1cd72bc2476e5fad331e322f834f4a xsa294/4.11.patch 1fb22eab53f9b1e93fc25f5a08d37121a9278854174f1fbd495b3fe6e8babf3a xsa294/unstable.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl2y1/cMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZH54H/iShmv1F1GDALKhJJdm+BOEtyVy+ZCFU5Atn97dV 3Bm+3BtX1Nfcd1pnLdzQs0ocasw+FSp0Swq93nrpM8hPK9ze4aAKwo/Srhf/WV2/ V9N5lKwxCUub6p2QbAcqj//zLxv0llkhduVGzV9/NXOzeLn5Rp2Af/rgSchQ4QHp oEdHXNV93Pm1pi4NpCu8uXQAW4Mp7rRiWJPuBkuJDhgVftXItSNMc6jLunJS581X z+3SmLpfF3IDVpa5GqjtFJ3Exk9DJe4oYHZPmb2qwJTsfV20emIc/7mARGErgdwT jpRjss41gJX1l41zRF9mwKPc1qPW6Rc9xgh6q1jrjY1CCvk= =TV/a -END PGP SIGNATURE- xsa294/4.7.patch Description: Binary data xsa294/4.8.patch Description: Binary data xsa294/4.9.patch Description: Binary data xsa294/4.10.patch Description: Binary data xsa294/4.11.patch Description: Binary data xsa294/unstable.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org
[Xen-devel] Xen Security Advisory 291 v3 (CVE-2019-17345) - x86/PV: page type reference counting issue with failed IOMMU update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2019-17345 / XSA-291 version 3 x86/PV: page type reference counting issue with failed IOMMU update UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = When an x86 PV domain has a passed-through PCI device assigned, IOMMU mappings may need to be updated when the type of a particular page changes. Such an IOMMU operation may fail. In the event of failure, while at present the affected guest would be forcibly crashed, the already recorded additional type reference was not dropped again. This causes a bug check to trigger while cleaning up after the crashed guest. IMPACT == Malicious or buggy x86 PV guest kernels can mount a Denial of Service (DoS) attack affecting the whole system. VULNERABLE SYSTEMS == Xen versions from 4.8 onwards are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PV guests can exploit the vulnerability. x86 HVM and PVH guests cannot exploit the vulnerability. Only guests which are assigned a physical device can exploit this vulnerability. Guests which are not assigned physical devices cannot exploit this vulnerability. MITIGATION == Running only HVM or PVH guests avoids the vulnerability. Not passing through PCI devices to PV guests also avoids the vulnerability. CREDITS === This issue was discovered by Igor Druzhinin and Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa291.patch xen-unstable xsa291-4.11.patch Xen 4.11.x, Xen 4.10.x xsa291-4.9.patch Xen 4.9.x, Xen 4.8.x $ sha256sum xsa291* 01883c11ae45a5771644270445e463538a61d98c66adbba852de74ccd272eae9 xsa291.meta fb5f2a75ba113f21e9cb2dfbc22520495c69a4fef631c030a4834c680045e587 xsa291.patch 299bb4913e7ddb46ce90f415f91ee5e5480050631281c87e1a764b66fb116d89 xsa291-4.9.patch 16087ba5c59b9644f4f61c0c7fa124d9e04e88089b235aaae91daa04cdf1b8a1 xsa291-4.11.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl2y1+EMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZlLUIAIIHkQgn80yjzaDnIGp0iFhcoTjDGlwk47MaQiJ2 QbmVstpVbg4ZUuPmxJ6eWTJXoMbdelthA9klXX9zc0LWEOrMwWeykAxkWB8uVj+b URN6fJrLu73U2tqjmPT/P63FVgETXDbFGQcjsSkZ17VHcblmsysCUPmjLWn4r3Tc /lCXcEjwHYV2HnYUBrXO2biDVChRt3ClLhJZW9pfvI8hIzCqL+tdtNuvvqVSwR3Y SzR75k2lKwkmHQju2rpL00mNsyHsUOl3tDVeHTQa9V7yW4WO4vSb83oZExz9ChgH g9ro6epGfGYCQYB9mNSaQbOM3LhOrWeiR1i3nUcR0qRG1wY= =r9AC -END PGP SIGNATURE- xsa291.meta Description: Binary data xsa291.patch Description: Binary data xsa291-4.9.patch Description: Binary data xsa291-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 285 v3 (CVE-2019-17341) - race with pass-through device hotplug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2019-17341 / XSA-285 version 3 race with pass-through device hotplug UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = When adding a passed-through PCI device to a domain after it was already started, IOMMU page tables may need constructing on the fly. For PV guests the decision whether a page ought to have a mapping is based on whether the page is writable, to prevent IOMMU access to things like page tables. Writablility of a page may, however, change at any time. Failure of the relevant code to respect this possible race may lead to IOMMU mappings of, in particular, page tables, allowing the guest to alter such page tables without Xen auditing the changes. IMPACT == Malicious PV guests can escalate their privilege to that of the hypervisor. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PV guests can exploit the vulnerability. x86 HVM and PVH guests cannot exploit the vulnerability. Only guests which are assigned a device after domain creation can exploit this vulnerability. Guests which are not assigned devices, or guests assigned devices at domain creation time, cannot exploit this vulnerability. MITIGATION == Running only HVM or PVH guests avoids the vulnerability. Assigning passed-through PCI devices to PV guests at domain creation time also avoids the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa285.patch xen-unstable xsa285-4.11.patch Xen 4.7.x - Xen 4.11.x $ sha256sum xsa285* 0851a4a9120220e2b03eafaf94648077154b6a6f27c29055d3779ccad7684fce xsa285.meta 9e96d3763158edde8d664c3e26761e63ca6f96bb921e0d7eb68351fe47499bde xsa285.patch 38ec20b04e0a859abe9850803ae00a33e48591a9949e5287dfa3725f3bd179f3 xsa285-4.11.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl2y178MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZnhUIALWg5ROzP7vpvNOEQDICm/A/AxjPLB6uHnj95bBJ CxfLZPZyxUak9jmn8bJJrhJBNGS/RFUWrwWm+mHku8ywNKTcHkhGtweS8/GjuMeG I7hhh/Ux39vs/kPWvy7uydMIMrcIsiG69NWXl6xWMGkcmcmlkJCAi2KHX20Jb5qi Izy7swNoBFWuuGMaBTg8YJ+XfqQGonemzgviY01EHQqJo/2wPyJjgsbZzu6XlNJc R3K9K4RDzjtemIEQps9CWA8ilEXxv6DIhVKBx0gNLIrJZPVEh2awLr5Ve2YZIdk6 N5hSP2LFyueDhmKvwrMnrrKF4XqHlfyIsW0l8TXwa/OUTVI= =6noj -END PGP SIGNATURE- xsa285.meta Description: Binary data xsa285.patch Description: Binary data xsa285-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 290 v3 (CVE-2019-17344) - missing preemption in x86 PV page table unvalidation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2019-17344 / XSA-290 version 3 missing preemption in x86 PV page table unvalidation UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = XSA-273 changes required, among other things, making any PTE updates restartable. The changes making PTE updates restartable assumed that L2 pagetables would always be promoted preemptibly; but this turns out not to be the case when using the 'linear pagetable' feature; the result was that interrupted operations are not handled properly in certain cases. Furthermore, previous security work making pagetable update preemptible failed to account for 'linear pagetables' at L3 and L4 levels, making it possible for operations to run for longer than acceptable times. IMPACT == Malicious or buggy x86 PV guest kernels can mount a Denial of Service (DoS) attack affecting the whole system. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not affected. Only Xen versions which permit linear page table use by PV guests are vulnerable. Only x86 PV guests can leverage this vulnerability. x86 HVM guests cannot leverage this vulnerability. MITIGATION == Not permitting linear page table use by PV guests avoids the vulnerability. This can be done both at build time, by turning off the PV_LINEAR_PT configure option, or at runtime, by passing specifying "pv-linear-pt=0" on the hypervisor command line. Doing so would, however, render PV guests using the functionality, like NetBSD, unusable. On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which only issue sane hypercalls will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. Running only HVM guests will avoid this vulnerability. CREDITS === This issue was discovered by Manuel Bouyer. RESOLUTION == Applying the appropriate pair of attached patches resolves this issue. xsa290/unstable-?.patch xen-unstable xsa290/4.11-?.patch Xen 4.11.x xsa290/4.10-?.patch Xen 4.10.x xsa290/4.9-?.patch Xen 4.9.x xsa290/4.8-?.patch Xen 4.8.x xsa290/4.7-?.patch Xen 4.7.x $ sha256sum xsa290* xsa290*/* e74014bf97f223f35dc6142fbfadd8a3df6c7ecf1818d5d04ebb717a1d600959 xsa290.meta 87ffaf9712bfd2283e845d168811e572b9ebc8a580e750128586a48e65ae4c67 xsa290/4.7-1.patch 4137eb15d963a77ff302cb65f9f04e402ea23f69042f89ece4baaf4b7a58d638 xsa290/4.7-2.patch 0f5ce8c13c99431cae69736e117c7420c3202e3a680b42a66027646ae0aa141c xsa290/4.8-1.patch bb4102dd6f3daf60859a88b6a2f0828bc8aeb224d3d3b6fd2d2cc96b3f131a24 xsa290/4.8-2.patch a7e4902968529289c63149608d48e1eeac2feffa644e1337b1b5b9a624dc746d xsa290/4.9-1.patch 7798b063a8db95fc18bca1ea25d84937fbe9c6e0add15056841fd97d5aec2885 xsa290/4.9-2.patch 3a0bf44875bb5a8525b4418d6efd49bd6ed6cfaffe669cbdcfde61a65fe9cdea xsa290/4.10-1.patch 1e7dfe1b0c57e245daef1351db855a9312a4c225c05a6720460ea4aa1148ee22 xsa290/4.10-2.patch 3dd47f3bc1a004260d05cba548a80e475f85ffe60b663879de386e32a8e9ffbc xsa290/4.11-1.patch b3b17546fc553bf60572cf56023d8177f96973fcd072a8adfc622b4030e58d00 xsa290/4.11-2.patch 4ff1d857f46a781fd7483a30297ebf51bf079ccd1d598df799e5779ddc893674 xsa290/unstable-1.patch 3a85ecc426d482052aaf2a84bfde9840eb7a566638dbab042dac84b0019ca473 xsa290/unstable-2.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or the HVM-only as well as host controlled kernel mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER deployment of the "pv-linear-pt=0" mitigation described above is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because in that case the configuration change is visible to the guest, which could lead to the rediscovery of the vulnerability. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to
[Xen-devel] Xen Security Advisory 292 v3 (CVE-2019-17346) - x86: insufficient TLB flushing when using PCID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2019-17346 / XSA-292 version 3 x86: insufficient TLB flushing when using PCID UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Use of Process Context Identifiers (PCID) was introduced into Xen in order to improve performance after XSA-254 (and in particular its Meltdown sub-issue). This enablement implied changes to the TLB flushing logic. The particular case of context switch to a vCPU of a PCID-enabled guest left open a time window between the full TLB flush, and the actual address space switch, during which additional TLB entries (from the address space about to be switched away from) can be accumulated, which will not subsequently be purged. IMPACT == Malicious PV guests may be able to cause a host crash (Denial of Service) or to gain access to data pertaining to other guests. Privilege escalation opportunities cannot be ruled out. Additionally, vulnerable configurations are likely to be unstable even in the absence of an attack. VULNERABLE SYSTEMS == Only x86 systems are vulnerable. ARM systems are not vulnerable. Only systems running x86 PV guests are vulnerable. Systems running only x86 HVM or PVH guests are not vulnerable. Only systems with at least one PCID-enabled PV guest are vulnerable. Systems where PCID or INVPCID are unavailable or entirely disabled are not vulnerable. Note that PCID is enabled by default for both 64-bit dom0 and 64-bit domU when hardware supports it. PCID acceleration has been backported to the following versions: - Xen 4.11.x, - Xen 4.10.2 and onwards, - Xen 4.9.3 and onwards, - Xen 4.8.4 and onwards, - Xen 4.7.6. To exploit this vulnerability, problematic TLB entries must be created between the full TLB flush and the address space switch. The NMI watchdog handler (enabled via the "watchdog" command line option) is known to create such entries; other vectors cannot be ruled out. MITIGATION == Running only HVM or PVH guests will avoid this vulnerability. Running only 32-bit PV guests alongside the other two types mentioned above will also avoid this vulnerability, provided Dom0 is also 32-bit or is not using PCID. Making a 64-bit Dom0 not use PCID can be achieved by e.g. "xpti=no-dom0 pcid=xpti". Disabling use of PCID entirely, by passing "pcid=0" or "invpcid=0" as a command line option to the hypervisor, will also avoid this vulnerability (albeit re-introducing the XPTI performance regression use of PCID was intended to reduce). Disabling the watchdog timer will remove the only known way of reliably creating problematic TLB entries, potentially reducing the risk of a successful attack. CREDITS === This issue was discovered by Sergey Dyasli and Andrew Cooper of Citrix. RESOLUTION == Applying the attached patch resolves this issue. xsa292.patch xen-unstable, Xen 4.11.x ... Xen 4.7.6 $ sha256sum xsa292* c515e98e5ae8a16bc5c894741eea5523a7e568f81ee8a570626dcc0f58f40b40 xsa292.meta f42cb5e1eae5a5c6f0fd84e38df4db9f09a4e1176905c37f292fef9855c82fea xsa292.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl2y1+cMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZV48H/i1Wi6DV90quHvewv0j792crdJojnHgq/8V3+hfT lXWcmfW5IQLi02o4aG7XjUYwRTQ6clRgF4AZDZyrAY15QyVCz9diusvWOUzaq7Pd hrvuIMeaB3+ba2OY7bB3P0sCekhhj6MwqKEhGVlbLEB8A0vGq9XjZBuTmws6QA2J 6Il8fxEVupdtETsf3KlYfxvJOubN/B+tByaIpdWU0C2M66EVa4pcijSLcvoylGxi YS7jJrSMcqg4Sx/e/HnzCJ7jrvzhxSDHeyhPy1/NrwlQz2NQjd+FoFownsH48LuH 6LA6GGTIk5v+a/GtNVpb8Wwfg0UleabF+8S30C6QasUO70E= =Pk5K -END PGP SIGNATURE- xsa292.meta Description: Binary data xsa292.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 287 v3 (CVE-2019-17342) - x86: steal_page violates page_struct access discipline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2019-17342 / XSA-287 version 3 x86: steal_page violates page_struct access discipline UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Xen's reference counting rules were designed to allow pages to change owner and state without requiring a global lock. Each page has a page structure, and a very specific set of access disciplines must be observed to ensure that pages are freed properly, and that no writable mappings exist for PV pagetable pages. Unfortunately, when the XENMEM_exchange hypercall was introduced, these access disciplines were violated, opening up several potential race conditions. IMPACT == A single PV guest can leak arbitrary amounts of memory, leading to a denial of service. A cooperating pair of PV and HVM/PVH guests can get a writable pagetable entry, leading to information disclosure or privilege escalation. Privilege escalation attacks using only a single PV guest or a pair of PV guests have not been ruled out. Note that both of these attacks require very precise timing, which may be difficult to exploit in practice. VULNERABLE SYSTEMS == Only x86 systems are vulnerable. Only systems which run PV guests are vulnerable. Systems which run only HVM/PVH guests are not vulnerable. MITIGATION == Running only HVM or PVH guests will avoid these vulnerabilities. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa287.patch xen-unstable xsa287-4.11.patch Xen 4.11.x xsa287-4.10.patch Xen 4.10.x xsa287-4.9.patch Xen 4.9.x xsa287-4.8.patch Xen 4.8.x xsa287-4.7.patch Xen 4.7.x $ sha256sum xsa287* ae2b9261e26df871693478629c63970ba30817ee1dcb2266b89d8b067833c1b3 xsa287.meta 7de1b886d69dd7c497f88d41adf9a6f7cf9a305fd8ae9d714e1125e2a22208ab xsa287.patch 55f40f2f9bb41c85ac80dac775352e28b25fada80dae574e9d10300d5e2b91ce xsa287-4.7.patch 57312ff131eb6b51235723e862adf42ad3529ed13135375875c054fa0b55f80b xsa287-4.8.patch 34f4b835766a38bcf4066ccbab74676eda176e15ed2a6bd7884678a64507f89a xsa287-4.9.patch c7eaf8a325011dda84b02ee097ddbc7b5f2f4d3399de545a3a7b14e2d23f4278 xsa287-4.10.patch 6793315f714a249a4fad12b36559640b2f97f19f5b85f0d58694c6e78aa3d567 xsa287-4.11.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl2y18cMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZMbcIAKcMpCX29ANW9/W2cnGremzicicGAQW9KvmZVK5e weLBItv9pTqIGeVm71/X2dXt5KeRryh+Py53zYtUhy4pFQXQAezEzlRs+Y4TtX3l +XVsfDFqks+bfyduBKMerwJpqr2Hd3DOdvir8iSqH2jHLLd5JqTYho+m0L0HPD9J Smn43rwurMChSjSFR4H+TnrOcX/1iUWgj3BVUkswGn3CrUdBJFe5mp6QeoYlyiL1 CN6rmx5+CWLvBTwMkEiA8/3GX322qv4f2P0woOnaFW+aNgj1VRcyB2l1V0ParYYw 0Yfj32XNIhdzNfUanenRAUNnTYSzVFFdbTMgV2sgwZjXNgE= =7jA5 -END PGP SIGNATURE- xsa287.meta Description: Binary data xsa287.patch Description: Binary data xsa287-4.7.patch Description: Binary data xsa287-4.8.patch Description: Binary data xsa287-4.9.patch Description: Binary data xsa287-4.10.patch Description: Binary data xsa287-4.11.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 284 v3 (CVE-2019-17340) - grant table transfer issues on large hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2019-17340 / XSA-284 version 3 grant table transfer issues on large hosts UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = When the code processing grant table transfer requests finds a page with an address too large to be represented in the interface with the guest, it allocates a replacement page and copies page contents. However, the code doing so fails to set the newly allocated page's accounting properties correctly, resulting in the page becoming not only unusable by the target domain, but also unfreeable upon domain cleanup. The page as well as certain other remnants of an affected guest will be leaked. Furthermore internal state of the processing code was also not updated correctly, resulting in the insertion of an IOMMU mapping to the page being replaced (and subsequently freed), allowing the domain access to memory it does not own. IMPACT == The primary impact is a memory leak. Malicious or buggy guests with passed through PCI devices may also be able to escalate their privileges, crash the host, or access data belonging to other guests. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are vulnerable. 64-bit x86 PV guests can leverage the vulnerability on hosts with physical memory extending past the 16 TiB boundary. This is only possible for hypervisors built with CONFIG_BIGMEM enabled. 32-bit x86 PV guests can leverage the vulnerability on hosts with physical memory extending past the 168 GiB boundary. x86 HVM and PVH guests cannot leverage the vulnerability on libxl based systems. On xend based systems x86 HVM guests can leverage the vulnerability if their guest config file has a 'machine_address_size' setting. ARM systems are not vulnerable. MITIGATION == Running only x86 HVM/PVH guests will avoid this vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the attached patch resolves this issue. xsa284.patch xen-unstable, Xen 4.11.x ... 4.7.x $ sha256sum xsa284* 5359796890fc59dd2bbf8d23398c229153c8b9b716c01842dfb9f95d063a3ad4 xsa284.meta 3a95ae9faef3886fd3a4ed5b22d944939bb2f819bb5a2a8061b2311cf3c05776 xsa284.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl2y17gMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZkqwH/3M5SYKUH8RiLQierb63SJuwkRsxtQeFERCTZMh2 Q5jgE9RX3/QqubExkVV5gSJRDu0QtOGoo0cG1HwEgJ9fMRg1jtap1AGzGLyvSLMZ KQBRVuiaLhsQlrfQ3hRIbvUt/XcF58PWlX923bx7o7HJIUUpmF3+vr5V5QQ2SPz9 5/7extQJKeDG1lixlQfGGr3dLX1d7J20Rh5/vgdfpPYcjX9+Cl+EF1BlW6BQrQz3 S6MiHkxU4GUtPhJjZvqPupJcB5qDw2BTlEtcjzqhe1e60jzniPJW61D5xSFVcPmW uRAV3oDHzG2N2kOk61dTVhI53XdL81IwiGcMeVYg9drzPAo= =Nq7N -END PGP SIGNATURE- xsa284.meta Description: Binary data xsa284.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Tagging livepatch-build-tools.git with Xen releases
Hi all, I am wondering whether we should tag livepatch-build-tools.git with Xen releases Best Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge
On Thursday, October 24, 2019, Aleksandar Markovic < aleksandar.m.m...@gmail.com> wrote: > > > On Friday, October 18, 2019, Philippe Mathieu-Daudé > wrote: > >> Changes since v1 [0]: >> - Removed patch reintroducing DO_UPCAST() use (thuth) >> - Took various patches out to reduce series (thuth) >> - Added review tags (thanks all for reviewing!) >> >> > Philippe, > > Do you intend to submit v3? The softfreeze is close. > > A. > > Philippe, It looks you are very busy these days. Do you mind my integrating this series in next Mips queue, in its present v2 state? (You can certainly do further refinements later on.) Aleksandar > > >> $ git backport-diff -u pc_split_i440fx_piix-v1 -r mc146818rtc_init.. >> Key: >> [] : patches are identical >> [] : number of functional differences between upstream/downstream >> patch >> [down] : patch is downstream-only >> The flags [FC] indicate (F)unctional and (C)ontextual differences, >> respectively >> >> 001/20:[] [--] 'MAINTAINERS: Keep PIIX4 South Bridge separate from PC >> Chipsets' >> 002/20:[0011] [FC] 'piix4: add Reset Control Register' >> 003/20:[0014] [FC] 'piix4: add a i8259 interrupt controller as specified >> in datasheet' >> 004/20:[] [--] 'Revert "irq: introduce qemu_irq_proxy()"' >> 005/20:[] [--] 'piix4: rename PIIX4 object to piix4-isa' >> 006/20:[] [-C] 'piix4: add a i8257 dma controller as specified in >> datasheet' >> 007/20:[] [-C] 'piix4: add a i8254 pit controller as specified in >> datasheet' >> 008/20:[] [-C] 'piix4: add a mc146818rtc controller as specified in >> datasheet' >> 009/20:[] [--] 'hw/mips/mips_malta: Create IDE hard drive array >> dynamically' >> 010/20:[] [--] 'hw/mips/mips_malta: Extract the PIIX4 creation code >> as piix4_create()' >> 011/20:[] [--] 'hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c' >> 012/20:[] [--] 'hw/i386: Remove obsolete >> LoadStateHandler::load_state_old handlers' >> 013/20:[] [--] 'hw/pci-host/piix: Extract piix3_create()' >> 014/20:[0010] [FC] 'hw/pci-host/piix: Move RCR_IOPORT register definition' >> 015/20:[] [--] 'hw/pci-host/piix: Define and use the PIIX IRQ Route >> Control Registers' >> 016/20:[] [--] 'hw/pci-host/piix: Move i440FX declarations to >> hw/pci-host/i440fx.h' >> 017/20:[] [--] 'hw/pci-host/piix: Fix code style issues' >> 018/20:[0012] [FC] 'hw/pci-host/piix: Extract PIIX3 functions to >> hw/isa/piix3.c' >> 019/20:[] [--] 'hw/pci-host: Rename incorrectly named 'piix' as >> 'i440fx'' >> 020/20:[] [-C] 'hw/pci-host/i440fx: Remove the last PIIX3 traces' >> >> Previous cover: >> >> This series is a rework of "piix4: cleanup and improvements" [1] >> from Hervé, and my "remove i386/pc dependency: PIIX cleanup" [2]. >> >> Still trying to remove the strong X86/PC dependency 2 years later, >> one step at a time. >> Here we split the PIIX3 southbridge from i440FX northbridge. >> The i440FX northbridge is only used by the PC machine, while the >> PIIX southbridge is also used by the Malta MIPS machine. >> >> This is also a step forward using KConfig with the Malta board. >> Without this split, it was impossible to compile the Malta without >> pulling various X86 pieces of code. >> >> The overall design cleanup is not yet perfect, but enough to post >> as a series. >> >> Now that the PIIX3 code is extracted, the code duplication with the >> PIIX4 chipset is obvious. Not worth improving for now because it >> isn't broken. >> >> [0] https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg03685.html >> [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg500737.html >> [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg504081.html >> >> Based-on: <20191018133547.10936-1-phi...@redhat.com> >> mc146818rtc: Allow call object_initialize(MC146818_RTC) instead of >> rtc_init() >> https://mid.mail-archive.com/20191018133547.10936-1-philmd@redhat.com >> >> Hervé Poussineau (5): >> piix4: Add the Reset Control Register >> piix4: Add a i8259 Interrupt Controller as specified in datasheet >> piix4: Rename PIIX4 object to piix4-isa >> piix4: Add a i8257 DMA Controller as specified in datasheet >> piix4: Add a i8254 PIT Controller as specified in datasheet >> >> Philippe Mathieu-Daudé (15): >> MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets >> Revert "irq: introduce qemu_irq_proxy()" >> piix4: Add a MC146818 RTC Controller as specified in datasheet >> hw/mips/mips_malta: Create IDE hard drive array dynamically >> hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create() >> hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c >> hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers >> hw/pci-host/piix: Extract piix3_create() >> hw/pci-host/piix: Move RCR_IOPORT register definition >> hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers >> hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h >> hw/pci-host/piix: Fix code style
[Xen-devel] getting 4.11.3 ready
All, the 4.11.3 stable release is due. I intend to wait for the XSA fixes going public on the 31st, but not (much) longer. Please point out backporting candidates that you find missing from the respective stable trees. I have three ones queued which haven't passed the push gate to the master branch yet: 9257c218e5 x86/vvmx: Fix the use of RDTSCP when it is intercepted at L0 7eee9c16d6 x86/tsc: update vcpu time info on guest TSC adjustments 9633929824 x86: fix off-by-one in is_xen_fixed_mfn() Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Debugging Windows HVM crashes on Ryzen 3xxx series CPUs.
# patch -p1 < ../000-debug-patch-0.patch
patching file xen/arch/x86/hvm/hvm.c
Hunk #1 succeeded at 3373 (offset 1 line).
patching file xen/arch/x86/hvm/svm/svm.c
Hunk #1 succeeded at 2159 (offset -64 lines).
I've attached the output from around boot all the way until after the
Windows HVM DomU crashed.
I gzip'ed it, as its a few hundred Kb.
Steven Haigh
net...@crc.id.au https://www.crc.id.au
+613 9001 6090 +614 1293 5897
On Fri, Oct 25, 2019 at 10:28, Jan Beulich wrote:
On 25.10.2019 09:00, Steven Haigh wrote:
Further to my last, I downloaded the latest Windows Server 2016 ISO
from
Microsoft.
Filename:
Windows_Server_2016_Datacenter_EVAL_en-us_14393_refresh.ISO
Have attached as much of the log as I could get attempting to boot
from
the ISO and having a blank LV as the install target.
The Windows error message (shown via VNC) is HAL MEMORY ALLOCATION.
Hmm, that's as if there was still (again?) an issue with CPUID
handling - iirc the same was observable on maximum-size Rome
systems prior to df29d03f1d (and its fixup). Below the debugging
patch I did use at the time, maybe it turns out helpful here too
(and perhaps you'd really only need the first hunk, I had put in
the other one just in case anyway).
However this looks to be different from your earlier report,
where you said you've got some
(XEN) d1v0 VIRIDIAN CRASH: ac 0 a0a0 f8065c06bf88 bf8
So I wonder whether there's a new issue masking the old one.
Jan
--- unstable.orig/xen/arch/x86/hvm/hvm.c
+++ unstable/xen/arch/x86/hvm/hvm.c
@@ -3372,6 +3372,9 @@ int hvm_vmexit_cpuid(struct cpu_user_reg
}
guest_cpuid(curr, leaf, subleaf, );
+if(regs->ax && (regs->eax >> 16) != 0x4000 && (long)regs->rip < 0)
{//temp
+ printk("%pv[%08lx]: %08x:%08x=%08x:%08x:%08x:%08x\n", curr,
regs->rip, leaf, subleaf, res.a, res.b, res.c, res.d);
+}
HVMTRACE_6D(CPUID, leaf, subleaf, res.a, res.b, res.c, res.d);
regs->rax = res.a;
--- unstable.orig/xen/arch/x86/hvm/svm/svm.c
+++ unstable/xen/arch/x86/hvm/svm/svm.c
@@ -2223,7 +2223,13 @@ static void svm_do_msr_access(struct cpu
rc = hvm_msr_read_intercept(regs->ecx, _content);
if ( rc == X86EMUL_OKAY )
+{//temp
msr_split(regs, msr_content);
+ if(regs->ecx == 0xc001100c || regs->ecx == 0xc0011005)
+ printk("%pv[%08lx]: %08x -> %08x:%08x\n", curr, regs->rip,
regs->ecx, regs->edx, regs->eax);
+} else if(regs->ecx == 0xc001100c || regs->ecx == 0xc0011005) {
+ printk("%pv[%08lx]: %08x -> #GP\n", curr, regs->rip, regs->ecx);
+}
}
else
rc = hvm_msr_write_intercept(regs->ecx, msr_fold(regs),
true);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
xen-output.log.gz
Description: application/gzip
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-next 7/7] x86: implement Hyper-V clock source
Implement a clock source using Hyper-V's reference TSC page.
Signed-off-by: Wei Liu
---
Relevant spec:
https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/live/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0C.pdf
Section 12.6.
---
xen/arch/x86/time.c | 87 +
1 file changed, 87 insertions(+)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index d8242295ef..f7e93b8a1f 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -614,6 +615,89 @@ static struct platform_timesource __initdata plt_xen_timer
=
};
#endif
+#ifdef CONFIG_HYPERV_GUEST
+/
+ * PLATFORM TIMER 6: HYPER-V REFERENCE TSC
+ */
+
+static struct ms_hyperv_tsc_page hyperv_tsc_page __aligned(PAGE_SIZE);
+
+static int64_t __init init_hyperv_timer(struct platform_timesource *pts)
+{
+unsigned long maddr;
+uint64_t tsc_msr, freq;
+
+if ( !hyperv_guest ||
+ !(ms_hyperv.features & HV_MSR_REFERENCE_TSC_AVAILABLE) )
+return 0;
+
+maddr = virt_to_maddr(_tsc_page);
+
+/*
+ * Per Hyper-V TLFS:
+ * 1. Read existing MSR value
+ * 2. Preserve bits [11:1]
+ * 3. Set bits [63:12] to be guest physical address of tsc page
+ * 4. Set enabled bit (0)
+ * 5. Write back new MSR value
+ */
+rdmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr);
+tsc_msr &= GENMASK_ULL(11, 1);
+tsc_msr = tsc_msr | (uint64_t)maddr | 1 /* enabled */;
+wrmsrl(HV_X64_MSR_REFERENCE_TSC, tsc_msr);
+
+/* Get TSC frequency from Hyper-V */
+rdmsrl(HV_X64_MSR_TSC_FREQUENCY, freq);
+pts->frequency = freq;
+
+return freq;
+}
+
+static inline uint64_t read_hyperv_timer(void)
+{
+uint64_t scale, offset, ret, tsc;
+uint32_t seq;
+struct ms_hyperv_tsc_page *tsc_page = _tsc_page;
+
+do {
+seq = tsc_page->tsc_sequence;
+
+/* Seq 0 is special. It means the TSC enlightenment is not
+ * available at the moment. The reference time can only be
+ * obtained from the Reference Counter MSR.
+ */
+if ( seq == 0 )
+{
+rdmsrl(HV_X64_MSR_TIME_REF_COUNT, ret);
+return ret;
+}
+
+smp_rmb();
+
+tsc = rdtsc_ordered();
+scale = tsc_page->tsc_scale;
+offset = tsc_page->tsc_offset;
+
+smp_rmb();
+
+} while (tsc_page->tsc_sequence != seq);
+
+/* x86 has ARCH_SUPPORTS_INT128 */
+ret = (uint64_t)(((__uint128_t)tsc * scale) >> 64) + offset;
+
+return ret;
+}
+
+static struct platform_timesource __initdata plt_hyperv_timer =
+{
+.id = "hyperv",
+.name = "HYPER-V REFERENCE TSC",
+.read_counter = read_hyperv_timer,
+.init = init_hyperv_timer,
+.counter_bits = 63,
+};
+#endif
+
/
* GENERIC PLATFORM TIMER INFRASTRUCTURE
*/
@@ -763,6 +847,9 @@ static u64 __init init_platform_timer(void)
static struct platform_timesource * __initdata plt_timers[] = {
#ifdef CONFIG_XEN_GUEST
_xen_timer,
+#endif
+#ifdef CONFIG_HYPERV_GUEST
+_hyperv_timer,
#endif
_hpet, _pmtimer, _pit
};
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-next 0/7] Implement Hyper-V reference TSC based clock source
Hi all This series adds a clock source based on Hyper-V's reference TSC. The meat is in the last patch. With this series, Xen on Hyper-V no longer runs on emulated PIT. (XEN) Platform timer is 2294.686MHz HYPER-V REFERENCE TSC This series depends on [0]. Wei. 0: https://lists.xen.org/archives/html/xen-devel/2019-10/msg01420.html Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: Roger Pau Monné Cc: Paul Durrant Wei Liu (7): x86: import hyperv-tlfs.h from Linux x86: fix up hyperv-tlfs.h x86/hyperv: extract more information from Hyper-V x86: add a comment regarding the location of hypervisor_probe x86: use running_on_hypervisor to gate hypervisor_setup x86/hyperv: provide hyperv_guest variable x86: implement Hyper-V clock source xen/arch/x86/guest/hyperv/hyperv.c | 17 + xen/arch/x86/setup.c| 6 +- xen/arch/x86/time.c | 87 +++ xen/include/asm-x86/guest/hyperv-tlfs.h | 907 xen/include/asm-x86/guest/hyperv.h | 14 + 5 files changed, 1030 insertions(+), 1 deletion(-) create mode 100644 xen/include/asm-x86/guest/hyperv-tlfs.h -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-next 2/7] x86: fix up hyperv-tlfs.h
Do the following: 1. include xen/types.h and xen/bitops.h 2. fix up invocations of BIT macro Signed-off-by: Wei Liu --- This can be squashed into previous patch if preferred. --- xen/include/asm-x86/guest/hyperv-tlfs.h | 141 1 file changed, 71 insertions(+), 70 deletions(-) diff --git a/xen/include/asm-x86/guest/hyperv-tlfs.h b/xen/include/asm-x86/guest/hyperv-tlfs.h index 7741e211f7..ccd9850b27 100644 --- a/xen/include/asm-x86/guest/hyperv-tlfs.h +++ b/xen/include/asm-x86/guest/hyperv-tlfs.h @@ -9,7 +9,8 @@ #ifndef _ASM_X86_HYPERV_TLFS_H #define _ASM_X86_HYPERV_TLFS_H -#include +#include +#include #include /* @@ -19,7 +20,7 @@ * size may not be 4096 on all architectures. */ #define HV_HYP_PAGE_SHIFT 12 -#define HV_HYP_PAGE_SIZE BIT(HV_HYP_PAGE_SHIFT) +#define HV_HYP_PAGE_SIZE BIT(HV_HYP_PAGE_SHIFT, UL) #define HV_HYP_PAGE_MASK (~(HV_HYP_PAGE_SIZE - 1)) /* @@ -45,47 +46,47 @@ */ /* VP Runtime (HV_X64_MSR_VP_RUNTIME) available */ -#define HV_X64_MSR_VP_RUNTIME_AVAILABLEBIT(0) +#define HV_X64_MSR_VP_RUNTIME_AVAILABLEBIT(0, UL) /* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/ -#define HV_MSR_TIME_REF_COUNT_AVAILABLEBIT(1) +#define HV_MSR_TIME_REF_COUNT_AVAILABLEBIT(1, UL) /* * Basic SynIC MSRs (HV_X64_MSR_SCONTROL through HV_X64_MSR_EOM * and HV_X64_MSR_SINT0 through HV_X64_MSR_SINT15) available */ -#define HV_X64_MSR_SYNIC_AVAILABLE BIT(2) +#define HV_X64_MSR_SYNIC_AVAILABLE BIT(2, UL) /* * Synthetic Timer MSRs (HV_X64_MSR_STIMER0_CONFIG through * HV_X64_MSR_STIMER3_COUNT) available */ -#define HV_MSR_SYNTIMER_AVAILABLE BIT(3) +#define HV_MSR_SYNTIMER_AVAILABLE BIT(3, UL) /* * APIC access MSRs (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR) * are available */ -#define HV_X64_MSR_APIC_ACCESS_AVAILABLE BIT(4) +#define HV_X64_MSR_APIC_ACCESS_AVAILABLE BIT(4, UL) /* Hypercall MSRs (HV_X64_MSR_GUEST_OS_ID and HV_X64_MSR_HYPERCALL) available*/ -#define HV_X64_MSR_HYPERCALL_AVAILABLE BIT(5) +#define HV_X64_MSR_HYPERCALL_AVAILABLE BIT(5, UL) /* Access virtual processor index MSR (HV_X64_MSR_VP_INDEX) available*/ -#define HV_X64_MSR_VP_INDEX_AVAILABLE BIT(6) +#define HV_X64_MSR_VP_INDEX_AVAILABLE BIT(6, UL) /* Virtual system reset MSR (HV_X64_MSR_RESET) is available*/ -#define HV_X64_MSR_RESET_AVAILABLE BIT(7) +#define HV_X64_MSR_RESET_AVAILABLE BIT(7, UL) /* * Access statistics pages MSRs (HV_X64_MSR_STATS_PARTITION_RETAIL_PAGE, * HV_X64_MSR_STATS_PARTITION_INTERNAL_PAGE, HV_X64_MSR_STATS_VP_RETAIL_PAGE, * HV_X64_MSR_STATS_VP_INTERNAL_PAGE) available */ -#define HV_X64_MSR_STAT_PAGES_AVAILABLEBIT(8) +#define HV_X64_MSR_STAT_PAGES_AVAILABLEBIT(8, UL) /* Partition reference TSC MSR is available */ -#define HV_MSR_REFERENCE_TSC_AVAILABLE BIT(9) +#define HV_MSR_REFERENCE_TSC_AVAILABLE BIT(9, UL) /* Partition Guest IDLE MSR is available */ -#define HV_X64_MSR_GUEST_IDLE_AVAILABLEBIT(10) +#define HV_X64_MSR_GUEST_IDLE_AVAILABLEBIT(10, UL) /* * There is a single feature flag that signifies if the partition has access * to MSRs with local APIC and TSC frequencies. */ -#define HV_X64_ACCESS_FREQUENCY_MSRS BIT(11) +#define HV_X64_ACCESS_FREQUENCY_MSRS BIT(11, UL) /* AccessReenlightenmentControls privilege */ -#define HV_X64_ACCESS_REENLIGHTENMENT BIT(13) +#define HV_X64_ACCESS_REENLIGHTENMENT BIT(13, UL) /* * Feature identification: indicates which flags were specified at partition @@ -93,17 +94,17 @@ * defined in section Partition Creation Flags. * These are HYPERV_CPUID_FEATURES.EBX bits. */ -#define HV_X64_CREATE_PARTITIONS BIT(0) -#define HV_X64_ACCESS_PARTITION_ID BIT(1) -#define HV_X64_ACCESS_MEMORY_POOL BIT(2) -#define HV_X64_ADJUST_MESSAGE_BUFFERS BIT(3) -#define HV_X64_POST_MESSAGES BIT(4) -#define HV_X64_SIGNAL_EVENTS BIT(5) -#define HV_X64_CREATE_PORT BIT(6) -#define HV_X64_CONNECT_PORTBIT(7) -#define HV_X64_ACCESS_STATSBIT(8) -#define HV_X64_DEBUGGING BIT(11) -#define HV_X64_CPU_POWER_MANAGEMENTBIT(12) +#define HV_X64_CREATE_PARTITIONS BIT(0, UL) +#define HV_X64_ACCESS_PARTITION_ID BIT(1, UL) +#define HV_X64_ACCESS_MEMORY_POOL BIT(2, UL) +#define HV_X64_ADJUST_MESSAGE_BUFFERS BIT(3, UL) +#define HV_X64_POST_MESSAGES BIT(4, UL) +#define HV_X64_SIGNAL_EVENTS BIT(5, UL) +#define HV_X64_CREATE_PORT BIT(6, UL) +#define HV_X64_CONNECT_PORTBIT(7, UL) +#define
[Xen-devel] [PATCH for-next 5/7] x86: use running_on_hypervisor to gate hypervisor_setup
The hypervisor_setup method is not unique to Xen guest. Signed-off-by: Wei Liu --- xen/arch/x86/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 4aa0af5a12..044c45be36 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1577,7 +1577,7 @@ void __init noreturn __start_xen(unsigned long mbi_p) max_cpus = nr_cpu_ids; } -if ( xen_guest ) +if ( running_on_hypervisor ) hypervisor_setup(); /* Low mappings were only needed for some BIOS table parsing. */ -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-next 1/7] x86: import hyperv-tlfs.h from Linux
Taken from Linux commit b2d8b167e15bb5ec2691d1119c025630a247f649. This is a pristine copy from Linux. It is not used yet and probably doesn't compile. Changes to make it work will come later. Signed-off-by: Wei Liu --- xen/include/asm-x86/guest/hyperv-tlfs.h | 906 1 file changed, 906 insertions(+) create mode 100644 xen/include/asm-x86/guest/hyperv-tlfs.h diff --git a/xen/include/asm-x86/guest/hyperv-tlfs.h b/xen/include/asm-x86/guest/hyperv-tlfs.h new file mode 100644 index 00..7741e211f7 --- /dev/null +++ b/xen/include/asm-x86/guest/hyperv-tlfs.h @@ -0,0 +1,906 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +/* + * This file contains definitions from Hyper-V Hypervisor Top-Level Functional + * Specification (TLFS): + * https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs + */ + +#ifndef _ASM_X86_HYPERV_TLFS_H +#define _ASM_X86_HYPERV_TLFS_H + +#include +#include + +/* + * While not explicitly listed in the TLFS, Hyper-V always runs with a page size + * of 4096. These definitions are used when communicating with Hyper-V using + * guest physical pages and guest physical page addresses, since the guest page + * size may not be 4096 on all architectures. + */ +#define HV_HYP_PAGE_SHIFT 12 +#define HV_HYP_PAGE_SIZE BIT(HV_HYP_PAGE_SHIFT) +#define HV_HYP_PAGE_MASK (~(HV_HYP_PAGE_SIZE - 1)) + +/* + * The below CPUID leaves are present if VersionAndFeatures.HypervisorPresent + * is set by CPUID(HvCpuIdFunctionVersionAndFeatures). + */ +#define HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS 0x4000 +#define HYPERV_CPUID_INTERFACE 0x4001 +#define HYPERV_CPUID_VERSION 0x4002 +#define HYPERV_CPUID_FEATURES 0x4003 +#define HYPERV_CPUID_ENLIGHTMENT_INFO 0x4004 +#define HYPERV_CPUID_IMPLEMENT_LIMITS 0x4005 +#define HYPERV_CPUID_NESTED_FEATURES 0x400A + +#define HYPERV_HYPERVISOR_PRESENT_BIT 0x8000 +#define HYPERV_CPUID_MIN 0x4005 +#define HYPERV_CPUID_MAX 0x4000 + +/* + * Feature identification. EAX indicates which features are available + * to the partition based upon the current partition privileges. + * These are HYPERV_CPUID_FEATURES.EAX bits. + */ + +/* VP Runtime (HV_X64_MSR_VP_RUNTIME) available */ +#define HV_X64_MSR_VP_RUNTIME_AVAILABLEBIT(0) +/* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/ +#define HV_MSR_TIME_REF_COUNT_AVAILABLEBIT(1) +/* + * Basic SynIC MSRs (HV_X64_MSR_SCONTROL through HV_X64_MSR_EOM + * and HV_X64_MSR_SINT0 through HV_X64_MSR_SINT15) available + */ +#define HV_X64_MSR_SYNIC_AVAILABLE BIT(2) +/* + * Synthetic Timer MSRs (HV_X64_MSR_STIMER0_CONFIG through + * HV_X64_MSR_STIMER3_COUNT) available + */ +#define HV_MSR_SYNTIMER_AVAILABLE BIT(3) +/* + * APIC access MSRs (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR) + * are available + */ +#define HV_X64_MSR_APIC_ACCESS_AVAILABLE BIT(4) +/* Hypercall MSRs (HV_X64_MSR_GUEST_OS_ID and HV_X64_MSR_HYPERCALL) available*/ +#define HV_X64_MSR_HYPERCALL_AVAILABLE BIT(5) +/* Access virtual processor index MSR (HV_X64_MSR_VP_INDEX) available*/ +#define HV_X64_MSR_VP_INDEX_AVAILABLE BIT(6) +/* Virtual system reset MSR (HV_X64_MSR_RESET) is available*/ +#define HV_X64_MSR_RESET_AVAILABLE BIT(7) +/* + * Access statistics pages MSRs (HV_X64_MSR_STATS_PARTITION_RETAIL_PAGE, + * HV_X64_MSR_STATS_PARTITION_INTERNAL_PAGE, HV_X64_MSR_STATS_VP_RETAIL_PAGE, + * HV_X64_MSR_STATS_VP_INTERNAL_PAGE) available + */ +#define HV_X64_MSR_STAT_PAGES_AVAILABLEBIT(8) +/* Partition reference TSC MSR is available */ +#define HV_MSR_REFERENCE_TSC_AVAILABLE BIT(9) +/* Partition Guest IDLE MSR is available */ +#define HV_X64_MSR_GUEST_IDLE_AVAILABLEBIT(10) +/* + * There is a single feature flag that signifies if the partition has access + * to MSRs with local APIC and TSC frequencies. + */ +#define HV_X64_ACCESS_FREQUENCY_MSRS BIT(11) +/* AccessReenlightenmentControls privilege */ +#define HV_X64_ACCESS_REENLIGHTENMENT BIT(13) + +/* + * Feature identification: indicates which flags were specified at partition + * creation. The format is the same as the partition creation flag structure + * defined in section Partition Creation Flags. + * These are HYPERV_CPUID_FEATURES.EBX bits. + */ +#define HV_X64_CREATE_PARTITIONS BIT(0) +#define HV_X64_ACCESS_PARTITION_ID BIT(1) +#define HV_X64_ACCESS_MEMORY_POOL BIT(2) +#define HV_X64_ADJUST_MESSAGE_BUFFERS BIT(3) +#define HV_X64_POST_MESSAGES BIT(4) +#define HV_X64_SIGNAL_EVENTS BIT(5) +#define HV_X64_CREATE_PORT BIT(6) +#define HV_X64_CONNECT_PORTBIT(7) +#define HV_X64_ACCESS_STATS
[Xen-devel] [PATCH for-next 4/7] x86: add a comment regarding the location of hypervisor_probe
Signed-off-by: Wei Liu --- xen/arch/x86/setup.c | 4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index cf5a7b8e1e..4aa0af5a12 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -764,6 +764,10 @@ void __init noreturn __start_xen(unsigned long mbi_p) * allocing any xenheap structures wanted in lower memory. */ kexec_early_calculations(); +/* + * The probing has to be done _before_ initialising console, + * otherwise we couldn't set up Xen's PV console correctly. + */ running_on_hypervisor = hypervisor_probe(); parse_video_info(); -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-next 6/7] x86/hyperv: provide hyperv_guest variable
It will be used to gate Hyper-V related code outside of the guest
directory.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/hyperv.c | 3 +++
xen/include/asm-x86/guest/hyperv.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
b/xen/arch/x86/guest/hyperv/hyperv.c
index 041166f344..ee649426ce 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -24,6 +24,7 @@
#include
struct ms_hyperv_info ms_hyperv;
+bool hyperv_guest;
bool __init hyperv_probe(void)
{
@@ -50,6 +51,8 @@ bool __init hyperv_probe(void)
ms_hyperv.max_vp_index = cpuid_eax(HYPERV_CPUID_IMPLEMENT_LIMITS);
ms_hyperv.max_lp_index = cpuid_ebx(HYPERV_CPUID_IMPLEMENT_LIMITS);
+hyperv_guest = true;
+
return true;
}
diff --git a/xen/include/asm-x86/guest/hyperv.h
b/xen/include/asm-x86/guest/hyperv.h
index 0f8800040a..86f5c24ec6 100644
--- a/xen/include/asm-x86/guest/hyperv.h
+++ b/xen/include/asm-x86/guest/hyperv.h
@@ -35,6 +35,8 @@ struct ms_hyperv_info {
};
extern struct ms_hyperv_info ms_hyperv;
+extern bool hyperv_guest;
+
extern struct hypervisor_ops hyperv_ops;
bool hyperv_probe(void);
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-next 3/7] x86/hyperv: extract more information from Hyper-V
Provide a structure to store that information. The structure will be
accessed from other places later so make it public.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/hyperv.c | 14 ++
xen/include/asm-x86/guest/hyperv.h | 12
2 files changed, 26 insertions(+)
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
b/xen/arch/x86/guest/hyperv/hyperv.c
index 7ab4b127f3..041166f344 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -21,6 +21,9 @@
#include
#include
+#include
+
+struct ms_hyperv_info ms_hyperv;
bool __init hyperv_probe(void)
{
@@ -36,6 +39,17 @@ bool __init hyperv_probe(void)
if ( eax != 0x31237648 )/* Hv#1 */
return false;
+/* Extract more information from Hyper-V */
+ms_hyperv.features = cpuid_eax(HYPERV_CPUID_FEATURES);
+ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
+ms_hyperv.hints = cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
+
+if ( ms_hyperv.hints & HV_X64_ENLIGHTENED_VMCS_RECOMMENDED )
+ms_hyperv.nested_features = cpuid_eax(HYPERV_CPUID_NESTED_FEATURES);
+
+ms_hyperv.max_vp_index = cpuid_eax(HYPERV_CPUID_IMPLEMENT_LIMITS);
+ms_hyperv.max_lp_index = cpuid_ebx(HYPERV_CPUID_IMPLEMENT_LIMITS);
+
return true;
}
diff --git a/xen/include/asm-x86/guest/hyperv.h
b/xen/include/asm-x86/guest/hyperv.h
index 4b9cc5a836..0f8800040a 100644
--- a/xen/include/asm-x86/guest/hyperv.h
+++ b/xen/include/asm-x86/guest/hyperv.h
@@ -21,8 +21,20 @@
#ifdef CONFIG_HYPERV_GUEST
+#include
+
#include
+struct ms_hyperv_info {
+uint32_t features;
+uint32_t misc_features;
+uint32_t hints;
+uint32_t nested_features;
+uint32_t max_vp_index;
+uint32_t max_lp_index;
+};
+extern struct ms_hyperv_info ms_hyperv;
+
extern struct hypervisor_ops hyperv_ops;
bool hyperv_probe(void);
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Debugging Windows HVM crashes on Ryzen 3xxx series CPUs.
On 25.10.2019 09:00, Steven Haigh wrote:
> Further to my last, I downloaded the latest Windows Server 2016 ISO from
> Microsoft.
>
> Filename: Windows_Server_2016_Datacenter_EVAL_en-us_14393_refresh.ISO
>
> Have attached as much of the log as I could get attempting to boot from
> the ISO and having a blank LV as the install target.
>
> The Windows error message (shown via VNC) is HAL MEMORY ALLOCATION.
Hmm, that's as if there was still (again?) an issue with CPUID
handling - iirc the same was observable on maximum-size Rome
systems prior to df29d03f1d (and its fixup). Below the debugging
patch I did use at the time, maybe it turns out helpful here too
(and perhaps you'd really only need the first hunk, I had put in
the other one just in case anyway).
However this looks to be different from your earlier report,
where you said you've got some
(XEN) d1v0 VIRIDIAN CRASH: ac 0 a0a0 f8065c06bf88 bf8
So I wonder whether there's a new issue masking the old one.
Jan
--- unstable.orig/xen/arch/x86/hvm/hvm.c
+++ unstable/xen/arch/x86/hvm/hvm.c
@@ -3372,6 +3372,9 @@ int hvm_vmexit_cpuid(struct cpu_user_reg
}
guest_cpuid(curr, leaf, subleaf, );
+if(regs->ax && (regs->eax >> 16) != 0x4000 && (long)regs->rip < 0) {//temp
+ printk("%pv[%08lx]: %08x:%08x=%08x:%08x:%08x:%08x\n", curr, regs->rip, leaf,
subleaf, res.a, res.b, res.c, res.d);
+}
HVMTRACE_6D(CPUID, leaf, subleaf, res.a, res.b, res.c, res.d);
regs->rax = res.a;
--- unstable.orig/xen/arch/x86/hvm/svm/svm.c
+++ unstable/xen/arch/x86/hvm/svm/svm.c
@@ -2223,7 +2223,13 @@ static void svm_do_msr_access(struct cpu
rc = hvm_msr_read_intercept(regs->ecx, _content);
if ( rc == X86EMUL_OKAY )
+{//temp
msr_split(regs, msr_content);
+ if(regs->ecx == 0xc001100c || regs->ecx == 0xc0011005)
+ printk("%pv[%08lx]: %08x -> %08x:%08x\n", curr, regs->rip, regs->ecx,
regs->edx, regs->eax);
+} else if(regs->ecx == 0xc001100c || regs->ecx == 0xc0011005) {
+ printk("%pv[%08lx]: %08x -> #GP\n", curr, regs->rip, regs->ecx);
+}
}
else
rc = hvm_msr_write_intercept(regs->ecx, msr_fold(regs), true);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen: issue deprecation warning for 32-bit pv guest
Support for the kernel as Xen 32-bit PV guest will soon be removed.
Issue a warning when booted as such.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pv.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 58f79ab32358..5bfea374a160 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -117,6 +117,14 @@ static void __init xen_banner(void)
printk(KERN_INFO "Xen version: %d.%d%s%s\n",
version >> 16, version & 0x, extra.extraversion,
xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? "
(preserve-AD)" : "");
+
+#ifdef CONFIG_X86_32
+ pr_warn("WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
WARNING!\n"
+ "Support for running as 32-bit PV-guest under Xen will soon be
removed\n"
+ "from the Linux kernel!\n"
+ "Please use either a 64-bit kernel or switch to HVM or PVH
mode!\n"
+ "WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
WARNING!\n");
+#endif
}
static void __init xen_pv_init_platform(void)
--
2.16.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 143123: all pass - PUSHED
flight 143123 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/143123/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 6996ec88a244a2428beb81d126ee55d152f62a07 baseline version: ovmf 95d2883647dd8bf91f65cde87e73cede1dcc6574 Last test of basis 143072 2019-10-23 17:09:39 Z1 days Failing since143094 2019-10-24 10:02:58 Z0 days2 attempts Testing same since 143123 2019-10-24 20:39:27 Z0 days1 attempts People who touched revisions under test: Laszlo Ersek Liming Gao Michael D Kinney Sean Brogan 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 95d2883647..6996ec88a2 6996ec88a244a2428beb81d126ee55d152f62a07 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Debugging Windows HVM crashes on Ryzen 3xxx series CPUs.
Further to my last, I downloaded the latest Windows Server 2016 ISO from Microsoft. Filename: Windows_Server_2016_Datacenter_EVAL_en-us_14393_refresh.ISO Have attached as much of the log as I could get attempting to boot from the ISO and having a blank LV as the install target. The Windows error message (shown via VNC) is HAL MEMORY ALLOCATION. On 2019-10-25 16:26, Steven Haigh wrote: Just to make things annoying, I also get the following message in the logs for correctly operating Linux PVH DomU's: (XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x2600, fault address = 0xfffdf800, flags = 0x8 As such, I think we're back to zero clues at the moment as to what is going on. Suggestions welcome :) On 2019-10-25 01:45, Paul Durrant wrote: Not much clue in the logs. The crash params are weird though... certainly not matching the doc. (https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xac--hal-memory-allocation) but then again they are not always to be believed. There are some odd looking IOMMU faults in there too. Paul On Thu, 24 Oct 2019 at 13:01, Steven Haigh wrote: Hi all, I've managed to get the git master version of Xen on this affected system and tries to boot a Windows Server 2016 system. It crashes as per normal. I managed to get these logs, but I'm not quite sure what else to do to debug this issue further. Suggestions welcome. The boot log in /var/log/xen/ shows: Waiting for domain soti.vm (domid 4) to die [pid 9174] Domain 4 has shut down, reason code 3 0x3 Action for shutdown reason code 3 is destroy Domain 4 needs to be cleaned up: destroying the domain Done. Exiting now For some reason I'm not getting any serial output - so I'll have to take a look at that tomorrow - but if you need anything further, please let me know and I'll see what I can turn up. Windows config file: type = "hvm" name = "$vmname.vm" viridian = 1 #viridian = ['base'] memory = 8192 vcpus = 4 vif = ['bridge=br51, mac=00:16:3E:64:CC:A0'] #disk = [ '/dev/vg_hosting/$vmname.vm,raw,xvda,rw', 'file:/root/SW_DVD9_NTRL_Windows_Svrs_2016_English_2_Std_DC_FPP_OEM_X21-22567.ISO,hdc:cdrom,r' ] disk = [ '/dev/vg_hosting/$vmname.vm,raw,hda,rw' ] boot = 'cd' vnc = 2 vnclisten = "0.0.0.0" #vncpasswd = '' ## Set the clock to localtime - not UTC... localtime = 1 ## Fix the mouse cursor for VNC usage usbdevice = 'tablet' ## Lower CPU prio that other VMs... cpu_weight = 128 on_poweroff = 'destroy' on_reboot = 'destroy' on_crash = 'destroy' Steven Haigh net...@crc.id.au https://www.crc.id.au +613 9001 6090 +614 1293 5897 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel -- Steven Haigh ? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090? 0412 935 897(XEN) HVM d8v0 save: CPU (XEN) HVM d8v1 save: CPU (XEN) HVM d8v2 save: CPU (XEN) HVM d8v3 save: CPU (XEN) HVM d8 save: PIC (XEN) HVM d8 save: IOAPIC (XEN) HVM d8v0 save: LAPIC (XEN) HVM d8v1 save: LAPIC (XEN) HVM d8v2 save: LAPIC (XEN) HVM d8v3 save: LAPIC (XEN) HVM d8v0 save: LAPIC_REGS (XEN) HVM d8v1 save: LAPIC_REGS (XEN) HVM d8v2 save: LAPIC_REGS (XEN) HVM d8v3 save: LAPIC_REGS (XEN) HVM d8 save: PCI_IRQ (XEN) HVM d8 save: ISA_IRQ (XEN) HVM d8 save: PCI_LINK (XEN) HVM d8 save: PIT (XEN) HVM d8 save: RTC (XEN) HVM d8 save: HPET (XEN) HVM d8 save: PMTIMER (XEN) HVM d8v0 save: MTRR (XEN) HVM d8v1 save: MTRR (XEN) HVM d8v2 save: MTRR (XEN) HVM d8v3 save: MTRR (XEN) HVM d8 save: VIRIDIAN_DOMAIN (XEN) HVM d8v0 save: CPU_XSAVE (XEN) HVM d8v1 save: CPU_XSAVE (XEN) HVM d8v2 save: CPU_XSAVE (XEN) HVM d8v3 save: CPU_XSAVE (XEN) HVM d8v0 save: VIRIDIAN_VCPU (XEN) HVM d8v1 save: VIRIDIAN_VCPU (XEN) HVM d8v2 save: VIRIDIAN_VCPU (XEN) HVM d8v3 save: VIRIDIAN_VCPU (XEN) HVM d8v0 save: VMCE_VCPU (XEN) HVM d8v1 save: VMCE_VCPU (XEN) HVM d8v2 save: VMCE_VCPU (XEN) HVM d8v3 save: VMCE_VCPU (XEN) HVM d8v0 save: TSC_ADJUST (XEN) HVM d8v1 save: TSC_ADJUST (XEN) HVM d8v2 save: TSC_ADJUST (XEN) HVM d8v3 save: TSC_ADJUST (XEN) HVM d8v0 save: CPU_MSR (XEN) HVM d8v1 save: CPU_MSR (XEN) HVM d8v2 save: CPU_MSR (XEN) HVM d8v3 save: CPU_MSR (XEN) HVM8 restore: CPU 0 (XEN) emul-priv-op.c::d0v0 Domain attempted WRMSR c0011020 from 0x00064040 to 0x000640400400 (XEN) emul-priv-op.c::d0v1 Domain attempted WRMSR c0011020 from 0x00064040 to 0x000640400400 (XEN) emul-priv-op.c::d0v0 Domain attempted WRMSR c0011020 from 0x00064040 to 0x000640400400 (XEN) emul-priv-op.c::d0v2 Domain attempted WRMSR c0011020 from 0x00064040 to 0x000640400400 (XEN) emul-priv-op.c::d0v1 Domain attempted WRMSR c0011020 from 0x00064040 to 0x000640400400 (XEN) emul-priv-op.c::d0v1 Domain
Re: [Xen-devel] [PATCH] x86/stackframe/32: repair 32-bit Xen PV
On 25.10.19 08:06, Jan Beulich wrote:
On 24.10.2019 18:11, Andy Lutomirski wrote:
On Mon, Oct 7, 2019 at 3:41 AM Jan Beulich wrote:
Once again RPL checks have been introduced which don't account for a
32-bit kernel living in ring 1 when running in a PV Xen domain. The
case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_WRONG_CR3
as well just in case.
I'm okay with the generated code, but IMO the macro is too indirect
for something that's trivial.
Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
Signed-off-by: Jan Beulich
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -48,6 +48,17 @@
#include "calling.h"
+#ifndef CONFIG_XEN_PV
+# define USER_SEGMENT_RPL_MASK SEGMENT_RPL_MASK
+#else
+/*
+ * When running paravirtualized on Xen the kernel runs in ring 1, and hence
+ * simple mask based tests (i.e. ones not comparing against USER_RPL) have to
+ * ignore bit 0. See also the C-level get_kernel_rpl().
+ */
How about:
/*
* When running on Xen PV, the actual %cs register in the kernel is 1, not 0.
* If we need to distinguish between a %cs from kernel mode and a %cs from
* user mode, we can do test $2 instead of test $3.
*/
#define USER_SEGMENT_RPL_MASK 2
I.e. you're fine using just the single bit in all configurations?
+# define USER_SEGMENT_RPL_MASK (SEGMENT_RPL_MASK & ~1)
+#endif
+
.section .entry.text, "ax"
/*
@@ -172,7 +183,7 @@
ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
.if \no_user_check == 0
/* coming from usermode? */
- testl $SEGMENT_RPL_MASK, PT_CS(%esp)
+ testl $USER_SEGMENT_RPL_MASK, PT_CS(%esp)
Shouldn't PT_CS(%esp) be 0 if we came from the kernel? I'm guessing
the actual bug is in whatever code put 1 in here in the first place.
In other words, I'm having trouble understanding why there is any
context in which some value would be 3 for user mode and 1 for kernel
mode. Obviously if we're manually IRETing to kernel mode, we need to
set CS to 1, but if we're filling in our own PT_CS, we should just
write 0.
The supposedly offending commit (""x86/stackframe/32: Provide
consistent pt_regs") looks correct to me, so I suspect that the
problem is elsewhere. Or is it intentional that Xen PV's asm
(arch/x86/xen/whatever) sticks 1 into the CS field on the stack?
Manually created / updated frames _could_ in principle modify the
RPL, but ones coming from hardware (old 32-bit hypervisors) or Xen
(64-bit hypervisors) will have an RPL of 1, as already said by
Andrew. We could in principle also add a VM assist for the
hypervisor to store an RPL of 0, but I'd expect this to require
further kernel changes, and together with the old behavior still
being required to support I'm unconvinced this would be worth it.
Also, why are we supporting 32-bit Linux PV guests at all? Can we
just delete this code instead?
This was already suggested by Jürgen (now also CC-ed), but in reply
it was pointed out that the process would be to first deprecate the
code, and remove it only a couple of releases later if no-one comes
up with a reason to retain it.
Thanks for the reminder.
I'll send a patch with the deprecation warning for 32-bit PV.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/stackframe/32: repair 32-bit Xen PV
On 24.10.2019 18:11, Andy Lutomirski wrote:
> On Mon, Oct 7, 2019 at 3:41 AM Jan Beulich wrote:
>>
>> Once again RPL checks have been introduced which don't account for a
>> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
>> case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_WRONG_CR3
>> as well just in case.
>
> I'm okay with the generated code, but IMO the macro is too indirect
> for something that's trivial.
>
>>
>> Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
>> Signed-off-by: Jan Beulich
>>
>> --- a/arch/x86/entry/entry_32.S
>> +++ b/arch/x86/entry/entry_32.S
>> @@ -48,6 +48,17 @@
>>
>> #include "calling.h"
>>
>> +#ifndef CONFIG_XEN_PV
>> +# define USER_SEGMENT_RPL_MASK SEGMENT_RPL_MASK
>> +#else
>> +/*
>> + * When running paravirtualized on Xen the kernel runs in ring 1, and hence
>> + * simple mask based tests (i.e. ones not comparing against USER_RPL) have
>> to
>> + * ignore bit 0. See also the C-level get_kernel_rpl().
>> + */
>
> How about:
>
> /*
> * When running on Xen PV, the actual %cs register in the kernel is 1, not 0.
> * If we need to distinguish between a %cs from kernel mode and a %cs from
> * user mode, we can do test $2 instead of test $3.
> */
> #define USER_SEGMENT_RPL_MASK 2
I.e. you're fine using just the single bit in all configurations?
>> +# define USER_SEGMENT_RPL_MASK (SEGMENT_RPL_MASK & ~1)
>> +#endif
>> +
>> .section .entry.text, "ax"
>>
>> /*
>> @@ -172,7 +183,7 @@
>> ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
>> .if \no_user_check == 0
>> /* coming from usermode? */
>> - testl $SEGMENT_RPL_MASK, PT_CS(%esp)
>> + testl $USER_SEGMENT_RPL_MASK, PT_CS(%esp)
>
> Shouldn't PT_CS(%esp) be 0 if we came from the kernel? I'm guessing
> the actual bug is in whatever code put 1 in here in the first place.
>
> In other words, I'm having trouble understanding why there is any
> context in which some value would be 3 for user mode and 1 for kernel
> mode. Obviously if we're manually IRETing to kernel mode, we need to
> set CS to 1, but if we're filling in our own PT_CS, we should just
> write 0.
>
> The supposedly offending commit (""x86/stackframe/32: Provide
> consistent pt_regs") looks correct to me, so I suspect that the
> problem is elsewhere. Or is it intentional that Xen PV's asm
> (arch/x86/xen/whatever) sticks 1 into the CS field on the stack?
Manually created / updated frames _could_ in principle modify the
RPL, but ones coming from hardware (old 32-bit hypervisors) or Xen
(64-bit hypervisors) will have an RPL of 1, as already said by
Andrew. We could in principle also add a VM assist for the
hypervisor to store an RPL of 0, but I'd expect this to require
further kernel changes, and together with the old behavior still
being required to support I'm unconvinced this would be worth it.
> Also, why are we supporting 32-bit Linux PV guests at all? Can we
> just delete this code instead?
This was already suggested by Jürgen (now also CC-ed), but in reply
it was pointed out that the process would be to first deprecate the
code, and remove it only a couple of releases later if no-one comes
up with a reason to retain it.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
