[PATCH v2 3/3] tools/xl: Allow specifying JSON for domain configuration file format

[Elliott Mitchell]

JSON is currently used when saving domains to mass storage.  Being able
to use JSON as the normal input to `xl create` has potential to be
valuable.  Add the functionality.

Move the memset() earlier so to allow use of the structure sooner.

Signed-off-by: Elliott Mitchell 
---
v2:
Removing the UUOC situation.  Correct the comparison to match the correct
variable type.  Rename to "config_format" from "format".

Rename everything from "format" to "config_format".
---
 tools/xl/xl.h   |  5 +
 tools/xl/xl_cmdtable.c  |  2 ++
 tools/xl/xl_vmcontrol.c | 12 ++--
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 72538d6a81..4b0828431f 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -48,6 +48,11 @@ struct domain_create {
 int migrate_fd; /* -1 means none */
 int send_back_fd; /* -1 means none */
 char **migration_domname_r; /* from malloc */
+enum {
+CONFIG_FORMAT_DEFAULT,
+CONFIG_FORMAT_JSON,
+CONFIG_FORMAT_LEGACY,
+} config_format; /* format specified for configuration */
 };
 
 int create_domain(struct domain_create *dom_info);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 35182ca196..8a791d8c49 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -30,6 +30,8 @@ const struct cmd_spec cmd_table[] = {
   "-F  Run in foreground until death of the domain.\n"
   "-f FILE, --defconfig=FILE\n Use the given 
configuration file.\n"
   "-h  Print this help.\n"
+  "-j, --json  Interpret configuration file as JSON format\n"
+  "-J  Use traditional configuration file format 
(current default)\n"
   "-n, --dryrunDry run - prints the resulting configuration\n"
   " (deprecated in favour of global -N option).\n"
   "-p  Leave the domain paused after it is created.\n"
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 4bf041fb01..dd8b3f81a6 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -789,7 +789,7 @@ int create_domain(struct domain_create *dom_info)
 extra_config);
 }
 config_source=config_file;
