[Xen-devel] [xen-unstable-smoke test] 134084: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  1316369dca610352cce3aaf76e90db1cce75ed9f
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z3 days
Testing same since   134068  2019-03-25 12:00:51 Z0 days5 attempts


People who touched revisions under test:
  Andrew Cooper 
  Wei Liu 

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 1316369dca610352cce3aaf76e90db1cce75ed9f
Author: Andrew Cooper 
Date:   Fri Mar 22 11:12:28 2019 +

CI: Fix indentation in containerize script

The script is mostly indented with spaces, but there are three tabs.  Fix 
them
up to be consistent.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
(qemu changes not included)

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

[Xen-devel] [PATCH v1 1/1] hvmloader: allow overriding SMBIOS type 2 info

[Xin Li]

Extend smbios type 2 struct to match specification, add support to
override strings from toolstack.

Signed-off-by: Xin Li 

---
CC: Igor Druzhinin 
CC: Sergey Dyasli 
CC: Andrew Cooper 

---
 tools/firmware/hvmloader/smbios.c   | 64 -
 tools/firmware/hvmloader/smbios_types.h |  6 +++
 xen/include/public/hvm/hvm_xs_strings.h | 30 +++-
 3 files changed, 87 insertions(+), 13 deletions(-)

diff --git a/tools/firmware/hvmloader/smbios.c 
b/tools/firmware/hvmloader/smbios.c
index 40d8399be1..90cfe9fd10 100644
--- a/tools/firmware/hvmloader/smbios.c
+++ b/tools/firmware/hvmloader/smbios.c
@@ -497,9 +497,11 @@ static void *
 smbios_type_2_init(void *start)
 {
 struct smbios_type_2 *p = (struct smbios_type_2 *)start;
+const char *s;
 uint8_t *ptr;
 void *pts;
 uint32_t length;
+uint32_t counter = 0;
 
 pts = get_smbios_pt_struct(2, &length);
 if ( (pts != NULL)&&(length > 0) )
@@ -518,7 +520,67 @@ smbios_type_2_init(void *start)
 return (start + length);
 }
 
-/* Only present when passed in */
+s = xenstore_read(HVM_XS_BASEBOARD_MANUFACTURER, NULL);
+if ( (s != NULL) && (*s != '\0') )
+{
+memset(p, 0, sizeof(*p));
+p->header.type = 2;
+p->header.length = sizeof(struct smbios_type_2);
+p->header.handle = SMBIOS_HANDLE_TYPE2;
+p->feature_flags = 0x09; /* Board is a hosting board and replaceable */
+p->chassis_handle = SMBIOS_HANDLE_TYPE3;
+p->board_type = 0x0a; /* Motherboard */
+start += sizeof(struct smbios_type_2);
+
+strcpy((char *)start, s);
+start += strlen(s) + 1;
+p->manufacturer_str = ++counter;
+
+s = xenstore_read(HVM_XS_BASEBOARD_PRODUCT_NAME, NULL);
+if ( (s != NULL) && (*s != '\0') )
+{
+strcpy((char *)start, s);
+start += strlen(s) + 1;
+p->product_name_str = ++counter;
+}
+
+s = xenstore_read(HVM_XS_BASEBOARD_VERSION, NULL);
+if ( (s != NULL) && (*s != '\0') )
+{
+strcpy((char *)start, s);
+start += strlen(s) + 1;
+p->version_str = ++counter;
+}
+
+s = xenstore_read(HVM_XS_BASEBOARD_SERIAL_NUMBER, NULL);
+if ( (s != NULL) && (*s != '\0') )
+{
+strcpy((char *)start, s);
+start += strlen(s) + 1;
+p->serial_number_str = ++counter;
+}
+
+s = xenstore_read(HVM_XS_BASEBOARD_ASSET_TAG, NULL);
+if ( (s != NULL) && (*s != '\0') )
+{
+strcpy((char *)start, s);
+start += strlen(s) + 1;
+p->asset_tag_str = ++counter;
+}
+
+s = xenstore_read(HVM_XS_BASEBOARD_LOCATION_IN_CHASSIS, NULL);
+if ( (s != NULL) && (*s != '\0') )
+{
+strcpy((char *)start, s);
+start += strlen(s) + 1;
+p->location_in_chassis_str = ++counter;
+}
+
+*((uint8_t *)start) = 0;
+return start + 1;
+}
+   
+/* Only present when passed in or overriden */
 return start;
 }
 
diff --git a/tools/firmware/hvmloader/smbios_types.h 
b/tools/firmware/hvmloader/smbios_types.h
index acb63e2fe9..834ef38fba 100644
--- a/tools/firmware/hvmloader/smbios_types.h
+++ b/tools/firmware/hvmloader/smbios_types.h
@@ -90,6 +90,12 @@ struct smbios_type_2 {
 uint8_t product_name_str;
 uint8_t version_str;
 uint8_t serial_number_str;
+uint8_t asset_tag_str;
+uint8_t feature_flags;
+uint8_t location_in_chassis_str;
+uint16_t chassis_handle;
+uint8_t board_type;
+uint8_t contained_handle_count;
 } __attribute__ ((packed));
 
 /* System Enclosure - Contained Elements */
diff --git a/xen/include/public/hvm/hvm_xs_strings.h 
b/xen/include/public/hvm/hvm_xs_strings.h
index fea1dd4407..e3b328321d 100644
--- a/xen/include/public/hvm/hvm_xs_strings.h
+++ b/xen/include/public/hvm/hvm_xs_strings.h
@@ -62,18 +62,24 @@
 /* The following xenstore values are used to override some of the default
  * string values in the SMBIOS table constructed in hvmloader.
  */
-#define HVM_XS_BIOS_STRINGS"bios-strings"
-#define HVM_XS_BIOS_VENDOR "bios-strings/bios-vendor"
-#define HVM_XS_BIOS_VERSION"bios-strings/bios-version"
-#define HVM_XS_SYSTEM_MANUFACTURER "bios-strings/system-manufacturer"
-#define HVM_XS_SYSTEM_PRODUCT_NAME "bios-strings/system-product-name"
-#define HVM_XS_SYSTEM_VERSION  "bios-strings/system-version"
-#define HVM_XS_SYSTEM_SERIAL_NUMBER"bios-strings/system-serial-number"
-#define HVM_XS_ENCLOSURE_MANUFACTURER  "bios-strings/enclosure-manufacturer"
-#define HVM_XS_ENCLOSURE_SERIAL_NUMBER "bios-strings/enclosure-serial-number"
-#define HVM_XS_ENCLOSURE_ASSET_TAG "bios-strings/enclosure-asset-tag"
-#define HVM_XS_BATTERY_MANUFACTURER"bios-strings/battery-manufacturer"
-#define HVM_XS_BATTERY_DEVICE_NAME "bios-strings/battery-device-n

[Xen-devel] [xen-unstable-smoke test] 134079: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  1316369dca610352cce3aaf76e90db1cce75ed9f
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z3 days
Testing same since   134068  2019-03-25 12:00:51 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Wei Liu 

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 1316369dca610352cce3aaf76e90db1cce75ed9f
Author: Andrew Cooper 
Date:   Fri Mar 22 11:12:28 2019 +

CI: Fix indentation in containerize script

The script is mostly indented with spaces, but there are three tabs.  Fix 
them
up to be consistent.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
(qemu changes not included)

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

[Xen-devel] [linux-4.14 test] 134056: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64  broken
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 133923
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133923
 build-arm64   4 host-install(4)broken REGR. vs. 133923
 test-arm64-arm64-libvirt-xsm broken  in 134016
 test-arm64-arm64-libvirt-xsm 4 host-install(4) broken in 134016 REGR. vs. 
133923

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-examine  4 memdisk-try-append fail pass in 134016

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1 13 migrate-support-check fail in 134016 never pass
 test-arm64-arm64-xl-credit1 14 saverestore-support-check fail in 134016 never 
pass
 test-arm64-arm64-xl 13 migrate-support-check fail in 134016 never pass
 test-arm64-arm64-xl 14 saverestore-support-check fail in 134016 never pass
 test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 134016 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 134016 never pass
 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 134016 never pass
 test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 134016 never 
pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-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-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-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-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-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-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivc

Re: [Xen-devel] python3 issues

[Elliott Mitchell]

On Mon, Mar 25, 2019 at 10:20:05PM +, YOUNG, MICHAEL A. wrote:
> I have been testing the python3 changes committed to xen and found a few 
> issues. There are a couple of ocaml python build scripts that don't work 
> for me with python3, and I needed a few fixes to get pygrub to work, 
> mostly due to the change from strings to bytes. I am attaching the patch I 
> put together in testing to get these things to work to illustrate where 
> the problems are and in case it is useful to others, though I believe at 
> least some of it isn't compatible with python2.

Most Python code can be easily made compatible with both Python 2 and
Python 3 with the right constructs.


> --- xen-4.12.0-rc5/tools/ocaml/libs/xentoollog/genlevels.py.orig  
> 2019-03-06 14:42:49.0 +
> +++ xen-4.12.0-rc5/tools/ocaml/libs/xentoollog/genlevels.py   2019-03-13 
> 21:33:59.805930989 +
> @@ -86,14 +87,14 @@
>  def autogen_header(open_comment, close_comment):
>  s = open_comment + " AUTO-GENERATED FILE DO NOT EDIT " + close_comment + 
> "\n"
>  s += open_comment + " autogenerated by \n"
> -s += reduce(lambda x,y: x + " ", range(len(open_comment + " ")), "")
> +s += reduce(lambda x,y: x + " ", list(range(len(open_comment + " "))), 
> "")
>  s += "%s" % " ".join(sys.argv)
>  s += "\n " + close_comment + "\n\n"
>  return s
>  
>  if __name__ == '__main__':
>   if len(sys.argv) < 3:
> - print >>sys.stderr, "Usage: genlevels.py   "
> + print("Usage: genlevels.py   ", file=sys.stderr)
>   sys.exit(1)
>  
>   levels, olevels = read_levels()

The print() function notation is required for Python 3, but has a bit of
trouble with Python 2.  Python 2 though does have support.  At the top of
the relevant files add "from __future__ import print_function" and the
print() will work in Python 2.  I'm unsure of the status of the other
constructs in this patch.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



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

[Xen-devel] [linux-4.19 test] 134050: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64   4 host-install(4)broken REGR. vs. 129313
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 129313
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 129313
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
129313

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 129313

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 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-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-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-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-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxa2cddfe2ce6e9108341820fff8af46713685b2cb
baseline version:
 linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d

Last test of basis   129313  2018-11-02 05:39:08 Z  143 days
Failing since   

[Xen-devel] [xen-unstable-smoke test] 134077: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  1316369dca610352cce3aaf76e90db1cce75ed9f
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z3 days
Testing same since   134068  2019-03-25 12:00:51 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Wei Liu 

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 1316369dca610352cce3aaf76e90db1cce75ed9f
Author: Andrew Cooper 
Date:   Fri Mar 22 11:12:28 2019 +

CI: Fix indentation in containerize script

The script is mostly indented with spaces, but there are three tabs.  Fix 
them
up to be consistent.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
(qemu changes not included)

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

Re: [Xen-devel] Xen 4.8.5 release missing on the website

[Lars Kurth]

Marek,
thanks for pointing this out. I will fix this tomorrow
Lars

> On 21 Mar 2019, at 23:11, Marek Marczykowski-Górecki 
>  wrote:
> 
> Signed PGP part
> Hi,
> 
> Looks like the new website doesn't list Xen 4.8.5:
> 
> https://xenproject.org/downloads/xen-project-archives/xen-project-4-8-series/
> https://xenproject.org/xen-project-archives/
> 
> Both have 4.8.4 as the latest version.
> 
> -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> 
> 


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

[Xen-devel] python3 issues

[YOUNG, MICHAEL A.]

I have been testing the python3 changes committed to xen and found a few 
issues. There are a couple of ocaml python build scripts that don't work 
for me with python3, and I needed a few fixes to get pygrub to work, 
mostly due to the change from strings to bytes. I am attaching the patch I 
put together in testing to get these things to work to illustrate where 
the problems are and in case it is useful to others, though I believe at 
least some of it isn't compatible with python2.

Michael Young--- xen-4.12.0-rc5/tools/ocaml/libs/xentoollog/genlevels.py.orig
2019-03-06 14:42:49.0 +
+++ xen-4.12.0-rc5/tools/ocaml/libs/xentoollog/genlevels.py 2019-03-13 
21:33:59.805930989 +
@@ -1,6 +1,7 @@
 #!/usr/bin/python
 
 import sys
+from functools import reduce
 
 def read_levels():
f = open('../../../libs/toollog/include/xentoollog.h', 'r')
@@ -86,14 +87,14 @@
 def autogen_header(open_comment, close_comment):
 s = open_comment + " AUTO-GENERATED FILE DO NOT EDIT " + close_comment + 
"\n"
 s += open_comment + " autogenerated by \n"
-s += reduce(lambda x,y: x + " ", range(len(open_comment + " ")), "")
+s += reduce(lambda x,y: x + " ", list(range(len(open_comment + " "))), "")
 s += "%s" % " ".join(sys.argv)
 s += "\n " + close_comment + "\n\n"
 return s
 
 if __name__ == '__main__':
if len(sys.argv) < 3:
-   print >>sys.stderr, "Usage: genlevels.py   "
+   print("Usage: genlevels.py   ", file=sys.stderr)
sys.exit(1)
 
levels, olevels = read_levels()
--- xen-4.12.0-rc5/tools/ocaml/libs/xl/genwrap.py.orig  2019-03-06 
14:42:49.0 +
+++ xen-4.12.0-rc5/tools/ocaml/libs/xl/genwrap.py   2019-03-13 
21:34:00.674962832 +
@@ -3,6 +3,7 @@
 import sys,os
 
 import idl
+from functools import reduce
 
 # typename -> ( ocaml_type, c_from_ocaml, ocaml_from_c )
 builtins = {
@@ -78,7 +79,7 @@
 elif isinstance(ty,idl.Array):
 return "%s array" % ocaml_type_of(ty.elem_type)
 elif isinstance(ty,idl.Builtin):
-if not builtins.has_key(ty.typename):
+if ty.typename not in builtins:
 raise NotImplementedError("Unknown Builtin %s (%s)" % 
(ty.typename, type(ty)))
 typename,_,_ = builtins[ty.typename]
 if not typename:
@@ -251,7 +252,7 @@
 else:
 s += "\texternal default : ctx -> %sunit -> t = 
\"stub_libxl_%s_init\"\n" % (union_args, ty.rawname)
 
-if functions.has_key(ty.rawname):
+if ty.rawname in functions:
 for name,args in functions[ty.rawname]:
 s += "\texternal %s : " % name
 s += " -> ".join(args)
@@ -278,7 +279,7 @@
 else:
 s += "%s = Int_val(%s);" % (c, o)
 elif isinstance(ty,idl.Builtin):
-if not builtins.has_key(ty.typename):
+if ty.typename not in builtins:
 raise NotImplementedError("Unknown Builtin %s (%s)" % 
(ty.typename, type(ty)))
 _,fn,_ = builtins[ty.typename]
 if not fn:
@@ -375,7 +376,7 @@
 else:
 s += "%s = Val_int(%s);" % (o, c)
 elif isinstance(ty,idl.Builtin):
-if not builtins.has_key(ty.typename):
+if ty.typename not in builtins:
 raise NotImplementedError("Unknown Builtin %s (%s)" % 
(ty.typename, type(ty)))
 _,_,fn = builtins[ty.typename]
 if not fn:
@@ -513,14 +514,14 @@
 def autogen_header(open_comment, close_comment):
 s = open_comment + " AUTO-GENERATED FILE DO NOT EDIT " + close_comment + 
"\n"
 s += open_comment + " autogenerated by \n"
-s += reduce(lambda x,y: x + " ", range(len(open_comment + " ")), "")
+s += reduce(lambda x,y: x + " ", list(range(len(open_comment + " "))), "")
 s += "%s" % " ".join(sys.argv)
 s += "\n " + close_comment + "\n\n"
 return s
 
 if __name__ == '__main__':
 if len(sys.argv) < 4:
-print >>sys.stderr, "Usage: genwrap.py"
+print("Usage: genwrap.py", file=sys.stderr)
 sys.exit(1)
 
 (_,types) = idl.parse(sys.argv[1])
@@ -533,7 +534,7 @@
 
 for t in blacklist:
 if t not in [ty.rawname for ty in types]:
-print "unknown type %s in blacklist" % t
+print("unknown type %s in blacklist" % t)
 
 types = [ty for ty in types if not ty.rawname in blacklist]
 
@@ -564,7 +565,7 @@
 cinc.write("\n")
 cinc.write(gen_Val_ocaml(ty))
 cinc.write("\n")
-if functions.has_key(ty.rawname):
+if ty.rawname in functions:
 cinc.write(gen_c_stub_prototype(ty, functions[ty.rawname]))
 cinc.write("\n")
 if ty.init_fn is not None:
--- xen-4.12.0-rc6/tools/pygrub/src/GrubConf.py.orig2019-03-24 
22:44:05.502581989 +
+++ xen-4.12.0-rc6/tools/pygrub/src/GrubConf.py 2019-03-24 22:49:14.025934786 
+
@@ -230,10 +230,10 @@
 def _get_default(self):
 return self._default
 def _set_defa

Re: [Xen-devel] [PATCH v2 1/1] treewide: Switch printk users from %pf and %pF to %ps and %pS, respectively

[Bjorn Helgaas]

On Mon, Mar 25, 2019 at 09:32:28PM +0200, Sakari Ailus wrote:
> %pF and %pf are functionally equivalent to %pS and %ps conversion
> specifiers. The former are deprecated, therefore switch the current users
> to use the preferred variant.
> 
> The changes have been produced by the following command:
> 
>   git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \
>   while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done
> 
> And verifying the result.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: David Sterba  (for btrfs)
> Acked-by: Mike Rapoport  (for mm/memblock.c)
> Acked-by: Rafael J. Wysocki 

Acked-by: Bjorn Helgaas  (for drivers/pci)

Thanks a lot for cleaning this up.  This has been annoying for a long time.

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

[Xen-devel] Xen from Xilinx 2018.3 not recognizing boot arguments

[Danux]

Hi,

When adding altp2m=1 argument to xen,xen-bootargs via DTB, I can see the
parameter passed via xl info:

xen_commandline: console=dtuart dtuart=serial0 dom0_mem=1G
bootscrub=0 maxcpus=1 timer_slop=0* altp2m=1*

However, I got an error like this at booting phase:

(XEN) parameter "*altp2m*" unknown!

Please shed some light on this.

Thanks.

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

[Xen-devel] [xen-unstable-smoke test] 134075: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991
 build-armhf   6 xen-buildfail REGR. vs. 133991

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail pass 
in 134068

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl 13 migrate-support-check fail in 134068 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 134068 never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  1316369dca610352cce3aaf76e90db1cce75ed9f
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z3 days
Testing same since   134068  2019-03-25 12:00:51 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Wei Liu 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)
broken-job build-arm64-xsm broken

Not pushing.


commit 1316369dca610352cce3aaf76e90db1cce75ed9f
Author: Andrew Cooper 
Date:   Fri Mar 22 11:12:28 2019 +

CI: Fix indentation in containerize script

The script is mostly indented with spaces, but there are three tabs.  Fix 
them
up to be consistent.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
(qemu changes not included)

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

[Xen-devel] [PATCH v2 1/1] treewide: Switch printk users from %pf and %pF to %ps and %pS, respectively

[Sakari Ailus]

%pF and %pf are functionally equivalent to %pS and %ps conversion
specifiers. The former are deprecated, therefore switch the current users
to use the preferred variant.

The changes have been produced by the following command:

git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \
while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done

And verifying the result.

Signed-off-by: Sakari Ailus 
Acked-by: David Sterba  (for btrfs)
Acked-by: Mike Rapoport  (for mm/memblock.c)
Acked-by: Rafael J. Wysocki 
---
I split this off from the set as there's a change in
include/trace/events/timer.h that conflicts with v1 of this patch and
should the second patch to be applied without that change, results into
invalid use of %pf. To address the matter safely without conflicts or
trying to print invalid pointer conversions, this patch and the other one
changing include/trace/events/timer.h must be merged before second patch
in v1 of this set can go in.

since v1:

- Drop such changes to include/trace/events/timer.h where %pf has already
  been converted to %ps in linux-next master.

 arch/alpha/kernel/pci_iommu.c   | 20 ++--
 arch/arm/mach-imx/pm-imx6.c |  2 +-
 arch/arm/mm/alignment.c |  2 +-
 arch/arm/nwfpe/fpmodule.c   |  2 +-
 arch/microblaze/mm/pgtable.c|  2 +-
 arch/sparc/kernel/ds.c  |  2 +-
 arch/um/kernel/sysrq.c  |  2 +-
 arch/x86/include/asm/trace/exceptions.h |  2 +-
 arch/x86/kernel/irq_64.c|  2 +-
 arch/x86/mm/extable.c   |  4 ++--
 arch/x86/xen/multicalls.c   |  2 +-
 drivers/acpi/device_pm.c|  2 +-
 drivers/base/power/main.c   |  6 +++---
 drivers/base/syscore.c  | 12 ++--
 drivers/block/drbd/drbd_receiver.c  |  2 +-
 drivers/block/floppy.c  | 10 +-
 drivers/cpufreq/cpufreq.c   |  2 +-
 drivers/mmc/core/quirks.h   |  2 +-
 drivers/nvdimm/bus.c|  2 +-
 drivers/nvdimm/dimm_devs.c  |  2 +-
 drivers/pci/pci-driver.c| 14 +++---
 drivers/pci/quirks.c|  4 ++--
 drivers/pnp/quirks.c|  2 +-
 drivers/scsi/esp_scsi.c |  2 +-
 fs/btrfs/tests/free-space-tree-tests.c  |  4 ++--
 fs/f2fs/f2fs.h  |  2 +-
 fs/pstore/inode.c   |  2 +-
 include/trace/events/btrfs.h|  2 +-
 include/trace/events/cpuhp.h|  4 ++--
 include/trace/events/preemptirq.h   |  2 +-
 include/trace/events/rcu.h  |  4 ++--
 include/trace/events/sunrpc.h   |  2 +-
 include/trace/events/vmscan.h   |  4 ++--
 include/trace/events/workqueue.h|  4 ++--
 include/trace/events/xen.h  |  2 +-
 init/main.c |  6 +++---
 kernel/async.c  |  4 ++--
 kernel/events/uprobes.c |  2 +-
 kernel/fail_function.c  |  2 +-
 kernel/irq/debugfs.c|  2 +-
 kernel/irq/handle.c |  2 +-
 kernel/irq/manage.c |  2 +-
 kernel/irq/spurious.c   |  4 ++--
 kernel/rcu/tree.c   |  2 +-
 kernel/stop_machine.c   |  2 +-
 kernel/time/sched_clock.c   |  2 +-
 kernel/time/timer.c |  2 +-
 kernel/workqueue.c  | 12 ++--
 lib/error-inject.c  |  2 +-
 lib/percpu-refcount.c   |  4 ++--
 mm/memblock.c   | 12 ++--
 mm/memory.c |  2 +-
 mm/vmscan.c |  2 +-
 net/ceph/osd_client.c   |  2 +-
 net/core/net-procfs.c   |  2 +-
 net/core/netpoll.c  |  4 ++--
 56 files changed, 105 insertions(+), 105 deletions(-)

diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 3034d6d936d2..242108439f42 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -249,7 +249,7 @@ static int pci_dac_dma_supported(struct pci_dev *dev, u64 
mask)
ok = 0;
 
/* If both conditions above are met, we are fine. */
-   DBGA("pci_dac_dma_supported %s from %pf\n",
+   DBGA("pci_dac_dma_supported %s from %ps\n",
 ok ? "yes" : "no", __builtin_return_address(0));
 
return ok;
@@ -281,7 +281,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, 
size_t size,
&& paddr + size <= __direct_map_size) {
ret = paddr + __direct_map_base;
 
-   DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %pf\n",
+   DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %ps\n",
  cpu_addr, size, ret, __builtin_return_address(0));
 

Re: [Xen-devel] [PATCH] x86/xen: Add "xen_timer_slop" command line option

[Boris Ostrovsky]

On 3/25/19 10:11 AM, Ryan Thibodeaux wrote:
> On Mon, Mar 25, 2019 at 09:43:20AM -0400, Boris Ostrovsky wrote:
>> On 3/25/19 8:05 AM, luca abeni wrote:
>>> Hi all,
>>>
>>> On Sat, 23 Mar 2019 11:41:51 +0100
>>> luca abeni  wrote:
>>> [...]
>> Is there any data that shows effects of using this new parameter?
>> 
> Yes, I've done some research and experiments on this. I did it
> together with a friend, which I'm Cc-ing, as I'm not sure we're
> ready/capable to share the results, yet (Luca?).  
 I think we can easily share the experimental data (cyclictest output
 and plots).

 Moreover, we can share the scripts and tools for running the
 experiments (so, everyone can easily reproduce the numbers by simply
 typing "make" and waiting for some time :)


 I'll try to package the results and the scripts/tools this evening,
 and I'll send them.
>>> Sorry for the delay. I put some quick results here:
>>> http://retis.santannapisa.it/luca/XenTimers/
>>> (there also is a link to the scripts to be used for reproducing the
>>> results). The latencies have been measured by running cyclictest in the
>>> guest (see the scripts for details).
>>>
>>> The picture shows the latencies measured with an unpatched guest kernel
>>> and with a guest kernel having TIMER_SLOP set to 1000 (arbitrary small
>>> value :).
>>> All the experiments have been performed booting the hypervisor with a
>>> small timer_slop (the hypervisor's one) value. So, they show that
>>> decreasing the hypervisor's timer_slop is not enough to measure low
>>> latencies with cyclictest.
>>
>>
>> I have a couple of questions:
>> * Does it make sense to make this a tunable for other clockevent devices
>> as well?
> I gather that would be on a case-by-case basis for very specific 
> ones.
>
> For many timers in the kernel, the minimums are determined by the
> actual hardware  backing the timer, and the minimum can be
> adjusted by the clockevent code. This case is special since it 
> is entirely a software-based implementation in the kernel, where 
> the actual timer implementation is in the Xen hypervisor.
>
>> * This patch adjusts min value. Could max value (ever) need a similar
>> adjustment?
> I cannot think of such a case where that would be helpful, but I
> cannot rule that out or speak as an authority.


I am asking mostly because you are introducing new interface and I don't
want it to change in the future. I suppose if later we decide to add
control for the max value we could just expand your current proposal to
xen_timer_slop=[min],[max] and keep it to be back-compatible.

For the patch:

Reviewed-by: Boris Ostrovsky 




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

Re: [Xen-devel] [PATCH 4/6] xen: don't free percpu areas during suspend

[Dario Faggioli]

On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
> Instead of freeing percpu areas during suspend and allocating them
> again when resuming keep them. Only free an area in case a cpu didn't
> come up again when resuming.
> 
> Signed-off-by: Juergen Gross 
>
Reviewed-by: Dario Faggioli 

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PULL 0/7] Tracing patches

[Peter Maydell]

On Mon, 25 Mar 2019 at 15:59, Stefan Hajnoczi  wrote:
>
> The following changes since commit d97a39d903fe33c45be83ac6943a2f82a3649a11:
>
>   Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' 
> into staging (2019-03-22 09:37:38 +)
>
> are available in the Git repository at:
>
>   git://github.com/stefanha/qemu.git tags/tracing-pull-request
>
> for you to fetch changes up to dec9776049e32d6c830127b286530c5f53267eff:
>
>   trace-events: Fix attribution of trace points to source (2019-03-22 
> 16:18:07 +)
>
> 
> Pull request
>
> Compilation fixes and cleanups for QEMU 4.0.0.
>
> 
>

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM

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

Re: [Xen-devel] [PATCH] x86/xen: Add "xen_timer_slop" command line option

[Ryan Thibodeaux]

On Mon, Mar 25, 2019 at 10:11:38AM -0400, Ryan Thibodeaux wrote:
> > > [...]
> >  Is there any data that shows effects of using this new parameter?
> >  

Continuing with the experimental data conversation (thanks to Luca and
Dario for being so generous), I am providing more results from quick
tests this morning.

I ran the same sequence of tests four times with the same hardware,
hypervisor, and Linux guest setup. Only changes between runs was 
adjusting the slop settings in Xen and Linux. This was on a 
build of Xen 4.10 and a Linux guest running the current Xen 
tip.git kernel with my patch.

For each sequence, I ran two variations of cyclictest on an isolated
processor. The first test used an interval of 50 microseconds and
second test used an interval of 1000 microseconds, passing "-i50"
and "-1" arguments to cyclictest respectively.

The variations of the sequences are as follows:
#1 - default slops:  Xen@5, Linux@10
#2 - lowering Linux: Xen@5, Linux@5000
#3 - lowering Xen:   Xen@5000,  Linux@10
#4 - lowering both:  Xen@5000,  Linux@5000

The cleaned up test output is below. Only showing the total
stats for each run and the number of spikes / samples that went 
over 100 microseconds. I do not record each sample value like
Luca and Dario, because I want to eliminate as many variables as
possible, e.g., eliminating overhead of writing out raw results.

Looking at the results, you can see that only lowering the Linux
slop (with my proposed patch) does reduce the overall PDL stats for
the shorter interval, but it especially lowers the spikes, in both
cases. Even in test #3 where the Xen slop was lowered, the spikes 
are a problem at the default Linux slop.

Reiterating what Luca and Dario said, lowering both slops is the 
way to consisten results for both interval configurations.

Note: even better stats can likely be achieved with more tuning
and using the RT patchset. These results were just focusing on
a non-specialized configuration.

...
##

# Timer Slop: Xen (default, 5) | Guest (default, 10)

# Cyclictest Interval (-i50)
Min: 62
Avg: 127
Max: 212
Spikes (over 100): 3892034

# Cyclictest Interval (-i1000)
Min: 24
Avg: 45
Max: 156
Spikes (over 100): 27


##

# Timer Slop: Xen (default, 5) | Guest (5000)

# Cyclictest Interval (-i50)
Min: 25
Avg: 78
Max: 230
Spikes (over 100): 274549

# Cyclictest Interval (-i1000)
Min: 37
Avg: 45
Max: 82
Spikes (over 100): 0


##

# Timer Slop: Xen (5000) | Guest (default, 10)

# Cyclictest Interval (-i50)
Min: 61
Avg: 126
Max: 226
Spikes (over 100): 3877860

# Cyclictest Interval (-i1000)
Min: 37
Avg: 45
Max: 74
Spikes (over 100): 0


##

# Timer Slop: Xen (5000) | Guest (5000)

# Cyclictest Interval (-i50)
Min: 13
Avg: 30
Max: 150
Spikes (over 100): 120

# Cyclictest Interval (-i1000)
Min: 37
Avg: 45
Max: 97
Spikes (over 100): 0
...

- Ryan

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

Re: [Xen-devel] [PATCH for-4.12] passthrough/vtd: Drop the "workaround_bios_bug" logic entirely

[Andrew Cooper]

On 25/03/2019 15:24, Jan Beulich wrote:
 On 21.03.19 at 21:26,  wrote:
>> It turns out that this code was previously dead.
> If it was entirely dead, why the rush to get the change into 4.12?
> (I suppose the later parts of description are then justifying why
> the code wasn't actually dead, and why it was getting in the way,
> but I think this way of putting it is at least confusing.)
>
>> c/s dcf41790 " x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling
>> acpi_parse_dmar()" resulted in PCI segment 0 now having been initialised
>> enough for acpi_parse_one_drhd() to not take the
>>
>>   /* Skip checking if segment is not accessible yet. */
>>
>> path unconditionally.
> Or am I misreading the initial sentence, and you're really suggesting
> that prior to said commit the code in question had been dead?

This logic (which is being deleted) used to be dead, and became non-dead
with the identified commit.

The code, now being run, constitutes a functional regression on some
hardware, which worked fine with Xen 4.11.

> How's that commit related then? Segment 0 is valid irrespective of any
> MMCFG information gained from ACPI tables (see pci_segments_init()).

Exactly - that is why it is a regression.

Before pci_segments_init() (which is the first action of
acpi_mmcfg_init(), and hence is moved by the mentioned commit),
acpi_parse_one_drhd()'s query of segment zero returns "not present",
causing the check to be skipped.

>
>>  However, some systems have DMAR tables which list
>> devices which are disabled by user choice (in particular, Dell PowerEdge R740
>> with I/O AT DMA disabled), and turning off all IOMMU functionality in this
>> case is entirely unhelpful behaviour.
> As in many other cases, what is or is not unhelpful is often a matter
> of perception and hence possibly subjective. I can see your point,
> but I also can see why the authors of the code considered it a rather
> bad sign if non-existing PCI devices get named by an ACPI table.
> What if e.g. later a device gets hot-plugged into that very SBDF?

Exactly the same as what happens on Xen 4.11 and earlier, whatever that
happens to be.

>
>> Leave the warning which identifies the problematic devices, but drop the
>> remaining logic.  This leaves the system in better overall state, and working
>> in the same way that it did in previous releases.
> I wonder whether you've taken the time to look at the description
> of the commit first introducing this logic (a8059ffced "VT-d: improve
> RMRR validity checking"). I find it worrying in particular to
> effectively revert a change which claims 'to avoid any security
> vulnerability with malicious s/s re-enabling "supposed disabled"
> devices' without any discussion of why that may have been a
> wrong perspective to take.

I had, and as a maintainer, I'd reject a patch like that were it
presented today.

There is a nebulous claim of security, but it is exactly that -
nebulous.  There isn't enough information to work out what the concern
was, and even if the concern was valid, disabling VT-d across the system
isn't an appropriate action to take.

>
> I'd also appreciate clarification on you saying "working in the same
> way that it did in previous releases" - it sounds as if you might
> have spotted a regression here, but it's not really becoming clear
> to me what that regression then would have been.
>
>> This is a candidate for 4.12.  Given the absense of Jan as the maintaner, and
>> the proximity to the 4.12 release, I put this patch to The Rest for a
>> hopefully-more-timely decision and review.
> To be honest, I have two problems with this: For one the main
> part of your change falls in Kevin's realm, not mine. And then,
> even if it would have been mainly me to ack the change, I was
> gone for three days, not three months. Yet the code had been
> this way for over 9 years. One thing seems pretty clear to me:
> It is at best non-obvious that there is no risk of regressions
> here.

The commit message states clearly the commit which caused the function
regression, and the justification for why deleting the code resolves the
regression by making the behaviour identical to 4.11 and earlier.

I'm not sure what more you are looking for, but this is very clear cut
and safe from my point of view.

~Andrew

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

Re: [Xen-devel] [PATCH] xen/netfront: Remove unneeded .resume callback

[Anchal Agarwal]

On Fri, Mar 22, 2019 at 10:44:33AM +, Oleksandr Andrushchenko wrote:
> 
> On 3/20/19 5:50 AM, Munehisa Kamata wrote:
> > On 3/18/2019 3:02 AM, Oleksandr Andrushchenko wrote:
> >> +Amazon
> >> pls see inline
> > Hi Oleksandr,
> >
> > Let me add some comments as the original author of the series.
> Thank you for your work!
Hi Oleksandr,
> >
> >> On 3/14/19 9:00 PM, Julien Grall wrote:
> >>> Hi,
> >>>
> >>> On 3/14/19 3:40 PM, Boris Ostrovsky wrote:
>  On 3/14/19 11:10 AM, Oleksandr Andrushchenko wrote:
> > On 3/14/19 5:02 PM, Boris Ostrovsky wrote:
> >> On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:
> >>> On 3/14/19 4:47 PM, Boris Ostrovsky wrote:
>  On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko 
> >
> > Currently on driver resume we remove all the network queues and
> > destroy shared Tx/Rx rings leaving the driver in its current state
> > and never signaling the backend of this frontend's state change.
> > This leads to the number of consequences:
> > - when frontend withdraws granted references to the rings etc. it
> > cannot
> >   be cleanly done as the backend still holds those (it was 
> > not
> > told to
> >   free the resources)
> > - it is not possible to resume driver operation as all the
> > communication
> >   means with the backned were destroyed by the frontend, 
> > thus
> >   making the frontend appear to the guest OS as functional, 
> > but
> >   not really.
>  What do you mean? Are you saying that after resume you lose
>  connectivity?
> >>> Exactly, if you take a look at the .resume callback as it is now
> >>> what it does it destroys the rings etc. and never notifies the backend
> >>> of that, e.g. it stays in, say, connected state with communication
> >>> channels destroyed. It never goes into any other Xen bus state, so
> >>> there is
> >>> no way its state machine can help recovering.
> >> My tree is about a month old so perhaps there is some sort of 
> >> regression
> >> but this certainly works for me. After resume netfront gets
> >> XenbusStateInitWait from backend which causes xennet_connect().
> > Ah, the difference can be of the way we get the guest enter
> > the suspend state. I am making my guest to suspend with:
> > echo mem > /sys/power/state
> > And then I use an interrupt to the guest (this is a test code)
> > to wake it up.
> > Could you please share your exact use-case when the guest enters suspend
> > and what you do to resume it?
> 
>  xl save / xl restore
> 
> > I can see no way backend may want enter XenbusStateInitWait in my
> > use-case
> > as it simply doesn't know we want him to.
> 
>  Yours looks like ACPI path, I don't know how well it was tested TBH.
> >>> I remember a series from amazon [1] that plays around suspend and 
> >>> hibernation. The patch [2] leads me to think that guest triggered 
> >>> suspend/resume does not work properly. It looks like the series has never 
> >>> been fully reviewed. Not sure why...
> >> Julien, thanks a lot for bringing these patches to our attention which we 
> >> obviously missed.
> >>> Anyway, from my understanding this series may solve Oleksandr issue. 
> >>> However, this would only address the common code side. AFAIK Oleksandr is 
> >>> targeting Arm platform. If so, I think this would require more work than 
> >>> this series. Arm code still miss few bits properly suspend/resume arch 
> >>> specific code (see [2]).
> >>>
> >>> I have a branch on my git to track the series. However, they never have 
> >>> been resent after Ian Campbell left Citrix. I would be happy to review 
> >>> them if someone wants to pick them up and repost them.
> >>>
> >> First of all, let me make it clear that we are interested in hibernation 
> >> long term, so it would be
> >> desirable to re-use as much work form resume/suspend as we can. But, we 
> >> see it as a step by
> >> step work, e.g. first S2RAM and later on hibernation.
> >> Let me clarify the immediate use-case that we have, so it is easier to 
> >> understand what we want
> >> and what we don't at the moment. We are about to continue work started by 
> >> Mirela/Xilinx on
> >> Suspend-to-RAM for ARM [3] and we made number of assumptions:
> >> 1. We are talking about *system* suspend, e.g. the goal is to suspend all 
> >> the components
> >> of the system and Xen itself at once. Think about this as fast-boot and/or 
> >> energy saving
> >> feature if you will.
> >> 2. With suspend/resume there is no intention to migrate VMs to any other 
> >> host.
> >> 3. Most probably configuration of the back/front won't change between 
> >> suspend/resume.
> >> But long term we are also thinking for supporting suspend/resu

Re: [Xen-devel] [PATCH v1] x86/microcode: always collect_cpu_info() during boot

[Jan Beulich]

>>> On 25.03.19 at 12:12,  wrote:
> Currently cpu_sig struct is not updated during boot when either:
> 
> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
> 2. initrd does not contain a microcode blob

What about "ucode="?

> These will result in cpu_sig.rev being 0 which affects APIC's
> check_deadline_errata() and retpoline_safe() functions.
> 
> Fix this by getting ucode revision early during boot and SMP bring up.

Can't you then drop the call from microcode_update_cpu()?

> @@ -413,6 +421,8 @@ int __init early_microcode_update_cpu(bool start_update)
>  
>  int __init early_microcode_init(void)
>  {
> +unsigned int cpu = smp_processor_id();
> +struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);

Would you mind moving these declarations ...

> @@ -425,6 +435,8 @@ int __init early_microcode_init(void)
>  
>  if ( microcode_ops )
>  {
> +microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);

... into this scope?

Jan



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

Re: [Xen-devel] Xen 4.12.0-rc Hangs Around masked ExtINT on CPU#

[John L. Poole]

On 3/25/2019 8:53 AM, Jan Beulich wrote:

On 22.03.19 at 10:53,  wrote:

2) Xen Source - here is the log of an attempt adding "cpuinfor maxcpus=1"
as an option in myman_xen.cfg:
https://pastebin.com/ifHZqCuX (6months)

Well, the "maxcpus=1" doesn't really hide the issue (anymore) because
we now bring up all secondary processors despite this option (and then
park them because of the option). But other than for 1) (yet like for 3))
two of the secondary processors get brought up fine here. Could you
check whether this is random, i.e. whether with the same set of options
you observe varying or consistent mileage? In the latter case slowing
things further down might by another worthwhile experiment, all to get
a feel for whether we're dealing with some systematic issue in our code
or some timing issue.

Jan



I removed the "maxcpus=1" and attempted seven (7) boots.
There were minor variations, they do not seem to get
past the first additional processor.  Below is a summary.

Hang points at https://pastebin.com/9gab3fZm

293:
(XEN) [2019-03-25 16:31:47] 3.
(XEN) [2019-03-25 16:31:47] Asserting INIT.
(XEN) [2019-03-25 16:31:47] Waiting for send to finish...

604
(XEN) [2019-03-25 16:33:35] Asserting INIT.
(XEN) [2019-03-25 16:33:35] Waiting for send to finish...
(XEN) [2019-03-25 16:33:35] +Deasserting INIT.
(XEN) [2019-03-25 16:33:35] Waiting for send to finish...

915:
(XEN) [2019-03-25 16:35:12] 3.
(XEN) [2019-03-25 16:35:12] Asserting INIT.
(XEN) [2019-03-25 16:35:12] Waiting for send to finish...
(XEN) [2019-03-25 16:35:12] +Deasserting INIT.

1225:
(XEN) [2019-03-25 16:36:52] 3.
(XEN) [2019-03-25 16:36:52] Asserting INIT.
(XEN) [2019-03-25 16:36:52] Waiting for send to finish...

1538:
(XEN) [2019-03-25 16:38:23] 3.
(XEN) [2019-03-25 16:38:23] Asserting INIT.
(XEN) [2019-03-25 16:38:23] Waiting for send to finish...
(XEN) [2019-03-25 16:38:24] +Deasserting INIT.
(XEN) [2019-03-25 16:38:24] Waiting for send to finish...

1848:
(XEN) [2019-03-25 16:39:52] 3.
(XEN) [2019-03-25 16:39:52] Asserting INIT.
(XEN) [2019-03-25 16:39:52] Waiting for send to finish...

2159:
(XEN) [2019-03-25 16:41:19] 1.
(XEN) [2019-03-25 16:41:19] 2.
(XEN) [2019-03-25 16:41:19] 3.
(XEN) [2019-03-25 16:41:19] Asserting INIT.
(XEN) [2019-03-25 16:41:19] Waiting for send to finish...

-- John

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

[Xen-devel] [xen-unstable-smoke test] 134068: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  1316369dca610352cce3aaf76e90db1cce75ed9f
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z3 days
Testing same since   134068  2019-03-25 12:00:51 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Wei Liu 

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 1316369dca610352cce3aaf76e90db1cce75ed9f
Author: Andrew Cooper 
Date:   Fri Mar 22 11:12:28 2019 +

CI: Fix indentation in containerize script

The script is mostly indented with spaces, but there are three tabs.  Fix 
them
up to be consistent.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
(qemu changes not included)

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

[Xen-devel] [PATCH v1] install pkgconfig files into libdir

[Olaf Hering]

Most pkgconfig files contain a Libs: variable, which is either /usr/lib
or /usr/lib64. If a 32bit and a 64bit variant of xen libraries is
installed, the last one wins. As a result compiling for the other
bitsize will fail.

