[Xen-devel] [rumprun test] 121072: regressions - FAIL
flight 121072 rumprun real [real] http://logs.test-lab.xenproject.org/osstest/logs/121072/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754 build-i386-rumprun6 rumprun-buildfail REGR. vs. 106754 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a version targeted for testing: rumprun 94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c baseline version: rumprun c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 Last test of basis 106754 2017-03-18 04:21:25 Z 370 days Testing same since 120360 2018-03-09 04:19:20 Z 14 days 11 attempts People who touched revisions under test: Kent McLeod Kent McLeod Naja Melan Sebastian Wicki Wei Liu jobs: build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumprun fail build-i386-rumprun fail test-amd64-amd64-rumprun-amd64 blocked test-amd64-i386-rumprun-i386 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. commit 94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c Merge: 8fe40c8 b3c1033 Author: Kent McLeod Date: Fri Feb 16 09:15:45 2018 +1100 Merge pull request #118 from kent-mcleod/stretch-linking-defaultpie Fix linking on Debian Stretch (gcc-6) commit b3c1033b090b65e8e86999ddd063c174502aa3f0 Author: Kent McLeod Date: Wed Feb 14 16:43:16 2018 +1100 Add further -no-pie checks to Rumprun build tools This builds upon the previous commit to add -no-pie anywhere the relocatable flag (-Wl,-r) is used to handle compilers that enable -pie by default (Such as Debian Stretch). commit 8fe40c84edddfbf472b4a7cce960df749701174c Merge: c7f2f01 685f4ab Author: Sebastian Wicki Date: Fri Jan 5 15:04:18 2018 +0100 Merge pull request #112 from najamelan/bugfix/gcc7-fallthrough Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7 commit 685f4ab3b74b6f1e1b40bdd3d2c42efa44bf385d Author: Naja Melan Date: Thu Jan 4 16:07:46 2018 + Make the disabling of the fallthrough warning dependent on GCC version This should prevent older gcc versions from choking on unknown argument. I have not tested this, just wrote the code directly on github. Use with caution. commit 34056451174e8722b972229fefc1bf9e0b89a7da Author: Naja Melan Date: Wed Jan 3 18:57:50 2018 + Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7 GCC7 comes with a new warning "implicit-fallthrough" which will prevent building the netbsd-src. For more information: https://dzone.com/articles/implicit-fallthrough-in-gcc-7 commit 35d81194b7feb75d20af3ba4fdb45ea76230852f Author: Wei Liu Date: Wed Jun 7 16:30:00 2017 +0100 Fix linking on Debian Stretch Provide cc-option. Use that to check if -no-pie is available and append it when necessary. Signed-off-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 121052: regressions - FAIL
flight 121052 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/121052/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 5 host-ping-check-native fail REGR. vs. 120913 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 120913 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120913 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120913 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120913 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120913 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120913 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-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-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxa779add58a837fbd5156e0fab0aca5e3b53754ef baseline version: linux46e076f0dad02f5c445a5c27adbd3f06147e33ed Last test of basis 120913 2018-03-18 11:32:38 Z5 days Testing same since 121052 2018-03-22 08:44:51 Z1 days1 attempts People who touched revisions under test: "Eric
[Xen-devel] [libvirt test] 121051: regressions - FAIL
flight 121051 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/121051/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 120982 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 120982 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 120982 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 120982 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass version targeted for testing: libvirt 85666f1314d46d8c1e45614b7f8329848bb666e0 baseline version: libvirt 8ef5db6581912e016a400cd8b317d21d004e38af Last test of basis 120982 2018-03-20 05:52:44 Z3 days Testing same since 121051 2018-03-22 08:14:27 Z1 days1 attempts People who touched revisions under test: Andrea Bolognani Cole Robinson Daniel P. Berrangé Han Han Jim Fehlig Jiri Denemark Michal Privoznik Radostin Stoyanov jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in
[Xen-devel] [linux-3.18 test] 121053: regressions - FAIL
flight 121053 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/121053/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 18 leak-check/check fail REGR. vs. 120977 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 120977 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 120977 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 120977 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120977 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120977 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120977 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120977 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 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-amd64-libvirt-xsm 13 migrate-support-checkfail never pass build-arm64-pvops 6 kernel-build 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-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-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-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-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: linux44ec71c0cd728e8cbd346e135eef9b43b03654ab baseline version: linux5fcd9374919e35f015c283d6900a1f0fca00477e Last test of basis 120977 2018-03-19 23:54:00 Z3 days Testing same since 121053 2018-03-22 08:45:13 Z1 days1 attempts People who touched revisions under test: Akinobu Mita Al Viro Alan Stern Alex Deucher Alexander Potapenko Andreas Pape Andrew F. Davis Andrew Lunn Anton Blanchard Arnaldo Carvalho de M
[Xen-devel] [PATCH 4/4] drivers/net: Use octal not symbolic permissions
Prefer the direct use of octal for permissions.
Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
and some typing.
Miscellanea:
o Whitespace neatening around these conversions.
Signed-off-by: Joe Perches
---
drivers/net/bonding/bond_procfs.c | 2 +-
drivers/net/bonding/bond_sysfs.c | 73 +-
drivers/net/bonding/bond_sysfs_slave.c | 4 +-
drivers/net/caif/caif_serial.c | 32 +++
drivers/net/caif/caif_spi.c| 16
drivers/net/caif/caif_virtio.c | 16
drivers/net/can/at91_can.c | 3 +-
drivers/net/can/cc770/cc770.c | 4 +-
drivers/net/can/cc770/cc770_isa.c | 16
drivers/net/can/grcan.c| 4 +-
drivers/net/can/janz-ican3.c | 6 +--
drivers/net/can/sja1000/sja1000_isa.c | 14 +++
drivers/net/can/softing/softing_main.c | 4 +-
drivers/net/can/spi/mcp251x.c | 2 +-
drivers/net/can/usb/esd_usb2.c | 6 +--
drivers/net/can/vcan.c | 2 +-
drivers/net/hamradio/bpqether.c| 3 +-
drivers/net/hamradio/yam.c | 2 +-
drivers/net/hyperv/netvsc_drv.c| 4 +-
drivers/net/ieee802154/at86rf230.c | 2 +-
drivers/net/phy/spi_ks8995.c | 2 +-
drivers/net/ppp/ppp_generic.c | 2 +-
drivers/net/ppp/pppoe.c| 2 +-
drivers/net/usb/cdc_ncm.c | 12 +++---
drivers/net/usb/hso.c | 8 ++--
drivers/net/xen-netback/xenbus.c | 4 +-
drivers/net/xen-netfront.c | 6 +--
27 files changed, 124 insertions(+), 127 deletions(-)
diff --git a/drivers/net/bonding/bond_procfs.c
b/drivers/net/bonding/bond_procfs.c
index f7799321dffb..01059f1a7bca 100644
--- a/drivers/net/bonding/bond_procfs.c
+++ b/drivers/net/bonding/bond_procfs.c
@@ -287,7 +287,7 @@ void bond_create_proc_entry(struct bonding *bond)
if (bn->proc_dir) {
bond->proc_entry = proc_create_data(bond_dev->name,
- S_IRUGO, bn->proc_dir,
+ 0444, bn->proc_dir,
&bond_info_fops, bond);
if (bond->proc_entry == NULL)
netdev_warn(bond_dev, "Cannot create /proc/net/%s/%s\n",
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 040b493f60ae..6096440e96ea 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -147,7 +147,7 @@ static ssize_t bonding_store_bonds(struct class *cls,
static const struct class_attribute class_attr_bonding_masters = {
.attr = {
.name = "bonding_masters",
- .mode = S_IWUSR | S_IRUGO,
+ .mode = 0644,
},
.show = bonding_show_bonds,
.store = bonding_store_bonds,
@@ -202,7 +202,7 @@ static ssize_t bonding_show_slaves(struct device *d,
return res;
}
-static DEVICE_ATTR(slaves, S_IRUGO | S_IWUSR, bonding_show_slaves,
+static DEVICE_ATTR(slaves, 0644, bonding_show_slaves,
bonding_sysfs_store_option);
/* Show the bonding mode. */
@@ -216,8 +216,7 @@ static ssize_t bonding_show_mode(struct device *d,
return sprintf(buf, "%s %d\n", val->string, BOND_MODE(bond));
}
-static DEVICE_ATTR(mode, S_IRUGO | S_IWUSR,
- bonding_show_mode, bonding_sysfs_store_option);
+static DEVICE_ATTR(mode, 0644, bonding_show_mode, bonding_sysfs_store_option);
/* Show the bonding transmit hash method. */
static ssize_t bonding_show_xmit_hash(struct device *d,
@@ -231,7 +230,7 @@ static ssize_t bonding_show_xmit_hash(struct device *d,
return sprintf(buf, "%s %d\n", val->string, bond->params.xmit_policy);
}
-static DEVICE_ATTR(xmit_hash_policy, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(xmit_hash_policy, 0644,
bonding_show_xmit_hash, bonding_sysfs_store_option);
/* Show arp_validate. */
@@ -247,7 +246,7 @@ static ssize_t bonding_show_arp_validate(struct device *d,
return sprintf(buf, "%s %d\n", val->string, bond->params.arp_validate);
}
-static DEVICE_ATTR(arp_validate, S_IRUGO | S_IWUSR, bonding_show_arp_validate,
+static DEVICE_ATTR(arp_validate, 0644, bonding_show_arp_validate,
bonding_sysfs_store_option);
/* Show arp_all_targets. */
@@ -263,7 +262,7 @@ static ssize_t bonding_show_arp_all_targets(struct device
*d,
return sprintf(buf, "%s %d\n",
val->string, bond->params.arp_all_targets);
}
-static DEVICE_ATTR(arp_all_targets, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(arp_all_targets, 0644,
bonding_show_arp_all_targets, bonding_sysfs_store_option);
/* Show fail_over_mac. */
@@ -279,7 +278,7 @@ static ssize_t bonding_show_fail_over_mac(struct device *d,
return sprintf(buf, "%s %d\n", val->string, bond->params.fail_over_mac);
}
-stat
[Xen-devel] [PATCH 0/4] net: drivers/net: Use octal permissions
Using octal and not symbolic permissions is preferred by many as more readable. https://lkml.org/lkml/2016/8/2/1945 Rather than getting these piecemeal, just do them all. Done with checkpatch and some typing. Joe Perches (4): ethernet: Use octal not symbolic permissions wireless: Use octal not symbolic permissions net: Use octal not symbolic permissions drivers/net: Use octal not symbolic permissions drivers/net/bonding/bond_procfs.c | 2 +- drivers/net/bonding/bond_sysfs.c | 73 +++--- drivers/net/bonding/bond_sysfs_slave.c | 4 +- drivers/net/caif/caif_serial.c | 32 +++--- drivers/net/caif/caif_spi.c| 16 +-- drivers/net/caif/caif_virtio.c | 16 +-- drivers/net/can/at91_can.c | 3 +- drivers/net/can/cc770/cc770.c | 4 +- drivers/net/can/cc770/cc770_isa.c | 16 +-- drivers/net/can/grcan.c| 4 +- drivers/net/can/janz-ican3.c | 6 +- drivers/net/can/sja1000/sja1000_isa.c | 14 +-- drivers/net/can/softing/softing_main.c | 4 +- drivers/net/can/spi/mcp251x.c | 2 +- drivers/net/can/usb/esd_usb2.c | 6 +- drivers/net/can/vcan.c | 2 +- drivers/net/ethernet/8390/apne.c | 2 +- drivers/net/ethernet/8390/lib8390.c| 2 +- drivers/net/ethernet/8390/ne.c | 2 +- drivers/net/ethernet/8390/ne2k-pci.c | 2 +- drivers/net/ethernet/8390/smc-ultra.c | 2 +- drivers/net/ethernet/8390/stnic.c | 2 +- drivers/net/ethernet/8390/wd.c | 2 +- drivers/net/ethernet/altera/altera_tse_main.c | 6 +- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 10 +- drivers/net/ethernet/amd/xgbe/xgbe-main.c | 2 +- drivers/net/ethernet/broadcom/bnx2.c | 2 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 12 +-- drivers/net/ethernet/broadcom/sb1250-mac.c | 10 +- drivers/net/ethernet/broadcom/tg3.c| 6 +- drivers/net/ethernet/brocade/bna/bnad.c| 2 +- drivers/net/ethernet/brocade/bna/bnad_debugfs.c| 10 +- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 2 +- drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c| 6 +- drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 112 ++--- .../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c| 10 +- drivers/net/ethernet/ec_bhf.c | 2 +- drivers/net/ethernet/emulex/benet/be_main.c| 6 +- drivers/net/ethernet/ibm/ehea/ehea_main.c | 7 +- drivers/net/ethernet/ibm/ibmveth.c | 2 +- drivers/net/ethernet/intel/igb/igb_hwmon.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.c | 2 +- drivers/net/ethernet/marvell/mvneta.c | 8 +- drivers/net/ethernet/marvell/skge.c| 2 +- drivers/net/ethernet/marvell/sky2.c| 2 +- drivers/net/ethernet/mellanox/mlx4/main.c | 16 +-- drivers/net/ethernet/mellanox/mlxsw/core_hwmon.c | 10 +- drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 32 +++--- .../net/ethernet/netronome/nfp/nfp_net_debugfs.c | 6 +- .../net/ethernet/qlogic/netxen/netxen_nic_main.c | 14 +-- drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 30 +++--- drivers/net/ethernet/qualcomm/qca_debug.c | 2 +- drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c| 4 +- drivers/net/ethernet/sfc/mcdi_mon.c| 2 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 26 ++--- drivers/net/ethernet/sun/niu.c | 10 +- drivers/net/hamradio/bpqether.c| 3 +- drivers/net/hamradio/yam.c | 2 +- drivers/net/hyperv/netvsc_drv.c| 4 +- drivers/net/ieee802154/at86rf230.c | 2 +- drivers/net/phy/spi_ks8995.c | 2 +- drivers/net/ppp/ppp_generic.c | 2 +- drivers/net/ppp/pppoe.c| 2 +- drivers/net/usb/cdc_ncm.c | 12 +-- drivers/net/usb/hso.c | 8 +- drivers/net/wireless/ath/ath5k/base.c | 6 +- drivers/net/wireless/ath/ath5k/debug.c | 37 ++- drivers/net/wireless/ath/ath5k/sysfs.c | 8 +- drivers/net/wireless/ath/ath6kl/debug.c| 43 drivers/net/wireless/ath/ath9k/common-debug.c | 9 +- drivers/net/wireless/ath/ath9k/common-spectral.c | 10 +- drivers/net/wireless/ath/ath9k/debug.c | 40 drivers/net/wireless/ath/ath9k/debug_sta.c | 6 +- drivers/net/wireless/ath/ath9k/dfs_debug.c | 4 +
Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring
On Fri, 23 Mar 2018 13:57:11 + Paul Durrant wrote: [...] >> Few related thoughts: >> >> 1. MMCONFIG address is chipset-specific. On Q35 it's a PCIEXBAR, on >> other x86 systems it may be HECBASE or else. So we can assume it is >> bound to the emulated machine > >Xen emulates the machine so it should be emulating PCIEXBAR. Actually, Xen currently emulates only few devices. Others are provided by QEMU, that's the problem. >> 2. We rely on QEMU to emulate different machines for us. >We should not be. It's a historical artefact that we rely on QEMU for >any part of machine emulation. HVM guests need to see something more or less close to real hardware to run. Even if we later install PV drivers for network/storage/etc usage, we still need to support system firmware (SeaBIOS/OVMF) and be able to install any (ideally) OS which expects to be installed only on some real x86 hw. We also need to be ready to fallback to the emulated hw if eg. user will boot OS in the safe mode. It all depends on what you mean by not relying on QEMU for any part of machine emulation. There is a number of mandatory devices which should be provided for a typical x86 system. Xen emulates some of them, but there is a number which he doesn't. Apart from "classic" devices like RTC, PIT, KBC, etc we need to provide at least storage and network interfaces. Windows installer won't be happy to boot from the PV storage device, he prefers to encounter something like AHCI (Windows 7+), ATA (for older OSes) or ATAPI if it is an iso cd. Providing emulation for the AHCI+ATA+ATAPI trio alone is a non-trivial task. QEMU itself provides only partial implementation of these, many features are unsupported. Another very useful thing to emulate is USB. Depending on the controller version and device classes required, this may be far more complex to emulate than AHCI+ATA+ATAPI combined. So, if you suggest to drop QEMU completely, it means that all this functionality must be replaced by own. Not that hard, but still a lot of effort. OTOH, if you mean stripping QEMU of general PCI bus control and replacing his emulated NB/SB with Xen-owned -- well, it theory it should be possible, with patches on QEMU side. In fact, the emulated chipset (NB+SB combo without supplemental devices) itself is a small part of required emulation. It's relatively easy to provide own analogs of for eg. 'mch' and 'ICH9-LPC' QEMU PCIDevice's, the problem is to glue all remaining parts together. I assume the final goal in this case is to have only a set of necessary QEMU PCIDevice's for which we will be providing I/O, MMIO and PCI conf trapping facilities. Only devices such as rtl8139, ich9-ahci and few others. Basically, this means a new, chipset-less QEMU machine type. Well, in theory it is possible with a bit of effort I think. The main question is where will be the NB/SB/PCIbus emulating part reside in this case. As this part must still have some priveleges, it's basically the same decision problem as with QEMU's dwelling place -- stubdomain, Dom0 or else. >> 3. There are users which touch chipset-specific PCIEXBAR directly if >> they see a Q35 system (OVMF so far) > >And we should squash such accesses. > Yes, we have that privilege (i.e. allocating all IO/MMIO bases) for hvmloader. OVMF should not differ in this subject to SeaBIOS. >The toolstack should be sole >control of the guest memory map. It should be the only building MCFG >so it should decide where the MMCONFIG regions go, not the firmware >running in guest context. HVM memory layout is another problem which needs solution BTW. I had to implement one for my PT goals, but it's very radical I'm afraid. Right now there are wicked issues present in handling memory layout between hvmloader and QEMU. They may see a different memory map, even with overlaps in some (depending on MMIO hole size and content) cases -- like an attempt to place MMIO BAR over memory which is used for vram backing storage by QEMU, causing variety of issues like emulated I/O errors (with a storage device) during guest boot attempt. Regarding control of the guest memory map in the toolstack only... The problem is, only firmware can see a final memory map at the moment. And only the device model knows about invisible "service" ranges for emulated devices, like the LFB content (aka "VRAM") when it is not mapped to a guest. In order to calculate the final memory/MMIO hole split, we need to know: 1) all PCI devices on a PCI bus. At the moment Xen contributes only devices like PT to the final PCI bus (via QMP device_add). Others are QEMU ones. Even Xen platform PCI device relies on QEMU emulation. Non-QEMU device emulators are another source of virtual PCI devices I guess. 2) all chipset-specific emulated MMIO ranges. MMCONFIG is one of them and largest (up to 256Mb for a segment). There are few other smaller ranges, eg. Root Complex registers. All this ranges depend on the emulated chipset. 3) all reserved memory ranges (this one what
[Xen-devel] [xen-unstable-smoke test] 121090: tolerable all pass - PUSHED
flight 121090 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121090/ 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 eabb83121226d5a6a5a68da3a913ac0b5bb1e0cf baseline version: xen 738301591ccb663e7d87f431cdda3d5c9d31ab97 Last test of basis 121084 2018-03-23 10:01:47 Z0 days Testing same since 121090 2018-03-23 17:09:54 Z0 days1 attempts People who touched revisions under test: Doug Goldstein Juergen Gross Roger Pau Monne Roger Pau Monné Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 738301591c..eabb831212 eabb83121226d5a6a5a68da3a913ac0b5bb1e0cf -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [examine test] 121088: tolerable ALL FAIL
flight 121088 examine real [real] http://logs.test-lab.xenproject.org/osstest/logs/121088/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: examine-cubietruck-braque 2 hosts-allocate broken like 119971 examine-godello0 2 hosts-allocate broken like 119971 examine-arndale-metrocentre 2 hosts-allocate broken like 119971 examine-chardonnay1 2 hosts-allocate broken like 119971 examine-arndale-westfield 2 hosts-allocate broken like 119971 examine-fiano02 hosts-allocate broken like 119971 examine-rimava0 2 hosts-allocate broken like 119971 examine-baroque0 2 hosts-allocate broken like 119971 examine-laxton1 2 hosts-allocate broken like 119971 examine-cubietruck-gleizes2 hosts-allocate broken like 119971 examine-cubietruck-picasso2 hosts-allocate broken like 119971 examine-huxelrebe02 hosts-allocate broken like 119971 examine-fiano12 hosts-allocate broken like 119971 examine-elbling0 2 hosts-allocate broken like 119971 examine-baroque1 2 hosts-allocate broken like 119971 examine-italia0 2 hosts-allocate broken like 119971 examine-godello1 2 hosts-allocate broken like 119971 examine-elbling1 2 hosts-allocate broken like 119971 examine-chardonnay0 2 hosts-allocate broken like 119971 examine-pinot12 hosts-allocate broken like 119971 examine-italia1 2 hosts-allocate broken like 119971 examine-pinot02 hosts-allocate broken like 119971 examine-arndale-lakeside 2 hosts-allocate broken like 119971 examine-arndale-bluewater 2 hosts-allocate broken like 119971 examine-huxelrebe12 hosts-allocate broken like 119971 examine-cubietruck-metzinger 2 hosts-allocate broken like 119971 baseline version: flight 119971 jobs: examine-baroque0 fail examine-baroque1 fail examine-arndale-bluewaterfail examine-cubietruck-braquefail examine-chardonnay0 fail examine-chardonnay1 fail examine-elbling0 fail examine-elbling1 fail examine-fiano0 fail examine-fiano1 fail examine-cubietruck-gleizes fail examine-godello0 fail examine-godello1 fail examine-huxelrebe0 fail examine-huxelrebe1 fail examine-italia0 fail examine-italia1 fail examine-arndale-lakeside fail examine-laxton1 fail examine-arndale-metrocentre fail examine-cubietruck-metzinger fail examine-cubietruck-picasso fail examine-pinot0 fail examine-pinot1 fail examine-rimava0 fail examine-arndale-westfieldfail 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 Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.7-testing test] 121047: tolerable FAIL - PUSHED
flight 121047 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/121047/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119780 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119780 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 119780 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 119780 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119780 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119780 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 119780 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119780 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119780 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119780 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 119780 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119780 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 119780 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 119780 test-xtf-amd64-amd64-1 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-memop-seg fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 7e5f68befc6fc40b50d2fece228dad72f4fdfd43 baseline version: xen c64e0c1cb5cda
Re: [Xen-devel] [seabios test] 121050: regressions - FAIL
On Fri, Mar 23, 2018 at 05:06:30PM +, osstest service owner wrote: > flight 121050 seabios real [real] > http://logs.test-lab.xenproject.org/osstest/logs/121050/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. > 115539 http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ws16-amd64/ALL This test has been failing on all our branches. I think we got lucky once in the seabios branch. > > Tests which did not succeed, but are not blocking: > test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like > 115539 > test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like > 115539 > test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like > 115539 > test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check > fail never pass > test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check > fail never pass > test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 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 > > version targeted for testing: > seabios 4922d6cb391b8ea48a35a73c46e484cf5f1a9b1a > baseline version: > seabios 0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea > > Last test of basis 115539 2017-11-03 20:48:58 Z 139 days > Failing since115733 2017-11-10 17:19:59 Z 132 days 152 attempts > Testing same since 121050 2018-03-22 07:01:10 Z1 days1 attempts The regression actually started a long time ago. Looking at the range of commits tested on that day, it is only a doc change. I think we should force push the seabios branch. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [seabios test] 121050: regressions - FAIL
flight 121050 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/121050/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 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 version targeted for testing: seabios 4922d6cb391b8ea48a35a73c46e484cf5f1a9b1a baseline version: seabios 0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea Last test of basis 115539 2017-11-03 20:48:58 Z 139 days Failing since115733 2017-11-10 17:19:59 Z 132 days 152 attempts Testing same since 121050 2018-03-22 07:01:10 Z1 days1 attempts People who touched revisions under test: Kevin O'Connor Marc-André Lureau Marcel Apfelbaum Michael S. Tsirkin Nikolay Nikolov Paul Menzel Stefan Berger Stephen Douthit 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 374 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items
On Fri, 23 Mar 2018, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monné [mailto:roy...@gmail.com] On Behalf Of Roger Pau > > Monné > > Sent: 23 March 2018 09:44 > > To: Stefano Stabellini > > Cc: Lars Kurth ; Juergen Gross ; Ji, > > John ; xen-de...@lists.xensource.com; Wei Liu > > ; Tamas K Lengyel ; Andrew > > Cooper ; Daniel Kiper > > ; Christopher Clark > > ; Rich Persaud ; > > Janakarajan Natarajan ; Julien Grall > > ; Paul Durrant ; > > committ...@xenproject.org; Jan Beulich' ; Brian > > Woods > > Subject: Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC > > - Call for Agenda Items > > > > On Thu, Mar 22, 2018 at 03:51:11PM -0700, Stefano Stabellini wrote: > > > On Thu, 22 Mar 2018, Lars Kurth wrote: > > > > On 22/03/2018, 14:49, "Julien Grall" wrote: > > > > > > > > >> - > > > > >> > > > > >> I think we need to discuss PCI emulation and our future > > > > direction. > > Our current hybrid with QEMU is becoming increasingly problematic. > > > > > > > > > > +1 > > > > > > > > I think it would be worth for Stefano and I to join this discussion. > > > > Ideally, we want to use a common solution between Arm and x86. > > > > > > > > Not sure the time will fit for Stefano thought. > > > > > > > > It's at 7am Pacific, which is a little early for Stefano. I can't > > > > really move the > > call: it was quite hard to agree a time-slot. > > > > But we could aim to schedule this discussion for say 7:30 or 7:45, which > > makes this easier for Stefano > > > > > > Yes, indeed it is very early for Stefano :-) > > > > > > But I can do 7:30-7:45 for once. > > > > > > In general, for things that interest both x86 and Arm, and PCI > > > passthrough is a great example, I think it would be best to organize > > > topic specific calls (that I would love push to 8AM or later ;-) > > > > This is probably going to be a big topic, so I agree that a separate > > call with a dedicated agenda might be better. > > > > Yes, and it may be prudent to reserve some time for a design session at > summit, if relevant folks will be there. +1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.1 test] 121048: regressions - trouble: blocked/broken/fail/pass
flight 121048 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/121048/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt broken build-armhf-libvirt 5 host-build-prep fail REGR. vs. 118294 build-arm64-pvops 6 kernel-build fail REGR. vs. 118294 build-i386-pvops 6 kernel-build fail REGR. vs. 118294 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 120984 pass in 121048 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 120984 pass in 121048 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail pass in 120984 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 saverestore-support-check fail in 120984 like 118294 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 120984 like 118294 test-armhf-armhf-libvirt13 migrate-support-check fail in 120984 never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 120984 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 120984 never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 120984 never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118294 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118294 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu
Re: [Xen-devel] [PATCH 12/20] xen/domctl: Merge max_vcpus into createdomain
>>> On 19.03.18 at 20:13, wrote:
> @@ -551,6 +555,37 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> if ( !ret )
> goto createdomain_fail_late;
>
> +ret = -EINVAL;
> +if ( vcpus > domain_max_vcpus(d) )
> +goto createdomain_fail_late;
> +
> +ret = -ENOMEM;
> +online = cpupool_domain_cpumask(d);
> +
> +BUG_ON(d->vcpu);
> +BUG_ON(d->max_vcpus);
> +
> +d->vcpu = xzalloc_array(struct vcpu *, vcpus);
> +/* Install vcpu array /then/ update max_vcpus. */
> +smp_wmb();
> +if ( !d->vcpu )
> +goto createdomain_fail_late;
> +d->max_vcpus = vcpus;
> +
> +cpu = cpumask_any(online);
> +for ( i = 0; i < vcpus; ++i )
> +{
> +BUG_ON(d->vcpu[i]);
> +
> +if ( alloc_vcpu(d, i, cpu) == NULL )
> +goto createdomain_fail_late;
> +
> +BUG_ON(!d->vcpu[i]);
> +
> +cpu = cpumask_cycle(d->vcpu[i]->processor, online);
> +}
> +
> +ret = 0;
> d = NULL;
> break;
Same question here regarding the late placement. Additionally, by
doing this after insertion onto the list, you still leave a window
where the domain can be found but has a NULL vcpus pointer.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 11/20] xen/domctl: Merge set_gnttab_limits into createdomain
>>> On 19.03.18 at 20:13, wrote: > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -539,14 +539,37 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) > u_domctl) > break; > } > > +/* Stash the new domid for the toolstack. */ > +op->domain = d->domain_id; > +copyback = true; > + > d->max_evtchn_port = > min_t(unsigned int, op->u.createdomain.max_evtchn_port, INT_MAX); > > -ret = 0; > -op->domain = d->domain_id; > -copyback = 1; > +ret = grant_table_set_limits(d, op->u.createdomain.max_grant_frames, > + op->u.createdomain.max_maptrack_frames); > +if ( !ret ) > +goto createdomain_fail_late; > + > d = NULL; > break; > + > +createdomain_fail_late: > +/* > + * We've hit an error after putting the domain into the domain list, > + * meaning that other entities in the system can refer to it. > + * > + * Unwinding is substantially more complicated, and without > + * returning success, the toolstack wont know to clean up. > + * > + * Reuse the continuation logic to turn this hypercall into a > + * destroydomain on behalf of the toolstack. > + */ > +op->cmd = XEN_DOMCTL_destroydomain; > +d = NULL; > + > +ret = hypercall_create_continuation(__HYPERVISOR_domctl, "h", > u_domctl); > +break; > } Nice idea, but what exactly is the reason you can't do this before inserting the domain into the list? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature
>>> On 23.03.18 at 15:11, wrote: > On 23/03/18 14:46, Jan Beulich wrote: >> Valid point. Looking at all present uses of ->arch.cr3, it's probably >> indeed better the way you have it. However, I'm now wondering >> about something else: make_cr3() leaves PCID as zero for HVM >> and idle domains, but runs Xen with PCIDs 2 and 3 for (some) PV >> domains. That looks like an undesirable setup though - it would >> seem better to run Xen (with full page tables) with PCID 0 at all >> times. >> >> Then we'd have e.g. >> PCID 0 Xen (full page tables) >> PCID x PV guest priv >> PCID y PV guest user > > So this would need another way to switch between guest and xen %cr3. > Or would you want to use different %cr3 values with the same PCID > without flushing the TLB in between? This seems to be a way to ask for > problems... Well, a TLB flush is clearly needed in such a setup when going from kernel to user mode. > In case you'd use the same %cr3 (guest kernel one, I guess) for both > cases: are you really sure there is no problem in any hypervisor path > accessing guest data which would result in using guest kernel access > rights when coming from user mode (BTW: that was the security note I > had in v2 of my series). I'm afraid I don't understand: Same %cr3? There are separate kernel and user page tables, requiring different values anyway. I also don't understand what problems in hypervisor code paths you suspect, when everything looks to work fine right now without PCID. >> Global pages in PCID 0 could then still be permitted, and wouldn't >> ever need flushing except when FLUSH_TLB_GLOBAL is requested. >> >> As to the use of two separate PCIDs for PV kernel and user modes >> - while this helps isolation, it prevents recovering the non-XPTI >> property of user mode TLB entries surviving in-guest mode switches. > > I don't get that. With PCID the guest's kernel _and_ user entries > will survive in-guest mode switches as there is no TLB flushing > involved (the no-flush bit is set in v->arch.cr3 for both modes). > > The only downside are guest kernel accesses to user pages: they will > need additional TLB entries as the PCID is different. That's the point I was trying to make. This was further explained in my previous reply a little further down. >> I wonder whether this is part of the reason you see PCID have a >> negative effect in the non-XPTI case. >> >> So in the end the question is: Why not use just two PCIDs, and >> allow global pages just like we do now, with the added benefit >> that we no longer need to flush Xen's global TLB entries just >> because we want to get rid of PV guest user ones. > > I can't see how that would work without either needing some more TLB > flushes in order to prevent stale TLB entries or loosing the Meltdown > mitigation. > > Which %cr3/PCID combination should be used in hypervisor, guest kernel > and guest user mode? Xen would run with PCID 0 (and full Xen mappings) at all times (except early entry and late exit code of course). The guest would run with PCID 1 (and minimal Xen mappings) at all times. The switch of PCID eliminates the need for flushes on the way out and back in. > Which pages would be global? Use of global pages would continue to be as today: Xen has some, and guest user mode has some. Of course it is quite possible that the use of global pages with a single guest PCID is still worse than no global pages with two guest PCIDs, but that's a separate step to take (and measure) imo. >>> I don't >>> want to use global guest user pages together with PCID as flushing >>> global pages from the TLB with PCID enabled requires flushing either >>> the complete TLB or you'd have to use INVLPG in all possible address >>> spaces (so you'd need to have multiple %cr3 switches). >> >> Well, yes, flushing _individual_ pages is a problem in that case. >> As to multiple CR3 switches - are these all that bad really with >> the no-flush bit set? With the reduced number of PCIDs in actual >> use (as discussed above) "all possible address spaces" would >> mean just two. And I could imagine that in a number of cases >> just one INVLPG (with the right PCID active) might suffice. >> >> One complicating factor is that we don't want to introduce >> Xen TLB entries for other than what we map in the minimal page >> tables into PV guest PCID space, which would happen if we >> simply switched PCID around an INVLPG. >> >> What I don't understand in any event is why you need separate >> PCIDs for Xen depending on whether the active PV guest is in >> kernel or user mode. > > Main reason are the different page tables anchored in %cr3. Hmm, right, looks like we can't have the best of both worlds: We'd like the Xen part of the address space to be shared, but the guest part of it to be separate. Question then still is whether the reduced flushing outweighs the reduced sharing. IOW between what we have today (a single PCID and a lot of flushing) and what you introduce
Re: [Xen-devel] [PATCH v3] drm/xen-front: Add support for Xen PV display frontend
My apologies, but I found a few more things that look strange and should
be cleaned up. Sorry for this iterative review approach, but I think we're
slowly getting there.
Thank you for reviewing!
Cheers, Daniel
---
+static int xen_drm_drv_dumb_create(struct drm_file *filp,
+ struct drm_device *dev, struct drm_mode_create_dumb *args)
+{
+ struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+ struct drm_gem_object *obj;
+ int ret;
+
+ ret = xen_drm_front_gem_dumb_create(filp, dev, args);
+ if (ret)
+ goto fail;
+
+ obj = drm_gem_object_lookup(filp, args->handle);
+ if (!obj) {
+ ret = -ENOENT;
+ goto fail_destroy;
+ }
+
+ drm_gem_object_unreference_unlocked(obj);
You can't drop the reference while you keep using the object, someone else
might sneak in and destroy your object. The unreference always must be
last.
Will fix, thank you
+
+ /*
+* In case of CONFIG_DRM_XEN_FRONTEND_CMA gem_obj is constructed
+* via DRM CMA helpers and doesn't have ->pages allocated
+* (xendrm_gem_get_pages will return NULL), but instead can provide
+* sg table
+*/
+ if (xen_drm_front_gem_get_pages(obj))
+ ret = xen_drm_front_dbuf_create_from_pages(
+ drm_info->front_info,
+ xen_drm_front_dbuf_to_cookie(obj),
+ args->width, args->height, args->bpp,
+ args->size,
+ xen_drm_front_gem_get_pages(obj));
+ else
+ ret = xen_drm_front_dbuf_create_from_sgt(
+ drm_info->front_info,
+ xen_drm_front_dbuf_to_cookie(obj),
+ args->width, args->height, args->bpp,
+ args->size,
+ xen_drm_front_gem_get_sg_table(obj));
+ if (ret)
+ goto fail_destroy;
+
The above also has another race: If you construct an object, then it must
be fully constructed by the time you publish it to the wider world. In gem
this is done by calling drm_gem_handle_create() - after that userspace can
get at your object and do nasty things with it in a separate thread,
forcing your driver to Oops if the object isn't fully constructed yet.
That means you need to redo this code here to make sure that the gem
object is fully set up (including pages and sg tables) _before_ anything
calls drm_gem_handle_create().
You are correct, I need to rework this code
This probably means you also need to open-code the cma side, by first
calling drm_gem_cma_create(), then doing any additional setup, and finally
doing the registration to userspace with drm_gem_handle_create as the very
last thing.
Although I tend to avoid open-coding, but this seems the necessary
measure here
Alternativet is to do the pages/sg setup only when you create an fb (and
drop the pages again when the fb is destroyed), but that requires some
refcounting/locking in the driver.
Not sure this will work: nothing prevents you from attaching multiple
FBs to a single dumb handle
So, not only ref-counting should be done here, but I also need to check
if the dumb buffer,
we are attaching to, has been created already
So, I will rework with open-coding some stuff from CMA helpers
Aside: There's still a lot of indirection and jumping around which makes
the code a bit hard to follow.
Probably I am not sure of which indirection we are talking about, could
you please
specifically mark those annoying you?
+
+static void xen_drm_drv_release(struct drm_device *dev)
+{
+ struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+ struct xen_drm_front_info *front_info = drm_info->front_info;
+
+ drm_atomic_helper_shutdown(dev);
+ drm_mode_config_cleanup(dev);
+
+ xen_drm_front_evtchnl_free_all(front_info);
+ dbuf_free_all(&front_info->dbuf_list);
+
+ drm_dev_fini(dev);
+ kfree(dev);
+
+ /*
+* Free now, as this release could be not due to rmmod, but
+* due to the backend disconnect, making drm_info hang in
+* memory until rmmod
+*/
+ devm_kfree(&front_info->xb_dev->dev, front_info->drm_info);
+ front_info->drm_info = NULL;
+
+ /* Tell the backend we are ready to (re)initialize */
+ xenbus_switch_state(front_info->xb_dev, XenbusStateInitialising);
This needs to be in the unplug code. Yes that means you'll have multiple
drm_devices floating around, but that's how hotplug works. That would also
mean that you need to drop the front_info pointer from the backend at
unplug time.
If you don't like those semantics then the only other option is to never
destroy the drm_device, but only mark the drm_connector as disconnected
when the xenbus backend is gone. But this half-half solution here wher
Re: [Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai
>>> On 23.03.18 at 12:28, wrote:
> From: FionaLi
>
> Signed-off-by: Fiona Li
First of all, please shorten the subject and put a fair part of what
you had there in the description.
Then you talk about a VT-d compatible IOMMU, but not about VMX
or some other CPU side hardware virtualization. Is that really not
available?
Further it would help if the mail address you send from was in
sync (or at least allow some matching with) the one in the From
and S-o-b.
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Makefile
> @@ -5,6 +5,7 @@ obj-y += amd.o
> obj-y += centaur.o
> obj-y += common.o
> obj-y += intel.o
> +obj-y += shanghai.o
Please put where it belongs alphabetically.
> --- /dev/null
> +++ b/xen/arch/x86/cpu/shanghai.c
> @@ -0,0 +1,61 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "cpu.h"
> +
> +#define ACE_PRESENT(x) ((x)&(1U<<6))
> +#define ACE_ENABLED(x) ((x)&(1U<<7))
> +#define ACE_FCR (1U << 28) /* MSR_ZX_ACE Advanced
> Cryprography Engine */
> +
> +#define RNG_PRESENT(x) ((x)&(1U<<6))
> +#define RNG_ENABLED(x) ((x)&(1U<<7))
> +#define RNG_ENABLE (1U << 6) /* MSR_ZX_RNG Random Number Generator */
Style: Blanks around binary operators please.
> +
> +
> +
Please don't put multiple consecutive blank lines anywhere.
> +static void init_shanghai(struct cpuinfo_x86 *c)
> +{
> + uint64_t msr_ace,msr_rng;
> + /* Test for Shanghai Extended CPUID information */
> + if (cpuid_eax(0xC000) >= 0xC001) {
> + /*Get Shanghai Extended function number */
> + u32 extented_feature_flags = cpuid_edx(0xC001);
> +
> + /* enable ACE,if support ACE unit */
> + if(ACE_PRESENT(extented_feature_flags) &&
> !ACE_ENABLED(extented_feature_flags)) {
> + rdmsrl(MSR_ZX_ACE, msr_ace);
> + /* enable ACE */
> + wrmsrl(MSR_ZX_ACE, (msr_ace | ACE_FCR));
> + printk(KERN_INFO "CPU: Enabled ACE h/w crypto\n");
> + }
> + /* enable RNG,if support RNG unit */
> + if (RNG_PRESENT(extented_feature_flags) &&
> !RNG_ENABLED(extented_feature_flags)) {
> + rdmsrl(MSR_ZX_RNG, msr_rng);
> + /* enable RNG */
> + wrmsrl(MSR_ZX_RNG, msr_rng | RNG_ENABLE);
> + printk(KERN_INFO "CPU: Enabled h/w RNG\n");
> + }
> + }
> +
> + if (c->x86 == 0x6 && c->x86_model >= 0xf) {
> + c->x86_cache_alignment = c->x86_clflush_size * 2;
> + __set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> + }
Is there a specification available anywhere for all of the above?
What about guests? How would they know these extensions are
available for their use?
> --- a/xen/include/asm-x86/iommu.h
> +++ b/xen/include/asm-x86/iommu.h
> @@ -53,6 +53,7 @@ static inline const struct iommu_ops *iommu_get_ops(void)
> {
> switch ( boot_cpu_data.x86_vendor )
> {
> +case X86_VENDOR_SHANGHAI:
> case X86_VENDOR_INTEL:
> return &intel_iommu_ops;
> case X86_VENDOR_AMD:
> @@ -68,6 +69,7 @@ static inline int iommu_hardware_setup(void)
> {
> switch ( boot_cpu_data.x86_vendor )
> {
> +case X86_VENDOR_SHANGHAI:
> case X86_VENDOR_INTEL:
> return intel_vtd_setup();
> case X86_VENDOR_AMD:
Please don't put new entries first.
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -293,6 +293,10 @@
> #define MSR_TMTA_LRTI_READOUT0x80868018
> #define MSR_TMTA_LRTI_VOLT_MHZ 0x8086801a
>
> +/* Shanghai ZhaoXin defined MSRs*/
> +#define MSR_ZX_ACE 0x1107
> +#define MSR_ZX_RNG 0x110b
As Wei has already indicated, we'd prefer consistent names.
Either ZX / ZhaoXin everywhere, or Shanghai. If one of them is
just a code name, the permanent one would obviously better.
This extends to ...
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -22,6 +22,7 @@ int amd_init_cpu(void);
> int cyrix_init_cpu(void);
> int nsc_init_cpu(void);
> int centaur_init_cpu(void);
> +int shanghai_init_cpu(void);
... this and ...
> --- a/xen/include/asm-x86/x86-vendors.h
> +++ b/xen/include/asm-x86/x86-vendors.h
> @@ -7,7 +7,8 @@
> #define X86_VENDOR_INTEL 0
> #define X86_VENDOR_AMD 1
> #define X86_VENDOR_CENTAUR 2
> -#define X86_VENDOR_NUM 3
> +#define X86_VENDOR_SHANGHAI 3
... this (alongside the file name chosen).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing test] 121045: tolerable FAIL - PUSHED
flight 121045 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/121045/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 0f92968bcfa037c7747bc58b9e8a52603e52e182 baseline version: xen cee48d83cb5a7023c4bde93bbb5d42f8c110579d Last test of basis 120967 2018-03-19 12:08:34 Z4 days Testing same since 121045 2018-03-22 02:28:40 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Boris Ostrovsky George Dunlap Jan Beulich Juergen Gross Liran Alon Martin Cerveny jobs: build-amd64-xsm pass build-arm64-xsm
Re: [Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai. Shanghai cpu defines two msr registers to enable Random Number Generator and Advanced Cryprography Engine.The cpu supports
>>> On 23.03.18 at 13:41, wrote:
> On Fri, Mar 23, 2018 at 07:28:56PM +0800, Fionali wrote:
>> +/* Test for Shanghai Extended CPUID information */
>> +if (cpuid_eax(0xC000) >= 0xC001) {
>
> Coding style. Should be
>
> if ( )
> {
FAOD with the tab replaced by 4 spaces.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] possible I/O emulation state machine issue
>>> On 23.03.18 at 14:41, wrote: > Ah that's true. We will do the check based on the response state even if the > next IO is going to be dealt with internally. So, yes, the real question is > why the previous I/O was completed without apparently waiting for QEMU to > finish. > We should have sent the VGA PIO out to QEMU, resulting in > hvm_vcpu_io_need_completion() returning true in handle_pio() meaning that > vio->io_completion gets set to HVMIO_pio_completion. We should then return > true from handle_pio() resulting in RIP being advanced when we return to > guest, but we should not get back into the guest because hvm_do_resume() > should see the pending IO flag on one of the ioreq server vcpus and block on > the relevant event channel. > So somehow it appears the vcpu got back into guest and executed the next > instruction whilst there was pending I/O. I've extended my debugging patch to check vio->io_req.state for being other STATE_IOREQ_NONE first thing in the VMEXIT handler as well as first and last thing in vmx_vmenter_helper(). If you have any other ideas where to place sanity checks, I'm all ears. If that doesn't help, I guess I'll have to pull out a bigger hammer and log recent ioreq-s handled (and perhaps individual steps thereof) to see if their sequence rings any bell. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/libxc: fix usage of XEN_X86_EMU_ALL after VPCI addition
On Fri, Mar 23, 2018 at 10:57:56AM +, Roger Pau Monne wrote: > HVM guest should be created with (XEN_X86_EMU_ALL & > ~XEN_X86_EMU_VPCI). This is not an issue for xl/libxl because it > already sets the correct emulation flags and doesn't pass a NULL > xc_domain_configuration_t to xc_domain_create. > > Signed-off-by: Roger Pau Monné Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] tools/xenstore: fix linking libxenstore with ldl
On Fri, Mar 23, 2018 at 08:42:53AM +0100, Juergen Gross wrote:
> Commit 448c03b3cbe1487 ("tools/xenstore: try to get minimum thread
> stack size for watch thread") added a dependency to libdl to
> libxenstore. Unfortunately the way it was added requires now all
> users of libxenstore to specify "-ldl" when linking. This can be
> avoided by linking libxenstore.so specifying "-ldl" as a trailing
> option. So use APPEND_LDFLAGS instead of LDFLAGS for adding the
> "-ldl" option when linking libxenstore.so.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] tools/xenstore: fix linking libxenstore with ldl
On 3/23/18 2:42 AM, Juergen Gross wrote:
> Commit 448c03b3cbe1487 ("tools/xenstore: try to get minimum thread
> stack size for watch thread") added a dependency to libdl to
> libxenstore. Unfortunately the way it was added requires now all
> users of libxenstore to specify "-ldl" when linking. This can be
> avoided by linking libxenstore.so specifying "-ldl" as a trailing
> option. So use APPEND_LDFLAGS instead of LDFLAGS for adding the
> "-ldl" option when linking libxenstore.so.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Doug Goldstein
Tested-by: Doug Goldstein
--
Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature
On 23/03/18 14:46, Jan Beulich wrote: On 23.03.18 at 12:29, wrote: >> On 23/03/18 11:51, Jan Beulich wrote: >> On 21.03.18 at 13:51, wrote: Avoid flushing the complete TLB when switching %cr3 for mitigation of Meltdown by using the PCID feature if available. We are using 4 PCID values for a 64 bit pv domain subject to XPTI and 2 values for the non-XPTI case: - guest active and in kernel mode - guest active and in user mode - hypervisor active and guest in user mode (XPTI only) - hypervisor active and guest in kernel mode (XPTI only) >>> >>> Before committing to this route, Jun, Kevin, can we please get >>> confirmation that PCID isn't (and isn't going to be) subject to the >>> same speculation issues in the pipeline that the U/S bit is (having >>> caused Meltdown in the first place)? To me it seems a pretty >>> likely thing to play all the same games. >> >> Really? This would assume either the processor is capable to deal with >> multiple matching TLB entries when speculating or that there can be >> only one entry per virtual address present in the TLB at the same time >> in spite of different PCIDs. > > Hmm, yes, good point. > >> And why aren't you asking for the same problem with VPIDs? This should >> be comparable to the PCID problem you are suspecting. > > Since Linux is using the approach, I'm not really suspecting a > problem. I'd just like to be sure there is none / not going to be > one. None of this is spelled out in the doc after all. > --- docs/misc/xen-command-line.markdown | 12 + xen/arch/x86/debug.c| 3 ++- xen/arch/x86/domain_page.c | 2 +- xen/arch/x86/domctl.c | 4 +++ xen/arch/x86/flushtlb.c | 49 -- xen/arch/x86/mm.c | 34 +--- xen/arch/x86/pv/dom0_build.c| 1 + xen/arch/x86/pv/domain.c| 52 + xen/include/asm-x86/domain.h| 14 +++--- xen/include/asm-x86/pv/domain.h | 2 ++ xen/include/asm-x86/x86-defns.h | 1 + 11 files changed, 158 insertions(+), 16 deletions(-) >>> >>> Having had the discussion previously, I'm missing a change to >>> smp.c:new_tlbflush_clock_period() here. >> >> I can add that. I did not do this as I haven't treated FLUSH_TLB >> differently to FLUSH_TLB_GLOBAL (trying this even without any other >> change to staging led to degfaults in dom0). So such a change to >> new_tlbflush_clock_period() should be a separate patch I believe. > > Ah yes, you don't have the "flushing too much" issue anymore in > this version, or at least not in as obvious a way. Or wait - it's in > patch 4. You still do an including-global flush there regardless of > whether FLUSH_TLB_GLOBAL was actually requested. Anyway, > we'll save this aspect for later. > --- a/xen/arch/x86/debug.c +++ b/xen/arch/x86/debug.c @@ -97,7 +97,8 @@ dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val) l3_pgentry_t l3e, *l3t; l2_pgentry_t l2e, *l2t; l1_pgentry_t l1e, *l1t; -unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3); +unsigned long cr3 = (pgd3val ? pgd3val + : (dp->vcpu[0]->arch.cr3 & ~X86_CR3_NOFLUSH)); >>> >>> What about the PCID portion? You want the address of the page >>> here, so I think you should use a "white-listing" masking operation >>> instead of a blacklisting one. >> >> The PCID portion is no problem here as the value is converted into a >> mfn. >> >> I can do the modification you are asking for, of course. > > Well, even if the bits are shifter out in the end, the code could > look more correct. Plus by masking to just the address, future > new meaning assigned to currently unused bits would not be > a problem for this piece of code anymore. > +/* + * Return additional PCID specific cr3 bits. + * + * Note that X86_CR3_NOFLUSH will not be readable in cr3. Anyone consuming + * v->arch.cr3 should mask away X86_CR3_NOFLUSH and X86_CR3_PCIDMASK in case >>> >>> I stand to my previous comment, which was left unanswered afaics: >> >> Uuh, sorry for that. >> >>> "Is it a good idea to suppress the flush this way for every reader >>> of v->arch.cr3? For example, what about the use in >>> dbg_pv_va2mfn()? I think it should be the consumers of the field >>> to decide whether to OR in that flag (which isn't part of the >>> register value anyway)." >>> To be more precise, I can see the pcid to be put here (which will >>> require consumers to be aware anyway), but I don't think the non- >>> register-value no-flush indicator belongs here. IOW I think after >>> writing the value into %cr3, the value read back should match the >>> stored value. >> >> This will make restore_all_guest more compl
Re: [Xen-devel] [PATCH v3 0/7] xen/x86: various XPTI speedups
On Wed, 2018-03-21 at 13:51 +0100, Juergen Gross wrote: > On my machine (Intel i7-4600M) using the PCID feature in the non-XPTI > case showed a slightly worse performance than using global pages > instead (using PCID and global pages is a bad idea as invalidating > global pages in this case would need a complete TLB flush). For this > reason I've decided to use PCID for XPTI only as the default. That > can easily be changed by using the command line parameter "pcid=all". > >XPTI off Jan, XPTI on+this series, XPTI on > real 1m21.169s1m52.149s (+38%)1m25.692s (+6%) > user 2m47.652s2m50.054s (+1%) 2m46.428s (-1%) > sys1m11.949s2m21.767s (+97%)1m23.053s (+15%) > > A git branch of that series (+ Jan's patches) is available: > > https://github.com/jgross1/xen.git xpti > As usual, I've run a few benchmarks. Long story short, this series mitigates the performance hit of XPTI, in pretty much all the cases. In a couple of cases, even significantly so (~10%). The improvement is not as good as in the above numbers, even for similar workloads (compile ones), but I guess that depends on the hardware. But anyway, things do improve, and I think we should have the series in 4.11. I can also confirm that using PCID with XPTI=no, does not bring much of an improvement, if any at all. There's the weird case of STREAM, where using PCID makes things go significantly worse, not only than no-PCID and xpti=no, but also than PCID and xpri=true. Basically, when using PCID, xpti boosts STREAM performance, which is a little weird. I'll try to manually re-run the benchmark in a couple of configurations, and let's see what I will find. Here's the results. Basically: - if you want to compare xpti=on, with and without this series, look at 'Jan, XPTI on' (without) and '+this series, XPTI on' (with); - if you want to compare, with this series, xpti on and off, look at 'XPTI off' (off) and '+this series, XPTI on' (on); - if you want to compare xpti=off, with and without PCID, look at 'XPTI off' (without) and '+this series, XPTI off, PCID all' (with). https://openbenchmarking.org/result/1803232-DARI-180323589 Also available here: AIO-Stress 0.21 Test: Random Write MB/s > Higher Is Better XPTI off .. 1783.11 |=== +this series, XPTI on . 1967.75 |== +this series, XPTI off, PCID all .. 1827.43 |== Jan, XPTI on .. 1866.80 |== Stream 2013-01-17 Type: Copy MB/s > Higher Is Better XPTI off .. 19442.54 |= +this series, XPTI on . 18939.40 |= +this series, XPTI off, PCID all .. 15478.48 | Jan, XPTI on .. 15638.96 |== Stream 2013-01-17 Type: Scale MB/s > Higher Is Better XPTI off .. 12978.74 |= +this series, XPTI on . 12851.56 |=== +this series, XPTI off, PCID all .. 10699.02 |= Jan, XPTI on .. 10778.84 |== Stream 2013-01-17 Type: Triad MB/s > Higher Is Better XPTI off .. 14280.68 |
Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring
> -Original Message- > From: Alexey G [mailto:x19...@gmail.com] > Sent: 22 March 2018 15:09 > To: Jan Beulich > Cc: Andrew Cooper ; Anthony Perard > ; Ian Jackson ; Paul > Durrant ; Roger Pau Monne > ; Wei Liu ; StefanoStabellini > ; xen-devel@lists.xenproject.org > Subject: Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG > area in the MMIO hole + minor code refactoring > > On Thu, 22 Mar 2018 08:42:09 -0600 > "Jan Beulich" wrote: > > On 22.03.18 at 15:34, wrote: > >> On Thu, 22 Mar 2018 07:20:00 -0600 > >> "Jan Beulich" wrote: > >> > >> On 22.03.18 at 14:05, wrote: > On Thu, 22 Mar 2018 06:09:44 -0600 > "Jan Beulich" wrote: > > On 22.03.18 at 12:56, wrote: > >> I really don't understand why some people have that fear of > >> emulated MMCONFIG -- it's really the same thing as any other > MMIO > >> range QEMU already emulates via > map_io_range_to_ioreq_server(). > >> No sensitive information exposed. It is related only to emulated > >> PCI conf space which QEMU already knows about and use, providing > >> emulated PCI devices for it. > > > >You continue to ignore the routing requirement multiple ioreq > >servers impose. > > If the emulated MMCONFIG approach will be modified to become > fully compatible with multiple ioreq servers (whatever they used > for), I assume there will be no objections that emulated MMCONFIG > can't be used? > I just want to clarify this moment -- why people think that > a completely emulated MMIO range, not related in any > way to host's MMCONFIG may compromise something. > >>> > >>>Compromise? All that was said so far - afair - was that this is the > >>>wrong way round design wise. > >> > >> I assume it's all about emulating some real system for HVM, for other > >> goals PV/PVH are available. What is a proper, design-wise way to > >> emulate the MMIO-based MMCONFIG range Q35 provides you think of? > >> > >> Here is what I've heard so far in this thread: > >> > >> 1. Add a completely new dmop/hypercall so that QEMU can tell Xen > >> where emulated MMCONFIG MMIO area is located and in the same time > >> map it for MMIO trapping to intercept accesses. Latter action is the > >> same what map_io_range_to_ioreq_server() does, but let's ignore it > >> for now because there was opinion that we need to stick to a > >> distinct hypercall. > >> > >> 2. Upon trapping accesses to this emulated range, Xen will pretend > >> that QEMU didn't just told him about MMCONFIG location and size and > >> instead convert MMIO access into PCI conf one and send the ioreq to > >> QEMU or some other DM. > >> > >> 3. If there will be a PCIEXBAR relocation (OVMF does it currently for > >> MMCONFIG usage, but we must later teach him non-QEMU manners), > QEMU > >> must immediately inform Xen about any changes in MMCONFIG > >> location/status. > >> > >> 4. QEMU receives PCI conf access while expecting the MMIO address, so > >> xen-hvm.c has to deal with it somehow, either obtaining MMCONFIG > base > >> and recreating emulated MMIO access from BDF/reg or doing the dirty > >> work of finding PCIBus/PCIDevice target itself as it cannot use > >> emulated CF8/CFC ports due to legacy PCI conf size limitation. > >> > >> Please confirm that it is a preferable solution or if something > >> missing. > > > >I'm afraid this is only part of the picture, as you've been told by > >others before. We first of all need to settle on who emulates > >the core chipset registers. Depending on that will be how Xen > >would learn about the MCFG location inside the guest. > > Few related thoughts: > > 1. MMCONFIG address is chipset-specific. On Q35 it's a PCIEXBAR, on > other x86 systems it may be HECBASE or else. So we can assume it is > bound to the emulated machine > Xen emulates the machine so it should be emulating PCIEXBAR. > 2. We rely on QEMU to emulate different machines for us. > We should not be. It's a historical artefact that we rely on QEMU for any part of machine emulation. > 3. There are users which touch chipset-specific PCIEXBAR directly if > they see a Q35 system (OVMF so far) > And we should squash such accesses. The toolstack should be sole control of the guest memory map. It should be the only building MCFG so it should decide where the MMCONFIG regions go, not the firmware running in guest context. > Seems like we're pretty limited in freedom of choice in this > conditions, I'm afraid. I don't think so. We're only limited if we use QEMU's Q35 emulation and what I'm saying is that we should not be doing that (nor should be we be using it to emulate any part of the PIIX today). Paul ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] make: move generated headers to qemu-build/
On Fri, Mar 23, 2018 at 10:22:27AM +, Daniel P. Berrangé wrote: > On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote: > > Make sure all generated files go into qemu-build subdirectory. > > We can then include them like this: > > #include "qemu-build/trace.h" > > > > This serves two purposes: > > - make it easy to detect which files are in the source > > directory (a bit more work for writers, easier for readers) > > - reduce chances of conflicts with possible stale files in source > > directory (which could be left over from e.g. old patches, etc) > > If people care about this, then they can just be doing a build > with srcdir != builddir config. Helps with the second point but I do not see how this will help address the first point. I see include "x.h" in source, it's natural to ask where it is. I look for it in the c file directory. Not there. I look for it in the include, it's not there. Where then? qemu source root on the include path. Not there. Oh tcg directory is in the include path for some reason. Not there. Some other tree coming from a submodule maybe? Oh *maybe* it will be generated by some script, I need to run build to find out. For the record, more remains to be done. Here's a list from and oot build of virtio, with some comments: cc -iquote /home/mst/qemu-oot/hw/virtio -iquote hw/virtio <- same directory repeated twice. <- also this is here just for trace.h . Better to just change code to point at the right trace header - will look into it. -iquote /home/mst/qemu/tcg <- why does everyone want tcg? better to just include with tcg/ -iquote /home/mst/qemu/tcg/i386 <- and i386 specifically? -I/home/mst/qemu/linux-headers <- ok this is so we can override with our own version of headers -I/home/mst/qemu-oot/linux-headers <- why do we have these at all? oh it's because we have asm- tricks like linux used to use years ago, then we copy the correct asm headers: ls linux-headers/asm/ bitsperlong.h hyperv.h kvm.h kvm_para.h unistd_32.h unistd_64.h unistd.h unistd_x32.h a better strategy would be to have headers in arch//asm like Linux does now, no code generation tricks. -iquote . <- build directory. No headers there at all. -iquote /home/mst/qemu <- turns out we still have headers in source root. Why not move them to include/ ? -iquote /home/mst/qemu/accel/tcg <- more tcg goodness for everyone? -iquote /home/mst/qemu/include <- ok that's expected. Why isn't this first on the list though? -I/usr/include/pixman-1 <- should be limited to ui files I guess? -I/usr/include/glib-2.0 <- ok we need that -I/usr/lib64/glib-2.0/include <- but that one does not exist -I/usr/include/p11-kit-1 -I/usr/include/libpng16 -I/usr/include/libdrm <- more GUI things? -I/home/mst/qemu/capstone/include <- ok a bunch of disasm things. ls capstone/include/ arm64.h arm.h capstone.h mips.h platform.h ppc.h sparc.h systemz.h x86.h xcore.h can we add this just to disas.c? -I../linux-headers <- all together now: same as qemu-oot but with a relative path now. -iquote .. <- build directory - no headers there -iquote /home/mst/qemu/target/arm <- this is a good idea why? -iquote /home/mst/qemu/include <- deja vu Wow that was fun. > If people are using srcdir == builddir > then they likely *want* all the generated files in their srcdir. > > IMHO it would be valid for us to consider if we could just mandate > srcdir != builddir, but if people object to such a proposal, then I > don't think we should arbitrarily move all generated source files > in this way, as that's effectively the same thing forced onto devs. > > Regards, > Daniel People don't really care. > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Jan Beulich > Sent: 23 March 2018 11:39 > To: Paul Durrant > Cc: Stefano Stabellini ; Wei Liu > ; Andrew Cooper ; > 'Alexey G' ; xen-devel@lists.xenproject.org; Anthony > Perard ; Ian Jackson ; > Roger Pau Monne > Subject: Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG > area in the MMIO hole + minor code refactoring > > >>> On 23.03.18 at 11:29, wrote: > > No, that's not quite right. Only qemu-trad (and stubdom) are 'default' ioreq > > servers. Upstream QEMU has registered individual PCI devices with Xen for > > some time now, and hence gets proper PCI config IOREQs. Also we really > really > > want default ioreq servers as their interface to Xen is fragile and has only > > just narrowly avoided being a security issue. > > Did you miss some "don't" or "to go away"? > Oops, yes! "to go away" definitely. Paul > Jan > > > ___ > 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
Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature
>>> On 23.03.18 at 12:29, wrote: > On 23/03/18 11:51, Jan Beulich wrote: > On 21.03.18 at 13:51, wrote: >>> Avoid flushing the complete TLB when switching %cr3 for mitigation of >>> Meltdown by using the PCID feature if available. >>> >>> We are using 4 PCID values for a 64 bit pv domain subject to XPTI and >>> 2 values for the non-XPTI case: >>> >>> - guest active and in kernel mode >>> - guest active and in user mode >>> - hypervisor active and guest in user mode (XPTI only) >>> - hypervisor active and guest in kernel mode (XPTI only) >> >> Before committing to this route, Jun, Kevin, can we please get >> confirmation that PCID isn't (and isn't going to be) subject to the >> same speculation issues in the pipeline that the U/S bit is (having >> caused Meltdown in the first place)? To me it seems a pretty >> likely thing to play all the same games. > > Really? This would assume either the processor is capable to deal with > multiple matching TLB entries when speculating or that there can be > only one entry per virtual address present in the TLB at the same time > in spite of different PCIDs. Hmm, yes, good point. > And why aren't you asking for the same problem with VPIDs? This should > be comparable to the PCID problem you are suspecting. Since Linux is using the approach, I'm not really suspecting a problem. I'd just like to be sure there is none / not going to be one. None of this is spelled out in the doc after all. >>> --- >>> docs/misc/xen-command-line.markdown | 12 + >>> xen/arch/x86/debug.c| 3 ++- >>> xen/arch/x86/domain_page.c | 2 +- >>> xen/arch/x86/domctl.c | 4 +++ >>> xen/arch/x86/flushtlb.c | 49 -- >>> xen/arch/x86/mm.c | 34 +--- >>> xen/arch/x86/pv/dom0_build.c| 1 + >>> xen/arch/x86/pv/domain.c| 52 >>> + >>> xen/include/asm-x86/domain.h| 14 +++--- >>> xen/include/asm-x86/pv/domain.h | 2 ++ >>> xen/include/asm-x86/x86-defns.h | 1 + >>> 11 files changed, 158 insertions(+), 16 deletions(-) >> >> Having had the discussion previously, I'm missing a change to >> smp.c:new_tlbflush_clock_period() here. > > I can add that. I did not do this as I haven't treated FLUSH_TLB > differently to FLUSH_TLB_GLOBAL (trying this even without any other > change to staging led to degfaults in dom0). So such a change to > new_tlbflush_clock_period() should be a separate patch I believe. Ah yes, you don't have the "flushing too much" issue anymore in this version, or at least not in as obvious a way. Or wait - it's in patch 4. You still do an including-global flush there regardless of whether FLUSH_TLB_GLOBAL was actually requested. Anyway, we'll save this aspect for later. >>> --- a/xen/arch/x86/debug.c >>> +++ b/xen/arch/x86/debug.c >>> @@ -97,7 +97,8 @@ dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t >>> pgd3val) >>> l3_pgentry_t l3e, *l3t; >>> l2_pgentry_t l2e, *l2t; >>> l1_pgentry_t l1e, *l1t; >>> -unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3); >>> +unsigned long cr3 = (pgd3val ? pgd3val >>> + : (dp->vcpu[0]->arch.cr3 & >>> ~X86_CR3_NOFLUSH)); >> >> What about the PCID portion? You want the address of the page >> here, so I think you should use a "white-listing" masking operation >> instead of a blacklisting one. > > The PCID portion is no problem here as the value is converted into a > mfn. > > I can do the modification you are asking for, of course. Well, even if the bits are shifter out in the end, the code could look more correct. Plus by masking to just the address, future new meaning assigned to currently unused bits would not be a problem for this piece of code anymore. >>> +/* >>> + * Return additional PCID specific cr3 bits. >>> + * >>> + * Note that X86_CR3_NOFLUSH will not be readable in cr3. Anyone consuming >>> + * v->arch.cr3 should mask away X86_CR3_NOFLUSH and X86_CR3_PCIDMASK in >>> case >> >> I stand to my previous comment, which was left unanswered afaics: > > Uuh, sorry for that. > >> "Is it a good idea to suppress the flush this way for every reader >> of v->arch.cr3? For example, what about the use in >> dbg_pv_va2mfn()? I think it should be the consumers of the field >> to decide whether to OR in that flag (which isn't part of the >> register value anyway)." >> To be more precise, I can see the pcid to be put here (which will >> require consumers to be aware anyway), but I don't think the non- >> register-value no-flush indicator belongs here. IOW I think after >> writing the value into %cr3, the value read back should match the >> stored value. > > This will make restore_all_guest more complicated. v->arch.cr3 is copied > to cpu_info->xen_cr3 there and this value is then used for %cr3. I > really don't want to add complex logic there to add the no-flush
Re: [Xen-devel] possible I/O emulation state machine issue
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Jan Beulich > Sent: 23 March 2018 11:36 > To: Paul Durrant > Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org> > Subject: Re: [Xen-devel] possible I/O emulation state machine issue > > >>> On 23.03.18 at 11:43, wrote: > >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On > Behalf > >> Of Jan Beulich > >> Sent: 23 March 2018 07:30 > >> > >> >>> On 22.03.18 at 16:29, wrote: > >> > On 22/03/18 15:12, Jan Beulich wrote: > >> >> Paul, > >> >> > >> >> our PV driver person has found a reproducible crash with ws2k8, > >> >> triggered by one of the WHQL tests. The guest get crashed because > >> >> the re-issue check of an ioreq close to the top of hvmemul_do_io() > >> >> fails. I've handed him a first debugging patch, output of which > >> >> suggests that we're dealing with a completely new request, which > >> >> in turn would mean that we've run into stale STATE_IORESP_READY > >> >> state: > >> >> > >> >> (XEN) d2v3: t=0/1 a=3c4/fed000f0 s=2/4 c=1/1 d=0/1 f=0/0 p=0/0 > >> > v=100/831873f27a30 > >> >> (XEN) [ Xen-4.10.0_15-0 x86_64 debug=n Tainted: C ] > >> > > >> > Irrespective of the issue at hand, can testing be tried with a debug > >> > build to see if any of the assertions are hit? > >> > >> Nothing, unfortunately. But at least the stack trace can be relied > >> upon this way. > > > > I'm assuming the debug line above is indicating the former emulation > > before the '/' and the latter after? In which case it looks like an MMIO to > > the HPET (I think that's what's at 0xfed000f0) clashing with a port IO to > > the > > graphics device. So, why is the HPET emulation making it to QEMU? Are you > > trying to run Windows with Xen's HPET emulation turned on? > > Actually I think I'm confused by your reply. Why are you talking about > qemu? Said check sits above hvm_io_intercept(), so the code in question > runs for both internally handled and forwarded requests. The question > for me rather is why we see a HPET access when the prior VGA one > apparently wasn't fully finished yet. Ah that's true. We will do the check based on the response state even if the next IO is going to be dealt with internally. So, yes, the real question is why the previous I/O was completed without apparently waiting for QEMU to finish. We should have sent the VGA PIO out to QEMU, resulting in hvm_vcpu_io_need_completion() returning true in handle_pio() meaning that vio->io_completion gets set to HVMIO_pio_completion. We should then return true from handle_pio() resulting in RIP being advanced when we return to guest, but we should not get back into the guest because hvm_do_resume() should see the pending IO flag on one of the ioreq server vcpus and block on the relevant event channel. So somehow it appears the vcpu got back into guest and executed the next instruction whilst there was pending I/O. > > The exact port number of the earlier access isn't stable (above you see > 3c4, but the other (debug) output had 3ce. These are the two ports > stdvga.c intercepts without actually handling the accesses. The > consistent part is that it's a VGA port write followed by a HPET read. > > Yet in no event can I make any connection (yet) to our internal state > getting screwed during a driver reload in a guest. > No, I can't see any connection there at all. Paul > Jan > > > ___ > 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
Re: [Xen-devel] [PATCH v5] hvm/svm: Implement Debug events
On Vi, 2018-03-23 at 09:35 -0400, Boris Ostrovsky wrote:
> On 03/23/2018 05:10 AM, Jan Beulich wrote:
> >
> > >
> > > >
> > > > >
> > > > > On 23.03.18 at 09:31, wrote:
> > > @@ -2656,9 +2663,28 @@ void svm_vmexit_handler(struct
> > > cpu_user_regs *regs)
> > > HVMTRACE_0D(SMI);
> > > break;
> > >
> > > +case VMEXIT_ICEBP:
> > > case VMEXIT_EXCEPTION_DB:
> > > if ( !v->domain->debugger_attached )
> > > -hvm_inject_hw_exception(TRAP_debug,
> > > X86_EVENT_NO_EC);
> > > +{
> > > +int rc;
> > > +unsigned int trap_type = exit_reason == VMEXIT_ICEBP
> > > ?
> > > +X86_EVENTTYPE_PRI_SW_EXCEPTION :
> > > X86_EVENTTYPE_HW_EXCEPTION;
> > > +
> > > +inst_len = 0;
> > > +
> > > +if ( trap_type == X86_EVENTTYPE_PRI_SW_EXCEPTION )
> > > +inst_len = __get_instruction_length(v,
> > > INSTR_ICEBP);
> > It'll be the SVM maintainers to judge, but I think the code
> > structure
> > I've previously suggested would make things more clear:
> >
> > if ( exit_reason != VMEXIT_ICEBP )
> > {
> > trap_type == X86_EVENTTYPE_HW_EXCEPTION;
> > inst_len = 0;
> > }
> > else
> > {
> > trap_type == X86_EVENTTYPE_PRI_SW_EXCEPTION;
> > inst_len = __get_instruction_length(v,
> > INSTR_ICEBP);
> > }
> >
> > Perhaps even with likely() added.
> Yes, I also think this is easier to read.
>
> -boris
>
>
Ok, I will change it in the next version
~Alex
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 v5] hvm/svm: Implement Debug events
On 03/23/2018 05:10 AM, Jan Beulich wrote:
On 23.03.18 at 09:31, wrote:
>> @@ -2656,9 +2663,28 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>> HVMTRACE_0D(SMI);
>> break;
>>
>> +case VMEXIT_ICEBP:
>> case VMEXIT_EXCEPTION_DB:
>> if ( !v->domain->debugger_attached )
>> -hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
>> +{
>> +int rc;
>> +unsigned int trap_type = exit_reason == VMEXIT_ICEBP ?
>> +X86_EVENTTYPE_PRI_SW_EXCEPTION : X86_EVENTTYPE_HW_EXCEPTION;
>> +
>> +inst_len = 0;
>> +
>> +if ( trap_type == X86_EVENTTYPE_PRI_SW_EXCEPTION )
>> +inst_len = __get_instruction_length(v, INSTR_ICEBP);
> It'll be the SVM maintainers to judge, but I think the code structure
> I've previously suggested would make things more clear:
>
> if ( exit_reason != VMEXIT_ICEBP )
> {
> trap_type == X86_EVENTTYPE_HW_EXCEPTION;
> inst_len = 0;
> }
> else
> {
> trap_type == X86_EVENTTYPE_PRI_SW_EXCEPTION;
> inst_len = __get_instruction_length(v, INSTR_ICEBP);
> }
>
> Perhaps even with likely() added.
Yes, I also think this is easier to read.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai. Shanghai cpu defines two msr registers to enable Random Number Generator and Advanced Cryprography Engine.The cpu supports
On Fri, Mar 23, 2018 at 07:28:56PM +0800, Fionali wrote:
> From: FionaLi
>
> Signed-off-by: Fiona Li
> ---
> xen/arch/x86/cpu/Makefile | 1 +
> xen/arch/x86/cpu/common.c | 1 +
> xen/arch/x86/cpu/shanghai.c | 61
> +++
> xen/include/asm-x86/iommu.h | 2 ++
> xen/include/asm-x86/msr-index.h | 4 +++
> xen/include/asm-x86/setup.h | 1 +
> xen/include/asm-x86/x86-vendors.h | 3 +-
> 7 files changed, 72 insertions(+), 1 deletion(-)
> create mode 100644 xen/arch/x86/cpu/shanghai.c
>
> diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
> index 74f23ae..8fcffdd 100644
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Makefile
> @@ -5,6 +5,7 @@ obj-y += amd.o
> obj-y += centaur.o
> obj-y += common.o
> obj-y += intel.o
> +obj-y += shanghai.o
> obj-y += intel_cacheinfo.o
> obj-y += mwait-idle.o
> obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 0a452ae..02863c9 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -709,6 +709,7 @@ void __init early_cpu_init(void)
> intel_cpu_init();
> amd_init_cpu();
> centaur_init_cpu();
> + shanghai_init_cpu();
> early_cpu_detect();
> }
>
> diff --git a/xen/arch/x86/cpu/shanghai.c b/xen/arch/x86/cpu/shanghai.c
> new file mode 100644
> index 000..7910f03
> --- /dev/null
> +++ b/xen/arch/x86/cpu/shanghai.c
> @@ -0,0 +1,61 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Use the following order please:
#include
#include
#include
#include
#include
#include
> +#include "cpu.h"
> +
> +#define ACE_PRESENT(x) ((x)&(1U<<6))
Please add spaces around "&" and "<<".
> +#define ACE_ENABLED(x) ((x)&(1U<<7))
> +#define ACE_FCR (1U << 28) /* MSR_ZX_ACE Advanced
> Cryprography Engine */
> +
> +#define RNG_PRESENT(x) ((x)&(1U<<6))
> +#define RNG_ENABLED(x) ((x)&(1U<<7))
> +#define RNG_ENABLE (1U << 6) /* MSR_ZX_RNG Random Number Generator */
> +
> +
> +
> +static void init_shanghai(struct cpuinfo_x86 *c)
> +{
> + uint64_t msr_ace,msr_rng;
Add a blank line here.
> + /* Test for Shanghai Extended CPUID information */
> + if (cpuid_eax(0xC000) >= 0xC001) {
Coding style. Should be
if ( )
{
Please fix all instances.
> + /*Get Shanghai Extended function number */
> + u32 extented_feature_flags = cpuid_edx(0xC001);
> +
> + /* enable ACE,if support ACE unit */
> + if(ACE_PRESENT(extented_feature_flags) &&
> !ACE_ENABLED(extented_feature_flags)) {
> + rdmsrl(MSR_ZX_ACE, msr_ace);
> + /* enable ACE */
> + wrmsrl(MSR_ZX_ACE, (msr_ace | ACE_FCR));
> + printk(KERN_INFO "CPU: Enabled ACE h/w crypto\n");
Drop KERN_INFO please.
> + }
Blank line here please.
> + /* enable RNG,if support RNG unit */
> + if (RNG_PRESENT(extented_feature_flags) &&
> !RNG_ENABLED(extented_feature_flags)) {
> + rdmsrl(MSR_ZX_RNG, msr_rng);
> + /* enable RNG */
> + wrmsrl(MSR_ZX_RNG, msr_rng | RNG_ENABLE);
> + printk(KERN_INFO "CPU: Enabled h/w RNG\n");
> + }
> + }
> +
> + if (c->x86 == 0x6 && c->x86_model >= 0xf) {
> + c->x86_cache_alignment = c->x86_clflush_size * 2;
> + __set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> + }
Blank line.
> + get_model_name(c);
> + display_cacheinfo(c);
> +}
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/7] x86/xpti: don't flush TLB twice when switching to 64-bit pv context
On 22/03/18 15:50, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> When switching to a 64-bit pv context the TLB is flushed twice today:
>> the first time when switching to the new address space in
>> write_ptbase(), the second time when switching to guest mode in
>> restore_to_guest.
>>
>> Avoid the first TLB flush in that case.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> V3:
>> - omit setting root_pgt_changed to false (Jan Beulich)
>> ---
>> xen/arch/x86/mm.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index 352600ad73..8c944b33c9 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -123,6 +123,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -507,8 +508,14 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>> void write_ptbase(struct vcpu *v)
>> {
>> if ( this_cpu(root_pgt) && is_pv_vcpu(v) && !is_pv_32bit_vcpu(v) )
>> +{
>> get_cpu_info()->root_pgt_changed = true;
>> -write_cr3(v->arch.cr3);
>> +asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
>> +}
>> +else
>> +{
>> +write_cr3(v->arch.cr3);
>> +}
>
> Unnecessary braces. with that
> Reviewed-by: Jan Beulich
> (This could be taken care of while committing, but the patch
> depends on patch 1 anyway, which may see further
> transformation.)
Just realized it now: I have to re-introduce the conditionals I removed
on your behalf from patch 1, as otherwise I'd omit TLB flushing via
write_cr3() for 32-bit pv-domains and HVM-domains.
Therefor I'm removing your R-b in case you don't like that (patch 3
changes the conditional again, so I don't think that is really bad).
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 121084: tolerable all pass - PUSHED
flight 121084 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121084/ 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 738301591ccb663e7d87f431cdda3d5c9d31ab97 baseline version: xen e633b13a18f7a7e407cba2de42a5a2a86aaec9c1 Last test of basis 121068 2018-03-22 19:05:15 Z0 days Testing same since 121084 2018-03-23 10:01:47 Z0 days1 attempts People who touched revisions under test: Julien Grall Roger Pau Monne Roger Pau Monné Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git e633b13a18..738301591c 738301591ccb663e7d87f431cdda3d5c9d31ab97 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai. Shanghai cpu defines two msr registers to enable Random Number Generator and Advanced Cryprography Engine.The cpu supports
On Fri, Mar 23, 2018 at 07:28:56PM +0800, Fionali wrote: > From: FionaLi > > Signed-off-by: Fiona Li > --- > xen/arch/x86/cpu/Makefile | 1 + > xen/arch/x86/cpu/common.c | 1 + > xen/arch/x86/cpu/shanghai.c | 61 > +++ > xen/include/asm-x86/iommu.h | 2 ++ > xen/include/asm-x86/msr-index.h | 4 +++ > xen/include/asm-x86/setup.h | 1 + > xen/include/asm-x86/x86-vendors.h | 3 +- > 7 files changed, 72 insertions(+), 1 deletion(-) > create mode 100644 xen/arch/x86/cpu/shanghai.c > > diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile > index 74f23ae..8fcffdd 100644 > --- a/xen/arch/x86/cpu/Makefile > +++ b/xen/arch/x86/cpu/Makefile > @@ -5,6 +5,7 @@ obj-y += amd.o > obj-y += centaur.o > obj-y += common.o > obj-y += intel.o > +obj-y += shanghai.o I'm confused. Shouldn't you use zhaoxin instead? Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans
On Thu, Mar 22, 2018 at 06:24:37PM +, George Dunlap wrote: > +### Disks > + > +The chroot (and seccomp?) happens late enough such that QEMU can > +initialize itself and open its disks. If you want to add a disk at run > +time via or insert a CD, you can't pass a path because QEMU is > +chrooted. Instead use the add-fd QMP command and use > +/dev/fdset/ as the path. > + > +A further layer of restriction could be to set RLIMIT_NOFILES to '0', > +and hand all disks over QMP. The "add-fd" can work also on the command line. But I guess using only QMP will be better from libxl point of view, only one code path to add disks. Also, with dm_restrict=1, another todo: qdisk backend doesn't work. We probably needs to start a second QEMU process for pv backends. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai. Shanghai cpu defines two msr registers to enable Random Number Generator and Advanced Cryprography Engine.The cpu supports iom
From: FionaLi
Signed-off-by: Fiona Li
---
xen/arch/x86/cpu/Makefile | 1 +
xen/arch/x86/cpu/common.c | 1 +
xen/arch/x86/cpu/shanghai.c | 61 +++
xen/include/asm-x86/iommu.h | 2 ++
xen/include/asm-x86/msr-index.h | 4 +++
xen/include/asm-x86/setup.h | 1 +
xen/include/asm-x86/x86-vendors.h | 3 +-
7 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/x86/cpu/shanghai.c
diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index 74f23ae..8fcffdd 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -5,6 +5,7 @@ obj-y += amd.o
obj-y += centaur.o
obj-y += common.o
obj-y += intel.o
+obj-y += shanghai.o
obj-y += intel_cacheinfo.o
obj-y += mwait-idle.o
obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 0a452ae..02863c9 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -709,6 +709,7 @@ void __init early_cpu_init(void)
intel_cpu_init();
amd_init_cpu();
centaur_init_cpu();
+ shanghai_init_cpu();
early_cpu_detect();
}
diff --git a/xen/arch/x86/cpu/shanghai.c b/xen/arch/x86/cpu/shanghai.c
new file mode 100644
index 000..7910f03
--- /dev/null
+++ b/xen/arch/x86/cpu/shanghai.c
@@ -0,0 +1,61 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cpu.h"
+
+#define ACE_PRESENT(x) ((x)&(1U<<6))
+#define ACE_ENABLED(x) ((x)&(1U<<7))
+#define ACE_FCR(1U << 28) /* MSR_ZX_ACE Advanced
Cryprography Engine */
+
+#define RNG_PRESENT(x) ((x)&(1U<<6))
+#define RNG_ENABLED(x) ((x)&(1U<<7))
+#define RNG_ENABLE (1U << 6) /* MSR_ZX_RNG Random Number Generator */
+
+
+
+static void init_shanghai(struct cpuinfo_x86 *c)
+{
+ uint64_t msr_ace,msr_rng;
+ /* Test for Shanghai Extended CPUID information */
+ if (cpuid_eax(0xC000) >= 0xC001) {
+ /*Get Shanghai Extended function number */
+ u32 extented_feature_flags = cpuid_edx(0xC001);
+
+ /* enable ACE,if support ACE unit */
+ if(ACE_PRESENT(extented_feature_flags) &&
!ACE_ENABLED(extented_feature_flags)) {
+ rdmsrl(MSR_ZX_ACE, msr_ace);
+ /* enable ACE */
+ wrmsrl(MSR_ZX_ACE, (msr_ace | ACE_FCR));
+ printk(KERN_INFO "CPU: Enabled ACE h/w crypto\n");
+ }
+ /* enable RNG,if support RNG unit */
+ if (RNG_PRESENT(extented_feature_flags) &&
!RNG_ENABLED(extented_feature_flags)) {
+ rdmsrl(MSR_ZX_RNG, msr_rng);
+ /* enable RNG */
+ wrmsrl(MSR_ZX_RNG, msr_rng | RNG_ENABLE);
+ printk(KERN_INFO "CPU: Enabled h/w RNG\n");
+ }
+ }
+
+ if (c->x86 == 0x6 && c->x86_model >= 0xf) {
+ c->x86_cache_alignment = c->x86_clflush_size * 2;
+ __set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
+ }
+ get_model_name(c);
+ display_cacheinfo(c);
+}
+
+static const struct cpu_dev shanghai_cpu_dev = {
+ .c_vendor = "Shanghai",
+ .c_ident= { " Shanghai " },
+ .c_init = init_shanghai,
+};
+
+int __init shanghai_init_cpu(void)
+{
+ cpu_devs[X86_VENDOR_SHANGHAI] = &shanghai_cpu_dev;
+ return 0;
+}
diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 14ad048..c125da6 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -53,6 +53,7 @@ static inline const struct iommu_ops *iommu_get_ops(void)
{
switch ( boot_cpu_data.x86_vendor )
{
+case X86_VENDOR_SHANGHAI:
case X86_VENDOR_INTEL:
return &intel_iommu_ops;
case X86_VENDOR_AMD:
@@ -68,6 +69,7 @@ static inline int iommu_hardware_setup(void)
{
switch ( boot_cpu_data.x86_vendor )
{
+case X86_VENDOR_SHANGHAI:
case X86_VENDOR_INTEL:
return intel_vtd_setup();
case X86_VENDOR_AMD:
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index 23ad743..f2ce71a 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -293,6 +293,10 @@
#define MSR_TMTA_LRTI_READOUT 0x80868018
#define MSR_TMTA_LRTI_VOLT_MHZ 0x8086801a
+/* Shanghai ZhaoXin defined MSRs*/
+#define MSR_ZX_ACE 0x1107
+#define MSR_ZX_RNG 0x110b
+
/* Intel defined MSRs. */
#define MSR_IA32_P5_MC_ADDR0x
#define MSR_IA32_P5_MC_TYPE0x0001
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index 19232af..827daf8 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -22,6 +22,7 @@ int amd_init_cpu(void);
int cyrix_init_cpu(void);
int nsc_init_cpu(void);
i
[Xen-devel] [PATCH v2] SUPPORT.md: add PVH Dom0 status
Also fix x86/HVM to spell out that only DomU HVM mode is supported and remove the 'guest' from the ARM section, ARM supports both Dom0/DomU using the same mode. Signed-off-by: Roger Pau Monné --- 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 --- Changes since v1: - Don't add a Dom0 specific section. --- SUPPORT.md | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index ddcdfab5ad..c72a25b6e2 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -74,23 +74,26 @@ No hardware requirements ### x86/HVM -Status: Supported +Status, domU: Supported Fully virtualised guest using hardware virtualisation extensions Requires hardware virtualisation support (Intel VMX / AMD SVM) -### x86/PVH guest +### x86/PVH -Status: Supported +Status, domU: Supported +Status, dom0: Experimental PVH is a next-generation paravirtualized mode designed to take advantage of hardware virtualization support when possible. During development this was sometimes called HVMLite or PVHv2. -Requires hardware virtualisation support (Intel VMX / AMD SVM) +Requires hardware virtualisation support (Intel VMX / AMD SVM). + +Dom0 support requires an IOMMU (Intel VT-d / AMD IOMMU). -### ARM guest +### ARM Status: Supported -- 2.16.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring
>>> On 23.03.18 at 11:29, wrote: > No, that's not quite right. Only qemu-trad (and stubdom) are 'default' ioreq > servers. Upstream QEMU has registered individual PCI devices with Xen for > some time now, and hence gets proper PCI config IOREQs. Also we really really > want default ioreq servers as their interface to Xen is fragile and has only > just narrowly avoided being a security issue. Did you miss some "don't" or "to go away"? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] possible I/O emulation state machine issue
>>> On 23.03.18 at 11:43, wrote: >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf >> Of Jan Beulich >> Sent: 23 March 2018 07:30 >> >> >>> On 22.03.18 at 16:29, wrote: >> > On 22/03/18 15:12, Jan Beulich wrote: >> >> Paul, >> >> >> >> our PV driver person has found a reproducible crash with ws2k8, >> >> triggered by one of the WHQL tests. The guest get crashed because >> >> the re-issue check of an ioreq close to the top of hvmemul_do_io() >> >> fails. I've handed him a first debugging patch, output of which >> >> suggests that we're dealing with a completely new request, which >> >> in turn would mean that we've run into stale STATE_IORESP_READY >> >> state: >> >> >> >> (XEN) d2v3: t=0/1 a=3c4/fed000f0 s=2/4 c=1/1 d=0/1 f=0/0 p=0/0 >> > v=100/831873f27a30 >> >> (XEN) [ Xen-4.10.0_15-0 x86_64 debug=n Tainted: C ] >> > >> > Irrespective of the issue at hand, can testing be tried with a debug >> > build to see if any of the assertions are hit? >> >> Nothing, unfortunately. But at least the stack trace can be relied >> upon this way. > > I'm assuming the debug line above is indicating the former emulation > before the '/' and the latter after? In which case it looks like an MMIO to > the HPET (I think that's what's at 0xfed000f0) clashing with a port IO to the > graphics device. So, why is the HPET emulation making it to QEMU? Are you > trying to run Windows with Xen's HPET emulation turned on? Actually I think I'm confused by your reply. Why are you talking about qemu? Said check sits above hvm_io_intercept(), so the code in question runs for both internally handled and forwarded requests. The question for me rather is why we see a HPET access when the prior VGA one apparently wasn't fully finished yet. The exact port number of the earlier access isn't stable (above you see 3c4, but the other (debug) output had 3ce. These are the two ports stdvga.c intercepts without actually handling the accesses. The consistent part is that it's a VGA port write followed by a HPET read. Yet in no event can I make any connection (yet) to our internal state getting screwed during a driver reload in a guest. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans
On 03/23/2018 10:53 AM, George Dunlap wrote: On 03/23/2018 09:41 AM, Ross Lagerwall wrote: On 03/22/2018 06:24 PM, George Dunlap wrote: snip -for ((i=1; i<65536; i++)) +# Introduction + +# Setup + +## Getting the right versions of software + +Linux 4.XX (For dom0 kernel...) Requires 4.11 for the ability to restrict dmop calls. Thanks, I'll update this section. + +Xen 4.XX Requires 4.11 to get required dmop calls to make VGA work. On reflection, there's probably not much point in including this: The document will contain the state of functionality of the version of Xen that contains it. Agreed. +## Domain config changes + +The core domain config change is to add the following line to the +domain configuration: + + dm_restrict=1 + +This will perform a number of restrictions, outlined below in the +'Technical details' section. + +Remove non-functioning default features: + + vga="none" I'm not sure what this means? Well it's under "domain config changes"; if you add this to your xl domain config, then QEMU will not provide any emulated VGA devices. But it sounds like this issue has been fixed in 4.11 anyway, so perhaps we can remove this section? Yes, it can be removed. +Other features expected not to work include: +* Inserting a new cdrom while the guest is running (xl cdrom-insert) +* migration / save / restore The above two features could be made to work if the toolstack drives QEMU correctly. Yes; I'm trying to use this document for several purposes: * "HOWTO" -- useful for people who want to experiment with the feature. For this I want to include what works and what doesn't work * Design doc -- a place to discuss / record what to do and how to do it (a lot of these are independent, so the work could be shared or at least passed around between people). * Todo list -- a place to identify work that still needs to be done. But I could try to make it clearer that these are "todo" items, and that "PCI" is further down the importance list than the others. +### Xen restrictions + +'''Description''': Close and restrict Xen-related file descriptors. +Specifically, make sure that only one `privcmd` instance is open, and +that the IOCTL_EVTCHN_RESTRICT_DOMID ioctl has been called. Just to clarify, we call IOCTL_PRIVCMD_RESTRICT on the `privcmd` fds and IOCTL_EVTCHN_RESTRICT_DOMID on the evtchn fds which remain open. There is no requirement to have only one instance of each. + +XXX Also, make sure that only one `xenstore` fd remains open, and that +it's restricted. The current implementation closes _all_ xenstore fds and doesn't need to make use of xenstore after going into restricted mode. Ack (and with spelling mistakes) +### Network namespacing + +Enter QEMU into its own network namespace (in addition to mount & IPC +namespaces). Basically change the 'unshare' call to be as follows: + + unshare(CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWIPC) It might be clearer if this was merged with the other Namespacing section or at least put immediately afterwards. Part of my goal here was to list things in a "low-hanging-fruit" order. Since QEMU doesn't use mount or IPC namespaces, that can be done immediately. Using a new network namespace requires changing how network devices are set up, and possibly making code changes to QEMU so that it can still listen on network sockets; hence putting this lower down the list (followed by the two things that would need to be fixed if it were implemented). OK, fair enough. -- 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] xen/x86: use PCID feature
On 23/03/18 11:51, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> Avoid flushing the complete TLB when switching %cr3 for mitigation of
>> Meltdown by using the PCID feature if available.
>>
>> We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
>> 2 values for the non-XPTI case:
>>
>> - guest active and in kernel mode
>> - guest active and in user mode
>> - hypervisor active and guest in user mode (XPTI only)
>> - hypervisor active and guest in kernel mode (XPTI only)
>
> Before committing to this route, Jun, Kevin, can we please get
> confirmation that PCID isn't (and isn't going to be) subject to the
> same speculation issues in the pipeline that the U/S bit is (having
> caused Meltdown in the first place)? To me it seems a pretty
> likely thing to play all the same games.
Really? This would assume either the processor is capable to deal with
multiple matching TLB entries when speculating or that there can be
only one entry per virtual address present in the TLB at the same time
in spite of different PCIDs.
And why aren't you asking for the same problem with VPIDs? This should
be comparable to the PCID problem you are suspecting.
>
>> ---
>> docs/misc/xen-command-line.markdown | 12 +
>> xen/arch/x86/debug.c| 3 ++-
>> xen/arch/x86/domain_page.c | 2 +-
>> xen/arch/x86/domctl.c | 4 +++
>> xen/arch/x86/flushtlb.c | 49 --
>> xen/arch/x86/mm.c | 34 +---
>> xen/arch/x86/pv/dom0_build.c| 1 +
>> xen/arch/x86/pv/domain.c| 52
>> +
>> xen/include/asm-x86/domain.h| 14 +++---
>> xen/include/asm-x86/pv/domain.h | 2 ++
>> xen/include/asm-x86/x86-defns.h | 1 +
>> 11 files changed, 158 insertions(+), 16 deletions(-)
>
> Having had the discussion previously, I'm missing a change to
> smp.c:new_tlbflush_clock_period() here.
I can add that. I did not do this as I haven't treated FLUSH_TLB
differently to FLUSH_TLB_GLOBAL (trying this even without any other
change to staging led to degfaults in dom0). So such a change to
new_tlbflush_clock_period() should be a separate patch I believe.
>
>> --- a/xen/arch/x86/debug.c
>> +++ b/xen/arch/x86/debug.c
>> @@ -97,7 +97,8 @@ dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t
>> pgd3val)
>> l3_pgentry_t l3e, *l3t;
>> l2_pgentry_t l2e, *l2t;
>> l1_pgentry_t l1e, *l1t;
>> -unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3);
>> +unsigned long cr3 = (pgd3val ? pgd3val
>> + : (dp->vcpu[0]->arch.cr3 &
>> ~X86_CR3_NOFLUSH));
>
> What about the PCID portion? You want the address of the page
> here, so I think you should use a "white-listing" masking operation
> instead of a blacklisting one.
The PCID portion is no problem here as the value is converted into a
mfn.
I can do the modification you are asking for, of course.
>
> Also, as you touch this anyway, it would have been nice to drop
> the unnecessary middle argument at the same time.
Okay.
>
>> --- a/xen/arch/x86/flushtlb.c
>> +++ b/xen/arch/x86/flushtlb.c
>> @@ -102,7 +102,19 @@ void write_cr3_cr4(unsigned long cr3, unsigned long cr4)
>> t = pre_flush();
>>
>> if ( read_cr4() & X86_CR4_PGE )
>> +/*
>> + * X86_CR4_PGE set means PCID being inactive.
>> + * We have to purge the TLB via flipping cr4.pge.
>> + */
>> write_cr4(cr4 & ~X86_CR4_PGE);
>> +else if ( cpu_has_invpcid )
>> +/*
>> + * If we are using PCID purge the TLB via INVPCID as loading cr3
>> + * will affect the current PCID only.
>> + * If INVPCID is not supported we don't use PCIDs so loading cr3
>> + * will purge the TLB (we are in the "global pages off" branch).
>> + */
>> +invpcid_flush_all();
>
> Since with CR4.PGE correctness-wise clear it doesn't matter whether
> you use invpcid_flush_all() or invpcid_flush_all_nonglobals() here,
> does it also not matter performance-wise?
I didn't check that. I'll have a try.
>
>> @@ -131,14 +143,35 @@ unsigned int flush_area_local(const void *va, unsigned
>> int flags)
>> {
>> if ( order == 0 )
>> {
>> -/*
>> - * We don't INVLPG multi-page regions because the 2M/4M/1G
>> - * region may not have been mapped with a superpage. Also there
>> - * are various errata surrounding INVLPG usage on superpages,
>> and
>> - * a full flush is in any case not *that* expensive.
>> - */
>
> This comment really explains the order == 0 check above, so I
> don't think it should be moved.
Okay.
>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -497,12 +497,38 @@ void free_shared_domheap_page(struct page_info *page)
>> free_domheap_page(page);
>> }
>>
>> +/*
>> + * Return additional PCI
Re: [Xen-devel] [PATCH v2 1/2] make: move generated headers to qemu-build/
Am 23.03.2018 um 11:22 hat Daniel P. Berrangé geschrieben: > On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote: > > Make sure all generated files go into qemu-build subdirectory. > > We can then include them like this: > > #include "qemu-build/trace.h" > > > > This serves two purposes: > > - make it easy to detect which files are in the source > > directory (a bit more work for writers, easier for readers) > > - reduce chances of conflicts with possible stale files in source > > directory (which could be left over from e.g. old patches, etc) > > If people care about this, then they can just be doing a build > with srcdir != builddir config. If people are using srcdir == builddir > then they likely *want* all the generated files in their srcdir. > > IMHO it would be valid for us to consider if we could just mandate > srcdir != builddir, but if people object to such a proposal, then I > don't think we should arbitrarily move all generated source files > in this way, as that's effectively the same thing forced onto devs. Not necessarily. I build from the srcdir simply because it's more convenient to be able to easily start the editor and make from the same directory (or sometimes start make from inside the editor). I suppose that (or for users, being too lazy to create a second directory for that one-time build) is the motivation for most other users of srcdir == builddir, too. I don't really mind where generated source files are stored, they just happen to end up in my root source directory if I want to be able to build from there without dealing with paths. I won't be angry if they are suddenly in a different directory as long as it doesn't mean more typing for me. Moving them to a separate directory might in fact make things a bit nicer occasionally. Not enough for me to actively propose such a change, but if Michael wants to do this, I'm certainly not opposed. Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] possible I/O emulation state machine issue
>>> On 23.03.18 at 11:43, wrote: >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf >> Of Jan Beulich >> Sent: 23 March 2018 07:30 >> >> >>> On 22.03.18 at 16:29, wrote: >> > On 22/03/18 15:12, Jan Beulich wrote: >> >> our PV driver person has found a reproducible crash with ws2k8, >> >> triggered by one of the WHQL tests. The guest get crashed because >> >> the re-issue check of an ioreq close to the top of hvmemul_do_io() >> >> fails. I've handed him a first debugging patch, output of which >> >> suggests that we're dealing with a completely new request, which >> >> in turn would mean that we've run into stale STATE_IORESP_READY >> >> state: >> >> >> >> (XEN) d2v3: t=0/1 a=3c4/fed000f0 s=2/4 c=1/1 d=0/1 f=0/0 p=0/0 >> > v=100/831873f27a30 >> >> (XEN) [ Xen-4.10.0_15-0 x86_64 debug=n Tainted: C ] >> > >> > Irrespective of the issue at hand, can testing be tried with a debug >> > build to see if any of the assertions are hit? >> >> Nothing, unfortunately. But at least the stack trace can be relied >> upon this way. > > I'm assuming the debug line above is indicating the former emulation > before the '/' and the latter after? Yes (to clarify this is why I had included the patch as well). > In which case it looks like an MMIO to > the HPET (I think that's what's at 0xfed000f0) clashing with a port IO to the > graphics device. That's what I had concluded too. > So, why is the HPET emulation making it to QEMU? Are you > trying to run Windows with Xen's HPET emulation turned on? DYM "off"? In any event I don't think he's having any special settings in place, but I'll double check. Yet if there really was "hpet=0" in the guest config file, things should still work, shouldn't they? I'd rather take this as a hint that hpet_range() suddenly isn't reached anymore, perhaps because of some other address range getting inserted which supersedes the HPET one. In that context it may become relevant to mention that this happens when, in the course of the test, the LAN driver gets unloaded and then reloaded (i.e. it's the reload which triggers the issue). He's calling the test "AddressChange test", and now I start wondering whether this isn't a change of the NIC address, but a change of addresses within the MMIO window. I've asked for clarification of that as well. Supposedly all was fine with 4.9, but I'll also ask to make sure it really is. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] SUPPORT.md: add Domain 0 section
On 03/23/2018 11:14 AM, Roger Pau Monné wrote: > On Fri, Mar 23, 2018 at 11:06:54AM +, George Dunlap wrote: >> On 03/23/2018 10:27 AM, Roger Pau Monne wrote: >>> Signed-off-by: Roger Pau Monné >>> --- >>> 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 >>> --- >>> SUPPORT.md | 24 >>> 1 file changed, 24 insertions(+) >>> >>> diff --git a/SUPPORT.md b/SUPPORT.md >>> index ddcdfab5ad..fb0151aa7b 100644 >>> --- a/SUPPORT.md >>> +++ b/SUPPORT.md >>> @@ -96,6 +96,30 @@ Requires hardware virtualisation support (Intel VMX / >>> AMD SVM) >>> >>> ARM only has one guest type at the moment >>> >>> +## Domain 0 Type >>> + >>> +### x86/PV Dom0 >>> + >>> +Status: Supported >>> + >>> +Traditional Xen PV Domain 0 >>> + >>> +No hardware requirements >>> + >>> +### x86/PVH Dom0 >>> + >>> +Status: Experimental >>> + >>> +PVH based Domain 0 >>> + >>> +Requires CPU hardware virtualization extensions and an IOMMU. >>> + >>> +### ARM Dom0 >>> + >>> +Status: Supported >>> + >>> +ARM only has one Domain 0 type at the moment >>> + >> >> There's a lot of redundancy here. What about keeping the guest types >> together, like the following? >> >> --- >> ### x86/PVH >> >> Status, domU: Supported >> Status, dom0: Experimental >> >> [description] >> >> Note also that dom0 support requires IOMMU or VT-d hardware. > > Sure. I wasn't aware that we could use 'Status, XXX:'. Somehow I > thought this won't be processed correctly, but there are bunch of > entries using this format already. Well at the moment there isn't any processing. If it turns out to be too difficult to process as it is, then we'll have to figure something else out; but as you say, there are already dozens of other entries that will need to be changed as well. > Let me send v2. Thanks, -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] SUPPORT.md: add Domain 0 section
On Fri, Mar 23, 2018 at 11:06:54AM +, George Dunlap wrote: > On 03/23/2018 10:27 AM, Roger Pau Monne wrote: > > Signed-off-by: Roger Pau Monné > > --- > > 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 > > --- > > SUPPORT.md | 24 > > 1 file changed, 24 insertions(+) > > > > diff --git a/SUPPORT.md b/SUPPORT.md > > index ddcdfab5ad..fb0151aa7b 100644 > > --- a/SUPPORT.md > > +++ b/SUPPORT.md > > @@ -96,6 +96,30 @@ Requires hardware virtualisation support (Intel VMX / > > AMD SVM) > > > > ARM only has one guest type at the moment > > > > +## Domain 0 Type > > + > > +### x86/PV Dom0 > > + > > +Status: Supported > > + > > +Traditional Xen PV Domain 0 > > + > > +No hardware requirements > > + > > +### x86/PVH Dom0 > > + > > +Status: Experimental > > + > > +PVH based Domain 0 > > + > > +Requires CPU hardware virtualization extensions and an IOMMU. > > + > > +### ARM Dom0 > > + > > +Status: Supported > > + > > +ARM only has one Domain 0 type at the moment > > + > > There's a lot of redundancy here. What about keeping the guest types > together, like the following? > > --- > ### x86/PVH > > Status, domU: Supported > Status, dom0: Experimental > > [description] > > Note also that dom0 support requires IOMMU or VT-d hardware. Sure. I wasn't aware that we could use 'Status, XXX:'. Somehow I thought this won't be processed correctly, but there are bunch of entries using this format already. Let me send v2. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] SUPPORT.md: add Domain 0 section
On 03/23/2018 10:27 AM, Roger Pau Monne wrote: > Signed-off-by: Roger Pau Monné > --- > 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 > --- > SUPPORT.md | 24 > 1 file changed, 24 insertions(+) > > diff --git a/SUPPORT.md b/SUPPORT.md > index ddcdfab5ad..fb0151aa7b 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -96,6 +96,30 @@ Requires hardware virtualisation support (Intel VMX / AMD > SVM) > > ARM only has one guest type at the moment > > +## Domain 0 Type > + > +### x86/PV Dom0 > + > +Status: Supported > + > +Traditional Xen PV Domain 0 > + > +No hardware requirements > + > +### x86/PVH Dom0 > + > +Status: Experimental > + > +PVH based Domain 0 > + > +Requires CPU hardware virtualization extensions and an IOMMU. > + > +### ARM Dom0 > + > +Status: Supported > + > +ARM only has one Domain 0 type at the moment > + There's a lot of redundancy here. What about keeping the guest types together, like the following? --- ### x86/PVH Status, domU: Supported Status, dom0: Experimental [description] Note also that dom0 support requires IOMMU or VT-d hardware. --- -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11] x86/libxc: fix usage of XEN_X86_EMU_ALL after VPCI addition
HVM guest should be created with (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI). This is not an issue for xl/libxl because it already sets the correct emulation flags and doesn't pass a NULL xc_domain_configuration_t to xc_domain_create. Signed-off-by: Roger Pau Monné --- Cc: Ian Jackson Cc: Wei Liu --- tools/libxc/xc_domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c index ea3df1ef31..26b4b908b9 100644 --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -40,7 +40,7 @@ int xc_domain_create(xc_interface *xch, uint32_t ssidref, #if defined (__i386) || defined(__x86_64__) if ( flags & XEN_DOMCTL_CDF_hvm_guest ) -lconfig.emulation_flags = XEN_X86_EMU_ALL; +lconfig.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI); #elif defined (__arm__) || defined(__aarch64__) lconfig.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; lconfig.nr_spis = 0; -- 2.16.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans
On 03/23/2018 09:41 AM, Ross Lagerwall wrote: > On 03/22/2018 06:24 PM, George Dunlap wrote: > snip >> -for ((i=1; i<65536; i++)) >> +# Introduction >> + >> +# Setup >> + >> +## Getting the right versions of software >> + >> +Linux 4.XX > > (For dom0 kernel...) > > Requires 4.11 for the ability to restrict dmop calls. Thanks, I'll update this section. >> + >> +Xen 4.XX > > Requires 4.11 to get required dmop calls to make VGA work. On reflection, there's probably not much point in including this: The document will contain the state of functionality of the version of Xen that contains it. >> +## Domain config changes >> + >> +The core domain config change is to add the following line to the >> +domain configuration: >> + >> + dm_restrict=1 >> + >> +This will perform a number of restrictions, outlined below in the >> +'Technical details' section. >> + >> +Remove non-functioning default features: >> + >> + vga="none" > > I'm not sure what this means? Well it's under "domain config changes"; if you add this to your xl domain config, then QEMU will not provide any emulated VGA devices. But it sounds like this issue has been fixed in 4.11 anyway, so perhaps we can remove this section? >> +Other features expected not to work include: >> +* Inserting a new cdrom while the guest is running (xl cdrom-insert) >> +* migration / save / restore > > The above two features could be made to work if the toolstack drives > QEMU correctly. Yes; I'm trying to use this document for several purposes: * "HOWTO" -- useful for people who want to experiment with the feature. For this I want to include what works and what doesn't work * Design doc -- a place to discuss / record what to do and how to do it (a lot of these are independent, so the work could be shared or at least passed around between people). * Todo list -- a place to identify work that still needs to be done. But I could try to make it clearer that these are "todo" items, and that "PCI" is further down the importance list than the others. >> +### Xen restrictions >> + >> +'''Description''': Close and restrict Xen-related file descriptors. >> +Specifically, make sure that only one `privcmd` instance is open, and >> +that the IOCTL_EVTCHN_RESTRICT_DOMID ioctl has been called. > > Just to clarify, we call IOCTL_PRIVCMD_RESTRICT on the `privcmd` fds and > IOCTL_EVTCHN_RESTRICT_DOMID on the evtchn fds which remain open. There > is no requirement to have only one instance of each. > >> + >> +XXX Also, make sure that only one `xenstore` fd remains open, and that >> +it's restricted. > > The current implementation closes _all_ xenstore fds and doesn't need to > make use of xenstore after going into restricted mode. Ack (and with spelling mistakes) >> +### Network namespacing >> + >> +Enter QEMU into its own network namespace (in addition to mount & IPC >> +namespaces). Basically change the 'unshare' call to be as follows: >> + >> + unshare(CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWIPC) > > It might be clearer if this was merged with the other Namespacing > section or at least put immediately afterwards. Part of my goal here was to list things in a "low-hanging-fruit" order. Since QEMU doesn't use mount or IPC namespaces, that can be done immediately. Using a new network namespace requires changing how network devices are set up, and possibly making code changes to QEMU so that it can still listen on network sockets; hence putting this lower down the list (followed by the two things that would need to be fixed if it were implemented). >> +### Network >> +If QEMU runs in its own network namespace, it can't open the tap >> +device itself because the interface won't be visible outside of its >> +own namespace. So instead, have the toolstack open the device and pass >> +it as an fd on the command-line: >> -2) a user named "xen-qemuuser-shared" >> -As a fall back if both 1) fails, libxl will use a single user for >> -all QEMU instances. The user is named xen-qemuuser-shared. This is >> -less secure but still better than running QEMU as root. Using this is as >> -simple as creating just one more user on your host: >> + -device rtl8139,netdev=tapnet0,mac=... -netdev >> tap,id=tapnet0,fd= >> -adduser --no-create-home --system xen-qemuuser-shared >> +### VNC >> +If QEMU runs in its own network namespace, it is not straightforward >> +to listen on a TCP socket outside of its own network namespace. One >> +option would be to use VNC over a UNIX socket: >> -3) root >> -As a last resort, libxl will start QEMU as root. >> + -vnc unix:/var/run/xen/vnc- >> +However, this would break functionality in the general case; I think >> +we need to have the toolstack open a socket and pass the fd to QEMU >> +(which requires changes to QEMU). >> -Please note that running QEMU as non-root causes several features like >> -migration and PCI passthrough to not work properly and may prevent >> the guest >> -from booting. >> > > Although there are still
Re: [Xen-devel] [PATCH v3 7/7] xen/x86: use PCID feature
>>> On 21.03.18 at 13:51, wrote:
> Avoid flushing the complete TLB when switching %cr3 for mitigation of
> Meltdown by using the PCID feature if available.
>
> We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
> 2 values for the non-XPTI case:
>
> - guest active and in kernel mode
> - guest active and in user mode
> - hypervisor active and guest in user mode (XPTI only)
> - hypervisor active and guest in kernel mode (XPTI only)
Before committing to this route, Jun, Kevin, can we please get
confirmation that PCID isn't (and isn't going to be) subject to the
same speculation issues in the pipeline that the U/S bit is (having
caused Meltdown in the first place)? To me it seems a pretty
likely thing to play all the same games.
> ---
> docs/misc/xen-command-line.markdown | 12 +
> xen/arch/x86/debug.c| 3 ++-
> xen/arch/x86/domain_page.c | 2 +-
> xen/arch/x86/domctl.c | 4 +++
> xen/arch/x86/flushtlb.c | 49 --
> xen/arch/x86/mm.c | 34 +---
> xen/arch/x86/pv/dom0_build.c| 1 +
> xen/arch/x86/pv/domain.c| 52
> +
> xen/include/asm-x86/domain.h| 14 +++---
> xen/include/asm-x86/pv/domain.h | 2 ++
> xen/include/asm-x86/x86-defns.h | 1 +
> 11 files changed, 158 insertions(+), 16 deletions(-)
Having had the discussion previously, I'm missing a change to
smp.c:new_tlbflush_clock_period() here.
> --- a/xen/arch/x86/debug.c
> +++ b/xen/arch/x86/debug.c
> @@ -97,7 +97,8 @@ dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t
> pgd3val)
> l3_pgentry_t l3e, *l3t;
> l2_pgentry_t l2e, *l2t;
> l1_pgentry_t l1e, *l1t;
> -unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3);
> +unsigned long cr3 = (pgd3val ? pgd3val
> + : (dp->vcpu[0]->arch.cr3 &
> ~X86_CR3_NOFLUSH));
What about the PCID portion? You want the address of the page
here, so I think you should use a "white-listing" masking operation
instead of a blacklisting one.
Also, as you touch this anyway, it would have been nice to drop
the unnecessary middle argument at the same time.
> --- a/xen/arch/x86/flushtlb.c
> +++ b/xen/arch/x86/flushtlb.c
> @@ -102,7 +102,19 @@ void write_cr3_cr4(unsigned long cr3, unsigned long cr4)
> t = pre_flush();
>
> if ( read_cr4() & X86_CR4_PGE )
> +/*
> + * X86_CR4_PGE set means PCID being inactive.
> + * We have to purge the TLB via flipping cr4.pge.
> + */
> write_cr4(cr4 & ~X86_CR4_PGE);
> +else if ( cpu_has_invpcid )
> +/*
> + * If we are using PCID purge the TLB via INVPCID as loading cr3
> + * will affect the current PCID only.
> + * If INVPCID is not supported we don't use PCIDs so loading cr3
> + * will purge the TLB (we are in the "global pages off" branch).
> + */
> +invpcid_flush_all();
Since with CR4.PGE correctness-wise clear it doesn't matter whether
you use invpcid_flush_all() or invpcid_flush_all_nonglobals() here,
does it also not matter performance-wise?
> @@ -131,14 +143,35 @@ unsigned int flush_area_local(const void *va, unsigned
> int flags)
> {
> if ( order == 0 )
> {
> -/*
> - * We don't INVLPG multi-page regions because the 2M/4M/1G
> - * region may not have been mapped with a superpage. Also there
> - * are various errata surrounding INVLPG usage on superpages, and
> - * a full flush is in any case not *that* expensive.
> - */
This comment really explains the order == 0 check above, so I
don't think it should be moved.
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -497,12 +497,38 @@ void free_shared_domheap_page(struct page_info *page)
> free_domheap_page(page);
> }
>
> +/*
> + * Return additional PCID specific cr3 bits.
> + *
> + * Note that X86_CR3_NOFLUSH will not be readable in cr3. Anyone consuming
> + * v->arch.cr3 should mask away X86_CR3_NOFLUSH and X86_CR3_PCIDMASK in case
I stand to my previous comment, which was left unanswered afaics:
"Is it a good idea to suppress the flush this way for every reader
of v->arch.cr3? For example, what about the use in
dbg_pv_va2mfn()? I think it should be the consumers of the field
to decide whether to OR in that flag (which isn't part of the
register value anyway)."
To be more precise, I can see the pcid to be put here (which will
require consumers to be aware anyway), but I don't think the non-
register-value no-flush indicator belongs here. IOW I think after
writing the value into %cr3, the value read back should match the
stored value.
> + * the value is used to address the root page table.
> + */
> +static unsigned long get_pcid_bits(struct vcpu *v, bool is_xen)
> +{
> +return X86_CR3_NOFLUSH | (is_xen ? PCID_PV_XEN
Re: [Xen-devel] [PATCH v4 0/8] x86: Meltdown band-aid overhead reduction
On 19/03/18 14:32, Jan Beulich wrote: > 1: NOP out most XPTI entry/exit code when it's not in use > 2: disable XPTI when RDCL_NO > 3: x86: log XPTI enabled status > 4: use %r12 to write zero into xen_cr3 > 5: reduce .text.entry > 6: enable interrupts earlier with XPTI disabled > 7: also NOP out xen_cr3 restores of XPTI > 8: avoid double CR3 reload when switching to guest user mode > > Signed-off-by: Jan Beulich > --- > v4: Main change is the split of patch 1. Andrew, any chance you could review patches 1 and 5-8 in order to unblock this series and mine? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] possible I/O emulation state machine issue
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Jan Beulich > Sent: 23 March 2018 07:30 > To: Andrew Cooper > Cc: xen-devel ; Paul Durrant > > Subject: Re: [Xen-devel] possible I/O emulation state machine issue > > >>> On 22.03.18 at 16:29, wrote: > > On 22/03/18 15:12, Jan Beulich wrote: > >> Paul, > >> > >> our PV driver person has found a reproducible crash with ws2k8, > >> triggered by one of the WHQL tests. The guest get crashed because > >> the re-issue check of an ioreq close to the top of hvmemul_do_io() > >> fails. I've handed him a first debugging patch, output of which > >> suggests that we're dealing with a completely new request, which > >> in turn would mean that we've run into stale STATE_IORESP_READY > >> state: > >> > >> (XEN) d2v3: t=0/1 a=3c4/fed000f0 s=2/4 c=1/1 d=0/1 f=0/0 p=0/0 > > v=100/831873f27a30 > >> (XEN) [ Xen-4.10.0_15-0 x86_64 debug=n Tainted: C ] > > > > Irrespective of the issue at hand, can testing be tried with a debug > > build to see if any of the assertions are hit? > > Nothing, unfortunately. But at least the stack trace can be relied > upon this way. > Jan, I'm assuming the debug line above is indicating the former emulation before the '/' and the latter after? In which case it looks like an MMIO to the HPET (I think that's what's at 0xfed000f0) clashing with a port IO to the graphics device. So, why is the HPET emulation making it to QEMU? Are you trying to run Windows with Xen's HPET emulation turned on? Paul > Jan > > (XEN) d2v3: t=0/1 a=3ce/fed000f0 s=2/4 c=1/1 d=0/1 f=0/0 p=0/0 > v=406/83387d21fa30 > (XEN) [ Xen-4.10.0_15-0 x86_64 debug=y Tainted: C ] > (XEN) CPU:62 > (XEN) RIP:e008:[] > emulate.c#hvmemul_do_io+0x169/0x445 > (XEN) RFLAGS: 00010292 CONTEXT: hypervisor (d2v3) > (XEN) rax: 8308796f602c rbx: 830007d26000 rcx: > (XEN) rdx: 83387d21 rsi: 000a rdi: 82d0804823b8 > (XEN) rbp: 83387d21f788 rsp: 83387d21f6a8 r8: 830879d0 > (XEN) r9: 0030 r10: 000f r11: ffee > (XEN) r12: 0004 r13: r14: 83387d21f850 > (XEN) r15: 0001 cr0: 80050033 cr4: 26e0 > (XEN) cr3: 0037d2026000 cr2: f880051d17ac > (XEN) fsb: gsb: gss: 07f98000 > (XEN) ds: es: fs: gs: ss: cs: e008 > (XEN) Xen code around > (emulate.c#hvmemul_do_io+0x169/0x445): > (XEN) 00 00 00 e8 f5 e2 f6 ff <0f> 0b 48 83 c4 60 ba ab 00 00 00 48 8d 35 89 > cd > (XEN) Xen stack trace from rsp=83387d21f6a8: > (XEN)0002 0004 0001 > 0001 > (XEN) 0001 > > (XEN) 0406 > 83387d21fa30 > (XEN)83387d21f798 fed000f0 831187beb000 > 00017d21f914 > (XEN) 014c 03ce > 0406 > (XEN)00020001 014c > 0004 > (XEN)0001 83387d21fa30 fed000f0 > 830007d269c8 > (XEN)83387d21f7c8 82d0802e5c06 > 83387d21fa30 > (XEN)0004 0004 > fed000f0 > (XEN)83387d21f898 82d0802e6264 83387d21fa30 > 0003 > (XEN)83387d21f860 83387d21f858 0004 ffd070f0 > (XEN)0003 83387d21fc58 00040001 > 83387d21f850 > (XEN) 83387d21fa30 01ff83380004 > 83387d21fa30 > (XEN)1b41 0001 0001 > fed000f0 > (XEN)8318ad778380 0004 83387d21fc58 > 0001 > (XEN)0002 830007d26000 83387d21f918 > 82d0802e725f > (XEN)0001 82d0803e6da0 > 83387d21fa30 > (XEN)0001 ffd070f0 00861efd > 0004 > (XEN)008b 83387d21f9c0 83387d21fc58 > 82d0803e6da0 > (XEN)83387d21fef8 008b 83387d21f928 > 82d0802e73c3 > (XEN) Xen call trace: > (XEN)[] emulate.c#hvmemul_do_io+0x169/0x445 > (XEN)[] emulate.c#hvmemul_do_io_buffer+0x2e/0x68 > (XEN)[] > emulate.c#hvmemul_linear_mmio_access+0x2b9/0x3fc > (XEN)[] emulate.c#__hvmemul_read+0x163/0x1fa > (XEN)[] emulate.c#hvmemul_read+0x1c/0x2a > (XEN)[] x86_emulate.c#read_ulong+0x13/0x15 > (XEN)[] x86_emulate+0x47d/0x1efa3 > (XEN)[] x86_emulate_wrapper+0x26/0x5f > (XEN)[] emulate.c#_hvm_emulate_one+0x54/0x173 > (XEN)[] hvm_emulate_one+0x10/0x12 > (XEN)[] hvm_emulate_one_insn+0x42/0x130 > (XEN)[] handle_mmio_with_translation+0x4f/0x51 > (XE
Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Alexey G
> Sent: 22 March 2018 15:31
> To: Roger Pau Monne
> Cc: Stefano Stabellini ; Wei Liu
> ; Andrew Cooper ; Ian
> Jackson ; Paul Durrant ;
> Jan Beulich ; Anthony Perard
> ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG
> area in the MMIO hole + minor code refactoring
>
> On Thu, 22 Mar 2018 12:44:02 +
> Roger Pau Monné wrote:
>
> >On Thu, Mar 22, 2018 at 10:29:22PM +1000, Alexey G wrote:
> >> On Thu, 22 Mar 2018 09:57:16 +
> >> Roger Pau Monné wrote:
> >> [...]
> >> >> Yes, and it is still needed as we have two distinct (and not
> >> >> equal) interfaces to PCI conf space. Apart from 0..FFh range
> >> >> overlapping they can be considered very different interfaces. And
> >> >> whether it is a real system or emulated -- we can use either one
> >> >> of these two interfaces or both.
> >> >
> >> >The legacy PCI config space accesses and the MCFG config space
> >> >access are just different methods of accessing the PCI
> >> >configuration space, but the data _must_ be exactly the same. I
> >> >don't see how a device would care about where the access to the
> >> >config space originated.
> >>
> >> If they were different methods of accessing the same thing, they
> >> could've been used interchangeably. When we've got a PCI conf ioreq
> >> which has offset>100h we know we cannot just pass it to emulated
> >> CF8/CFC but have to emulate this specifically.
> >
> >This is already not the best approach to dispatch PCI config space
> >access in QEMU. I think the interface in QEMU should be:
> >
> >pci_conf_space_{read/write}(sbdf, register, size , data)
> >
> >And this would go directly into the device. But I assume this involves
> >a non-trivial amount of work to be implemented. Hence xen-hvm.c usage
> >of the IO port access replay.
>
> Yes, it's a helpful shortcut. The only bad thing that we can't use
> it for PCI extended config accesses, a memory address within emulated
> MMCONFIG much more preferable in current architecture.
>
> >> >OK, so you don't want to reconstruct the access, fine.
> >> >
> >> >Then just inject it using pcie_mmcfg_data_{read/write} or some
> >> >similar wrapper. My suggestion was just to try to use the easier
> >> >way to get this injected into QEMU.
> >>
> >> QEMU knows its position, the problem it that xen-hvm.c (ioreq
> >> processor) is rather isolated from MMCONFIG emulation.
> >>
> >> If you check the pcie_mmcfg_data_read/write MMCONFIG handlers in
> >> QEMU, you can see this:
> >>
> >> static uint64_t pcie_mmcfg_data_read(void *opaque, <...>
> >> {
> >> PCIExpressHost *e = opaque;
> >> ...
> >>
> >> We know this 'opaque' when we do MMIO-style MMCONFIG handling as
> >> pcie_mmcfg_data_read/write are actual handlers.
> >>
> >> But xen-hvm.c needs to gain access to PCIExpressHost out of nowhere,
> >> which is possible but considered a hack by QEMU. We can also insert
> >> some code to MMCONFIG emulation which will store info we need to
> some
> >> global variables to be used across wildly different and unrelated
> >> modules. It will work, but anyone who see it will have bad thoughts
> >> on his mind.
> >
> >Since you need to notify Xen the MCFG area address, why not just store
> >the MCFG address while doing this operation? You could do this with a
> >helper in xen-hvm.c, and keep the variable locally to that file.
> >
> >In any case, this is a QEMU implementation detail. IMO the IOREQ
> >interface is clear and should not be bended like this just because
> >'this is easier to implement in QEMU'.
>
> A bit of hack too, but might work. Anyway, it's an extra work we can
> avoid if we simply skip PCI conf translation for MMCONFIG MMIO ioreqs
> targeting QEMU. I completely agree that we need to translate these
> accesses into PCI conf ioreqs for device DMs, but for QEMU it is an
> unwanted and redundant step.
>
> AFAIK (Paul might correct me here) the multiple device emulators
> feature already makes use of the primary (aka default) DM and
> device-specific DM distinction, so in theory it should be possible to
> provide that translation only for device-specific DMs (which function
> apart from the emulated machine and cannot use its facilities).
>
No, that's not quite right. Only qemu-trad (and stubdom) are 'default' ioreq
servers. Upstream QEMU has registered individual PCI devices with Xen for some
time now, and hence gets proper PCI config IOREQs. Also we really really want
default ioreq servers as their interface to Xen is fragile and has only just
narrowly avoided being a security issue.
Paul
> ___
> 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/
[Xen-devel] [PATCH] SUPPORT.md: add Domain 0 section
Signed-off-by: Roger Pau Monné --- 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 --- SUPPORT.md | 24 1 file changed, 24 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index ddcdfab5ad..fb0151aa7b 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -96,6 +96,30 @@ Requires hardware virtualisation support (Intel VMX / AMD SVM) ARM only has one guest type at the moment +## Domain 0 Type + +### x86/PV Dom0 + +Status: Supported + +Traditional Xen PV Domain 0 + +No hardware requirements + +### x86/PVH Dom0 + +Status: Experimental + +PVH based Domain 0 + +Requires CPU hardware virtualization extensions and an IOMMU. + +### ARM Dom0 + +Status: Supported + +ARM only has one Domain 0 type at the moment + ## Toolstack ### xl -- 2.16.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] make: move generated headers to qemu-build/
On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote: > Make sure all generated files go into qemu-build subdirectory. > We can then include them like this: > #include "qemu-build/trace.h" > > This serves two purposes: > - make it easy to detect which files are in the source > directory (a bit more work for writers, easier for readers) > - reduce chances of conflicts with possible stale files in source > directory (which could be left over from e.g. old patches, etc) If people care about this, then they can just be doing a build with srcdir != builddir config. If people are using srcdir == builddir then they likely *want* all the generated files in their srcdir. IMHO it would be valid for us to consider if we could just mandate srcdir != builddir, but if people object to such a proposal, then I don't think we should arbitrarily move all generated source files in this way, as that's effectively the same thing forced onto devs. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans
On Fri, Mar 23, 2018 at 09:41:47AM +, Ross Lagerwall wrote: > On 03/22/2018 06:24 PM, George Dunlap wrote: > > +* PCI passthrough > > This one requires a fair amount of Xen & QEMU changes to have a chance of > working. I'm not sure this will ever be feasible with the current approach where QEMU is the one doing the passthrough mediation. You need QEMU to be able to write to the PCI config space, at which point the depriv thing becomes moot. Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items
> -Original Message- > From: Roger Pau Monné [mailto:roy...@gmail.com] On Behalf Of Roger Pau > Monné > Sent: 23 March 2018 09:44 > To: Stefano Stabellini > Cc: Lars Kurth ; Juergen Gross ; Ji, > John ; xen-de...@lists.xensource.com; Wei Liu > ; Tamas K Lengyel ; Andrew > Cooper ; Daniel Kiper > ; Christopher Clark > ; Rich Persaud ; > Janakarajan Natarajan ; Julien Grall > ; Paul Durrant ; > committ...@xenproject.org; Jan Beulich' ; Brian > Woods > Subject: Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC > - Call for Agenda Items > > On Thu, Mar 22, 2018 at 03:51:11PM -0700, Stefano Stabellini wrote: > > On Thu, 22 Mar 2018, Lars Kurth wrote: > > > On 22/03/2018, 14:49, "Julien Grall" wrote: > > > > > > >> - > > > >> > > > >> I think we need to discuss PCI emulation and our future direction. > Our current hybrid with QEMU is becoming increasingly problematic. > > > > > > > > +1 > > > > > > I think it would be worth for Stefano and I to join this discussion. > > > Ideally, we want to use a common solution between Arm and x86. > > > > > > Not sure the time will fit for Stefano thought. > > > > > > It's at 7am Pacific, which is a little early for Stefano. I can't really > > > move the > call: it was quite hard to agree a time-slot. > > > But we could aim to schedule this discussion for say 7:30 or 7:45, which > makes this easier for Stefano > > > > Yes, indeed it is very early for Stefano :-) > > > > But I can do 7:30-7:45 for once. > > > > In general, for things that interest both x86 and Arm, and PCI > > passthrough is a great example, I think it would be best to organize > > topic specific calls (that I would love push to 8AM or later ;-) > > This is probably going to be a big topic, so I agree that a separate > call with a dedicated agenda might be better. > Yes, and it may be prudent to reserve some time for a design session at summit, if relevant folks will be there. Paul > Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 6/7] xen/x86: use flag byte for decision whether xen_cr3 is valid
>>> On 21.03.18 at 13:51, wrote: > Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to > be switched on entry to Xen, or negative for keeping the value while > indicating not to restore %cr3, or positive in case %cr3 is to be > restored. > > Switch to use a flag byte instead of a negative xen_cr3 value in order > to allow %cr3 values with the high bit set in case we want to keep TLB > entries when using the PCID feature. > > This reduces the number of branches in interrupt handling and results > in better performance (e.g. parallel make of the Xen hypervisor on my > system was using about 3% less system time). > > Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items
On Thu, Mar 22, 2018 at 03:51:11PM -0700, Stefano Stabellini wrote: > On Thu, 22 Mar 2018, Lars Kurth wrote: > > On 22/03/2018, 14:49, "Julien Grall" wrote: > > > > >> - > > >> > > >> I think we need to discuss PCI emulation and our future direction. > > Our current hybrid with QEMU is becoming increasingly problematic. > > > > > > +1 > > > > I think it would be worth for Stefano and I to join this discussion. > > Ideally, we want to use a common solution between Arm and x86. > > > > Not sure the time will fit for Stefano thought. > > > > It's at 7am Pacific, which is a little early for Stefano. I can't really > > move the call: it was quite hard to agree a time-slot. > > But we could aim to schedule this discussion for say 7:30 or 7:45, which > > makes this easier for Stefano > > Yes, indeed it is very early for Stefano :-) > > But I can do 7:30-7:45 for once. > > In general, for things that interest both x86 and Arm, and PCI > passthrough is a great example, I think it would be best to organize > topic specific calls (that I would love push to 8AM or later ;-) This is probably going to be a big topic, so I agree that a separate call with a dedicated agenda might be better. Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans
On 03/22/2018 06:24 PM, George Dunlap wrote: snip -for ((i=1; i<65536; i++)) +# Introduction + +# Setup + +## Getting the right versions of software + +Linux 4.XX (For dom0 kernel...) Requires 4.11 for the ability to restrict dmop calls. + +Xen 4.XX Requires 4.11 to get required dmop calls to make VGA work. + +Qemu: Requires patches not yet in any release + +## Setting up a userid range + +For maximum security, libxl needs to run the devicemodel for each +domain under a user id (UID) corresponding to its domain id. There +are 32752 possible domain IDs, and so libxl needs 32752 user ids set +aside for it. + +The simplest and most effective way to do this is to allocate a +contiguous block of UIDs, and create a single user named +`xen-qemuuser-range-base` with the first UID. For example, under Debian: + +adduser --no-create-home --uid 65536 --system xen-qemuuser-range-base + +An alternate way is to create 32752 distinct users with the name +`xen-qemuuser-domid$domid`, doing something like the following: + +for ((i=1; i<=32751; i++)) do -adduser --no-create-home --system xen-qemuuser-domid$i +adduser --no-create-home --system --uid $(($i-1+65536)) xen-qemuuser-domid$i done -You might want to consider passing --group to adduser to create a new -group for each new user. +FIXME: Test the above script to see if it works + +NOTE: Most modern systems have 32-bit UIDs, and so can in theory go up +to 2^31 (or 2^32 if uids are unsigned). POSIX only guarantees 16-bit +UIDs however. UID 65535 is reserved for an invalid value, and 65534 +is normally allocated to "nobody". + +Another, less-secure way is to run all QEMUs as the same UID. To do +this, create a user named `xen-qemuuser-shared`; for example: + +adduser --no-create-home --system xen-qemuuser-shared + +## Domain config changes + +The core domain config change is to add the following line to the +domain configuration: + +dm_restrict=1 + +This will perform a number of restrictions, outlined below in the +'Technical details' section. + +Remove non-functioning default features: + +vga="none" I'm not sure what this means? + +Other features expected not to work include: +* Inserting a new cdrom while the guest is running (xl cdrom-insert) +* migration / save / restore The above two features could be made to work if the toolstack drives QEMU correctly. +* PCI passthrough This one requires a fair amount of Xen & QEMU changes to have a chance of working. + +# Technical details + +## Restrictions done + +### Having qemu switch user + +'''Description''': As mentioned above, having qemu switch to a non-root user, one per +domain id. + +'''Implementation''': The toolstack adds the following to the qemu command-line: + +-runas : + +'''Testing Status''': Not tested + +### Xen restrictions + +'''Description''': Close and restrict Xen-related file descriptors. +Specifically, make sure that only one `privcmd` instance is open, and +that the IOCTL_EVTCHN_RESTRICT_DOMID ioctl has been called. Just to clarify, we call IOCTL_PRIVCMD_RESTRICT on the `privcmd` fds and IOCTL_EVTCHN_RESTRICT_DOMID on the evtchn fds which remain open. There is no requirement to have only one instance of each. + +XXX Also, make sure that only one `xenstore` fd remains open, and that +it's restricted. The current implementation closes _all_ xenstore fds and doesn't need to make use of xenstore after going into restricted mode. + +'''Implementation''': Toolstack adds the following to the qemu command-line: + +-xen-domid-restrict + +'''Testing status''': Not tested XXX + +## Restrictions still to do + +### Chroot + +'''Description''': Qemu runs in its own chroot, such that even if it +could call an 'open' command of some sort, there would be nothing for +it to see. + +'''Implementation''': The toolstack creates a directory such as: +`/var/run/qemu/root-` + +Then add the following to the qemu command-line: + +-chroot /var/run/qemu/root- + +### Namespaces for unused functionality + +'''Descripiton''': Enter QEMU into its own mount & IPC namespaces. Spelling: Descripiton +This means that even if other restrictions fail, the process won't be +able to even name system mount points or exsting non-file-based IPC +descriptors to attempt to attack them. + +'''Implementation''': + +In theory this could be done in QEMU (similar to -sandbox, -runas, +-chroot, and so on), but a patch doing this in QEMU was NAKed +upstream. They preferred that this was done as a setup step by +whatever executes QEMU; i.e., have the process which exec's QEMU first +call: + +unshare(CLONE_NEWNS | CLONE_NEWIPC) + +### seccomp filtering + +'''Description''': Turn on seccomp filtering to disable syscalls which +QEMU doesn't need: + +'''Implementation''': Enable from the command-line: + +-sandbox on,obsolete=deny,elevateprivileges=allow,spawn=deny,resourcecontrol=deny + +`elevateprivileges` is currently required to allow `-runas` to work. +Remov
[Xen-devel] [xen-4.8-testing test] 121044: regressions - FAIL
flight 121044 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/121044/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 120116 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120116 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120116 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120116 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120116 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 120116 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 120116 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 120116 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120116 test-xtf-amd64-amd64-1 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-memop-seg fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass build-amd64-prev 7 xen-build/dist-test fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 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 build-i386-prev 7 xen-build/dist-test fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 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-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386
Re: [Xen-devel] [PATCH v5] hvm/svm: Implement Debug events
>>> On 23.03.18 at 09:31, wrote:
> @@ -2656,9 +2663,28 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
> HVMTRACE_0D(SMI);
> break;
>
> +case VMEXIT_ICEBP:
> case VMEXIT_EXCEPTION_DB:
> if ( !v->domain->debugger_attached )
> -hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
> +{
> +int rc;
> +unsigned int trap_type = exit_reason == VMEXIT_ICEBP ?
> +X86_EVENTTYPE_PRI_SW_EXCEPTION : X86_EVENTTYPE_HW_EXCEPTION;
> +
> +inst_len = 0;
> +
> +if ( trap_type == X86_EVENTTYPE_PRI_SW_EXCEPTION )
> +inst_len = __get_instruction_length(v, INSTR_ICEBP);
It'll be the SVM maintainers to judge, but I think the code structure
I've previously suggested would make things more clear:
if ( exit_reason != VMEXIT_ICEBP )
{
trap_type == X86_EVENTTYPE_HW_EXCEPTION;
inst_len = 0;
}
else
{
trap_type == X86_EVENTTYPE_PRI_SW_EXCEPTION;
inst_len = __get_instruction_length(v, INSTR_ICEBP);
}
Perhaps even with likely() added.
> @@ -407,6 +408,20 @@ void hvm_migrate_pirqs(struct vcpu *v);
>
> void hvm_inject_event(const struct x86_event *event);
>
> +static inline void hvm_inject_exception(
> +unsigned int vector, unsigned int type,
> +unsigned int insn_len, int error_code)
> +{
> +struct x86_event event = {
> +.vector = vector,
> +.type = type,
> +.insn_len = insn_len,
> +.error_code = error_code,
> +};
> +
> +hvm_inject_event(&event);
> +}
> +
> static inline void hvm_inject_hw_exception(unsigned int vector, int errcode)
One more note here: I wonder whether hvm_inject_hw_exception()
shouldn't become a wrapper now around the new function you
introduce. But of course this could also be done as cleanup later.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active
>>> On 23.03.18 at 09:29, wrote:
> On 23/03/18 09:14, Jan Beulich wrote:
> On 23.03.18 at 08:58, wrote:
>>> On 23/03/18 08:46, Jan Beulich wrote:
>>> On 22.03.18 at 19:18, wrote:
> On 22/03/18 17:30, Jan Beulich wrote:
> On 21.03.18 at 13:51, wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -508,18 +508,23 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>> void write_ptbase(struct vcpu *v)
>>> {
>>> struct cpu_info *cpu_info = get_cpu_info();
>>> +unsigned long new_cr4;
>>> +
>>> +new_cr4 = (is_pv_vcpu(v) && !is_idle_vcpu(v))
>>> + ? pv_guest_cr4_to_real_cr4(v) : mmu_cr4_features;
>>
>> I'm not overly happy to see any new uses of mmu_cr4_features.
>> This should really only be used for priming certain values imo,
>> which isn't the case here (otoh pv_guest_cr4_to_real_cr4() does
>> so too, and perhaps better wouldn't). Hence I wonder whether
>> this shouldn't be read_cr4() | X86_CR4_PGE, not the least
>> because we've just got rid of the blanket reversion to
>> mmu_cr4_features in VMX code.
>
> I do understand that using mmu_cr4_features isn't the best way to set
> cr4. But I think it is a good idea to have a default value which should
> normally be used instead of only switching various bits on and off.
>
> In case cr4 is loaded with a strange value in some corner case that
> value might be used from then on instead of being repaired by loading a
> dedicated value at certain points in time, e.g. when doing a context
> switch.
But that would make it even more difficult to notice and debug a
possible problem. The more we play with CR4 bits, the more
important it is that we keep an accurate record of what is currently
loaded into it, and that we have a clear understanding of what we
mean to be loaded into the register at any given point in time.
>>>
>>> What about adding an appropriate ASSERT() for that case?
>>>
>>> So I would use read_cr4() | X86_CR4_PGE and ASSERT() that cr4 matches
>>> the default value.
>>
>> That's an option; later we may want to sprinkle around a few more
>> such assertions.
>
> Okay, I'll go that route then. Do you want me to use a new default_cr4
> variable for doing the assertion (and as initial cr4 value for secondary
> cpus), or are you fine with using mmu_cr4_features for now?
I'd prefer if we could get away without yet another variable holding
some variant of possible CR4 values. As a follow-up we'll then want
to switch pv_guest_cr4_to_real_cr4() away from using
mmu_cr4_features as well (except for a possible assertion to put
there).
And btw, please consider re-organizing your change to
pv_guest_cr4_to_real_cr4() to match what we do for X86_CR4_TSD,
rather than first ORing in X86_CR4_PGE in order to then
(conditionally) mask it back out.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active
>>> On 23.03.18 at 08:58, wrote:
> On 23/03/18 08:46, Jan Beulich wrote:
> On 22.03.18 at 19:18, wrote:
>>> On 22/03/18 17:30, Jan Beulich wrote:
>>> On 21.03.18 at 13:51, wrote:
> Instead of flushing the TLB from global pages when switching address
> spaces with XPTI being active just disable global pages via %cr4
> completely when a domain subject to XPTI is active. This avoids the
> need for extra TLB flushes as loading %cr3 will remove all TLB
> entries.
I continue to be not entirely convinced of this move. I had an
alternative in mind: Since retaining global pages is particularly
relevant for switches between guest user and guest kernel
modes, what if we made a shortcut from e.g. lstar_enter through
switch_to_kernel to restore_all_guest without ever switching to
the full page Xen tables?
>>>
>>> With patch 7 of this series in mind I'm not convinced the extra effort
>>> is really making sense. Today most processors do have PCID support so
>>> for that old hardware I don't think we need to make the handling even
>>> more complex.
>>
>> PCID yes, but INVPCID (and we're talking about Intel hardware
>> here only anyway)? But yes, the extra complexity is what has kept
>> me so far from investing time here.
>
> As PCID seems to speed up XPTI only and XPTI is necessary for INTEL cpus
> only I don't see a problem here. :-)
Well, yes as far as AMD is unaffected, but not entirely yes to the
rest, as I intentionally pointed out the difference of availability of
PCID (which even Westmere's have) and INVPCID (which only my
Haswell has).
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -508,18 +508,23 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
> void write_ptbase(struct vcpu *v)
> {
> struct cpu_info *cpu_info = get_cpu_info();
> +unsigned long new_cr4;
> +
> +new_cr4 = (is_pv_vcpu(v) && !is_idle_vcpu(v))
> + ? pv_guest_cr4_to_real_cr4(v) : mmu_cr4_features;
I'm not overly happy to see any new uses of mmu_cr4_features.
This should really only be used for priming certain values imo,
which isn't the case here (otoh pv_guest_cr4_to_real_cr4() does
so too, and perhaps better wouldn't). Hence I wonder whether
this shouldn't be read_cr4() | X86_CR4_PGE, not the least
because we've just got rid of the blanket reversion to
mmu_cr4_features in VMX code.
>>>
>>> I do understand that using mmu_cr4_features isn't the best way to set
>>> cr4. But I think it is a good idea to have a default value which should
>>> normally be used instead of only switching various bits on and off.
>>>
>>> In case cr4 is loaded with a strange value in some corner case that
>>> value might be used from then on instead of being repaired by loading a
>>> dedicated value at certain points in time, e.g. when doing a context
>>> switch.
>>
>> But that would make it even more difficult to notice and debug a
>> possible problem. The more we play with CR4 bits, the more
>> important it is that we keep an accurate record of what is currently
>> loaded into it, and that we have a clear understanding of what we
>> mean to be loaded into the register at any given point in time.
>
> What about adding an appropriate ASSERT() for that case?
>
> So I would use read_cr4() | X86_CR4_PGE and ASSERT() that cr4 matches
> the default value.
That's an option; later we may want to sprinkle around a few more
such assertions.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5] hvm/svm: Implement Debug events
At this moment the Debug events for the AMD architecture are not
forwarded to the monitor layer.
This patch adds the Debug event to the common capabilities, adds
the VMEXIT_ICEBP then forwards the event to the monitor layer.
Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1
exception generated by the single byte INT1
instruction (also known as ICEBP) does not trigger the #DB
intercept. Software should use the dedicated ICEBP
intercept to intercept ICEBP"
Signed-off-by: Alexandru Isaila
---
Changes since V4:
- Add const to struct vcpu *v
- Check trap_type == X86_EVENTTYPE_PRI_SW_EXCEPTION
- Replaced return 1/0 with true/false
- Add space after if
---
xen/arch/x86/hvm/svm/emulate.c| 1 +
xen/arch/x86/hvm/svm/svm.c| 60 +--
xen/arch/x86/monitor.c| 3 ++
xen/include/asm-x86/hvm/hvm.h | 25 +++
xen/include/asm-x86/hvm/svm/emulate.h | 1 +
xen/include/asm-x86/monitor.h | 4 +--
6 files changed, 76 insertions(+), 18 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/emulate.c b/xen/arch/x86/hvm/svm/emulate.c
index e1a1581..535674e 100644
--- a/xen/arch/x86/hvm/svm/emulate.c
+++ b/xen/arch/x86/hvm/svm/emulate.c
@@ -65,6 +65,7 @@ static const struct {
} opc_tab[INSTR_MAX_COUNT] = {
[INSTR_PAUSE] = { X86EMUL_OPC_F3(0, 0x90) },
[INSTR_INT3]= { X86EMUL_OPC( 0, 0xcc) },
+[INSTR_ICEBP] = { X86EMUL_OPC( 0, 0xf1) },
[INSTR_HLT] = { X86EMUL_OPC( 0, 0xf4) },
[INSTR_XSETBV] = { X86EMUL_OPC(0x0f, 0x01), MODRM(3, 2, 1) },
[INSTR_VMRUN] = { X86EMUL_OPC(0x0f, 0x01), MODRM(3, 3, 0) },
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c34f5b5..c073ec7 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -172,6 +172,24 @@ static void svm_enable_msr_interception(struct domain *d,
uint32_t msr)
svm_intercept_msr(v, msr, MSR_INTERCEPT_WRITE);
}
+static void svm_set_icebp_interception(struct domain *d, bool enable)
+{
+const struct vcpu *v;
+
+for_each_vcpu ( d, v )
+{
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+uint32_t intercepts = vmcb_get_general2_intercepts(vmcb);
+
+if ( enable )
+intercepts |= GENERAL2_INTERCEPT_ICEBP;
+else
+intercepts &= ~GENERAL2_INTERCEPT_ICEBP;
+
+vmcb_set_general2_intercepts(vmcb, intercepts);
+}
+}
+
static void svm_save_dr(struct vcpu *v)
{
struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -1109,7 +1127,8 @@ static void noreturn svm_do_resume(struct vcpu *v)
{
struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
bool debug_state = (v->domain->debugger_attached ||
-v->domain->arch.monitor.software_breakpoint_enabled);
+v->domain->arch.monitor.software_breakpoint_enabled ||
+v->domain->arch.monitor.debug_exception_enabled);
bool_t vcpu_guestmode = 0;
struct vlapic *vlapic = vcpu_vlapic(v);
@@ -2438,19 +2457,6 @@ static bool svm_get_pending_event(struct vcpu *v, struct
x86_event *info)
return true;
}
-static void svm_propagate_intr(struct vcpu *v, unsigned long insn_len)
-{
-struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
-struct x86_event event = {
-.vector = vmcb->eventinj.fields.type,
-.type = vmcb->eventinj.fields.type,
-.error_code = vmcb->exitinfo1,
-};
-
-event.insn_len = insn_len;
-hvm_inject_event(&event);
-}
-
static struct hvm_function_table __initdata svm_function_table = {
.name = "SVM",
.cpu_up_prepare = svm_cpu_up_prepare,
@@ -2490,6 +2496,7 @@ static struct hvm_function_table __initdata
svm_function_table = {
.msr_read_intercept = svm_msr_read_intercept,
.msr_write_intercept = svm_msr_write_intercept,
.enable_msr_interception = svm_enable_msr_interception,
+.set_icebp_interception = svm_set_icebp_interception,
.set_rdtsc_exiting= svm_set_rdtsc_exiting,
.set_descriptor_access_exiting = svm_set_descriptor_access_exiting,
.get_insn_bytes = svm_get_insn_bytes,
@@ -2656,9 +2663,28 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
HVMTRACE_0D(SMI);
break;
+case VMEXIT_ICEBP:
case VMEXIT_EXCEPTION_DB:
if ( !v->domain->debugger_attached )
-hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
+{
+int rc;
+unsigned int trap_type = exit_reason == VMEXIT_ICEBP ?
+X86_EVENTTYPE_PRI_SW_EXCEPTION : X86_EVENTTYPE_HW_EXCEPTION;
+
+inst_len = 0;
+
+if ( trap_type == X86_EVENTTYPE_PRI_SW_EXCEPTION )
+inst_len = __get_instruction_length(v, INSTR_ICEBP);
+
+rc = hvm_monitor_debug(regs->rip,
+ HVM_MONITOR_DEBUG_EXCEPTION,
+
Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active
On 23/03/18 09:14, Jan Beulich wrote:
On 23.03.18 at 08:58, wrote:
>> On 23/03/18 08:46, Jan Beulich wrote:
>> On 22.03.18 at 19:18, wrote:
On 22/03/18 17:30, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> Instead of flushing the TLB from global pages when switching address
>> spaces with XPTI being active just disable global pages via %cr4
>> completely when a domain subject to XPTI is active. This avoids the
>> need for extra TLB flushes as loading %cr3 will remove all TLB
>> entries.
>
> I continue to be not entirely convinced of this move. I had an
> alternative in mind: Since retaining global pages is particularly
> relevant for switches between guest user and guest kernel
> modes, what if we made a shortcut from e.g. lstar_enter through
> switch_to_kernel to restore_all_guest without ever switching to
> the full page Xen tables?
With patch 7 of this series in mind I'm not convinced the extra effort
is really making sense. Today most processors do have PCID support so
for that old hardware I don't think we need to make the handling even
more complex.
>>>
>>> PCID yes, but INVPCID (and we're talking about Intel hardware
>>> here only anyway)? But yes, the extra complexity is what has kept
>>> me so far from investing time here.
>>
>> As PCID seems to speed up XPTI only and XPTI is necessary for INTEL cpus
>> only I don't see a problem here. :-)
>
> Well, yes as far as AMD is unaffected, but not entirely yes to the
> rest, as I intentionally pointed out the difference of availability of
> PCID (which even Westmere's have) and INVPCID (which only my
> Haswell has).
Haswells are out for nearly 5 years now.
I think in case we want to do something else here we should delay that
to 4.12. Even without PCID this patch is speeding up XPTI handling
significantly (parallel hypervisor compilation: elapsed time -6%,
system time -12%), so I'm not making anything worse.
BTW: while Westmere is supporting PCID I remember having done some PCID
testing with Westmere not showing any performance gains at all.
>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -508,18 +508,23 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>> void write_ptbase(struct vcpu *v)
>> {
>> struct cpu_info *cpu_info = get_cpu_info();
>> +unsigned long new_cr4;
>> +
>> +new_cr4 = (is_pv_vcpu(v) && !is_idle_vcpu(v))
>> + ? pv_guest_cr4_to_real_cr4(v) : mmu_cr4_features;
>
> I'm not overly happy to see any new uses of mmu_cr4_features.
> This should really only be used for priming certain values imo,
> which isn't the case here (otoh pv_guest_cr4_to_real_cr4() does
> so too, and perhaps better wouldn't). Hence I wonder whether
> this shouldn't be read_cr4() | X86_CR4_PGE, not the least
> because we've just got rid of the blanket reversion to
> mmu_cr4_features in VMX code.
I do understand that using mmu_cr4_features isn't the best way to set
cr4. But I think it is a good idea to have a default value which should
normally be used instead of only switching various bits on and off.
In case cr4 is loaded with a strange value in some corner case that
value might be used from then on instead of being repaired by loading a
dedicated value at certain points in time, e.g. when doing a context
switch.
>>>
>>> But that would make it even more difficult to notice and debug a
>>> possible problem. The more we play with CR4 bits, the more
>>> important it is that we keep an accurate record of what is currently
>>> loaded into it, and that we have a clear understanding of what we
>>> mean to be loaded into the register at any given point in time.
>>
>> What about adding an appropriate ASSERT() for that case?
>>
>> So I would use read_cr4() | X86_CR4_PGE and ASSERT() that cr4 matches
>> the default value.
>
> That's an option; later we may want to sprinkle around a few more
> such assertions.
Okay, I'll go that route then. Do you want me to use a new default_cr4
variable for doing the assertion (and as initial cr4 value for secondary
cpus), or are you fine with using mmu_cr4_features for now?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/pv: Fix the handing of writes to %dr7
>>> On 22.03.18 at 20:13, wrote: > c/s 65e35549 "x86/PV: support data breakpoint extension registers" > accidentally broke the handing of writes. The call to activate_debugregs() > doesn't write %dr7 as v->arch.debugreg[7] hasn't been updated yet, and the > break skips the intended write to %dr7. That's really odd, especially with the comment in activate_debugregs() specifically stating that fact. > Remove the break, causing execution to hit the write_debugreg(7, value); in > context at the bottom of the hunk, which in turn causes hardware to be updated > appropriately. > > 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
Re: [Xen-devel] [xen-4.6-testing test] 121031: regressions - FAIL
>>> On 23.03.18 at 01:13, wrote: > flight 121031 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/121031/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. > 119227 > test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail > REGR. vs. 119227 > test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. > vs. 119227 So this last one keeps being an issue, and no matter how many times I look at the logs, I can't spot more than apparently an L2 guest reboot does not actually work. Yet of the commits under test I can't spot anything that could at least half way sensibly be connected to such a regression. Are bisections initiated automatically for stable branches? If not, could one be set up on this one? Or wait, looking at the test's history on that branch the failure was introduced with commit d1618f473a5f (its immediate predecessor 9d534c12bf71 was still okay). Yet that's a 1-line ARM-only change. Which suggests to me that something outside the Xen sources has actually introduced the failure. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-next test] 121026: regressions - FAIL
flight 121026 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/121026/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 120952 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 120952 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 120952 test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 120952 test-armhf-armhf-xl-arndale 10 debian-install fail REGR. vs. 120952 test-armhf-armhf-xl-multivcpu 10 debian-install fail REGR. vs. 120952 test-armhf-armhf-xl-xsm 10 debian-install fail REGR. vs. 120952 Tests which did not succeed, but are not blocking: test-amd64-i386-examine 8 reboot fail like 120952 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail like 120952 test-amd64-i386-pair 10 xen-boot/src_hostfail like 120952 test-amd64-i386-pair 11 xen-boot/dst_hostfail like 120952 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail like 120952 test-amd64-i386-xl7 xen-boot fail like 120952 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail like 120952 test-amd64-i386-freebsd10-amd64 7 xen-boot fail like 120952 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 120952 test-amd64-i386-rumprun-i386 7 xen-boot fail like 120952 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail like 120952 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 120952 test-amd64-i386-libvirt-xsm 7 xen-boot fail like 120952 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail like 120952 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail like 120952 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail like 120952 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail like 120952 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail like 120952 test-amd64-i386-xl-xsm7 xen-boot fail like 120952 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-bootfail like 120952 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail like 120952 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail like 120952 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail like 120952 test-amd64-i386-xl-raw7 xen-boot fail like 120952 test-amd64-i386-freebsd10-i386 7 xen-bootfail like 120952 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail like 120952 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-bootfail like 120952 test-amd64-i386-libvirt 7 xen-boot fail like 120952 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail like 120952 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 120952 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 120952 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 120952 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120952 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120952 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120952 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 120952 test-amd64-i386-xl-pvshim 7 xen-boot fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 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-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-arm
Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active
>>> On 22.03.18 at 19:18, wrote:
> On 22/03/18 17:30, Jan Beulich wrote:
> On 21.03.18 at 13:51, wrote:
>>> Instead of flushing the TLB from global pages when switching address
>>> spaces with XPTI being active just disable global pages via %cr4
>>> completely when a domain subject to XPTI is active. This avoids the
>>> need for extra TLB flushes as loading %cr3 will remove all TLB
>>> entries.
>>
>> I continue to be not entirely convinced of this move. I had an
>> alternative in mind: Since retaining global pages is particularly
>> relevant for switches between guest user and guest kernel
>> modes, what if we made a shortcut from e.g. lstar_enter through
>> switch_to_kernel to restore_all_guest without ever switching to
>> the full page Xen tables?
>
> With patch 7 of this series in mind I'm not convinced the extra effort
> is really making sense. Today most processors do have PCID support so
> for that old hardware I don't think we need to make the handling even
> more complex.
PCID yes, but INVPCID (and we're talking about Intel hardware
here only anyway)? But yes, the extra complexity is what has kept
me so far from investing time here.
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -508,18 +508,23 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>> void write_ptbase(struct vcpu *v)
>>> {
>>> struct cpu_info *cpu_info = get_cpu_info();
>>> +unsigned long new_cr4;
>>> +
>>> +new_cr4 = (is_pv_vcpu(v) && !is_idle_vcpu(v))
>>> + ? pv_guest_cr4_to_real_cr4(v) : mmu_cr4_features;
>>
>> I'm not overly happy to see any new uses of mmu_cr4_features.
>> This should really only be used for priming certain values imo,
>> which isn't the case here (otoh pv_guest_cr4_to_real_cr4() does
>> so too, and perhaps better wouldn't). Hence I wonder whether
>> this shouldn't be read_cr4() | X86_CR4_PGE, not the least
>> because we've just got rid of the blanket reversion to
>> mmu_cr4_features in VMX code.
>
> I do understand that using mmu_cr4_features isn't the best way to set
> cr4. But I think it is a good idea to have a default value which should
> normally be used instead of only switching various bits on and off.
>
> In case cr4 is loaded with a strange value in some corner case that
> value might be used from then on instead of being repaired by loading a
> dedicated value at certain points in time, e.g. when doing a context
> switch.
But that would make it even more difficult to notice and debug a
possible problem. The more we play with CR4 bits, the more
important it is that we keep an accurate record of what is currently
loaded into it, and that we have a clear understanding of what we
mean to be loaded into the register at any given point in time.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/7] xen/x86: disable global pages for domains with XPTI active
On 23/03/18 08:46, Jan Beulich wrote:
On 22.03.18 at 19:18, wrote:
>> On 22/03/18 17:30, Jan Beulich wrote:
>> On 21.03.18 at 13:51, wrote:
Instead of flushing the TLB from global pages when switching address
spaces with XPTI being active just disable global pages via %cr4
completely when a domain subject to XPTI is active. This avoids the
need for extra TLB flushes as loading %cr3 will remove all TLB
entries.
>>>
>>> I continue to be not entirely convinced of this move. I had an
>>> alternative in mind: Since retaining global pages is particularly
>>> relevant for switches between guest user and guest kernel
>>> modes, what if we made a shortcut from e.g. lstar_enter through
>>> switch_to_kernel to restore_all_guest without ever switching to
>>> the full page Xen tables?
>>
>> With patch 7 of this series in mind I'm not convinced the extra effort
>> is really making sense. Today most processors do have PCID support so
>> for that old hardware I don't think we need to make the handling even
>> more complex.
>
> PCID yes, but INVPCID (and we're talking about Intel hardware
> here only anyway)? But yes, the extra complexity is what has kept
> me so far from investing time here.
As PCID seems to speed up XPTI only and XPTI is necessary for INTEL cpus
only I don't see a problem here. :-)
>
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -508,18 +508,23 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
void write_ptbase(struct vcpu *v)
{
struct cpu_info *cpu_info = get_cpu_info();
+unsigned long new_cr4;
+
+new_cr4 = (is_pv_vcpu(v) && !is_idle_vcpu(v))
+ ? pv_guest_cr4_to_real_cr4(v) : mmu_cr4_features;
>>>
>>> I'm not overly happy to see any new uses of mmu_cr4_features.
>>> This should really only be used for priming certain values imo,
>>> which isn't the case here (otoh pv_guest_cr4_to_real_cr4() does
>>> so too, and perhaps better wouldn't). Hence I wonder whether
>>> this shouldn't be read_cr4() | X86_CR4_PGE, not the least
>>> because we've just got rid of the blanket reversion to
>>> mmu_cr4_features in VMX code.
>>
>> I do understand that using mmu_cr4_features isn't the best way to set
>> cr4. But I think it is a good idea to have a default value which should
>> normally be used instead of only switching various bits on and off.
>>
>> In case cr4 is loaded with a strange value in some corner case that
>> value might be used from then on instead of being repaired by loading a
>> dedicated value at certain points in time, e.g. when doing a context
>> switch.
>
> But that would make it even more difficult to notice and debug a
> possible problem. The more we play with CR4 bits, the more
> important it is that we keep an accurate record of what is currently
> loaded into it, and that we have a clear understanding of what we
> mean to be loaded into the register at any given point in time.
What about adding an appropriate ASSERT() for that case?
So I would use read_cr4() | X86_CR4_PGE and ASSERT() that cr4 matches
the default value.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] possible I/O emulation state machine issue
>>> On 22.03.18 at 16:29, wrote: > On 22/03/18 15:12, Jan Beulich wrote: >> Paul, >> >> our PV driver person has found a reproducible crash with ws2k8, >> triggered by one of the WHQL tests. The guest get crashed because >> the re-issue check of an ioreq close to the top of hvmemul_do_io() >> fails. I've handed him a first debugging patch, output of which >> suggests that we're dealing with a completely new request, which >> in turn would mean that we've run into stale STATE_IORESP_READY >> state: >> >> (XEN) d2v3: t=0/1 a=3c4/fed000f0 s=2/4 c=1/1 d=0/1 f=0/0 p=0/0 > v=100/831873f27a30 >> (XEN) [ Xen-4.10.0_15-0 x86_64 debug=n Tainted: C ] > > Irrespective of the issue at hand, can testing be tried with a debug > build to see if any of the assertions are hit? Nothing, unfortunately. But at least the stack trace can be relied upon this way. Jan (XEN) d2v3: t=0/1 a=3ce/fed000f0 s=2/4 c=1/1 d=0/1 f=0/0 p=0/0 v=406/83387d21fa30 (XEN) [ Xen-4.10.0_15-0 x86_64 debug=y Tainted: C ] (XEN) CPU:62 (XEN) RIP:e008:[] emulate.c#hvmemul_do_io+0x169/0x445 (XEN) RFLAGS: 00010292 CONTEXT: hypervisor (d2v3) (XEN) rax: 8308796f602c rbx: 830007d26000 rcx: (XEN) rdx: 83387d21 rsi: 000a rdi: 82d0804823b8 (XEN) rbp: 83387d21f788 rsp: 83387d21f6a8 r8: 830879d0 (XEN) r9: 0030 r10: 000f r11: ffee (XEN) r12: 0004 r13: r14: 83387d21f850 (XEN) r15: 0001 cr0: 80050033 cr4: 26e0 (XEN) cr3: 0037d2026000 cr2: f880051d17ac (XEN) fsb: gsb: gss: 07f98000 (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen code around (emulate.c#hvmemul_do_io+0x169/0x445): (XEN) 00 00 00 e8 f5 e2 f6 ff <0f> 0b 48 83 c4 60 ba ab 00 00 00 48 8d 35 89 cd (XEN) Xen stack trace from rsp=83387d21f6a8: (XEN)0002 0004 0001 0001 (XEN) 0001 (XEN) 0406 83387d21fa30 (XEN)83387d21f798 fed000f0 831187beb000 00017d21f914 (XEN) 014c 03ce 0406 (XEN)00020001 014c 0004 (XEN)0001 83387d21fa30 fed000f0 830007d269c8 (XEN)83387d21f7c8 82d0802e5c06 83387d21fa30 (XEN)0004 0004 fed000f0 (XEN)83387d21f898 82d0802e6264 83387d21fa30 0003 (XEN)83387d21f860 83387d21f858 0004 ffd070f0 (XEN)0003 83387d21fc58 00040001 83387d21f850 (XEN) 83387d21fa30 01ff83380004 83387d21fa30 (XEN)1b41 0001 0001 fed000f0 (XEN)8318ad778380 0004 83387d21fc58 0001 (XEN)0002 830007d26000 83387d21f918 82d0802e725f (XEN)0001 82d0803e6da0 83387d21fa30 (XEN)0001 ffd070f0 00861efd 0004 (XEN)008b 83387d21f9c0 83387d21fc58 82d0803e6da0 (XEN)83387d21fef8 008b 83387d21f928 82d0802e73c3 (XEN) Xen call trace: (XEN)[] emulate.c#hvmemul_do_io+0x169/0x445 (XEN)[] emulate.c#hvmemul_do_io_buffer+0x2e/0x68 (XEN)[] emulate.c#hvmemul_linear_mmio_access+0x2b9/0x3fc (XEN)[] emulate.c#__hvmemul_read+0x163/0x1fa (XEN)[] emulate.c#hvmemul_read+0x1c/0x2a (XEN)[] x86_emulate.c#read_ulong+0x13/0x15 (XEN)[] x86_emulate+0x47d/0x1efa3 (XEN)[] x86_emulate_wrapper+0x26/0x5f (XEN)[] emulate.c#_hvm_emulate_one+0x54/0x173 (XEN)[] hvm_emulate_one+0x10/0x12 (XEN)[] hvm_emulate_one_insn+0x42/0x130 (XEN)[] handle_mmio_with_translation+0x4f/0x51 (XEN)[] hvm_hap_nested_page_fault+0x1e4/0x6b6 (XEN)[] vmx_vmexit_handler+0x1796/0x1d3d (XEN)[] vmx_asm_vmexit_handler+0xe8/0x250 (XEN) (XEN) domain_crash called from emulate.c:171 (XEN) Domain 2 (vcpu#3) crashed on cpu#62: (XEN) [ Xen-4.10.0_15-0 x86_64 debug=y Tainted: C ] (XEN) CPU:62 (XEN) RIP:0010:[] (XEN) RFLAGS: 00010046 CONTEXT: hvm guest (d2v3) (XEN) rax: ffd07000 rbx: rcx: 000c800022a5 (XEN) rdx: fd5b rsi: fa60019dba00 rdi: fa80049bf3e0 (XEN) rbp: fa80049da440 rsp: fa60019ffcd8 r8: (XEN) r9: 0001 r10: r11: (XEN) r12: r13: 0912 r14: fa8003c20950 (XEN) r15: 00019274 cr0: 80050031 cr4: 06f
[Xen-devel] [PATCH for-4.11] tools/xenstore: fix linking libxenstore with ldl
Commit 448c03b3cbe1487 ("tools/xenstore: try to get minimum thread
stack size for watch thread") added a dependency to libdl to
libxenstore. Unfortunately the way it was added requires now all
users of libxenstore to specify "-ldl" when linking. This can be
avoided by linking libxenstore.so specifying "-ldl" as a trailing
option. So use APPEND_LDFLAGS instead of LDFLAGS for adding the
"-ldl" option when linking libxenstore.so.
Signed-off-by: Juergen Gross
---
tools/xenstore/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 69e55e73e5..445e9911b2 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -104,7 +104,7 @@ libxenstore.so.$(MAJOR): libxenstore.so.$(MAJOR).$(MINOR)
xs.opic: CFLAGS += -DUSE_PTHREAD
ifeq ($(CONFIG_Linux),y)
xs.opic: CFLAGS += -DUSE_DLSYM
-libxenstore.so.$(MAJOR).$(MINOR): LDFLAGS += -ldl
+libxenstore.so.$(MAJOR).$(MINOR): APPEND_LDFLAGS += -ldl
else
PKG_CONFIG_REMOVE += -ldl
endif
--
2.13.6
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