-config_in_json = false;
+config_in_json = dom_info->config_format == CONFIG_FORMAT_JSON;
 } else {
 if (!config_data) {
 fprintf(stderr, "Config file not specified and"
@@ -1167,6 +1167,7 @@ int main_create(int argc, char **argv)
 struct domain_create dom_info = {
 /* Command-line options */
 .config_file = NULL,
+.config_format = CONFIG_FORMAT_DEFAULT,
 .console_autoconnect = 0,
 .debug = 0,
 .daemonize = 1,
@@ -1189,6 +1190,7 @@ int main_create(int argc, char **argv)
 {"defconfig", 1, 0, 'f'},
 {"dryrun", 0, 0, 'n'},
 {"ignore-global-affinity-masks", 0, 0, 'i'},
+{"json", 0, 0, 'j'},
 {"quiet", 0, 0, 'q'},
 {"vncviewer", 0, 0, 'V'},
 {"vncviewer-autopass", 0, 0, 'A'},
@@ -1200,13 +1202,16 @@ int main_create(int argc, char **argv)
 argc--; argv++;
 }
 
-SWITCH_FOREACH_OPT(opt, "AFVcdef:inpq", opts, "create", 0) {
+SWITCH_FOREACH_OPT(opt, "AFJVcdef:ijnpq", opts, "create", 0) {
 case 'A':
 dom_info.vnc = dom_info.vncautopass = 1;
 break;
 case 'F':
 dom_info.daemonize = 0;
 break;
+case 'J':
+dom_info.config_format = CONFIG_FORMAT_LEGACY;
+break;
 case 'V':
 dom_info.vnc = 1;
 break;
@@ -1226,6 +1231,9 @@ int main_create(int argc, char **argv)
 case 'i':
 dom_info.ignore_global_affinity_masks = 1;
 break;
+case 'j':
+dom_info.config_format = CONFIG_FORMAT_JSON;
+break;
 case 'n':
 dryrun_only = 1;
 break;
-- 
2.30.2

[PATCH v2 2/3] tools/xl: Use sparse init for dom_info, remove duplicate vars

[Elliott Mitchell]

Rather than having shadow variables for every element of dom_info, it is
better to properly initialize dom_info at the start.  This also removes
the misleading memset() in the middle of main_create().

Remove the dryrun element of domain_create as that has been displaced
by the global "dryrun_only" variable.

Signed-off-by: Elliott Mitchell 
---
v2:
This was added due to the confusing situation with dom_info.
---
 tools/xl/xl.h   |  1 -
 tools/xl/xl_vmcontrol.c | 76 -
 2 files changed, 37 insertions(+), 40 deletions(-)

diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index c5c4bedbdd..72538d6a81 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -34,7 +34,6 @@ struct domain_create {
 int daemonize;
 int monitor; /* handle guest reboots etc */
 int paused;
-int dryrun;
 int quiet;
 int vnc;
 int vncautopass;
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index d081c6c290..4bf041fb01 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -854,8 +854,8 @@ int create_domain(struct domain_create *dom_info)
 }
 }
 
-if (debug || dom_info->dryrun) {
-FILE *cfg_print_fh = (debug && !dom_info->dryrun) ? stderr : stdout;
+if (debug || dryrun_only) {
+FILE *cfg_print_fh = (debug && !dryrun_only) ? stderr : stdout;
 if (default_output_format == OUTPUT_FORMAT_SXP) {
 printf_info_sexp(-1, _config, cfg_print_fh);
 } else {
@@ -873,7 +873,7 @@ int create_domain(struct domain_create *dom_info)
 
 
 ret = 0;
-if (dom_info->dryrun)
+if (dryrun_only)
 goto out;
 
 start:
@@ -1164,10 +1164,26 @@ out:
 
 int main_create(int argc, char **argv)
 {
-const char *filename = NULL;
-struct domain_create dom_info;
-int paused = 0, debug = 0, daemonize = 1, console_autoconnect = 0,
-quiet = 0, monitor = 1, vnc = 0, vncautopass = 0, ignore_masks = 0;
+struct domain_create dom_info = {
+/* Command-line options */
+.config_file = NULL,
+.console_autoconnect = 0,
+.debug = 0,
+.daemonize = 1,
+.ignore_global_affinity_masks = 0,
+.monitor = 1,
+.paused = 0,
+.quiet = 0,
+.vnc = 0,
+.vncautopass = 0,
+
+/* Extra configuration file settings */
+.extra_config = NULL,
+
+/* FDs, initialize to invalid */
+.migrate_fd = -1,
+.send_back_fd = -1,
+};
 int opt, rc;
 static const struct option opts[] = {
 {"defconfig", 1, 0, 'f'},
@@ -1179,58 +1195,54 @@ int main_create(int argc, char **argv)
 COMMON_LONG_OPTS
 };
 
-dom_info.extra_config = NULL;
-
 if (argv[1] && argv[1][0] != '-' && !strchr(argv[1], '=')) {
-filename = argv[1];
+dom_info.config_file = argv[1];
 argc--; argv++;
 }
 
 SWITCH_FOREACH_OPT(opt, "AFVcdef:inpq", opts, "create", 0) {
 case 'A':
-vnc = vncautopass = 1;
+dom_info.vnc = dom_info.vncautopass = 1;
 break;
 case 'F':
-daemonize = 0;
+dom_info.daemonize = 0;
 break;
 case 'V':
-vnc = 1;
+dom_info.vnc = 1;
 break;
 case 'c':
-console_autoconnect = 1;
+dom_info.console_autoconnect = 1;
 break;
 case 'd':
-debug = 1;
+dom_info.debug = 1;
 break;
 case 'e':
-daemonize = 0;
-monitor = 0;
+dom_info.daemonize = 0;
+dom_info.monitor = 0;
 break;
 case 'f':
-filename = optarg;
+dom_info.config_file = optarg;
 break;
 case 'i':
-ignore_masks = 1;
+dom_info.ignore_global_affinity_masks = 1;
 break;
 case 'n':
 dryrun_only = 1;
 break;
 case 'p':
-paused = 1;
+dom_info.paused = 1;
 break;
 case 'q':
-quiet = 1;
+dom_info.quiet = 1;
 break;
 }
 
-memset(_info, 0, sizeof(dom_info));
-
 for (; optind < argc; optind++) {
 if (strchr(argv[optind], '=') != NULL) {
 string_realloc_append(_info.extra_config, argv[optind]);
 string_realloc_append(_info.extra_config, "\n");
-} else if (!filename) {
-filename = argv[optind];
+} else if (!dom_info.config_file) {
+dom_info.config_file = argv[optind];
 } else {
 help("create");
 free(dom_info.extra_config);
@@ -1238,20 +1250,6 @@ int main_create(int argc, char **argv)
 }
 }
 
-dom_info.debug = debug;
-dom_info.daemonize = daemonize;
-dom_info.monitor = monitor;
-dom_info.paused = paused;
-dom_info.dryrun = dryrun_only;
-dom_info.quiet = quiet;
-dom_info.config_file = filename;
-dom_info.migrate_fd = -1;
-dom_info.send_back_fd = -1;
-dom_info.vnc = vnc;
-dom_info.vncautopass = vncautopass;
-dom_info.console_autoconnect = 

[PATCH v2 1/3] tools/xl: Sort create command options

[Elliott Mitchell]

Hopefully simplify future changes by sorting options lists for
`xl create`.  While at it, declare the options list constant.

Signed-off-by: Elliott Mitchell 
---
v2:
Adding mention of making the list constant.

Fix the getopt list sorting
---
 tools/xl/xl_cmdtable.c  | 12 ++--
 tools/xl/xl_vmcontrol.c | 40 
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 661323d488..35182ca196 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -24,16 +24,16 @@ const struct cmd_spec cmd_table[] = {
   _create, 1, 1,
   "Create a domain from config file ",
   " [options] [vars]",
-  "-h  Print this help.\n"
-  "-p  Leave the domain paused after it is created.\n"
   "-c  Connect to the console after the domain is 
created.\n"
+  "-d  Enable debug messages.\n"
+  "-e  Do not wait in the background for the death of 
the domain.\n"
+  "-F  Run in foreground until death of the domain.\n"
   "-f FILE, --defconfig=FILE\n Use the given 
configuration file.\n"
-  "-q, --quiet Quiet.\n"
+  "-h  Print this help.\n"
   "-n, --dryrunDry run - prints the resulting configuration\n"
   " (deprecated in favour of global -N option).\n"
-  "-d  Enable debug messages.\n"
-  "-F  Run in foreground until death of the domain.\n"
-  "-e  Do not wait in the background for the death of 
the domain.\n"
+  "-p  Leave the domain paused after it is created.\n"
+  "-q, --quiet Quiet.\n"
   "-V, --vncviewer Connect to the VNC display after the domain is 
created.\n"
   "-A, --vncviewer-autopass\n"
   "Pass VNC password to viewer via stdin.\n"
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 435155a033..d081c6c290 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -1169,13 +1169,13 @@ int main_create(int argc, char **argv)
 int paused = 0, debug = 0, daemonize = 1, console_autoconnect = 0,
 quiet = 0, monitor = 1, vnc = 0, vncautopass = 0, ignore_masks = 0;
 int opt, rc;
-static struct option opts[] = {
+static const struct option opts[] = {
+{"defconfig", 1, 0, 'f'},
 {"dryrun", 0, 0, 'n'},
+{"ignore-global-affinity-masks", 0, 0, 'i'},
 {"quiet", 0, 0, 'q'},
-{"defconfig", 1, 0, 'f'},
 {"vncviewer", 0, 0, 'V'},
 {"vncviewer-autopass", 0, 0, 'A'},
-{"ignore-global-affinity-masks", 0, 0, 'i'},
 COMMON_LONG_OPTS
 };
 
@@ -1186,12 +1186,15 @@ int main_create(int argc, char **argv)
 argc--; argv++;
 }
 
-SWITCH_FOREACH_OPT(opt, "Fnqf:pcdeVAi", opts, "create", 0) {
-case 'f':
-filename = optarg;
+SWITCH_FOREACH_OPT(opt, "AFVcdef:inpq", opts, "create", 0) {
+case 'A':
+vnc = vncautopass = 1;
 break;
-case 'p':
-paused = 1;
+case 'F':
+daemonize = 0;
+break;
+case 'V':
+vnc = 1;
 break;
 case 'c':
 console_autoconnect = 1;
@@ -1199,28 +1202,25 @@ int main_create(int argc, char **argv)
 case 'd':
 debug = 1;
 break;
-case 'F':
-daemonize = 0;
-break;
 case 'e':
 daemonize = 0;
 monitor = 0;
 break;
+case 'f':
+filename = optarg;
+break;
+case 'i':
+ignore_masks = 1;
+break;
 case 'n':
 dryrun_only = 1;
 break;
+case 'p':
+paused = 1;
+break;
 case 'q':
 quiet = 1;
 break;
-case 'V':
-vnc = 1;
-break;
-case 'A':
-vnc = vncautopass = 1;
-break;
-case 'i':
-ignore_masks = 1;
-break;
 }
 
 memset(_info, 0, sizeof(dom_info));
-- 
2.30.2

[PATCH v2 0/3] Allow use of JSON in domain configuration files

[Elliott Mitchell]

While the traditional domain configuration file format works acceptably,
I can see uses for having full JSON support.  As such add "-j" and "-J"
to `xl create` to specify format.  The traditional format is the current
default.

While attempting this, it came up that options for `xl create` aren't in
a consistent order.  I'm concerned about moving the VNC options apart,
but the others have been sorted.

Due to one issue in the previous round I ended up examing the dom_info
variable in main_create().  The situation there is a bit tangled.  There
were shadow variables for everything in dom_info.  Unfortunately the
short-hand serves to confuse, so I believe the appropriate action is to
remove the shadows.  Appears .dry_run had effectively been deprecated,
but not fully removed; as such now fully remove it.

Rename everything "format" to "config_format".

Elliott Mitchell (3):
  tools/xl: Sort create command options
  tools/xl: Use sparse init for dom_info, remove duplicate vars
  tools/xl: Allow specifying JSON for domain configuration file format

 tools/xl/xl.h   |   6 ++-
 tools/xl/xl_cmdtable.c  |  14 ++---
 tools/xl/xl_vmcontrol.c | 114 +---
 3 files changed, 73 insertions(+), 61 deletions(-)

-- 
2.30.2

[ovmf test] 169892: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  706 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   27 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [PATCH 2/2] tools/xl: Allow specifying JSON for domain configuration file format

[Elliott Mitchell]

On Fri, Apr 29, 2022 at 01:34:40PM +0100, Anthony PERARD wrote:
> On Tue, Apr 19, 2022 at 06:23:41PM -0700, Elliott Mitchell wrote:
> > JSON is currently used when saving domains to mass storage.  Being able
> > to use JSON as the normal input to `xl create` has potential to be
> > valuable.  Add the functionality.
> 
> "potential", right, but it isn't hasn't been really tested. When
> implemented, I think the intend of the json format was for libxl to
> communicate with itself while migrating a guest (or save/restore). It
> would be nice to know if it actually can work.

What I wonder is why the behind the scenes format is flexible enough to
fully handle domain configuration, yet wasn't reused for domain
configuration.  Then I look at the parser for domain configuration files
and it isn't really that great.

Add those two together and moving towards domain configuration files
being JSON seems natural.  Look at the "vif" and "disk" sections.  Those
could be very naturally handled as JSON, while the current parser isn't
rather limited.

There may be need to modify libxl_domain_config_from_json() to ensure it
gives good error messages.

> > Signed-off-by: Elliott Mitchell 
> > ---
> > diff --git a/tools/xl/xl.h b/tools/xl/xl.h
> > index c5c4bedbdd..a0c03f96df 100644
> > --- a/tools/xl/xl.h
> > +++ b/tools/xl/xl.h
> > @@ -49,6 +49,11 @@ struct domain_create {
> >  int migrate_fd; /* -1 means none */
> >  int send_back_fd; /* -1 means none */
> >  char **migration_domname_r; /* from malloc */
> > +enum {
> > +FORMAT_DEFAULT,
> > +FORMAT_JSON,
> > +FORMAT_LEGACY,
> > +} format;
> 
> I think the name "format" here is too generic, we are in the struct
> "domain_create" and this new format field isn't intended to specify the
> format of the domain. I think "config_file_format" would be better, as
> it is only used for the format of the config_file.

What about "config_format" to match below?

> Also I don't think having "_DEFAULT" would be useful, we need to know
> what the format is intended to be before starting to parse the file, and
> I don't think changing the default is going to work. So for the enum, we
> could have "_LEGACY = 0".
> 
> The prefix "FORMAT_" feels a bit generic, maybe "CONFIG_FORMAT_" would
> be better, or something else.

Okay.

Over time the default can be changed.  Document plans to move to JSON
exclusively.  Then after a few versions switch the default.  Then after
more versions remove the old format.

> >  };
> >  
> >  int create_domain(struct domain_create *dom_info);
> > diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
> > index f546beaceb..04d579a596 100644
> > --- a/tools/xl/xl_cmdtable.c
> > +++ b/tools/xl/xl_cmdtable.c
> > @@ -31,6 +31,8 @@ const struct cmd_spec cmd_table[] = {
> >"-h  Print this help.\n"
> >"-p  Leave the domain paused after it is 
> > created.\n"
> >"-f FILE, --defconfig=FILE\n Use the given 
> > configuration file.\n"
> > +  "-j, --json  Interpret configuration file as JSON 
> > format\n"
> > +  "-J  Use traditional configuration file format 
> > (current default)\n"
> 
> I don't think this new "-J" option would be useful, just the "-j" should be
> enough.

I was thinking of this as a transition mechanism.  Have "-J" for when the
default has been changed, but the code to handle the original format
hasn't been removed.

> >"-n, --dryrunDry run - prints the resulting 
> > configuration\n"
> >" (deprecated in favour of global -N 
> > option).\n"
> >"-q, --quiet Quiet.\n"
> > diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
> > index 2ec4140258..41bd919d1d 100644
> > --- a/tools/xl/xl_vmcontrol.c
> > +++ b/tools/xl/xl_vmcontrol.c
> > @@ -789,7 +789,7 @@ int create_domain(struct domain_create *dom_info)
> >  extra_config);
> >  }
> >  config_source=config_file;
> > -config_in_json = false;
> > +config_in_json = dom_info.format == FORMAT_JSON ? true : false;
> 
> This doesn't build, "dom_info" is a pointer.
> 
> Also, "? true : false;" is weird in C.

Uh, yeah.  Too many different coding standards.  Plus things being
passed around.  Erk.  %-/

> >  } else {
> >  if (!config_data) {
> >  fprintf(stderr, "Config file not specified and"
> > @@ -1173,6 +1173,7 @@ int main_create(int argc, char **argv)
> >  {"defconfig", 1, 0, 'f'},
> >  {"dryrun", 0, 0, 'n'},
> >  {"ignore-global-affinity-masks", 0, 0, 'i'},
> > +{"json", 0, 0, 'j'},
> >  {"quiet", 0, 0, 'q'},
> >  {"vncviewer", 0, 0, 'V'},
> >  {"vncviewer-autopass", 0, 0, 'A'},
> > @@ -1181,18 +1182,23 @@ int main_create(int argc, char **argv)
> >  
> >  dom_info.extra_config = NULL;
> >  
> > +dom_info.format = 

Re: [LINUX PATCH v3] xen: add support for initializing xenstore later as HVM domain

[Boris Ostrovsky]

On 4/29/22 5:10 PM, Stefano Stabellini wrote:

From: Luca Miccio 

When running as dom0less guest (HVM domain on ARM) the xenstore event
channel is available at domain creation but the shared xenstore
interface page only becomes available later on.

In that case, wait for a notification on the xenstore event channel,
then complete the xenstore initialization later, when the shared page
is actually available.

The xenstore page has few extra field. Add them to the shared struct.
One of the field is "connection", when the connection is ready, it is
zero. If the connection is not-zero, wait for a notification.

Signed-off-by: Luca Miccio 
Signed-off-by: Stefano Stabellini 
CC: jgr...@suse.com
CC: boris.ostrov...@oracle.com
---
Changes in v3:
- check for the connection field, if it is not zero, wait for event

Changes in v2:
- remove XENFEAT_xenstore_late_init
---
  drivers/xen/xenbus/xenbus_probe.c  | 86 +++---
  include/xen/interface/io/xs_wire.h |  3 ++
  2 files changed, 70 insertions(+), 19 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index fe360c33ce71..dc046d25789e 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -65,6 +65,7 @@
  #include "xenbus.h"
  
  
+static int xs_init_irq;

  int xen_store_evtchn;
  EXPORT_SYMBOL_GPL(xen_store_evtchn);
  
@@ -750,6 +751,17 @@ static void xenbus_probe(void)

  {
xenstored_ready = 1;
  
+	if (!xen_store_interface) {

+   xen_store_interface = xen_remap(xen_store_gfn << XEN_PAGE_SHIFT,
+   XEN_PAGE_SIZE);
+   /*
+* Now it is safe to free the IRQ used for xenstore late
+* initialization. No need to unbind: it is about to be
+* bound again.



This assumes knowledge of bind/unbind internals. I think we should unbind.



+*/
+   free_irq(xs_init_irq, _waitq);
+   }
+





@@ -959,23 +988,42 @@ static int __init xenbus_init(void)
 *
 * Also recognize all bits set as an invalid value.



Is this comment still correct?



 */
-   if (!v || !~v) {
+   if (!v) {
err = -ENOENT;
goto out_error;
}
-   /* Avoid truncation on 32-bit. */
+   if (v == ~0ULL) {
+   wait = true;
+   } else {
+   /* Avoid truncation on 32-bit. */

[ovmf test] 169889: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  705 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   26 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [PATCH] swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm

[Stefano Stabellini]

On Fri, 29 Apr 2022, Boris Ostrovsky wrote:
> On 4/28/22 6:49 PM, Stefano Stabellini wrote:
> > On Thu, 28 Apr 2022, Boris Ostrovsky wrote:
> > > On 4/28/22 5:49 PM, Stefano Stabellini wrote:
> > > > On Thu, 28 Apr 2022, Christoph Hellwig wrote:
> > > > > On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote:
> > > > > > > Reported-by: Rahul Singh 
> > > > > > > Signed-off-by: Christoph Hellwig 
> > > > > > Reviewed-by: Stefano Stabellini 
> > > > > Do you want to take this through the Xen tree or should I pick it up?
> > > > > Either way I'd love to see some testing on x86 as well.
> > > > I agree on the x86 testing. Juergen, Boris?
> > > > 
> > > > I'd say to take this patch via the Xen tree but Juergen has just sent a
> > > > Xen pull request to Linux last Saturday. Juergen do you plan to send
> > > > another one? Do you have something else lined up? If not, it might be
> > > > better to let Christoph pick it up.
> > > 
> > > We don't have anything pending.
> > > 
> > > 
> > > I can test it but at best tomorrow so not sure we can get this into rc5.
> > > Do
> > > you consider this an urgent fix or can we wait until 5.19? Because it's a
> > > bit
> > > too much IMO for rc6.
> > On one hand, Linux doesn't boot on a platform without this fix. On the
> > other hand, I totally see that this patch could introduce regressions on
> > x86 so I think it is fair that we are careful with it.
> > 
> >  From my point of view, it might be better to wait for 5.19 and mark it
> > as backport.
> 
> 
> No problems uncovered during testing.

Great! Christoph you can go ahead and pick it up in your tree if you are
up for it.

Re: [PATCH] swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm

[Boris Ostrovsky]

On 4/28/22 6:49 PM, Stefano Stabellini wrote:

On Thu, 28 Apr 2022, Boris Ostrovsky wrote:

On 4/28/22 5:49 PM, Stefano Stabellini wrote:

On Thu, 28 Apr 2022, Christoph Hellwig wrote:

On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote:

Reported-by: Rahul Singh 
Signed-off-by: Christoph Hellwig 

Reviewed-by: Stefano Stabellini 

Do you want to take this through the Xen tree or should I pick it up?
Either way I'd love to see some testing on x86 as well.

I agree on the x86 testing. Juergen, Boris?

I'd say to take this patch via the Xen tree but Juergen has just sent a
Xen pull request to Linux last Saturday. Juergen do you plan to send
another one? Do you have something else lined up? If not, it might be
better to let Christoph pick it up.


We don't have anything pending.


I can test it but at best tomorrow so not sure we can get this into rc5. Do
you consider this an urgent fix or can we wait until 5.19? Because it's a bit
too much IMO for rc6.

On one hand, Linux doesn't boot on a platform without this fix. On the
other hand, I totally see that this patch could introduce regressions on
x86 so I think it is fair that we are careful with it.

 From my point of view, it might be better to wait for 5.19 and mark it
as backport.



No problems uncovered during testing.


-boris

Re: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers

[Guilherme G. Piccoli]

Hi Michael, first of all thanks for the great review, much appreciated.
Some comments inline below:

On 29/04/2022 14:16, Michael Kelley (LINUX) wrote:
> [...]
>> hypervisor I/O completion), so we postpone that to run late. But more
>> relevant: this *same* vmbus unloading happens in the crash_shutdown()
>> handler, so if kdump is set, we can safely skip this panic notifier and
>> defer such clean-up to the kexec crash handler.
> 
> While the last sentence is true for Hyper-V on x86/x64, it's not true for
> Hyper-V on ARM64.  x86/x64 has the 'machine_ops' data structure
> with the ability to provide a custom crash_shutdown() function, which
> Hyper-V does in the form of hv_machine_crash_shutdown().  But ARM64
> has no mechanism to provide such a custom function that will eventually
> do the needed vmbus_initiate_unload() before running kdump.
> 
> I'm not immediately sure what the best solution is for ARM64.  At this
> point, I'm just pointing out the problem and will think about the tradeoffs
> for various possible solutions.  Please do the same yourself. :-)
> 

Oh, you're totally right! I just assumed ARM64 would the the same, my
bad. Just to propose some alternatives, so you/others can also discuss
here and we can reach a consensus about the trade-offs:

(a) We could forget about this change, and always do the clean-up here,
not relying in machine_crash_shutdown().
Pro: really simple, behaves the same as it is doing currently.
Con: less elegant/concise, doesn't allow arm64 customization.

(b) Add a way to allow ARM64 customization of shutdown crash handler.
Pro: matches x86, more customizable, improves arm64 arch code.
Con: A tad more complex.

Also, a question that came-up: if ARM64 has no way of calling special
crash shutdown handler, how can you execute hv_stimer_cleanup() and
hv_synic_disable_regs() there? Or are they not required in ARM64?


>>
>> (c) There is also a Hyper-V framebuffer panic notifier, which relies in
>> doing a vmbus operation that demands a valid connection. So, we must
>> order this notifier with the panic notifier from vmbus_drv.c, in order to
>> guarantee that the framebuffer code executes before the vmbus connection
>> is unloaded.
> 
> Patch 21 of this set puts the Hyper-V FB panic notifier on the pre_reboot
> notifier list, which means it won't execute before the VMbus connection
> unload in the case of kdump.   This notifier is making sure that Hyper-V
> is notified about the last updates made to the frame buffer before the
> panic, so maybe it needs to be put on the hypervisor notifier list.  It
> sends a message to Hyper-V over its existing VMbus channel, but it
> does not wait for a reply.  It does, however, obtain a spin lock on the
> ring buffer used to communicate with Hyper-V.   Unless someone has
> a better suggestion, I'm inclined to take the risk of blocking on that
> spin lock.

The logic behind that was: when kdump is set, we'd skip the vmbus
disconnect on notifiers, deferring that to crash_shutdown(), logic this
one refuted in the above discussion on ARM64 (one more Pro argument to
the idea of refactoring aarch64 code to allow a custom crash shutdown
handler heh). But you're right, for the default level 2, we skip the
pre_reboot notifiers on kdump, effectively skipping this notifier.

Some ideas of what we can do here:

I) we could change the framebuffer notifier to rely on trylocks, instead
of risking a lockup scenario, and with that, we can execute it before
the vmbus disconnect in the hypervisor list;

II) we ignore the hypervisor notifier in case of kdump _by default_, and
if the users don't want that, they can always set the panic notifier
level to 4 and run all notifiers prior to kdump; would that be terrible
you think? Kdump users might don't care about the framebuffer...

III) we go with approach (b) above and refactor arm64 code to allow the
custom crash handler on kdump time, then [with point (I) above] the
logic proposed in this series is still valid - seems more and more the
most correct/complete solution.

In any case, I guess we should avoid workarounds if possible and do the
things the best way we can, to encompass all (or almost all) the
possible scenarios and don't force things on users (like enforcing panic
notifier level 4 for Hyper-V or something like this...)

More feedback from you / Hyper-V folks is pretty welcome about this.


> 
>> [...]
> The "Fixes:" tags imply that these changes should be backported to older
> longterm kernel versions, which I don't think is the case.  There is a
> dependency on Patch 14 of your series where PANIC_NOTIFIER is
> introduced.
> 

Oh, this was more related with archeology of the kernel. When I'm
investigating stuff, I really want to understand why code was added and
that usually require some time git blaming stuff, so having that pronto
in the commit message is a bonus.

But of course we don't need to use the Fixes tag for that, easy to only
mention it in the text. A secondary benefit by using this 

[ovmf test] 169885: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  704 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   25 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [PATCH v2 0/4] xen/pv-scsi: update header and harden frontend

[Boris Ostrovsky]

On 4/28/22 3:53 AM, Juergen Gross wrote:

Update the Xen PV-scsi interface from the Xen tree and adapt the
related drivers to use the new definitions.

Harden the frontend driver to be no longer vulnerable to a malicious
backend.

Juergen Gross (4):
   xen: update vscsiif.h
   xen/scsiback: use new command result macros
   xen/scsifront: use new command result macros
   xen/scsifront: harden driver against malicious backend

  drivers/scsi/xen-scsifront.c   | 168 ++---
  drivers/xen/xen-scsiback.c |  82 +-
  include/xen/interface/io/vscsiif.h | 133 ++-
  3 files changed, 340 insertions(+), 43 deletions(-)



Reviewed-by: Boris Ostrovsky 

[xen-unstable test] 169859: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-examine  8 reboot   fail REGR. vs. 169775
 test-arm64-arm64-libvirt-xsm  8 xen-boot fail REGR. vs. 169775
 test-arm64-arm64-xl-vhd   8 xen-boot fail REGR. vs. 169775
 test-arm64-arm64-libvirt-raw  8 xen-boot fail REGR. vs. 169775
 test-arm64-arm64-xl-thunderx  8 xen-boot fail REGR. vs. 169775
 test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 169775
 test-arm64-arm64-xl   8 xen-boot fail REGR. vs. 169775

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169775
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 169775
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169775
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169775
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 169775
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 169775
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 169775
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 169775
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169775
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169775
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169775
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169775
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass

version targeted for testing:
 xen  d711a8e5279d830d2e4f0f55246ed0c6e4a6bbed
baseline version:
 xen  3f5d61466345ed2213de2d7e391b6cd6d4b86015

Last test of basis   169775  2022-04-27 08:15:40 Z2 days
Failing since169798  2022-04-27 22:39:22 Z1 days3 attempts
Testing same since   169859  2022-04-29 07:50:06 Z0 days

Re: [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path

[Marc Zyngier]

On Fri, 29 Apr 2022 22:45:14 +0100,
"Russell King (Oracle)"  wrote:
> 
> On Fri, Apr 29, 2022 at 06:38:19PM -0300, Guilherme G. Piccoli wrote:
> > Thanks Marc and Michael for the review/discussion.
> > 
> > On 29/04/2022 15:20, Marc Zyngier wrote:
> > > [...]
> > 
> > > My expectations would be that, since we're getting here using an IPI,
> > > interrupts are already masked. So what reenabled them the first place?
> > > 
> > > Thanks,
> > > 
> > >   M.
> > > 
> > 
> > Marc, I did some investigation in the code (and tried/failed in the ARM
> > documentation as well heh), but this is still not 100% clear for me.
> > 
> > You're saying IPI calls disable IRQs/FIQs by default in the the target
> > CPUs? Where does it happen? I'm a bit confused if this a processor
> > mechanism, or it's in code.
> 
> When we taken an IRQ, IRQs will be masked, FIQs will not. IPIs are
> themselves interrupts, so IRQs will be masked while the IPI is being
> processed. Therefore, there should be no need to re-disable the
> already disabled interrupts.
> 
> > But crash_smp_send_stop() is different, it seems to IPI the other CPUs
> > with the flag IPI_CALL_FUNC, which leads to calling
> > generic_smp_call_function_interrupt() - does it disable interrupts/FIQs
> > as well? I couldn't find it.
> 
> It's buried in the architecture behaviour. When the CPU takes an
> interrupt and jumps to the interrupt vector in the vectors page, it is
> architecturally defined that interrupts will be disabled. If they
> weren't architecturally disabled at this point, then as soon as the
> first instruction is processed (at the interrupt vector, likely a
> branch) the CPU would immediately take another jump to the interrupt
> vector, and this process would continue indefinitely, making interrupt
> handling utterly useless.
> 
> So, you won't find an explicit instruction in the code path from the
> vectors to the IPI handler that disables interrupts - because it's
> written into the architecture that this is what must happen.
> 
> IRQs are a lower priority than FIQs, so FIQs remain unmasked.

Ah, you're of course right. That's one of the huge differences between
AArch32 and AArch64, where the former has per target mode masking
rules, and the later masks everything on entry...

M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path

[Guilherme G. Piccoli]

On 29/04/2022 18:45, Russell King (Oracle) wrote:
> [...]
>> Marc, I did some investigation in the code (and tried/failed in the ARM
>> documentation as well heh), but this is still not 100% clear for me.
>>
>> You're saying IPI calls disable IRQs/FIQs by default in the the target
>> CPUs? Where does it happen? I'm a bit confused if this a processor
>> mechanism, or it's in code.
> 
> When we taken an IRQ, IRQs will be masked, FIQs will not. IPIs are
> themselves interrupts, so IRQs will be masked while the IPI is being
> processed. Therefore, there should be no need to re-disable the
> already disabled interrupts.
> 
>> But crash_smp_send_stop() is different, it seems to IPI the other CPUs
>> with the flag IPI_CALL_FUNC, which leads to calling
>> generic_smp_call_function_interrupt() - does it disable interrupts/FIQs
>> as well? I couldn't find it.
> 
> It's buried in the architecture behaviour. When the CPU takes an
> interrupt and jumps to the interrupt vector in the vectors page, it is
> architecturally defined that interrupts will be disabled. If they
> weren't architecturally disabled at this point, then as soon as the
> first instruction is processed (at the interrupt vector, likely a
> branch) the CPU would immediately take another jump to the interrupt
> vector, and this process would continue indefinitely, making interrupt
> handling utterly useless.
> 
> So, you won't find an explicit instruction in the code path from the
> vectors to the IPI handler that disables interrupts - because it's
> written into the architecture that this is what must happen.
> 
> IRQs are a lower priority than FIQs, so FIQs remain unmasked.
> 

Thanks a lot for the *great* explanation Russell, much appreciated.
So, this leads to the both following questions:

a) Shall we then change the patch to only disable FIQs, since it's panic
path and we don't want secondary CPUs getting interrupted, but only
spinning quietly "forever"?

b) How about cleaning ipi_cpu_stop() then, by dropping the call to
local_irq_disable() there, to avoid the double IRQ disabling?

Thanks,


Guilherme

[linux-linus test] 169862: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169836
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 169836
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169836
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169836
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169836
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169836
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 169836
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 169836
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass

version targeted for testing:
 linux38d741cb70b30741c0e802cbed7bd9cf4fd15fa4
baseline version:
 linux249aca0d3d631660aa3583c6a3559b75b6e971b4

Last test of basis   169836  2022-04-28 22:11:22 Z0 days
Testing same since   169862  2022-04-29 09:52:04 Z0 days1 attempts


People who touched revisions under test:
  Alex Deucher 
  Dave Airlie 
  David Yat Sin 
  Evan Quan 
  Hans de Goede 
  Imre Deak 
  Joonas Lahtinen 
  Jouni Högander 
  Linus Torvalds 
  Maarten Lankhorst 
  Maxime Ripard 
  Miaoqian Lin 
  Michele Ballabio 
  Prike Liang 
  Samuel Holland 
  Ville Syrjälä 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm 

Re: [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path

[Russell King (Oracle)]

On Fri, Apr 29, 2022 at 06:38:19PM -0300, Guilherme G. Piccoli wrote:
> Thanks Marc and Michael for the review/discussion.
> 
> On 29/04/2022 15:20, Marc Zyngier wrote:
> > [...]
> 
> > My expectations would be that, since we're getting here using an IPI,
> > interrupts are already masked. So what reenabled them the first place?
> > 
> > Thanks,
> > 
> > M.
> > 
> 
> Marc, I did some investigation in the code (and tried/failed in the ARM
> documentation as well heh), but this is still not 100% clear for me.
> 
> You're saying IPI calls disable IRQs/FIQs by default in the the target
> CPUs? Where does it happen? I'm a bit confused if this a processor
> mechanism, or it's in code.

When we taken an IRQ, IRQs will be masked, FIQs will not. IPIs are
themselves interrupts, so IRQs will be masked while the IPI is being
processed. Therefore, there should be no need to re-disable the
already disabled interrupts.

> But crash_smp_send_stop() is different, it seems to IPI the other CPUs
> with the flag IPI_CALL_FUNC, which leads to calling
> generic_smp_call_function_interrupt() - does it disable interrupts/FIQs
> as well? I couldn't find it.

It's buried in the architecture behaviour. When the CPU takes an
interrupt and jumps to the interrupt vector in the vectors page, it is
architecturally defined that interrupts will be disabled. If they
weren't architecturally disabled at this point, then as soon as the
first instruction is processed (at the interrupt vector, likely a
branch) the CPU would immediately take another jump to the interrupt
vector, and this process would continue indefinitely, making interrupt
handling utterly useless.

So, you won't find an explicit instruction in the code path from the
vectors to the IPI handler that disables interrupts - because it's
written into the architecture that this is what must happen.

IRQs are a lower priority than FIQs, so FIQs remain unmasked.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path

[Guilherme G. Piccoli]

Thanks Marc and Michael for the review/discussion.

On 29/04/2022 15:20, Marc Zyngier wrote:
> [...]

> My expectations would be that, since we're getting here using an IPI,
> interrupts are already masked. So what reenabled them the first place?
> 
> Thanks,
> 
>   M.
> 

Marc, I did some investigation in the code (and tried/failed in the ARM
documentation as well heh), but this is still not 100% clear for me.

You're saying IPI calls disable IRQs/FIQs by default in the the target
CPUs? Where does it happen? I'm a bit confused if this a processor
mechanism, or it's in code.

Looking the smp_send_stop() in arch/arm/, it does IPI the CPUs, with the
flag IPI_CPU_STOP, eventually calling ipi_cpu_stop(), and the latter
does disable IRQ/FIQ in code - that's where I stole my code from.

But crash_smp_send_stop() is different, it seems to IPI the other CPUs
with the flag IPI_CALL_FUNC, which leads to calling
generic_smp_call_function_interrupt() - does it disable interrupts/FIQs
as well? I couldn't find it.

Appreciate your clarifications about that, thanks again.
Cheers,


Guilherme

[ovmf test] 169883: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  703 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   24 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [PATCH 1/2] tools/xl: Sort create command options

[Elliott Mitchell]

On Fri, Apr 29, 2022 at 10:39:27AM +0100, Anthony PERARD wrote:
> On Tue, Apr 19, 2022 at 06:56:03PM -0700, Elliott Mitchell wrote:
> > Hopefully simplify future changes by sorting options lists for
> > `xl create`.
> 
> I'm not sure that sorting options make changes easier, as it would mean
> one has to make sure the new option is sorted as well ;-). But sorting
> the options in the help message is probably useful; I've looked at a few
> linux utilities and they tend to have them sorted so doing this for xl
> create sound fine.

This ends up revolving around the question, is the work involved in
keeping things sorted more or less than the annoyance caused by having
them unsorted?  I tend towards keep them sorted since I find trying to
identify available option letters when they're in random order is rather
troublesome.

> > Signed-off-by: Elliott Mitchell 
> > ---
> > diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
> > index 435155a033..2ec4140258 100644
> > --- a/tools/xl/xl_vmcontrol.c
> > +++ b/tools/xl/xl_vmcontrol.c
> > @@ -1169,13 +1169,13 @@ int main_create(int argc, char **argv)
> >  int paused = 0, debug = 0, daemonize = 1, console_autoconnect = 0,
> >  quiet = 0, monitor = 1, vnc = 0, vncautopass = 0, ignore_masks = 0;
> >  int opt, rc;
> > -static struct option opts[] = {
> > +static const struct option opts[] = {
> 
> Could you add a note in the commit message that "opts" is now
> const?

Okay.

> > +{"defconfig", 1, 0, 'f'},
> >  {"dryrun", 0, 0, 'n'},
> > +{"ignore-global-affinity-masks", 0, 0, 'i'},
> >  {"quiet", 0, 0, 'q'},
> > -{"defconfig", 1, 0, 'f'},
> >  {"vncviewer", 0, 0, 'V'},
> >  {"vncviewer-autopass", 0, 0, 'A'},
> > -{"ignore-global-affinity-masks", 0, 0, 'i'},
> >  COMMON_LONG_OPTS
> >  };
> >  
> > @@ -1186,12 +1186,15 @@ int main_create(int argc, char **argv)
> >  argc--; argv++;
> >  }
> >  
> > -SWITCH_FOREACH_OPT(opt, "Fnqf:pcdeVAi", opts, "create", 0) {
> > -case 'f':
> > -filename = optarg;
> > +SWITCH_FOREACH_OPT(opt, "Ffnq:AVcdeip", opts, "create", 0) {
> 
> The list of short options aren't really sorted here. Also -q doesn't
> take an argument, but -f should keep requiring one.

Needed to reread the documentation on getopt() behavior.  I remembered
it being group before the colon didn't take options, ones after colon
did take options.  Instead it is colon for every option with argument.

Other issue is dictionary sort versus ASCII sort.  ie "AaBbCcDdEeFf..."
versus "A-Za-z".


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

[LINUX PATCH v3] xen: add support for initializing xenstore later as HVM domain

[Stefano Stabellini]

From: Luca Miccio 

When running as dom0less guest (HVM domain on ARM) the xenstore event
channel is available at domain creation but the shared xenstore
interface page only becomes available later on.

In that case, wait for a notification on the xenstore event channel,
then complete the xenstore initialization later, when the shared page
is actually available.

The xenstore page has few extra field. Add them to the shared struct.
One of the field is "connection", when the connection is ready, it is
zero. If the connection is not-zero, wait for a notification.

Signed-off-by: Luca Miccio 
Signed-off-by: Stefano Stabellini 
CC: jgr...@suse.com
CC: boris.ostrov...@oracle.com
---
Changes in v3:
- check for the connection field, if it is not zero, wait for event

Changes in v2:
- remove XENFEAT_xenstore_late_init
---
 drivers/xen/xenbus/xenbus_probe.c  | 86 +++---
 include/xen/interface/io/xs_wire.h |  3 ++
 2 files changed, 70 insertions(+), 19 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index fe360c33ce71..dc046d25789e 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -65,6 +65,7 @@
 #include "xenbus.h"
 
 
+static int xs_init_irq;
 int xen_store_evtchn;
 EXPORT_SYMBOL_GPL(xen_store_evtchn);
 
@@ -750,6 +751,17 @@ static void xenbus_probe(void)
 {
xenstored_ready = 1;
 
+   if (!xen_store_interface) {
+   xen_store_interface = xen_remap(xen_store_gfn << XEN_PAGE_SHIFT,
+   XEN_PAGE_SIZE);
+   /*
+* Now it is safe to free the IRQ used for xenstore late
+* initialization. No need to unbind: it is about to be
+* bound again.
+*/
+   free_irq(xs_init_irq, _waitq);
+   }
+
/*
 * In the HVM case, xenbus_init() deferred its call to
 * xs_init() in case callbacks were not operational yet.
@@ -798,20 +810,22 @@ static int __init xenbus_probe_initcall(void)
 {
/*
 * Probe XenBus here in the XS_PV case, and also XS_HVM unless we
-* need to wait for the platform PCI device to come up.
+* need to wait for the platform PCI device to come up or
+* xen_store_interface is not ready.
 */
if (xen_store_domain_type == XS_PV ||
(xen_store_domain_type == XS_HVM &&
-!xs_hvm_defer_init_for_callback()))
+!xs_hvm_defer_init_for_callback() &&
+xen_store_interface != NULL))
xenbus_probe();
 
/*
-* For XS_LOCAL, spawn a thread which will wait for xenstored
-* or a xenstore-stubdom to be started, then probe. It will be
-* triggered when communication starts happening, by waiting
-* on xb_waitq.
+* For XS_LOCAL or when xen_store_interface is not ready, spawn a
+* thread which will wait for xenstored or a xenstore-stubdom to be
+* started, then probe.  It will be triggered when communication
+* starts happening, by waiting on xb_waitq.
 */
-   if (xen_store_domain_type == XS_LOCAL) {
+   if (xen_store_domain_type == XS_LOCAL || xen_store_interface == NULL) {
struct task_struct *probe_task;
 
probe_task = kthread_run(xenbus_probe_thread, NULL,
@@ -907,10 +921,25 @@ static struct notifier_block xenbus_resume_nb = {
.notifier_call = xenbus_resume_cb,
 };
 
+static irqreturn_t xenbus_late_init(int irq, void *unused)
+{
+   int err = 0;
+   uint64_t v = 0;
+
+   err = hvm_get_parameter(HVM_PARAM_STORE_PFN, );
+   if (err || !v || !~v)
+   return IRQ_HANDLED;
+   xen_store_gfn = (unsigned long)v;
+
+   wake_up(_waitq);
+   return IRQ_HANDLED;
+}
+
 static int __init xenbus_init(void)
 {
int err;
uint64_t v = 0;
+   bool wait = false;
xen_store_domain_type = XS_UNKNOWN;
 
if (!xen_domain())
@@ -959,23 +988,42 @@ static int __init xenbus_init(void)
 *
 * Also recognize all bits set as an invalid value.
 */
-   if (!v || !~v) {
+   if (!v) {
err = -ENOENT;
goto out_error;
}
-   /* Avoid truncation on 32-bit. */
+   if (v == ~0ULL) {
+   wait = true;
+   } else {
+   /* Avoid truncation on 32-bit. */
 #if BITS_PER_LONG == 32
-   if (v > ULONG_MAX) {
-   pr_err("%s: cannot handle HVM_PARAM_STORE_PFN=%llx > 
ULONG_MAX\n",
-  __func__, v);
-   err = -EINVAL;
-   goto out_error;
-   }
+   if (v > ULONG_MAX) {
+   pr_err("%s: cannot handle 
HVM_PARAM_STORE_PFN=%llx > 

[ovmf test] 169882: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  702 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   23 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

[PATCH v5 5/7] xenstored: send an evtchn notification on introduce_domain

[Stefano Stabellini]

From: Luca Miccio 

When xs_introduce_domain is called, send out a notification on the
xenstore event channel so that any (dom0less) domain waiting for the
xenstore interface to be ready can continue with the initialization.
Before sending the notification, clear XS_CONNECTION_STATE_RECONNECTING.

The extra notification is harmless for domains that don't require it.

Signed-off-by: Luca Miccio 
Signed-off-by: Stefano Stabellini 
CC: Juergen Gross 
CC: Julien Grall 
---
I dropped the Reviewed-by tags due to the connect = 0 change. Julien
also suggested it would be a good idea to add a clarification statement
about the usage of XS_CONNECTION_STATE_RECONNECTING in the header files
but I wasn't sure what to write. Please advise and I am happy to include
a statement in the next version.

Changes in v5:
- reset XS_CONNECTION_STATE_RECONNECTING before notifying the domU

Changes in v2:
- drop the new late_init parameter
---
 tools/xenstore/xenstored_domain.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/xenstore/xenstored_domain.c 
b/tools/xenstore/xenstored_domain.c
index ae065fcbee..7bb8c64d33 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -493,6 +493,10 @@ static struct domain *introduce_domain(const void *ctx,
/* Now domain belongs to its connection. */
talloc_steal(domain->conn, domain);
 
+   /* Notify the domain that xenstore is available */
+   interface->connection = 0x0;
+   xenevtchn_notify(xce_handle, domain->port);
+
if (!is_master_domain && !restore)
fire_watches(NULL, ctx, "@introduceDomain", NULL,
 false, NULL);
-- 
2.25.1

[PATCH v5 7/7] docs: document dom0less + PV drivers

[Stefano Stabellini]

From: Stefano Stabellini 

Document how to use the feature and how the implementation works.

Signed-off-by: Stefano Stabellini 
---
 docs/features/dom0less.pandoc | 43 ---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/docs/features/dom0less.pandoc b/docs/features/dom0less.pandoc
index c9edb529e1..725afa0558 100644
--- a/docs/features/dom0less.pandoc
+++ b/docs/features/dom0less.pandoc
@@ -90,6 +90,46 @@ Otherwise, they may be unusable in Xen (for instance if they 
are compressed).
 
 See docs/misc/arm/device-tree/booting.txt for more information.
 
+PV Drivers
+--
+
+It is possible to use PV drivers with dom0less guests with some
+restrictions:
+
+- dom0less domUs that want to use PV drivers support should have the
+  "xen,enhanced" property set under their device tree nodes (see
+  docs/misc/arm/device-tree/booting.txt)
+- a dom0 must be present (or another domain with enough privileges to
+  run the toolstack)
+- after dom0 is booted, the utility "init-dom0less" must be run
+- do not run "init-dom0less" while creating other guests with xl
+
+After the execution of init-dom0less, it is possible to use "xl" to
+hotplug PV drivers to dom0less guests. E.g. xl network-attach domU.
+
+The implementation works as follows:
+- Xen allocates the xenstore event channel for each dom0less domU that
+  has the "xen,enhanced" property, and sets HVM_PARAM_STORE_EVTCHN
+- Xen does *not* allocate the xenstore page and sets HVM_PARAM_STORE_PFN
+  to ~0ULL (invalid)
+- Dom0less domU kernels check that HVM_PARAM_STORE_PFN is set to invalid
+- Old kernels will continue without xenstore support (Note: some old
+  buggy kernels might crash because they don't check the validity of
+  HVM_PARAM_STORE_PFN before using it! Disable "xen,enhanced" in
+  those cases)
+- New kernels will wait for a notification on the xenstore event
+  channel (HVM_PARAM_STORE_EVTCHN) before continuing with the
+  initialization
+- Once dom0 is booted, init-dom0less is executed:
+- it allocates the xenstore shared page and sets HVM_PARAM_STORE_PFN
+- it calls xs_introduce_domain
+- Xenstored notices the new domain, initializes interfaces as usual, and
+  sends an event channel notification to the domain using the xenstore
+  event channel (HVM_PARAM_STORE_EVTCHN)
+- The Linux domU kernel receives the event channel notification, checks
+  HVM_PARAM_STORE_PFN again and continue with the initialization
+
+
 Limitations
 ---
 
@@ -107,9 +147,6 @@ limitations:
   information, the GIC version exposed to the domains started by Xen at
   boot is the same as the native GIC version.
 
-- No PV drivers. There is no support for PV devices at the moment. All
-  devices need to be statically assigned to guests.
-
 - Pinning vCPUs of domains started by Xen at boot can be
   done from the control domain, using `xl vcpu-pin` as usual. It is not
   currently possible to configure vCPU pinning without a control domain.
-- 
2.25.1

[PATCH v5 3/7] xen: introduce xen,enhanced dom0less property

[Stefano Stabellini]

From: Stefano Stabellini 

Introduce a new "xen,enhanced" dom0less property to enable/disable PV
driver interfaces for dom0less guests. Currently only "enabled" and
"disabled" are supported property values (and empty). Leave the option
open to implement further possible values in the future (e.g.
"xenstore" to enable only xenstore.)

The configurable option is for domUs only. For dom0 we always set the
corresponding property in the Xen code to true (PV interfaces enabled.)

This patch only parses the property. Next patches will make use of it.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Bertrand Marquis 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
---
Changes in v4:
- move xen,enhanced to the bottom of the list
- do not set kinfo.dom0less_enhanced for dom0

Changes in v3:
- improve commit message

Changes in v2:
- rename kinfo.enhanced to kinfo.dom0less_enhanced
- set kinfo.dom0less_enhanced to true for dom0
- handle -ENODATA in addition to -EILSEQ
---
 docs/misc/arm/device-tree/booting.txt | 18 ++
 xen/arch/arm/domain_build.c   |  7 +++
 xen/arch/arm/include/asm/kernel.h |  3 +++
 3 files changed, 28 insertions(+)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index a94125394e..92097c4969 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -188,6 +188,24 @@ with the following properties:
 An empty property to request the memory of the domain to be
 direct-map (guest physical address == physical address).
 
+- xen,enhanced
+
+A string property. Possible property values are:
+
+- "enabled" (or missing property value)
+Xen PV interfaces, including grant-table and xenstore, will be
+enabled for the VM.
+
+- "disabled"
+Xen PV interfaces are disabled.
+
+If the xen,enhanced property is present with no value, it defaults
+to "enabled". If the xen,enhanced property is not present, PV
+interfaces are disabled.
+
+In the future other possible property values might be added to
+enable only selected interfaces.
+
 Under the "xen,domain" compatible node, one or more sub-nodes are present
 for the DomU kernel and ramdisk.
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 34d3e5ce30..a877ccf585 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3153,6 +3153,7 @@ static int __init construct_domU(struct domain *d,
  const struct dt_device_node *node)
 {
 struct kernel_info kinfo = {};
+const char *dom0less_enhanced;
 int rc;
 u64 mem;
 
@@ -3168,6 +3169,12 @@ static int __init construct_domU(struct domain *d,
 
 kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
 
+rc = dt_property_read_string(node, "xen,enhanced", _enhanced);
+if ( rc == -EILSEQ ||
+ rc == -ENODATA ||
+ (rc == 0 && !strcmp(dom0less_enhanced, "enabled")) )
+kinfo.dom0less_enhanced = true;
+
 if ( vcpu_create(d, 0) == NULL )
 return -ENOMEM;
 
diff --git a/xen/arch/arm/include/asm/kernel.h 
b/xen/arch/arm/include/asm/kernel.h
index 874aa108a7..c4dc039b54 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -36,6 +36,9 @@ struct kernel_info {
 /* Enable pl011 emulation */
 bool vpl011;
 
+/* Enable PV drivers */
+bool dom0less_enhanced;
+
 /* GIC phandle */
 uint32_t phandle_gic;
 
-- 
2.25.1

[PATCH v5 4/7] xen/arm: configure dom0less domain for enabling xenstore after boot

[Stefano Stabellini]

From: Luca Miccio 

Export evtchn_alloc_unbound and make it __must_check.

If "xen,enhanced" is enabled, then add to dom0less domains:

- the hypervisor node in device tree
- the xenstore event channel

The xenstore event channel is also used for the first notification to
let the guest know that xenstore has become available.

Signed-off-by: Luca Miccio 
Signed-off-by: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Jan Beulich 

---
I removed Bertrand's reviewed-by due to merging this patch with "xen:
export evtchn_alloc_unbound"

Changes in v5:
- merge with "xen: export evtchn_alloc_unbound"
- __must_check

Changes in v3:
- use evtchn_alloc_unbound

Changes in v2:
- set HVM_PARAM_STORE_PFN to ~0ULL at domain creation
- in alloc_xenstore_evtchn do not call _evtchn_alloc_unbound

xen: export evtchn_alloc_unbound

It will be used during dom0less domains construction.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 37 +
 xen/common/event_channel.c  |  2 +-
 xen/include/xen/event.h |  3 +++
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a877ccf585..249efbf804 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -2809,6 +2810,8 @@ static int __init prepare_dtb_domU(struct domain *d, 
struct kernel_info *kinfo)
 int ret;
 
 kinfo->phandle_gic = GUEST_PHANDLE_GIC;
+kinfo->gnttab_start = GUEST_GNTTAB_BASE;
+kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
 
 addrcells = GUEST_ROOT_ADDRESS_CELLS;
 sizecells = GUEST_ROOT_SIZE_CELLS;
@@ -2883,6 +2886,13 @@ static int __init prepare_dtb_domU(struct domain *d, 
struct kernel_info *kinfo)
 goto err;
 }
 
+if ( kinfo->dom0less_enhanced )
+{
+ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
+if ( ret )
+goto err;
+}
+
 ret = fdt_end_node(kinfo->fdt);
 if ( ret < 0 )
 goto err;
@@ -3149,6 +3159,25 @@ static int __init construct_domain(struct domain *d, 
struct kernel_info *kinfo)
 return 0;
 }
 
+static int __init alloc_xenstore_evtchn(struct domain *d)
+{
+evtchn_alloc_unbound_t alloc;
+int rc;
+
+alloc.dom = d->domain_id;
+alloc.remote_dom = hardware_domain->domain_id;
+rc = evtchn_alloc_unbound();
+if ( rc )
+{
+printk("Failed allocating event channel for domain\n");
+return rc;
+}
+
+d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
+
+return 0;
+}
+
 static int __init construct_domU(struct domain *d,
  const struct dt_device_node *node)
 {
@@ -3213,6 +3242,14 @@ static int __init construct_domU(struct domain *d,
 if ( rc < 0 )
 return rc;
 
+if ( kinfo.dom0less_enhanced )
+{
+rc = alloc_xenstore_evtchn(d);
+if ( rc < 0 )
+return rc;
+d->arch.hvm.params[HVM_PARAM_STORE_PFN] = ~0ULL;
+}
+
 return rc;
 }
 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index ffb042a241..2f6a89f52d 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -289,7 +289,7 @@ void evtchn_free(struct domain *d, struct evtchn *chn)
 xsm_evtchn_close_post(chn);
 }
 
-static int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
+int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
 struct evtchn *chn;
 struct domain *d;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 21c95e14fd..f3021fe304 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -71,6 +71,9 @@ void evtchn_free(struct domain *d, struct evtchn *chn);
 /* Allocate a specific event channel port. */
 int evtchn_allocate_port(struct domain *d, unsigned int port);
 
+/* Allocate a new event channel */
+int __must_check evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc);
+
 /* Unmask a local event-channel port. */
 int evtchn_unmask(unsigned int port);
 
-- 
2.25.1

[PATCH v5 2/7] xen/arm: implement domU extended regions

[Stefano Stabellini]

From: Stefano Stabellini 

Implement extended regions for dom0less domUs. The implementation is
based on the libxl implementation.

Signed-off-by: Stefano Stabellini 
---
Changes in v5:
- print the domain
- coding style
- simplify the code in find_domU_holes
- return error if no regions allocated in find_domU_holes
- use ROUNDUP
- uint64_t/paddr_t
---
 xen/arch/arm/domain_build.c | 56 +++--
 1 file changed, 48 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8be01678de..34d3e5ce30 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1324,6 +1324,37 @@ out:
 return res;
 }
 
+static int __init find_domU_holes(const struct kernel_info *kinfo,
+  struct meminfo *ext_regions)
+{
+unsigned int i;
+paddr_t bankend;
+const paddr_t bankbase[] = GUEST_RAM_BANK_BASES;
+const paddr_t banksize[] = GUEST_RAM_BANK_SIZES;
+int res = -ENOENT;
+
+for ( i = 0; i < GUEST_RAM_BANKS; i++ )
+{
+struct membank *ext_bank = &(ext_regions->bank[ext_regions->nr_banks]);
+
+ext_bank->start = ROUNDUP(bankbase[i] + kinfo->mem.bank[i].size,
+  SZ_2M);
+
+bankend = ~0ULL >> (64 - p2m_ipa_bits);
+bankend = min(bankend, bankbase[i] + banksize[i] - 1);
+if ( bankend > ext_bank->start )
+ext_bank->size = bankend - ext_bank->start + 1;
+
+/* 64MB is the minimum size of an extended region */
+if ( ext_bank->size < MB(64) )
+continue;
+ext_regions->nr_banks++;
+res = 0;
+}
+
+return res;
+}
+
 static int __init make_hypervisor_node(struct domain *d,
const struct kernel_info *kinfo,
int addrcells, int sizecells)
@@ -1360,12 +1391,13 @@ static int __init make_hypervisor_node(struct domain *d,
 
 if ( !opt_ext_regions )
 {
-printk(XENLOG_INFO "The extended regions support is disabled\n");
+printk(XENLOG_INFO "%pd: extended regions support is disabled\n", d);
 nr_ext_regions = 0;
 }
 else if ( is_32bit_domain(d) )
 {
-printk(XENLOG_WARNING "The extended regions are only supported for 
64-bit guest currently\n");
+printk(XENLOG_WARNING "%pd: extended regions are only supported for 
64-bit guest currently\n",
+   d);
 nr_ext_regions = 0;
 }
 else
@@ -1374,13 +1406,21 @@ static int __init make_hypervisor_node(struct domain *d,
 if ( !ext_regions )
 return -ENOMEM;
 
-if ( !is_iommu_enabled(d) )
-res = find_unallocated_memory(kinfo, ext_regions);
+if ( is_domain_direct_mapped(d) )
+{
+if ( !is_iommu_enabled(d) )
+res = find_unallocated_memory(kinfo, ext_regions);
+else
+res = find_memory_holes(kinfo, ext_regions);
+}
 else
-res = find_memory_holes(kinfo, ext_regions);
+{
+res = find_domU_holes(kinfo, ext_regions);
+}
 
 if ( res )
-printk(XENLOG_WARNING "Failed to allocate extended regions\n");
+printk(XENLOG_WARNING "%pd: failed to allocate extended regions\n",
+   d);
 nr_ext_regions = ext_regions->nr_banks;
 }
 
@@ -1401,8 +1441,8 @@ static int __init make_hypervisor_node(struct domain *d,
 u64 start = ext_regions->bank[i].start;
 u64 size = ext_regions->bank[i].size;
 
-printk("Extended region %d: %#"PRIx64"->%#"PRIx64"\n",
-   i, start, start + size);
+printk("%pd: extended region %d: %#"PRIx64"->%#"PRIx64"\n",
+   d, i, start, start + size);
 
 dt_child_set_range(, addrcells, sizecells, start, size);
 }
-- 
2.25.1

[PATCH v5 6/7] tools: add example application to initialize dom0less PV drivers

[Stefano Stabellini]

From: Luca Miccio 

Add an example application that can be run in dom0 to complete the
dom0less domains initialization so that they can get access to xenstore
and use PV drivers.

The application sets XS_CONNECTION_STATE_RECONNECTING on the xenstore
page before calling xs_introduce_domain to signal that the connection is
not ready yet to be used. XS_CONNECTION_STATE_RECONNECTING is reset soon
after by xenstored.

Signed-off-by: Luca Miccio 
Signed-off-by: Stefano Stabellini 
CC: Wei Liu 
CC: Anthony PERARD 
CC: Juergen Gross 
---
Changes in v5:
- set XS_CONNECTION_STATE_RECONNECTING before xs_introduce_domain

Changes in v4:
- only alloc xs page (no other magic pages)
- add xenstore permissions
- check all return values
- rename restore_xenstore to create_xenstore
- set target_memkb
- set start_time properly
- close xs transaction on error
- call xc_dom_gnttab_seed instead of xc_dom_gnttab_init
- xs_open instead of xs_daemon_open

Changes in v3:
- handle xenstore errors
- add an in-code comment about xenstore entries
- less verbose output
- clean-up error path in main

Changes in v2:
- do not set HVM_PARAM_STORE_EVTCHN twice
- rename restore_xenstore to create_xenstore
- increase maxmem

connection reconnecting
---
 tools/helpers/Makefile|  13 ++
 tools/helpers/init-dom0less.c | 341 ++
 2 files changed, 354 insertions(+)
 create mode 100644 tools/helpers/init-dom0less.c

diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index 7f6c422440..8d78ab1e90 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -10,6 +10,9 @@ ifeq ($(CONFIG_Linux),y)
 ifeq ($(CONFIG_X86),y)
 PROGS += init-xenstore-domain
 endif
+ifeq ($(CONFIG_ARM),y)
+PROGS += init-dom0less
+endif
 endif
 
 XEN_INIT_DOM0_OBJS = xen-init-dom0.o init-dom-json.o
@@ -26,6 +29,13 @@ $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenstore)
 $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h
 
+INIT_DOM0LESS_OBJS = init-dom0less.o init-dom-json.o
+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenstore)
+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenlight)
+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
+$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
+
 .PHONY: all
 all: $(PROGS)
 
@@ -35,6 +45,9 @@ xen-init-dom0: $(XEN_INIT_DOM0_OBJS)
 init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
$(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) 
$(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenguest) $(LDLIBS_libxenlight) $(APPEND_LDFLAGS)
 
+init-dom0less: $(INIT_DOM0LESS_OBJS)
+   $(CC) $(LDFLAGS) -o $@ $(INIT_DOM0LESS_OBJS) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenevtchn) $(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) 
$(LDLIBS_libxenlight) $(LDLIBS_libxenguest) $(LDLIBS_libxenforeignmemory) 
$(APPEND_LDFLAGS)
+
 .PHONY: install
 install: all
$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
new file mode 100644
index 00..a99398e928
--- /dev/null
+++ b/tools/helpers/init-dom0less.c
@@ -0,0 +1,341 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "init-dom-json.h"
+
+#define XS_CONNECTION_STATE_OFFSET   (2068/4)
+#define XS_CONNECTION_STATE_RECONNECTING 0x1
+#define XENSTORE_PFN_OFFSET 1
+#define STR_MAX_LENGTH 64
+
+static int alloc_xs_page(struct xc_interface_core *xch,
+ libxl_dominfo *info,
+ uint64_t *xenstore_pfn)
+{
+int rc;
+const xen_pfn_t base = GUEST_MAGIC_BASE >> XC_PAGE_SHIFT;
+xen_pfn_t p2m = (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT) + XENSTORE_PFN_OFFSET;
+
+rc = xc_domain_setmaxmem(xch, info->domid,
+ info->max_memkb + (XC_PAGE_SIZE/1024));
+if (rc < 0)
+return rc;
+
+rc = xc_domain_populate_physmap_exact(xch, info->domid, 1, 0, 0, );
+if (rc < 0)
+return rc;
+
+*xenstore_pfn = base + XENSTORE_PFN_OFFSET;
+rc = xc_clear_domain_page(xch, info->domid, *xenstore_pfn);
+if (rc < 0)
+return rc;
+
+return 0;
+}
+
+static bool do_xs_write_dom(struct xs_handle *xsh, xs_transaction_t t,
+domid_t domid, char *path, char *val)
+{
+char full_path[STR_MAX_LENGTH];
+struct xs_permissions perms[2];
+
+perms[0].id = domid;
+perms[0].perms = XS_PERM_NONE;
+perms[1].id = 0;
+perms[1].perms = XS_PERM_READ;
+
+if (snprintf(full_path, STR_MAX_LENGTH,
+ "/local/domain/%u/%s", domid, path) < 0)
+return false;
+if (!xs_write(xsh, t, full_path, val, strlen(val)))
+return false;
+return xs_set_permissions(xsh, t, full_path, perms, 2);
+}
+
+static bool do_xs_write_libxl(struct xs_handle *xsh, 

[PATCH v5 1/7] xen/dt: of_property_read_string return -ENODATA when !length

[Stefano Stabellini]

From: Stefano Stabellini 

When the length of the string is zero of_property_read_string should
return -ENODATA according to the description of the function.

However, of_property_read_string doesn't check prop->length. If
prop->length is zero, return -ENODATA.

Without this patch the following command in u-boot:

fdt set /chosen/node property-name

results in of_property_read_string returning -EILSEQ when attempting to
read property-name. With this patch, it returns -ENODATA as expected.

This commit is a backport of:
https://lore.kernel.org/xen-devel/20220416003028.1315268-1-sstabell...@kernel.org/

Signed-off-by: Stefano Stabellini 
---
Changes in v5:
- backport from Linux, I don't have the commit id yet so I used an LKML
  link instead for now
---
 xen/common/device_tree.c  | 2 +-
 xen/include/xen/device_tree.h | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 4aae281e89..0e8798bd24 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -198,7 +198,7 @@ int dt_property_read_string(const struct dt_device_node *np,
 
 if ( !pp )
 return -EINVAL;
-if ( !pp->value )
+if ( !pp->length )
 return -ENODATA;
 if ( strnlen(pp->value, pp->length) >= pp->length )
 return -EILSEQ;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index fd6cd00b43..430a1ef445 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -451,6 +451,9 @@ static inline bool_t dt_property_read_bool(const struct 
dt_device_node *np,
  * doest not have value, and -EILSEQ if the string is not
  * null-terminated with the length of the property data.
  *
+ * Note that the empty string "" has length of 1, thus -ENODATA cannot
+ * be interpreted as an empty string.
+ *
  * The out_string pointer is modified only if a valid string can be decoded.
  */
 int dt_property_read_string(const struct dt_device_node *np,
-- 
2.25.1

[PATCH v5 0/7] dom0less PV drivers

[Stefano Stabellini]

Hi all,

Currently dom0less guests cannot use PV drivers because they don't have
access to xenstore. Also, the hypervisor node in device tree is missing
so they don't detect that they are running on Xen (thus, they don't try
to enable PV interfaces.)

This patch series enables dom0less guests (on ARM) to use PV drivers.

Instead of initializing xenstore immediately at boot, dom0less guests
get access to xenstore later. They delay the initialization until they
receive a notification via the xenstore event channel (which is
available at boot.)

An example workflow is as follows:
- all domains start in parallel, dom0less guests are immediately running
- when dom0 is up and running, the init-dom0less application is called
- dom0less guests receive the notification and initialize xenstore
- now xl network-attach/disk-attach works as expected for dom0less domUs

The patch series introduces a new dom0less device tree option
"xen,enhanced" (in the Xen device tree) to specify whether PV interfaces
should be enabled/disabled for the dom0less guest.

This patch series is based on Daniel P. Smith's "Adds starting the idle
domain privileged".

A important change in v5 is the usage of
XS_CONNECTION_STATE_RECONNECTING to signal that the xenstore interface
is not ready.

Cheers,

Stefano

Luca Miccio (3):
  xen/arm: configure dom0less domain for enabling xenstore after boot
  xenstored: send an evtchn notification on introduce_domain
  tools: add example application to initialize dom0less PV drivers

Stefano Stabellini (4):
  xen/dt: of_property_read_string return -ENODATA when !length
  xen/arm: implement domU extended regions
  xen: introduce xen,enhanced dom0less property
  docs: document dom0less + PV drivers

 docs/features/dom0less.pandoc |  43 -
 docs/misc/arm/device-tree/booting.txt |  18 ++
 tools/helpers/Makefile|  13 ++
 tools/helpers/init-dom0less.c | 341 ++
 tools/xenstore/xenstored_domain.c |   4 +
 xen/arch/arm/domain_build.c   | 100 +-
 xen/arch/arm/include/asm/kernel.h |   3 +
 xen/common/device_tree.c  |   2 +-
 xen/common/event_channel.c|   2 +-
 xen/include/xen/device_tree.h |   3 +
 xen/include/xen/event.h   |   3 +
 11 files changed, 519 insertions(+), 13 deletions(-)
 create mode 100644 tools/helpers/init-dom0less.c

Re: [PATCH 24/30] panic: Refactor the panic path

[Guilherme G. Piccoli]

On 29/04/2022 14:53, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli  Sent: Wednesday, April 27, 
> 2022 3:49 PM
>> [...]
>> +panic_notifiers_level=
>> +[KNL] Set the panic notifiers execution order.
>> +Format: 
>> +We currently have 4 lists of panic notifiers; based
>> +on the functionality and risk (for panic success) the
>> +callbacks are added in a given list. The lists are:
>> +- hypervisor/FW notification list (low risk);
>> +- informational list (low/medium risk);
>> +- pre_reboot list (higher risk);
>> +- post_reboot list (only run late in panic and after
>> +kdump, not configurable for now).
>> +This parameter defines the ordering of the first 3
>> +lists with regards to kdump; the levels determine
>> +which set of notifiers execute before kdump. The
>> +accepted levels are:
>> +0: kdump is the first thing to run, NO list is
>> +executed before kdump.
>> +1: only the hypervisor list is executed before kdump.
>> +2 (default level): the hypervisor list and (*if*
>> +there's any kmsg_dumper defined) the informational
>> +list are executed before kdump.
>> +3: both the hypervisor and the informational lists
>> +(always) execute before kdump.
> 
> I'm not clear on why level 2 exists.  What is the scenario where
> execution of the info list before kdump should be conditional on the
> existence of a kmsg_dumper?   Maybe the scenario is described
> somewhere in the patch set and I just missed it.
> 

Hi Michael, thanks for your review/consideration. So, this idea started
kind of some time ago. It all started with a need of exposing more
information on kernel log *before* kdump and *before* pstore -
specifically, we're talking about panic_print. But this cause some
reactions, Baoquan was very concerned with that [0]. Soon after, I've
proposed a panic notifiers filter (orthogonal) approach, to which Petr
suggested instead doing a major refactor [1] - it finally is alive in
the form of this series.

The theory behind the level 2 is to allow a scenario of kdump with the
minimum amount of notifiers - what is the point in printing more
information if the user doesn't care, since it's going to kdump? Now, if
there is a kmsg dumper, it means that there is likely some interest in
collecting information, and that might as well be required before the
potential kdump (which is my case, hence the proposal on [0]).

Instead of forcing one of the two behaviors (level 1 or level 3), we
have a middle-term/compromise: if there's interest in collecting such
data (in the form of a kmsg dumper), we then execute the informational
notifiers before kdump. If not, why to increase (even slightly) the risk
for kdump?

I'm OK in removing the level 2 if people prefer, but I don't feel it's a
burden, quite opposite - seems a good way to accommodate the somewhat
antagonistic ideas (jump to kdump ASAP vs collecting more info in the
panicked kernel log).

[0] https://lore.kernel.org/lkml/20220126052246.GC2086@MiWiFi-R3L-srv/

[1] https://lore.kernel.org/lkml/YfPxvzSzDLjO5ldp@alley/


>[...]
>> + * Based on the level configured (smaller than 4), we clear the
>> + * proper bits in "panic_notifiers_bits". Notice that this bitfield
>> + * is initialized with all notifiers set.
>> + */
>> +switch (panic_notifiers_level) {
>> +case 3:
>> +clear_bit(PN_PRE_REBOOT_BIT, _notifiers_bits);
>> +break;
>> +case 2:
>> +clear_bit(PN_PRE_REBOOT_BIT, _notifiers_bits);
>> +
>> +if (!kmsg_has_dumpers())
>> +clear_bit(PN_INFO_BIT, _notifiers_bits);
>> +break;
>> +case 1:
>> +clear_bit(PN_PRE_REBOOT_BIT, _notifiers_bits);
>> +clear_bit(PN_INFO_BIT, _notifiers_bits);
>> +break;
>> +case 0:
>> +clear_bit(PN_PRE_REBOOT_BIT, _notifiers_bits);
>> +clear_bit(PN_INFO_BIT, _notifiers_bits);
>> +clear_bit(PN_HYPERVISOR_BIT, _notifiers_bits);
>> +break;
>> +}
> 
> I think the above switch statement could be done as follows:
> 
> if (panic_notifiers_level <= 3)
>   clear_bit(PN_PRE_REBOOT_BIT, _notifiers_bits);
> if (panic_notifiers_level <= 2)
>   if (!kmsg_has_dumpers())
>   clear_bit(PN_INFO_BIT, _notifiers_bits);
> if (panic_notifiers_level <=1)
>   clear_bit(PN_INFO_BIT, _notifiers_bits);
> if (panic_notifiers_level == 0)
>   clear_bit(PN_HYPERVISOR_BIT, _notifiers_bits);
> 
> That's about half the lines of code.  It's somewhat a matter of style,
> so treat this as just a suggestion to 

[ovmf test] 169880: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  701 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   22 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [PATCH 18/30] notifier: Show function names on notifier routines if DEBUG_NOTIFIERS is set

[Guilherme G. Piccoli]

On 27/04/2022 22:01, Xiaoming Ni wrote:
> [...]
> Duplicate Code.
> 
> Is it better to use __func__ and %pS?
> 
> pr_info("%s: %pS\n", __func__, n->notifier_call);
> 
> 

This is a great suggestion Xiaoming, much appreciated!
I feel like reinventing the wheel here - with your idea, code was super
clear and concise, very nice suggestion!!

The only 2 things that diverge from your idea: I'm using '%ps' (not
showing offsets) and also, kept the wording "(un)registered/calling",
not using __func__ - I feel it's a bit odd in the output.
OK for you?

I'm definitely using your idea in V2 heh
Cheers,


Guilherme

Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list

[Guilherme G. Piccoli]

On 29/04/2022 13:04, Max Filippov wrote:
> [...]
>>  arch/xtensa/platforms/iss/setup.c |  4 ++--For xtensa:
> 
> For xtensa:
> Acked-by: Max Filippov 
> 

Perfect, thanks Max!
Cheers,


Guilherme

Re: [PATCH 13/30] s390/consoles: Improve panic notifiers reliability

[Guilherme G. Piccoli]

On 29/04/2022 15:46, Heiko Carstens wrote:
> [...]
> 
> Code looks good, and everything still seems to work. I applied this
> internally for the time being, and if it passes testing, I'll schedule
> it for the next merge window.
> 
> Thanks!

Perfect Heiko, thanks a bunch for your review and tests!
Let me know if anything breaks heh
Cheers,


Guilherme

[ovmf test] 169879: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  700 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   21 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [PATCH 13/30] s390/consoles: Improve panic notifiers reliability

[Heiko Carstens]

On Wed, Apr 27, 2022 at 07:49:07PM -0300, Guilherme G. Piccoli wrote:
> Currently many console drivers for s390 rely on panic/reboot notifiers
> to invoke callbacks on these events. The panic() function disables local
> IRQs, secondary CPUs and preemption, so callbacks invoked on panic are
> effectively running in atomic context.
> 
> Happens that most of these console callbacks from s390 doesn't take the
> proper care with regards to atomic context, like taking spinlocks that
> might be taken in other function/CPU and hence will cause a lockup
> situation.
> 
> The goal for this patch is to improve the notifiers reliability, acting
> on 4 console drivers, as detailed below:
> 
> (1) con3215: changed a regular spinlock to the trylock alternative.
> 
> (2) con3270: also changed a regular spinlock to its trylock counterpart,
> but here we also have another problem: raw3270_activate_view() takes a
> different spinlock. So, we worked a helper to validate if this other lock
> is safe to acquire, and if so, raw3270_activate_view() should be safe.
> 
> Notice though that there is a functional change here: it's now possible
> to continue the notifier code [reaching con3270_wait_write() and
> con3270_rebuild_update()] without executing raw3270_activate_view().
> 
> (3) sclp: a global lock is used heavily in the functions called from
> the notifier, so we added a check here - if the lock is taken already,
> we just bail-out, preventing the lockup.
> 
> (4) sclp_vt220: same as (3), a lock validation was added to prevent the
> potential lockup problem.
> 
> Besides (1)-(4), we also removed useless void functions, adding the
> code called from the notifier inside its own body, and changed the
> priority of such notifiers to execute late, since they are "heavyweight"
> for the panic environment, so we aim to reduce risks here.
> Changed return values to NOTIFY_DONE as well, the standard one.
> 
> Cc: Alexander Gordeev 
> Cc: Christian Borntraeger 
> Cc: Heiko Carstens 
> Cc: Sven Schnelle 
> Cc: Vasily Gorbik 
> Signed-off-by: Guilherme G. Piccoli 
> ---
> 
> As a design choice, the option used here to verify a given spinlock is taken
> was the function "spin_is_locked()" - but we noticed that it is not often 
> used.
> An alternative would to take the lock with a spin_trylock() and if it 
> succeeds,
> just release the spinlock and continue the code. But that seemed weird...
> 
> Also, we'd like to ask a good validation of case (2) potential functionality
> change from the s390 console experts - far from expert here, and in our naive
> code observation, that seems fine, but that analysis might be missing some
> corner case.
> 
> Thanks in advance!
> 
>  drivers/s390/char/con3215.c| 36 +++--
>  drivers/s390/char/con3270.c| 34 +++
>  drivers/s390/char/raw3270.c| 18 +++
>  drivers/s390/char/raw3270.h|  1 +
>  drivers/s390/char/sclp_con.c   | 28 +--
>  drivers/s390/char/sclp_vt220.c | 42 +++---
>  6 files changed, 96 insertions(+), 63 deletions(-)

Code looks good, and everything still seems to work. I applied this
internally for the time being, and if it passes testing, I'll schedule
it for the next merge window.

Thanks!

[ovmf test] 169878: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  699 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   20 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path

[Marc Zyngier]

On Wed, 27 Apr 2022 23:48:56 +0100,
"Guilherme G. Piccoli"  wrote:
> 
> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> is responsible for that. This makes sense, since we're turning off
> such CPUs, putting them in an endless busy-wait loop.
> 
> Problem is that there is an alternative path for disabling CPUs,
> in the form of function crash_smp_send_stop(), used for kexec/panic
> paths. This functions relies in a SMP call that also triggers a
> busy-wait loop [at machine_crash_nonpanic_core()], but *without*
> disabling interrupts. This might lead to odd scenarios, like early
> interrupts in the boot of kexec'd kernel or even interrupts in
> other CPUs while the main one still works in the panic path and
> assumes all secondary CPUs are (really!) off.
> 
> This patch mimics the ipi_cpu_stop() interrupt disable mechanism
> in the crash CPU shutdown path, hence disabling IRQs/FIQs in all
> secondary CPUs in the kexec/panic path as well.
> 
> Cc: Marc Zyngier 
> Cc: Russell King 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>  arch/arm/kernel/machine_kexec.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index f567032a09c0..ef788ee00519 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -86,6 +86,9 @@ void machine_crash_nonpanic_core(void *unused)
>   set_cpu_online(smp_processor_id(), false);
>   atomic_dec(_for_crash_ipi);
>  
> + local_fiq_disable();
> + local_irq_disable();
> +

My expectations would be that, since we're getting here using an IPI,
interrupts are already masked. So what reenabled them the first place?

Thanks,

M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH] arm/acpi: don't expose the ACPI IORT SMMUv3 entry to dom0

[Rahul Singh]

Hi Julien,

> On 27 Apr 2022, at 7:26 pm, Julien Grall  wrote:
> 
> Hi Rahul,
> 
> On 27/04/2022 17:12, Rahul Singh wrote:
>> Xen should control the SMMUv3 devices therefore, don't expose the
>> SMMUv3 devices to dom0. Deny iomem access to SMMUv3 address space for
>> dom0 and also make ACPI IORT SMMUv3 node type to 0xff.
> 
> Looking at the IORT spec (ARM DEN 0049E), 255 (0xff) is marked as reserved. 
> So I don't think we can "allocate" 0xff to mean invalid without updating the 
> spec. Did you engage with whoever own the spec?

Yes I agree with you 0xff is reserved for future use. I didn’t find any other 
value to make node invalid. 
Linux kernel is mostly using the node->type to process the SMMUv3 or other IORT 
node so I thought this is the only possible solution to hide SMMUv3 for dom0

If you have any other suggestion to hide the SMMUv3 node I am okay to use that.
> 
>> Signed-off-by: Rahul Singh 
>> ---
>> xen/arch/arm/acpi/domain_build.c | 40 
>> 1 file changed, 40 insertions(+)
>> diff --git a/xen/arch/arm/acpi/domain_build.c 
>> b/xen/arch/arm/acpi/domain_build.c
>> index bbdc90f92c..ec0b5b261f 100644
>> --- a/xen/arch/arm/acpi/domain_build.c
>> +++ b/xen/arch/arm/acpi/domain_build.c
>> @@ -14,6 +14,7 @@
>> #include 
>> #include 
>> #include 
>> +#include 
>> #include 
>> #include 
>> #include 
>> @@ -30,6 +31,7 @@ static int __init acpi_iomem_deny_access(struct domain *d)
>> {
>> acpi_status status;
>> struct acpi_table_spcr *spcr = NULL;
>> + struct acpi_table_iort *iort;
>> unsigned long mfn;
>> int rc;
>> @@ -55,6 +57,44 @@ static int __init acpi_iomem_deny_access(struct domain *d)
>> printk("Failed to get SPCR table, Xen console may be unavailable\n");
>> }
>> + status = acpi_get_table(ACPI_SIG_IORT, 0,
>> + (struct acpi_table_header **));
> 
> At some point we will need to add support to hide the ARM SMMU device and 
> possibly some devices. So I think it would be better to create a function 
> that would deal with the IORT.

Ok. Let me add the function in next version.
> 
>> +
>> + if ( ACPI_SUCCESS(status) )
>> + {
>> + int i;
> 
> Please use unsigned int.
Ack.
> 
>> + struct acpi_iort_node *node, *end;
> 
> Coding style: Please add a newline.

Ack. 
> 
>> + node = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->node_offset);
>> + end = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->header.length);
>> +
>> + for ( i = 0; i < iort->node_count; i++ )
>> + {
>> + if ( node >= end )
> 
> Wouldn't this only happen if the table is somehow corrupted? If so, I think 
> we should print an error (or even panic).

Ok.
> 
>> + break;
>> +
>> + switch ( node->type )
>> + {
>> + case ACPI_IORT_NODE_SMMU_V3:
> 
> Coding style: The keyword "case" should be aligned the the start of the 
> keyword "switch”.
Ack. 
> 
>> + {
>> + struct acpi_iort_smmu_v3 *smmu;
> 
> Coding style: Newline.

Ack. 
>> + smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
>> + mfn = paddr_to_pfn(smmu->base_address);
>> + rc = iomem_deny_access(d, mfn, mfn + PFN_UP(SZ_128K));
>> + if ( rc )
>> + printk("iomem_deny_access failed for SMMUv3\n");
>> + node->type = 0xff;
> 
> 'node' points to the Xen copy of the ACPI table. We should really not touch 
> this copy. Instead, we should modify the version that will be used by dom0.

As of now IORT is untouched by Xen and mapped to dom0. I will create the IORT 
table for dom0 and modify the node SMMUv3 that will be used by dom0.
> 
> Furthermore, if we go down the road to update node->type, we should 0 the 
> node to avoid leaking the information to dom0.

I am not sure if we can zero the node, let me check and come back to you. 
> 
>> + break;
>> + }
>> + }
>> + node = ACPI_ADD_PTR(struct acpi_iort_node, node, node->length);
>> + }
>> + }
>> + else
>> + {
>> + printk("Failed to get IORT table\n");
>> + return -EINVAL;
>> + }
> 
> The IORT is not yet parsed by Xen and AFAIK is optional. So I don't think we 
> should return an error.

Ack. 

Regards,
Rahul

Re: [PATCH v2 18/19] xen/sndfront: use xenbus_setup_ring() and xenbus_teardown_ring()

[Oleksandr]

On 28.04.22 11:27, Juergen Gross wrote:

Hello Juergen, all


Simplify sndfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().

Signed-off-by: Juergen Gross 


I am not familiar with SOUND bits of this driver, but a little bit
familiar with Xen bits this patch only touches and I have environment to
test.

Xen specific changes looks good to me. Also I didn't see any issues when 
testing virtulized sound driver with current series except one I have 
already pointed out in PATCH v2 08/19.



root@salvator-x-h3-4x2g-xt-domu:~# dmesg | grep vsnd
[    0.432181] Initialising Xen vsnd frontend driver


root@salvator-x-h3-4x2g-xt-domu:~# aplay -l
 List of PLAYBACK Hardware Devices 
card 0: vsnd [], device 0: dev1 [Virtual card PCM]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

root@generic-armv8-xt-dom0:~# xenstore-ls -f | grep vsnd
/local/domain/1/backend/vsnd = ""
/local/domain/1/backend/vsnd/6 = ""
/local/domain/1/backend/vsnd/6/0 = ""
/local/domain/1/backend/vsnd/6/0/frontend = "/local/domain/6/device/vsnd/0"
/local/domain/1/backend/vsnd/6/0/frontend-id = "6"
/local/domain/1/backend/vsnd/6/0/online = "1"
/local/domain/1/backend/vsnd/6/0/state = "4"
/local/domain/6/device/vsnd = ""
/local/domain/6/device/vsnd/0 = ""
/local/domain/6/device/vsnd/0/backend = "/local/domain/1/backend/vsnd/6/0"
/local/domain/6/device/vsnd/0/backend-id = "1"
/local/domain/6/device/vsnd/0/state = "4"
/local/domain/6/device/vsnd/0/long-name = "Virtual sound card"
/local/domain/6/device/vsnd/0/short-name = "VCard"
/local/domain/6/device/vsnd/0/sample-rates = 
"8000,11025,16000,22050,32000,44100,48000"

/local/domain/6/device/vsnd/0/sample-formats = "s16_le"
/local/domain/6/device/vsnd/0/buffer-size = "65536"
/local/domain/6/device/vsnd/0/0 = ""
/local/domain/6/device/vsnd/0/0/name = "dev1"
/local/domain/6/device/vsnd/0/0/0 = ""
/local/domain/6/device/vsnd/0/0/0/unique-id = "pulse"
/local/domain/6/device/vsnd/0/0/0/type = "p"
/local/domain/6/device/vsnd/0/0/0/ring-ref = "2070"
/local/domain/6/device/vsnd/0/0/0/event-channel = "18"
/local/domain/6/device/vsnd/0/0/0/evt-ring-ref = "2071"
/local/domain/6/device/vsnd/0/0/0/evt-event-channel = "19"
/libxl/6/device/vsnd = ""
/libxl/6/device/vsnd/0 = ""
/libxl/6/device/vsnd/0/frontend = "/local/domain/6/device/vsnd/0"
/libxl/6/device/vsnd/0/backend = "/local/domain/1/backend/vsnd/6/0"
/libxl/6/device/vsnd/0/frontend-id = "6"
/libxl/6/device/vsnd/0/online = "1"
/libxl/6/device/vsnd/0/state = "1"



---
  sound/xen/xen_snd_front_evtchnl.c | 44 +++
  1 file changed, 10 insertions(+), 34 deletions(-)

diff --git a/sound/xen/xen_snd_front_evtchnl.c 
b/sound/xen/xen_snd_front_evtchnl.c
index 3e21369c8216..26d1b3987887 100644
--- a/sound/xen/xen_snd_front_evtchnl.c
+++ b/sound/xen/xen_snd_front_evtchnl.c
@@ -143,12 +143,12 @@ void xen_snd_front_evtchnl_flush(struct 
xen_snd_front_evtchnl *channel)
  static void evtchnl_free(struct xen_snd_front_info *front_info,
 struct xen_snd_front_evtchnl *channel)
  {
-   unsigned long page = 0;
+   void *page = NULL;
  
  	if (channel->type == EVTCHNL_TYPE_REQ)

-   page = (unsigned long)channel->u.req.ring.sring;
+   page = channel->u.req.ring.sring;
else if (channel->type == EVTCHNL_TYPE_EVT)
-   page = (unsigned long)channel->u.evt.page;
+   page = channel->u.evt.page;
  
  	if (!page)

return;
@@ -167,10 +167,7 @@ static void evtchnl_free(struct xen_snd_front_info 
*front_info,
xenbus_free_evtchn(front_info->xb_dev, channel->port);
  
  	/* End access and free the page. */

-   if (channel->gref != INVALID_GRANT_REF)
-   gnttab_end_foreign_access(channel->gref, page);
-   else
-   free_page(page);
+   xenbus_teardown_ring(, 1, >gref);
  
  	memset(channel, 0, sizeof(*channel));

  }
@@ -196,8 +193,7 @@ static int evtchnl_alloc(struct xen_snd_front_info 
*front_info, int index,
 enum xen_snd_front_evtchnl_type type)
  {
struct xenbus_device *xb_dev = front_info->xb_dev;
-   unsigned long page;
-   grant_ref_t gref;
+   void *page;
irq_handler_t handler;
char *handler_name = NULL;
int ret;
@@ -207,12 +203,9 @@ static int evtchnl_alloc(struct xen_snd_front_info 
*front_info, int index,
channel->index = index;
channel->front_info = front_info;
channel->state = EVTCHNL_STATE_DISCONNECTED;
-   channel->gref = INVALID_GRANT_REF;
-   page = get_zeroed_page(GFP_KERNEL);
-   if (!page) {
-   ret = -ENOMEM;
+   ret = xenbus_setup_ring(xb_dev, GFP_KERNEL, , 1, >gref);
+   if (ret)
goto fail;
-   }
  
  	handler_name = kasprintf(GFP_KERNEL, "%s-%s", XENSND_DRIVER_NAME,

 type == EVTCHNL_TYPE_REQ ?
@@ -226,33 +219,18 @@ static int evtchnl_alloc(struct xen_snd_front_info 

Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list

[Guilherme G. Piccoli]

On 29/04/2022 14:30, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli  Sent: Wednesday, April 27, 
> 2022 3:49 PM
>> [...]
>>
>> @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void)
>>  if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
>>  kmsg_dump_unregister(_kmsg_dumper);
>>  unregister_die_notifier(_die_report_block);
>> -atomic_notifier_chain_unregister(_notifier_list,
>> +atomic_notifier_chain_unregister(_hypervisor_list,
>>  _panic_report_block);
>>  }
>>
> 
> Using the hypervisor_list here produces a bit of a mismatch.  In many cases
> this notifier will do nothing, and will defer to the kmsg_dump() mechanism
> to notify the hypervisor about the panic.   Running the kmsg_dump()
> mechanism is linked to the info_list, so I'm thinking the Hyper-V panic report
> notifier should be on the info_list as well.  That way the reporting behavior
> is triggered at the same point in the panic path regardless of which
> reporting mechanism is used.
> 

Hi Michael, thanks for your feedback! I agree that your idea could work,
but...there is one downside: imagine the kmsg_dump() approach is not set
in some Hyper-V guest, then we would rely in the regular notification
mechanism [hv_die_panic_notify_crash()], right?
But...you want then to run this notifier in the informational list,
which...won't execute *by default* before kdump if no kmsg_dump() is
set. So, this logic is convoluted when you mix it with the default level
concept + kdump.

May I suggest something? If possible, take a run with this patch set +
DEBUG_NOTIFIER=y, in *both* cases (with and without the kmsg_dump()
set). I did that and they run almost at the same time...I've checked the
notifiers called, it's like almost nothing runs in-between.

I feel the panic notification mechanism does really fit with a
hypervisor list, it's a good match with the nature of the list, which
aims at informing the panic notification to the hypervisor/FW.
Of course we can modify it if you prefer...but please take into account
the kdump case and how it complicates the logic.

Let me know your considerations, in case you can experiment with the
patch set as-is.
Cheers,


Guilherme

RE: [PATCH 24/30] panic: Refactor the panic path

[Michael Kelley (LINUX)]

From: Guilherme G. Piccoli  Sent: Wednesday, April 27, 
2022 3:49 PM
> 
> The panic() function is somewhat convoluted - a lot of changes were
> made over the years, adding comments that might be misleading/outdated
> now, it has a code structure that is a bit complex to follow, with
> lots of conditionals, for example. The panic notifier list is something
> else - a single list, with multiple callbacks of different purposes,
> that run in a non-deterministic order and may affect hardly kdump
> reliability - see the "crash_kexec_post_notifiers" workaround-ish flag.
> 
> This patch proposes a major refactor on the panic path based on Petr's
> idea [0] - basically we split the notifiers list in three, having a set
> of different call points in the panic path. Below a list of changes
> proposed in this patch, culminating in the panic notifiers level
> concept:
> 
> (a) First of all, we improved comments all over the function
> and removed useless variables / includes. Also, as part of this
> clean-up we concentrate the console flushing functions in a helper.
> 
> (b) As mentioned before, there is a split of the panic notifier list
> in three, based on the purpose of the callback. The code contains
> good documentation in form of comments, but a summary of the three
> lists follows:
> 
> - the hypervisor list aims low-risk procedures to inform hypervisors
> or firmware about the panic event, also includes LED-related functions;
> 
> - the informational list contains callbacks that provide more details,
> like kernel offset or trace dump (if enabled) and also includes the
> callbacks aimed at reducing log pollution or warns, like the RCU and
> hung task disable callbacks;
> 
> - finally, the pre_reboot list is the old notifier list renamed,
> containing the more risky callbacks that didn't fit the previous
> lists. There is also a 4th list (the post_reboot one), but it's not
> related with the original list - it contains late time architecture
> callbacks aimed at stopping the machine, for example.
> 
> The 3 notifiers lists execute in different moments, hypervisor being
> the first, followed by informational and finally the pre_reboot list.
> 
> (c) But then, there is the ordering problem of the notifiers against
> the crash_kernel() call - kdump must be as reliable as possible.
> For that, a simple binary "switch" as "crash_kexec_post_notifiers"
> is not enough, hence we introduce here concept of panic notifier
> levels: there are 5 levels, from 0 (no notifier executes before
> kdump) until 4 (all notifiers run before kdump); the default level
> is 2, in which the hypervisor and (iff we have any kmsg dumper)
> the informational notifiers execute before kdump.
> 
> The detailed documentation of the levels is present in code comments
> and in the kernel-parameters.txt file; as an analogy with the previous
> panic() implementation, the level 0 is exactly the same as the old
> behavior of notifiers, running all after kdump, and the level 4 is
> the same as "crash_kexec_post_notifiers=Y" (we kept this parameter as
> a deprecated one).
> 
> (d) Finally, an important change made here: we now use only the
> function "crash_smp_send_stop()" to shut all the secondary CPUs
> in the panic path. Before, there was a case of using the regular
> "smp_send_stop()", but the better approach is to simplify the
> code and try to use the function which was created exclusively
> for the panic path. Experiments showed that it works fine, and
> code was very simplified with that.
> 
> Functional change is expected from this refactor, since now we
> call some notifiers by default before kdump, but the goal here
> besides code clean-up is to have a better panic path, more
> reliable and deterministic, but also very customizable.
> 
> [0] https://lore.kernel.org/lkml/YfPxvzSzDLjO5ldp@alley/
> 
> Suggested-by: Petr Mladek 
> Signed-off-by: Guilherme G. Piccoli 
> ---
> 
> Special thanks to Petr and Baoquan for the suggestion and feedback in a 
> previous
> email thread. There's some important design decisions that worth mentioning 
> and
> discussing:
> 
> * The default panic notifiers level is 2, based on Petr Mladek's suggestion,
> which makes a lot of sense. Of course, this is customizable through the
> parameter, but would be something worthwhile to have a KConfig option to set
> the default level? It would help distros that want the old behavior
> (no notifiers before kdump) as default.
> 
> * The implementation choice was to _avoid_ intricate if conditionals in the
> panic path, which would _definitely_ be present with the panic notifiers 
> levels
> idea; so, instead of lots of if conditionals, the set/clear bits approach with
> functions called in 2 points (but executing only in one of them) is much 
> easier
> to follow an was used here; the ordering helper function and the comments also
> help a lot to avoid confusion (hopefully).
> 
> * Choice was to *always* use crash_smp_send_stop() instead of sometimes making
> use of the 

[ovmf test] 169874: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  698 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   19 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

RE: [PATCH 19/30] panic: Add the panic hypervisor notifier list

[Michael Kelley (LINUX)]

From: Guilherme G. Piccoli  Sent: Wednesday, April 27, 
2022 3:49 PM
> 
> The goal of this new panic notifier is to allow its users to register
> callbacks to run very early in the panic path. This aims hypervisor/FW
> notification mechanisms as well as simple LED functions, and any other
> simple and safe mechanism that should run early in the panic path; more
> dangerous callbacks should execute later.
> 
> For now, the patch is almost a no-op (although it changes a bit the
> ordering in which some panic notifiers are executed). In a subsequent
> patch, the panic path will be refactored, then the panic hypervisor
> notifiers will effectively run very early in the panic path.
> 
> We also defer documenting it all properly in the subsequent refactor
> patch. While at it, we removed some useless header inclusions and
> fixed some notifiers return too (by using the standard NOTIFY_DONE).
> 
> Cc: Alexander Gordeev 
> Cc: Andrea Parri (Microsoft) 
> Cc: Ard Biesheuvel 
> Cc: Benjamin Herrenschmidt 
> Cc: Brian Norris 
> Cc: Christian Borntraeger 
> Cc: Christophe JAILLET 
> Cc: David Gow 
> Cc: "David S. Miller" 
> Cc: Dexuan Cui 
> Cc: Doug Berger 
> Cc: Evan Green 
> Cc: Florian Fainelli 
> Cc: Haiyang Zhang 
> Cc: Hari Bathini 
> Cc: Heiko Carstens 
> Cc: Julius Werner 
> Cc: Justin Chen 
> Cc: "K. Y. Srinivasan" 
> Cc: Lee Jones 
> Cc: Markus Mayer 
> Cc: Michael Ellerman 
> Cc: Michael Kelley 
> Cc: Mihai Carabas 
> Cc: Nicholas Piggin 
> Cc: Paul Mackerras 
> Cc: Pavel Machek 
> Cc: Scott Branden 
> Cc: Sebastian Reichel 
> Cc: Shile Zhang 
> Cc: Stephen Hemminger 
> Cc: Sven Schnelle 
> Cc: Thomas Bogendoerfer 
> Cc: Tianyu Lan 
> Cc: Vasily Gorbik 
> Cc: Wang ShaoBo 
> Cc: Wei Liu 
> Cc: zhenwei pi 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>  arch/mips/sgi-ip22/ip22-reset.c  | 2 +-
>  arch/mips/sgi-ip32/ip32-reset.c  | 3 +--
>  arch/powerpc/kernel/setup-common.c   | 2 +-
>  arch/sparc/kernel/sstate.c   | 3 +--
>  drivers/firmware/google/gsmi.c   | 4 ++--
>  drivers/hv/vmbus_drv.c   | 4 ++--
>  drivers/leds/trigger/ledtrig-activity.c  | 4 ++--
>  drivers/leds/trigger/ledtrig-heartbeat.c | 4 ++--
>  drivers/misc/bcm-vk/bcm_vk_dev.c | 6 +++---
>  drivers/misc/pvpanic/pvpanic.c   | 4 ++--
>  drivers/power/reset/ltc2952-poweroff.c   | 4 ++--
>  drivers/s390/char/zcore.c| 5 +++--
>  drivers/soc/bcm/brcmstb/pm/pm-arm.c  | 2 +-
>  include/linux/panic_notifier.h   | 1 +
>  kernel/panic.c   | 4 
>  15 files changed, 28 insertions(+), 24 deletions(-)

[ snip]

> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index f37f12d48001..901b97034308 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1614,7 +1614,7 @@ static int vmbus_bus_init(void)
>   hv_kmsg_dump_register();
> 
>   register_die_notifier(_die_report_block);
> - atomic_notifier_chain_register(_notifier_list,
> + atomic_notifier_chain_register(_hypervisor_list,
>   _panic_report_block);
>   }
> 
> @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void)
>   if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
>   kmsg_dump_unregister(_kmsg_dumper);
>   unregister_die_notifier(_die_report_block);
> - atomic_notifier_chain_unregister(_notifier_list,
> + atomic_notifier_chain_unregister(_hypervisor_list,
>   _panic_report_block);
>   }
> 

Using the hypervisor_list here produces a bit of a mismatch.  In many cases
this notifier will do nothing, and will defer to the kmsg_dump() mechanism
to notify the hypervisor about the panic.   Running the kmsg_dump()
mechanism is linked to the info_list, so I'm thinking the Hyper-V panic report
notifier should be on the info_list as well.  That way the reporting behavior
is triggered at the same point in the panic path regardless of which
reporting mechanism is used.

RE: [PATCH 16/30] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers

[Michael Kelley (LINUX)]

From: Guilherme G. Piccoli  Sent: Wednesday, April 27, 
2022 3:49 PM
> 
> Currently Hyper-V guests are among the most relevant users of the panic
> infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
> both in cleaning-up procedures (closing a hypervisor <-> guest connection,
> disabling a paravirtualized timer) as well as to data collection (sending
> panic information to the hypervisor) and framebuffer management.
> 
> The thing is: some notifiers are related to others, ordering matters, some
> functionalities are duplicated and there are lots of conditionals behind
> sending panic information to the hypervisor. This patch, as part of an
> effort to clean-up the panic notifiers mechanism and better document
> things, address some of the issues/complexities of Hyper-V panic handling
> through the following changes:
> 
> (a) We have die and panic notifiers on vmbus_drv.c and both have goals of
> sending panic information to the hypervisor, though the panic notifier is
> also responsible for a cleaning-up procedure.
> 
> This commit clears the code by splitting the panic notifier in two, one
> for closing the vmbus connection whereas the other is only for sending
> panic info to hypervisor. With that, it was possible to merge the die and
> panic notifiers in a single/well-documented function, and clear some
> conditional complexities on sending such information to the hypervisor.
> 
> (b) The new panic notifier created after (a) is only doing a single thing:
> cleaning the vmbus connection. This procedure might cause a delay (due to
> hypervisor I/O completion), so we postpone that to run late. But more
> relevant: this *same* vmbus unloading happens in the crash_shutdown()
> handler, so if kdump is set, we can safely skip this panic notifier and
> defer such clean-up to the kexec crash handler.

While the last sentence is true for Hyper-V on x86/x64, it's not true for
Hyper-V on ARM64.  x86/x64 has the 'machine_ops' data structure
with the ability to provide a custom crash_shutdown() function, which
Hyper-V does in the form of hv_machine_crash_shutdown().  But ARM64
has no mechanism to provide such a custom function that will eventually
do the needed vmbus_initiate_unload() before running kdump.

I'm not immediately sure what the best solution is for ARM64.  At this
point, I'm just pointing out the problem and will think about the tradeoffs
for various possible solutions.  Please do the same yourself. :-)

> 
> (c) There is also a Hyper-V framebuffer panic notifier, which relies in
> doing a vmbus operation that demands a valid connection. So, we must
> order this notifier with the panic notifier from vmbus_drv.c, in order to
> guarantee that the framebuffer code executes before the vmbus connection
> is unloaded.

Patch 21 of this set puts the Hyper-V FB panic notifier on the pre_reboot
notifier list, which means it won't execute before the VMbus connection
unload in the case of kdump.   This notifier is making sure that Hyper-V
is notified about the last updates made to the frame buffer before the
panic, so maybe it needs to be put on the hypervisor notifier list.  It
sends a message to Hyper-V over its existing VMbus channel, but it
does not wait for a reply.  It does, however, obtain a spin lock on the
ring buffer used to communicate with Hyper-V.   Unless someone has
a better suggestion, I'm inclined to take the risk of blocking on that
spin lock.

> 
> Also, this commit removes a useless header.
> 
> Although there is code rework and re-ordering, we expect that this change
> has no functional regressions but instead optimize the path and increase
> panic reliability on Hyper-V. This was tested on Hyper-V with success.
> 
> Fixes: 792f232d57ff ("Drivers: hv: vmbus: Fix potential crash on module 
> unload")
> Fixes: 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")

The "Fixes:" tags imply that these changes should be backported to older
longterm kernel versions, which I don't think is the case.  There is a
dependency on Patch 14 of your series where PANIC_NOTIFIER is
introduced.

> Cc: Andrea Parri (Microsoft) 
> Cc: Dexuan Cui 
> Cc: Haiyang Zhang 
> Cc: "K. Y. Srinivasan" 
> Cc: Michael Kelley 
> Cc: Stephen Hemminger 
> Cc: Tianyu Lan 
> Cc: Wei Liu 
> Tested-by: Fabio A M Martins 
> Signed-off-by: Guilherme G. Piccoli 
> ---
> 
> Special thanks to Michael Kelley for the good information about the Hyper-V
> panic path in email threads some months ago, and to Fabio for the testing
> performed.
> 
> Michael and all Microsoft folks: a careful analysis to double-check our 
> changes
> and assumptions here is really appreciated, this code is complex and 
> intricate,
> it is possible some corner case might have been overlooked.
> 
> Thanks in advance!
> 
>  drivers/hv/vmbus_drv.c  | 109 
>  drivers/video/fbdev/hyperv_fb.c |   8 +++
>  2 files changed, 76 insertions(+), 41 deletions(-)
> 
> diff --git 

[xen-unstable bisection] complete test-arm64-arm64-libvirt-raw

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-arm64-arm64-libvirt-raw
testid xen-boot

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  fa6dc0879ffd3daea2837953c7a8761a9ba0
  Bug not present: fbd2445558beff90eb9607308f0845b18a7a2b5a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/169871/


  commit fa6dc0879ffd3daea2837953c7a8761a9ba0
  Author: David Vrabel 
  Date:   Tue Apr 26 10:33:01 2022 +0200
  
  page_alloc: assert IRQs are enabled in heap alloc/free
  
  Heap pages can only be safely allocated and freed with interrupts
  enabled as they may require a TLB flush which may send IPIs (on x86).
  
  Normally spinlock debugging would catch calls from the incorrect
  context, but not from stop_machine_run() action functions as these are
  called with spin lock debugging disabled.
  
  Enhance the assertions in alloc_xenheap_pages() and
  alloc_domheap_pages() to check interrupts are enabled. For consistency
  the same asserts are used when freeing heap pages.
  
  As an exception, when only 1 PCPU is online, allocations are permitted
  with interrupts disabled as any TLB flushes would be local only. This
  is necessary during early boot.
  
  Signed-off-by: David Vrabel 
  Reviewed-by: Jan Beulich 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-arm64-arm64-libvirt-raw.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable/test-arm64-arm64-libvirt-raw.xen-boot
 --summary-out=tmp/169871.bisection-summary --basis-template=169775 
--blessings=real,real-bisect,real-retry xen-unstable 
test-arm64-arm64-libvirt-raw xen-boot
Searching for failure / basis pass:
 169819 fail [host=rochester0] / 169775 [host=rochester1] 169756 [host=laxton1] 
169723 [host=laxton1] 169694 [host=rochester1] 169666 ok.
Failure / basis pass flights: 169819 / 169666
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2c846fa6bcc11929c9fb857a22430fb9945654ad 
27acf0ef828bf719b2053ba398b195829413dbdd 
f0f0e602f7c9781699ecda9be763eac0b03d54f0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
a68d6d311c2d1fd9d2fa9a0768ea2353e8a79b42 
da28439ba55b8a571032b3358af567cff749f612
Basis pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 
27acf0ef828bf719b2053ba398b195829413dbdd 
f0f0e602f7c9781699ecda9be763eac0b03d54f0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
a68d6d311c2d1fd9d2fa9a0768ea2353e8a79b42 
2419a159fb943c24a6f2439604b9fdb1478fcd08
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#2c846fa6bcc11929c9fb857a22430fb9945654ad-2c846fa6bcc11929c9fb857a22430fb9945654ad
 
https://gitlab.com/keycodemap/keycodemapdb.git#27acf0ef828bf719b2053ba398b195829413dbdd-27acf0ef828bf719b2053ba398b195829413dbdd
 
git://xenbits.xen.org/linux-pvops.git#f0f0e602f7c9781699ecda9be763eac0b03d54f0-f0f0e602f7c9781699ecda9be763eac0b03d54f0
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0\
 dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 
git://xenbits.xen.org/qemu-xen.git#a68d6d311c2d1fd9d2fa9a0768ea2353e8a79b42-a68d6d311c2d1fd9d2fa9a0768ea2353e8a79b42
 
git://xenbits.xen.org/xen.git#2419a159fb943c24a6f2439604b9fdb1478fcd08-da28439ba55b8a571032b3358af567cff749f612
Loaded 5001 nodes in revision graph
Searching for test results:
 169635 [host=laxton1]
 169666 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 
27acf0ef828bf719b2053ba398b195829413dbdd 
f0f0e602f7c9781699ecda9be763eac0b03d54f0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
a68d6d311c2d1fd9d2fa9a0768ea2353e8a79b42 
2419a159fb943c24a6f2439604b9fdb1478fcd08
 169694 [host=rochester1]
 169723 [host=laxton1]
 169756 [host=laxton1]
 169775 [host=rochester1]
 169798 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 
27acf0ef828bf719b2053ba398b195829413dbdd 
f0f0e602f7c9781699ecda9be763eac0b03d54f0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
a68d6d311c2d1fd9d2fa9a0768ea2353e8a79b42 
53b705d02cec03861044e673536586bd1b2443bd
 169823 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 
27acf0ef828bf719b2053ba398b195829413dbdd 
f0f0e602f7c9781699ecda9be763eac0b03d54f0 

Re: [PATCH v3 3/4] Add a new hypercall to get the ESRT

[Demi Marie Obenour]

On Fri, Apr 29, 2022 at 10:40:42AM +0200, Jan Beulich wrote:
> On 29.04.2022 00:54, Demi Marie Obenour wrote:
> > On Thu, Apr 28, 2022 at 08:47:49AM +0200, Jan Beulich wrote:
> >> On 27.04.2022 21:08, Demi Marie Obenour wrote:
> >>> On Wed, Apr 27, 2022 at 10:56:34AM +0200, Jan Beulich wrote:
>  On 19.04.2022 17:49, Demi Marie Obenour wrote:
> > This hypercall can be used to get the ESRT from the hypervisor.  It
> > returning successfully also indicates that Xen has reserved the ESRT and
> > it can safely be parsed by dom0.
> 
>  I'm not convinced of the need, and I view such an addition as 
>  inconsistent
>  with the original intentions. The pointer comes from the config table,
>  which Dom0 already has access to. All a Dom0 kernel may need to know in
>  addition is whether the range was properly reserved. This could be 
>  achieved
>  by splitting the EFI memory map entry in patch 2, instead of only 
>  splitting
>  the E820 derivation, as then XEN_FW_EFI_MEM_INFO can be used to find out
>  the range's type. Another way to find out would be for Dom0 to attempt to
>  map this area as MMIO, after first checking that no part of the range is 
>  in
>  its own memory allocation. This 2nd approach may, however, not really be
>  suitable for PVH Dom0, I think.
> >>>
> >>> On further thought, I think the hypercall approach is actually better
> >>> than reserving the ESRT.  I really do not want XEN_FW_EFI_MEM_INFO to
> >>> return anything other than the actual firmware-provided memory
> >>> information, and the current approach seems to require more and more
> >>> special-casing of the ESRT, not to mention potentially wasting memory
> >>> and splitting a potentially large memory region into two smaller ones.
> >>> By copying the entire ESRT into memory owned by Xen, the logic becomes
> >>> significantly simpler on both the Xen and dom0 sides.
> >>
> >> I actually did consider the option of making a private copy when you did
> >> send the initial version of this, but I'm not convinced this simplifies
> >> things from a kernel perspective: They'd now need to discover the table
> >> by some entirely different means. In Linux at least such divergence
> >> "just for Xen" hasn't been liked in the past.
> >>
> >> There's also the question of how to propagate the information across
> >> kexec. But I guess that question exists even outside of Xen, with the
> >> area living in memory which the OS is expected to recycle.
> > 
> > Indeed it does.  A simple rule might be, “Only trust the ESRT if it is
> > in memory of type EfiRuntimeServicesData.”  That is easy to achieve by
> > monkeypatching the config table as you suggested below.
> > 
> > I *am* worried that the config table might be mapped read-only on some
> > systems, in which case the overwrite would cause a fatal page fault.  Is
> > there a way for Xen to check for this?
> 
> While in boot mode, aiui page tables aren't supposed to be enforcing
> access restrictions. Recall that on other architectures EFI even runs
> with paging disabled; this simply is not possible for x86-64.

Yikes!  No wonder firmware has nonexistent exploit mitigations.  They
really ought to start porting UEFI to Rust, with ASLR, NX, stack
canaries, a hardened allocator, and support for de-priviliged services
that run in user mode.

That reminds me: Can Xen itself run from ROM?  Xen is being ported to
POWER for use in Qubes OS, and one approach under consideration is to
have Xen and a mini-dom0 be part of the firmware.  Personally, I really
like this approach, as it makes untrusted storage domains much simpler.
If this should be a separate email thread, let me know.

> So
> portable firmware shouldn't map anything r/o. In principle the pointer
> could still be in ROM; I consider this unlikely, but we could check
> for that (just like we could do a page table walk to figure out
> whether a r/o mapping would prevent us from updating the field).

Is there a utility function that could be used for this?

> >  It could also be undefined behavior to modify it.
> 
> That's the bigger worry I have.

Turns out that it is *not* undefined behavior, so long as
ExitBootServices() has not been called.  This is becaues EFI drivers
will modify the config table, so firmware cannot assume it to be
read-only.

> >>> Is using ebmalloc() to allocate a copy of the ESRT a reasonable option?
> >>
> >> I'd suggest to try hard to avoid ebmalloc(). It ought to be possible to
> >> make the copy before ExitBootServices(), via normal EFI allocation. If
> >> replacing a pointer in the config table was okay(ish), this could even
> >> be utilized to overcome the kexec problem.
> > 
> > What type should I use for the allocation?  EfiLoaderData looks like the
> > most consistent choice, but I am not sure if memory so allocated remains
> > valid when Xen hands off to the OS, so EfiRuntimeServicesData might be a
> > better choice.
> 
> It definitely is. We 

[ovmf test] 169873: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  697 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   18 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [xen-unstable-smoke test] 169781: regressions - FAIL

[Julien Grall]

On 29/04/2022 17:15, Stefano Stabellini wrote:

Which seems to be the right sequence to me. There must be an early boot
phase where interrupts are disabled on a CPU but memory allocations are
possible. If this was x86 with the tlbflush limitation, I would suggest
to have per-cpu memory mapping areas so that we don't have to do any
global tlb flushes with interrupts disabled.

On ARM, we don't have the tlbflush limitation so we could do that but we
wouldn't have much to gain from it.

Also, this seems to be a bit of a special case, because in general we
can move drivers initializations later after local_irq_enable(). But
this is the interrupt controller driver itself -- we cannot move it
after local_irq_enable().

So maybe an ad-hoc solution could be acceptable?


We don't need any ad-hoc solution here. We can register a CPU notifier that
will notify us when a CPU will be prepared. Something like below should work
(untested yet):


The CPU notifier is a good idea. It looks like the patch below got
corrupted somehow by the mailer. If you send it as a proper patch I am
happy to have a look.


Doh. I will send a proper patch once I have done some testing.

Cheers,

--
Julien Grall

[ovmf test] 169872: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  696 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   17 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

RE: [PATCH 18/30] notifier: Show function names on notifier routines if DEBUG_NOTIFIERS is set

[Michael Kelley (LINUX)]

From: Guilherme G. Piccoli  Sent: Wednesday, April 27, 
2022 3:49 PM
> 
> Currently we have a debug infrastructure in the notifiers file, but
> it's very simple/limited. This patch extends it by:
> 
> (a) Showing all registered/unregistered notifiers' callback names;
> 
> (b) Adding a dynamic debug tuning to allow showing called notifiers'
> function names. Notice that this should be guarded as a tunable since
> it can flood the kernel log buffer.
> 
> Cc: Arjan van de Ven 
> Cc: Cong Wang 
> Cc: Sebastian Andrzej Siewior 
> Cc: Valentin Schneider 
> Cc: Xiaoming Ni 
> Signed-off-by: Guilherme G. Piccoli 
> ---
> 
> We have some design decisions that worth discussing here:
> 
> (a) First of call, using C99 helps a lot to write clear and concise code, but

s/call/all/

> due to commit 4d94f910e79a ("Kbuild: use -Wdeclaration-after-statement") we
> have a warning if mixing variable declarations with code. For this patch 
> though,
> doing that makes the code way clear, so decision was to add the debug code
> inside brackets whenever this warning pops up. We can change that, but that'll
> cause more ifdefs in the same function.
> 
> (b) In the symbol lookup helper function, we modify the parameter passed but
> even more, we return it as well! This is unusual and seems unnecessary, but 
> was
> the strategy taken to allow embedding such function in the pr_debug() call.
> 
> Not doing that would likely requiring 3 symbol_name variables to avoid
> concurrency (registering notifier A while calling notifier B) - we rely in
> local variables as a serialization mechanism.
> 
> We're open for suggestions in case this design is not appropriate;
> thanks in advance!
> 
>  kernel/notifier.c | 48 +--
>  1 file changed, 46 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/notifier.c b/kernel/notifier.c
> index ba005ebf4730..21032ebcde57 100644
> --- a/kernel/notifier.c
> +++ b/kernel/notifier.c
> @@ -7,6 +7,22 @@
>  #include 
>  #include 
> 
> +#ifdef CONFIG_DEBUG_NOTIFIERS
> +#include 
> +
> +/*
> + *   Helper to get symbol names in case DEBUG_NOTIFIERS is set.
> + *   Return the modified parameter is a strategy used to achieve
> + *   the pr_debug() functionality - with this, function is only
> + *   executed if the dynamic debug tuning is effectively set.
> + */
> +static inline char *notifier_name(struct notifier_block *nb, char *sym_name)
> +{
> + lookup_symbol_name((unsigned long)(nb->notifier_call), sym_name);
> + return sym_name;
> +}
> +#endif
> +
>  /*
>   *   Notifier list for kernel code which wants to be called
>   *   at shutdown. This is used to stop any idling DMA operations
> @@ -34,20 +50,41 @@ static int notifier_chain_register(struct notifier_block 
> **nl,
>   }
>   n->next = *nl;
>   rcu_assign_pointer(*nl, n);
> +
> +#ifdef CONFIG_DEBUG_NOTIFIERS
> + {
> + char sym_name[KSYM_NAME_LEN];
> +
> + pr_info("notifiers: registered %s()\n",
> + notifier_name(n, sym_name));
> + }
> +#endif
>   return 0;
>  }
> 
>  static int notifier_chain_unregister(struct notifier_block **nl,
>   struct notifier_block *n)
>  {
> + int ret = -ENOENT;
> +
>   while ((*nl) != NULL) {
>   if ((*nl) == n) {
>   rcu_assign_pointer(*nl, n->next);
> - return 0;
> + ret = 0;
> + break;
>   }
>   nl = &((*nl)->next);
>   }
> - return -ENOENT;
> +
> +#ifdef CONFIG_DEBUG_NOTIFIERS
> + if (!ret) {
> + char sym_name[KSYM_NAME_LEN];
> +
> + pr_info("notifiers: unregistered %s()\n",
> + notifier_name(n, sym_name));
> + }
> +#endif
> + return ret;
>  }
> 
>  /**
> @@ -80,6 +117,13 @@ static int notifier_call_chain(struct notifier_block **nl,
>   nb = next_nb;
>   continue;
>   }
> +
> + {
> + char sym_name[KSYM_NAME_LEN];
> +
> + pr_debug("notifiers: calling %s()\n",
> +  notifier_name(nb, sym_name));
> + }
>  #endif
>   ret = nb->notifier_call(nb, val, v);
> 
> --
> 2.36.0

RE: [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path

[Michael Kelley (LINUX)]

From: Guilherme G. Piccoli  Sent: Wednesday, April 27, 
2022 3:49 PM
> 
> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> is responsible for that. This makes sense, since we're turning off
> such CPUs, putting them in an endless busy-wait loop.
> 
> Problem is that there is an alternative path for disabling CPUs,
> in the form of function crash_smp_send_stop(), used for kexec/panic
> paths. This functions relies in a SMP call that also triggers a

s/functions relies in/function relies on/

> busy-wait loop [at machine_crash_nonpanic_core()], but *without*
> disabling interrupts. This might lead to odd scenarios, like early
> interrupts in the boot of kexec'd kernel or even interrupts in
> other CPUs while the main one still works in the panic path and
> assumes all secondary CPUs are (really!) off.
> 
> This patch mimics the ipi_cpu_stop() interrupt disable mechanism
> in the crash CPU shutdown path, hence disabling IRQs/FIQs in all
> secondary CPUs in the kexec/panic path as well.
> 
> Cc: Marc Zyngier 
> Cc: Russell King 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>  arch/arm/kernel/machine_kexec.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index f567032a09c0..ef788ee00519 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -86,6 +86,9 @@ void machine_crash_nonpanic_core(void *unused)
>   set_cpu_online(smp_processor_id(), false);
>   atomic_dec(_for_crash_ipi);
> 
> + local_fiq_disable();
> + local_irq_disable();
> +
>   while (1) {
>   cpu_relax();
>   wfe();
> --
> 2.36.0

Re: [xen-unstable-smoke test] 169781: regressions - FAIL

[Stefano Stabellini]

On Fri, 29 Apr 2022, Julien Grall wrote:
> On 29/04/2022 01:41, Stefano Stabellini wrote:
> > On Thu, 28 Apr 2022, Julien Grall wrote:
> > > On 28/04/2022 01:47, Stefano Stabellini wrote:
> > > > On Thu, 28 Apr 2022, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > > 
> > > > > On Thu, 28 Apr 2022, 00:02 Stefano Stabellini,
> > > > > 
> > > > > wrote
> > > > > It seems to me that it is acceptable to allocate memory with
> > > > > interrupt
> > > > > disabled during __init. I cannot see any drawbacks with it. I
> > > > > think
> > > > > we
> > > > > should change the ASSERT to only trigger after __init:
> > > > > system_state
> > > > > ==
> > > > > SYS_STATE_active.
> > > > > 
> > > > > What do you think?
> > > > > 
> > > > > 
> > > > > This would solve the immediate problem but not the long term one (i.e
> > > > > cpu
> > > > > hotplug).
> > > > > 
> > > > > So I think it would be better to properly fix it right away.
> > > > 
> > > > Yeah, you are right about cpu hotplug. I think both statements are true:
> > > > 
> > > > - it is true that this is supposed to work with cpu hotplug and these
> > > > functions might be directly affected by cpu hotplug (by a CPU coming
> > > > online later on)
> > > > 
> > > > - it is also true that it might not make sense to ASSERT at __init time
> > > > if IRQs are disabled. There might be other places, not affected by
> > > > cpu
> > > > hotplug, where we do memory allocation at __init time with IRQ
> > > > disabled. It might still be a good idea to add the system_state ==
> > > > SYS_STATE_active check in the ASSERT, not to solve this specific
> > > > problem but to avoid other issues.
> > > 
> > > AFAIU, it is not safe on x86 to do TLB flush with interrupts disabled
> > > *and*
> > > multiple CPUs running. So we can't generically relax the check.
> > > 
> > > Looking at the OSSTest results, both Arm32 and Arm64 without GICv3 ITS
> > > tests
> > > have passed. So it seems unnecessary to me to preemptively relax the check
> > > just for Arm.
> > 
> > It is good news that it works already (GICv3 aside) on ARM. If you
> > prefer not to relax it, I am OK with it (although it makes me a bit
> > worried about future breakages).
> 
> Bear in mind this is a debug only breakage, production build will work fines
> with any ASSERT() affecting large code base, it is going to be difficult to
> find all the potential misuse. So we have to rely on wider testing and fix it
> as it gets reported.
> 
> If we relax the check, then we are never going to be able to harden the code
> in timely maneer.
> 
> > > > In regard to gicv3_lpi_allocate_pendtable, I haven't thought about the
> > > > implications of cpu hotplug for LPIs and GICv3 before. Do you envision
> > > > that in a CPU hotplug scenario gicv3_lpi_init_rdist would be called when
> > > > the extra CPU comes online?
> > > 
> > > It is already called per-CPU. See gicv3_secondary_cpu_init() ->
> > > gicv3_cpu_init() -> gicv3_populate_rdist().
> > 
> > Got it, thanks!
> > 
> > 
> > > > Today gicv3_lpi_init_rdist is called based on the number of
> > > > rdist_regions without checking if the CPU is online or offline (I think
> > > > ?)
> > > 
> > > The re-distributors are not banked and therefore accessible by everyone.
> > > However, in Xen case, each pCPU will only touch its own re-distributor
> > > (well
> > > aside TYPER to figure out the ID).
> > > 
> > > The loop in gicv3_populate_rdist() will walk throught all the
> > > re-distributor to find which one corresponds to the current pCPU. Once we
> > > found it, we will call gicv3_lpi_init_rdist() to fully initialize the
> > > re-distributor.
> > > 
> > > I don't think we want to populate the memory for each re-distributor in
> > > advance.
> > 
> > I agree.
> > 
> > Currently we do:
> > 
> >  start_secondary
> >  [...]
> >  gic_init_secondary_cpu()
> >  [...]
> >  gicv3_lpi_init_rdist()
> >  [...]
> >  local_irq_enable();
> > 
> > Which seems to be the right sequence to me. There must be an early boot
> > phase where interrupts are disabled on a CPU but memory allocations are
> > possible. If this was x86 with the tlbflush limitation, I would suggest
> > to have per-cpu memory mapping areas so that we don't have to do any
> > global tlb flushes with interrupts disabled.
> > 
> > On ARM, we don't have the tlbflush limitation so we could do that but we
> > wouldn't have much to gain from it.
> > 
> > Also, this seems to be a bit of a special case, because in general we
> > can move drivers initializations later after local_irq_enable(). But
> > this is the interrupt controller driver itself -- we cannot move it
> > after local_irq_enable().
> > 
> > So maybe an ad-hoc solution could be acceptable?
> 
> We don't need any ad-hoc solution here. We can register a CPU notifier that
> will notify us when a CPU will be prepared. Something like below should work
> 

Re: [PATCH v4 3/3] amd/msr: implement VIRT_SPEC_CTRL for HVM guests using legacy SSBD

[Roger Pau Monné]

On Fri, Apr 29, 2022 at 05:49:42PM +0200, Roger Pau Monné wrote:
> On Fri, Apr 29, 2022 at 12:59:58PM +0200, Jan Beulich wrote:
> > On 27.04.2022 12:47, Roger Pau Monne wrote:> Changes since v3:>  - Align 
> > ssbd per-core struct to a cache line.>  - Open code a simple spinlock to 
> > avoid playing tricks with the lock>detector.>  - 
> > s/ssbd_core/ssbd_ls_cfg/.>  - Fix log message wording.>  - Fix define name 
> > and remove comment.>  - Also handle Hygon processors (Fam18h).>  - Add 
> > changelog entry.
> > What is this last line about?
> 
> Hm, seems like I forgot to do a patch refresh... So new version will
> have an entry about adding VIRT_SSBD support to HVM guests. Sorry for
> spoiling the surprise.
> 
> > > +bool __init amd_setup_legacy_ssbd(void)
> > > +{
> > > + unsigned int i;
> > > +
> > > + if ((boot_cpu_data.x86 != 0x17 && boot_cpu_data.x86 != 0x18) ||
> > > + boot_cpu_data.x86_num_siblings <= 1)
> > > + return true;
> > > +
> > > + /*
> > > +  * One could be forgiven for thinking that c->x86_max_cores is the
> > > +  * correct value to use here.
> > > +  *
> > > +  * However, that value is derived from the current configuration, and
> > > +  * c->cpu_core_id is sparse on all but the top end CPUs.  Derive
> > > +  * max_cpus from ApicIdCoreIdSize which will cover any sparseness.
> > > +  */
> > > + if (boot_cpu_data.extended_cpuid_level >= 0x8008) {
> > > + ssbd_max_cores = 1u << MASK_EXTR(cpuid_ecx(0x8008), 0xf000);
> > > + ssbd_max_cores /= boot_cpu_data.x86_num_siblings;
> > > + }
> > > + if (!ssbd_max_cores)
> > > + return false;
> > > +
> > > + ssbd_ls_cfg = xzalloc_array(struct ssbd_ls_cfg,
> > > + ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS);
> > > + if (!ssbd_ls_cfg)
> > > + return false;
> > > +
> > > + for (i = 0; i < ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS; i++)
> > > + /* Record initial state, also applies to any hotplug CPU. */
> > > + if (opt_ssbd)
> > > + ssbd_ls_cfg[i].count = boot_cpu_data.x86_num_siblings;
> > 
> > Perhaps flip if() and for()?
> 
> Indeed, thanks.
> 
> > > +void amd_set_legacy_ssbd(bool enable)
> > > +{
> > > + const struct cpuinfo_x86 *c = _cpu_data;
> > > + struct ssbd_ls_cfg *status;
> > > +
> > > + if (c->x86 != 0x17 || c->x86_num_siblings <= 1) {
> > > + BUG_ON(!set_legacy_ssbd(c, enable));
> > > + return;
> > > + }
> > > +
> > > + BUG_ON(c->phys_proc_id >= AMD_FAM17H_MAX_SOCKETS);
> > > + BUG_ON(c->cpu_core_id >= ssbd_max_cores);
> > > + status = _ls_cfg[c->phys_proc_id * ssbd_max_cores +
> > > +   c->cpu_core_id];
> > > +
> > > + /*
> > > +  * Open code a very simple spinlock: this function is used with GIF==0
> > > +  * and different IF values, so would trigger the checklock detector.
> > > +  * Instead of trying to workaround the detector, use a very simple lock
> > > +  * implementation: it's better to reduce the amount of code executed
> > > +  * with GIF==0.
> > > +  */
> > > + while ( test_and_set_bool(status->locked) )
> > > + cpu_relax();
> > > + status->count += enable ? 1 : -1;
> > > + ASSERT(status->count <= c->x86_num_siblings);
> > > + if (enable ? status->count == 1 : !status->count)
> > > + BUG_ON(!set_legacy_ssbd(c, enable));
> > 
> > What are the effects of ASSERT() or BUG_ON() triggering in a GIF=0
> > region?
> 
> So AFAICT the BUG itself works, the usage of a crash kernel however
> won't work as it's booted with GIF==0.
> 
> Maybe we need to issue an stgi as part of BUG_FRAME if required?
> (maybe that's too naive...)

Well, better in panic() or kexec_crash() likely.

Roger.

Re: [PATCH v2 14/19] xen/drmfront: use xenbus_setup_ring() and xenbus_teardown_ring()

[Oleksandr]

On 28.04.22 11:27, Juergen Gross wrote:

Hello Juergen, all


Simplify drmfront's ring creation and removal via xenbus_setup_ring()
and xenbus_teardown_ring().

Signed-off-by: Juergen Gross 



I am not familiar with DRM bits of this driver, but a little bit 
familiar with Xen bits this patch only touches and I have environment to 
test.


Xen specific changes looks good to me. Also I didn't see any specific to 
this series issues when testing virtulized display driver except one I 
have already pointed out in PATCH v2 08/19.


root@salvator-x-h3-4x2g-xt-domu:~# dmesg | grep drm
[    0.158190] [drm] Registering XEN PV vdispl
[    0.159620] [drm] Connector device/vdispl/0/0: resolution 1920x1080
[    0.159888] [drm] Have 1 connector(s)
[    0.289069] [drm] Creating Xen PV DRM Display Unit
[    0.289873] [drm] Initialized xendrm-du 1.0.0 20180221 for vdispl-0 
on minor 0

[    0.289918] [drm] Initialized xendrm-du 1.0.0 20180221 on minor 0


root@generic-armv8-xt-dom0:~# xenstore-ls -f | grep vdispl
/local/domain/1/backend/vdispl = ""
/local/domain/1/backend/vdispl/2 = ""
/local/domain/1/backend/vdispl/2/0 = ""
/local/domain/1/backend/vdispl/2/0/frontend = 
"/local/domain/2/device/vdispl/0"

/local/domain/1/backend/vdispl/2/0/frontend-id = "2"
/local/domain/1/backend/vdispl/2/0/online = "1"
/local/domain/1/backend/vdispl/2/0/state = "4"
/local/domain/2/device/vdispl = ""
/local/domain/2/device/vdispl/0 = ""
/local/domain/2/device/vdispl/0/backend = 
"/local/domain/1/backend/vdispl/2/0"

/local/domain/2/device/vdispl/0/backend-id = "1"
/local/domain/2/device/vdispl/0/state = "4"
/local/domain/2/device/vdispl/0/be-alloc = "0"
/local/domain/2/device/vdispl/0/0 = ""
/local/domain/2/device/vdispl/0/0/resolution = "1920x1080"
/local/domain/2/device/vdispl/0/0/unique-id = "HDMI-A-1"
/local/domain/2/device/vdispl/0/0/req-ring-ref = "8"
/local/domain/2/device/vdispl/0/0/req-event-channel = "7"
/local/domain/2/device/vdispl/0/0/evt-ring-ref = "9"
/local/domain/2/device/vdispl/0/0/evt-event-channel = "8"
/libxl/2/device/vdispl = ""
/libxl/2/device/vdispl/0 = ""
/libxl/2/device/vdispl/0/frontend = "/local/domain/2/device/vdispl/0"
/libxl/2/device/vdispl/0/backend = "/local/domain/1/backend/vdispl/2/0"
/libxl/2/device/vdispl/0/frontend-id = "2"
/libxl/2/device/vdispl/0/online = "1"
/libxl/2/device/vdispl/0/state = "1"


It worth mentioning I noticed one issue, but I believe it is not related 
to your series.


root@salvator-x-h3-4x2g-xt-domu:~# modetest -M xendrm-du -s 31:1920x1080
[   62.431887] [ cut here ]
[   62.431940] WARNING: CPU: 0 PID: 244 at 
drivers/gpu/drm/drm_gem.c:1055 drm_gem_mmap_obj+0x16c/0x180

[   62.432000] Modules linked in:
[   62.432025] CPU: 0 PID: 244 Comm: modetest Tainted: G W 
5.18.0-rc4-yocto-standard-00096-g936342d8fae2 #1

[   62.432067] Hardware name: XENVM-4.17 (DT)
[   62.432089] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS 
BTYPE=--)

[   62.432126] pc : drm_gem_mmap_obj+0x16c/0x180
[   62.432153] lr : drm_gem_mmap_obj+0x78/0x180
[   62.432178] sp : 89da3bb0
[   62.432196] x29: 89da3bb0 x28: 0008 x27: 
0001c3a56780
[   62.432237] x26: 0001c3a56f00 x25: 07e9 x24: 
0001c23dec00
[   62.432279] x23: 0001c0c98000 x22: 0001c2162b80 x21: 

[   62.432320] x20: 0001c3a56780 x19: 0001c23dea00 x18: 
0001
[   62.432355] x17:  x16:  x15: 
0003603c
[   62.432394] x14:  x13:  x12: 

[   62.432430] x11: 0010 x10: 88071000 x9 : 
0001c0f17e70
[   62.432470] x8 : 8001f65ce000 x7 : 0001 x6 : 
0001c388a000
[   62.432505] x5 : 89da3a10 x4 : 0090 x3 : 
10046400
[   62.432539] x2 : 07e9 x1 : 9b0023a536f4f400 x0 : 
10fb

[   62.432579] Call trace:
[   62.432593]  drm_gem_mmap_obj+0x16c/0x180
[   62.432617]  drm_gem_mmap+0x128/0x228
[   62.432641]  mmap_region+0x384/0x5a0
[   62.432667]  do_mmap+0x354/0x4f0
[   62.432687]  vm_mmap_pgoff+0xdc/0x108
[   62.432710]  ksys_mmap_pgoff+0x1b8/0x208
[   62.432734]  __arm64_sys_mmap+0x30/0x48
[   62.432760]  invoke_syscall+0x44/0x108
[   62.432783]  el0_svc_common.constprop.0+0xcc/0xf0
[   62.432811]  do_el0_svc+0x24/0x88
[   62.432831]  el0_svc+0x2c/0x88
[   62.432855]  el0t_64_sync_handler+0xb0/0xb8
[   62.432875]  el0t_64_sync+0x18c/0x190
[   62.432898] ---[ end trace  ]---
setting mode 1920x1080-60.00Hz@XR24 on connectors 31, crtc 34


Although we see that WARNING, the application still works. Looking into 
the code, I assume that problem is that frontend doesn't set the 
VM_DONTEXPAND flag in mmap callback.


This diff fixes an issue in my environment:

index 5a5bf4e..e31554d 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -71,7 +71,7 @@ static int 

Re: [PATCH 24/30] panic: Refactor the panic path

[Guilherme G. Piccoli]

On 27/04/2022 21:28, Randy Dunlap wrote:
> 
> 
> On 4/27/22 15:49, Guilherme G. Piccoli wrote:
>> +crash_kexec_post_notifiers
>> +This was DEPRECATED - users should always prefer the
> 
>   This is DEPRECATED - users should always prefer the
> 
>> +parameter "panic_notifiers_level" - check its entry
>> +in this documentation for details on how it works.
>> +Setting this parameter is exactly the same as setting
>> +"panic_notifiers_level=4".
> 

Thanks Randy, for your suggestion - but I confess I couldn't understand
it properly. It's related to spaces/tabs, right? What you suggest me to
change in this formatting? Just by looking the email I can't parse.

Cheers,


Guilherme

Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list

[Max Filippov]

On Wed, Apr 27, 2022 at 3:55 PM Guilherme G. Piccoli
 wrote:
>
> This patch renames the panic_notifier_list to panic_pre_reboot_list;
> the idea is that a subsequent patch will refactor the panic path
> in order to better split the notifiers, running some of them very
> early, some of them not so early [but still before kmsg_dump()] and
> finally, the rest should execute late, after kdump. The latter ones
> are now in the panic pre-reboot list - the name comes from the idea
> that these notifiers execute before panic() attempts rebooting the
> machine (if that option is set).
>
> We also took the opportunity to clean-up useless header inclusions,
> improve some notifier block declarations (e.g. in ibmasm/heartbeat.c)
> and more important, change some priorities - we hereby set 2 notifiers
> to run late in the list [iss_panic_event() and the IPMI panic_event()]
> due to the risks they offer (may not return, for example).
> Proper documentation is going to be provided in a subsequent patch,
> that effectively refactors the panic path.

[...]

>  arch/xtensa/platforms/iss/setup.c |  4 ++--For xtensa:

For xtensa:
Acked-by: Max Filippov 

-- 
Thanks.
-- Max

Re: [PATCH v4 3/3] amd/msr: implement VIRT_SPEC_CTRL for HVM guests using legacy SSBD

[Roger Pau Monné]

On Fri, Apr 29, 2022 at 12:59:58PM +0200, Jan Beulich wrote:
> On 27.04.2022 12:47, Roger Pau Monne wrote:> Changes since v3:>  - Align ssbd 
> per-core struct to a cache line.>  - Open code a simple spinlock to avoid 
> playing tricks with the lock>detector.>  - s/ssbd_core/ssbd_ls_cfg/.>  - 
> Fix log message wording.>  - Fix define name and remove comment.>  - Also 
> handle Hygon processors (Fam18h).>  - Add changelog entry.
> What is this last line about?

Hm, seems like I forgot to do a patch refresh... So new version will
have an entry about adding VIRT_SSBD support to HVM guests. Sorry for
spoiling the surprise.

> > +bool __init amd_setup_legacy_ssbd(void)
> > +{
> > +   unsigned int i;
> > +
> > +   if ((boot_cpu_data.x86 != 0x17 && boot_cpu_data.x86 != 0x18) ||
> > +   boot_cpu_data.x86_num_siblings <= 1)
> > +   return true;
> > +
> > +   /*
> > +* One could be forgiven for thinking that c->x86_max_cores is the
> > +* correct value to use here.
> > +*
> > +* However, that value is derived from the current configuration, and
> > +* c->cpu_core_id is sparse on all but the top end CPUs.  Derive
> > +* max_cpus from ApicIdCoreIdSize which will cover any sparseness.
> > +*/
> > +   if (boot_cpu_data.extended_cpuid_level >= 0x8008) {
> > +   ssbd_max_cores = 1u << MASK_EXTR(cpuid_ecx(0x8008), 0xf000);
> > +   ssbd_max_cores /= boot_cpu_data.x86_num_siblings;
> > +   }
> > +   if (!ssbd_max_cores)
> > +   return false;
> > +
> > +   ssbd_ls_cfg = xzalloc_array(struct ssbd_ls_cfg,
> > +   ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS);
> > +   if (!ssbd_ls_cfg)
> > +   return false;
> > +
> > +   for (i = 0; i < ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS; i++)
> > +   /* Record initial state, also applies to any hotplug CPU. */
> > +   if (opt_ssbd)
> > +   ssbd_ls_cfg[i].count = boot_cpu_data.x86_num_siblings;
> 
> Perhaps flip if() and for()?

Indeed, thanks.

> > +void amd_set_legacy_ssbd(bool enable)
> > +{
> > +   const struct cpuinfo_x86 *c = _cpu_data;
> > +   struct ssbd_ls_cfg *status;
> > +
> > +   if (c->x86 != 0x17 || c->x86_num_siblings <= 1) {
> > +   BUG_ON(!set_legacy_ssbd(c, enable));
> > +   return;
> > +   }
> > +
> > +   BUG_ON(c->phys_proc_id >= AMD_FAM17H_MAX_SOCKETS);
> > +   BUG_ON(c->cpu_core_id >= ssbd_max_cores);
> > +   status = _ls_cfg[c->phys_proc_id * ssbd_max_cores +
> > + c->cpu_core_id];
> > +
> > +   /*
> > +* Open code a very simple spinlock: this function is used with GIF==0
> > +* and different IF values, so would trigger the checklock detector.
> > +* Instead of trying to workaround the detector, use a very simple lock
> > +* implementation: it's better to reduce the amount of code executed
> > +* with GIF==0.
> > +*/
> > +   while ( test_and_set_bool(status->locked) )
> > +   cpu_relax();
> > +   status->count += enable ? 1 : -1;
> > +   ASSERT(status->count <= c->x86_num_siblings);
> > +   if (enable ? status->count == 1 : !status->count)
> > +   BUG_ON(!set_legacy_ssbd(c, enable));
> 
> What are the effects of ASSERT() or BUG_ON() triggering in a GIF=0
> region?

So AFAICT the BUG itself works, the usage of a crash kernel however
won't work as it's booted with GIF==0.

Maybe we need to issue an stgi as part of BUG_FRAME if required?
(maybe that's too naive...)

> > --- a/xen/arch/x86/cpuid.c
> > +++ b/xen/arch/x86/cpuid.c
> > @@ -544,6 +544,16 @@ static void __init calculate_hvm_max_policy(void)
> >  if ( !boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
> >  /* Clear VIRT_SSBD if VIRT_SPEC_CTRL is not exposed to guests. */
> >  __clear_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
> > +else
> > +/*
> > + * Expose VIRT_SSBD if VIRT_SPEC_CTRL is supported, as that 
> > implies the
> > + * underlying hardware is capable of setting SSBD using
> > + * non-architectural way or VIRT_SSBD is available.
> > + *
> > + * Note that if the hardware supports VIRT_SSBD natively this 
> > setting
> > + * will just override an already set bit.
> > + */
> > +__set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
> 
> With the 's' annotation gone from the public header, is this last
> sentence of the comment actually true? Aiui code near the top of
> the function would have zapped the bit from hvm_featureset[].

This comment is now gone, and there are no changes to
calculate_hvm_max_policy in this patch anymore.

> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -3126,6 +3126,8 @@ void vmexit_virt_spec_ctrl(void)
> >  
> >  if ( cpu_has_virt_ssbd )
> >  wrmsr(MSR_VIRT_SPEC_CTRL, val, 0);
> > +else
> > + amd_set_legacy_ssbd(opt_ssbd);
> 
> Nit: Indentation is off by one here. Of course this alone could
> easily be adjusted while 

[ovmf test] 169868: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  695 attempts
Testing same since   169816  2022-04-28 14:41:38 Z1 days   16 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [PATCH v2 08/19] xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF

[Oleksandr]

Hello Juergen


On 28.04.22 21:03, Oleksandr Tyshchenko wrote:



On Thu, Apr 28, 2022 at 11:28 AM Juergen Gross > wrote:


Hello Juergen

[sorry for the possible format issue]

Instead of using a private macro for an invalid grant reference use
the common one.

Signed-off-by: Juergen Gross mailto:jgr...@suse.com>>
---
 drivers/xen/xen-front-pgdir-shbuf.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/xen/xen-front-pgdir-shbuf.c
b/drivers/xen/xen-front-pgdir-shbuf.c
index a959dee21134..fa2921d4fbfc 100644
--- a/drivers/xen/xen-front-pgdir-shbuf.c
+++ b/drivers/xen/xen-front-pgdir-shbuf.c
@@ -21,15 +21,6 @@

 #include 

-#ifndef GRANT_INVALID_REF
-/*
- * FIXME: usage of grant reference 0 as invalid grant reference:
- * grant reference 0 is valid, but never exposed to a PV driver,
- * because of the fact it is already in use/reserved by the PV
console.
- */
-#define GRANT_INVALID_REF      0
-#endif
-
 /**
  * This structure represents the structure of a shared page
  * that contains grant references to the pages of the shared
@@ -83,7 +74,7 @@ grant_ref_t
 xen_front_pgdir_shbuf_get_dir_start(struct xen_front_pgdir_shbuf
*buf)
 {
        if (!buf->grefs)
-               return GRANT_INVALID_REF;
+               return INVALID_GRANT_REF;

        return buf->grefs[0];
 }
@@ -142,7 +133,7 @@ void xen_front_pgdir_shbuf_free(struct
xen_front_pgdir_shbuf *buf)
                int i;

                for (i = 0; i < buf->num_grefs; i++)
-                       if (buf->grefs[i] != GRANT_INVALID_REF)
+                       if (buf->grefs[i] != INVALID_GRANT_REF)
gnttab_end_foreign_access(buf->grefs[i], 0UL);
        }
        kfree(buf->grefs);
@@ -355,7 +346,7 @@ static void backend_fill_page_dir(struct
xen_front_pgdir_shbuf *buf)
        }
        /* Last page must say there is no more pages. */
        page_dir = (struct xen_page_directory *)ptr;
-       page_dir->gref_dir_next_page = GRANT_INVALID_REF;
+       page_dir->gref_dir_next_page = INVALID_GRANT_REF;
 }

 /**
@@ -384,7 +375,7 @@ static void guest_fill_page_dir(struct
xen_front_pgdir_shbuf *buf)

                if (grefs_left <= XEN_NUM_GREFS_PER_PAGE) {
                        to_copy = grefs_left;
-                       page_dir->gref_dir_next_page =
GRANT_INVALID_REF;
+                       page_dir->gref_dir_next_page =
INVALID_GRANT_REF;


I faced an issue with testing PV Sound with the current series.

root@salvator-x-h3-4x2g-xt-domu:~# aplay /media/MoodyLoop.wav
Playing WAVE '/media/MoodyLoop.wav' : Signed 16 bit Little Endian, 
Rate 44100 Hz, Stereo

(XEN) common/grant_table.c:1053:d1v2 Bad ref 0x for d6

Here we have an interesting situation. PV Sound frontend uses this 
xen-front-pgdir-shbuf framework. Technically, this patch changes 
page_dir->gref_dir_next_page (reference to the next page describing 
page directory) from 0 to 0x here.

#define INVALID_GRANT_REF  ((grant_ref_t)-1)

But according to the protocol (sndif.h), "0" means that there are no 
more pages in the list and the user space backend expects only that 
value. So receiving 0x it assumes there are pages in the list 
and trying to process...

https://elixir.bootlin.com/linux/v5.18-rc4/source/include/xen/interface/io/sndif.h#L650


I think, the same is relevant to backend_fill_page_dir() as well.



In addition to what I said yesterday:

PV Display also uses this xen-front-pgdir-shbuf framework. It's protocol 
(displif.h) also mentions the same as sndif.h if the context of 
gref_dir_next_page:


 * gref_dir_next_page - grant_ref_t, reference to the next page describing
 *   page directory. Must be 0 if there are no more pages in the list.


With that local change both PV devices work in my environment.

diff --git a/drivers/xen/xen-front-pgdir-shbuf.c 
b/drivers/xen/xen-front-pgdir-shbuf.c

index fa2921d..ad4a88e 100644
--- a/drivers/xen/xen-front-pgdir-shbuf.c
+++ b/drivers/xen/xen-front-pgdir-shbuf.c
@@ -346,7 +346,7 @@ static void backend_fill_page_dir(struct 
xen_front_pgdir_shbuf *buf)

    }
    /* Last page must say there is no more pages. */
    page_dir = (struct xen_page_directory *)ptr;
-   page_dir->gref_dir_next_page = INVALID_GRANT_REF;
+   page_dir->gref_dir_next_page = 0;
 }

 /**
@@ -375,7 +375,7 @@ static void guest_fill_page_dir(struct 
xen_front_pgdir_shbuf *buf)


    if (grefs_left <= XEN_NUM_GREFS_PER_PAGE) {
    to_copy = grefs_left;
-   page_dir->gref_dir_next_page = INVALID_GRANT_REF;
+   page_dir->gref_dir_next_page = 0;
    } else {
    to_copy = XEN_NUM_GREFS_PER_PAGE;
  

Re: [PATCH 21/30] panic: Introduce the panic pre-reboot notifier list

[Guilherme G. Piccoli]

On 28/04/2022 13:26, Corey Minyard wrote:
> [...]
> 
> For the IPMI portion:
> 
> Acked-by: Corey Minyard 

Thanks Alex and Corey for the ACKs!

> 
> Note that the IPMI panic_event() should always return, but it may take
> some time, especially if the IPMI controller is no longer functional.
> So the risk of a long delay is there and it makes sense to move it very
> late.
> 

Thanks, I agree - the patch moves it to the (latest - 1) position, since
some arch code might run as the latest and effectively stops the machine.
Cheers,


Guilherme

Re: [PATCH v2 19/19] xen/xenbus: eliminate xenbus_grant_ring()

[Oleksandr]

On 28.04.22 11:27, Juergen Gross wrote:


Hello Juergen



There is no external user of xenbus_grant_ring() left, so merge it into
the only caller xenbus_setup_ring().

Signed-off-by: Juergen Gross 
---
V2:
- make error message more precise (Andrew Cooper)
---
  drivers/xen/xenbus/xenbus_client.c | 65 +-
  include/xen/xenbus.h   |  2 -
  2 files changed, 19 insertions(+), 48 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c 
b/drivers/xen/xenbus/xenbus_client.c
index 1a2e0d94ccd1..d6fdd2d209d3 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -363,50 +363,6 @@ static void xenbus_switch_fatal(struct xenbus_device *dev, 
int depth, int err,
__xenbus_switch_state(dev, XenbusStateClosing, 1);
  }
  
-/**

- * xenbus_grant_ring
- * @dev: xenbus device
- * @vaddr: starting virtual address of the ring
- * @nr_pages: number of pages to be granted
- * @grefs: grant reference array to be filled in
- *
- * Grant access to the given @vaddr to the peer of the given device.
- * Then fill in @grefs with grant references.  Return 0 on success, or
- * -errno on error.  On error, the device will switch to
- * XenbusStateClosing, and the error will be saved in the store.
- */
-int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
- unsigned int nr_pages, grant_ref_t *grefs)
-{
-   int err;
-   unsigned int i;
-   grant_ref_t gref_head;
-
-   err = gnttab_alloc_grant_references(nr_pages, _head);
-   if (err) {
-   xenbus_dev_fatal(dev, err, "granting access to ring page");
-   return err;
-   }
-
-   for (i = 0; i < nr_pages; i++) {
-   unsigned long gfn;
-
-   if (is_vmalloc_addr(vaddr))
-   gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr));
-   else
-   gfn = virt_to_gfn(vaddr);
-
-   grefs[i] = gnttab_claim_grant_reference(_head);
-   gnttab_grant_foreign_access_ref(grefs[i], dev->otherend_id,
-   gfn, 0);
-
-   vaddr = vaddr + XEN_PAGE_SIZE;
-   }
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(xenbus_grant_ring);
-
  /*
   * xenbus_setup_ring
   * @dev: xenbus device
@@ -424,6 +380,7 @@ int xenbus_setup_ring(struct xenbus_device *dev, gfp_t gfp, 
void **vaddr,
  unsigned int nr_pages, grant_ref_t *grefs)
  {
unsigned long ring_size = nr_pages * XEN_PAGE_SIZE;
+   grant_ref_t gref_head;
unsigned int i;
int ret;
  
@@ -433,9 +390,25 @@ int xenbus_setup_ring(struct xenbus_device *dev, gfp_t gfp, void **vaddr,

goto err;
}
  
-	ret = xenbus_grant_ring(dev, *vaddr, nr_pages, grefs);

-   if (ret)
+   ret = gnttab_alloc_grant_references(nr_pages, _head);
+   if (ret) {
+   xenbus_dev_fatal(dev, ret, "granting access to %u ring pages",
+nr_pages);
goto err;
+   }
+
+   for (i = 0; i < nr_pages; i++) {
+   unsigned long gfn;
+
+   if (is_vmalloc_addr(*vaddr))
+   gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr[i]));
+   else
+   gfn = virt_to_gfn(vaddr[i]);
+
+   grefs[i] = gnttab_claim_grant_reference(_head);


gnttab_claim_grant_reference() can return error if no free grant 
reference remains.


I understand this patch only moves the code, but probably it would be 
better to add a missing check here (and likely rollback already 
processed grants if any?).





+   gnttab_grant_foreign_access_ref(grefs[i], dev->otherend_id,
+   gfn, 0);
+   }
  
  	return 0;
  
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h

index b533b4adc835..eaa932b99d8a 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -224,8 +224,6 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct 
xenbus_watch *watch,
 const char *pathfmt, ...);
  
  int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_state new_state);

-int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
- unsigned int nr_pages, grant_ref_t *grefs);
  int xenbus_setup_ring(struct xenbus_device *dev, gfp_t gfp, void **vaddr,
  unsigned int nr_pages, grant_ref_t *grefs);
  void xenbus_teardown_ring(void **vaddr, unsigned int nr_pages,


--
Regards,

Oleksandr Tyshchenko

Re: [PATCH v2] tools/libs/light: update xenstore entry when setting max domain memory

[Anthony PERARD]

On Wed, Apr 20, 2022 at 10:04:26AM +0200, Juergen Gross wrote:
> libxl_domain_setmaxmem() called during "xl mem-max" should update the
> domain's memory/static-max Xenstore node, as otherwise "xl mem-set"
> won't be able to set the memory size to the new maximum.

Setting domain's memory higher than the original mem-max only works on
PV and maybe PVH guest, right? Because on HVM, QEMU is told about
maxmem when starting a guest, and allocates some stuff from this address
(vga buffer, pci rom I think) so trying to give HVM guest more memory
after the fact is probably not going to go smoothly.

> Adjust the related comments and documentation accordingly.
> 
> Signed-off-by: Juergen Gross 
> ---
> V2:
> - adjust comments and docs (Anthony Perard)

Maybe `man xl` should be updated as well. In the section about `xl
mem-max`, there is:
"Note however that the initial maxmem value is still used as an
upper limit for xl mem-set.  Also note that calling xl mem-set will
reset this value."

That wouldn't be true anymore with this patch.

Thanks,

-- 
Anthony PERARD

Re: [PATCH 20/30] panic: Add the panic informational notifier list

[Guilherme G. Piccoli]

Thanks Paul and Suzuki for the ACKs.
Cheers,


Guilherme

Re: [PATCH 17/30] tracing: Improve panic/die notifiers

[Guilherme G. Piccoli]

On 29/04/2022 10:56, Steven Rostedt wrote:
> [...]
> No. The fallthrough keyword is only needed when there's code between case
> labels. As it is very common to list multiple cases for the same code path.
> That is:
> 
>   case DIE_OOPS:
>   case PANIC_NOTIFIER:
>   do_dump = 1;
>   break;
> 
> Does not need a fall through label, as there's no code between the DIE_OOPS
> and the PANIC_NOTIFIER. But if you had:
> 
>   case DIE_OOPS:
>   x = true;
>   case PANIC_NOTIFIER:
>   do_dump = 1;
>   break;
> 
> Then you do.
> 
> -- Steve

Thanks a bunch for the clarification, changed that for V2 =)

Re: [PATCH 12/30] parisc: Replace regular spinlock with spin_trylock on panic path

[Guilherme G. Piccoli]

On 28/04/2022 13:55, Helge Deller wrote:
> [...]
> You may add:
> Acked-by: Helge Deller  # parisc
> 
> Helge

Thanks Helge, added!
Cheers,


Guilherme

> 
> 
>> ---
>>  arch/parisc/include/asm/pdc.h |  1 +
>>  arch/parisc/kernel/firmware.c | 27 +++
>>  drivers/parisc/power.c| 17 ++---
>>  3 files changed, 34 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/parisc/include/asm/pdc.h b/arch/parisc/include/asm/pdc.h
>> index b643092d4b98..7a106008e258 100644
>> --- a/arch/parisc/include/asm/pdc.h
>> +++ b/arch/parisc/include/asm/pdc.h
>> @@ -83,6 +83,7 @@ int pdc_do_firm_test_reset(unsigned long ftc_bitmap);
>>  int pdc_do_reset(void);
>>  int pdc_soft_power_info(unsigned long *power_reg);
>>  int pdc_soft_power_button(int sw_control);
>> +int pdc_soft_power_button_panic(int sw_control);
>>  void pdc_io_reset(void);
>>  void pdc_io_reset_devices(void);
>>  int pdc_iodc_getc(void);
>> diff --git a/arch/parisc/kernel/firmware.c b/arch/parisc/kernel/firmware.c
>> index 6a7e315bcc2e..0e2f70b592f4 100644
>> --- a/arch/parisc/kernel/firmware.c
>> +++ b/arch/parisc/kernel/firmware.c
>> @@ -1232,15 +1232,18 @@ int __init pdc_soft_power_info(unsigned long 
>> *power_reg)
>>  }
>>
>>  /*
>> - * pdc_soft_power_button - Control the soft power button behaviour
>> - * @sw_control: 0 for hardware control, 1 for software control
>> + * pdc_soft_power_button{_panic} - Control the soft power button behaviour
>> + * @sw_control: 0 for hardware control, 1 for software control
>>   *
>>   *
>>   * This PDC function places the soft power button under software or
>>   * hardware control.
>> - * Under software control the OS may control to when to allow to shut
>> - * down the system. Under hardware control pressing the power button
>> + * Under software control the OS may control to when to allow to shut
>> + * down the system. Under hardware control pressing the power button
>>   * powers off the system immediately.
>> + *
>> + * The _panic version relies in spin_trylock to prevent deadlock
>> + * on panic path.
>>   */
>>  int pdc_soft_power_button(int sw_control)
>>  {
>> @@ -1254,6 +1257,22 @@ int pdc_soft_power_button(int sw_control)
>>  return retval;
>>  }
>>
>> +int pdc_soft_power_button_panic(int sw_control)
>> +{
>> +int retval;
>> +unsigned long flags;
>> +
>> +if (!spin_trylock_irqsave(_lock, flags)) {
>> +pr_emerg("Couldn't enable soft power button\n");
>> +return -EBUSY; /* ignored by the panic notifier */
>> +}
>> +
>> +retval = mem_pdc_call(PDC_SOFT_POWER, PDC_SOFT_POWER_ENABLE, 
>> __pa(pdc_result), sw_control);
>> +spin_unlock_irqrestore(_lock, flags);
>> +
>> +return retval;
>> +}
>> +
>>  /*
>>   * pdc_io_reset - Hack to avoid overlapping range registers of Bridges 
>> devices.
>>   * Primarily a problem on T600 (which parisc-linux doesn't support) but
>> diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
>> index 456776bd8ee6..8512884de2cf 100644
>> --- a/drivers/parisc/power.c
>> +++ b/drivers/parisc/power.c
>> @@ -37,7 +37,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -175,16 +174,21 @@ static void powerfail_interrupt(int code, void *x)
>>
>>
>>
>> -/* parisc_panic_event() is called by the panic handler.
>> - * As soon as a panic occurs, our tasklets above will not be
>> - * executed any longer. This function then re-enables the
>> - * soft-power switch and allows the user to switch off the system
>> +/*
>> + * parisc_panic_event() is called by the panic handler.
>> + *
>> + * As soon as a panic occurs, our tasklets above will not
>> + * be executed any longer. This function then re-enables
>> + * the soft-power switch and allows the user to switch off
>> + * the system. We rely in pdc_soft_power_button_panic()
>> + * since this version spin_trylocks (instead of regular
>> + * spinlock), preventing deadlocks on panic path.
>>   */
>>  static int parisc_panic_event(struct notifier_block *this,
>>  unsigned long event, void *ptr)
>>  {
>>  /* re-enable the soft-power switch */
>> -pdc_soft_power_button(0);
>> +pdc_soft_power_button_panic(0);
>>  return NOTIFY_DONE;
>>  }
>>
>> @@ -193,7 +197,6 @@ static struct notifier_block parisc_panic_block = {
>>  .priority   = INT_MAX,
>>  };
>>
>> -
>>  static int __init power_init(void)
>>  {
>>  unsigned long ret;
> 

[xen-unstable-smoke test] 169864: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  fe234237b6fc8afc5d8265850169ceeb3d2f81fd
baseline version:
 xen  e57477359071ab91429b0ebcbf7ff162242e2831

Last test of basis   169853  2022-04-29 05:00:25 Z0 days
Testing same since   169864  2022-04-29 10:00:27 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   e574773590..fe234237b6  fe234237b6fc8afc5d8265850169ceeb3d2f81fd -> smoke

Re: [PATCH] xen/arm: smmuv1: remove iommu group when deassign a device

[Rahul Singh]

Hi Julien,

> On 27 Apr 2022, at 6:42 pm, Julien Grall  wrote:
> 
> Hi,
> 
> On 27/04/2022 17:15, Rahul Singh wrote:
>> When a device is deassigned from the domain it is required to remove the
>> iommu group.
> 
> This read wrong to me. We should not need to re-create the IOMMU group (and 
> call arm_smmu_add_device()) every time a device is re-assigned.
Ok.
> 
>> If we don't remove the group, the next time when we assign
>> a device, SME and S2CR will not be setup correctly for the device
>> because of that SMMU fault will be observed.
> 
> I think this is a bug fix for 0435784cc75dcfef3b5f59c29deb1dbb84265ddb. If 
> so, please add a Fixes tag.

Ok Let me add the Fixes tag in next version.
> 
>> Signed-off-by: Rahul Singh 
>> ---
>> xen/drivers/passthrough/arm/smmu.c | 2 ++
>> 1 file changed, 2 insertions(+)
>> diff --git a/xen/drivers/passthrough/arm/smmu.c 
>> b/xen/drivers/passthrough/arm/smmu.c
>> index 5cacb2dd99..9a31c332d0 100644
>> --- a/xen/drivers/passthrough/arm/smmu.c
>> +++ b/xen/drivers/passthrough/arm/smmu.c
>> @@ -1690,6 +1690,8 @@ static void arm_smmu_detach_dev(struct iommu_domain 
>> *domain, struct device *dev)
>>  if (cfg)
>>  arm_smmu_master_free_smes(cfg);
>> +iommu_group_put(dev_iommu_group(dev));
>> +dev_iommu_group(dev) = NULL;
>> }
> 
> The goal of arm_smmu_detach_dev() is to revert the change made in 
> arm_smmu_attach_dev(). But looking at the code, neither the IOMMU group nor 
> the smes are allocated in arm_smmu_attach_dev().
> 
> Are the SMES meant to be re-allocated everytime we assign to a different 
> domain? If yes, the allocation should be done in arm_smmu_attach_dev().

Yes SMES have to be re-allocated every time a device is assigned.

Is that okay if I will move the function arm_smmu_master_alloc_smes() from 
arm_smmu_add_device() to arm_smmu_attach_dev().
In this case we don’t need to remove the IOMMU group and also 
arm_smmu_detach_dev() will also revert the  change made in 
arm_smmu_attach_dev().

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 5cacb2dd99..ff1b73d3d8 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -1680,6 +1680,10 @@ static int arm_smmu_attach_dev(struct iommu_domain 
*domain, struct device *dev)
if (!cfg)
return -ENODEV;
 
+   ret = arm_smmu_master_alloc_smes(dev);
+   if (ret)
+   return ret;
+
return arm_smmu_domain_add_master(smmu_domain, cfg);
 }
 
@@ -2075,7 +2079,7 @@ static int arm_smmu_add_device(struct device *dev)
iommu_group_add_device(group, dev);
iommu_group_put(group);
 
-   return arm_smmu_master_alloc_smes(dev);
+   return 0;
 }

Regards,
Rahul
> 
> If not, then we should not free the SMES here
> 
> IIUC, the SMES have to be re-allocated every time a device is assigned. 
> Therefore, I think we should move the call to arm_smmu_master_alloc_smes() 
> out of the detach callback and in a helper that would be used when removing a 
> device (not yet supported by Xen).
> 
> Cheers,
> 
> -- 
> Julien Grall

[qemu-mainline test] 169849: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl7 xen-install fail pass in 169869-retest
 test-armhf-armhf-xl-arndale   8 xen-bootfail pass in 169869-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale 15 migrate-support-check fail in 169869 never pass
 test-armhf-armhf-xl-arndale 16 saverestore-support-check fail in 169869 never 
pass
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169827
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 169827
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169827
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169827
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 169827
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 169827
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169827
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169827
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuf22833602095b05733bceaddeb20f3edfced3c07
baseline version:
 qemuu

Re: [PATCH] x86: make "dom0_nodes=" work with credit2

[Dario Faggioli]

On Fri, 2022-04-29 at 14:16 +0200, Jan Beulich wrote:
> On 29.04.2022 12:52, Dario Faggioli wrote:
> > > Is that mainly
> > > to have a way to record preferences even when all preferred CPUs
> > > are
> > > offline, to be able to go back to the preferences once CPUs come
> > > back
> > > online?
> > > 
> > That's another example/use case, yes. We want to record the user's
> > preference, whatever the status of the system (and of other aspects
> > of
> > the configuration) is.
> > 
> > But I'm not really sure I've answered... Have I?
> 
> You did. 
>
Ok, great! :-)

> > 
> > If dom0_nodes is in "strict" mode,
> > we want to control hard affinity only. So we set soft to the
> > default,
> > which is "all". During operations, since hard is a subset of "all",
> > soft-affinity will be just ignored.
> 
> Right - until such point that all (original) Dom0 CPUs have gone
> offline. Hence my 2nd question.
> 
> > So I'm using "all" because soft-affinity is just "all", unless
> > someone
> > sets it differently.
> 
> How would "someone set it differently"? Aiui you can't control both
> affinities at the same time.
> 
Yeah, the argument here is basically the one that I put below, and that
you say you understand. I guess I could have put it a bit more upfront,
sorry about that. :-)

> > > 
> > > Hmm, you leave this alone. Wouldn't it be better to further
> > > generalize
> > > things, in case domain affinity was set already? I was referring
> > > to
> > > the mask calculated by sched_select_initial_cpu() also in this
> > > regard.
> > > And when I did suggest to re-use the result, I did mean this
> > > literally.
> > > 
> > Technically, I think we can do that. Although, it's probably
> > cumbersome
> > to do, without adding at least one cpumask on the stack, or
> > reshuffle
> > the locking between sched_select_initial_cpu() and
> > sched_init_vcpu(),
> > in a way that I (personally) don't find particularly pretty.
> 
> Locking? sched_select_initial_cpu() calculates into a per-CPU
> variable,
> which I sincerely hope cannot be corrupted by another CPU.
> 
No, not by another CPU, hopefully.

And this is probably fine, during boot, when there should be no (other)
scheduling activity. However, during normal operation, a vCPU being
scheduled on CPU X, or in general having X in v->processor, could be
using the scratch cpumask of X already. So, if we use it without
locking, we'd risk using the wrong mask.

Therefore, we require the scheduler lock to be held, for playing with
the scratch cpumasks:

/*
 * Scratch space, for avoiding having too many cpumask_t on the stack.
 * Within each scheduler, when using the scratch mask of one pCPU:
 * - the pCPU must belong to the scheduler,
 * - the caller must own the per-pCPU scheduler lock (a.k.a. runqueue
 *   lock).
 */
DECLARE_PER_CPU(cpumask_t, cpumask_scratch);
#define cpumask_scratch(_cpu(cpumask_scratch))
#define cpumask_scratch_cpu(c) (_cpu(cpumask_scratch, c))

And sched_init_vcpu() (and hence sched_select_initial_cpu()) can be
called during normal operation.

In fact, sched_select_initial_cpu() does pcpu_schedule_lock_irqsave()
before starting using it.

> 
> > And again, soft and hard affinity should be set to what the user
> > wants
> > and asks for. And if, for instance, he/she passes
> > dom0_nodes="1,strict", soft-affinity should just be all. If, e.g.,
> > we
> > set both hard and soft affinity to the CPUs of node 1, and if later
> > hard affinity is manually changed to "all", soft affinity will
> > remain
> > to node 1, even if it was never asked for it to be that way, and
> > the
> > user will need to change that explicitly as well. (Of course, it's
> > not
> > particularly clever to boot with dom0_nodes="1,strict" and then
> > change
> > dom0's vCPUs' hard affinity to node 0... but the user is free to do
> > that.)
> 
> I can certainly accept this as justification for using "all" further
> up.
> 
Good then.

Do you think some of this exchange we had should end somewhere
(comments? changelogs?), to make it clearer to both future us and new
contributors why things are done this way?

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


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 09/30] coresight: cpu-debug: Replace mutex with mutex_trylock on panic notifier

[Guilherme G. Piccoli]

On 28/04/2022 05:11, Suzuki K Poulose wrote:
> Hi Guilherme,
> [...] 
> How would you like to proceed with queuing this ? I am happy
> either way. In case you plan to push this as part of this
> series (I don't see any potential conflicts) :
> 
> Reviewed-by: Suzuki K Poulose 

Thanks for your review Suzuki, much appreciated!

About your question, I'm not sure yet - in case the core changes would
take a while (like if community find them polemic, require many changes,
etc) I might split this series in 2 parts, the fixes part vs the
improvements per se. Either way, a V2 is going to happen for sure, and
in that moment, I'll let you know what I think it's best.

But either way, any choice you prefer is fine by me as well (like if you
want to merge it now or postpone to get merged in the future), this is
not an urgent fix I think =)
Cheers,


Guilherme

Re: [PATCH 17/30] tracing: Improve panic/die notifiers

[Steven Rostedt]

On Fri, 29 Apr 2022 10:46:35 -0300
"Guilherme G. Piccoli"  wrote:

> Thanks Sergei and Steven, good idea! I thought about the switch change
> you propose, but I confess I got a bit confused by the "fallthrough"
> keyword - do I need to use it?

No. The fallthrough keyword is only needed when there's code between case
labels. As it is very common to list multiple cases for the same code path.
That is:

case DIE_OOPS:
case PANIC_NOTIFIER:
do_dump = 1;
break;

Does not need a fall through label, as there's no code between the DIE_OOPS
and the PANIC_NOTIFIER. But if you had:

case DIE_OOPS:
x = true;
case PANIC_NOTIFIER:
do_dump = 1;
break;

Then you do.

-- Steve

Re: [PATCH v10 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC

[Christian Lindig]

On 13 Apr 2022, at 12:21, Jane Malalane 
mailto:jane.malal...@citrix.com>> wrote:

Introduce a new per-domain creation x86 specific flag to
select whether hardware assisted virtualization should be used for
x{2}APIC.

tools/ocaml/libs/xc/xenctrl.ml|  2 ++
tools/ocaml/libs/xc/xenctrl.mli   |  2 ++
tools/ocaml/libs/xc/xenctrl_stubs.c   |  2 +-

Acked-by: Christian Lindig 
mailto:christian.lin...@citrix.com>>

The changes here are minimal - I had ack’ed an earlier iteration.

— Christian

Re: [PATCH 17/30] tracing: Improve panic/die notifiers

[Guilherme G. Piccoli]

On 29/04/2022 10:23, Steven Rostedt wrote:
> On Fri, 29 Apr 2022 12:22:44 +0300
> Sergei Shtylyov  wrote:
> 
>>> +   switch (ev) {
>>> +   case DIE_OOPS:
>>> +   do_dump = 1;
>>> +   break;
>>> +   case PANIC_NOTIFIER:
>>> +   do_dump = 1;
>>> +   break;  
>>
>>Why not:
>>
>>  case DIE_OOPS:
>>  case PANIC_NOTIFIER:
>>  do_dump = 1;
>>  break;
> 
> Agreed.
> 
> Other than that.
> 
> Acked-by: Steven Rostedt (Google) 
> 
> -- Steve

Thanks Sergei and Steven, good idea! I thought about the switch change
you propose, but I confess I got a bit confused by the "fallthrough"
keyword - do I need to use it?

About the s/int/bool, for sure! Not sure why I didn't use bool at
first...heheh

Cheers,


Guilherme

Re: [PATCH] x86/mm: slightly relax TLB-flush-local check again

[Jan Beulich]

On 29.04.2022 15:32, Andrew Cooper wrote:
> On 29/04/2022 14:20, Jan Beulich wrote:
>> system_state changes to SYS_STATE_smp_boot before alternative_branches()
>> is invoked, yet that function, with CET-SS enabled, needs to invoke
>> modify_xen_mappings(). Convert to check for the number of online CPUs,
>> just like was done also in 88a037e2cfe1 / fa6dc0879ffd ("page_alloc:
>> assert IRQs are enabled in heap alloc/free", both instance of which
>> needed reverting for other reasons).
>>
>> Fixes: 78e072bc3750 ("x86/mm: avoid inadvertently degrading a TLB flush to 
>> local only")
>> Reported-by: Andrew Cooper 
>> Signed-off-by: Jan Beulich 
>> ---
>> Only build-tested, as I don't have suitable hardware at hand.
> 
> I'll give it a test in just a moment, and while semantically I think
> it's probably right, I don't think we want to express the logic like this.
> 
> num_online_cpus() is cpumask_weight(_online_map) behind the scenes
> which is obnoxiously expensive for what we want.
> 
> For cases where we care just about UP vs SMP-ness, can't we just have an
> bool which is re-evaluated each time we take a CPU online/offline?  That
> should be far lower overhead.

Perhaps, but then I'd immediately ask: Why boolean? We could then as well
have a variable holding the count, such that num_online_cpus() wouldn't
need to invoke cpumask_weight() anymore at all.

In any event I view this as an orthogonal change. It's not entirely without
risk, as all updates to cpu_online_map would now also need to update the
variable. There shouldn't be too many right now; my main concern would be
with future additions.

Jan

Re: [PATCH] x86/mm: slightly relax TLB-flush-local check again

[Andrew Cooper]

On 29/04/2022 14:20, Jan Beulich wrote:
> system_state changes to SYS_STATE_smp_boot before alternative_branches()
> is invoked, yet that function, with CET-SS enabled, needs to invoke
> modify_xen_mappings(). Convert to check for the number of online CPUs,
> just like was done also in 88a037e2cfe1 / fa6dc0879ffd ("page_alloc:
> assert IRQs are enabled in heap alloc/free", both instance of which
> needed reverting for other reasons).
>
> Fixes: 78e072bc3750 ("x86/mm: avoid inadvertently degrading a TLB flush to 
> local only")
> Reported-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> ---
> Only build-tested, as I don't have suitable hardware at hand.

I'll give it a test in just a moment, and while semantically I think
it's probably right, I don't think we want to express the logic like this.

num_online_cpus() is cpumask_weight(_online_map) behind the scenes
which is obnoxiously expensive for what we want.

For cases where we care just about UP vs SMP-ness, can't we just have an
bool which is re-evaluated each time we take a CPU online/offline?  That
should be far lower overhead.

~Andrew

Re: [PATCH v10 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC

[Anthony PERARD]

On Wed, Apr 13, 2022 at 12:21:11PM +0100, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
> 
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware assisted virtualization, as well as a global
> configuration option.
> 
> Having all APIC interaction exit to Xen for emulation is slow and can
> induce much overhead. Hardware can speed up x{2}APIC by decoding the
> APIC access and providing a VM exit with a more specific exit reason
> than a regular EPT fault or by altogether avoiding a VM exit.
> 
> On the other hand, being able to disable x{2}APIC hardware assisted
> virtualization can be useful for testing and debugging purposes.
> 
> Note:
> 
> - vmx_install_vlapic_mapping doesn't require modifications regardless
> of whether the guest has "Virtualize APIC accesses" enabled or not,
> i.e., setting the APIC_ACCESS_ADDR VMCS field is fine so long as
> virtualize_apic_accesses is supported by the CPU.
> 
> - Both per-domain and global assisted_x{2}apic options are not part of
> the migration stream, unless explicitly set in the respective
> configuration files. Default settings of assisted_x{2}apic done
> internally by the toolstack, based on host capabilities at create
> time, are not migrated.
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Jane Malalane 
> Reviewed-by: "Roger Pau Monné" 

Reviewed-by: Anthony PERARD  # tools

-- 
Anthony PERARD

Re: [PATCH v10 1/2] xen+tools: Report Interrupt Controller Virtualization capabilities on x86

[Anthony PERARD]

On Wed, Apr 13, 2022 at 12:21:10PM +0100, Jane Malalane wrote:
> Add XEN_SYSCTL_PHYSCAP_X86_ASSISTED_XAPIC and
> XEN_SYSCTL_PHYSCAP_X86_ASSISTED_X2APIC to report accelerated xAPIC and
> x2APIC, on x86 hardware. This is so that xAPIC and x2APIC virtualization
> can subsequently be enabled on a per-domain basis.
> No such features are currently implemented on AMD hardware.
> 
> HW assisted xAPIC virtualization will be reported if HW, at the
> minimum, supports virtualize_apic_accesses as this feature alone means
> that an access to the APIC page will cause an APIC-access VM exit. An
> APIC-access VM exit provides a VMM with information about the access
> causing the VM exit, unlike a regular EPT fault, thus simplifying some
> internal handling.
> 
> HW assisted x2APIC virtualization will be reported if HW supports
> virtualize_x2apic_mode and, at least, either apic_reg_virt or
> virtual_intr_delivery. This also means that
> sysctl follows the conditionals in vmx_vlapic_msr_changed().
> 
> For that purpose, also add an arch-specific "capabilities" parameter
> to struct xen_sysctl_physinfo.
> 
> Note that this interface is intended to be compatible with AMD so that
> AVIC support can be introduced in a future patch. Unlike Intel that
> has multiple controls for APIC Virtualization, AMD has one global
> 'AVIC Enable' control bit, so fine-graining of APIC virtualization
> control cannot be done on a common interface.
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Jane Malalane 
> Reviewed-by: "Roger Pau Monné" 

No changes in the tools since v9, so my tag still stand:
Reviewed-by: Anthony PERARD  # tools

-- 
Anthony PERARD

Re: [PATCH 17/30] tracing: Improve panic/die notifiers

[Steven Rostedt]

On Fri, 29 Apr 2022 12:22:44 +0300
Sergei Shtylyov  wrote:

> > +   switch (ev) {
> > +   case DIE_OOPS:
> > +   do_dump = 1;
> > +   break;
> > +   case PANIC_NOTIFIER:
> > +   do_dump = 1;
> > +   break;  
> 
>Why not:
> 
>   case DIE_OOPS:
>   case PANIC_NOTIFIER:
>   do_dump = 1;
>   break;

Agreed.

Other than that.

Acked-by: Steven Rostedt (Google) 

-- Steve

[PATCH] x86/mm: slightly relax TLB-flush-local check again

[Jan Beulich]

system_state changes to SYS_STATE_smp_boot before alternative_branches()
is invoked, yet that function, with CET-SS enabled, needs to invoke
modify_xen_mappings(). Convert to check for the number of online CPUs,
just like was done also in 88a037e2cfe1 / fa6dc0879ffd ("page_alloc:
assert IRQs are enabled in heap alloc/free", both instance of which
needed reverting for other reasons).

Fixes: 78e072bc3750 ("x86/mm: avoid inadvertently degrading a TLB flush to 
local only")
Reported-by: Andrew Cooper 
Signed-off-by: Jan Beulich 
---
Only build-tested, as I don't have suitable hardware at hand.

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5074,7 +5074,7 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned l
  * map_pages_to_xen() can be called early in boot before any other
  * CPUs are online. Use flush_area_local() in this case.
  */
-#define flush_area(v,f) (system_state < SYS_STATE_smp_boot ?\
+#define flush_area(v,f) (num_online_cpus() <= 1 ?   \
  flush_area_local((const void *)v, f) : \
  flush_area_all((const void *)v, f))
 

[PATCH] PCI: don't allow "pci-phantom=" to mark real devices as phantom functions

[Jan Beulich]

IOMMU code mapping / unmapping devices and interrupts will misbehave if
a wrong command line option declared a function "phantom" when there's a
real device at that position. Warn about this and adjust the specified
stride (in the worst case ignoring the option altogether).

Requested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -451,7 +451,24 @@ static struct pci_dev *alloc_pdev(struct
  phantom_devs[i].slot == PCI_SLOT(devfn) &&
  phantom_devs[i].stride > PCI_FUNC(devfn) )
 {
-pdev->phantom_stride = phantom_devs[i].stride;
+pci_sbdf_t sbdf = pdev->sbdf;
+unsigned int stride = phantom_devs[i].stride;
+
+while ( (sbdf.fn += stride) > PCI_FUNC(devfn) )
+{
+if ( pci_conf_read16(sbdf, PCI_VENDOR_ID) == 
0x &&
+ pci_conf_read16(sbdf, PCI_DEVICE_ID) == 
0x )
+continue;
+stride <<= 1;
+printk(XENLOG_WARNING
+   "%pp looks to be a real device; bumping 
%04x:%02x:%02x stride to %u\n",
+   , phantom_devs[i].seg,
+   phantom_devs[i].bus, phantom_devs[i].slot,
+   stride);
+sbdf = pdev->sbdf;
+}
+if ( PCI_FUNC(stride) )
+   pdev->phantom_stride = stride;
 break;
 }
 }

[ovmf test] 169866: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  694 attempts
Testing same since   169816  2022-04-28 14:41:38 Z0 days   15 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: [PATCH 2/2] tools/xl: Allow specifying JSON for domain configuration file format

[Anthony PERARD]

On Tue, Apr 19, 2022 at 06:23:41PM -0700, Elliott Mitchell wrote:
> JSON is currently used when saving domains to mass storage.  Being able
> to use JSON as the normal input to `xl create` has potential to be
> valuable.  Add the functionality.

"potential", right, but it isn't hasn't been really tested. When
implemented, I think the intend of the json format was for libxl to
communicate with itself while migrating a guest (or save/restore). It
would be nice to know if it actually can work.

> Signed-off-by: Elliott Mitchell 
> ---
> diff --git a/tools/xl/xl.h b/tools/xl/xl.h
> index c5c4bedbdd..a0c03f96df 100644
> --- a/tools/xl/xl.h
> +++ b/tools/xl/xl.h
> @@ -49,6 +49,11 @@ struct domain_create {
>  int migrate_fd; /* -1 means none */
>  int send_back_fd; /* -1 means none */
>  char **migration_domname_r; /* from malloc */
> +enum {
> +FORMAT_DEFAULT,
> +FORMAT_JSON,
> +FORMAT_LEGACY,
> +} format;

I think the name "format" here is too generic, we are in the struct
"domain_create" and this new format field isn't intended to specify the
format of the domain. I think "config_file_format" would be better, as
it is only used for the format of the config_file.

Also I don't think having "_DEFAULT" would be useful, we need to know
what the format is intended to be before starting to parse the file, and
I don't think changing the default is going to work. So for the enum, we
could have "_LEGACY = 0".

The prefix "FORMAT_" feels a bit generic, maybe "CONFIG_FORMAT_" would
be better, or something else.

>  };
>  
>  int create_domain(struct domain_create *dom_info);
> diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
> index f546beaceb..04d579a596 100644
> --- a/tools/xl/xl_cmdtable.c
> +++ b/tools/xl/xl_cmdtable.c
> @@ -31,6 +31,8 @@ const struct cmd_spec cmd_table[] = {
>"-h  Print this help.\n"
>"-p  Leave the domain paused after it is 
> created.\n"
>"-f FILE, --defconfig=FILE\n Use the given 
> configuration file.\n"
> +  "-j, --json  Interpret configuration file as JSON format\n"
> +  "-J  Use traditional configuration file format 
> (current default)\n"

I don't think this new "-J" option would be useful, just the "-j" should be
enough.

>"-n, --dryrunDry run - prints the resulting 
> configuration\n"
>" (deprecated in favour of global -N 
> option).\n"
>"-q, --quiet Quiet.\n"
> diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
> index 2ec4140258..41bd919d1d 100644
> --- a/tools/xl/xl_vmcontrol.c
> +++ b/tools/xl/xl_vmcontrol.c
> @@ -789,7 +789,7 @@ int create_domain(struct domain_create *dom_info)
>  extra_config);
>  }
>  config_source=config_file;
> -config_in_json = false;
> +config_in_json = dom_info.format == FORMAT_JSON ? true : false;

This doesn't build, "dom_info" is a pointer.

Also, "? true : false;" is weird in C.


>  } else {
>  if (!config_data) {
>  fprintf(stderr, "Config file not specified and"
> @@ -1173,6 +1173,7 @@ int main_create(int argc, char **argv)
>  {"defconfig", 1, 0, 'f'},
>  {"dryrun", 0, 0, 'n'},
>  {"ignore-global-affinity-masks", 0, 0, 'i'},
> +{"json", 0, 0, 'j'},
>  {"quiet", 0, 0, 'q'},
>  {"vncviewer", 0, 0, 'V'},
>  {"vncviewer-autopass", 0, 0, 'A'},
> @@ -1181,18 +1182,23 @@ int main_create(int argc, char **argv)
>  
>  dom_info.extra_config = NULL;
>  
> +dom_info.format = FORMAT_DEFAULT;
> +
>  if (argv[1] && argv[1][0] != '-' && !strchr(argv[1], '=')) {
>  filename = argv[1];
>  argc--; argv++;
>  }
>  
> -SWITCH_FOREACH_OPT(opt, "Ffnq:AVcdeip", opts, "create", 0) {
> +SWITCH_FOREACH_OPT(opt, "FJfjnq:AVcdeip", opts, "create", 0) {
>  case 'A':
>  vnc = vncautopass = 1;
>  break;
>  case 'F':
>  daemonize = 0;
>  break;
> +case 'J':
> +dom_info.format = FORMAT_LEGACY;
> +break;
>  case 'V':
>  vnc = 1;
>  break;
> @@ -1212,6 +1218,9 @@ int main_create(int argc, char **argv)
>  case 'i':
>  ignore_masks = 1;
>  break;
> +case 'j':
> +dom_info.format = FORMAT_JSON;

This setting is ignored, as "dom_info" is reset later.

> +break;
>  case 'n':
>  dryrun_only = 1;
>  break;

Thanks,

-- 
Anthony PERARD

Re: [PATCH] x86/cet: Support cet= on the command line

[Jan Beulich]

On 29.04.2022 12:13, Andrew Cooper wrote:
> On 28/04/2022 11:13, Jan Beulich wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -117,7 +117,20 @@ static int __init cf_check parse_cet(const char *s)
>>>  if ( !ss )
>>>  ss = strchr(s, '\0');
>>>  
>>> -if ( (val = parse_boolean("shstk", s, ss)) >= 0 )
>>> +if ( (val = parse_bool(s, ss)) >= 0 )
>>> +{
>>> +#ifdef CONFIG_XEN_SHSTK
>>> +opt_xen_shstk = val;
>>> +#else
>>> +no_config_param("XEN_SHSTK", "cet", s, ss);
>>> +#endif
>>> +#ifdef CONFIG_XEN_IBT
>>> +opt_xen_ibt = val;
>>> +#else
>>> +no_config_param("XEN_IBT", "cet", s, ss);
>>> +#endif
>> There shouldn't be two invocations of no_config_param() here; imo if
>> either CONFIG_* is defined, use of the option shouldn't produce any
>> warning at all.
> 
> It's this, or:
> 
>     if ( (val = parse_bool(s, ss)) >= 0 )
>     {
> #if !defined(CONFIG_XEN_SHSTK) && !defined(CONFIG_XEN_IBT)
>     no_config_param("XEN_{SHSTK,IBT}", "cet", s, ss);
> #endif
> #ifdef CONFIG_XEN_SHSTK
>     opt_xen_shstk = val;
> #endif
> #ifdef CONFIG_XEN_IBT
>     opt_xen_ibt = val;
> #endif
>     }
> 
> I'm not terribly fussed.

I'd prefer the alternative variant; hopefully Roger doesn't strongly
prefer the other one. And then
Reviewed-by: Jan Beulich 

Jan

Re: [PATCH] x86: make "dom0_nodes=" work with credit2

[Jan Beulich]

On 29.04.2022 12:52, Dario Faggioli wrote:
> On Wed, 2022-04-13 at 12:00 +0200, Jan Beulich wrote:
>> I also have a more general question here: sched.h says "Bitmask of
>> CPUs
>> on which this VCPU may run" for hard affinity and "Bitmask of CPUs on
>> which this VCPU prefers to run" for soft affinity. Additionally
>> there's
>> soft_aff_effective. Does it make sense in the first place for one to
>> be
>> a proper subset of the of the other in _both_ directions? 
>>
> I'm not sure I'm 100% getting what you're asking. In particular, I'm
> not sure what you mean with "for one to be a propper subset of the
> other in both directions"?
> 
> Anyway, soft and hard affinity are under the complete control of the
> user (I guess we can say that they're policy), so we tend to accept
> pretty much everything that comes from the user.
> 
> That is, the user can set an hard affinity to 1-6 and a soft affinity
> of (a) 2-3, (b) 0-2, (c) 7-12, etc.
> 
> Case (a), i.e., soft is a strict subset of hard, is the one that makes
> the most sense, of course. With this configuration, the vCPU(s) can run
> on CPUs 1, 2, 3, 4, 5 and 6, but the scheduler will prefer to run it
> (them) on 2 and/or 3.
> 
> Case (b), i.e., no strict subset, but there's some overlap, also means
> that soft-affinity is going to be considered and have an effect. In
> fact, vCPU(s) will prefer to run on CPUs 1 and/or 2, but of course it
> (they) will never run on CPU 0. Of course, the user can, at a later
> point in time, change the hard affinity so that it includes CPU 0, and
> we'll be back to the strict-subset case. So that's way we want to keep
> 0 in the mast, even if it causes soft to not be a strict subset of
> hard.
> 
> In case (c), soft affinity is totally useless. However, again, the user
> can later change hard to include some or all CPUs 7-12, so we keep it.
> We do, however, print a warning. And we also use the soft_aff_effective
> flag to avoid going through the soft-affinity balancing step in the
> scheduler code. This is, in fact, why we also check whether hard is not
> a strict subset of soft. As, if it is, there's no need to do anything
> about soft, as honoring hard will automatically take care of that as
> well.
> 
>> Is that mainly
>> to have a way to record preferences even when all preferred CPUs are
>> offline, to be able to go back to the preferences once CPUs come back
>> online?
>>
> That's another example/use case, yes. We want to record the user's
> preference, whatever the status of the system (and of other aspects of
> the configuration) is.
> 
> But I'm not really sure I've answered... Have I?

You did. My question really only was whether there are useful scenarios
for proper-subset cases in both possible directions.

>> Then a follow-on question is: Why do you use cpumask_all for soft
>> affinity in the first of the two calls above? Is this to cover for
>> the
>> case where all CPUs in dom0_cpus would go offline?
>>
> Mmm... what else should I be using?

I was thinking of dom0_cpus.

> If dom0_nodes is in "strict" mode,
> we want to control hard affinity only. So we set soft to the default,
> which is "all". During operations, since hard is a subset of "all",
> soft-affinity will be just ignored.

Right - until such point that all (original) Dom0 CPUs have gone
offline. Hence my 2nd question.

> So I'm using "all" because soft-affinity is just "all", unless someone
> sets it differently.

How would "someone set it differently"? Aiui you can't control both
affinities at the same time.

> But I am again not sure that I fully understood and properly addressed
> your question. :-(
> 
> 
>>> +    }
>>>  else
>>>  sched_set_affinity(unit, _all, _all);
>>
>> Hmm, you leave this alone. Wouldn't it be better to further
>> generalize
>> things, in case domain affinity was set already? I was referring to
>> the mask calculated by sched_select_initial_cpu() also in this
>> regard.
>> And when I did suggest to re-use the result, I did mean this
>> literally.
>>
> Technically, I think we can do that. Although, it's probably cumbersome
> to do, without adding at least one cpumask on the stack, or reshuffle
> the locking between sched_select_initial_cpu() and sched_init_vcpu(),
> in a way that I (personally) don't find particularly pretty.

Locking? sched_select_initial_cpu() calculates into a per-CPU variable,
which I sincerely hope cannot be corrupted by another CPU.

> Also, I don't think we gain much from doing that, as we probably still
> need to have some special casing of dom0, for handling dom0_vcpus_pin.

dom0_vcpus_pin is likely always going to require special casing, until
such point where we drop support for it.

> And again, soft and hard affinity should be set to what the user wants
> and asks for. And if, for instance, he/she passes
> dom0_nodes="1,strict", soft-affinity should just be all. If, e.g., we
> set both hard and soft affinity to the CPUs of node 1, and if later
> hard affinity is manually changed to 

[ovmf test] 169865: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf d372ab585a2cdc5348af5f701c56c631235fe698
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   60 days
Failing since168258  2022-03-01 01:55:31 Z   59 days  693 attempts
Testing same since   169816  2022-04-28 14:41:38 Z0 days   14 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chen Lin Z 
  Chen, Lin Z 
  Dandan Bi 
  Dun Tan 
  Feng, Bob C 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  Li, Zhihao 
  Liming Gao 
  Liu 
  Liu Yun 
  Liu Yun Y 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael D Kinney 
  Michael Kubacki 
  Michael Kubacki 
  Min Xu 
  Oliver Steffen 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yuanhao Xie 
  Zhihao Li 

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



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

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

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

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


Not pushing.

(No revision log; it would be 5844 lines long.)

Re: Virtio on Xen with Rust

[Oleksandr]

On 29.04.22 06:59, Viresh Kumar wrote:


Hello Viresh



On 29-04-22, 09:18, Viresh Kumar wrote:

Now, it was just yesterday that I started looking into MMIO modern stuff as the
GPIO device needs it and you sent me working code to look how to do it as well.
You saved at least 1-2 days of my time :)

One question though, do we need to support Legacy mode at all in the work we are
doing ?



I am not 100% sure I can answer precisely here. virtio-disk backend 
worked perfectly fine in legacy virtio-mmio transport mode
with the latest vanilla Linux. For the "restricted memory access using 
Xen grant mappings" feature to work I had to switch it to use modern 
virtio-mmio transport.
CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS requires the virtio 
devices to support VIRTIO_F_VERSION_1. In addition, we do need 64-bit 
addresses in the virtqueue.


BTW, the virtio-iommu also requires VIRTIO_F_VERSION_1.






--
Regards,

Oleksandr Tyshchenko

Re: [xen-unstable test] 169819: regressions - FAIL

[Roger Pau Monné]

On Fri, Apr 29, 2022 at 12:37:13PM +0200, Jan Beulich wrote:
> On 29.04.2022 12:30, Roger Pau Monné wrote:
> > On Fri, Apr 29, 2022 at 07:46:47AM +, osstest service owner wrote:
> >> flight 169819 xen-unstable real [real]
> >> flight 169843 xen-unstable real-retest [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/169819/
> >> http://logs.test-lab.xenproject.org/osstest/logs/169843/
> >>
> >> Regressions :-(
> >>
> >> Tests which did not succeed and are blocking,
> >> including tests which could not be run:
> >>  test-arm64-arm64-examine  8 reboot   fail REGR. vs. 
> >> 169775
> >>  test-arm64-arm64-libvirt-xsm  8 xen-boot fail REGR. vs. 
> >> 169775
> >>  test-arm64-arm64-libvirt-raw  8 xen-boot fail REGR. vs. 
> >> 169775
> >>  test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 
> >> 169775
> >>  test-arm64-arm64-xl-thunderx  8 xen-boot fail REGR. vs. 
> >> 169775
> >>  test-arm64-arm64-xl   8 xen-boot fail REGR. vs. 
> >> 169775
> >>
> >> Tests which are failing intermittently (not blocking):
> >>  test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail 
> >> pass in 169843-retest
> > 
> > Looked into this one, and it's slightly concerning, guest seems to be
> > stuck at installation:
> > 
> > Select and install software  [  481.093857] watchdog: BUG: soft lockup - 
> > CPU#1 stuck for 23s! [ksoftirqd/1:17]
> > [  509.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [  545.093820] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  573.093809] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  609.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [  637.093836] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [  673.093957] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  701.093854] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  733.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  761.093817] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  797.093898] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [  825.093863] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  861.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  889.093945] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [  925.093974] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  953.093925] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [  985.093832] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1013.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1049.094031] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1077.093860] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1113.093938] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1141.093803] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1177.094051] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1205.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1237.093955] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1265.094004] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1301.093835] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1329.094039] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1365.093883] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1393.094167] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1429.093857] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1457.093900] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1489.094026] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1517.093997] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1553.093996] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1581.094064] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1617.094076] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1645.093882] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> > [ksoftirqd/1:17]
> > [ 1681.093896] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> > [ksoftirqd/1:17]
> > [ 1709.094022] watchdog: BUG: soft lockup - CPU#1 stuck for 