Instead of sharedir use libdir as install target. This matches both the
documentation and the expected result.

Signed-off-by: Olaf Hering 
---

I think this deserves a backport to relesed versions.


 config/Paths.mk.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/Paths.mk.in b/config/Paths.mk.in
index 8a518d5a5d..dc9d0c0353 100644
--- a/config/Paths.mk.in
+++ b/config/Paths.mk.in
@@ -58,4 +58,4 @@ XENFIRMWAREDIR   := @XENFIRMWAREDIR@
 XEN_CONFIG_DIR   := @XEN_CONFIG_DIR@
 XEN_SCRIPT_DIR   := @XEN_SCRIPT_DIR@
 
-PKG_INSTALLDIR   := ${SHAREDIR}/pkgconfig
+PKG_INSTALLDIR   := ${libdir}/pkgconfig

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

[Xen-devel] [PULL 7/7] trace-events: Fix attribution of trace points to source

[Stefan Hajnoczi]

From: Markus Armbruster 

Some trace points are attributed to the wrong source file.  Happens
when we neglect to update trace-events for code motion, or add events
in the wrong place, or misspell the file name.

Clean up with help of cleanup-trace-events.pl.  Same funnies as in the
previous commit, of course.  Manually shorten its change to
linux-user/trace-events to */signal.c.

Signed-off-by: Markus Armbruster 
Message-id: 20190314180929.27722-6-arm...@redhat.com
Message-Id: <20190314180929.27722-6-arm...@redhat.com>
Signed-off-by: Stefan Hajnoczi 
---
 authz/trace-events   |  2 +-
 hw/9pfs/trace-events |  2 +-
 hw/arm/trace-events  |  4 ++--
 hw/block/trace-events|  3 ++-
 hw/char/trace-events |  2 +-
 hw/display/trace-events  |  3 ++-
 hw/ide/trace-events  |  6 --
 hw/input/trace-events|  2 +-
 hw/misc/trace-events |  8 +---
 hw/net/trace-events  |  8 
 hw/ppc/trace-events  |  6 +-
 hw/timer/trace-events|  4 ++--
 hw/vfio/trace-events |  2 +-
 hw/watchdog/trace-events |  2 +-
 linux-user/trace-events  |  1 +
 migration/trace-events   | 44 
 trace-events | 11 ++
 ui/trace-events  |  5 +
 util/trace-events|  6 +++---
 19 files changed, 78 insertions(+), 43 deletions(-)

diff --git a/authz/trace-events b/authz/trace-events
index 5cb577061c..e62ebb36b7 100644
--- a/authz/trace-events
+++ b/authz/trace-events
@@ -14,5 +14,5 @@ qauthz_list_default_policy(void *authz, const char *identity, 
int policy) "AuthZ
 qauthz_list_file_load(void *authz, const char *filename) "AuthZ file %p load 
filename=%s"
 qauthz_list_file_refresh(void *authz, const char *filename, int success) 
"AuthZ file %p load filename=%s success=%d"
 
-# pam.c
+# pamacct.c
 qauthz_pam_check(void *authz, const char *identity, const char *service) 
"AuthZ PAM %p identity=%s service=%s"
diff --git a/hw/9pfs/trace-events b/hw/9pfs/trace-events
index 0c14bda178..c0a0a4ab5d 100644
--- a/hw/9pfs/trace-events
+++ b/hw/9pfs/trace-events
@@ -1,6 +1,6 @@
 # See docs/devel/tracing.txt for syntax documentation.
 
-# virtio-9p.c
+# 9p.c
 v9fs_rcancel(uint16_t tag, uint8_t id) "tag %d id %d"
 v9fs_rerror(uint16_t tag, uint8_t id, int err) "tag %d id %d err %d"
 v9fs_version(uint16_t tag, uint8_t id, int32_t msize, char* version) "tag %d 