Re: [PATCH v4 3/3] amd/msr: implement VIRT_SPEC_CTRL for HVM guests using legacy SSBD

[Jan Beulich]

On 27.04.2022 12:47, Roger Pau Monne wrote:> Changes since v3:>  - Align ssbd 
per-core struct to a cache line.>  - Open code a simple spinlock to avoid 
playing tricks with the lock>detector.>  - s/ssbd_core/ssbd_ls_cfg/.>  - 
Fix log message wording.>  - Fix define name and remove comment.>  - Also 
handle Hygon processors (Fam18h).>  - Add changelog entry.
What is this last line about?

> +bool __init amd_setup_legacy_ssbd(void)
> +{
> + unsigned int i;
> +
> + if ((boot_cpu_data.x86 != 0x17 && boot_cpu_data.x86 != 0x18) ||
> + boot_cpu_data.x86_num_siblings <= 1)
> + return true;
> +
> + /*
> +  * One could be forgiven for thinking that c->x86_max_cores is the
> +  * correct value to use here.
> +  *
> +  * However, that value is derived from the current configuration, and
> +  * c->cpu_core_id is sparse on all but the top end CPUs.  Derive
> +  * max_cpus from ApicIdCoreIdSize which will cover any sparseness.
> +  */
> + if (boot_cpu_data.extended_cpuid_level >= 0x8008) {
> + ssbd_max_cores = 1u << MASK_EXTR(cpuid_ecx(0x8008), 0xf000);
> + ssbd_max_cores /= boot_cpu_data.x86_num_siblings;
> + }
> + if (!ssbd_max_cores)
> + return false;
> +
> + ssbd_ls_cfg = xzalloc_array(struct ssbd_ls_cfg,
> + ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS);
> + if (!ssbd_ls_cfg)
> + return false;
> +
> + for (i = 0; i < ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS; i++)
> + /* Record initial state, also applies to any hotplug CPU. */
> + if (opt_ssbd)
> + ssbd_ls_cfg[i].count = boot_cpu_data.x86_num_siblings;

Perhaps flip if() and for()?

> +void amd_set_legacy_ssbd(bool enable)
> +{
> + const struct cpuinfo_x86 *c = _cpu_data;
> + struct ssbd_ls_cfg *status;
> +
> + if (c->x86 != 0x17 || c->x86_num_siblings <= 1) {
> + BUG_ON(!set_legacy_ssbd(c, enable));
> + return;
> + }
> +
> + BUG_ON(c->phys_proc_id >= AMD_FAM17H_MAX_SOCKETS);
> + BUG_ON(c->cpu_core_id >= ssbd_max_cores);
> + status = _ls_cfg[c->phys_proc_id * ssbd_max_cores +
> +   c->cpu_core_id];
> +
> + /*
> +  * Open code a very simple spinlock: this function is used with GIF==0
> +  * and different IF values, so would trigger the checklock detector.
> +  * Instead of trying to workaround the detector, use a very simple lock
> +  * implementation: it's better to reduce the amount of code executed
> +  * with GIF==0.
> +  */
> + while ( test_and_set_bool(status->locked) )
> + cpu_relax();
> + status->count += enable ? 1 : -1;
> + ASSERT(status->count <= c->x86_num_siblings);
> + if (enable ? status->count == 1 : !status->count)
> + BUG_ON(!set_legacy_ssbd(c, enable));

What are the effects of ASSERT() or BUG_ON() triggering in a GIF=0
region?

> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -544,6 +544,16 @@ static void __init calculate_hvm_max_policy(void)
>  if ( !boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
>  /* Clear VIRT_SSBD if VIRT_SPEC_CTRL is not exposed to guests. */
>  __clear_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
> +else
> +/*
> + * Expose VIRT_SSBD if VIRT_SPEC_CTRL is supported, as that implies 
> the
> + * underlying hardware is capable of setting SSBD using
> + * non-architectural way or VIRT_SSBD is available.
> + *
> + * Note that if the hardware supports VIRT_SSBD natively this setting
> + * will just override an already set bit.
> + */
> +__set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);

With the 's' annotation gone from the public header, is this last
sentence of the comment actually true? Aiui code near the top of
the function would have zapped the bit from hvm_featureset[].

> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -3126,6 +3126,8 @@ void vmexit_virt_spec_ctrl(void)
>  
>  if ( cpu_has_virt_ssbd )
>  wrmsr(MSR_VIRT_SPEC_CTRL, val, 0);
> +else
> + amd_set_legacy_ssbd(opt_ssbd);

Nit: Indentation is off by one here. Of course this alone could
easily be adjusted while committing.

> @@ -3138,6 +3140,9 @@ void vmentry_virt_spec_ctrl(void)
>  
>  if ( cpu_has_virt_ssbd )
>  wrmsr(MSR_VIRT_SPEC_CTRL, current->arch.msrs->virt_spec_ctrl.raw, 0);
> +else
> +amd_set_legacy_ssbd(current->arch.msrs->virt_spec_ctrl.raw &
> +SPEC_CTRL_SSBD);

Would seem cheaper to use !val here (and then val for symmetry in
the other function).

Jan

Re: x86/PV: (lack of) MTRR exposure

[Roger Pau Monné]

On Fri, Apr 29, 2022 at 12:00:21PM +0200, Jan Beulich wrote:
> On 29.04.2022 10:00, Roger Pau Monné wrote:
> > On Thu, Apr 28, 2022 at 05:53:17PM +0200, Jan Beulich wrote:
> >> Hello,
> >>
> >> in the course of analyzing the i915 driver causing boot to fail in
> >> Linux 5.18 I found that Linux, for all the years, has been running
> >> in PV mode as if PAT was (mostly) disabled. This is a result of
> >> them tying PAT initialization to MTRR initialization, while we
> >> offer PAT but not MTRR in CPUID output. This was different before
> >> our moving to CPU featuresets, and as such one could view this
> >> behavior as a regression from that change.
> >>
> >> The first question here is whether not exposing MTRR as a feature
> >> was really intended, in particular also for PV Dom0. The XenoLinux
> >> kernel and its forward ports did make use of XENPF_*_memtype to
> >> deal with MTRRs. That's functionality which (maybe for a good
> >> reason) never made it into the pvops kernel. Note that PVH Dom0
> >> does have access to the original settings, as the host values are
> >> used as initial state there.
> >>
> >> The next question would be how we could go about improving the
> >> situation. For the particular issue in 5.18 I've found a relatively
> >> simple solution [1] (which also looks to help graphics performance
> >> on other systems, according to my initial observations with using
> >> the change), albeit its simplicity likely means it either is wrong
> >> in some way, or might not be liked for looking hacky and/or abusive.
> > 
> > I wonder whether the patch needs to be limited to the CPUID Hypervisor
> > bit being present.  If the PAT MSR is readable and returns a value !=
> > 0 then PAT should be available?
> 
> I simply didn't want to be too "aggressive". There may be reasons why
> they want things to be the way they are on native. All I really care
> about is that things are broken on PV Xen; as such I wouldn't even
> mind tightening the check to xen_pv_domain(). But first I need
> feedback from the maintainers there anyway.

Right, I did also consider suggesting to limit this to PV at first,
but I was unsure why native wouldn't also want such behavior.  Maybe
there's no hardware that has PAT but not MTRR, and hence this was
never considered.

> > I guess we should instead check that the current PAT value matches
> > what Linux expects, before declaring PAT enabled?
> 
> I don't think such a check is needed, the code ...
> 
> > Note there's already a comment in init_cache_modes that refers to Xen
> > in the check for PAT CPUID bit.
> 
> ... in __init_cache_modes() already does it the other way around:
> Adapt behavior to what is found in PAT.
> 
> >  We might want to expand that comment
> > (or add one to the new check you are adding).
> 
> I don't see what further information you would want to put there.

It would depend on how the check ends up looking I think.  If the
enabling is limited to also having the Hypervisor CPUID bit set then
the comment should likely mention why setting it on native is not
safe.

Anyway, let's see what maintainers think.

The other option would be to set some kind of hooks for Xen PV to be
able to report PAT as enabled (maybe a Xen PV implementation of
mtrr_ops?), but that seems like over-engineering it.  My main concern
with setting pat_bp_enabled to true is whether in the future such
setting could be used to gate PAT MSR writes.  It's already like this
for APs (in pat_init() -> pat_ap_init()), but we avoid that path
because we don't report MTRR support AFAICT.

Thanks, Roger.

Re: [PATCH] x86: make "dom0_nodes=" work with credit2

[Dario Faggioli]

On Wed, 2022-04-13 at 12:00 +0200, Jan Beulich wrote:
> On 12.04.2022 18:11, Dario Faggioli wrote:
> > --- a/xen/common/sched/core.c
> > +++ b/xen/common/sched/core.c
> > @@ -572,11 +572,41 @@ int sched_init_vcpu(struct vcpu *v)
> >  }
> >  
> >  /*
> > - * Initialize affinity settings. The idler, and potentially
> > - * domain-0 VCPUs, are pinned onto their respective physical
> > CPUs.
> > + * Initialize affinity settings. By doing this before the unit
> > is
> > + * inserted in the scheduler runqueues (by the call to
> > sched_insert_unit(),
> > + * at the end of the function, we are sure that it will be put
> > on an
> > + * appropriate CPU.
> >   */
> > -    if ( is_idle_domain(d) || (is_hardware_domain(d) &&
> > opt_dom0_vcpus_pin) )
> > +    if ( pv_shim && v->vcpu_id == 0 )
> 
> I don't think you can handle the shim case first, as then you'd also
> have
> its CPU0 idle vCPU take this path. The difference _may_ only be
> cosmetic,
> but I think it would be odd for CPU0's idle vCPU to have a soft
> affinity
> of just CPU0, while all others use cpumask_all.
> 
Ok, yes, I didn't think to that. I'll reshuffle the if-s order.

> 
> > +    {
> > +    /*
> > + * The idler, and potentially domain-0 VCPUs, are pinned
> > onto their
> > + * respective physical CPUs.
> > + */
> >  sched_set_affinity(unit, cpumask_of(processor),
> > _all);
> > +    }
> > +    else if ( is_hardware_domain(d) )
> 
> ... here I wonder: Shouldn't this be limited to Dom0 (for the
> purposes here
> != hwdom)? Any special affinity for a late hwdom ought to be
> specified by
> the logic creating that domain imo, not by command line options
> concerning
> Dom0 only.
> 
I think this makes sense. I'll add a patch for changing it.

> I also have a more general question here: sched.h says "Bitmask of
> CPUs
> on which this VCPU may run" for hard affinity and "Bitmask of CPUs on
> which this VCPU prefers to run" for soft affinity. Additionally
> there's
> soft_aff_effective. Does it make sense in the first place for one to
> be
> a proper subset of the of the other in _both_ directions? 
>
I'm not sure I'm 100% getting what you're asking. In particular, I'm
not sure what you mean with "for one to be a propper subset of the
other in both directions"?

Anyway, soft and hard affinity are under the complete control of the
user (I guess we can say that they're policy), so we tend to accept
pretty much everything that comes from the user.

That is, the user can set an hard affinity to 1-6 and a soft affinity
of (a) 2-3, (b) 0-2, (c) 7-12, etc.

Case (a), i.e., soft is a strict subset of hard, is the one that makes
the most sense, of course. With this configuration, the vCPU(s) can run
on CPUs 1, 2, 3, 4, 5 and 6, but the scheduler will prefer to run it
(them) on 2 and/or 3.

Case (b), i.e., no strict subset, but there's some overlap, also means
that soft-affinity is going to be considered and have an effect. In
fact, vCPU(s) will prefer to run on CPUs 1 and/or 2, but of course it
(they) will never run on CPU 0. Of course, the user can, at a later
point in time, change the hard affinity so that it includes CPU 0, and
we'll be back to the strict-subset case. So that's way we want to keep
0 in the mast, even if it causes soft to not be a strict subset of
hard.

In case (c), soft affinity is totally useless. However, again, the user
can later change hard to include some or all CPUs 7-12, so we keep it.
We do, however, print a warning. And we also use the soft_aff_effective
flag to avoid going through the soft-affinity balancing step in the
scheduler code. This is, in fact, why we also check whether hard is not
a strict subset of soft. As, if it is, there's no need to do anything
about soft, as honoring hard will automatically take care of that as
well.

> Is that mainly
> to have a way to record preferences even when all preferred CPUs are
> offline, to be able to go back to the preferences once CPUs come back
> online?
> 
That's another example/use case, yes. We want to record the user's
preference, whatever the status of the system (and of other aspects of
the configuration) is.

But I'm not really sure I've answered... Have I?

> Then a follow-on question is: Why do you use cpumask_all for soft
> affinity in the first of the two calls above? Is this to cover for
> the
> case where all CPUs in dom0_cpus would go offline?
> 
Mmm... what else should I be using? If dom0_nodes is in "strict" mode,
we want to control hard affinity only. So we set soft to the default,
which is "all". During operations, since hard is a subset of "all",
soft-affinity will be just ignored.

So I'm using "all" because soft-affinity is just "all", unless someone
sets it differently.

But I am again not sure that I fully understood and properly addressed
your question. :-(


> > +    }
> >  else
> >  sched_set_affinity(unit, _all, _all);
> 
> Hmm, you leave this alone. Wouldn't it be better to 

Re: Virtio on Xen with Rust

[Oleksandr]

On 29.04.22 06:48, Viresh Kumar wrote:


Hello Viresh


On 28-04-22, 16:52, Oleksandr Tyshchenko wrote:

Great work!

Thanks Oleksandr.


I skimmed through your toolstack patches, awesome, you created a completely
new virtual device "I2C".

I have also created GPIO now :)