id %d msize %d version %s"
diff --git a/hw/arm/trace-events b/hw/arm/trace-events
index 441d12df5e..0acedcedc6 100644
--- a/hw/arm/trace-events
+++ b/hw/arm/trace-events
@@ -10,8 +10,6 @@ smmu_ptw_invalid_pte(int stage, int level, uint64_t baseaddr, 
uint64_t pteaddr,
 smmu_ptw_page_pte(int stage, int level,  uint64_t iova, uint64_t baseaddr, 
uint64_t pteaddr, uint64_t pte, uint64_t address) "stage=%d level=%d 
iova=0x%"PRIx64" base@=0x%"PRIx64" pte@=0x%"PRIx64" pte=0x%"PRIx64" page 
address = 0x%"PRIx64
 smmu_ptw_block_pte(int stage, int level, uint64_t baseaddr, uint64_t pteaddr, 
uint64_t pte, uint64_t iova, uint64_t gpa, int bsize_mb) "stage=%d level=%d 
base@=0x%"PRIx64" pte@=0x%"PRIx64" pte=0x%"PRIx64" iova=0x%"PRIx64" block 
address = 0x%"PRIx64" block size = %d MiB"
 smmu_get_pte(uint64_t baseaddr, int index, uint64_t pteaddr, uint64_t pte) 
"baseaddr=0x%"PRIx64" index=0x%x, pteaddr=0x%"PRIx64", pte=0x%"PRIx64
-smmu_iotlb_cache_hit(uint16_t asid, uint64_t addr, uint32_t hit, uint32_t 
miss, uint32_t p) "IOTLB cache HIT asid=%d addr=0x%"PRIx64" hit=%d miss=%d hit 
rate=%d"
-smmu_iotlb_cache_miss(uint16_t asid, uint64_t addr, uint32_t hit, uint32_t 
miss, uint32_t p) "IOTLB cache MISS asid=%d addr=0x%"PRIx64" hit=%d miss=%d hit 
rate=%d"
 smmu_iotlb_inv_all(void) "IOTLB invalidate all"
 smmu_iotlb_inv_asid(uint16_t asid) "IOTLB invalidate asid=%d"
 smmu_iotlb_inv_iova(uint16_t asid, uint64_t addr) "IOTLB invalidate asid=%d 
addr=0x%"PRIx64
@@ -48,6 +46,8 @@ smmuv3_cmdq_tlbi_nh_va(int vmid, int asid, uint64_t addr, 
bool leaf) "vmid =%d a
 smmuv3_cmdq_tlbi_nh_vaa(int vmid, uint64_t addr) "vmid =%d addr=0x%"PRIx64
 smmuv3_cmdq_tlbi_nh(void) ""
 smmuv3_cmdq_tlbi_nh_asid(uint16_t asid) "asid=%d"
+smmu_iotlb_cache_hit(uint16_t asid, uint64_t addr, uint32_t hit, uint32_t 
miss, uint32_t p) "IOTLB cache HIT asid=%d addr=0x%"PRIx64" hit=%d miss=%d hit 
rate=%d"
+smmu_iotlb_cache_miss(uint16_t asid, uint64_t addr, uint32_t hit, uint32_t 
miss, uint32_t p) "IOTLB cache MISS asid=%d addr=0x%"PRIx64" hit=%d miss=%d hit 
rate=%d"
 smmuv3_config_cache_inv(uint32_t sid) "Config cache INV for sid %d"
 smmuv3_notify_flag_add(const char *iommu) "ADD SMMUNotifier node for iommu 
mr=%s"
 smmuv3_notify_flag_del(const char *iommu) "DEL SMMUNotifier node for iommu 
mr=%s"
diff --git a/hw/block/trace-events b/hw/block/trace-events
index 780416c13f..b92039a573 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -4,7 +4,8 @@
 fdc_ioport_read(uint8_t reg, uint8_t value) "read reg 0x%02x val 0x%02x"
 fdc_ioport_write(uint8_t reg, uint8_t value) "write reg 0x%02x val 0x%02x"
 
-# pflash

[Xen-devel] [PULL 5/7] scripts/cleanup-trace-events: Update for current practice

[Stefan Hajnoczi]

From: Markus Armbruster 

Emit comments with shortened file names (previous commit).

Limit search to the input file's directory.

Cope with properties tcg (commit b2b36c22bd8) and vcpu (commit
3d211d9f4db).

Cope with capital letters in function names.

Signed-off-by: Markus Armbruster 
Message-id: 20190314180929.27722-4-arm...@redhat.com
Message-Id: <20190314180929.27722-4-arm...@redhat.com>
Signed-off-by: Stefan Hajnoczi 
---
 scripts/cleanup-trace-events.pl | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/scripts/cleanup-trace-events.pl b/scripts/cleanup-trace-events.pl
index e93abc00da..d4f0e4cab5 100755
--- a/scripts/cleanup-trace-events.pl
+++ b/scripts/cleanup-trace-events.pl
@@ -13,6 +13,7 @@
 
 use warnings;
 use strict;
+use File::Basename;
 
 my $buf = '';
 my %seen = ();
@@ -23,12 +24,19 @@ sub out {
 %seen = ();
 }
 
-while (<>) {
-if (/^(disable )?([a-z_0-9]+)\(/) {
-open GREP, '-|', 'git', 'grep', '-lw', "trace_$2"
+$#ARGV == 0 or die "usage: $0 FILE";
+my $in = $ARGV[0];
+my $dir = dirname($in);
+open(IN, $in) or die "open $in: $!";
+chdir($dir) or die "chdir $dir: $!";
+
+while () {
+if (/^(disable |(tcg) |vcpu )*([a-z_0-9]+)\(/i) {
+my $pat = "trace_$3";
+$pat .= '_tcg' if (defined $2);
+open GREP, '-|', 'git', 'grep', '-lw', '--max-depth', '1', $pat
 or die "run git grep: $!";
-my $fname;
-while ($fname = ) {
+while (my $fname = ) {
 chomp $fname;
 next if $seen{$fname} || $fname eq 'trace-events';
 $seen{$fname} = 1;
@@ -49,3 +57,4 @@ while (<>) {
 }
 
 out;
+close(IN) or die "close $in: $!";
-- 
2.20.1


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

[Xen-devel] [PULL 3/7] trace-events: Consistently point to docs/devel/tracing.txt

[Stefan Hajnoczi]

From: Markus Armbruster 

Almost all trace-events point to docs/devel/tracing.txt in a comment
right at the beginning.  Touch up the ones that don't.

[Updated with Markus' new commit description wording.
--Stefan]

Signed-off-by: Markus Armbruster 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20190314180929.27722-2-arm...@redhat.com
Message-Id: <20190314180929.27722-2-arm...@redhat.com>
Signed-off-by: Stefan Hajnoczi 
---
 accel/kvm/trace-events   | 2 +-
 accel/tcg/trace-events   | 2 +-
 hw/i386/xen/trace-events | 2 ++
 nbd/trace-events | 2 ++
 qapi/trace-events| 2 ++
 scsi/trace-events| 2 ++
 trace-events | 2 +-
 7 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/accel/kvm/trace-events b/accel/kvm/trace-events
index 8841025d68..33c5b1b3af 100644
--- a/accel/kvm/trace-events
+++ b/accel/kvm/trace-events
@@ -1,4 +1,4 @@
-# Trace events for debugging and performance instrumentation
+# See docs/devel/tracing.txt for syntax documentation.
 
 # kvm-all.c
 kvm_ioctl(int type, void *arg) "type 0x%x, arg %p"
diff --git a/accel/tcg/trace-events b/accel/tcg/trace-events
index c22ad60af7..01852217a6 100644
--- a/accel/tcg/trace-events
+++ b/accel/tcg/trace-events
@@ -1,4 +1,4 @@
-# Trace events for debugging and performance instrumentation
+# See docs/devel/tracing.txt for syntax documentation.
 
 # TCG related tracing (mostly disabled by default)
 # cpu-exec.c
diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
index 8a9077cd4e..8732741541 100644
--- a/hw/i386/xen/trace-events
+++ b/hw/i386/xen/trace-events
@@ -1,3 +1,5 @@
+# See docs/devel/tracing.txt for syntax documentation.
+
 # hw/i386/xen/xen_platform.c
 xen_platform_log(char *s) "xen platform: %s"
 
diff --git a/nbd/trace-events b/nbd/trace-events
index 7f10ebd4e0..6db8375c3e 100644
--- a/nbd/trace-events
+++ b/nbd/trace-events
@@ -1,3 +1,5 @@
+# See docs/devel/tracing.txt for syntax documentation.
+
 # nbd/client.c
 nbd_send_option_request(uint32_t opt, const char *name, uint32_t len) "Sending 
option request %" PRIu32" (%s), len %" PRIu32
 nbd_receive_option_reply(uint32_t option, const char *optname, uint32_t type, 
const char *typename, uint32_t length) "Received option reply %" PRIu32" (%s), 
type %" PRIu32" (%s), len %" PRIu32
diff --git a/qapi/trace-events b/qapi/trace-events
index 70e049ea80..b123c5e302 100644
--- a/qapi/trace-events
+++ b/qapi/trace-events
@@ -1,3 +1,5 @@
+# See docs/devel/tracing.txt for syntax documentation.
+
 # qapi/qapi-visit-core.c
 visit_free(void *v) "v=%p"
 visit_complete(void *v, void *opaque) "v=%p opaque=%p"
diff --git a/scsi/trace-events b/scsi/trace-events
index f8a68b11eb..499098e50b 100644
--- a/scsi/trace-events
+++ b/scsi/trace-events
@@ -1,3 +1,5 @@
+# See docs/devel/tracing.txt for syntax documentation.
+
 # scsi/pr-manager.c
 pr_manager_execute(int fd, int cmd, int sa) "fd=%d cmd=0x%02x service 
action=0x%02x"
 pr_manager_run(int fd, int cmd, int sa) "fd=%d cmd=0x%02x service 
action=0x%02x"
diff --git a/trace-events b/trace-events
index e66afc59e9..b48f417225 100644
--- a/trace-events
+++ b/trace-events
@@ -1,4 +1,4 @@
-# Trace events for debugging and performance instrumentation
+# See docs/devel/tracing.txt for syntax documentation.
 #
 # This file is processed by the tracetool script during the build.
 #
-- 
2.20.1


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

[Xen-devel] [PULL 2/7] trace: avoid SystemTap dtrace(1) warnings on empty files

[Stefan Hajnoczi]

target/hppa/trace-events only contains disabled events, resulting in a
trace-dtrace.dtrace file that says "provider qemu {}".  SystemTap's
dtrace(1) tool prints a warning when processing this input file.

This patch avoids the error by emitting an empty file instead of
"provider qemu {}" when there are no enabled trace events.

Fixes: 23c3d569f44284066714ff7c46bc4f19e630583f ("target/hppa: add TLB trace 
events")
Reported-by: Markus Armbruster 
Signed-off-by: Stefan Hajnoczi 
Reviewed-by: Markus Armbruster 
Reviewed-by: Liam Merwick 
Message-id: 20190321170831.6539-3-stefa...@redhat.com
Message-Id: <20190321170831.6539-3-stefa...@redhat.com>
Signed-off-by: Stefan Hajnoczi 
---
 scripts/tracetool/format/d.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/scripts/tracetool/format/d.py b/scripts/tracetool/format/d.py
index 78397c24d2..c7cb2a93a6 100644
--- a/scripts/tracetool/format/d.py
+++ b/scripts/tracetool/format/d.py
@@ -33,6 +33,11 @@ def generate(events, backend, group):
 events = [e for e in events
   if "disable" not in e.properties]
 
+# SystemTap's dtrace(1) warns about empty "provider qemu {}" but is happy
+# with an empty file.  Avoid the warning.
+if not events:
+return
+
 out('/* This file is autogenerated by tracetool, do not edit. */'
 '',
 'provider qemu {')
-- 
2.20.1


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

[Xen-devel] [PULL 1/7] trace: handle tracefs path truncation

[Stefan Hajnoczi]

If the tracefs mountpoint has a very long path we may exceed PATH_MAX.
This is a system misconfiguration and the user must resolve it so that
applications can perform path-based system calls successfully.

This issue does not occur on real-world systems since tracefs is mounted
on /sys/kernel/debug/tracing/, but the compiler is smart enough to
foresee the possibility and warn about the unchecked snprintf(3) return
value.  This patch fixes the compiler warning.

Reported-by: Markus Armbruster 
Signed-off-by: Stefan Hajnoczi 
Reviewed-by: Markus Armbruster 
Reviewed-by: Liam Merwick 
Message-id: 20190321170831.6539-2-stefa...@redhat.com
Message-Id: <20190321170831.6539-2-stefa...@redhat.com>
Signed-off-by: Stefan Hajnoczi 
---
 trace/ftrace.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/trace/ftrace.c b/trace/ftrace.c
index 61692a8682..9749543d9b 100644
--- a/trace/ftrace.c
+++ b/trace/ftrace.c
@@ -53,7 +53,11 @@ bool ftrace_init(void)
 }
 
 if (tracefs_found) {
-snprintf(path, PATH_MAX, "%s%s/tracing_on", mount_point, subdir);
+if (snprintf(path, PATH_MAX, "%s%s/tracing_on", mount_point, subdir)
+>= sizeof(path)) {
+fprintf(stderr, "Using tracefs mountpoint would exceed 
PATH_MAX\n");
+return false;
+}
 trace_fd = open(path, O_WRONLY);
 if (trace_fd < 0) {
 if (errno == EACCES) {
@@ -72,7 +76,11 @@ bool ftrace_init(void)
 }
 close(trace_fd);
 }
-snprintf(path, PATH_MAX, "%s%s/trace_marker", mount_point, subdir);
+if (snprintf(path, PATH_MAX, "%s%s/trace_marker", mount_point, subdir)
+>= sizeof(path)) {
+fprintf(stderr, "Using tracefs mountpoint would exceed 
PATH_MAX\n");
+return false;
+}
 trace_marker_fd = open(path, O_WRONLY);
 if (trace_marker_fd < 0) {
 perror("Could not open ftrace 'trace_marker' file");
-- 
2.20.1


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

[Xen-devel] [PULL 6/7] trace-events: Delete unused trace points

[Stefan Hajnoczi]

From: Markus Armbruster 

Tracked down with cleanup-trace-events.pl.  Funnies requiring manual
post-processing:

* block.c and blockdev.c trace points are in block/trace-events.

* hw/block/nvme.c uses the preprocessor to hide its trace point use
  from cleanup-trace-events.pl.

* include/hw/xen/xen_common.h trace points are in hw/xen/trace-events.

* net/colo-compare and net/filter-rewriter.c use pseudo trace points
  colo_compare_udp_miscompare and colo_filter_rewriter_debug to guard
  debug code.

Signed-off-by: Markus Armbruster 
Message-id: 20190314180929.27722-5-arm...@redhat.com
Message-Id: <20190314180929.27722-5-arm...@redhat.com>
Signed-off-by: Stefan Hajnoczi 
---
 block/trace-events | 1 -
 hw/arm/trace-events| 7 ---
 hw/block/trace-events  | 2 --
 hw/display/trace-events| 1 -
 hw/i386/trace-events   | 2 --
 hw/ide/trace-events| 1 -
 hw/intc/trace-events   | 1 -
 hw/misc/macio/trace-events | 1 -
 hw/misc/trace-events   | 2 --
 hw/ppc/trace-events| 8 
 hw/sd/trace-events | 1 -
 hw/vfio/trace-events   | 1 -
 nbd/trace-events   | 2 --
 util/trace-events  | 2 --
 14 files changed, 32 deletions(-)

diff --git a/block/trace-events b/block/trace-events
index 28b6364f28..e6bb5a8f05 100644
--- a/block/trace-events
+++ b/block/trace-events
@@ -57,7 +57,6 @@ qmp_block_stream(void *bs, void *job) "bs %p job %p"
 
 # file-posix.c
 # file-win32.c
-file_paio_submit_co(int64_t offset, int count, int type) "offset %"PRId64" 
count %d type %d"
 file_paio_submit(void *acb, void *opaque, int64_t offset, int count, int type) 
"acb %p opaque %p offset %"PRId64" count %d type %d"
 file_copy_file_range(void *bs, int src, int64_t src_off, int dst, int64_t 
dst_off, int64_t bytes, int flags, int64_t ret) "bs %p src_fd %d offset 
%"PRIu64" dst_fd %d offset %"PRIu64" bytes %"PRIu64" flags %d ret %"PRId64
 
diff --git a/hw/arm/trace-events b/hw/arm/trace-events
index 3e91ca37a9..441d12df5e 100644
--- a/hw/arm/trace-events
+++ b/hw/arm/trace-events
@@ -5,8 +5,6 @@ virt_acpi_setup(void) "No fw cfg or ACPI disabled. Bailing out."
 
 # smmu-common.c
 smmu_add_mr(const char *name) "%s"
-smmu_page_walk(int stage, uint64_t baseaddr, int first_level, uint64_t start, 
uint64_t end) "stage=%d, baseaddr=0x%"PRIx64", first level=%d, 
start=0x%"PRIx64", end=0x%"PRIx64
-smmu_lookup_table(int level, uint64_t baseaddr, int granule_sz, uint64_t 
start, uint64_t end, int flags, uint64_t subpage_size) "level=%d 
baseaddr=0x%"PRIx64" granule=%d, start=0x%"PRIx64" end=0x%"PRIx64" flags=%d 
subpage_size=0x%"PRIx64
 smmu_ptw_level(int level, uint64_t iova, size_t subpage_size, uint64_t 
baseaddr, uint32_t offset, uint64_t pte) "level=%d iova=0x%"PRIx64" 
subpage_sz=0x%zx baseaddr=0x%"PRIx64" offset=%d => pte=0x%"PRIx64
 smmu_ptw_invalid_pte(int stage, int level, uint64_t baseaddr, uint64_t 
pteaddr, uint32_t offset, uint64_t pte) "stage=%d level=%d base@=0x%"PRIx64" 
pte@=0x%"PRIx64" offset=%d pte=0x%"PRIx64
 smmu_ptw_page_pte(int stage, int level,  uint64_t iova, uint64_t baseaddr, 
uint64_t pteaddr, uint64_t pte, uint64_t address) "stage=%d level=%d 
iova=0x%"PRIx64" base@=0x%"PRIx64" pte@=0x%"PRIx64" pte=0x%"PRIx64" page 
address = 0x%"PRIx64
@@ -29,12 +27,7 @@ smmuv3_cmdq_consume(uint32_t prod, uint32_t cons, uint8_t 
prod_wrap, uint8_t con
 smmuv3_cmdq_opcode(const char *opcode) "<--- %s"
 smmuv3_cmdq_consume_out(uint32_t prod, uint32_t cons, uint8_t prod_wrap, 
uint8_t cons_wrap) "prod:%d, cons:%d, prod_wrap:%d, cons_wrap:%d "
 smmuv3_cmdq_consume_error(const char *cmd_name, uint8_t cmd_error) "Error on 
%s command execution: %d"
-smmuv3_update(bool is_empty, uint32_t prod, uint32_t cons, uint8_t prod_wrap, 
uint8_t cons_wrap) "q empty:%d prod:%d cons:%d p.wrap:%d p.cons:%d"
-smmuv3_update_check_cmd(int error) "cmdq not enabled or error :0x%x"
 smmuv3_write_mmio(uint64_t addr, uint64_t val, unsigned size, uint32_t r) 
"addr: 0x%"PRIx64" val:0x%"PRIx64" size: 0x%x(%d)"
-smmuv3_write_mmio_idr(uint64_t addr, uint64_t val) "write to RO/Unimpl reg 
0x%"PRIx64" val64:0x%"PRIx64
-smmuv3_write_mmio_evtq_cons_bef_clear(uint32_t prod, uint32_t cons, uint8_t 
prod_wrap, uint8_t cons_wrap) "Before clearing interrupt prod:0x%x cons:0x%x 
prod.w:%d cons.w:%d"
-smmuv3_write_mmio_evtq_cons_after_clear(uint32_t prod, uint32_t cons, uint8_t 
prod_wrap, uint8_t cons_wrap) "after clearing interrupt prod:0x%x cons:0x%x 
prod.w:%d cons.w:%d"
 smmuv3_record_event(const char *type, uint32_t sid) "%s sid=%d"
 smmuv3_find_ste(uint16_t sid, uint32_t features, uint16_t sid_split) "SID:0x%x 
features:0x%x, sid_split:0x%x"
 smmuv3_find_ste_2lvl(uint64_t strtab_base, uint64_t l1ptr, int l1_ste_offset, 
uint64_t l2ptr, int l2_ste_offset, int max_l2_ste) "strtab_base:0x%"PRIx64" 
l1ptr:0x%"PRIx64" l1_off:0x%x, l2ptr:0x%"PRIx64" l2_off:0x%x max_l2_ste:%d"
diff --git a/hw/block/trace-events b/hw/block/trace-events
index 239753c92b..780416c13f 100644
--- a/hw/block/trace-events
+++ b/h

[Xen-devel] [PULL 0/7] Tracing patches

[Stefan Hajnoczi]

The following changes since commit d97a39d903fe33c45be83ac6943a2f82a3649a11:

  Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' 
into staging (2019-03-22 09:37:38 +)

are available in the Git repository at:

  git://github.com/stefanha/qemu.git tags/tracing-pull-request

for you to fetch changes up to dec9776049e32d6c830127b286530c5f53267eff:

  trace-events: Fix attribution of trace points to source (2019-03-22 16:18:07 
+)


Pull request

Compilation fixes and cleanups for QEMU 4.0.0.



Markus Armbruster (5):
  trace-events: Consistently point to docs/devel/tracing.txt
  trace-events: Shorten file names in comments
  scripts/cleanup-trace-events: Update for current practice
  trace-events: Delete unused trace points
  trace-events: Fix attribution of trace points to source

Stefan Hajnoczi (2):
  trace: handle tracefs path truncation
  trace: avoid SystemTap dtrace(1) warnings on empty files

 trace/ftrace.c  | 12 +-
 accel/kvm/trace-events  |  2 +-
 accel/tcg/trace-events  |  2 +-
 audio/trace-events  |  6 +--
 authz/trace-events  | 10 ++---
 block/trace-events  | 49 +++
 chardev/trace-events|  4 +-
 crypto/trace-events | 10 ++---
 hw/9pfs/trace-events|  2 +-
 hw/acpi/trace-events|  6 +--
 hw/alpha/trace-events   |  2 +-
 hw/arm/trace-events | 17 +++-
 hw/audio/trace-events   |  6 +--
 hw/block/dataplane/trace-events |  2 +-
 hw/block/trace-events   | 15 ---
 hw/char/trace-events| 24 +--
 hw/display/trace-events | 28 ++---
 hw/dma/trace-events |  6 +--
 hw/gpio/trace-events|  2 +-
 hw/hppa/trace-events|  2 +-
 hw/i2c/trace-events |  2 +-
 hw/i386/trace-events| 10 ++---
 hw/i386/xen/trace-events|  6 ++-
 hw/ide/trace-events | 23 +--
 hw/input/trace-events   | 16 
 hw/intc/trace-events| 35 -
 hw/isa/trace-events |  4 +-
 hw/mem/trace-events |  4 +-
 hw/misc/macio/trace-events  |  9 ++---
 hw/misc/trace-events| 40 +--
 hw/net/trace-events | 42 ++--
 hw/nvram/trace-events   |  4 +-
 hw/pci-host/trace-events|  6 +--
 hw/pci/trace-events |  6 +--
 hw/ppc/trace-events | 40 +--
 hw/rdma/trace-events|  6 +--
 hw/rdma/vmw/trace-events|  8 ++--
 hw/s390x/trace-events   |  4 +-
 hw/scsi/trace-events| 22 +--
 hw/sd/trace-events  | 13 +++---
 hw/sparc/trace-events   |  6 +--
 hw/sparc64/trace-events |  6 +--
 hw/timer/trace-events   | 24 +--
 hw/tpm/trace-events | 12 +++---
 hw/usb/trace-events | 22 +--
 hw/vfio/trace-events| 15 ---
 hw/virtio/trace-events  | 10 ++---
 hw/watchdog/trace-events|  2 +-
 hw/xen/trace-events |  6 +--
 io/trace-events | 12 +++---
 linux-user/trace-events |  3 +-
 migration/trace-events  | 70 ++---
 nbd/trace-events| 10 ++---
 net/trace-events| 10 ++---
 qapi/trace-events   |  4 +-
 qom/trace-events|  2 +-
 scripts/cleanup-trace-events.pl | 19 ++---
 scripts/tracetool/format/d.py   |  5 +++
 scsi/trace-events   |  4 +-
 target/arm/trace-events |  4 +-
 target/hppa/trace-events|  4 +-
 target/i386/trace-events|  4 +-
 target/mips/trace-events|  2 +-
 target/ppc/trace-events |  2 +-
 target/s390x/trace-events   | 10 ++---
 target/sparc/trace-events   |  8 ++--
 trace-events| 13 +-
 ui/trace-events | 19 +
 util/trace-events   | 28 ++---
 69 files changed, 438 insertions(+), 405 deletions(-)

-- 
2.20.1


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

Re: [Xen-devel] Xen 4.12.0-rc Hangs Around masked ExtINT on CPU#

[Jan Beulich]

>>> On 22.03.19 at 10:53,  wrote:
> 2) Xen Source - here is the log of an attempt adding "cpuinfor maxcpus=1"
> as an option in myman_xen.cfg:
> https://pastebin.com/ifHZqCuX (6months)

Well, the "maxcpus=1" doesn't really hide the issue (anymore) because
we now bring up all secondary processors despite this option (and then
park them because of the option). But other than for 1) (yet like for 3))
two of the secondary processors get brought up fine here. Could you
check whether this is random, i.e. whether with the same set of options
you observe varying or consistent mileage? In the latter case slowing
things further down might by another worthwhile experiment, all to get
a feel for whether we're dealing with some systematic issue in our code
or some timing issue.

Jan



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

Re: [Xen-devel] [PATCH for-4.12] passthrough/vtd: Drop the "workaround_bios_bug" logic entirely

[Jan Beulich]

>>> On 21.03.19 at 21:26,  wrote:
> It turns out that this code was previously dead.

If it was entirely dead, why the rush to get the change into 4.12?
(I suppose the later parts of description are then justifying why
the code wasn't actually dead, and why it was getting in the way,
but I think this way of putting it is at least confusing.)

> c/s dcf41790 " x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling
> acpi_parse_dmar()" resulted in PCI segment 0 now having been initialised
> enough for acpi_parse_one_drhd() to not take the
> 
>   /* Skip checking if segment is not accessible yet. */
> 
> path unconditionally.

Or am I misreading the initial sentence, and you're really suggesting
that prior to said commit the code in question had been dead? How's
that commit related then? Segment 0 is valid irrespective of any
MMCFG information gained from ACPI tables (see pci_segments_init()).

>  However, some systems have DMAR tables which list
> devices which are disabled by user choice (in particular, Dell PowerEdge R740
> with I/O AT DMA disabled), and turning off all IOMMU functionality in this
> case is entirely unhelpful behaviour.

As in many other cases, what is or is not unhelpful is often a matter
of perception and hence possibly subjective. I can see your point,
but I also can see why the authors of the code considered it a rather
bad sign if non-existing PCI devices get named by an ACPI table.
What if e.g. later a device gets hot-plugged into that very SBDF?

> Leave the warning which identifies the problematic devices, but drop the
> remaining logic.  This leaves the system in better overall state, and working
> in the same way that it did in previous releases.

I wonder whether you've taken the time to look at the description
of the commit first introducing this logic (a8059ffced "VT-d: improve
RMRR validity checking"). I find it worrying in particular to
effectively revert a change which claims 'to avoid any security
vulnerability with malicious s/s re-enabling "supposed disabled"
devices' without any discussion of why that may have been a
wrong perspective to take.

I'd also appreciate clarification on you saying "working in the same
way that it did in previous releases" - it sounds as if you might
have spotted a regression here, but it's not really becoming clear
to me what that regression then would have been.

> This is a candidate for 4.12.  Given the absense of Jan as the maintaner, and
> the proximity to the 4.12 release, I put this patch to The Rest for a
> hopefully-more-timely decision and review.

To be honest, I have two problems with this: For one the main
part of your change falls in Kevin's realm, not mine. And then,
even if it would have been mainly me to ack the change, I was
gone for three days, not three months. Yet the code had been
this way for over 9 years. One thing seems pretty clear to me:
It is at best non-obvious that there is no risk of regressions
here.

Much less risky changes have been rejected as coming too late
for 4.12. I don't think this should have been rushed into the
tree, and even less so for a release about to be cut. Especially
not without a proper maintainer ack.

The main reason why, at least for the moment, I'm not meaning
to officially request a revert is that I'm not sure the original
commit's description is fully correct and / or it was really
addressing some ia64-specific quirk.

Jan



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

Re: [Xen-devel] [PATCH 0/2] Remove support for deprecated %pf and %pF in vsprintf

[Andy Shevchenko]

On Mon, Mar 25, 2019 at 05:13:00PM +0200, Sakari Ailus wrote:

> All other invalid pointer conversion specifiers currently result into a
> warning only. I see that as an orthogonal change to this set. I found
> another issue in checkpatch.pl that may require some discussion; would you
> be ok with addressing this in another set?

If it looks better that way, I have no objection.

-- 
With Best Regards,
Andy Shevchenko



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

Re: [Xen-devel] [PATCH 0/2] Remove support for deprecated %pf and %pF in vsprintf

[Sakari Ailus]

Hi Andy,

On Sun, Mar 24, 2019 at 11:19:32PM +0200, Andy Shevchenko wrote:
> On Sun, Mar 24, 2019 at 11:10:08PM +0200, Sakari Ailus wrote:
> > On Fri, Mar 22, 2019 at 07:05:50PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 22, 2019 at 03:53:50PM +0200, Sakari Ailus wrote:
> > > 
> > > > Porting a patch
> > > > forward should have no issues either as checkpatch.pl has been 
> > > > complaining
> > > > of the use of %pf and %pF for a while now.
> > > 
> > > And that's exactly the reason why I think instead of removing warning on
> > > checkpatch, it makes sense to convert to an error for a while. People are
> > > tending read documentation on internet and thus might have outdated one. 
> > > And
> > > yes, the compiler doesn't tell a thing about it.
> > > 
> > > P.S. Though, if majority of people will tell that I'm wrong, then it's 
> > > okay to
> > > remove.
> > 
> > I wonder if you wrote this before seeing my other patchset.
> 
> Yes, I wrote it before seeing another series.
> 
> > What I think could be done is to warn of plain %pf (without following "w")
> > in checkpatch.pl, and %pf that is not followed by "w" in the kernel.
> > Although we didn't have such checks to begin with. The case is still a
> > little bit different as %pf used to be a valid conversion specifier whereas
> > %pO likely has never existed.
> > 
> > So, how about adding such checks in the other set? I can retain %p[fF] check
> > here, too, if you like.
> 
> Consistency tells me that the warning->error transformation in checkpatch.pl
> belongs this series.

All other invalid pointer conversion specifiers currently result into a
warning only. I see that as an orthogonal change to this set. I found
another issue in checkpatch.pl that may require some discussion; would you
be ok with addressing this in another set?

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

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

Re: [Xen-devel] [PATCH] CI: Add a CentOS 6 container and build jobs

[Andrew Cooper]

On 25/03/2019 11:33, Wei Liu wrote:
> On Mon, Mar 25, 2019 at 11:21:44AM +, Wei Liu wrote:
>> On Fri, Mar 22, 2019 at 11:13:40AM +, Andrew Cooper wrote:
>>> CentOS 6 is probably the most frequently broken build, so adding it to CI
>>> would be a very good move.
>>>
>>> One problem is that CentOS 6 comes with Python 2.6, and Qemu requires 2.7.
>>> There appear to be no sensible ways to get Python 2.7 into a CentOS 6
>>> environments, so modify the build script to skip the Qemu upstream build
>>> instead.
>>>
>>> Signed-off-by: Andrew Cooper 
>> Acked-by: Wei Liu 
> Just saw your thread on seabios list -- do you want to exclude seabios
> build in CentOS 6?

Yeah, but I'm not sure how best to do that.  Testing the version of GCC
isn't as easy as testing the version of python.

~Andrew

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

Re: [Xen-devel] [PATCH] xen/pv: Add PV specific legacy_pic struct to expose legacy IRQs.

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of 
> Jennifer Herbert
> Sent: 25 March 2019 14:24
> To: Boris Ostrovsky ; x...@kernel.org; 
> xen-devel@lists.xenproject.org;
> linux-ker...@vger.kernel.org
> Cc: Juergen Gross ; Stefano Stabellini 
> ; Ingo Molnar
> ; Borislav Petkov ; H. Peter Anvin 
> ; Thomas Gleixner
> 
> Subject: Re: [Xen-devel] [PATCH] xen/pv: Add PV specific legacy_pic struct to 
> expose legacy IRQs.
> 
> 
> 
> On 21/03/19 17:49, Jennifer Herbert wrote:
> >
> >
> > On 19/03/19 23:06, Boris Ostrovsky wrote:
> >> On 3/19/19 4:02 PM, Jennifer Herbert wrote:
> >>> The ACPI tables doesn't always contain all IRQs for legacy devices
> >>> such as RTC.  Since no PIC controller is visible for a PV linux guest,
> >>> under Xen, legacy_pic currently defaults to the null_legacy_pic - with
> >>> reports no legacy IRQs.  Since the commit "rtc: cmos: Do not assume
> >>> irq 8 for rtc when there are no legacy irqs" by Hans de Goede
> >>> (commit id: a1e23a42f1bdc00e32fc4869caef12e4e6272f26), the rtc now
> >>> incorrectly decides it has no irq it can use, for some hardware.
> >>>
> >>> This patch rectifies the problem by providing a xen legacy_pic
> >>> struct, which is much like the null_legacy_pic except that it
> >>> reports NR_IRQS_LEGACY irqs.
> >> I assume this is for dom0?
> >>
> >> Could there be the same problem with PVH dom0? (and if yes then this
> >> should probably go into arch/x86/xen/enlighten.c).
> >>
> >> -boris
> >>
> >
> > I am doing this to fix a problem with dom0.  DomU doesn't seem to have
> > an RTC, and so it is unaffected.
> >
> > I'm not familiar with PVH, but have now done some experiments. The RTC
> > on PVH seems broken - but not quite in the same way as PV. More
> > research is needed, however simply doing the same trick I did with PV
> > will not fix the issue.
> >
> > I'll look further into it.
> >
> 
> The same problem does exist with PVH - however its worse with the
> presence of the IO-APIC, as with my patch it tries to set up with IRQ,
> and fails.  I'm not sure how would be best to deal with this.
> However, the RTC seems broken even for machines without the ACPI omission.
> I can see fixing it for just PV doesn't seem too nice, but unsure how to
> fix this for PVH.  I'm open to suggestions, but otherwise I'll put this
> on hold.

AFAICT from the code in libxl__arch_domain_prepare_config(), PVH domains don't 
get an RTC, just a local APIC.

  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/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xen: Add "xen_timer_slop" command line option

[luca abeni]

Hi,

On Mon, 25 Mar 2019 09:43:20 -0400
Boris Ostrovsky  wrote:
[...]
> > http://retis.santannapisa.it/luca/XenTimers/
> > (there also is a link to the scripts to be used for reproducing the
> > results). The latencies have been measured by running cyclictest in
> > the guest (see the scripts for details).
> >
> > The picture shows the latencies measured with an unpatched guest
> > kernel and with a guest kernel having TIMER_SLOP set to 1000
> > (arbitrary small value :).
> > All the experiments have been performed booting the hypervisor with
> > a small timer_slop (the hypervisor's one) value. So, they show that
> > decreasing the hypervisor's timer_slop is not enough to measure low
> > latencies with cyclictest.  
> 
> 
> 
> I have a couple of questions:
> * Does it make sense to make this a tunable for other clockevent
> devices as well?
> * This patch adjusts min value. Could max value (ever) need a similar
> adjustment?

Sorry, I do not know much about clockevent devices, so I have no answers
to these questions...

What I can say is that when I repeated the cyclictest experiments on
VMs using a different clockevent device (lapic) I did not measure large
latencies.
So, I guess the "lapic" clockevent device already defaults to a smaller
min value (not sure about other clockevent devices, I do not know how
to test them).



Luca

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

Re: [Xen-devel] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

[Igor Druzhinin]

On 24/03/2019 03:50, Roger Pau Monné wrote:
> On Fri, Mar 22, 2019 at 10:06:45AM +0100, Laszlo Ersek wrote:
>> The core PciBusDxe driver that is built into OVMF certainly does the
>> resource allocation/placement, but when OVMF is executed on Xen, this
>> functionality of PciBusDxe is dynamically disabled by setting
>> PcdPciDisableBusEnumeration to TRUE. (I'm not saying this is right vs.
>> wrong, just that it happens.)
>>
>> Note that OVMF itself checks PcdPciDisableBusEnumeration for many things
>> (just grep OvmfPkg to see), so if we were to flip the PCD while running
>> on Xen, it would change the behavior of OVMF on Xen in a number of
>> areas. Can't offer a deeper treatise for now; all the related source
>> code locations would have to be audited (likely with "git blame" too).
>>
>> Now, if PciBusDxe *is* allowed/requested to lay out the BARs, through
>> the PCD, then it (indirectly) depends on platform code to provide the
>> resource apertures -- of the root bridges -- out of which it can
>> allocate the BARs. My understanding is that XenSupport.c tries to detect
>> these apertures "retroactively", from the pre-existing BAR placements.
>> This was contributed by Ray in commit 49effaf26ec9
>> ("OvmfPkg/PciHostBridgeLib: Scan for root bridges when running over
>> Xen", 2016-05-11), so I'll have to defer to him on the code.
>>
>> I believe that, if we flipped the PCD to FALSE on Xen, and hvmloader
>> would stop pre-configuring the BARs (or OVMF would simply ignore that
>> pre-config), then this code (XenSupport.c) should be possible to
>> eliminate -- *however*, in that case, some other Xen-specific code would
>> become necessary, to expose the root bridge resource apertures (out of
>> which BARs should be allocated by PciBusDxe, see above).
>>
>> In QEMU's case: all root bridges share the same apertures between each
>> other (given any specific resource type). They are communicated via
>> dynamic PCDs. The 32-bit MMIO aperture PCDs are set in PlatformPei
>> somewhat simply (based on QEMU machine type, IIRC). The 64-bit MMIO
>> aperture PCDs are also calculated in PlatformPei, but that calculation
>> is a *lot* more complex.
>>
>> All in all, the "root" information is the set of apertures, i.e. what
>> parts of the GPA space can be used for what resource allocation.
> 
> Thanks for the detailed explanation. IMO it would be better to let
> OVMF do the BAR placement instead of having to do it in hvmloader,
> this just causes code duplication between projects and there's nothing
> Xen-specific about the PCI resource allocation.
> 
> I will try to find some time to look into this, albeit I'm not going
> to be able to work in this immediately. I'm more than happy if someone
> else has spare time and wants to pick this up.

I was thinking about that as well since most of the issues I found stem
from the fact hvmloader does its own things behind OVMF's back. But
decided that for now it'd be better to have a quick relief than try to
change the approach drastically as Laszlo pointed out there are many
implications of that change.

So for this patch I prefer to stick to removing only prefetchable
aperture all together (as dead code) and marking the host bridge as not
supporting it (as Laszlo suggested) since it reflects the reality and
done similarly for QEMU-KVM. More code removals and changes could be
done later.

Igor

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

Re: [Xen-devel] [PATCH] xen/pv: Add PV specific legacy_pic struct to expose legacy IRQs.

[Jennifer Herbert]

On 21/03/19 17:49, Jennifer Herbert wrote:



On 19/03/19 23:06, Boris Ostrovsky wrote:

On 3/19/19 4:02 PM, Jennifer Herbert wrote:

The ACPI tables doesn't always contain all IRQs for legacy devices
such as RTC.  Since no PIC controller is visible for a PV linux guest,
under Xen, legacy_pic currently defaults to the null_legacy_pic - with
reports no legacy IRQs.  Since the commit "rtc: cmos: Do not assume
irq 8 for rtc when there are no legacy irqs" by Hans de Goede
(commit id: a1e23a42f1bdc00e32fc4869caef12e4e6272f26), the rtc now
incorrectly decides it has no irq it can use, for some hardware.

This patch rectifies the problem by providing a xen legacy_pic
struct, which is much like the null_legacy_pic except that it
reports NR_IRQS_LEGACY irqs.

I assume this is for dom0?

Could there be the same problem with PVH dom0? (and if yes then this
should probably go into arch/x86/xen/enlighten.c).

-boris



I am doing this to fix a problem with dom0.  DomU doesn't seem to have 
an RTC, and so it is unaffected.


I'm not familiar with PVH, but have now done some experiments. The RTC 
on PVH seems broken - but not quite in the same way as PV. More 
research is needed, however simply doing the same trick I did with PV 
will not fix the issue.


I'll look further into it.



The same problem does exist with PVH - however its worse with the 
presence of the IO-APIC, as with my patch it tries to set up with IRQ, 
and fails.  I'm not sure how would be best to deal with this.

However, the RTC seems broken even for machines without the ACPI omission.
I can see fixing it for just PV doesn't seem too nice, but unsure how to 
fix this for PVH.  I'm open to suggestions, but otherwise I'll put this 
on hold.





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

[Xen-devel] [linux-4.4 test] 134041: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64   4 host-install(4)broken REGR. vs. 133468
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133468
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 133468

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   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-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-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-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-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-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-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-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-qemut-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-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
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux6b50202a4d53bf527c640467bcff68b50a5e38a2
baseline version:
 linuxaf13f

Re: [Xen-devel] [PATCH] x86/xen: Add "xen_timer_slop" command line option

[Ryan Thibodeaux]

On Mon, Mar 25, 2019 at 09:43:20AM -0400, Boris Ostrovsky wrote:
> On 3/25/19 8:05 AM, luca abeni wrote:
> > Hi all,
> >
> > On Sat, 23 Mar 2019 11:41:51 +0100
> > luca abeni  wrote:
> > [...]
>  Is there any data that shows effects of using this new parameter?
>  
> >>> Yes, I've done some research and experiments on this. I did it
> >>> together with a friend, which I'm Cc-ing, as I'm not sure we're
> >>> ready/capable to share the results, yet (Luca?).  
> >> I think we can easily share the experimental data (cyclictest output
> >> and plots).
> >>
> >> Moreover, we can share the scripts and tools for running the
> >> experiments (so, everyone can easily reproduce the numbers by simply
> >> typing "make" and waiting for some time :)
> >>
> >>
> >> I'll try to package the results and the scripts/tools this evening,
> >> and I'll send them.
> > Sorry for the delay. I put some quick results here:
> > http://retis.santannapisa.it/luca/XenTimers/
> > (there also is a link to the scripts to be used for reproducing the
> > results). The latencies have been measured by running cyclictest in the
> > guest (see the scripts for details).
> >
> > The picture shows the latencies measured with an unpatched guest kernel
> > and with a guest kernel having TIMER_SLOP set to 1000 (arbitrary small
> > value :).
> > All the experiments have been performed booting the hypervisor with a
> > small timer_slop (the hypervisor's one) value. So, they show that
> > decreasing the hypervisor's timer_slop is not enough to measure low
> > latencies with cyclictest.
> 
> 
> 
> I have a couple of questions:
> * Does it make sense to make this a tunable for other clockevent devices
> as well?

I gather that would be on a case-by-case basis for very specific 
ones.

For many timers in the kernel, the minimums are determined by the
actual hardware  backing the timer, and the minimum can be
adjusted by the clockevent code. This case is special since it 
is entirely a software-based implementation in the kernel, where 
the actual timer implementation is in the Xen hypervisor.

> * This patch adjusts min value. Could max value (ever) need a similar
> adjustment?

I cannot think of such a case where that would be helpful, but I
cannot rule that out or speak as an authority.

- Ryan

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

Re: [Xen-devel] [PATCH] x86/xen: Add "xen_timer_slop" command line option

[Boris Ostrovsky]

On 3/25/19 8:05 AM, luca abeni wrote:
> Hi all,
>
> On Sat, 23 Mar 2019 11:41:51 +0100
> luca abeni  wrote:
> [...]
 Is there any data that shows effects of using this new parameter?
 
>>> Yes, I've done some research and experiments on this. I did it
>>> together with a friend, which I'm Cc-ing, as I'm not sure we're
>>> ready/capable to share the results, yet (Luca?).  
>> I think we can easily share the experimental data (cyclictest output
>> and plots).
>>
>> Moreover, we can share the scripts and tools for running the
>> experiments (so, everyone can easily reproduce the numbers by simply
>> typing "make" and waiting for some time :)
>>
>>
>> I'll try to package the results and the scripts/tools this evening,
>> and I'll send them.
> Sorry for the delay. I put some quick results here:
> http://retis.santannapisa.it/luca/XenTimers/
> (there also is a link to the scripts to be used for reproducing the
> results). The latencies have been measured by running cyclictest in the
> guest (see the scripts for details).
>
> The picture shows the latencies measured with an unpatched guest kernel
> and with a guest kernel having TIMER_SLOP set to 1000 (arbitrary small
> value :).
> All the experiments have been performed booting the hypervisor with a
> small timer_slop (the hypervisor's one) value. So, they show that
> decreasing the hypervisor's timer_slop is not enough to measure low
> latencies with cyclictest.



I have a couple of questions:
* Does it make sense to make this a tunable for other clockevent devices
as well?
* This patch adjusts min value. Could max value (ever) need a similar
adjustment?

-boris

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

[Xen-devel] Xen 4.12 RC7

[Juergen Gross]

Hi all,

Xen 4.12 rc7 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.12.0-rc7

For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12.0-rc7/xen-4.12.0-rc7.tar.gz

And the signature is at:
https://downloads.xenproject.org/release/xen/4.12.0-rc7/xen-4.12.0-rc7.tar.gz.sig

Please send bug reports and test reports to xen-devel@lists.xenproject.org.
When sending bug reports, please CC relevant maintainers and me
(jgr...@suse.com).

This will be the last RC before Xen 4.12 release (at least I hope so).


Juergen

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

[Xen-devel] [PATCH v3 00/14] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
is a joint venture between AMD and Haiguang Information Technology Co.,
Ltd., aims at providing high performance x86 processors for China
server market.

The first generation Hygon processor(Dhyana) originates from AMD
technology and shares most of the architecture with AMD's family 17h,
but with different CPU vendor ID("HygonGenuine") and family series
number 18h (Hygon negotiated with AMD to make sure that only Hygon
will use family 18h).

To enable support of Xen to Hygon Dhyana CPU, add a new vendor type
(X86_VENDOR_HYGON, with value of 5), and share most of the code with
AMD family 17h.

The MSRs and CPUIDs which are used by this patch series are all defined
in this PPR[1].

This patch series have been applied and tested successfully on Hygon
Dhyana processor, also been tested on AMD EPYC (family 17h) processor.
It works fine and makes no harm to the existing code.

Reference:
[1] 
https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf


v2->v3:
  - Rebased on 4.13-unstable and tested against it.
  - Simplify code of hygon.c by re-using early_init_amd().
  - Return false in the function probe_cpuid_faulting().
  - Adjust code for calculating phys_proc_id for Hygon.
  - Abstract common function _vpmu_init() and add hygon_vpmu_init().
  - Refine some comments and descriptions.
  - Add Acked-by from Jan Beulich for x86/cpu/mtrr, x86/cpu/mce,
x86/spec_ctrl, x86/apic, x86/acpi, x86/iommu, x86/pv, x86/domain,
x86/domctl and x86/cpuid.

v1->v2:
  - Rebased on 4.12.0-rc3 and tested against it.
  - Move opt_cpuid_mask_l7s0_(eax/ebx) to common.c.
  - Insert Hygon cases after AMD ones instead of above.
  - Remove (rd/wr)msr_hygon_safe and use (rd/wr)msr_safe instead.
  - Remove wrmsr_hygon and use wrmsrl instead.
  - Remove the unnecessary change to xstate.
  - Refine some codes and comments.
  - Add Acked-by from Jan Beulich for x86/traps.
  - Add Acked-by from Wei Liu for tools/libxc.


Pu Wen (14):
  x86/cpu: Create Hygon Dhyana architecture support file
  x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2
  x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU
  x86/cpu/mce: Add Hygon Dhyana support to the MCA infrastructure
  x86/spec_ctrl: Add Hygon Dhyana to the respective mitigation machinery
  x86/apic: Add Hygon Dhyana support
  x86/acpi: Add Hygon Dhyana support
  x86/iommu: Add Hygon Dhyana support
  x86/pv: Add Hygon Dhyana support to emulate MSRs access
  x86/domain: Add Hygon Dhyana support
  x86/domctl: Add Hygon Dhyana support
  x86/traps: Add Hygon Dhyana support
  x86/cpuid: Add Hygon Dhyana support
  tools/libxc: Add Hygon Dhyana support

 tools/libxc/xc_cpuid_x86.c | 16 --
 xen/arch/x86/acpi/cpu_idle.c   |  3 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c|  8 +--
 xen/arch/x86/acpi/cpufreq/powernow.c   |  3 +-
 xen/arch/x86/apic.c|  5 ++
 xen/arch/x86/cpu/Makefile  |  1 +
 xen/arch/x86/cpu/amd.c |  7 +--
 xen/arch/x86/cpu/common.c  | 12 -
 xen/arch/x86/cpu/cpu.h |  4 ++
 xen/arch/x86/cpu/hygon.c   | 95 ++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c |  5 +-
 xen/arch/x86/cpu/mcheck/mce.c  |  6 ++-
 xen/arch/x86/cpu/mcheck/mce_amd.c  |  5 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c|  3 +-
 xen/arch/x86/cpu/mcheck/vmce.c |  2 +
 xen/arch/x86/cpu/mtrr/generic.c|  5 +-
 xen/arch/x86/cpu/vpmu.c|  5 ++
 xen/arch/x86/cpu/vpmu_amd.c| 57 ++--
 xen/arch/x86/cpuid.c   | 10 ++--
 xen/arch/x86/dom0_build.c  |  3 +-
 xen/arch/x86/domain.c  |  9 ++--
 xen/arch/x86/domctl.c  | 13 +++--
 xen/arch/x86/pv/emul-priv-op.c | 19 ---
 xen/arch/x86/spec_ctrl.c   |  6 ++-
 xen/arch/x86/traps.c   |  3 ++
 xen/include/asm-x86/iommu.h|  1 +
 xen/include/asm-x86/vpmu.h |  1 +
 xen/include/asm-x86/x86-vendors.h  |  3 +-
 28 files changed, 250 insertions(+), 60 deletions(-)
 create mode 100644 xen/arch/x86/cpu/hygon.c

-- 
2.7.4


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

[Xen-devel] [PATCH v3 14/14] tools/libxc: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to caculate the cpuid policies for creating PV
or HVM guest by using the code path of AMD.

Signed-off-by: Pu Wen 
Acked-by: Wei Liu 
---
 tools/libxc/xc_cpuid_x86.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 098affe..d0cb9ae 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -234,6 +234,7 @@ struct cpuid_domain_info
 VENDOR_UNKNOWN,
 VENDOR_INTEL,
 VENDOR_AMD,
+VENDOR_HYGON,
 } vendor;
 
 bool hvm;
@@ -304,6 +305,10 @@ static int get_cpuid_domain_info(xc_interface *xch, 
uint32_t domid,
   regs[2] == 0x444d4163U &&
   regs[3] == 0x69746e65U )
 info->vendor = VENDOR_AMD;
+else if ( regs[1] == 0x6f677948U && /* "HygonGenuine" */
+  regs[2] == 0x656e6975U &&
+  regs[3] == 0x6e65476eU )
+info->vendor = VENDOR_HYGON;
 else
 info->vendor = VENDOR_UNKNOWN;
 
@@ -568,7 +573,8 @@ static void xc_cpuid_hvm_policy(const struct 
cpuid_domain_info *info,
 break;
 }
 
-if ( info->vendor == VENDOR_AMD )
+if ( info->vendor == VENDOR_AMD ||
+ info->vendor == VENDOR_HYGON )
 amd_xc_cpuid_policy(info, input, regs);
 else
 intel_xc_cpuid_policy(info, input, regs);
@@ -630,7 +636,8 @@ static void xc_cpuid_pv_policy(const struct 
cpuid_domain_info *info,
 
 case 0x8000:
 {
-unsigned int max = info->vendor == VENDOR_AMD
+unsigned int max = (info->vendor == VENDOR_AMD||
+info->vendor == VENDOR_HYGON)
 ? DEF_MAX_AMDEXT : DEF_MAX_INTELEXT;
 
 if ( regs[0] > max )
@@ -736,7 +743,8 @@ static void sanitise_featureset(struct cpuid_domain_info 
*info)
 if ( !info->pv64 )
 {
 clear_bit(X86_FEATURE_LM, info->featureset);
-if ( info->vendor != VENDOR_AMD )
+if ( info->vendor != VENDOR_AMD &&
+ info->vendor != VENDOR_HYGON )
 clear_bit(X86_FEATURE_SYSCALL, info->featureset);
 }
 
@@ -787,7 +795,7 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid,
 input[0] = 0x8000;
 cpuid(input, regs);
 
-if ( info.vendor == VENDOR_AMD )
+if ( info.vendor == VENDOR_AMD || info.vendor == VENDOR_HYGON )
 ext_max = (regs[0] <= DEF_MAX_AMDEXT) ? regs[0] : DEF_MAX_AMDEXT;
 else
 ext_max = (regs[0] <= DEF_MAX_INTELEXT) ? regs[0] : DEF_MAX_INTELEXT;
-- 
2.7.4


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

[Xen-devel] [PATCH v3 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

As Hygon Dhyana CPU share similar PMU architecture with AMD family
17h one, so add Hygon Dhyana support in vpmu_arch_initialise() and
vpmu_init() by sharing AMD code path.

Split the common part in amd_vpmu_init() to a static function
_vpmu_init(), making AMD and Hygon to call the shared function to
initialize vPMU.

As current vPMU still not support Zen(family 17h), add 0x17 support
to amd_vpmu_init().

Also create a function hygon_vpmu_init() for Hygon vPMU initialization.

Both of AMD 17h and Hygon 18h have the same performance event select
and counter MSRs as AMD 15h has, so reuse the 15h definitions for them.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/cpu/vpmu.c |  5 
 xen/arch/x86/cpu/vpmu_amd.c | 57 -
 xen/include/asm-x86/vpmu.h  |  1 +
 3 files changed, 47 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 8f6daf1..93a27d8 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -456,6 +456,7 @@ static int vpmu_arch_initialise(struct vcpu *v)
 switch ( vendor )
 {
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 ret = svm_vpmu_initialise(v);
 break;
 
@@ -876,6 +877,10 @@ static int __init vpmu_init(void)
 if ( amd_vpmu_init() )
vpmu_mode = XENPMU_MODE_OFF;
 break;
+case X86_VENDOR_HYGON:
+if ( hygon_vpmu_init() )
+   vpmu_mode = XENPMU_MODE_OFF;
+break;
 case X86_VENDOR_INTEL:
 if ( core2_vpmu_init() )
vpmu_mode = XENPMU_MODE_OFF;
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index 5efc39b..3fc955f 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -538,13 +538,37 @@ int svm_vpmu_initialise(struct vcpu *v)
 return 0;
 }
 
-int __init amd_vpmu_init(void)
+static int _vpmu_init(void)
 {
 unsigned int i;
 
+if ( sizeof(struct xen_pmu_data) +
+ 2 * sizeof(uint64_t) * num_counters > PAGE_SIZE )
+{
+printk(XENLOG_WARNING
+   "VPMU: Register bank does not fit into VPMU shared page\n");
+counters = ctrls = NULL;
+num_counters = 0;
+return -ENOSPC;
+}
+
+for ( i = 0; i < num_counters; i++ )
+{
+rdmsrl(ctrls[i], ctrl_rsvd[i]);
+ctrl_rsvd[i] &= CTRL_RSVD_MASK;
+}
+
+regs_sz = 2 * sizeof(uint64_t) * num_counters;
+
+return 0;
+}
+
+int __init amd_vpmu_init(void)
+{
 switch ( current_cpu_data.x86 )
 {
 case 0x15:
+case 0x17:
 num_counters = F15H_NUM_COUNTERS;
 counters = AMD_F15H_COUNTERS;
 ctrls = AMD_F15H_CTRLS;
@@ -565,24 +589,25 @@ int __init amd_vpmu_init(void)
 return -EINVAL;
 }
 
-if ( sizeof(struct xen_pmu_data) +
- 2 * sizeof(uint64_t) * num_counters > PAGE_SIZE )
-{
-printk(XENLOG_WARNING
-   "VPMU: Register bank does not fit into VPMU shared page\n");
-counters = ctrls = NULL;
-num_counters = 0;
-return -ENOSPC;
-}
+return _vpmu_init();
+}
 
-for ( i = 0; i < num_counters; i++ )
+int __init hygon_vpmu_init(void)
+{
+switch ( current_cpu_data.x86 )
 {
-rdmsrl(ctrls[i], ctrl_rsvd[i]);
-ctrl_rsvd[i] &= CTRL_RSVD_MASK;
+case 0x18:
+num_counters = F15H_NUM_COUNTERS;
+counters = AMD_F15H_COUNTERS;
+ctrls = AMD_F15H_CTRLS;
+k7_counters_mirrored = 1;
+break;
+default:
+printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
+   current_cpu_data.x86);
+return -EINVAL;
 }
 
-regs_sz = 2 * sizeof(uint64_t) * num_counters;
-
-return 0;
+return _vpmu_init();
 }
 
diff --git a/xen/include/asm-x86/vpmu.h b/xen/include/asm-x86/vpmu.h
index 1287b9f..55f85ba 100644
--- a/xen/include/asm-x86/vpmu.h
+++ b/xen/include/asm-x86/vpmu.h
@@ -52,6 +52,7 @@ struct arch_vpmu_ops {
 int core2_vpmu_init(void);
 int vmx_vpmu_initialise(struct vcpu *);
 int amd_vpmu_init(void);
+int hygon_vpmu_init(void);
 int svm_vpmu_initialise(struct vcpu *);
 
 struct vpmu_struct {
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v3] x86/mm: Clean up p2m_finish_type_change return value

[Jan Beulich]

>>> On 25.03.19 at 10:09,  wrote:
>> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
>> Sent: 22 March 2019 12:09
>> 
>> In the case of any errors, finish_type_change() passes values returned
>> from p2m->recalc() up the stack (with some exceptions in the case where
>> an error is expected); this eventually ends up being returned to the
>> XEN_DOMOP_map_mem_type_to_ioreq_server hypercall.
>> 
>> However, on Intel processors (but not on AMD processor), p2m->recalc()
>> can also return '1' as well as '0'.  This case is handled very
>> inconsistently: finish_type_change() will return the value of the final
>> entry it attempts, discarding results for other entries;
>> p2m_finish_type_change() will attempt to accumulate '1's, so that it
>> returns '1' if any of the calls to finish_type_change() returns '1'; and
>> dm_op() will again return '1' only if the very last call to
>> p2m_finish_type_change() returns '1'.  The result is that the
>> XEN_DMOP_map_mem_type_to_ioreq_server() hypercall will sometimes return
>> 0 and sometimes return 1 on success, in an unpredictable manner.
>> 
>> The hypercall documentation doesn't mention return values; but it's not
>> clear what the caller could do with the information about whether
>> entries had been changed or not.  At the moment it's always 0 on AMD
>> boxes, and *usually* 1 on Intel boxes; so nothing can be relying on a
>> '1' return value for correctness (or if it is, it's broken).
>> 
>> Make the return value on success consistently '0' by only returning
>> 0/-ERROR from finish_type_change().  Also remove the accumulation code
>> from p2m_finish_type_change().
> 
> Sorry, I don't think I was cc-ed on the original and I managed to miss George 
> cc-ing me on his response to v2. Digging into the code a bit I can't honestly 
> see what the point of returning anything other than 0/-errno out of 
> p2m->recalc 
> is. The only use of rc > 0 from p2m-ept.c:resolve_misconfig() is in 
> ept_handle_misconfig() AFAICT so it would make more sense to me to tighten up 
> the semantics of recalc (which I believe Jan suggested in response to v1) and 
> turn any > 0 return from resolve_misconfig() into 0. So, the code below looks 
> fine but the patch just needs to do a little more (and then your rc < 0 test 
> can also be simplified to !rc too).

Yes, indeed I'd prefer everything to be cleaned up in one go.

Jan



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

[Xen-devel] [PATCH v3 08/14] x86/iommu: Add Hygon Dhyana support

[Pu Wen]

The IOMMU architecture for the Hygon Dhyana CPU is similar to the AMD
family 17h one. So add Hygon Dhyana support to it by sharing the code
path of AMD.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/include/asm-x86/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 8dc3924..699a8f7 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -74,6 +74,7 @@ static inline int iommu_hardware_setup(void)
 case X86_VENDOR_INTEL:
 return intel_vtd_setup();
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 return amd_iov_detect();
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v3 10/14] x86/domain: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to handle HyperTransport range.

Also loading a nul selector does not clear bases and limits on Hygon
CPUs, so add Hygon Dhyana support to the function preload_segment.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/dom0_build.c | 3 ++-
 xen/arch/x86/domain.c | 9 +
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 6ebe367..6178d79 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -542,7 +542,8 @@ int __init dom0_setup_permissions(struct domain *d)
 paddr_to_pfn(MSI_ADDR_BASE_LO +
  MSI_ADDR_DEST_ID_MASK));
 /* HyperTransport range. */
-if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
 rc |= iomem_deny_access(d, paddr_to_pfn(0xfdULL << 32),
 paddr_to_pfn((1ULL << 40) - 1));
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 8d579e2..eefe0fc 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1253,13 +1253,14 @@ arch_do_vcpu_op(
 }
 
 /*
- * Loading a nul selector does not clear bases and limits on AMD CPUs. Be on
- * the safe side and re-initialize both to flat segment values before loading
- * a nul selector.
+ * Loading a nul selector does not clear bases and limits on AMD or Hygon
+ * CPUs. Be on the safe side and re-initialize both to flat segment values
+ * before loading a nul selector.
  */
 #define preload_segment(seg, value) do {  \
 if ( !((value) & ~3) &&   \
- boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) \
+(boot_cpu_data.x86_vendor == X86_VENDOR_AMD || \
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) ) \
 asm volatile ( "movl %k0, %%" #seg\
:: "r" (FLAT_USER_DS32) ); \
 } while ( false )
-- 
2.7.4


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

[Xen-devel] [PATCH v3 06/14] x86/apic: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to use modern APIC.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/apic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 2a24326..004d685 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -92,6 +92,11 @@ static int modern_apic(void)
 if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
 boot_cpu_data.x86 >= 0xf)
 return 1;
+
+/* Hygon systems use modern APIC */
+if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+return 1;
+
 lvr = apic_read(APIC_LVR);
 version = GET_APIC_VERSION(lvr);
 return version >= 0x14;
-- 
2.7.4


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

[Xen-devel] [PATCH v3 13/14] x86/cpuid: Add Hygon Dhyana support

[Pu Wen]

The Hygon Dhyana family 18h processor shares the same cpuid leaves as
the AMD family 17h one. So add Hygon Dhyana support to caculate the
cpuid policies as the AMD CPU does.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/cpuid.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index ab0aab6..f760594 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -240,6 +240,7 @@ static void recalculate_misc(struct cpuid_policy *p)
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 zero_leaves(p->basic.raw, 0x2, 0x3);
 memset(p->cache.raw, 0, sizeof(p->cache.raw));
 zero_leaves(p->basic.raw, 0x9, 0xa);
@@ -390,7 +391,8 @@ static void __init calculate_hvm_max_policy(void)
  * long mode (and init_amd() has cleared it out of host capabilities), but
  * HVM guests are able if running in protected mode.
  */
-if ( (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+if ( (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+  boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) &&
  raw_cpuid_policy.basic.sep )
 __set_bit(X86_FEATURE_SEP, hvm_featureset);
 
@@ -465,7 +467,8 @@ void recalculate_cpuid_policy(struct domain *d)
 p->basic.max_leaf   = min(p->basic.max_leaf,   max->basic.max_leaf);
 p->feat.max_subleaf = min(p->feat.max_subleaf, max->feat.max_subleaf);
 p->extd.max_leaf= 0x8000 | min(p->extd.max_leaf & 0x,
-   (p->x86_vendor == X86_VENDOR_AMD
+  ((p->x86_vendor == X86_VENDOR_AMD ||
+p->x86_vendor == X86_VENDOR_HYGON)
 ? CPUID_GUEST_NR_EXTD_AMD
 : CPUID_GUEST_NR_EXTD_INTEL) - 1);
 
@@ -507,7 +510,8 @@ void recalculate_cpuid_policy(struct domain *d)
 if ( is_pv_32bit_domain(d) )
 {
 __clear_bit(X86_FEATURE_LM, max_fs);
-if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
 __clear_bit(X86_FEATURE_SYSCALL, max_fs);
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v3 12/14] x86/traps: Add Hygon Dhyana support

[Pu Wen]

The Hygon Dhyana processor has the methold to get the last exception
source IP from MSR_01DD. So add support for it if the boot param
ler is true.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/traps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 05ddc39..97bf9e2 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1973,6 +1973,9 @@ static unsigned int calc_ler_msr(void)
 return MSR_IA32_LASTINTFROMIP;
 }
 break;
+
+case X86_VENDOR_HYGON:
+return MSR_IA32_LASTINTFROMIP;
 }
 
 return 0;
-- 
2.7.4


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

[Xen-devel] [PATCH v3 11/14] x86/domctl: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to update cpuid info for creating PV guest.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/domctl.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9bf2d08..19b7bdd 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -176,6 +176,7 @@ static int update_domain_cpuid_info(struct domain *d,
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 mask &= ((uint64_t)ecx << 32) | edx;
 
 /*
@@ -220,7 +221,8 @@ static int update_domain_cpuid_info(struct domain *d,
 uint32_t eax = ctl->eax;
 uint32_t ebx = p->feat._7b0;
 
-if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
 mask &= ((uint64_t)eax << 32) | ebx;
 
 d->arch.pv.cpuidmasks->_7ab0 = mask;
@@ -281,8 +283,12 @@ static int update_domain_cpuid_info(struct domain *d,
 if ( cpu_has_cmp_legacy )
 ecx |= cpufeat_mask(X86_FEATURE_CMP_LEGACY);
 
-/* If not emulating AMD, clear the duplicated features in e1d. */
-if ( p->x86_vendor != X86_VENDOR_AMD )
+/*
+ * If not emulating AMD or Hygon, clear the duplicated features
+ * in e1d.
+ */
+if ( p->x86_vendor != X86_VENDOR_AMD &&
+ p->x86_vendor != X86_VENDOR_HYGON )
 edx &= ~CPUID_COMMON_1D_FEATURES;
 
 switch ( boot_cpu_data.x86_vendor )
@@ -292,6 +298,7 @@ static int update_domain_cpuid_info(struct domain *d,
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 mask &= ((uint64_t)ecx << 32) | edx;
 
 /*
-- 
2.7.4


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

[Xen-devel] [PATCH v3 09/14] x86/pv: Add Hygon Dhyana support to emulate MSRs access

[Pu Wen]

The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
counter MSRs, hardware configuration MSR, MMIO configuration base address
MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the
PV emulation infrastructure by using the code path of AMD.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/pv/emul-priv-op.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 3746e2a..c92f9dc 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -924,7 +924,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
 /* fall through */
 case MSR_AMD_FAM15H_EVNTSEL0 ... MSR_AMD_FAM15H_PERFCTR5:
 case MSR_K7_EVNTSEL0 ... MSR_K7_PERFCTR3:
-if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+if ( vpmu_msr ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) )
 {
 if ( vpmu_do_rdmsr(reg, val) )
 break;
@@ -1006,7 +1008,8 @@ static int write_msr(unsigned int reg, uint64_t val,
 case MSR_K8_PSTATE6:
 case MSR_K8_PSTATE7:
 case MSR_K8_HWCR:
-if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
 break;
 if ( likely(!is_cpufreq_controller(currd)) ||
  wrmsr_safe(reg, val) == 0 )
@@ -1027,8 +1030,9 @@ static int write_msr(unsigned int reg, uint64_t val,
 break;
 
 case MSR_FAM10H_MMIO_CONF_BASE:
-if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
- boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
+if ( (boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
+  boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17) &&
+  boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
 break;
 if ( !is_hardware_domain(currd) || !is_pinned_vcpu(curr) )
 return X86EMUL_OKAY;
@@ -1067,7 +1071,8 @@ static int write_msr(unsigned int reg, uint64_t val,
 case MSR_IA32_MPERF:
 case MSR_IA32_APERF:
 if ( (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) &&
- (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) )
+ (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) &&
+ (boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) )
 break;
 if ( likely(!is_cpufreq_controller(currd)) ||
  wrmsr_safe(reg, val) == 0 )
@@ -1100,7 +1105,9 @@ static int write_msr(unsigned int reg, uint64_t val,
 vpmu_msr = true;
 case MSR_AMD_FAM15H_EVNTSEL0 ... MSR_AMD_FAM15H_PERFCTR5:
 case MSR_K7_EVNTSEL0 ... MSR_K7_PERFCTR3:
-if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+if ( vpmu_msr ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) )
 {
 if ( (vpmu_mode & XENPMU_MODE_ALL) &&
  !is_hardware_domain(currd) )
-- 
2.7.4


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

[Xen-devel] [PATCH v3 05/14] x86/spec_ctrl: Add Hygon Dhyana to the respective mitigation machinery

[Pu Wen]

The Hygon Dhyana CPU has the same speculative execution as AMD family
17h, so share AMD Retpoline and PTI mitigation code with Hygon Dhyana.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/spec_ctrl.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 1171c02..1cd7903 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -306,7 +306,8 @@ static bool __init retpoline_safe(uint64_t caps)
 {
 unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
 
-if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
 return true;
 
 if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
@@ -632,7 +633,8 @@ int8_t __read_mostly opt_xpti_domu = -1;
 
 static __init void xpti_init_default(uint64_t caps)
 {
-if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
 caps = ARCH_CAPS_RDCL_NO;
 
 if ( caps & ARCH_CAPS_RDCL_NO )
-- 
2.7.4


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

[Xen-devel] [PATCH v3 02/14] x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2

[Pu Wen]

The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
Dhyana support to print the value of TOP_MEM2.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/cpu/mtrr/generic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index 8f9cf1b..94ee7d6 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -217,8 +217,9 @@ static void __init print_mtrr_state(const char *level)
printk("%s  %u disabled\n", level, i);
}
 
-   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD
-   && boot_cpu_data.x86 >= 0xf) {
+   if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
+boot_cpu_data.x86 >= 0xf) ||
+boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
uint64_t syscfg, tom2;
 
rdmsrl(MSR_K8_SYSCFG, syscfg);
-- 
2.7.4


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

[Xen-devel] [PATCH v3 04/14] x86/cpu/mce: Add Hygon Dhyana support to the MCA infrastructure

[Pu Wen]

The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. Add vendor checking for Hygon Dhyana to share the
code path of AMD family 17h.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/cpu/common.c  | 3 ++-
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c | 5 +++--
 xen/arch/x86/cpu/mcheck/mce.c  | 6 --
 xen/arch/x86/cpu/mcheck/mce_amd.c  | 5 -
 xen/arch/x86/cpu/mcheck/non-fatal.c| 3 ++-
 xen/arch/x86/cpu/mcheck/vmce.c | 2 ++
 6 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 9fb75dd..3f70415 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -353,7 +353,8 @@ static void __init early_cpu_detect(void)
hap_paddr_bits = PADDR_BITS;
}
 
-   if (c->x86_vendor != X86_VENDOR_AMD)
+   if (c->x86_vendor != X86_VENDOR_AMD &&
+   c->x86_vendor != X86_VENDOR_HYGON)
park_offline_cpus = opt_mce;
 
initialize_cpu_data(0);
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c 
b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 222f539..589dac5 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -203,10 +203,11 @@ static void mce_amd_work_fn(void *data)
 
 void __init amd_nonfatal_mcheck_init(struct cpuinfo_x86 *c)
 {
-   if (c->x86_vendor != X86_VENDOR_AMD)
+   if (c->x86_vendor != X86_VENDOR_AMD &&
+   c->x86_vendor != X86_VENDOR_HYGON)
return;
 
-   /* Assume we are on K8 or newer AMD CPU here */
+   /* Assume we are on K8 or newer AMD or Hygon CPU here */
 
/* The threshold bitfields in MSR_IA32_MC4_MISC has
 * been introduced along with the SVME feature bit. */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 30cdb06..0798dea 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -778,6 +778,7 @@ void mcheck_init(struct cpuinfo_x86 *c, bool bsp)
 switch ( c->x86_vendor )
 {
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 inited = amd_mcheck_init(c);
 break;
 
@@ -1172,10 +1173,11 @@ static bool x86_mc_msrinject_verify(struct 
xen_mc_msrinject *mci)
 
 /* MSRs that the HV will take care of */
 case MSR_K8_HWCR:
-if ( c->x86_vendor == X86_VENDOR_AMD )
+if ( c->x86_vendor == X86_VENDOR_AMD ||
+ c->x86_vendor == X86_VENDOR_HYGON )
 reason = "HV will operate HWCR";
 else
-reason = "only supported on AMD";
+reason = "only supported on AMD or Hygon";
 break;
 
 default:
diff --git a/xen/arch/x86/cpu/mcheck/mce_amd.c 
b/xen/arch/x86/cpu/mcheck/mce_amd.c
index ed29fcc..8ed2b17 100644
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
@@ -286,7 +286,10 @@ enum mcheck_type
 amd_mcheck_init(struct cpuinfo_x86 *ci)
 {
 uint32_t i;
-enum mcequirk_amd_flags quirkflag = mcequirk_lookup_amd_quirkdata(ci);
+enum mcequirk_amd_flags quirkflag = 0;
+
+if (ci->x86_vendor != X86_VENDOR_HYGON)
+quirkflag = mcequirk_lookup_amd_quirkdata(ci);
 
 /* Assume that machine check support is available.
  * The minimum provided support is at least the K8. */
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c 
b/xen/arch/x86/cpu/mcheck/non-fatal.c
index d12e8f2..77be418 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -101,7 +101,8 @@ static int __init init_nonfatal_mce_checker(void)
 */
switch (c->x86_vendor) {
case X86_VENDOR_AMD:
-   /* Assume we are on K8 or newer AMD CPU here */
+   case X86_VENDOR_HYGON:
+   /* Assume we are on K8 or newer AMD or Hygon CPU here */
amd_nonfatal_mcheck_init(c);
break;
 
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index f15835e..4f5de07 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -154,6 +154,7 @@ static int bank_mce_rdmsr(const struct vcpu *v, uint32_t 
msr, uint64_t *val)
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 ret = vmce_amd_rdmsr(v, msr, val);
 break;
 
@@ -284,6 +285,7 @@ static int bank_mce_wrmsr(struct vcpu *v, uint32_t msr, 
uint64_t val)
 break;
 
 case X86_VENDOR_AMD:
+case X86_VENDOR_HYGON:
 ret = vmce_amd_wrmsr(v, msr, val);
 break;
 
-- 
2.7.4


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

[Xen-devel] [PATCH v3 07/14] x86/acpi: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to the acpi cpufreq and cpuidle subsystems by
using the code path of AMD.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/acpi/cpu_idle.c | 3 ++-
 xen/arch/x86/acpi/cpufreq/cpufreq.c  | 8 +---
 xen/arch/x86/acpi/cpufreq/powernow.c | 3 ++-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 654de24..02e4873 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -796,7 +796,8 @@ void acpi_dead_idle(void)
 __mwait(cx->address, 0);
 }
 }
-else if ( current_cpu_data.x86_vendor == X86_VENDOR_AMD &&
+else if ( (current_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+   current_cpu_data.x86_vendor == X86_VENDOR_HYGON) &&
   cx->entry_method == ACPI_CSTATE_EM_SYSIO )
 {
 /* Intel prefers not to use SYSIO */
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c 
b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 844ab85..14c18bd 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -649,7 +649,8 @@ static int __init cpufreq_driver_init(void)
 (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL))
 ret = cpufreq_register_driver(&acpi_cpufreq_driver);
 else if ((cpufreq_controller == FREQCTL_xen) &&
-(boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
+(boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON))
 ret = powernow_register_driver();
 
 return ret;
@@ -660,9 +661,10 @@ int cpufreq_cpu_init(unsigned int cpuid)
 {
 int ret;
 
-/* Currently we only handle Intel and AMD processor */
+/* Currently we only handle Intel, AMD and Hygon processor */
 if ( (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) ||
- (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) )
+ (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) ||
+ (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ) )
 ret = cpufreq_add_cpu(cpuid);
 else
 ret = -EFAULT;
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c 
b/xen/arch/x86/acpi/cpufreq/powernow.c
index 025b37d..f245908 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -360,7 +360,8 @@ unsigned int __init powernow_register_driver()
 
 for_each_online_cpu(i) {
 struct cpuinfo_x86 *c = &cpu_data[i];
-if (c->x86_vendor != X86_VENDOR_AMD)
+if (c->x86_vendor != X86_VENDOR_AMD &&
+c->x86_vendor != X86_VENDOR_HYGON)
 ret = -ENODEV;
 else
 {
-- 
2.7.4


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 210bd16aff81f6746033dfc0c4cc7c463349bce0
baseline version:
 ovmf f4c5200926df8aa8e4ede24fcca288be2150acb4

Last test of basis   133980  2019-03-22 07:22:47 Z3 days
Testing same since   134043  2019-03-24 06:11:54 Z1 days1 attempts


People who touched revisions under test:
  Bob Feng 
  Feng, Bob C 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   f4c5200926..210bd16aff  210bd16aff81f6746033dfc0c4cc7c463349bce0 -> 
xen-tested-master

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

[Xen-devel] [PATCH v3 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. To make Hygon initialization flow more clear, carve out code from
amd.c into a separate file hygon.c, and remove unnecessary code for
Hygon Dhyana.

To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON
for system recognition.

Hygon can fully use the function early_init_amd(), so make this common
function non-static and direct call it from Hygon code.

As opt_cpuid_mask_l7s0_eax and opt_cpuid_mask_l7s0_ebx are used by both
AMD and Hygon, so move them to common.c.

Hygon Dhyana has no CPUID faulting, so directly return false in the
function probe_cpuid_faulting().

Add a separate hygon_get_topology(), which calculate phys_proc_id from
AcpiId[6](see reference [1]).

Reference:
[1] https://git.kernel.org/tip/e0ceeae708cebf22c990c3d703a4ca187dc837f5

Signed-off-by: Pu Wen 
---
 xen/arch/x86/cpu/Makefile |  1 +
 xen/arch/x86/cpu/amd.c|  7 +--
 xen/arch/x86/cpu/common.c |  9 
 xen/arch/x86/cpu/cpu.h|  4 ++
 xen/arch/x86/cpu/hygon.c  | 95 +++
 xen/include/asm-x86/x86-vendors.h |  3 +-
 6 files changed, 112 insertions(+), 7 deletions(-)
 create mode 100644 xen/arch/x86/cpu/hygon.c

diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index 34a01ca..466acc8 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -4,6 +4,7 @@ subdir-y += mtrr
 obj-y += amd.o
 obj-y += centaur.o
 obj-y += common.o
+obj-y += hygon.o
 obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index c790416..812d54d 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -32,11 +32,6 @@
 static char __initdata opt_famrev[14];
 string_param("cpuid_mask_cpu", opt_famrev);
 
-static unsigned int __initdata opt_cpuid_mask_l7s0_eax = ~0u;
-integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
-static unsigned int __initdata opt_cpuid_mask_l7s0_ebx = ~0u;
-integer_param("cpuid_mask_l7s0_ebx", opt_cpuid_mask_l7s0_ebx);
-
 static unsigned int __initdata opt_cpuid_mask_thermal_ecx = ~0u;
 integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_thermal_ecx);
 
@@ -526,7 +521,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
   : c->cpu_core_id);
 }
 
-static void early_init_amd(struct cpuinfo_x86 *c)
+void early_init_amd(struct cpuinfo_x86 *c)
 {
if (c == &boot_cpu_data)
amd_init_levelling();
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 53bb0a9..9fb75dd 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -36,6 +36,11 @@ integer_param("cpuid_mask_ext_ecx", opt_cpuid_mask_ext_ecx);
 unsigned int opt_cpuid_mask_ext_edx = ~0u;
 integer_param("cpuid_mask_ext_edx", opt_cpuid_mask_ext_edx);
 
+unsigned int  opt_cpuid_mask_l7s0_eax = ~0u;
+integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
+unsigned int  opt_cpuid_mask_l7s0_ebx = ~0u;
+integer_param("cpuid_mask_l7s0_ebx", opt_cpuid_mask_l7s0_ebx);
+
 unsigned int __initdata expected_levelling_cap;
 unsigned int __read_mostly levelling_caps;
 
@@ -116,6 +121,9 @@ bool __init probe_cpuid_faulting(void)
uint64_t val;
int rc;
 
+   if(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+   return false;
+
if ((rc = rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val)) == 0)
raw_msr_policy.plaform_info.cpuid_faulting =
val & MSR_PLATFORM_INFO_CPUID_FAULTING;
@@ -710,6 +718,7 @@ void __init early_cpu_init(void)
amd_init_cpu();
centaur_init_cpu();
shanghai_init_cpu();
+   hygon_init_cpu();
early_cpu_detect();
 }
 
diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h
index 2fcb931..971077a 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -13,11 +13,15 @@ extern bool_t opt_arat;
 extern unsigned int opt_cpuid_mask_ecx, opt_cpuid_mask_edx;
 extern unsigned int opt_cpuid_mask_xsave_eax;
 extern unsigned int opt_cpuid_mask_ext_ecx, opt_cpuid_mask_ext_edx;
+extern unsigned int opt_cpuid_mask_l7s0_eax, opt_cpuid_mask_l7s0_ebx;
 
 extern int get_model_name(struct cpuinfo_x86 *c);
 extern void display_cacheinfo(struct cpuinfo_x86 *c);
 
+void early_init_amd(struct cpuinfo_x86 *c);
+
 int intel_cpu_init(void);
 int amd_init_cpu(void);
 int centaur_init_cpu(void);
 int shanghai_init_cpu(void);
+int hygon_init_cpu(void);
diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c
new file mode 100644
index 000..bbe13c5
--- /dev/null
+++ b/xen/arch/x86/cpu/hygon.c
@@ -0,0 +1,95 @@
+#include 
+#include 
+#include 
+#include 
+
+#include "cpu.h"
+
+#define APICID_SOCKET_ID_BIT 6
+
+static void hygon_get_topology(struct cpuinfo_x86 *c)
+{
+   u32 ebx;
+
+   if (c->x86_max_cores <= 1)
+   return;
+
+   /* Socket ID is ApicId[6] for

Re: [Xen-devel] [PATCH] PCI: Mark expected switch fall-throughs

[Jan Beulich]

>>> On 20.03.19 at 19:27,  wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
> 
> This patch fixes the following warnings:
> 
> drivers/pci/proc.c: In function ‘proc_bus_pci_ioctl’:
> drivers/pci/proc.c:216:6: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
>if (arch_can_pci_mmap_wc()) {
>   ^
> drivers/pci/proc.c:225:2: note: here
>   default:
>   ^~~
> 
> drivers/pci/xen-pcifront.c: In function ‘pcifront_backend_changed’:
> drivers/pci/xen-pcifront.c:1105:6: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
>if (xdev->state == XenbusStateClosed)
>   ^
> drivers/pci/xen-pcifront.c:1108:2: note: here
>   case XenbusStateClosing:
>   ^~~~
> 
> Notice that, in this particular case, the /* fall through */
> comment is placed at the very bottom of the case statement,
> which is what GCC is expecting to find.
> 
> Warning level 3 was used: -Wimplicit-fallthrough=3
> 
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.

None of the above explains why ...

> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -1104,7 +1104,7 @@ static void __ref pcifront_backend_changed(struct 
> xenbus_device *xdev,
>   case XenbusStateClosed:
>   if (xdev->state == XenbusStateClosed)
>   break;
> - /* Missed the backend's CLOSING state -- fallthrough */
> + /* fall through - Missed the backend's CLOSING state. */

... the original comment here wasn't good enough.

Jan


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

Re: [Xen-devel] [PATCH 3/6] xen: add new cpu notifier action CPU_RESUME_FAILED

[Juergen Gross]

On 25/03/2019 13:21, Dario Faggioli wrote:
> On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
>> --- a/xen/include/xen/cpu.h
>> +++ b/xen/include/xen/cpu.h
>> @@ -32,23 +32,25 @@ void register_cpu_notifier(struct notifier_block
>> *nb);
>>   *  (a) A CPU is going down; or (b) CPU_UP_CANCELED
>>   */
>>  /* CPU_UP_PREPARE: Preparing to bring CPU online. */
>> -#define CPU_UP_PREPARE   (0x0001 | NOTIFY_FORWARD)
>> +#define CPU_UP_PREPARE(0x0001 | NOTIFY_FORWARD)
>>
> In the comment block before these definitions, there's this:
> 
>  * Possible event sequences for a given CPU:
>  *  CPU_UP_PREPARE -> CPU_UP_CANCELLED   -- failed CPU up
>  *  CPU_UP_PREPARE -> CPU_STARTING -> CPU_ONLINE -- successful CPU up
>  *  CPU_DOWN_PREPARE -> CPU_DOWN_FAILED  -- failed CPU down
>  *  CPU_DOWN_PREPARE -> CPU_DYING -> CPU_DEAD-- successful CPU down
> 
> Shouldn't we add a line for this new hook? Something, IIUIC, like:
> 
>  CPU_UP_PREPARE -> CPU_UP_CANCELLED -> CPU_RESUME_FAILED --CPU not resuming

Fine with me.

> 
> With this, FWIW,
> 
> Reviewed-by: Dario Faggioli 
> 
> One more (minor) thing...
> 
>>  /* CPU_REMOVE: CPU was removed. */
>> -#define CPU_REMOVE   (0x0009 | NOTIFY_REVERSE)
>> +#define CPU_REMOVE(0x0009 | NOTIFY_REVERSE)
>> +/* CPU_RESUME_FAILED: CPU failed to come up in resume, all other CPUs up. */
>> +#define CPU_RESUME_FAILED (0x000a | NOTIFY_REVERSE)
>>  
> ... technically, when we're dealing with CPU_RESUME_FAILED on one CPU,
> we don't know if _all_ others really went up, so I think I'd remove
> what follows the ','.

The point is that for the CPU_RESUME_FAILED case we can be sure that no
cpu will come up due to resume just a little bit later. So we can test
for e.g. a cpupool suddenly having no more cpus available. This is in
contrast to CPU_UP_CANCELLED being signalled just after the one cpu
failing to come up, but before the next cpu is triggered to come up.


Juergen

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

Re: [Xen-devel] [PATCH 3/6] xen: add new cpu notifier action CPU_RESUME_FAILED

[Dario Faggioli]

On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
> --- a/xen/include/xen/cpu.h
> +++ b/xen/include/xen/cpu.h
> @@ -32,23 +32,25 @@ void register_cpu_notifier(struct notifier_block
> *nb);
>   *  (a) A CPU is going down; or (b) CPU_UP_CANCELED
>   */
>  /* CPU_UP_PREPARE: Preparing to bring CPU online. */
> -#define CPU_UP_PREPARE   (0x0001 | NOTIFY_FORWARD)
> +#define CPU_UP_PREPARE(0x0001 | NOTIFY_FORWARD)
>
In the comment block before these definitions, there's this:

 * Possible event sequences for a given CPU:
 *  CPU_UP_PREPARE -> CPU_UP_CANCELLED   -- failed CPU up
 *  CPU_UP_PREPARE -> CPU_STARTING -> CPU_ONLINE -- successful CPU up
 *  CPU_DOWN_PREPARE -> CPU_DOWN_FAILED  -- failed CPU down
 *  CPU_DOWN_PREPARE -> CPU_DYING -> CPU_DEAD-- successful CPU down

Shouldn't we add a line for this new hook? Something, IIUIC, like:

 CPU_UP_PREPARE -> CPU_UP_CANCELLED -> CPU_RESUME_FAILED --CPU not resuming

With this, FWIW,

Reviewed-by: Dario Faggioli 

One more (minor) thing...

>  /* CPU_REMOVE: CPU was removed. */
> -#define CPU_REMOVE   (0x0009 | NOTIFY_REVERSE)
> +#define CPU_REMOVE(0x0009 | NOTIFY_REVERSE)
> +/* CPU_RESUME_FAILED: CPU failed to come up in resume, all other CPUs up. */
> +#define CPU_RESUME_FAILED (0x000a | NOTIFY_REVERSE)
>  
... technically, when we're dealing with CPU_RESUME_FAILED on one CPU,
we don't know if _all_ others really went up, so I think I'd remove
what follows the ','.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xen: Add "xen_timer_slop" command line option

[luca abeni]

Hi all,

On Sat, 23 Mar 2019 11:41:51 +0100
luca abeni  wrote:
[...]
> > > Is there any data that shows effects of using this new parameter?
> > > 
> > Yes, I've done some research and experiments on this. I did it
> > together with a friend, which I'm Cc-ing, as I'm not sure we're
> > ready/capable to share the results, yet (Luca?).  
> 
> I think we can easily share the experimental data (cyclictest output
> and plots).
> 
> Moreover, we can share the scripts and tools for running the
> experiments (so, everyone can easily reproduce the numbers by simply
> typing "make" and waiting for some time :)
> 
> 
> I'll try to package the results and the scripts/tools this evening,
> and I'll send them.

Sorry for the delay. I put some quick results here:
http://retis.santannapisa.it/luca/XenTimers/
(there also is a link to the scripts to be used for reproducing the
results). The latencies have been measured by running cyclictest in the
guest (see the scripts for details).

The picture shows the latencies measured with an unpatched guest kernel
and with a guest kernel having TIMER_SLOP set to 1000 (arbitrary small
value :).
All the experiments have been performed booting the hypervisor with a
small timer_slop (the hypervisor's one) value. So, they show that
decreasing the hypervisor's timer_slop is not enough to measure low
latencies with cyclictest.


Luca

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

[Xen-devel] [xen-4.8-testing test] 134035: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-libvirt  broken
 build-arm64-xsm  broken
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
vs. 130965

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-5 69 xtf/test-hvm64-xsa-278 fail in 133998 pass in 134035
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
133662
 test-xtf-amd64-amd64-4   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 133998
 test-xtf-amd64-amd64-1   69 xtf/test-hvm64-xsa-278 fail pass in 133998
 test-armhf-armhf-xl-rtds  7 xen-boot   fail pass in 133998

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-pvops 4 host-install(4)   broken baseline untested
 build-arm64-xsm   4 host-install(4)   broken baseline untested
 build-arm64-libvirt   4 host-install(4)   broken baseline untested
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 133998 like 
130965
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 133998 like 
130965
 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 133998 never pass
 test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 133998 never 
pass
 test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 133998 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 133998 never pass
 test-arm64-arm64-xl-credit1 13 migrate-support-check fail in 133998 never pass
 test-arm64-arm64-xl-credit1 14 saverestore-support-check fail in 133998 never 
pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 133998 never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 133998 never 
pass
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 133998 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 133998 never pass
 test-arm64-arm64-xl 13 migrate-support-check fail in 133998 never pass
 test-arm64-arm64-xl 14 saverestore-support-check fail in 133998 never pass
 test-xtf-amd64-amd64-1  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 130965
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 130965
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 130965
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 130965
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 130965
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 130965
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 130965
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 130965
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 130965
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 130965
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail neve

Re: [Xen-devel] [PATCH 2/6] xen: add helper for calling notifier_call_chain() to common/cpu.c

[Dario Faggioli]

On Mon, 2019-03-18 at 14:11 +0100, Juergen Gross wrote:
> Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
> for a cpu with a specified action, returning an errno value.
> 
> This avoids coding the same pattern multiple times.
> 
> Signed-off-by: Juergen Gross 
>
Reviewed-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] xen/sched: don't disable scheduler on cpus during suspend

[Dario Faggioli]

On Sat, 2019-03-16 at 14:14 +0100, Juergen Gross wrote:
> On 16/03/2019 04:01, Dario Faggioli wrote:

> > > So we can just omit the call of cpu_disable_scheduler() when
> > > offlining
> > > a cpu due to suspend and on resuming we can omit taking the
> > > schedule
> > > lock for selecting the new processor.
> > > 
> > Well, in theory, we should hold the lock when for using
> > 'cpumask_scratch_cpu(cpu)'. Not sure this is an actual problem in
> > this
> > case, but still...
> 
> I think there is no problem as there is no scheduling activity.
> 
I concur. I'm wondering whether it's worth adding a brief comment about
it. If it were me doing this, I most likely would.

> > > In restore_vcpu_affinity() we should be careful when applying
> > > affinity
> > > as the cpu might not have come back to life. 
> > > 
> > But restore_vcpu_affinity() is done, in a loop, for all vcpus of
> > all
> > domains, in thaw_domains(), which in turn comes after
> > enable_nonboot_cpus(), which I think is supposed to bring every CPU
> > back up What am I missing?
> 
> There is no guarantee all cpus will be up after suspend. Some might
> fail coming up.
> 
Ah, ok, that's the case we're trying to address. I didn't get it in the
first place.

And this, in fact, was what I was missing, and the reason why I was
finding some aspects of the patch a little weird. :-P

So, can we state this a bit better in the changelog, and also in a
comment? I'd like the reason why we break the affinity in a function
called "repair_affinity" to be more obvious. :-P

> > > diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
> > > index e89bb67e71..7b5ce18426 100644
> > > --- a/xen/common/cpupool.c
> > > +++ b/xen/common/cpupool.c
> > > @@ -313,7 +313,7 @@ static long cpupool_unassign_cpu_helper(void
> > > *info)
> > >   * cpu_disable_scheduler(), and at the bottom of this
> > > function.
> > >   */
> > >  rcu_read_lock(&domlist_read_lock);
> > > -ret = cpu_disable_scheduler(cpu);
> > > +ret = (system_state == SYS_STATE_suspend) ? 0 :
> > > cpu_disable_scheduler(cpu);
> > > 
> > Mmm... How can this function be called with state = STATE_suspend ?
> 
> Meh, my bad. I masked the wrong call of cpu_disable_scheduler().
> Should
> have been that from __cpu_disable().
> 
Yes, that should be the one.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/sched: fix credit2 smt idle handling

[Juergen Gross]

On 25/03/2019 11:53, Dario Faggioli wrote:
> On Sat, 2019-03-23 at 14:22 +0100, Juergen Gross wrote:
>> On 23/03/2019 03:32, Dario Faggioli wrote:
>>> To properly deal with offline CPUs, I think we can change the logic
>>> a
>>> little, i.e., we initialize the smt_idle mask to all-1 (all CPUs
>>> idle),
>>> and we also make sure that we set the CPU bit (instead of learing
>>> it)
>>> in smt_idle, when we remove the CPU from the scheduler.
>>
>> How does that help?
>>
>> Only if all siblings are marked as idle in rqd->idle we set any bits
>> in rqd->smt_idle (all siblings).
>>
>> Or did you mean rqd->idle instead?
>>
> Yep, indeed I was thinking to rqd->idle, sorry for the confusion. :-)
> 
>> This might be problematic in case of runqueue per cpu, though.
>>
> Mmm... So, my point here is, when a CPU does not belong to a scheduler
> (and, in case of Credit2, even when it does not belong to a runqueue)
> we "consider" it as being either idle or busy, depending on whether we
> set or clear the relevant bit.
> 
> But truth is, we don't have a way to know if it is really idle or not,
> so we really shouldn't rely on such info.
> 
> Therefore, we should:
> - make sure that we actually don't, or it's a bug (which is the point
> of this patch ;-P)
> - decide whether to set or clear the bit basing on what's more
> convenient (e.g., because it saves some cpumask operation).
> 
> Anyway...
> 
>> Another idea: we could introduce a credit2 pcpu data cpumask pointer
>> for replacement of the cpu_sibling_mask. For runqueue per cpu it
>> would
>> pount to cpumask_of(cpu), for the "normal case" it would point to the
>> correct cpu_sibling_mask, and for special cases we could allocate a
>> mask if needed.
>>
> ... I think I am fine with this idea.

Preparing V2 of the patch...


Juergen


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

Re: [Xen-devel] [PATCH v1] x86/microcode: always collect_cpu_info() during boot

[Chao Gao]

On Mon, Mar 25, 2019 at 11:12:17AM +, Sergey Dyasli wrote:
>Currently cpu_sig struct is not updated during boot when either:
>
>1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>2. initrd does not contain a microcode blob
>
>These will result in cpu_sig.rev being 0 which affects APIC's
>check_deadline_errata() and retpoline_safe() functions.
>
>Fix this by getting ucode revision early during boot and SMP bring up.
>While at it, protect early_microcode_update_cpu() for cases when
>microcode_ops is NULL.
>
>Signed-off-by: Sergey Dyasli 

Reviewed-by: Chao Gao 

Thanks
Chao

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

Re: [Xen-devel] [PATCH] CI: Add a CentOS 6 container and build jobs

[Wei Liu]

On Mon, Mar 25, 2019 at 11:21:44AM +, Wei Liu wrote:
> On Fri, Mar 22, 2019 at 11:13:40AM +, Andrew Cooper wrote:
> > CentOS 6 is probably the most frequently broken build, so adding it to CI
> > would be a very good move.
> > 
> > One problem is that CentOS 6 comes with Python 2.6, and Qemu requires 2.7.
> > There appear to be no sensible ways to get Python 2.7 into a CentOS 6
> > environments, so modify the build script to skip the Qemu upstream build
> > instead.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Acked-by: Wei Liu 

Just saw your thread on seabios list -- do you want to exclude seabios
build in CentOS 6?

Wei.

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

Re: [Xen-devel] [PATCH] CI: Fix indentation in containerize script

[Wei Liu]

On Fri, Mar 22, 2019 at 11:12:28AM +, Andrew Cooper wrote:
> The script is mostly indented with spaces, but there are three tabs.  Fix them
> up to be consistent.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

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] CI: Add a CentOS 6 container and build jobs

[Wei Liu]

On Fri, Mar 22, 2019 at 11:13:40AM +, Andrew Cooper wrote:
> CentOS 6 is probably the most frequently broken build, so adding it to CI
> would be a very good move.
> 
> One problem is that CentOS 6 comes with Python 2.6, and Qemu requires 2.7.
> There appear to be no sensible ways to get Python 2.7 into a CentOS 6
> environments, so modify the build script to skip the Qemu upstream build
> instead.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH v1] x86/microcode: always collect_cpu_info() during boot

[Sergey Dyasli]

Currently cpu_sig struct is not updated during boot when either:

1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
2. initrd does not contain a microcode blob

These will result in cpu_sig.rev being 0 which affects APIC's
check_deadline_errata() and retpoline_safe() functions.

Fix this by getting ucode revision early during boot and SMP bring up.
While at it, protect early_microcode_update_cpu() for cases when
microcode_ops is NULL.

Signed-off-by: Sergey Dyasli 
---
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Wei Liu 
CC: "Roger Pau Monné" 
CC: Chao Gao 
---
 xen/arch/x86/microcode.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 4163f50bb7..421d57e925 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -383,10 +383,15 @@ static struct notifier_block microcode_percpu_nfb = {
 
 int __init early_microcode_update_cpu(bool start_update)
 {
+unsigned int cpu = smp_processor_id();
+struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
 int rc = 0;
 void *data = NULL;
 size_t len;
 
+if ( !microcode_ops )
+return -ENOSYS;
+
 if ( ucode_blob.size )
 {
 len = ucode_blob.size;
@@ -397,6 +402,9 @@ int __init early_microcode_update_cpu(bool start_update)
 len = ucode_mod.mod_end;
 data = bootstrap_map(&ucode_mod);
 }
+
+microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
+
 if ( data )
 {
 if ( start_update && microcode_ops->start_update )
@@ -413,6 +421,8 @@ int __init early_microcode_update_cpu(bool start_update)
 
 int __init early_microcode_init(void)
 {
+unsigned int cpu = smp_processor_id();
+struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
 int rc;
 
 rc = microcode_init_intel();
@@ -425,6 +435,8 @@ int __init early_microcode_init(void)
 
 if ( microcode_ops )
 {
+microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
+
 if ( ucode_mod.mod_end || ucode_blob.size )
 rc = early_microcode_update_cpu(true);
 
-- 
2.17.1


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

Re: [Xen-devel] [PATCH] xen/sched: fix credit2 smt idle handling

[Dario Faggioli]

On Sat, 2019-03-23 at 14:22 +0100, Juergen Gross wrote:
> On 23/03/2019 03:32, Dario Faggioli wrote:
> > To properly deal with offline CPUs, I think we can change the logic
> > a
> > little, i.e., we initialize the smt_idle mask to all-1 (all CPUs
> > idle),
> > and we also make sure that we set the CPU bit (instead of learing
> > it)
> > in smt_idle, when we remove the CPU from the scheduler.
> 
> How does that help?
> 
> Only if all siblings are marked as idle in rqd->idle we set any bits
> in rqd->smt_idle (all siblings).
> 
> Or did you mean rqd->idle instead?
> 
Yep, indeed I was thinking to rqd->idle, sorry for the confusion. :-)

> This might be problematic in case of runqueue per cpu, though.
> 
Mmm... So, my point here is, when a CPU does not belong to a scheduler
(and, in case of Credit2, even when it does not belong to a runqueue)
we "consider" it as being either idle or busy, depending on whether we
set or clear the relevant bit.

But truth is, we don't have a way to know if it is really idle or not,
so we really shouldn't rely on such info.

Therefore, we should:
- make sure that we actually don't, or it's a bug (which is the point
of this patch ;-P)
- decide whether to set or clear the bit basing on what's more
convenient (e.g., because it saves some cpumask operation).

Anyway...

> Another idea: we could introduce a credit2 pcpu data cpumask pointer
> for replacement of the cpu_sibling_mask. For runqueue per cpu it
> would
> pount to cpumask_of(cpu), for the "normal case" it would point to the
> correct cpu_sibling_mask, and for special cases we could allocate a
> mask if needed.
> 
... I think I am fine with this idea.

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xen: Add "xen_timer_slop" command line option

[Dario Faggioli]

On Sun, 2019-03-24 at 14:07 -0400, Boris Ostrovsky wrote:
> On Sat, Mar 23, 2019 at 08:00:52AM -0400, Ryan Thibodeaux wrote:
> > This test system was configured to use a TSC clocksource, disabled
> > C states, and lowered the timer slop. I am not claiming the timer
> > slop change was solely responsible for the best results.
> 
> How can we then be sure that the proposed change will indeed provide
> some sort of benefit?
> 
> Were there any other changes between your tests to think that slop
> time modification may not be responsible for better results?
> 
FWIW, in mine and Luca's experiments, changing lowering both timer_slop
in Xen and TIMER_SLOP in Linux, improved latency dramatically, without
any other change.

We also tried _only_ playing with the Xen tunable (as there's a Xen
boot parameter for it already) but that wasn't enough. It was only when
we also tuned TIMER_SLOP in Linux's Xen clockevent device that we got
decent numbers (i.e., comparable to KVM ones).

Reason why we had not share these results yet was that we were still
"polishing" them, and because we also found a couple of other issues,
and we were trying to understand them better, before sending anything
out. But those other issues were --although still about achieving low
latencies-- orthogonal from this, and lowering the default slop is
absolute prerequisite for even talking about having a reasonable vcpu
response time.

A patch like this one, was something we were thinking to submit ourself
sooner or later (backed up by our results). Personally, in addition to
making the value tunable, which I think is a good thing, I also would
lower the default.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] vsprintf: Remove support for %pF and %pf in favour of %pS and %ps

[Rafael J. Wysocki]

On Mon, Mar 25, 2019 at 10:30 AM Rafael J. Wysocki  wrote:
>
> On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus
>  wrote:
> >
> > %pS and %ps are now the preferred conversion specifiers to print function
> > %names. The functionality is equivalent; remove the old, deprecated %pF
> > %and %pf support.
>
> Are %pF and %pf really not used any more in the kernel?
>
> If that is not the case, you need to convert the remaining users of
> them to using %ps or %pS before making support for them go away
> completely.

Well, this is a [2/2] in a series, sorry for the noise (/me blames
gmail for the confusion).

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

Re: [Xen-devel] [PATCH v6 01/12] misc/xenmicrocode: Upload a microcode blob to the hypervisor

[Sergey Dyasli]

On 11/03/2019 07:57, Chao Gao wrote:
> This patch provides a tool for late microcode update.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> Signed-off-by: Chao Gao 
> ---
>  tools/libxc/include/xenctrl.h |  1 +
>  tools/libxc/xc_misc.c | 20 ++
>  tools/misc/Makefile   |  4 ++
>  tools/misc/xenmicrocode.c | 89 
> +++
>  4 files changed, 114 insertions(+)
>  create mode 100644 tools/misc/xenmicrocode.c
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 31cdda7..c69699b 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1245,6 +1245,7 @@ typedef uint32_t xc_node_to_node_dist_t;
>  int xc_physinfo(xc_interface *xch, xc_physinfo_t *info);
>  int xc_cputopoinfo(xc_interface *xch, unsigned *max_cpus,
> xc_cputopo_t *cputopo);
> +int xc_platform_op(xc_interface *xch, struct xen_platform_op *op);
>  int xc_numainfo(xc_interface *xch, unsigned *max_nodes,
>  xc_meminfo_t *meminfo, uint32_t *distance);
>  int xc_pcitopoinfo(xc_interface *xch, unsigned num_devs,
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> index 5e6714a..061c7a5 100644
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -226,6 +226,26 @@ int xc_physinfo(xc_interface *xch,
>  return 0;
>  }
>  
> +int xc_platform_op(xc_interface *xch, struct xen_platform_op *op)
> +{
> +int ret = 0;
> +DECLARE_PLATFORM_OP;
> +DECLARE_HYPERCALL_BOUNCE(op, sizeof(*op), 
> XC_HYPERCALL_BUFFER_BOUNCE_BOTH);

So I've found that the bouncing in this function is not needed.
In fact, it gets in a way when Xen is returning information via xen_platform_op.
I ended up having only the single line in this function:

return do_platform_op(xch, op);

Not sure how correct this is, but it seems to work for ucode application and
XENPF_get_cpu_version.

Thanks,
Sergey

> +
> +if ( xc_hypercall_bounce_pre(xch, op) )
> +{
> +PERROR("Could not bounce xen_platform_op memory buffer");
> +return -1;
> +}
> +op->interface_version = XENPF_INTERFACE_VERSION;
> +
> +platform_op = *op;
> +ret = do_platform_op(xch, &platform_op);
> +xc_hypercall_bounce_post(xch, op);
> +
> +return ret;
> +}
> +
>  int xc_cputopoinfo(xc_interface *xch, unsigned *max_cpus,
> xc_cputopo_t *cputopo)
>  {
> diff --git a/tools/misc/Makefile b/tools/misc/Makefile
> index 51adb6f..c297a75 100644
> --- a/tools/misc/Makefile
> +++ b/tools/misc/Makefile
> @@ -22,6 +22,7 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-hvmcrash
>  INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx
>  INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
>  INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
> +INSTALL_SBIN-$(CONFIG_X86) += xenmicrocode
>  INSTALL_SBIN   += xen-tmem-list-parse
>  INSTALL_SBIN   += xencov
>  INSTALL_SBIN   += xenlockprof
> @@ -114,4 +115,7 @@ xen-lowmemd: xen-lowmemd.o
>  xencov: xencov.o
>   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
>  
> +xenmicrocode: xenmicrocode.o
> + $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> +
>  -include $(DEPS_INCLUDE)
> diff --git a/tools/misc/xenmicrocode.c b/tools/misc/xenmicrocode.c
> new file mode 100644
> index 000..e6c8a3d
> --- /dev/null
> +++ b/tools/misc/xenmicrocode.c
> @@ -0,0 +1,89 @@
> +#define _GNU_SOURCE
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void show_help(void)
> +{
> +fprintf(stderr,
> +"xenmicrocode: Xen microcode updating tool\n"
> +"Usage: xenmicrocode \n");
> +}
> +
> +int main(int argc, char *argv[])
> +{
> +int fd, len, ret;
> +char *filename, *buf;
> +struct stat st;
> +struct xen_platform_op op;
> +xc_interface *xch;
> +DECLARE_HYPERCALL_BUFFER(struct xenpf_microcode_update, uc);
> +
> +if (argc < 2)
> +{
> +show_help();
> +return 0;
> +}
> +
> +filename = argv[1];
> +fd = open(filename, O_RDONLY);
> +if (fd < 0) {
> +fprintf(stderr, "Could not open %s. (err: %s)\n",
> +filename, strerror(errno));
> +return errno;
> +}
> +
> +if (stat(filename, &st) != 0) {
> +fprintf(stderr, "Could not get the size of %s. (err: %s)\n",
> +filename, strerror(errno));
> +return errno;
> +}
> +
> +len = st.st_size;
> +buf = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, 0);
> +if (buf == MAP_FAILED) {
> +fprintf(stderr, "mmap failed. (error: %s)\n", strerror(errno));
> +return errno;
> +}
> +
> +xch = xc_interface_open(0,0,0);
> +if (xch == NULL)
> +{
> +fprintf(stderr, "Error opening xc interface. (err: %s)\n",
> +strerror(errno));
> +return errno;
> +}

Re: [Xen-devel] [PATCH 1/2] treewide: Switch printk users from %pf and %pF to %ps and %pS, respectively

[Rafael J. Wysocki]

On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus
 wrote:
>
> %pF and %pf are functionally equivalent to %pS and %ps conversion
> specifiers. The former are deprecated, therefore switch the current users
> to use the preferred variant.
>
> The changes have been produced by the following command:
>
> git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \
> while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done
>
> And verifying the result.
>
> Signed-off-by: Sakari Ailus 

Acked-by: Rafael J. Wysocki 

> ---
>  arch/alpha/kernel/pci_iommu.c   | 20 ++--
>  arch/arm/mach-imx/pm-imx6.c |  2 +-
>  arch/arm/mm/alignment.c |  2 +-
>  arch/arm/nwfpe/fpmodule.c   |  2 +-
>  arch/microblaze/mm/pgtable.c|  2 +-
>  arch/sparc/kernel/ds.c  |  2 +-
>  arch/um/kernel/sysrq.c  |  2 +-
>  arch/x86/include/asm/trace/exceptions.h |  2 +-
>  arch/x86/kernel/irq_64.c|  2 +-
>  arch/x86/mm/extable.c   |  4 ++--
>  arch/x86/xen/multicalls.c   |  2 +-
>  drivers/acpi/device_pm.c|  2 +-
>  drivers/base/power/main.c   |  6 +++---
>  drivers/base/syscore.c  | 12 ++--
>  drivers/block/drbd/drbd_receiver.c  |  2 +-
>  drivers/block/floppy.c  | 10 +-
>  drivers/cpufreq/cpufreq.c   |  2 +-
>  drivers/mmc/core/quirks.h   |  2 +-
>  drivers/nvdimm/bus.c|  2 +-
>  drivers/nvdimm/dimm_devs.c  |  2 +-
>  drivers/pci/pci-driver.c| 14 +++---
>  drivers/pci/quirks.c|  4 ++--
>  drivers/pnp/quirks.c|  2 +-
>  drivers/scsi/esp_scsi.c |  2 +-
>  fs/btrfs/tests/free-space-tree-tests.c  |  4 ++--
>  fs/f2fs/f2fs.h  |  2 +-
>  fs/pstore/inode.c   |  2 +-
>  include/trace/events/btrfs.h|  2 +-
>  include/trace/events/cpuhp.h|  4 ++--
>  include/trace/events/preemptirq.h   |  2 +-
>  include/trace/events/rcu.h  |  4 ++--
>  include/trace/events/sunrpc.h   |  2 +-
>  include/trace/events/timer.h|  8 
>  include/trace/events/vmscan.h   |  4 ++--
>  include/trace/events/workqueue.h|  4 ++--
>  include/trace/events/xen.h  |  2 +-
>  init/main.c |  6 +++---
>  kernel/async.c  |  4 ++--
>  kernel/events/uprobes.c |  2 +-
>  kernel/fail_function.c  |  2 +-
>  kernel/irq/debugfs.c|  2 +-
>  kernel/irq/handle.c |  2 +-
>  kernel/irq/manage.c |  2 +-
>  kernel/irq/spurious.c   |  4 ++--
>  kernel/rcu/tree.c   |  2 +-
>  kernel/stop_machine.c   |  2 +-
>  kernel/time/sched_clock.c   |  2 +-
>  kernel/time/timer.c |  2 +-
>  kernel/workqueue.c  | 12 ++--
>  lib/error-inject.c  |  2 +-
>  lib/percpu-refcount.c   |  4 ++--
>  mm/memblock.c   | 12 ++--
>  mm/memory.c |  2 +-
>  mm/vmscan.c |  2 +-
>  net/ceph/osd_client.c   |  2 +-
>  net/core/net-procfs.c   |  2 +-
>  net/core/netpoll.c  |  4 ++--
>  57 files changed, 109 insertions(+), 109 deletions(-)
>
> diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
> index 3034d6d936d2..242108439f42 100644
> --- a/arch/alpha/kernel/pci_iommu.c
> +++ b/arch/alpha/kernel/pci_iommu.c
> @@ -249,7 +249,7 @@ static int pci_dac_dma_supported(struct pci_dev *dev, u64 
> mask)
> ok = 0;
>
> /* If both conditions above are met, we are fine. */
> -   DBGA("pci_dac_dma_supported %s from %pf\n",
> +   DBGA("pci_dac_dma_supported %s from %ps\n",
>  ok ? "yes" : "no", __builtin_return_address(0));
>
> return ok;
> @@ -281,7 +281,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, 
> size_t size,
> && paddr + size <= __direct_map_size) {
> ret = paddr + __direct_map_base;
>
> -   DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %pf\n",
> +   DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %ps\n",
>   cpu_addr, size, ret, __builtin_return_address(0));
>
> return ret;
> @@ -292,7 +292,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, 
> size_t size,
> if (dac_allowed) {
> ret = paddr + alpha_mv.pci_dac_offset;
>
> -   DBGA2("pci_map_single: [%p,%zx] -> DAC %llx from %pf\n",
> +   DBGA2("pci_map_single: [%p,%zx] -> DAC %llx from %ps\n",
>

Re: [Xen-devel] [PATCH 2/2] vsprintf: Remove support for %pF and %pf in favour of %pS and %ps

[Rafael J. Wysocki]

On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus
 wrote:
>
> %pS and %ps are now the preferred conversion specifiers to print function
> %names. The functionality is equivalent; remove the old, deprecated %pF
> %and %pf support.

Are %pF and %pf really not used any more in the kernel?

If that is not the case, you need to convert the remaining users of
them to using %ps or %pS before making support for them go away
completely.

That said, checkpatch can be made treat %pf/F as invalid format right away IMO.

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

Re: [Xen-devel] [PATCH v3] x86/mm: Clean up p2m_finish_type_change return value

[Paul Durrant]

> -Original Message-
> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> Sent: 22 March 2019 12:09
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
> ; Wei Liu ; Roger Pau Monne 
> ;
> George Dunlap ; Alexandru Stefan ISAILA 
> 
> Subject: [PATCH v3] x86/mm: Clean up p2m_finish_type_change return value
> 
> In the case of any errors, finish_type_change() passes values returned
> from p2m->recalc() up the stack (with some exceptions in the case where
> an error is expected); this eventually ends up being returned to the
> XEN_DOMOP_map_mem_type_to_ioreq_server hypercall.
> 
> However, on Intel processors (but not on AMD processor), p2m->recalc()
> can also return '1' as well as '0'.  This case is handled very
> inconsistently: finish_type_change() will return the value of the final
> entry it attempts, discarding results for other entries;
> p2m_finish_type_change() will attempt to accumulate '1's, so that it
> returns '1' if any of the calls to finish_type_change() returns '1'; and
> dm_op() will again return '1' only if the very last call to
> p2m_finish_type_change() returns '1'.  The result is that the
> XEN_DMOP_map_mem_type_to_ioreq_server() hypercall will sometimes return
> 0 and sometimes return 1 on success, in an unpredictable manner.
> 
> The hypercall documentation doesn't mention return values; but it's not
> clear what the caller could do with the information about whether
> entries had been changed or not.  At the moment it's always 0 on AMD
> boxes, and *usually* 1 on Intel boxes; so nothing can be relying on a
> '1' return value for correctness (or if it is, it's broken).
> 
> Make the return value on success consistently '0' by only returning
> 0/-ERROR from finish_type_change().  Also remove the accumulation code
> from p2m_finish_type_change().

Sorry, I don't think I was cc-ed on the original and I managed to miss George 
cc-ing me on his response to v2. Digging into the code a bit I can't honestly 
see what the point of returning anything other than 0/-errno out of p2m->recalc 
is. The only use of rc > 0 from p2m-ept.c:resolve_misconfig() is in 
ept_handle_misconfig() AFAICT so it would make more sense to me to tighten up 
the semantics of recalc (which I believe Jan suggested in response to v1) and 
turn any > 0 return from resolve_misconfig() into 0. So, the code below looks 
fine but the patch just needs to do a little more (and then your rc < 0 test 
can also be simplified to !rc too).

  Paul

> 
> Suggested-by: George Dunlap 
> Signed-off-by: Alexandru Isaila 
> 
> ---
> Changes since V2:
>   - Update commit msg.
> ---
>  xen/arch/x86/mm/p2m.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index b9bbb8f485..bcf8cad423 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1213,22 +1213,17 @@ int p2m_finish_type_change(struct domain *d,
>  if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
>  {
>  struct p2m_domain *altp2m = d->arch.altp2m_p2m[i];
> -int rc1;
> 
>  p2m_lock(altp2m);
> -rc1 = finish_type_change(altp2m, first_gfn, max_nr);
> +rc = finish_type_change(altp2m, first_gfn, max_nr);
>  p2m_unlock(altp2m);
> 
> -if ( rc1 < 0 )
> -{
> -rc = rc1;
> +if ( rc < 0 )
>  goto out;
> -}
> -
> -rc |= rc1;
>  }
>  }
>  #endif
> +rc = 0;
> 
>   out:
>  p2m_unlock(hostp2m);
> --
> 2.17.1


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

Re: [Xen-devel] [PATCH] x86/AMD: correct certain Fam17 checks

[Jan Beulich]

>>> On 22.03.19 at 20:56,  wrote:
> On 19/03/2019 09:16, Jan Beulich wrote:
>> Commit 3157bb4e13 ("Add MSR support for various feature AMD processor
>> families") converted certain checks for Fam11 to include families all
>> the way up to Fam17. The commit having no description, it is hard to
>> tell whether this was a mechanical dec->hex conversion mistake, or
>> indeed intended. In any event the NB_CFG handling needs to be restricted
>> to Fam16 and below: Fam17 doesn't have such an MSR anymore.
>>
>> A non-MMCFG extended config space access mechanism still appears to
>> exist, but code to deal with it will need to be written down the road,
>> when it can actually be tested.
>>
>> Reported-by: Pu Wen 
>> Signed-off-by: Jan Beulich 
> 
> Having looked through various spec documents, this is a chronic mess.
> 
> First, to NB_CTL MSR itself.  It certainly is documented in Fam15, and
> is absence in the documentation of Fam17.
> 
> In Fam15, it is explicitly documented as an alias of
> 00:18.3[NB_CFG_LOW/HIGH] which are registers at offset 0x88 and 0x8c in
> config space.
> 
> Fam17 documents that the extended cfc/cf8 mechanism does still exist,
> and the new controls for that found in 00:18.4[CoreMasterAccessCtrl]
> with a different bit layout.
> 
> Experimentation on a Rome system indicates that NB_CTL is fully
> read0/write discard, so this patch is probably an improvement.

Hmm, if it's read-zero / write-discard, then I guess we would better
emulate that behavior. I simply didn't expect it to be that way, as
I would generally assume undocumented _and_ unused MSRs to
raise #GP. In which case the simplest thing to do would be to drop
the one respective hunk changing emul-priv-op.c:write_msr().

> Therefore, in principle, Acked-by: Andrew Cooper 

Well, even without the point above I wouldn't be sure whether
using an "in principle" ack as justification for committing is
appropriate. So perhaps (see above and below) we'd better
settle on something that you could agree to with less
reservations (by directly adjusting this patch, or by adding a
2nd one on top).

> However, the actual code touched is completely insane.
> 
> HVM guests have it automatically read0/write discard, even for Intel
> (citing cross vendor migration).
> 
> PV guest handling is complicated.  For CPUs without the MSR, it is read
> #GP, write discard.  For CPUs which do have the MSR, it is read0/write
> discard for domU or nonpinned dom0, which is 100% of usecases.  The PV
> vs HVM differences cause an asymetry for the hardware domain.

So how about we make it uniformly read-zero / write-discard, as long
as the emulated CPUID has vendor AMD and family 0x10 and higher?
Or even independent of vendor and family, to fully match current
HVM behavior?

> A pinned PV dom0 is permitted to change just the IO_ECS bit, eliciting a
> warning but no #GP for modifying other bits.  As NB_CTL is a per-node
> control (not a per-core control), unless dom0 vcpus == host pcpus, this
> creates an asymmetry across the system as to whether IO_ECS is enabled
> or not.

Correct, but there's no inconsistency from Dom0's POV. Furthermore,
as you explain further down, the PCI config space method of changing
the bit was specifically added to Linux to avoid this inconsistency.

> The HVM IOREQ path, and PV cfg_ok() path, when seeing an IO_ECS access
> from the guest, reads the MSR every time, which is results in behaviour
> which doesn't match the settings a guest can see, and comes with a
> massive perf hit.

Indeed it should be the guest view of the MSR which ought to be used
there.

>  It also means the behaviour of the guest IO depends
> on which node it is currently scheduled on.

If Dom0 enabled things in an asymmetric way.

> The IO_ECS setting should be chosen once at boot, made consistent across
> the entire system, and never touched at runtime.

I don't fully agree (but it somewhat depends on what "at boot" is
supposed to mean in your reply): We should leave the choice to Dom0,
but it would probably not hurt to enforce a consistent setting. Doing
this when Dom0 uses the MSR method would be relatively easy, but
then again Dom0 shouldnt use that approach anyway. Doing this
when Dom0 uses PCI config space writes would be less straightforward,
as we'd have to write protect the north bridge devices' config spaces.
Which wouldn't be very useful imo, as Dom0 - if it already uses the
PCI config space approach - would update all north bridges anyway.

> In all cases for guests, we can offer MMCFG even on a system which
> doesn't have IO_ECS, and they will prefer that.  The behaviour of the
> extra 4 bits is reserved, so we could have IO_ECS working in practice
> with no signal.  However, we could equally drop IO_ECS entirely.  Guests
> can't find its setting to begin with, so can't reliably use it, and also
> wouldn't in the presence of MMCFG anyway.

All this assuming that platforms correctly surface MMCFG. This not
having been the case in at least the Fam10 days was

Re: [Xen-devel] [PATCH v2] x86/atomic: Improvements and simplifications to assembly constraints

[Jan Beulich]

>>> On 22.03.19 at 21:19,  wrote:
> On 18/03/2019 14:58, Jan Beulich wrote:
> On 18.03.19 at 15:11,  wrote:
>>> On 18/03/2019 13:20, Jan Beulich wrote:
  >>> On 18.03.19 at 12:27,  wrote:
> * Some of the single-byte versions specify "=q" as the output.  This is a
>remnent of the 32bit build and can be relaxed to "=r" in 64bit builds.
 I have to admit that I don't understand the "relaxed" part of this:
 "q" and "r" represent the exact same set of registers on 64-bit.
 Unless the conversion allows further code folding, I think it wouldn't
 be a bad idea to retain the distinction, just for cases like code
 eventually getting shared via something like lib/x86/.
>>> The change from =q to =r is specifically to allow the folding to +r
>> Hmm, I still don't understand. "+q" is as valid as "+r". And "q" does
>> not make any size implications, i.e. registers in that group aren't
>> implicitly byte ones (albeit this aspect doesn't even matter here).
> 
> I'm at a complete loss to understand what you are objecting to here.

The main point of my comment is your use of the word "relax" when
there's nothing you really relax (afaics - below you confirm yourself
that the two are synonyms on 64-bit).

> "q" and "r" mean different things on 32bit, and "+q" would be wrong to
> use there.

Why would "+q" be wrong? You want "q" (to constrain the register
set to those registers which are byte accessible) and you also want
"+" (as it's an in/out, and the folding from "=q" plus "0" is as valid as
the folding from "=r" plus "0" to "+r").

> "q" and "r" are synonymous on 64bit, but "r" is still the one to use
> because that is the more common constraint, and therefore the more
> familiar for people reading the code.

I understand this part of your argument; I don't see you responding
at all to the potential code re-usability point I've been making. Yet
there's weighing to be done between the two.

> @@ -40,28 +37,24 @@ static always_inline unsigned long __xchg(
>  switch ( size )
>  {
>  case 1:
> -asm volatile ( "xchgb %b0,%1"
> -   : "=q" (x)
> -   : "m" (*__xg(ptr)), "0" (x)
> -   : "memory" );
> +asm volatile ( "xchg %b[x], %[ptr]"
> +   : [x] "+r" (x), [ptr] "+m" (*(uint8_t *)ptr)
> +   :: "memory" );
>  break;
>  case 2:
> -asm volatile ( "xchgw %w0,%1"
> -   : "=r" (x)
> -   : "m" (*__xg(ptr)), "0" (x)
> -   : "memory" );
> +asm volatile ( "xchg %w[x], %[ptr]"
> +   : [x] "+r" (x), [ptr] "+m" (*(uint16_t *)ptr)
> +   :: "memory" );
>  break;
>  case 4:
> -asm volatile ( "xchgl %k0,%1"
> -   : "=r" (x)
> -   : "m" (*__xg(ptr)), "0" (x)
> -   : "memory" );
> +asm volatile ( "xchg %k[x], %[ptr]"
> +   : [x] "+r" (x), [ptr] "+m" (*(uint32_t *)ptr)
> +   :: "memory" );
>  break;
>  case 8:
> -asm volatile ( "xchgq %0,%1"
> -   : "=r" (x)
> -   : "m" (*__xg(ptr)), "0" (x)
> -   : "memory" );
> +asm volatile ( "xchg %q[x], %[ptr]"
> +   : [x] "+r" (x), [ptr] "+m" (*(uint64_t *)ptr)
> +   :: "memory" );
>  break;
 Is the q modifier really useful to have here (and elsewhere below)?
>>> Yes - it is strictly necessary, because otherwise it gets derived from
>>> the type of (x) which is unsigned long even in the smaller size constructs.
>> What you say explains why you need the b, w, and k modifiers. It
>> doesn't explain the q one, since sizeof(unsigned long) is 8 and
>> hence exactly what would result without the modifier.
> 
> Oh, in which case, "for consistency".

Well, okay, albeit along the lines of the code re-usability point made
before (and mentioned above) personally I'd prefer if we kept the
code in a shape where it could _in principle_ be (easily) re-used for
32-bit.

Jan


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