Awesome!




What should I do about these patches ? Send them to xen list ? I can at least
send the stuff which doesn't depend on your series ?


Below my understanding, which might be wrong)


I think, the best case scenario - is to try to get these features 
upstreamed. I expect a possible interest to virtulized I2C/GPIO devices 
on Xen,
especially in embedded environment where the passthrough of dedicated 
I2C/GPIO controller to the guest is not possible for some reason 
(clocks, pins, power domains, etc).
But I do understand it most likely takes some time. If upsteaming this 
stuff is not your primary target, then I think, such patch series 
deserves to be sent to the Xen mailing list anyway for someone who is 
interested in the topic to give it a try. For example, you can send RFC 
version saying in cover letter that it depends on non-upsteamed yet 
stuff to start discussion.







FYI, I have updated "Virtio support for toolstack on Arm" [1] since (to
make it more generic), now V7 is available and I have a plan to push V8
soon.

I will surely have a look, thanks.


FYI, currently we are working on one feature to restrict memory access
using Xen grant mappings based on xen-grant DMA-mapping layer for Linux [1].
And there is a working PoC on Arm based on an updated virtio-disk. As for
libraries, there is a new dependency on "xengnttab" library. In comparison
with Xen foreign mappings model (xenforeignmemory),
the Xen grant mappings model is a good fit into the Xen security model,
this is a safe mechanism to share pages between guests.

Right, I was aware of this work but didn't dive into it yet. We will surely need
to do that eventually, lets see when I will be able to get to that. The current
focus is the get the solution a bit more robust (so it can be used with any
device) and upstream it to rust-vmm space on github.


ok, I see. I understand your point, your primary target is 
hypervisor-agnostic Rust based backend(s) to be applicable for any device.







With Xen grant mappings, if I am not mistaken, it is going to be almost the
same: mmap() then ioctl(). But the file will be "/dev/xen/gntdev".

Okay, the problem (for us) still exists then :)


It seems, yes.


  

FYI, new branch "virtio_grant" besides supporting Xen grant mappings also
supports virtio-mmio modern transport.

Somehow the timing of your emails have been spot on.

Last time, when you told me about the "dev" branch, I have already started to
reinvent the wheel and your branch really helped.

Now, it was just yesterday that I started looking into MMIO modern stuff as the
GPIO device needs it and you sent me working code to look how to do it as well.
You saved at least 1-2 days of my time :)


Great, I'm glad to hear it.




Thanks Oleksandr.


--
Regards,

Oleksandr Tyshchenko

Re: [xen-unstable test] 169819: regressions - FAIL

[Jan Beulich]

On 29.04.2022 12:30, Roger Pau Monné wrote:
> On Fri, Apr 29, 2022 at 07:46:47AM +, osstest service owner wrote:
>> flight 169819 xen-unstable real [real]
>> flight 169843 xen-unstable real-retest [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/169819/
>> http://logs.test-lab.xenproject.org/osstest/logs/169843/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-arm64-arm64-examine  8 reboot   fail REGR. vs. 
>> 169775
>>  test-arm64-arm64-libvirt-xsm  8 xen-boot fail REGR. vs. 
>> 169775
>>  test-arm64-arm64-libvirt-raw  8 xen-boot fail REGR. vs. 
>> 169775
>>  test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 
>> 169775
>>  test-arm64-arm64-xl-thunderx  8 xen-boot fail REGR. vs. 
>> 169775
>>  test-arm64-arm64-xl   8 xen-boot fail REGR. vs. 
>> 169775
>>
>> Tests which are failing intermittently (not blocking):
>>  test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail 
>> pass in 169843-retest
> 
> Looked into this one, and it's slightly concerning, guest seems to be
> stuck at installation:
> 
> Select and install software  [  481.093857] watchdog: BUG: soft lockup - 
> CPU#1 stuck for 23s! [ksoftirqd/1:17]
> [  509.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [  545.093820] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  573.093809] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  609.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [  637.093836] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [  673.093957] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  701.093854] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  733.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  761.093817] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  797.093898] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [  825.093863] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  861.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  889.093945] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [  925.093974] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  953.093925] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [  985.093832] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1013.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1049.094031] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1077.093860] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1113.093938] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1141.093803] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1177.094051] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1205.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1237.093955] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1265.094004] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1301.093835] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1329.094039] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1365.093883] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1393.094167] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1429.093857] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1457.093900] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1489.094026] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1517.093997] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1553.093996] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1581.094064] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1617.094076] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1645.093882] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> [ksoftirqd/1:17]
> [ 1681.093896] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1709.094022] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1741.093870] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1769.093854] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
> [ksoftirqd/1:17]
> [ 1805.094017] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
> 

Re: [PATCH v4 2/3] amd/msr: allow passthrough of VIRT_SPEC_CTRL for HVM guests

[Jan Beulich]

On 27.04.2022 12:47, Roger Pau Monne wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -541,6 +541,10 @@ static void __init calculate_hvm_max_policy(void)
>   raw_cpuid_policy.basic.sep )
>  __set_bit(X86_FEATURE_SEP, hvm_featureset);
>  
> +if ( !boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
> +/* Clear VIRT_SSBD if VIRT_SPEC_CTRL is not exposed to guests. */
> +__clear_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
> +
>  /*
>   * If Xen isn't virtualising MSR_SPEC_CTRL for HVM guests (functional
>   * availability, or admin choice), hide the feature.
> @@ -597,6 +601,13 @@ static void __init calculate_hvm_def_policy(void)
>  guest_common_feature_adjustments(hvm_featureset);
>  guest_common_default_feature_adjustments(hvm_featureset);
>  
> +/*
> + * Only expose VIRT_SSBD if AMD_SSBD is not available, and thus
> + * VIRT_SC_MSR_HVM is set.
> + */
> +if ( boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
> +__set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);

The earlier patch sets the bit in "max" when SC_MSR_HVM && AMD_SSBD.
This patch doesn't set the bit in "max" at all (it only clears it in
one case as per the earlier hunk), thus leading to "def" holding a
set bit which supposedly cannot be set. Irrespective of the feature's
'!' annotation I think we'd better not violate "max" >= "def".

Everything else in this patch looks good to me.

Jan

Re: [xen-unstable test] 169819: regressions - FAIL

[Roger Pau Monné]

On Fri, Apr 29, 2022 at 07:46:47AM +, osstest service owner wrote:
> flight 169819 xen-unstable real [real]
> flight 169843 xen-unstable real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/169819/
> http://logs.test-lab.xenproject.org/osstest/logs/169843/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-arm64-arm64-examine  8 reboot   fail REGR. vs. 
> 169775
>  test-arm64-arm64-libvirt-xsm  8 xen-boot fail REGR. vs. 
> 169775
>  test-arm64-arm64-libvirt-raw  8 xen-boot fail REGR. vs. 
> 169775
>  test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 
> 169775
>  test-arm64-arm64-xl-thunderx  8 xen-boot fail REGR. vs. 
> 169775
>  test-arm64-arm64-xl   8 xen-boot fail REGR. vs. 
> 169775
> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
> in 169843-retest

Looked into this one, and it's slightly concerning, guest seems to be
stuck at installation:

Select and install software  [  481.093857] watchdog: BUG: soft lockup - CPU#1 
stuck for 23s! [ksoftirqd/1:17]
[  509.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  545.093820] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  573.093809] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  609.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  637.093836] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  673.093957] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  701.093854] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  733.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  761.093817] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  797.093898] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  825.093863] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  861.093865] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  889.093945] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[  925.093974] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  953.093925] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[  985.093832] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1013.093855] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1049.094031] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1077.093860] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1113.093938] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1141.093803] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1177.094051] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1205.093805] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1237.093955] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1265.094004] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1301.093835] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1329.094039] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1365.093883] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1393.094167] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1429.093857] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1457.093900] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1489.094026] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1517.093997] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1553.093996] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1581.094064] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1617.094076] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1645.093882] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1681.093896] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1709.094022] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1741.093870] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1769.093854] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1805.094017] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1833.093837] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! 
[ksoftirqd/1:17]
[ 1869.094043] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 
[ksoftirqd/1:17]
[ 1897.094101] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! 

Re: [PATCH] x86/cet: Support cet= on the command line

[Andrew Cooper]

On 28/04/2022 11:13, Jan Beulich wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -117,7 +117,20 @@ static int __init cf_check parse_cet(const char *s)
>>  if ( !ss )
>>  ss = strchr(s, '\0');
>>  
>> -if ( (val = parse_boolean("shstk", s, ss)) >= 0 )
>> +if ( (val = parse_bool(s, ss)) >= 0 )
>> +{
>> +#ifdef CONFIG_XEN_SHSTK
>> +opt_xen_shstk = val;
>> +#else
>> +no_config_param("XEN_SHSTK", "cet", s, ss);
>> +#endif
>> +#ifdef CONFIG_XEN_IBT
>> +opt_xen_ibt = val;
>> +#else
>> +no_config_param("XEN_IBT", "cet", s, ss);
>> +#endif
> There shouldn't be two invocations of no_config_param() here; imo if
> either CONFIG_* is defined, use of the option shouldn't produce any
> warning at all.

It's this, or:

    if ( (val = parse_bool(s, ss)) >= 0 )
    {
#if !defined(CONFIG_XEN_SHSTK) && !defined(CONFIG_XEN_IBT)
    no_config_param("XEN_{SHSTK,IBT}", "cet", s, ss);
#endif
#ifdef CONFIG_XEN_SHSTK
    opt_xen_shstk = val;
#endif
#ifdef CONFIG_XEN_IBT
    opt_xen_ibt = val;
#endif
    }

I'm not terribly fussed.

~Andrew

Re: [PATCH] x86/cet: Support cet= on the command line

[Andrew Cooper]

On 28/04/2022 11:13, Jan Beulich wrote:
> On 28.04.2022 10:52, Andrew Cooper wrote:
>> @@ -283,6 +283,8 @@ CET is incompatible with 32bit PV guests.  If any CET 
>> sub-options are active,
>>  they will override the `pv=32` boolean to `false`.  Backwards compatibility
>>  can be maintained with the pv-shim mechanism.
>>  
>> +*   An unqualified boolean is shorthand for setting all suboptions at once.
> You're the native speaker, but I wonder whether there an "a" missing
> before "shorthand".

I was going to say it was correct as is, but it turn out both are
acceptable.  "shorthand" is both a countable and uncountable quantity,
and both "sound" right.

~Andrew

Re: x86/PV: (lack of) MTRR exposure

[Roger Pau Monné]

On Fri, Apr 29, 2022 at 11:50:39AM +0200, Jan Beulich wrote:
> On 28.04.2022 23:30, Boris Ostrovsky wrote:
> > 
> > On 4/28/22 11:53 AM, Jan Beulich wrote:
> >> Hello,
> >>
> >> in the course of analyzing the i915 driver causing boot to fail in
> >> Linux 5.18 I found that Linux, for all the years, has been running
> >> in PV mode as if PAT was (mostly) disabled. This is a result of
> >> them tying PAT initialization to MTRR initialization, while we
> >> offer PAT but not MTRR in CPUID output. This was different before
> >> our moving to CPU featuresets, and as such one could view this
> >> behavior as a regression from that change.
> >>
> >> The first question here is whether not exposing MTRR as a feature
> >> was really intended, in particular also for PV Dom0. The XenoLinux
> >> kernel and its forward ports did make use of XENPF_*_memtype to
> >> deal with MTRRs. That's functionality which (maybe for a good
> >> reason) never made it into the pvops kernel. Note that PVH Dom0
> >> does have access to the original settings, as the host values are
> >> used as initial state there.
> > 
> > 
> > Initially MTRR was supposed to be supported but it was shot down by x86 
> > maintainers who strongly suggested to use PAT.
> > 
> > 
> > https://lists.xen.org/archives/html/xen-devel/2010-09/msg01634.html
> 
> I recall Ingo's dislike, yes. But them suggesting to use PAT when
> PAT depends on MTRR internally is, well, odd. Plus there continues
> to be the question why PVH Dom0 should see (and be able to play
> with) MTRRs, when PV Dom0 can't even learn their values.

Oh, I didn't realize the handling of MTRR in PVH dom0 was a question,
sorry.

I don't think it makes sense to limit PVH dom0 access to MTRR if that
then implies changes to Linux when running in PVH mode so it can use
PAT, and likely changes to Xen in order to avoid using MTRR when
calculating the effective cache types (ie: in epte_get_entry_emt).

I also don't think there's a need to have this kind of feature parity
between PVH and PV dom0s.  IMO we should expose whatever is required
or makes the implementation of guests easier.  For PVH we could always
stop reporting the CPUID MTRR bit and thus stop exposing MTRRs and
guests should cope.

Thanks, Roger.