Re: [Xen-devel] [RFC v5 025/126] scripts: add coccinelle script to use auto propagated errp

[Eric Blake]

On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---




  scripts/coccinelle/auto-propagated-errp.cocci | 118 ++
  1 file changed, 118 insertions(+)
  create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci

diff --git a/scripts/coccinelle/auto-propagated-errp.cocci 
b/scripts/coccinelle/auto-propagated-errp.cocci
new file mode 100644
index 00..d9731620aa
--- /dev/null
+++ b/scripts/coccinelle/auto-propagated-errp.cocci



+@rule1@
+// Drop local_err
+identifier fn, local_err;
+symbol errp;
+@@
+
+ fn(..., Error **errp, ...)
+ {
+ <...
+-Error *local_err = NULL;
+ ...>
+ }
+


So our goal is to automate removal of all local_err (including when it 
is spelled err)...



+@@
+// Handle pattern with goto, otherwise we'll finish up
+// with labels at function end which will not compile.
+identifier rule1.fn;
+identifier rule1.local_err;
+identifier OUT;
+@@
+
+ fn(...)
+ {
+ <...
+-goto OUT;
++return;
+ ...>
+- OUT:
+-error_propagate(errp, local_err);
+ }
+


this dangling label cleanup makes sense


+@@
+identifier rule1.fn;
+identifier rule1.local_err;
+@@
+
+ fn(...)
+ {
+ <...
+(
+-error_free(local_err);
+-local_err = NULL;
++error_free_errp(errp);


This does not make sense - error_free_errp() is not defined prior to 
this series or anywhere in patches 1-24, if I'm reading it correctly.



+|
+-error_free(local_err);
++error_free_errp(errp);


and again


+|
+-error_report_err(local_err);
++error_report_errp(errp);
+|
+-warn_report_err(local_err);
++warn_report_errp(errp);
+|
+-error_propagate_prepend(errp, local_err,
++error_prepend(errp,
+  ...);
+|
+-error_propagate(errp, local_err);
+)
+ ...>
+ }
+


It looks like once this script is run, error_propagate_prepend() will 
have no clients.  Is there a non-generated cleanup patch that removes it 
(and once it is removed, it can also be removed from the .cocci script 
as no further clients will reappear later)?




+@@
+identifier rule1.fn;
+identifier rule1.local_err;
+@@
+
+ fn(...)
+ {
+ <...
+(
+-_err
++errp
+|
+-local_err
++*errp
+)
+ ...>
+ }
+
+@@
+symbol errp;
+@@
+
+- *errp != NULL
++ *errp



Seems to make sense.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

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

Re: [Xen-devel] [RFC v5 025/126] scripts: add coccinelle script to use auto propagated errp

[Eric Blake]

On 10/11/19 12:12 PM, Eric Blake wrote:

On 10/11/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---




+@@
+identifier rule1.fn;
+identifier rule1.local_err;
+@@
+
+ fn(...)
+ {
+ <...
+(
+-    error_free(local_err);
+-    local_err = NULL;
++    error_free_errp(errp);


This does not make sense - error_free_errp() is not defined prior to 
this series or anywhere in patches 1-24, if I'm reading it correctly.


Apologies - I sent my reply to this message before 21/126 showed up in 
my inbox, and didn't realize that I had skipped over sequencing.  This 
part is fine after all, but it points to the perils of reviewing a 
thread as it comes in piecemeal, vs. reviewing an actual branch with all 
patches instantly available.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

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

[Xen-devel] [RFC v5 025/126] scripts: add coccinelle script to use auto propagated errp

[Vladimir Sementsov-Ogievskiy]

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

CC: Gerd Hoffmann 
CC: "Gonglei (Arei)" 
CC: Eduardo Habkost 
CC: Igor Mammedov 
CC: Laurent Vivier 
CC: Amit Shah 
CC: Kevin Wolf 
CC: Max Reitz 
CC: John Snow 
CC: Ari Sundholm 
CC: Pavel Dovgalyuk 
CC: Paolo Bonzini 
CC: Stefan Hajnoczi 
CC: Fam Zheng 
CC: Stefan Weil 
CC: Ronnie Sahlberg 
CC: Peter Lieven 
CC: Eric Blake 
CC: "Denis V. Lunev" 
CC: Markus Armbruster 
CC: Alberto Garcia 
CC: Jason Dillaman 
CC: Wen Congyang 
CC: Xie Changlong 
CC: Liu Yuan 
CC: "Richard W.M. Jones" 
CC: Jeff Cody 
CC: "Marc-André Lureau" 
CC: "Daniel P. Berrangé" 
CC: Richard Henderson 
CC: Greg Kurz 
CC: "Michael S. Tsirkin" 
CC: Marcel Apfelbaum 
CC: Beniamino Galvani 
CC: Peter Maydell 
CC: "Cédric Le Goater" 
CC: Andrew Jeffery 
CC: Joel Stanley 
CC: Andrew Baumann 
CC: "Philippe Mathieu-Daudé" 
CC: Antony Pavlov 
CC: Jean-Christophe Dubois 
CC: Peter Chubb 
CC: Subbaraya Sundeep 
CC: Eric Auger 
CC: Alistair Francis 
CC: "Edgar E. Iglesias" 
CC: Stefano Stabellini 
CC: Anthony Perard 
CC: Paul Durrant 
CC: Paul Burton 
CC: Aleksandar Rikalo 
CC: Chris Wulff 
CC: Marek Vasut 
CC: David Gibson 
CC: Cornelia Huck 
CC: Halil Pasic 
CC: Christian Borntraeger 
CC: "Hervé Poussineau" 
CC: Xiao Guangrong 
CC: Aurelien Jarno 
CC: Aleksandar Markovic 
CC: Mark Cave-Ayland 
CC: Jason Wang 
CC: Laszlo Ersek 
CC: Yuval Shaia 
CC: Palmer Dabbelt 
CC: Sagar Karandikar 
CC: Bastian Koppelmann 
CC: David Hildenbrand 
CC: Thomas Huth 
CC: Eric Farman 
CC: Matthew Rosato 
CC: Hannes Reinecke 
CC: Michael Walle 
CC: Artyom Tarasenko 
CC: Stefan Berger 
CC: Samuel Thibault 
CC: Alex Williamson 
CC: Tony Krowiak 
CC: Pierre Morel 
CC: Michael Roth 
CC: Hailiang Zhang 
CC: Juan Quintela 
CC: "Dr. David Alan Gilbert" 
CC: Luigi Rizzo 
CC: Giuseppe Lettieri 
CC: Vincenzo Maffione 
CC: Jan Kiszka 
CC: Anthony Green 
CC: Stafford Horne 
CC: Guan Xuetao 
CC: Max Filippov 
CC: qemu-bl...@nongnu.org
CC: integrat...@gluster.org
CC: sheep...@lists.wpkg.org
CC: qemu-...@nongnu.org
CC: xen-devel@lists.xenproject.org
CC: qemu-...@nongnu.org
CC: qemu-s3...@nongnu.org
CC: qemu-ri...@nongnu.org

 scripts/coccinelle/auto-propagated-errp.cocci | 118 ++
 1 file changed, 118 insertions(+)
 create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci

diff --git a/scripts/coccinelle/auto-propagated-errp.cocci 
b/scripts/coccinelle/auto-propagated-errp.cocci
new file mode 100644
index 00..d9731620aa
--- /dev/null
+++ b/scripts/coccinelle/auto-propagated-errp.cocci
@@ -0,0 +1,118 @@
+@rule0@
+// Add invocation to errp-functions where necessary
+identifier fn, local_err;
+symbol errp;
+@@
+
+ fn(..., Error **errp, ...)
+ {
++   ERRP_AUTO_PROPAGATE();
+<+...
+(
+error_append_hint(errp, ...);
+|
+error_prepend(errp, ...);
+|
+Error *local_err = NULL;
+)
+...+>
+ }
+
+@@
+// Drop doubled invocation
+identifier rule0.fn;
+@@
+
+ fn(...)
+{
+-   ERRP_AUTO_PROPAGATE();
+ERRP_AUTO_PROPAGATE();
+...
+}
+
+@rule1@
+// Drop local_err
+identifier fn, local_err;
+symbol errp;
+@@
+
+ fn(..., Error **errp, ...)
+ {
+ <...
+-Error *local_err = NULL;
+ ...>
+ }
+
+@@
+// Handle pattern with goto, otherwise we'll finish up
+// with labels at function end which will not compile.
+identifier rule1.fn;
+identifier rule1.local_err;
+identifier OUT;
+@@
+
+ fn(...)
+ {
+ <...
+-goto OUT;
++return;
+ ...>
+- OUT:
+-error_propagate(errp, local_err);
+ }
+
+@@
+identifier rule1.fn;
+identifier rule1.local_err;
+@@
+
+ fn(...)
+ {
+ <...
+(
+-error_free(local_err);
+-local_err = NULL;
++error_free_errp(errp);
+|
+-error_free(local_err);
++error_free_errp(errp);
+|
+-error_report_err(local_err);
++error_report_errp(errp);
+|
+-warn_report_err(local_err);
++warn_report_errp(errp);
+|
+-error_propagate_prepend(errp, local_err,
++error_prepend(errp,
+  ...);
+|
+-error_propagate(errp, local_err);
+)
+ ...>
+ }
+
+@@
+identifier rule1.fn;
+identifier rule1.local_err;
+@@
+
+ fn(...)
+ {
+ <...
+(
+-_err
++errp
+|
+-local_err
++*errp
+)
+ ...>
+ }
+
+@@
+symbol errp;
+@@
+
+- *errp != NULL
++ *errp
-- 
2.21.0


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

[Xen-devel] [RFC v5 024/126] error: auto propagated local_err

[Vladimir Sementsov-Ogievskiy]

Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with errp OUT parameter.

It has three goals:

1. Fix issue with error_fatal & error_prepend/error_append_hint: user
can't see this additional information, because exit() happens in
error_setg earlier than information is added. [Reported by Greg Kurz]

2. Fix issue with error_abort & error_propagate: when we wrap
error_abort by local_err+error_propagate, resulting coredump will
refer to error_propagate and not to the place where error happened.
(the macro itself doesn't fix the issue, but it allows to [3.] drop all
local_err+error_propagate pattern, which will definitely fix the issue)
[Reported by Kevin Wolf]

3. Drop local_err+error_propagate pattern, which is used to workaround
void functions with errp parameter, when caller wants to know resulting
status. (Note: actually these functions could be merely updated to
return int error code).

To achieve these goals, we need to add invocation of the macro at start
of functions, which needs error_prepend/error_append_hint (1.); add
invocation of the macro at start of functions which do
local_err+error_propagate scenario the check errors, drop local errors
from them and just use *errp instead (2., 3.).

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Eric Blake 
---

CC: Gerd Hoffmann 
CC: "Gonglei (Arei)" 
CC: Eduardo Habkost 
CC: Igor Mammedov 
CC: Laurent Vivier 
CC: Amit Shah 
CC: Kevin Wolf 
CC: Max Reitz 
CC: John Snow 
CC: Ari Sundholm 
CC: Pavel Dovgalyuk 
CC: Paolo Bonzini 
CC: Stefan Hajnoczi 
CC: Fam Zheng 
CC: Stefan Weil 
CC: Ronnie Sahlberg 
CC: Peter Lieven 
CC: Eric Blake 
CC: "Denis V. Lunev" 
CC: Markus Armbruster 
CC: Alberto Garcia 
CC: Jason Dillaman 
CC: Wen Congyang 
CC: Xie Changlong 
CC: Liu Yuan 
CC: "Richard W.M. Jones" 
CC: Jeff Cody 
CC: "Marc-André Lureau" 
CC: "Daniel P. Berrangé" 
CC: Richard Henderson 
CC: Greg Kurz 
CC: "Michael S. Tsirkin" 
CC: Marcel Apfelbaum 
CC: Beniamino Galvani 
CC: Peter Maydell 
CC: "Cédric Le Goater" 
CC: Andrew Jeffery 
CC: Joel Stanley 
CC: Andrew Baumann 
CC: "Philippe Mathieu-Daudé" 
CC: Antony Pavlov 
CC: Jean-Christophe Dubois 
CC: Peter Chubb 
CC: Subbaraya Sundeep 
CC: Eric Auger 
CC: Alistair Francis 
CC: "Edgar E. Iglesias" 
CC: Stefano Stabellini 
CC: Anthony Perard 
CC: Paul Durrant 
CC: Paul Burton 
CC: Aleksandar Rikalo 
CC: Chris Wulff 
CC: Marek Vasut 
CC: David Gibson 
CC: Cornelia Huck 
CC: Halil Pasic 
CC: Christian Borntraeger 
CC: "Hervé Poussineau" 
CC: Xiao Guangrong 
CC: Aurelien Jarno 
CC: Aleksandar Markovic 
CC: Mark Cave-Ayland 
CC: Jason Wang 
CC: Laszlo Ersek 
CC: Yuval Shaia 
CC: Palmer Dabbelt 
CC: Sagar Karandikar 
CC: Bastian Koppelmann 
CC: David Hildenbrand 
CC: Thomas Huth 
CC: Eric Farman 
CC: Matthew Rosato 
CC: Hannes Reinecke 
CC: Michael Walle 
CC: Artyom Tarasenko 
CC: Stefan Berger 
CC: Samuel Thibault 
CC: Alex Williamson 
CC: Tony Krowiak 
CC: Pierre Morel 
CC: Michael Roth 
CC: Hailiang Zhang 
CC: Juan Quintela 
CC: "Dr. David Alan Gilbert" 
CC: Luigi Rizzo 
CC: Giuseppe Lettieri 
CC: Vincenzo Maffione 
CC: Jan Kiszka 
CC: Anthony Green 
CC: Stafford Horne 
CC: Guan Xuetao 
CC: Max Filippov 
CC: qemu-bl...@nongnu.org
CC: integrat...@gluster.org
CC: sheep...@lists.wpkg.org
CC: qemu-...@nongnu.org
CC: xen-devel@lists.xenproject.org
CC: qemu-...@nongnu.org
CC: qemu-s3...@nongnu.org
CC: qemu-ri...@nongnu.org

 include/qapi/error.h | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/include/qapi/error.h b/include/qapi/error.h
index d6898d833b..47238d9065 100644
--- a/include/qapi/error.h
+++ b/include/qapi/error.h
@@ -345,6 +345,44 @@ void error_set_internal(Error **errp,
 ErrorClass err_class, const char *fmt, ...)
 GCC_FMT_ATTR(6, 7);
 
+typedef struct ErrorPropagator {
+Error *local_err;
+Error **errp;
+} ErrorPropagator;
+
+static inline void error_propagator_cleanup(ErrorPropagator *prop)
+{
+error_propagate(prop->errp, prop->local_err);
+}
+
+G_DEFINE_AUTO_CLEANUP_CLEAR_FUNC(ErrorPropagator, error_propagator_cleanup);
+
+/*
+ * ERRP_AUTO_PROPAGATE
+ *
+ * This macro is created to be the first line of a function with Error **errp
+ * OUT parameter. It's needed only in cases where we want to use error_prepend,
+ * error_append_hint or dereference *errp. It's still safe (but useless) in
+ * other cases.
+ *
+ * If errp is NULL or points to error_fatal, it is rewritten to point to a
+ * local Error object, which will be automatically propagated to the original
+ * errp on function exit (see error_propagator_cleanup).
+ *
+ * After invocation of this macro it is always safe to dereference errp
+ * (as it's not NULL anymore) and to add information (by error_prepend or
+ * error_append_hint)
+ * (as, if it was error_fatal, we swapped it with a local_error to be
+ * propagated on cleanup).
+ *
+ * Note: we don't wrap the error_abort case, as we want resulting coredump
+ * to point to the place 

[Xen-devel] [RFC v5 026/126] python: add commit-per-subsystem.py

[Vladimir Sementsov-Ogievskiy]

Add script to automatically commit tree-wide changes per-subsystem.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

CC: Gerd Hoffmann 
CC: "Gonglei (Arei)" 
CC: Eduardo Habkost 
CC: Igor Mammedov 
CC: Laurent Vivier 
CC: Amit Shah 
CC: Kevin Wolf 
CC: Max Reitz 
CC: John Snow 
CC: Ari Sundholm 
CC: Pavel Dovgalyuk 
CC: Paolo Bonzini 
CC: Stefan Hajnoczi 
CC: Fam Zheng 
CC: Stefan Weil 
CC: Ronnie Sahlberg 
CC: Peter Lieven 
CC: Eric Blake 
CC: "Denis V. Lunev" 
CC: Markus Armbruster 
CC: Alberto Garcia 
CC: Jason Dillaman 
CC: Wen Congyang 
CC: Xie Changlong 
CC: Liu Yuan 
CC: "Richard W.M. Jones" 
CC: Jeff Cody 
CC: "Marc-André Lureau" 
CC: "Daniel P. Berrangé" 
CC: Richard Henderson 
CC: Greg Kurz 
CC: "Michael S. Tsirkin" 
CC: Marcel Apfelbaum 
CC: Beniamino Galvani 
CC: Peter Maydell 
CC: "Cédric Le Goater" 
CC: Andrew Jeffery 
CC: Joel Stanley 
CC: Andrew Baumann 
CC: "Philippe Mathieu-Daudé" 
CC: Antony Pavlov 
CC: Jean-Christophe Dubois 
CC: Peter Chubb 
CC: Subbaraya Sundeep 
CC: Eric Auger 
CC: Alistair Francis 
CC: "Edgar E. Iglesias" 
CC: Stefano Stabellini 
CC: Anthony Perard 
CC: Paul Durrant 
CC: Paul Burton 
CC: Aleksandar Rikalo 
CC: Chris Wulff 
CC: Marek Vasut 
CC: David Gibson 
CC: Cornelia Huck 
CC: Halil Pasic 
CC: Christian Borntraeger 
CC: "Hervé Poussineau" 
CC: Xiao Guangrong 
CC: Aurelien Jarno 
CC: Aleksandar Markovic 
CC: Mark Cave-Ayland 
CC: Jason Wang 
CC: Laszlo Ersek 
CC: Yuval Shaia 
CC: Palmer Dabbelt 
CC: Sagar Karandikar 
CC: Bastian Koppelmann 
CC: David Hildenbrand 
CC: Thomas Huth 
CC: Eric Farman 
CC: Matthew Rosato 
CC: Hannes Reinecke 
CC: Michael Walle 
CC: Artyom Tarasenko 
CC: Stefan Berger 
CC: Samuel Thibault 
CC: Alex Williamson 
CC: Tony Krowiak 
CC: Pierre Morel 
CC: Michael Roth 
CC: Hailiang Zhang 
CC: Juan Quintela 
CC: "Dr. David Alan Gilbert" 
CC: Luigi Rizzo 
CC: Giuseppe Lettieri 
CC: Vincenzo Maffione 
CC: Jan Kiszka 
CC: Anthony Green 
CC: Stafford Horne 
CC: Guan Xuetao 
CC: Max Filippov 
CC: qemu-bl...@nongnu.org
CC: integrat...@gluster.org
CC: sheep...@lists.wpkg.org
CC: qemu-...@nongnu.org
CC: xen-devel@lists.xenproject.org
CC: qemu-...@nongnu.org
CC: qemu-s3...@nongnu.org
CC: qemu-ri...@nongnu.org

 python/commit-per-subsystem.py | 204 +
 1 file changed, 204 insertions(+)
 create mode 100755 python/commit-per-subsystem.py

diff --git a/python/commit-per-subsystem.py b/python/commit-per-subsystem.py
new file mode 100755
index 00..2ccf84cb15
--- /dev/null
+++ b/python/commit-per-subsystem.py
@@ -0,0 +1,204 @@
+#!/usr/bin/env python3
+#
+# Copyright (c) 2019 Virtuozzo International GmbH
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+import subprocess
+import sys
+import os
+import glob
+
+
+def git_add(pattern):
+subprocess.run(['git', 'add', pattern])
+
+
+def git_commit(msg):
+subprocess.run(['git', 'commit', '-m', msg], capture_output=True)
+
+
+def git_changed_files():
+ret = subprocess.check_output(['git', 'diff', '--name-only'], 
encoding='utf-8').split('\n')
+if ret[-1] == '':
+del ret[-1]
+return ret
+
+
+maintainers = sys.argv[1]
+message = sys.argv[2].strip()
+
+subsystem = None
+
+remap = {
+'Block layer core': 'block',
+'Block Jobs': 'block',
+'Dirty Bitmaps': 'block',
+'Block QAPI, monitor, command line': 'block',
+'Block I/O path': 'block',
+'Throttling infrastructure': 'block',
+'Architecture support': 's390x',
+'Guest CPU Cores (KVM)': 'kvm',
+'Guest CPU Cores (Xen)': 'xen',
+'Guest CPU cores (TCG)': 'tcg',
+'Network Block Device (NBD)': 'nbd',
+'Parallel NOR Flash devices': 'pflash',
+'Firmware configuration (fw_cfg)': 'fw_cfg',
+'Block SCSI subsystem': 'scsi',
+'Network device backends': 'net',
+'Netmap network backend': 'net',
+'Host Memory Backends': 'hostmem',
+'Cryptodev Backends': 'cryptodev',
+'QEMU Guest Agent': 'qga',
+'COLO Framework': 'colo',
+'Command line option argument parsing': 'cmdline',
+'Character device backends': 'chardev'
+}
+
+
+class Maintainers:
+def add(self, subsystem, path, mapper, mapper_name, glob_count=1):
+if subsystem in remap:
+subsystem = remap[subsystem]
+if subsystem not in self.subsystems:
+self.subsystems.append(subsystem)
+
+if path[-1] == '/':
+path = path[:-1]
+
+

[Xen-devel] [RFC v5 000/126] error: auto propagated local_err

[Vladimir Sementsov-Ogievskiy]

Hi all!

At the request of Markus: full version of errp propagation. Let's look
at it. Cover as much as possible, except inserting macro invocation
where it's not necessary.

It's huge, and so it's an RFC.

In v5 I've added a lot more preparation cleanups:
01-23 are preparation cleanups
  01: not changed, keep Eric's r-b
  02: improve commit msg [Markus], keep Eric's r-b
  03: changed, only error API here, drop r-b
24 is core macro
  - improve cover letter, wording and macro code style
  - keep Eric's r-b
25-26: automation scripts
   - commit-per-subsystem changed a lot. it's a draft, don't bother too
 much with it
   - coccinelle: add support of error_propagate_prepend

27-126: generated patches



Here is a proposal of auto propagation for local_err, to not call
error_propagate on every exit point, when we deal with local_err.

There are also two issues with errp:

1. error_fatal & error_append_hint/error_prepend: user can't see this
additional info, because exit() happens in error_setg earlier than info
is added. [Reported by Greg Kurz]

2. error_abort & error_propagate: when we wrap
error_abort by local_err+error_propagate, resulting coredump will
refer to error_propagate and not to the place where error happened.
(the macro itself don't fix the issue, but it allows to [3.] drop all
local_err+error_propagate pattern, which will definitely fix the issue)
[Reported by Kevin Wolf]



Generated patches split:

misc
   hw/misc/ivshmem.c
   hw/misc/tmp105.c
   hw/misc/tmp421.c
s390x
   hw/intc/s390_flic_kvm.c
   hw/s390x/3270-ccw.c
   hw/s390x/css-bridge.c
   hw/s390x/css.c
   hw/s390x/s390-skeys.c
   hw/s390x/s390-virtio-ccw.c
   hw/s390x/sclp.c
   hw/s390x/tod-kvm.c
   hw/vfio/ccw.c
   target/s390x/cpu.c
tcg
   exec.c
   hw/arm/armv7m.c
   hw/arm/smmu-common.c
   hw/arm/smmuv3.c
   hw/cpu/a15mpcore.c
   hw/cpu/a9mpcore.c
   hw/cpu/arm11mpcore.c
   hw/i386/pc.c
   hw/intc/nios2_iic.c
   hw/mips/cps.c
   hw/riscv/riscv_hart.c
   hw/riscv/sifive_e.c
   hw/riscv/sifive_u.c
   hw/sd/milkymist-memcard.c
   target/alpha/cpu.c
   target/arm/cpu.c
   target/arm/cpu64.c
   target/cris/cpu.c
   target/hppa/cpu.c
   target/i386/cpu.c
   target/lm32/cpu.c
   target/m68k/cpu.c
   target/microblaze/cpu.c
   target/mips/cpu.c
   target/moxie/cpu.c
   target/nios2/cpu.c
   target/openrisc/cpu.c
   target/ppc/compat.c
   target/ppc/translate_init.inc.c
   target/riscv/cpu.c
   target/sh4/cpu.c
   target/sparc/cpu.c
   target/tricore/cpu.c
   target/unicore32/cpu.c
   target/xtensa/cpu.c
kvm
   target/ppc/kvm.c
   target/s390x/cpu_models.c
xen
   hw/block/dataplane/xen-block.c
   hw/block/xen-block.c
   hw/xen/xen-backend.c
   hw/xen/xen-bus.c
   hw/xen/xen-host-pci-device.c
   hw/xen/xen_pt.c
   hw/xen/xen_pt_config_init.c
Hosts
   qga/commands-win32.c
   util/oslib-posix.c
ARM Machines
   hw/arm/allwinner-a10.c
   hw/arm/aspeed_soc.c
   hw/arm/bcm2835_peripherals.c
   hw/arm/bcm2836.c
   hw/arm/digic.c
   hw/arm/fsl-imx25.c
   hw/arm/fsl-imx31.c
   hw/arm/fsl-imx6.c
   hw/arm/integratorcp.c
   hw/arm/msf2-soc.c
   hw/arm/nrf51_soc.c
   hw/arm/stm32f205_soc.c
   hw/arm/virt.c
   hw/arm/xlnx-versal-virt.c
   hw/arm/xlnx-zynqmp.c
   hw/cpu/realview_mpcore.c
   hw/display/bcm2835_fb.c
   hw/dma/bcm2835_dma.c
   hw/dma/xilinx_axidma.c
   hw/gpio/aspeed_gpio.c
   hw/gpio/bcm2835_gpio.c
   hw/intc/arm_gic.c
   hw/intc/arm_gic_kvm.c
   hw/intc/arm_gicv3.c
   hw/intc/arm_gicv3_its_kvm.c
   hw/intc/arm_gicv3_kvm.c
   hw/intc/armv7m_nvic.c
   hw/intc/realview_gic.c
   hw/microblaze/xlnx-zynqmp-pmu.c
   hw/misc/bcm2835_mbox.c
   hw/misc/bcm2835_property.c
   hw/misc/msf2-sysreg.c
   hw/net/xilinx_axienet.c
   hw/nvram/nrf51_nvm.c
   hw/timer/aspeed_timer.c
   hw/watchdog/wdt_aspeed.c
MIPS Machines
   hw/core/loader-fit.c
PowerPC Machines
   hw/intc/pnv_xive.c
   hw/intc/xics.c
   hw/intc/xics_kvm.c
   hw/intc/xics_pnv.c
   hw/intc/xics_spapr.c
   hw/isa/pc87312.c
   hw/misc/macio/macio.c
   hw/ppc/e500.c
   hw/ppc/mac_newworld.c
   hw/ppc/pnv.c
   hw/ppc/pnv_core.c
   hw/ppc/pnv_homer.c
   hw/ppc/pnv_lpc.c
   hw/ppc/pnv_occ.c
   hw/ppc/pnv_psi.c
   hw/ppc/spapr.c
   hw/ppc/spapr_caps.c
   hw/ppc/spapr_cpu_core.c
   hw/ppc/spapr_drc.c
   hw/ppc/spapr_irq.c
   hw/ppc/spapr_pci.c
   hw/ppc/spapr_vio.c
SPARC Machines
   hw/sparc/sun4m.c
   hw/sparc64/sun4u.c
S390 Machines
   hw/s390x/ipl.c
   hw/s390x/s390-pci-bus.c
X86 Machines
   hw/acpi/ich9.c
   hw/char/debugcon.c
   hw/char/serial-pci-multi.c
   hw/char/serial-pci.c
   hw/core/machine.c
   hw/core/numa.c
   hw/intc/apic_common.c
   hw/pci-host/piix.c
IDE
   hw/ide/qdev.c
Floppy
   hw/block/fdc.c
IPack
   hw/ipack/ipack.c
PCI
   hw/pci-bridge/gen_pcie_root_port.c
   hw/pci-bridge/pci_bridge_dev.c
   hw/pci-bridge/pci_expander_bridge.c
   hw/pci-bridge/pcie_pci_bridge.c
   hw/pci-bridge/pcie_root_port.c
   hw/pci/pci.c
   hw/pci/pcie.c
   hw/pci/shpc.c
ACPI/SMBIOS
   hw/acpi/core.c
   hw/acpi/cpu_hotplug.c
   hw/acpi/memory_hotplug.c
   hw/mem/memory-device.c
   

Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err

[Eric Blake]

On 10/11/19 11:03 AM, Vladimir Sementsov-Ogievskiy wrote:

Hi all!

At the request of Markus: full version of errp propagation. Let's look
at it. Cover as much as possible, except inserting macro invocation
where it's not necessary.

It's huge, and so it's an RFC.


Is there a repo containing these patches, to make it easier to play with 
them locally without having to 'git am' the entire 126 messages?




  util/qemu-sockets.c   |  31 +--
  vl.c  |  14 +-
  python/commit-per-subsystem.py| 204 ++
  scripts/coccinelle/auto-propagated-errp.cocci | 118 
  341 files changed, 3851 insertions(+), 4455 deletions(-)
  create mode 100755 python/commit-per-subsystem.py
  create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci


So, whether or not we take commit-per-subsystem.py, the overall series 
appears to be a nice reduction in lines of code.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

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

[Xen-devel] [xen-unstable test] 142598: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 141822
 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 141822

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 141822
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 141822

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

[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-qemuu-nested-intel

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  6105683da35babad9ae168a72d1e89e63e9d6974
  Bug not present: e1b3d47751a420835cb0560fd029c39fea961a79
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/142639/


  commit 6105683da35babad9ae168a72d1e89e63e9d6974
  Author: Laurent Vivier 
  Date:   Fri Sep 6 10:38:12 2019 +0200
  
  ui: add an embedded Barrier client
  
  This allows to receive mouse and keyboard events from
  a Barrier server.
  
  This is enabled by adding the following parameter on the
  command line
  
  ... -object input-barrier,id=$id,name=$name ...
  
  Where $name is the name declared in the screens section of barrier.conf
  
  The barrier server (barriers) must be configured and must run on the
  local host.
  
  For instance:
  
section: screens
localhost:
...
VM-1:
...
end
  
section: links
localhost:
right = VM-1
VM-1:
left = localhost
end
  
  Then on the QEMU command line:
  
  ... -object input-barrier,id=barrie0,name=VM-1 ...
  
  When the mouse will move out of the screen of the local host on
  the right, the mouse and the keyboard will be grabbed and all
  related events will be send to the guest OS.
  
  This is usefull when qemu is configured without emulated graphic card
  but with a VFIO attached graphic card.
  
  More information about Barrier can be found at:
  
https://github.com/debauchee/barrier
  
  This avoids to install the Barrier server in the guest OS,
  for instance when it is not supported or during the installation.
  
  Signed-off-by: Laurent Vivier 
  Message-id: 20190906083812.29487-1-laur...@vivier.eu
  Signed-off-by: Gerd Hoffmann 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install
 --summary-out=tmp/142639.bisection-summary --basis-template=140282 
--blessings=real,real-bisect qemu-mainline test-amd64-amd64-qemuu-nested-intel 
debian-hvm-install
Searching for failure / basis pass:
 142586 fail [host=albana0] / 141466 [host=huxelrebe1] 141434 [host=elbling1] 
141377 [host=chardonnay1] 141348 [host=huxelrebe0] 141320 [host=godello1] 
141285 [host=elbling0] 141259 [host=godello0] 141243 [host=debina0] 141204 
[host=debina0] 141179 [host=chardonnay0] 141087 [host=baroque0] 141058 ok.
Failure / basis pass flights: 142586 / 141058
(tree with no url: minios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 42327896f194f256e5a361e0069985bc8d209b42 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
410c4d00d9f7e369d1ce183e9e8de98cb59c4d20 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
98b2e3c9ab3abfe476a2b02f8f51813edb90e72d 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
f93abf0315efef861270c25d83c8047fd6a54ec4
Basis pass 3ffe1e79c174b2093f7ee3df589a7705572c9620 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
adb59b633c12eae334540295092da94736bffa33 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
74aa913fe62e54f4cb077df51346d6448d57494b 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
6c9639a72f0ca3a9430ef75f375877182281fdef
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#3ffe1e79c174b2093f7ee3df589a7705572c9620-42327896f194f256e5a361e0069985bc8d209b42
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#adb59b633c12eae334540295092da94736bffa33-410c4d00d9f7e369d1ce183e9e8de98cb59c4d20
 git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484\
 

[Xen-devel] [ovmf test] 142599: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
142423

version targeted for testing:
 ovmf a7e2d20193e853020a1415c25b53280955055394
baseline version:
 ovmf 410c4d00d9f7e369d1ce183e9e8de98cb59c4d20

Last test of basis   142423  2019-10-08 01:39:34 Z3 days
Failing since142455  2019-10-08 19:21:52 Z3 days5 attempts
Testing same since   142599  2019-10-11 11:07:40 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Jiewen Yao 
  Laszlo Ersek 
  Pete Batard 

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



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

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

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

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


Not pushing.

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

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

[Xen-devel] [linux-next test] 142594: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-examine   8 reboot   fail  like 142539
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail  like 142539
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail  like 142539
 test-amd64-i386-libvirt   7 xen-boot fail  like 142539
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot  fail like 142539
 test-amd64-i386-xl-raw7 xen-boot fail  like 142539
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot   fail like 142539
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail like 
142539
 test-amd64-i386-libvirt-xsm   7 xen-boot fail  like 142539
 test-amd64-i386-xl-xsm7 xen-boot fail  like 142539
 test-amd64-i386-xl-shadow 7 xen-boot fail  like 142539
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-bootfail like 142539
 test-amd64-i386-freebsd10-i386  7 xen-bootfail like 142539
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 
142539
 test-amd64-i386-xl7 xen-boot fail  like 142539
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-bootfail like 142539
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot   fail like 142539
 test-amd64-i386-pair 10 xen-boot/src_hostfail  like 142539
 test-amd64-i386-pair 11 xen-boot/dst_hostfail  like 142539
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot  fail like 142539
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  7 xen-boot   fail like 142539
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot   fail like 142539
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot   fail like 142539
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot  fail like 142539
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  7 xen-boot fail like 142539
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot  fail like 142539
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot   fail like 142539
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot   fail like 142539
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot   fail like 142539
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot   fail like 142539
 test-amd64-i386-xl-pvshim 7 xen-boot fail  like 142539
 test-amd64-i386-freebsd10-amd64  7 xen-boot   fail like 142539
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot   fail like 142539
 test-arm64-arm64-examine 11 examine-serial/bootloaderfail  like 142539
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142539
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142539
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142539
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142539
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142539
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-amd64-xl-pvshim  20 guest-start/debian.repeat fail REGR. vs. 133580
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 133580

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133580
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 133580
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   

Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early

[Julien Grall]

On 10/11/19 8:01 PM, Stefano Stabellini wrote:

On Fri, 11 Oct 2019, Julien Grall wrote:

Hi Stefano,

On 10/11/19 6:11 PM, Stefano Stabellini wrote:

This is not pretty, but I don't view this as critical to fix for Xen 4.13.
So
I am thinking to defer this post 4.13.


If the issue doesn't trigger on 4.13, then I agree we shouldn't try to
fix it (badly) at this stage.

But we do have a "minus phys_offset" operation in dump_hyp_walk, I don't
follow why we wouldn't see a problem if Xen is loaded at 1MB on arm32.


I haven't said the issue cannot be triggered. I pointed out I don't view this
as critical.

One of the reason is that I bet nobody ever run Xen below 1MB on Arm32.
Otherwise they would have seen an error...

In other words, I am not going to plan to fix it for Xen 4.13. However, if
someone wants to spend time on it (and have platform to test it), then patch
are welcomed.


If the issue can be triggered then I think we have a choice between
fixing it (you don't necessarily have to be the one to do it) or
documenting that Xen needs to be loaded above XEN_VIRT_ADDR on arm32.


As I said before on a similar topic, if we document this, we also need 
to document that our Xen boot code is definitely not compliant with the 
Arm Arm and you are at risk to not be able to boot ;).



Xen pa: 0x10
Xen va: 0x20
phys_offset: 0xfff0

test_va: 0x202000
test_va - phys_offset = 0x00300200. But it should be 0x102000. >
Given that the problem is in a BUG_ON maybe we could remove it? Or just
rework the BUG_ON?


For arm32, dump_hyp_walk() is only called when the AT instruction fails to
translate a physical address. You are already doing something wrong if you
hit, so you will panic in either case. The only difference is you don't get
the page-table dumped.


Why don't we change the BUG_ON like the following:

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a6637ce347..b7883cfbab 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -284,10 +284,7 @@ void dump_hyp_walk(vaddr_t addr)
 "on CPU%d via TTBR 0x%016"PRIx64"\n",
 addr, smp_processor_id(), ttbr);
  
-if ( smp_processor_id() == 0 )

-BUG_ON( (lpae_t *)(unsigned long)(ttbr - phys_offset) != pgtable );
-else
-BUG_ON( virt_to_maddr(pgtable) != ttbr );
+BUG_ON( virt_to_maddr(pgtable) != ttbr );
  dump_pt_walk(ttbr, addr, HYP_PT_ROOT_LEVEL, 1);
  }
  
We probably don't need the CPU0 special case?


We don't need it. Patch are welcomed.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap

[Brian Woods]

On Fri, Oct 11, 2019 at 07:17:29PM +0100, Julien Grall wrote:
> Hi,
> 
> On 10/11/19 7:06 PM, Brian Woods wrote:
> >On Fri, Oct 11, 2019 at 05:58:35PM +0100, Julien Grall wrote:
> >For that, you'd need to either check the start and end of the added
> >module or the start of both.  So something like:
> >
> >if ( ((mod->start >= start) && (mod->start < (start + size))) ||
> >  ((start >= mod->start) && (start < (mod->start + mod->size))) )
> > printk("WARNING: ...");
> >
> >If you don't you run the risk of having a module overlap but not at the
> >start of the added module (unless there's a guaranteed order).  You're
> >still running all of the checks from what I can tell, just not in nested
> >for loop so. Plus I'm not sure how many times add_boot_module gets run
> >and the "mod->kind == kind .." if statement gets run and is true.
> >If the above is true, wouldn't that cause extra checks for the for loop
> >iterations before it was true?
> 
> For non-dom0less case, we are talking about 4 modules max (Xen, Kernel,
> Initramfs, flask policy). Modules cannot be the shared here.
> 
> For dom0less, you are unlikely to have that many domains started from Xen.
> So the number of modules will still be limited (even more if you share it).

Not arguing that.  With the second loop (checking two start addresses)
it's only n(n-1)/2 iterations. Even if you had 12 memory modules, it's
only 66 iterations.  In the large scheme of things, that isn't THAT
many.

> This code is also only called at boot where there are bigger time consuming
> part (such as domheap initialization). So I would be surprised if you see
> any improvement (other than a couple of cycles) in boot time here.
> 
> Therefore, I would favor a readable solution over a micro-optimized solution
> here.

Which is why I wanted to put it where it was in the patch.  Where the
user would see the warning after the information about the memory
modules were printed (and fair early).

Either way, take your pick of location and if it's only debug or not and
I can write it up and test it.

Brian

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

Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early

[Stefano Stabellini]

On Fri, 11 Oct 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/11/19 6:11 PM, Stefano Stabellini wrote:
> > > This is not pretty, but I don't view this as critical to fix for Xen 4.13.
> > > So
> > > I am thinking to defer this post 4.13.
> > 
> > If the issue doesn't trigger on 4.13, then I agree we shouldn't try to
> > fix it (badly) at this stage.
> > 
> > But we do have a "minus phys_offset" operation in dump_hyp_walk, I don't
> > follow why we wouldn't see a problem if Xen is loaded at 1MB on arm32.
> 
> I haven't said the issue cannot be triggered. I pointed out I don't view this
> as critical.
> 
> One of the reason is that I bet nobody ever run Xen below 1MB on Arm32.
> Otherwise they would have seen an error...
> 
> In other words, I am not going to plan to fix it for Xen 4.13. However, if
> someone wants to spend time on it (and have platform to test it), then patch
> are welcomed.

If the issue can be triggered then I think we have a choice between
fixing it (you don't necessarily have to be the one to do it) or
documenting that Xen needs to be loaded above XEN_VIRT_ADDR on arm32.
But see below.


> > Xen pa: 0x10
> > Xen va: 0x20
> > phys_offset: 0xfff0
> > 
> > test_va: 0x202000
> > test_va - phys_offset = 0x00300200. But it should be 0x102000. >
> > Given that the problem is in a BUG_ON maybe we could remove it? Or just
> > rework the BUG_ON?
> 
> For arm32, dump_hyp_walk() is only called when the AT instruction fails to
> translate a physical address. You are already doing something wrong if you
> hit, so you will panic in either case. The only difference is you don't get
> the page-table dumped.

Why don't we change the BUG_ON like the following:

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a6637ce347..b7883cfbab 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -284,10 +284,7 @@ void dump_hyp_walk(vaddr_t addr)
"on CPU%d via TTBR 0x%016"PRIx64"\n",
addr, smp_processor_id(), ttbr);
 
-if ( smp_processor_id() == 0 )
-BUG_ON( (lpae_t *)(unsigned long)(ttbr - phys_offset) != pgtable );
-else
-BUG_ON( virt_to_maddr(pgtable) != ttbr );
+BUG_ON( virt_to_maddr(pgtable) != ttbr );
 dump_pt_walk(ttbr, addr, HYP_PT_ROOT_LEVEL, 1);
 }
 
We probably don't need the CPU0 special case?

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

Re: [Xen-devel] [PATCH v3 1/3] x86/boot: Introduce the kernel_info

[Konrad Rzeszutek Wilk]

> >>> +be prefixed with header/magic and its size, e.g.:
> >>> +
> >>> +  kernel_info:
> >>> +  .ascii  "LToP"  /* Header, Linux top (structure). */
> >>> +  .long   kernel_info_var_len_data - kernel_info
> >>> +  .long   kernel_info_end - kernel_info
> >>> +  .long   0x01234567  /* Some fixed size data for the 
> >>> bootloaders. */
> >>> +  kernel_info_var_len_data:
> >>> +  example_struct: /* Some variable size data for the 
> >>> bootloaders. */
> >>> +  .ascii  "EsTT"  /* Header/Magic. */
> >>> +  .long   example_struct_end - example_struct
> >>> +  .ascii  "Struct"
> >>> +  .long   0x89012345
> >>> +  example_struct_end:
> >>> +  example_strings:/* Some variable size data for the 
> >>> bootloaders. */
> >>> +  .ascii  "EsTs"  /* Header/Magic. */
> >>
> >> Where do the Magic values "EsTT" and "EsTs" come from?
> >> where are they defined?
> > 
> > EsTT == Example STrucT
> > EsTs == Example STringS
> > 
> > Anyway, it can be anything which does not collide with existing variable
> > length data magics. There are none right now. So, it can be anything.
> > Maybe I should add something saying that.
> 
> Yes, please.

Or make it very clear they are examples, says "1234" or "ABCD" or such.

> 
> thanks.
> -- 
> ~Randy

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

Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap

[Julien Grall]

Hi,

On 10/11/19 7:06 PM, Brian Woods wrote:

On Fri, Oct 11, 2019 at 05:58:35PM +0100, Julien Grall wrote:
For that, you'd need to either check the start and end of the added
module or the start of both.  So something like:

if ( ((mod->start >= start) && (mod->start < (start + size))) ||
  ((start >= mod->start) && (start < (mod->start + mod->size))) )
 printk("WARNING: ...");

If you don't you run the risk of having a module overlap but not at the
start of the added module (unless there's a guaranteed order).  You're
still running all of the checks from what I can tell, just not in nested
for loop so. Plus I'm not sure how many times add_boot_module gets run
and the "mod->kind == kind .." if statement gets run and is true.
If the above is true, wouldn't that cause extra checks for the for loop
iterations before it was true?


For non-dom0less case, we are talking about 4 modules max (Xen, Kernel, 
Initramfs, flask policy). Modules cannot be the shared here.


For dom0less, you are unlikely to have that many domains started from 
Xen. So the number of modules will still be limited (even more if you 
share it).


This code is also only called at boot where there are bigger time 
consuming part (such as domheap initialization). So I would be surprised 
if you see any improvement (other than a couple of cycles) in boot time 
here.


Therefore, I would favor a readable solution over a micro-optimized 
solution here.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap

[Brian Woods]

On Fri, Oct 11, 2019 at 05:58:35PM +0100, Julien Grall wrote:
> Hi,
> 
> Please at least remove the signature in the e-mail you reply to. The best
> would be to trim the e-mail and answer right below the specific paragraph.
> 
> >
> >To make sure the module is going to get added, you'd need to do the
> >check after the for loop.  This means there's going to be multiple for
> >loops just spread over the course of adding the boot modules rather than
> >one place.
> 
> I don't think you need to do the check after the loop. The only way to go
> out of the loop in add_boot_module() is when i reached mods->nr_mods.

See below.

> >
> >I had this before but decided against it but after changing it to both
> >starts rather than the stand and end (ends look much uglier), it looks
> >cleaner.
> >
> > for ( i = 0 ; i < mods->nr_mods-1; i++ )
> > for ( j = i+1 ; j < mods->nr_mods; j++ )
> > if ( ((mods->module[i].start >= mods->module[j].start) &&
> >   (mods->module[i].start <=
> >mods->module[j].start + mods->module[j].size)) ||
> >  ((mods->module[j].start >= mods->module[i].start) &&
> >   (mods->module[j].start <=
> >mods->module[i].start + mods->module[i].size)) )
> > printk("WARNING: modules %-12s and %-12s overlap\n",
> >boot_module_kind_as_string(mods->module[i].kind),
> >boot_module_kind_as_string(mods->module[j].kind));
> >
> >That's also a possibility.
> >
> >I just don't see a way around it, computationally.  You can split where
> >the loops are executed but in the end the same amount of checks/total
> >iterations have to be run.
> >
> >I was talking to someone and he suggested you could just check Xen at
> >early boot and then check other modules later.
> 
> What's wrong with:
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 705a917abf..ecd09ec698 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -254,6 +254,10 @@ struct bootmodule __init
> *add_boot_module(bootmodule_kind kind,
>  mod->domU = false;
>  return mod;
>  }
> +
> +if ((mod->start >= start) &&
> +(mod->start < (start + size)))
> +printk("WARNING: modules...\n");
>  }
> 
>  mod = >module[mods->nr_mods++];
> 
> Cheers,
> 
> -- 
> Julien Grall

For that, you'd need to either check the start and end of the added
module or the start of both.  So something like:

if ( ((mod->start >= start) && (mod->start < (start + size))) ||
 ((start >= mod->start) && (start < (mod->start + mod->size))) )
printk("WARNING: ...");

If you don't you run the risk of having a module overlap but not at the
start of the added module (unless there's a guaranteed order).  You're
still running all of the checks from what I can tell, just not in nested
for loop so. Plus I'm not sure how many times add_boot_module gets run
and the "mod->kind == kind .." if statement gets run and is true.
If the above is true, wouldn't that cause extra checks for the for loop
iterations before it was true?

Brian

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

Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early

[Julien Grall]

Hi Stefano,

On 10/11/19 6:11 PM, Stefano Stabellini wrote:

This is not pretty, but I don't view this as critical to fix for Xen 4.13. So
I am thinking to defer this post 4.13.


If the issue doesn't trigger on 4.13, then I agree we shouldn't try to
fix it (badly) at this stage.

But we do have a "minus phys_offset" operation in dump_hyp_walk, I don't
follow why we wouldn't see a problem if Xen is loaded at 1MB on arm32.


I haven't said the issue cannot be triggered. I pointed out I don't view 
this as critical.


One of the reason is that I bet nobody ever run Xen below 1MB on Arm32. 
Otherwise they would have seen an error...


In other words, I am not going to plan to fix it for Xen 4.13. However, 
if someone wants to spend time on it (and have platform to test it), 
then patch are welcomed.




Xen pa: 0x10
Xen va: 0x20
phys_offset: 0xfff0

test_va: 0x202000
test_va - phys_offset = 0x00300200. But it should be 0x102000. >
Given that the problem is in a BUG_ON maybe we could remove it? Or just
rework the BUG_ON?


For arm32, dump_hyp_walk() is only called when the AT instruction fails 
to translate a physical address. You are already doing something wrong 
if you hit, so you will panic in either case. The only difference is you 
don't get the page-table dumped.


Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
140282
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 140282
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
140282
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 140282
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 140282
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 140282
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 140282
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
140282
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 140282
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 140282
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 140282
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. 
vs. 140282
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 140282
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 140282
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 140282
 test-amd64-i386-freebsd10-amd64 11 guest-start   fail REGR. vs. 140282
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 140282
 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 140282
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 140282
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. 
vs. 140282
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 140282
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 140282

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host  fail pass in 142548
 test-armhf-armhf-xl-credit1   7 xen-boot   fail pass in 142548

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit1 13 migrate-support-check fail in 142548 never pass
 test-armhf-armhf-xl-credit1 14 saverestore-support-check fail in 142548 never 
pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 140282
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 140282
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-check

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Stefano Stabellini]

On Fri, 11 Oct 2019, Lars Kurth wrote:
> On 11/10/2019, 02:24, "Stefano Stabellini"  wrote:
> 
> On Thu, 10 Oct 2019, Lars Kurth wrote:
> > * Would we ever include API docs generated from GPLv2 code? E.g. for 
> safety use-cases?
> > @Stefano, @Artem: I guess this one is for you. 
> > I suppose if we would have a similar issue for a safety manual
> > I am also assuming we would want to use sphinx docs and rst to generate 
> a future safety manual
> 
> Hi Lars,
> 
> Thanks for putting this email together.
> 
> In terms of formats, I don't have a preference between rst and pandoc,
> but if we are going to use rst going forward, I'd say to try to use rst
> for everything, including converting all the old stuff. The fewer
> different formats, the better.
> 
> I think the proposal that needs to follow on from this (which would at some
> point need to be voted on) would then be to go for rst. 
> 
> As I mentioned during the FuSa call, I agree with you, Andrew, and
> others that it would be best to have the docs under a CC license. I do
> expect that we'll end up copy/pasting snippets of in-code comments into
> the docs, so I think it is important that we are allowed to do that from
> a license perspective. It is great that GPLv2 allows it (we need to be
> sure about this).
> 
> The GPL does *not* allow this, but (c) law and fair use clauses do. So 
> typically
> stuff such as
> * Referring to function names, signatures, etc. tend to be all fine
> * Copying large portions of in-line comments would not be fine, but
> If they are large, they would in most cases be re-written in a more suitable
> language. 
> 
> So, I think overall, we should be fine. It's a bit of a grey area though.
> 
> And as you point out below, most of the code in question is typically BSD 
> 
> Yes, I expect that some docs might be automatically generated, but from
> header files, not from source code. Especailly public/ header files,
> which are typically BSD, not GPLv2. I cannot come up with examples of
> docs we need to generated from GPLv2-only code at the moment, hopefully
> there won't be any.
> 
> That makes things a lot easier.
>  
> > I wasn't planning on reusing any of the markup, and wasn't 
> expecting to
> > use much of the text either.  I'm still considering the option of
> > defining that xen/public/* isn't the canonical description of the 
> ABI,
> > because C is the wrong tool for the job.
> > 
> > Its fine to provide a C set of headers implementing an ABI, but 
> there is
> > a very deliberate reason why the canonical migration v2 spec is in a
> > text document.
> > 
> > @Stefano: as you and I believe Brian will be spending time on improving 
> the
> > ABI docs, I think we need to build some agreement here on what/how
> > to do it. I was assuming that generally the consensus was to have
> > docs close to the code in source, but this does not seem to be the case.
> > 
> > But if we do have stuff separately, ideally we would have a tool that 
> helps
> > point people editing headers to also look at the relevant docs. 
> Otherwise it will
> > be hard to keep them in sync.
> 
> In general, it is a good idea to keep the docs close to the code to make
> it easier to keep them up to date. But there is no one-size-fits-all
> here. For public ABI descriptions, I agree with Andrew that ideally they
> should not be defined as C header files.
> 
> But it is not an issue: any work that we do here won't be wasted. For
> instance, we could start by adding more comments to the current header
> files. Then, as a second step, take all the comments and turn them into
> a proper ABI description document without any C function declarations.
> It is easy to move English text around, as long as the license allows it
> -- that is the only potential blocker I can see.
> 
> This is likely to be problematic. First of all, we are talking about 
> BSD-3-Clause
> or BSD-2-Clause code (the latter is more dominant in headers I believe) in
> all known cases.
> 
> The main properties of the BSD are
> 1: Can be pretty much used anywhere for any purpose
> 2: Can be modified for any purpose 
> 3: But the original license header must be retained in derivates
> 
> Does *not* have requirements around attribution as CC-BY-4: however,
> as we store everything in git attribution is handled by us by default
> 
> CC-BY-4 also has properties 1-3
> In addition: it does require that 
> 4: Derived works are giving appropriate credit to authors 
> We could clarify in a COPYING how we prefer to do this
> 4.1: We could say that "referring to the Xen Project community" 
> is sufficient to comply with the attribution clause
> 4.2: We could require individual authors to be credited: in 

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Stefano Stabellini]

On Fri, 11 Oct 2019, Lars Kurth wrote:
> On 11/10/2019, 09:32, "Jan Beulich"  wrote:
> 
> On 10.10.2019 20:30, Lars Kurth wrote:
> > On 10/10/2019, 18:05, "Andrew Cooper"  wrote:
> > On 10/10/2019 13:34, Lars Kurth wrote:
> > > Existing formats and licenses
> > > * Hypercall ABI Documentation generated from Xen public headers
> > > Format: kerndoc
> > > License: typically BSD-3-Clause (documentation is generated from 
> public headers)
> > 
> > Its homegrown markup, superimposed on what used to be doxygen 
> in
> > the past.
> > 
> > Oh, I forgot
> > 
> > I wasn't planning on reusing any of the markup, and wasn't 
> expecting to
> > use much of the text either.  I'm still considering the option of
> > defining that xen/public/* isn't the canonical description of the 
> ABI,
> > because C is the wrong tool for the job.
> > 
> > Its fine to provide a C set of headers implementing an ABI, but 
> there is
> > a very deliberate reason why the canonical migration v2 spec is in a
> > text document.
> > 
> > @Stefano: as you and I believe Brian will be spending time on improving 
> the
> > ABI docs, I think we need to build some agreement here on what/how
> > to do it. I was assuming that generally the consensus was to have
> > docs close to the code in source, but this does not seem to be the case.
> 
> Well, for migration v2 having the spec in a text file seems sensible
> to me. For the public ABI, however, I think it's more helpful to have
> the doc next to the actual definitions. Considering the possible use
> of languages other than C I can certainly see why separating both
> would be even more clean, but I think here we want to weigh practical
> purposes against cleanliness.
> 
> I think that is an area where we need to build some consensus. The problem
> falls under what is considered "traceability" in safety speak: in other 
> words, 
> for the ABI documentation use-case it must be easy to be able to
> keep documentation and code in sync. And ideally, we would be able to
> check this automatically somehow, or have a bot provide hints such as 
> "You changed XYZ and should have a look and check whether ABC needs
> changing also".
> 
> I have thought about the problem of "traceability" for some time, which
> goes far beyond what we need for this use-case. Typical things that need
> to be maintained for a "traceable (safety) documentation set" are
> 
> ## Keeping key docs and code in sync 
> The use-cases here are things such as
> - keep man pages and xl sources in sync
> - keep ABI docs and headers in sync
> - keep documents such as the migration b2 spec in sync with
>   actual source
>  
> This is a problem we already have today and where we do this often
> fairly poorly manually (as can be seen on how out-of-date
> man pages often are)
> 
> Possible solutions for this are
> - store docs alongside headers (maybe using the same base
> file name) => that would work for ABI docs
> 
> - have some tagging or meta-information scheme which links
> specific source files to docs files => that would work for most
> other docs (albeit not always perfectly - e.g. when functionality
> is spread over many files and just portions of them)
> 
> For example: tools/xl/xl_cmdtable.c  
> is linked to files in docs/man/xl*
> 
> This means creating a bot/tool which warns that when you change
> foo.c to also look at foo.rst and/or ../../docs/.../bar.rst should be
> relatively straightforward. It would require some initial effort
> to create initial mappings, but these would never really change,
> unless we refactor code significantly.
>  
> ## Keeping dependent documents (or portions of documents) in sync
> This is something we have not really faced, because we do not
> have a lot of docs.  
> 
> In a large documentation set having the right chapter/tree
> structure enables this. In waterfall software engineering
> models, where you start off with high-level documents/
> requirements/specs/etc. documents which become
> increasingly detailed this is done through a chapter/tree
> structure, with the capability to make separate documents
> (or sections thereof) on other documents (or sections
> thereof). When you change something, a tool such as DOORS 
> forces you review and sign off child documents.
> 
> This is conceptually similar to what we would need for
> "linking" sources to docs as outlined above, only that
> the "linking" is between docs. It would also be easy enough
> to check and highlight, what else may have to be looked at.  
> 
> ## Proving that your tests verify design claims and that *all claims* are 
> tested
> This is typically the hardest problem to solve. It requires
> for test cases (be it a document or actual code) to
> link to claims (in a design, architecture, spec, ...)
> and to prove that all of them are 

Re: [Xen-devel] [XEN PATCH v1] libxl: Add DTB compatible list to config file

[Stefano Stabellini]

On Fri, 11 Oct 2019, Julien Grall wrote:
> Hi,
> 
> On 11/10/2019 16:23, Ian Jackson wrote:
> > Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to
> > config file"):
> > > From: Oleksandr Grytsov 
> > > 
> > > Some platforms need more compatible property values in device
> > > tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
> > > values that are given by Xen by default.
> 
> I am pretty sure I have seen this patch a few years ago, but I can't find it
> in my inbox. What is the exact problem here?
> 
> > > Specify in domain configuration file which values should be added
> > > by providing "dtb_compatible" list of strings separated by comas.
> > 
> > Hi, thanks.
> > 
> > I don't have an opinion about the principle of this and would like to
> > hear from ARM folks about that.
> > 
> > Also, Stefano, Julien: should we be asking for a freeze exception for
> > this for 4.13 ?
> 
> I don't have enough context to understand the exact issue he is trying to
> solve.

Same here. Is this patch needed because on some platform the OS checks
for the platform "model" (also known as "machine name") on device tree
before continuing or to trigger a difference behavior?

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

Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early

[Stefano Stabellini]

On Fri, 11 Oct 2019, Julien Grall wrote:
> On 11/10/2019 01:32, Stefano Stabellini wrote:
> > On Thu, 10 Oct 2019, Julien Grall wrote:
> > > On 08/10/2019 23:24, Stefano Stabellini wrote:
> > > > On Tue, 8 Oct 2019, Julien Grall wrote:
> > > > > On 10/8/19 1:18 AM, Stefano Stabellini wrote:
> > > > > > On Mon, 7 Oct 2019, Julien Grall wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On 03/10/2019 02:02, Stefano Stabellini wrote:
> > > > > > > > On Fri, 20 Sep 2019, Julien Grall wrote:
> > > > > > > > > That's not correct. alloc_boot_pages() is actually here to
> > > > > > > > > allow
> > > > > > > > > dynamic
> > > > > > > > > allocation before the memory subsystem (and therefore the
> > > > > > > > > runtime
> > > > > > > > > allocator)
> > > > > > > > > is initialized.
> > > > > > > > 
> > > > > > > > Let me change the question then: is the system_state ==
> > > > > > > > SYS_STATE_early_boot check strictly necessary? It looks like it
> > > > > > > > is
> > > > > > > > not:
> > > > > > > > the patch would work even if it was just:
> > > > > > > 
> > > > > > > I had a few thoughts about it. On Arm32, this only really works
> > > > > > > for
> > > > > > > 32-bits machine address (it can go up to 40-bits). I haven't
> > > > > > > really
> > > > > > > fully investigated what could go wrong, but it would be best to
> > > > > > > keep
> > > > > > > it
> > > > > > > only for early boot.
> > > > > > > 
> > > > > > > Also, I don't really want to rely on this "workaround" after boot.
> > > > > > > Maybe
> > > > > > > we would want to keep them unmapped in the future.
> > > > > > 
> > > > > > Yes, no problems, we agree on that. I am not asking in regards to
> > > > > > the
> > > > > > check system_state == SYS_STATE_early_boot with the goal of asking
> > > > > > you
> > > > > > to get rid of it. I am fine with keeping the check. (Maybe we want
> > > > > > to
> > > > > > add
> > > > > > an `unlikely()' around the check.)
> > > > > > 
> > > > > > I am trying to understand whether the code actually relies on
> > > > > > system_state == SYS_STATE_early_boot, and, if so, why. The goal is
> > > > > > to
> > > > > > make sure that if there are some limitations that they are
> > > > > > documented,
> > > > > > or just to double-check that there are no limitations.
> > > > > 
> > > > > The check is not strictly necessary.
> > > > > 
> > > > > > 
> > > > > > In regards to your comment about only working for 32-bit addresses
> > > > > > on
> > > > > > Arm32, you have a point. At least we should be careful with the mfn
> > > > > > to
> > > > > > vaddr conversion because mfn_to_maddr returns a paddr_t which is
> > > > > > 64-bit
> > > > > > and vaddr_t is 32-bit. I imagine that theoretically, even with
> > > > > > system_state == SYS_STATE_early_boot, it could get truncated with
> > > > > > the
> > > > > > wrong combination of mfn and phys_offset.
> > > > > > 
> > > > > > If nothing else, maybe we should add a truncation check for safety?
> > > > > 
> > > > > Except that phys_offset is not defined correctly, so your check below
> > > > > will
> > > > > break some setup :(. Let's take the following example:
> > > > > 
> > > > >  Xen is loaded at PA 0x10
> > > > > 
> > > > > The boot offset is computed using 32-bit address (see head.S):
> > > > >   PA - VA = 0x10 - 0x20
> > > > >   = 0xfff0
> > > > > 
> > > > > This value will be passed to C code as an unsigned long. But then we
> > > > > will
> > > > > store it in a uint64_t/paddr_t (see phys_offset which is set in
> > > > > setup_page_tables). Because this is a conversion from unsigned to
> > > > > unsigned,
> > > > > the "sign bit" will not be propagated.
> > > > > 
> > > > > This means that phys_offset will be equal to 0xfff0 and not
> > > > > 0xfff0!
> > > > > 
> > > > > Therefore if we try to convert 0x10 (where Xen has been loaded)
> > > > > back
> > > > > to
> > > > > its VA, the resulting value will be 0x00200100.
> > > > > 
> > > > > Looking at the code, I think pte_of_xenaddr() has also the exact
> > > > > problem.
> > > > > :(
> > > > 
> > > > One way to fix it would be to change phys_offset to register_t (or just
> > > > declare it as unsigned long on arm32 and unsigned long long on arm64):
> > > 
> > > sizeof (unsigned long) = 32 (resp. 64) on Arm32 (resp. arm64). This is
> > > what we
> > > already rely on for boot_phys_offset (see setup_pagetables). So I am not
> > > sure
> > > why phys_offset needs to be defined differently.
> > > 
> > > An alternative is to use vaddr_t.
> > 
> > Yes, I meant like vaddr_t or just "unsigned long" like boot_phys_offset.
> > Even with your latest patch
> > (https://marc.info/?l=xen-devel=157073004830894) which I like as a way
> > to solve the original GRUB booting issue, it looks like we also need to
> > change phys_addr to unsigned long to fix other arm32 problems.
> > 
> > Are you going to send the patch for that too?
> 
> I am looking at dropping phys_offset 

Re: [Xen-devel] [PATCH v1 1/2] libxl: introduce new backend type VINPUT

[Ian Jackson]

Oleksandr Grytsov writes ("Re: [PATCH v1 1/2] libxl: introduce new backend type 
VINPUT"):
> On Fri, Oct 11, 2019 at 5:58 PM Ian Jackson  wrote:
> > I think it was a48e00f14a2d "libxl: add backend type and id to vkb"
> > which introduced what you are calling "user space" backends.  It
> > appears that the vkb backend type enum was introduced there
> > specifically to distinguish between these two situations.  For reasons
> >
> > Am I wrong ?  If not, why is this not working or not suitable ?
> 
> You are right. It is not working in some cases due to QEMU_BACKEND macro.
> QEMU_BACKEND treats both backends as QEMU. As result xl performs device
> hotplug on add/remove device. Which is not expected in case "user
> space" backend.

Then perhaps this macro needs to be adjusted or called only
conditionally or something ?

> In this patch I propose solution similar to VUSB device. Where VUSB
> used for frontend and depends on backend (kernel or QEMU) either
> VUSB or QUSB used for backend device type e.g. use different backend
> device type for different backends.

I confess I don't quite follow all the VUSB stuff but I don't think it
is necessarily a good model.

> Introducing new backend device type for VKBD also allows to have
> both backends (QEMU and non QEMU) run in same domain. Not sure if it
> is useful scenario but with this proposal it is possible from
> technical point of view.

I don't understand why this is not possible simply by having a
different backend type.

> > I also don't understand why the "user space" kbd backend seems to be
> > "linux" in the enum.
> 
> I agree this is not so good name. But I don't know how to call
> backends which are not running
> inside QEMU in general.

I think this would be useable on freebsd ?  "linux" definitely seems
wrong.  I see it hasn't been in a release so it is not too late to
rename it, subject to discussion with Juergen as RM.

> > Where is the implementation of this user space
> > backend ?
> 
> We have extended kbd interface (kbdif.h) to support multi-touch events
> as well. And we have
> implemented own kbd backend https://github.com/xen-troops/displ_be/
> It is integrated with display backend as both use wayland API.

Great.

> > Is it be controlled entirely through xenstore ?
> 
> Yes it is controlled entirely through xenstore: lib xl creates
> frontend/backend entries with
> initial states and configuration.

And your display backend in "troops" (is that the name of your
project) checks whether the backend type is set to "linux", so that it
knows to ignore ones that say "qemu" ?

Maybe "linux" should be "troops"...

Ian.

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

Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap

[Julien Grall]

Hi,

On 10/11/19 5:43 PM, Brian Woods wrote:

On Thu, Oct 10, 2019 at 04:39:07PM +0100, Julien Grall wrote:

Hi Brian,

Thank you for the patch.

On 10/9/19 8:47 PM, Brian Woods wrote:

It's possible for a misconfigured device tree to cause Xen to crash when
there are overlapping addresses in the memory modules.  Add a warning
when printing the addresses to let the user know there's a possible
issue when DEBUG is enabled.

Signed-off-by: Brian Woods 
---
sample output:
...
(XEN) MODULE[0]: 0140 - 0153b8f1 Xen
(XEN) MODULE[1]: 076d2000 - 076dc080 Device Tree
(XEN) MODULE[2]: 076df000 - 07fff364 Ramdisk
(XEN) MODULE[3]: 0008 - 0318 Kernel
(XEN)  RESVD[0]: 076d2000 - 076dc000
(XEN)  RESVD[1]: 076df000 - 07fff364
(XEN)
(XEN) WARNING: modules Xen  and Kernel   overlap
(XEN)
(XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=1G bootscrub=0 
maxcpus=1 timer_slop=0
...

  xen/arch/arm/bootfdt.c | 17 +
  1 file changed, 17 insertions(+)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 08fb59f..3cb0c43 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -387,6 +387,23 @@ static void __init early_print_info(void)
 mem_resv->bank[j].start + mem_resv->bank[j].size - 1);
  }
  printk("\n");
+
+#ifndef NDEBUG
+/*
+ * Assuming all combinations are checked, only the starting address
+ * has to be checked if it's in another memory module's range.
+ */
+for ( i = 0 ; i < mods->nr_mods; i++ )
+for ( j = 0 ; j < mods->nr_mods; j++ )
+if ( (i != j) &&
+ (mods->module[i].start >= mods->module[j].start) &&
+ (mods->module[i].start <
+  mods->module[j].start + mods->module[j].size) )
+printk("WARNING: modules %-12s and %-12s overlap\n",
+   boot_module_kind_as_string(mods->module[i].kind),
+   boot_module_kind_as_string(mods->module[j].kind));


I am not entirely happy with the double for-loop here.

As we already go through all the modules in add_boot_module(). Could you
look whether this check could be part of it?

This should also allow to have this check for non-debug build as well.

Cheers,

--
Julien Grall


Please at least remove the signature in the e-mail you reply to. The 
best would be to trim the e-mail and answer right below the specific 
paragraph.




To make sure the module is going to get added, you'd need to do the
check after the for loop.  This means there's going to be multiple for
loops just spread over the course of adding the boot modules rather than
one place.


I don't think you need to do the check after the loop. The only way to 
go out of the loop in add_boot_module() is when i reached mods->nr_mods.




I had this before but decided against it but after changing it to both
starts rather than the stand and end (ends look much uglier), it looks
cleaner.

 for ( i = 0 ; i < mods->nr_mods-1; i++ )
 for ( j = i+1 ; j < mods->nr_mods; j++ )
 if ( ((mods->module[i].start >= mods->module[j].start) &&
   (mods->module[i].start <=
mods->module[j].start + mods->module[j].size)) ||
  ((mods->module[j].start >= mods->module[i].start) &&
   (mods->module[j].start <=
mods->module[i].start + mods->module[i].size)) )
 printk("WARNING: modules %-12s and %-12s overlap\n",
boot_module_kind_as_string(mods->module[i].kind),
boot_module_kind_as_string(mods->module[j].kind));

That's also a possibility.

I just don't see a way around it, computationally.  You can split where
the loops are executed but in the end the same amount of checks/total
iterations have to be run.

I was talking to someone and he suggested you could just check Xen at
early boot and then check other modules later.


What's wrong with:

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 705a917abf..ecd09ec698 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -254,6 +254,10 @@ struct bootmodule __init 
*add_boot_module(bootmodule_kind kind,

 mod->domU = false;
 return mod;
 }
+
+if ((mod->start >= start) &&
+(mod->start < (start + size)))
+printk("WARNING: modules...\n");
 }

 mod = >module[mods->nr_mods++];

Cheers,

--
Julien Grall

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

[Xen-devel] [XEN PATCH for-4.13 v3 06/10] libxl: Remove/deprecate libxl_get_required_*_memory from the API

[Ian Jackson]

These are now redundant because shadow_memkb and iommu_memkb are now
defaulted automatically by libxl_domain_need_memory and
libxl_domain_create etc.  Callers should not now call these; instead,
they should just let libxl take care of it.

libxl_get_required_shadow_memory was introduced in f89f555827a6
  "remove late (on-demand) construction of IOMMU page tables"
We can freely remove it because it was never in any release.

libxl_get_required_shadow_memory has been in libxl approximately
forever.  It should probably not have survived the creation of
libxl_domain_create, but it seems the API awkwardnesses we see in
recent commits prevented this.  So we have to keep it.  It remains
functional but we can deprecate it.  Hopefully we can get rid of it
completely before we find the need to change the calculation to use
additional information which its arguments do not currently supply.

Signed-off-by: Ian Jackson 
Acked-by: Anthony PERARD 
---
 tools/libxl/libxl_create.c | 17 -
 tools/libxl/libxl_utils.c  | 15 ---
 tools/libxl/libxl_utils.h  |  2 +-
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a1b00a8aef..b394312d98 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -888,6 +888,21 @@ static bool ok_to_default_memkb_in_create(libxl__gc *gc)
  */
 }
 
+static unsigned long libxl__get_required_iommu_memory(unsigned long maxmem_kb)
+{
+unsigned long iommu_pages = 0, mem_pages = maxmem_kb / 4;
+unsigned int level;
+
+/* Assume a 4 level page table with 512 entries per level */
+for (level = 0; level < 4; level++)
+{
+mem_pages = DIV_ROUNDUP(mem_pages, 512);
+iommu_pages += mem_pages;
+}
+
+return iommu_pages * 4;
+}
+
 int libxl__domain_config_setdefault(libxl__gc *gc,
 libxl_domain_config *d_config,
 uint32_t domid)
@@ -1011,7 +1026,7 @@ int libxl__domain_config_setdefault(libxl__gc *gc,
 && ok_to_default_memkb_in_create(gc))
 d_config->b_info.iommu_memkb =
 (d_config->c_info.passthrough == LIBXL_PASSTHROUGH_SYNC_PT)
-? libxl_get_required_iommu_memory(d_config->b_info.max_memkb)
+? libxl__get_required_iommu_memory(d_config->b_info.max_memkb)
 : 0;
 
 ret = libxl__domain_build_info_setdefault(gc, _config->b_info);
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 405733b7e1..f360f5e228 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -48,21 +48,6 @@ unsigned long libxl_get_required_shadow_memory(unsigned long 
maxmem_kb, unsigned
 return 4 * (256 * smp_cpus + 2 * (maxmem_kb / 1024));
 }
 
-unsigned long libxl_get_required_iommu_memory(unsigned long maxmem_kb)
-{
-unsigned long iommu_pages = 0, mem_pages = maxmem_kb / 4;
-unsigned int level;
-
-/* Assume a 4 level page table with 512 entries per level */
-for (level = 0; level < 4; level++)
-{
-mem_pages = DIV_ROUNDUP(mem_pages, 512);
-iommu_pages += mem_pages;
-}
-
-return iommu_pages * 4;
-}
-
 char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid)
 {
 unsigned int len;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 630ccbe28a..46918aea84 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -24,7 +24,7 @@ const
 char *libxl_basename(const char *name); /* returns string from strdup */
 
 unsigned long libxl_get_required_shadow_memory(unsigned long maxmem_kb, 
unsigned int smp_cpus);
-unsigned long libxl_get_required_iommu_memory(unsigned long maxmem_kb);
+  /* deprecated; see LIBXL_HAVE_DOMAIN_NEED_MEMORY_CONFIG in libxl.h */
 int libxl_name_to_domid(libxl_ctx *ctx, const char *name, uint32_t *domid);
 int libxl_domain_qualifier_to_domid(libxl_ctx *ctx, const char *name, uint32_t 
*domid);
 char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid);
-- 
2.11.0


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

[Xen-devel] [XEN PATCH for-4.13 v3 09/10] libxl: Move domain_create_info_setdefault earlier

[Ian Jackson]

We need this before we start to figure out the passthrough mode.

I have checked that nothing in libxl__domain_create_info_setdefault
nor the two implementations of ..._arch_... accesses anything else,
other than (i) the domain type (which this function is responsible for
setting and nothing before it looks at) (ii) c_info->ssidref (which is
defaulted by flask code near the top of
libxl__domain_config_setdefault and not accessed afterwards).

So no functional change.

Signed-off-by: Ian Jackson 
---
v3: New patch in this version of the series.
---
 tools/libxl/libxl_create.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 69971c97b6..3d2cb52bf7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -968,6 +968,13 @@ int libxl__domain_config_setdefault(libxl__gc *gc,
 goto error_out;
 }
 
+ret = libxl__domain_create_info_setdefault(gc, _config->c_info,
+   );
+if (ret) {
+LOGD(ERROR, domid, "Unable to set domain create info defaults");
+goto error_out;
+}
+
 /* If target_memkb is smaller than max_memkb, the subsequent call
  * to libxc when building HVM domain will enable PoD mode.
  */
@@ -1007,13 +1014,6 @@ int libxl__domain_config_setdefault(libxl__gc *gc,
 goto error_out;
 }
 
-ret = libxl__domain_create_info_setdefault(gc, _config->c_info,
-   );
-if (ret) {
-LOGD(ERROR, domid, "Unable to set domain create info defaults");
-goto error_out;
-}
-
 if (d_config->b_info.shadow_memkb == LIBXL_MEMKB_DEFAULT
 && ok_to_default_memkb_in_create(gc))
 d_config->b_info.shadow_memkb =
-- 
2.11.0


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

[Xen-devel] [XEN PATCH for-4.13 v3 00/10] libxl memkb & pt defaulting

[Ian Jackson]

This is v3 of my series to sort out the shadow/iommu memory and pci
passthrough situation.  It is also available here:
   https://xenbits.xen.org/gitweb/?p=people/iwj/xen.git;a=summary
   wip.libxl-memkb-ptcfg.v3

Thanks to Andrew Cooper and Julien Grall for comments about the PT
mode setting, which I think I have taken into account.

 #a  01 libxl: Offer API versions 0x040700 and 0x040800
 #r  02 xl: Pass libxl_domain_config to freemem(), instead of b_info
 #r  03 libxl: libxl__domain_config_setdefault: New function
 #r  04 libxl: libxl_domain_need_memory: Make it take a domain_config
 05 libxl: Move shadow_memkb and iommu_memkb defaulting into libxl
  a  06 libxl: Remove/deprecate libxl_get_required_*_memory from the API
  a  07 libxl: create: setdefault: Make libxl_physinfo info[1]
  a  08 libxl: create: setdefault: Move physinfo into config_setdefault
   + 09 libxl: Move domain_create_info_setdefault earlier
   * 10 libxl/xl: Overhaul passthrough setting logic

 # = not actually reposted so as to shrink the patchbomb;
  unchanged from previous posting
 a = acked; r = reviewed
 * = patch changed; m = message changed; + = new patch

 docs/man/xl.cfg.5.pod.in |   6 ++
 tools/libxl/libxl.h  |  24 ++-
 tools/libxl/libxl_arch.h |   6 ++
 tools/libxl/libxl_arm.c  |  24 +++
 tools/libxl/libxl_create.c   | 168 ---
 tools/libxl/libxl_dm.c   |   7 +-
 tools/libxl/libxl_dom.c  |   7 +-
 tools/libxl/libxl_internal.h |  13 +++-
 tools/libxl/libxl_mem.c  |  69 ++
 tools/libxl/libxl_types.idl  |   7 +-
 tools/libxl/libxl_utils.c|  15 
 tools/libxl/libxl_utils.h|   2 +-
 tools/libxl/libxl_x86.c  |  41 +++
 tools/xl/xl_parse.c  |  82 ++---
 tools/xl/xl_vmcontrol.c  |   6 +-
 15 files changed, 321 insertions(+), 156 deletions(-)

-- 
2.11.0


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

[Xen-devel] [XEN PATCH for-4.13 v3 05/10] libxl: Move shadow_memkb and iommu_memkb defaulting into libxl

[Ian Jackson]

Defaulting is supposed to be done by libxl.  So these calculations
should be here in libxl.  libxl__domain_config_setdefault has all the
necessary information including the values of max_memkb and max_vcpus.

The overall functional effect depends on the caller:

For xl, no change.  The code moves from xl to libxl.

For callers who set one or both shadow_memkb and iommu_memkb (whether
from libxl_get_required_shadow_memory or otherwise) before calling
libxl_domain_need_memory (any version): the new code will leave their
setting(s) unchanged.

For callers who do not call libxl_domain_need_memory at all, and who
fail to set one of these memory values: now they are both are properly
set.  The shadow and iommu memory to be properly accounted for as
intended.

For callers which call libxl_domain_need_memory and request the
current API (4.13) or which track libxl, the default values are also
now right and everything works as intended.

For callers which call libxl_domain_need_memory, and request an old
pre-4.13 libxl API, and which leave one of these memkb settings unset,
we take special measures to preserve the old behaviour.

This means that they don't get the additional iommu memory and are at
risk of the domain running out of memory as a result of f89f555827a6
"remove late (on-demand) construction of IOMMU page tables".  But this
is no worse than the state just after f89f555827a6, which already
broke such callers in that way.  This is perhaps justifiable because
of the API stability warning next to libxl_domain_need_memory.

An alternative would be to drop the special-casing of these callers.
That would cause a discrepancy between libxl_domain_need_memory and
libxl_domain_create: the former would not include the iommu memory and
the latter would.  That seems worse, but it's debateable.

Signed-off-by: Ian Jackson 
---
v2: Replace _Bool with bool
Fix logic sense in ok_to_default_memkb_in_create
---
 tools/libxl/libxl_create.c   | 40 
 tools/libxl/libxl_internal.h |  3 +++
 tools/libxl/libxl_mem.c  |  4 
 tools/xl/xl_parse.c  | 15 ++-
 4 files changed, 49 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index fd8bb22be9..a1b00a8aef 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -250,6 +250,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 switch (b_info->type) {
 case LIBXL_DOMAIN_TYPE_HVM:
 if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+/* Normally defaulted in libxl__domain_create_info_setdefault */
 b_info->shadow_memkb = 0;
 if (b_info->u.hvm.mmio_hole_memkb == LIBXL_MEMKB_DEFAULT)
 b_info->u.hvm.mmio_hole_memkb = 0;
@@ -395,6 +396,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
 b_info->video_memkb = 0;
 if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
+/* Normally defaulted in libxl__domain_create_info_setdefault */
 b_info->shadow_memkb = 0;
 if (b_info->u.pv.slack_memkb == LIBXL_MEMKB_DEFAULT)
 b_info->u.pv.slack_memkb = 0;
@@ -862,6 +864,30 @@ static void domcreate_destruction_cb(libxl__egc *egc,
  libxl__domain_destroy_state *dds,
  int rc);
 
+static bool ok_to_default_memkb_in_create(libxl__gc *gc)
+{
+/*
+ * This is a fudge.  We are trying to find whether the caller
+ * calls the old version of libxl_domain_need_memory.  If they do
+ * then, because it only gets the b_info, and because it can't
+ * update the b_info (because it's const), it will base its
+ * calculations on defaulting shadow_memkb and iommu_memkb to 0
+ * In that case we probably shouldn't default them differently
+ * during libxl_domain_create.
+ *
+ * The result is that the behaviour with old callers is the same
+ * as in 4.13: no additional memory is allocated for shadow and
+ * iommu (unless the caller set shadow_memkb, eg from a call to
+ * libxl_get_required_shadow_memory).
+ */
+return !CTX->libxl_domain_need_memory_0x041200_called ||
+CTX->libxl_domain_need_memory_called;
+/*
+ * Treat mixed callers as new callers.  Presumably they know what
+ * they are doing.
+ */
+}
+
 int libxl__domain_config_setdefault(libxl__gc *gc,
 libxl_domain_config *d_config,
 uint32_t domid)
@@ -974,6 +1000,20 @@ int libxl__domain_config_setdefault(libxl__gc *gc,
 goto error_out;
 }
 
+if (d_config->b_info.shadow_memkb == LIBXL_MEMKB_DEFAULT
+&& ok_to_default_memkb_in_create(gc))
+d_config->b_info.shadow_memkb =
+libxl_get_required_shadow_memory(d_config->b_info.max_memkb,
+ 

[Xen-devel] [XEN PATCH for-4.13 v3 10/10] libxl/xl: Overhaul passthrough setting logic

[Ian Jackson]

LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
version of this code) is doing double duty.  We actually need all of
the following to be specificable:
  * default ("unspecified"): enable PT iff we have devices to
pass through specified in the initial config file.
  * "enabled" (and fail if the platform doesn't support it).
  * "disabled" (and reject future PT hotplug).
  * "share_pt"/"sync_pt": enable PT and set a specific PT mode.

Defaulting and error checking should be done in libxl.  So, we make
several changes here.

We introduce "enabled".  (And we document "unspecified".)

We move all of the error checking and defaulting code from xl into
libxl.  Now, libxl__domain_config_setdefault has all of the necessary
information to get this right.  So we can do it all there.  Choosing
the specific mode is arch-specific.

We can also arrange to have only one place each which calculates
(i) whether passthrough needs to be enabled because pt devices were
specified (ii) whether pt_share can be used (for each arch).

xl now only has to parse the enum in the same way as it parses all
other enums.

This change fixes a regression from earlier 4.13-pre: until recent
changes, passthrough was only enabled by default if passthrough
devices were specified.  We restore this behaviour.

Signed-off-by: Ian Jackson 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Andrew Cooper 
CC: Paul Durrant 
CC: Jan Beulich 

---
v3: Drop paragraph about masking another osstest regression,
 as that's now fixed.
Drop redundant "ERROR:" in two log messages.
Add a comment about the way "enabled" gets changed to a specific value.
Split passthrough mode defaulting into arch specific functions.
On ARM, always choose (and insist on) share_pt.
Reject share_pt for non-HAP guests.
Reject passthrough for PVH guests.
Actually document "unspecified" option in xl.cfg(5)
Rename "unknown" to "unspecified"

v2: New patch in this version of the series.
---
 docs/man/xl.cfg.5.pod.in|  6 
 tools/libxl/libxl_arch.h|  6 
 tools/libxl/libxl_arm.c | 24 
 tools/libxl/libxl_create.c  | 43 -
 tools/libxl/libxl_types.idl |  7 +++--
 tools/libxl/libxl_x86.c | 41 +++
 tools/xl/xl_parse.c | 67 -
 7 files changed, 116 insertions(+), 78 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 64bed30bce..7e220d0c20 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -660,6 +660,12 @@ in preference. However, the availability of this option is 
hardware
 specific. If B reports B containing
 B then this option may be used.
 
+=item B
+
+The default, which chooses between B and B
+according to whether passthrough devices are enabled in the config
+file.
+
 =back
 
 =back
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index d624159e53..ee6641b3e6 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -73,6 +73,12 @@ void libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
   libxl_domain_build_info *b_info);
 
 _hidden
+int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
+uint32_t domid,
+libxl_domain_config *d_config,
+const libxl_physinfo *physinfo);
+
+_hidden
 int libxl__arch_extra_memory(libxl__gc *gc,
  const libxl_domain_build_info *info,
  uint64_t *out);
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index bf31b9b3ca..2f1ca69431 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1191,6 +1191,30 @@ void libxl__arch_domain_build_info_setdefault(libxl__gc 
*gc,
 libxl_domain_build_info_init_type(b_info, LIBXL_DOMAIN_TYPE_PVH);
 }
 
+int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
+uint32_t domid,
+libxl_domain_config *d_config,
+const libxl_physinfo *physinfo)
+{
+int rc;
+libxl_domain_create_info *const c_info = _config->c_info;
+
+if (c_info->passthrough == LIBXL_PASSTHROUGH_ENABLED) {
+c_info->passthrough = LIBXL_PASSTHROUGH_SHARE_PT;
+}
+
+if (c_info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT) {
+LOGD(ERROR, domid,
+ "passthrough=\"sync_pt\" not supported on ARM\n");
+rc = ERROR_INVAL;
+goto out;
+}
+
+rc = 0;
+ out:
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3d2cb52bf7..bcf4896df6 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -57,18 +57,6 @@ int 

[Xen-devel] [XEN PATCH for-4.13 v3 08/10] libxl: create: setdefault: Move physinfo into config_setdefault

[Ian Jackson]

No functional change.  This will let us refer to it in code we are
about to add to this function.

Signed-off-by: Ian Jackson 
Acked-by: Wei Liu 
---
v2: New patch in this version of the series.
---
 tools/libxl/libxl_create.c   | 17 -
 tools/libxl/libxl_dm.c   |  7 ++-
 tools/libxl/libxl_internal.h |  3 ++-
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 9c56a914ca..69971c97b6 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -28,15 +28,9 @@
 #include 
 
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
- libxl_domain_create_info *c_info)
+ libxl_domain_create_info *c_info,
+ const libxl_physinfo *info)
 {
-libxl_physinfo info[1];
-int rc;
-
-rc = libxl_get_physinfo(CTX, info);
-if (rc)
-return rc;
-
 if (!c_info->type) {
 LOG(ERROR, "domain type unspecified");
 return ERROR_INVAL;
@@ -911,6 +905,10 @@ int libxl__domain_config_setdefault(libxl__gc *gc,
 int ret;
 bool pod_enabled = false;
 
+libxl_physinfo physinfo;
+ret = libxl_get_physinfo(CTX, );
+if (ret) goto error_out;
+
 if (d_config->c_info.ssid_label) {
 char *s = d_config->c_info.ssid_label;
 ret = libxl_flask_context_to_sid(ctx, s, strlen(s),
@@ -1009,7 +1007,8 @@ int libxl__domain_config_setdefault(libxl__gc *gc,
 goto error_out;
 }
 
-ret = libxl__domain_create_info_setdefault(gc, _config->c_info);
+ret = libxl__domain_create_info_setdefault(gc, _config->c_info,
+   );
 if (ret) {
 LOGD(ERROR, domid, "Unable to set domain create info defaults");
 goto error_out;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index c00356a2f1..e6a48974f8 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2167,7 +2167,12 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
libxl__stub_dm_spawn_state *sdss)
 dm_config->c_info.run_hotplug_scripts =
 guest_config->c_info.run_hotplug_scripts;
 
-ret = libxl__domain_create_info_setdefault(gc, _config->c_info);
+libxl_physinfo physinfo;
+ret = libxl_get_physinfo(CTX, );
+if (ret) goto out;
+
+ret = libxl__domain_create_info_setdefault(gc, _config->c_info,
+   );
 if (ret) goto out;
 ret = libxl__domain_build_info_setdefault(gc, _config->b_info);
 if (ret) goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0185b8ff01..6a614658c2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1447,7 +1447,8 @@ _hidden int libxl__domain_config_setdefault(libxl__gc *gc,
 libxl_domain_config *d_config,
 uint32_t domid /* logging only */);
 _hidden int libxl__domain_create_info_setdefault(libxl__gc *gc,
-libxl_domain_create_info *c_info);
+libxl_domain_create_info *c_info,
+const libxl_physinfo *info);
 _hidden int libxl__domain_build_info_setdefault(libxl__gc *gc,
 libxl_domain_build_info *b_info);
 _hidden void libxl__rdm_setdefault(libxl__gc *gc,
-- 
2.11.0


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

[Xen-devel] [XEN PATCH for-4.13 v3 07/10] libxl: create: setdefault: Make libxl_physinfo info[1]

[Ian Jackson]

No functional change.  This will let us make it into a pointer without
textual change other than to the definition.

While we are here, fix some style errors (missing { }).

Signed-off-by: Ian Jackson 
Acked-by: Wei Liu 
---
v2: New patch in this version of the series.
---
 tools/libxl/libxl_create.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b394312d98..9c56a914ca 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -30,10 +30,10 @@
 int libxl__domain_create_info_setdefault(libxl__gc *gc,
  libxl_domain_create_info *c_info)
 {
-libxl_physinfo info;
+libxl_physinfo info[1];
 int rc;
 
-rc = libxl_get_physinfo(CTX, );
+rc = libxl_get_physinfo(CTX, info);
 if (rc)
 return rc;
 
@@ -45,11 +45,11 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
 libxl__arch_domain_create_info_setdefault(gc, c_info);
 
 if (c_info->type != LIBXL_DOMAIN_TYPE_PV) {
-if (info.cap_hap)
+if (info->cap_hap) {
 libxl_defbool_setdefault(_info->hap, true);
-else if (info.cap_shadow)
+} else if (info->cap_shadow) {
 libxl_defbool_setdefault(_info->hap, false);
-else {
+} else {
 LOG(ERROR, "neither hap nor shadow paging available");
 return ERROR_INVAL;
 }
@@ -63,12 +63,12 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
 if (!c_info->ssidref)
 c_info->ssidref = SECINITSID_DOMU;
 
-if (info.cap_hvm_directio &&
+if (info->cap_hvm_directio &&
 (c_info->passthrough == LIBXL_PASSTHROUGH_UNKNOWN)) {
 c_info->passthrough = ((c_info->type == LIBXL_DOMAIN_TYPE_PV) ||
-   !info.cap_iommu_hap_pt_share) ?
+   !info->cap_iommu_hap_pt_share) ?
 LIBXL_PASSTHROUGH_SYNC_PT : LIBXL_PASSTHROUGH_SHARE_PT;
-} else if (!info.cap_hvm_directio) {
+} else if (!info->cap_hvm_directio) {
 c_info->passthrough = LIBXL_PASSTHROUGH_DISABLED;
 }
 
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap

[Brian Woods]

On Thu, Oct 10, 2019 at 04:39:07PM +0100, Julien Grall wrote:
> Hi Brian,
> 
> Thank you for the patch.
> 
> On 10/9/19 8:47 PM, Brian Woods wrote:
> >It's possible for a misconfigured device tree to cause Xen to crash when
> >there are overlapping addresses in the memory modules.  Add a warning
> >when printing the addresses to let the user know there's a possible
> >issue when DEBUG is enabled.
> >
> >Signed-off-by: Brian Woods 
> >---
> >sample output:
> >...
> >(XEN) MODULE[0]: 0140 - 0153b8f1 Xen
> >(XEN) MODULE[1]: 076d2000 - 076dc080 Device Tree
> >(XEN) MODULE[2]: 076df000 - 07fff364 Ramdisk
> >(XEN) MODULE[3]: 0008 - 0318 Kernel
> >(XEN)  RESVD[0]: 076d2000 - 076dc000
> >(XEN)  RESVD[1]: 076df000 - 07fff364
> >(XEN)
> >(XEN) WARNING: modules Xen  and Kernel   overlap
> >(XEN)
> >(XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=1G bootscrub=0 
> >maxcpus=1 timer_slop=0
> >...
> >
> >  xen/arch/arm/bootfdt.c | 17 +
> >  1 file changed, 17 insertions(+)
> >
> >diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> >index 08fb59f..3cb0c43 100644
> >--- a/xen/arch/arm/bootfdt.c
> >+++ b/xen/arch/arm/bootfdt.c
> >@@ -387,6 +387,23 @@ static void __init early_print_info(void)
> > mem_resv->bank[j].start + mem_resv->bank[j].size - 1);
> >  }
> >  printk("\n");
> >+
> >+#ifndef NDEBUG
> >+/*
> >+ * Assuming all combinations are checked, only the starting address
> >+ * has to be checked if it's in another memory module's range.
> >+ */
> >+for ( i = 0 ; i < mods->nr_mods; i++ )
> >+for ( j = 0 ; j < mods->nr_mods; j++ )
> >+if ( (i != j) &&
> >+ (mods->module[i].start >= mods->module[j].start) &&
> >+ (mods->module[i].start <
> >+  mods->module[j].start + mods->module[j].size) )
> >+printk("WARNING: modules %-12s and %-12s overlap\n",
> >+   boot_module_kind_as_string(mods->module[i].kind),
> >+   boot_module_kind_as_string(mods->module[j].kind));
> 
> I am not entirely happy with the double for-loop here.
> 
> As we already go through all the modules in add_boot_module(). Could you
> look whether this check could be part of it?
> 
> This should also allow to have this check for non-debug build as well.
> 
> Cheers,
> 
> -- 
> Julien Grall

To make sure the module is going to get added, you'd need to do the
check after the for loop.  This means there's going to be multiple for
loops just spread over the course of adding the boot modules rather than
one place.

I had this before but decided against it but after changing it to both
starts rather than the stand and end (ends look much uglier), it looks
cleaner.

for ( i = 0 ; i < mods->nr_mods-1; i++ )
for ( j = i+1 ; j < mods->nr_mods; j++ )
if ( ((mods->module[i].start >= mods->module[j].start) &&
  (mods->module[i].start <=
   mods->module[j].start + mods->module[j].size)) ||
 ((mods->module[j].start >= mods->module[i].start) &&
  (mods->module[j].start <=
   mods->module[i].start + mods->module[i].size)) )
printk("WARNING: modules %-12s and %-12s overlap\n",
   boot_module_kind_as_string(mods->module[i].kind),
   boot_module_kind_as_string(mods->module[j].kind));

That's also a possibility.

I just don't see a way around it, computationally.  You can split where
the loops are executed but in the end the same amount of checks/total
iterations have to be run.

I was talking to someone and he suggested you could just check Xen at
early boot and then check other modules later.

-- 
Brian Woods

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

Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic

[Ian Jackson]

Jürgen Groß writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: 
Overhaul passthrough setting logic"):
> On 11.10.19 15:31, Ian Jackson wrote:
> > I do not have a strong opinion about this.  I would be happy with
> > "auto" (or "default" maybe).
> 
> "unspecified"?

That is IMO the best suggestion so far so I will go with that in my
v3.

Ian.

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

[Xen-devel] [freebsd-master test] 142595: regressions - trouble: blocked/fail

[osstest service owner]

flight 142595 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142595/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-freebsd   7 freebsd-buildfail REGR. vs. 141501

Tests which did not succeed, but are not blocking:
 build-amd64-freebsd-again 1 build-check(1)   blocked  n/a
 build-amd64-xen-freebsd   1 build-check(1)   blocked  n/a

version targeted for testing:
 freebsd  917384c7c5eb6b436f81bb86d2ed81f91bb3883f
baseline version:
 freebsd  14aef6dfca96006e52b8fb920bde7c612ba58b79

Last test of basis   141501  2019-09-20 09:19:51 Z   21 days
Failing since141701  2019-09-23 09:19:41 Z   18 days8 attempts
Testing same since   142595  2019-10-11 09:32:36 Z0 days1 attempts


People who touched revisions under test:
  0mp <0...@freebsd.org>
  alc 
  allanjude 
  ambrisko 
  andrew 
  asomers 
  avg 
  bapt 
  br 
  brooks 
  cem 
  cperciva 
  cy 
  dab 
  daichi 
  dchagin 
  dim 
  dougm 
  emaste 
  erj 
  gallatin 
  gjb 
  glebius 
  gonzo 
  grembo 
  hrs 
  hselasky 
  ian 
  imp 
  jhb 
  jhibbits 
  jilles 
  jkim 
  jlh 
  jmg 
  jtl 
  kaktus 
  kan 
  karels 
  kevans 
  kib 
  lwhsu 
  manu 
  markj 
  mav 
  mckusick 
  mhorne 
  mjg 
  mm 
  mmacy 
  olivier 
  oshogbo 
  Piotr Pietruszewski 
  ray 
  rmacklem 
  royger 
  rrs 
  rstone 
  schweikh 
  sef 
  sjg 
  tijl 
  trasz 
  tsoome 
  tuexen 
  vangyzen 
  vmaffione 
  yuripv 

jobs:
 build-amd64-freebsd-againblocked 
 build-amd64-freebsd  fail
 build-amd64-xen-freebsd  blocked 



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

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

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

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


Not pushing.

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

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

[Xen-devel] [RFC v5 031/126] xen: introduce ERRP_AUTO_PROPAGATE

[Vladimir Sementsov-Ogievskiy]

If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == _err
(the program will exit prior to the error_append_hint() or
error_prepend() call).  Fix such cases.

If we want to check error after errp-function call, we need to
introduce local_err and than propagate it to errp. Instead, use
ERRP_AUTO_PROPAGATE macro, benefits are:
1. No need of explicit error_propagate call
2. No need of explicit local_err variable: use errp directly
3. ERRP_AUTO_PROPAGATE leaves errp as is if it's not NULL or
   _fatel, this means that we don't break error_abort
   (we'll abort on error_set, not on error_propagate)

This commit (together with its neighbors) was generated by

for f in $(git grep -l errp \*.[ch]); do \
spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
--macro-file scripts/cocci-macro-file.h --in-place --no-show-diff $f; \
done;

then fix a bit of compilation problems: coccinelle for some reason
leaves several
f() {
...
goto out;
...
out:
}
patterns, with "out:" at function end.

then
./python/commit-per-subsystem.py MAINTAINERS "$(< auto-msg)"

(auto-msg was a file with this commit message)

Still, for backporting it may be more comfortable to use only the first
command and then do one huge commit.

Reported-by: Kevin Wolf 
Reported-by: Greg Kurz 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 hw/block/dataplane/xen-block.c |  17 ++---
 hw/block/xen-block.c   | 119 ++---
 hw/xen/xen-backend.c   |   7 +-
 hw/xen/xen-bus.c   |  92 -
 hw/xen/xen-host-pci-device.c   |  27 
 hw/xen/xen_pt.c|  25 +++
 hw/xen/xen_pt_config_init.c|  20 +++---
 7 files changed, 139 insertions(+), 168 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 3b9caeb2fa..c38e3c3d85 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -727,8 +727,8 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane,
unsigned int protocol,
Error **errp)
 {
+ERRP_AUTO_PROPAGATE();
 XenDevice *xendev = dataplane->xendev;
-Error *local_err = NULL;
 unsigned int ring_size;
 unsigned int i;
 
@@ -764,9 +764,8 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane,
 }
 
 xen_device_set_max_grant_refs(xendev, dataplane->nr_ring_ref,
-  _err);
-if (local_err) {
-error_propagate(errp, local_err);
+  errp);
+if (*errp) {
 goto stop;
 }
 
@@ -774,9 +773,8 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane,
   dataplane->ring_ref,
   dataplane->nr_ring_ref,
   PROT_READ | PROT_WRITE,
-  _err);
-if (local_err) {
-error_propagate(errp, local_err);
+  errp);
+if (*errp) {
 goto stop;
 }
 
@@ -809,9 +807,8 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane,
 dataplane->event_channel =
 xen_device_bind_event_channel(xendev, dataplane->ctx, event_channel,
   xen_block_dataplane_event, dataplane,
-  _err);
-if (local_err) {
-error_propagate(errp, local_err);
+  errp);
+if (*errp) {
 goto stop;
 }
 
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 879fc310a4..8f4165edd9 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -194,6 +194,7 @@ static const BlockDevOps xen_block_dev_ops = {
 
 static void xen_block_realize(XenDevice *xendev, Error **errp)
 {
+ERRP_AUTO_PROPAGATE();
 XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
 XenBlockDeviceClass *blockdev_class =
 XEN_BLOCK_DEVICE_GET_CLASS(xendev);
@@ -201,7 +202,6 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 XenBlockVdev *vdev = >props.vdev;
 BlockConf *conf = >props.conf;
 BlockBackend *blk = conf->blk;
-Error *local_err = NULL;
 
 if (vdev->type == XEN_BLOCK_VDEV_TYPE_INVALID) {
 error_setg(errp, "vdev property not set");
@@ -211,9 +211,8 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 trace_xen_block_realize(type, vdev->disk, vdev->partition);
 
 if (blockdev_class->realize) {
-blockdev_class->realize(blockdev, _err);
-if (local_err) {
-error_propagate(errp, local_err);
+blockdev_class->realize(blockdev, errp);
+if (*errp) {
 return;
 }
 }
@@ -283,8 +282,8 @@ static void 

Re: [Xen-devel] [XEN PATCH v1] libxl: Add DTB compatible list to config file

[Julien Grall]

Hi,

On 11/10/2019 16:23, Ian Jackson wrote:

Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to config 
file"):

From: Oleksandr Grytsov 

Some platforms need more compatible property values in device
tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
values that are given by Xen by default.


I am pretty sure I have seen this patch a few years ago, but I can't find it in 
my inbox. What is the exact problem here?



Specify in domain configuration file which values should be added
by providing "dtb_compatible" list of strings separated by comas.


Hi, thanks.

I don't have an opinion about the principle of this and would like to
hear from ARM folks about that.

Also, Stefano, Julien: should we be asking for a freeze exception for
this for 4.13 ?


I don't have enough context to understand the exact issue he is trying to solve.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 1/2] libxl: introduce new backend type VINPUT

[Oleksandr Grytsov]

On Fri, Oct 11, 2019 at 5:58 PM Ian Jackson  wrote:
>
> Oleksandr Grytsov writes ("[PATCH v1 1/2] libxl: introduce new backend type 
> VINPUT"):
> > From: Oleksandr Grytsov 
> >
> > There are two kind of VKBD devices: with QEMU backend and user space
> > backend. In current implementation they can't be distinguished as both use
> > VKBD backend type. As result, user space KBD backend is started and
> > stopped as QEMU backend. This commit adds new device kind VINPUT to be
> > used as backend type for user space KBD backend.
>
> I find this confusing.  I'm not sure this change is right.  But I'm
> afraid the original patches in this area passed me by so I don't know
> much about it.
>
> I think it was a48e00f14a2d "libxl: add backend type and id to vkb"
> which introduced what you are calling "user space" backends.  It
> appears that the vkb backend type enum was introduced there
> specifically to distinguish between these two situations.  For reasons
>
> Am I wrong ?  If not, why is this not working or not suitable ?

You are right. It is not working in some cases due to QEMU_BACKEND macro.
QEMU_BACKEND treats both backends as QEMU. As result xl performs device
hotplug on add/remove device. Which is not expected in case "user
space" backend.

In this patch I propose solution similar to VUSB device. Where VUSB
used for frontend
and depends on backend (kernel or QEMU) either VUSB or QUSB used for backend
device type e.g. use different backend device type for different
backends. It would be
more clear if, for example, QEMU backend has QKBD name and all other
VKBD. But it
would require changes on QEMU side too. That's why I've chosen VINPUT name.

Introducing new backend device type for VKBD also allows to have both backends
(QEMU and non QEMU) run in same domain. Not sure if it is useful
scenario but with
this proposal it is possible from technical point of view.

>
> I also don't understand why the "user space" kbd backend seems to be
> "linux" in the enum.

I agree this is not so good name. But I don't know how to call
backends which are not running
inside QEMU in general.

> Where is the implementation of this user space
> backend ?

We have extended kbd interface (kbdif.h) to support multi-touch events
as well. And we have
implemented own kbd backend https://github.com/xen-troops/displ_be/
It is integrated with display backend as both use wayland API.

> Is it be controlled entirely through xenstore ?

Yes it is controlled entirely through xenstore: lib xl creates
frontend/backend entries with
initial states and configuration.

> Ian.

-- 
Best Regards,
Oleksandr Grytsov.

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

Re: [Xen-devel] [PATCH v1 2/2] libxl: add removing XS backend path for PV devices on domain destroy

[Ian Jackson]

Roger Pau Monne writes ("Re: [PATCH v1 2/2] libxl: add removing XS backend path 
for PV devices on domain destroy"):
> When this code was added (devd) those where the only backends handled
> by libxl. VDISPL, VSND, VINPUT didn't exist at that point, so I think
> the issue is that when support for those was added, it wasn't properly
> wired into devd.
> 
> > I think:
> > 
> > >  switch(ddev->dev->backend_kind) {
> > > +case LIBXL__DEVICE_KIND_VDISPL:
> > > +case LIBXL__DEVICE_KIND_VSND:
> > > +case LIBXL__DEVICE_KIND_VINPUT:
> > >  case LIBXL__DEVICE_KIND_VBD:
> > >  case LIBXL__DEVICE_KIND_VIF:
> > 
> > If we do want this to handle *all* kinds of device, maybe it should
> > have a fallback that aborts, or something ?  (I don't think it is
> > easy to make it a compile error to forget to add an entry here but if
> > we could do that it would probably be best.)
> 
> Maybe we could have some generic handling for everything != qdisk?

So make that the "default:" ?  That would be fine by me.

> IIRC qdisk needs special handling so that devd can launch and destroy
> a QEMU instance when required, but other backends that run in the
> kernel don't need such handling and could maybe share the same generic
> code path.

Right.

> > All of that assuming that the basic idea is right, which I would like
> > Roger's opinion about.
> 
> Looking at the patch itself, you also seem to be doing some changes
> related to num_vbds and num_vifs, but those are not mentioned in the
> commit message, is that a stray change?

No, I don't think so.  Those variables just tell us when the thing is
torn down but Oleksandr's code is able to use the devices slist itself
for that.  Please do check to see if you agree.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH for-4.13] x86/VT-d: Drop unhelpful information in diagnostics

[Roger Pau Monné]

On Fri, Oct 11, 2019 at 04:02:53PM +0100, Andrew Cooper wrote:
> The virtual address of the base of the IOMMU's regsters is not useful for
> diagnostic purposes, and is quite voluminous.  The PCI coordinates is by far
> the most useful piece of identifying information.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Juergen Gross 
> 
> Surrounding printk()s also identify the IOMMU by Xen's internal ID, but that
> is also pretty useless information when diagnosing problems.
> 
> RFC for-4.13.  This is a nice to have stylistic improvement.

I don't think the register is useful for debugging, at least I have
never used it myself, so:

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v1 2/2] libxl: add removing XS backend path for PV devices on domain destroy

[Roger Pau Monné]

On Fri, Oct 11, 2019 at 04:07:11PM +0100, Ian Jackson wrote:
> Oleksandr Grytsov writes ("[PATCH v1 2/2] libxl: add removing XS backend path 
> for PV devices on domain destroy"):
> > From: Oleksandr Grytsov 
> > 
> > Currently backend path is remove for specific devices: VBD, VIF, QDISK.
> > This commit adds removing backend path for: VDISPL, VSND, VINPUT.
> 
> Thanks for this and your previous patch.
> 
> This one looks to me like it is probably correct.  But I have not been
> able to understand why this code was limited to vbds and vifs before
> so I am hesitant.
> 
> Searching the git history, I think this has been like this since
> a0eaa86e7537
>  "libxl: add device backend listener in order to launch backends"
> and subsequent commits have just reorganised things but not
> fundamentally changed them.  I've CC'd Roger who wrote this code.

When this code was added (devd) those where the only backends handled
by libxl. VDISPL, VSND, VINPUT didn't exist at that point, so I think
the issue is that when support for those was added, it wasn't properly
wired into devd.

> I think:
> 
> >  switch(ddev->dev->backend_kind) {
> > +case LIBXL__DEVICE_KIND_VDISPL:
> > +case LIBXL__DEVICE_KIND_VSND:
> > +case LIBXL__DEVICE_KIND_VINPUT:
> >  case LIBXL__DEVICE_KIND_VBD:
> >  case LIBXL__DEVICE_KIND_VIF:
> 
> If we do want this to handle *all* kinds of device, maybe it should
> have a fallback that aborts, or something ?  (I don't think it is
> easy to make it a compile error to forget to add an entry here but if
> we could do that it would probably be best.)

Maybe we could have some generic handling for everything != qdisk?

IIRC qdisk needs special handling so that devd can launch and destroy
a QEMU instance when required, but other backends that run in the
kernel don't need such handling and could maybe share the same generic
code path.

> All of that assuming that the basic idea is right, which I would like
> Roger's opinion about.

Looking at the patch itself, you also seem to be doing some changes
related to num_vbds and num_vifs, but those are not mentioned in the
commit message, is that a stray change?

I'm not saying it's wrong, it's just that it feels like it belongs in
a different patch maybe.

Thanks, Roger.

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

Re: [Xen-devel] [XEN PATCH v1] libxl: Add DTB compatible list to config file

[Ian Jackson]

Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to config 
file"):
> From: Oleksandr Grytsov 
> 
> Some platforms need more compatible property values in device
> tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
> values that are given by Xen by default.
> Specify in domain configuration file which values should be added
> by providing "dtb_compatible" list of strings separated by comas.

Hi, thanks.

I don't have an opinion about the principle of this and would like to
hear from ARM folks about that.

Also, Stefano, Julien: should we be asking for a freeze exception for
this for 4.13 ?


As for the detail of the code:

The method you use for building compats[] is really rather ad-hoc.
Why not use a flexarray ?

(Also you do not need to check the error return from libxl__zalloc.
From libxl.h:
 * Memory allocation failures are not handled gracefully.  If malloc
 * (or realloc) fails, libxl will cause the entire process to print
 * a message to stderr and exit with status 255.
But really (i) you should be using GCNEW_ARRAY anyway and (ii) this
is all irrelevant if you switch to a flexarray instead.)

Thanks,
Ian.

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

Re: [Xen-devel] [XEN PATCH for-4.13 v1] Reset iomem's gfn to LIBXL_INVALID_GFN on reboot

[Ian Jackson]

Oleksandr Grytsov writes ("[PATCH v1] Reset iomem's gfn to LIBXL_INVALID_GFN on 
reboot"):
> During domain reboot its configuration is partially reused
> to re-create a new domain, but iomem's GFN field for the
> iomem is only restored for those memory ranges, which are
> configured in form of [IOMEM_START,NUM_PAGES[@GFN], but not for
> those in form of [IOMEM_START,NUM_PAGES], e.g. without GFN.
> For the latter GFN is reset to 0, but while mapping ranges
> to a domain during reboot there is a check that GFN treated
> as valid if it is not equal to LIBXL_INVALID_GFN, thus making
> Xen to map IOMEM_START to address 0 in the guest's address space.
> 
> Workaround it by resseting GFN to LIBXL_INVALID_GFN, so xl
> can set proper values for mapping on reboot.

Thanks for this patch.

I confess that I am not sure what is going on here.  Where is this
troublesome 0 coming from ?  I see that the default value for gfn in
the struct is 0 and looking for assignments before this patch, gfn is
defaulted from b_info->iomem[i].start, which is presumably non-0.

I suspect that your patch may be fixing this the wrong way.  I have
addressed this mail to various people who have touched this area of
code and hope they will be able to clarify.

BTW, please do ping this (and your other patches) by email, if the
conversation seems to stall.

Thanks,
Ian.

> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  tools/libxl/libxl_domain.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
> index 9d0eb5aed1..0ae16a5b12 100644
> --- a/tools/libxl/libxl_domain.c
> +++ b/tools/libxl/libxl_domain.c
> @@ -2120,6 +2120,15 @@ static void 
> retrieve_domain_configuration_end(libxl__egc *egc,
>  }
>  }
>  
> +/* reset IOMEM's GFN to initial value */
> +{
> +int i;
> +
> +for (i = 0; i < d_config->b_info.num_iomem; i++)
> +if (d_config->b_info.iomem[i].gfn == 0)
> +d_config->b_info.iomem[i].gfn = LIBXL_INVALID_GFN;
> +}
> +
>  /* Devices: disk, nic, vtpm, pcidev etc. */
>  
>  /* The MERGE macro implements following logic:
> -- 
> 2.17.1
> 

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

Re: [Xen-devel] [PATCH v1 2/2] libxl: add removing XS backend path for PV devices on domain destroy

[Ian Jackson]

Oleksandr Grytsov writes ("[PATCH v1 2/2] libxl: add removing XS backend path 
for PV devices on domain destroy"):
> From: Oleksandr Grytsov 
> 
> Currently backend path is remove for specific devices: VBD, VIF, QDISK.
> This commit adds removing backend path for: VDISPL, VSND, VINPUT.

Thanks for this and your previous patch.

This one looks to me like it is probably correct.  But I have not been
able to understand why this code was limited to vbds and vifs before
so I am hesitant.

Searching the git history, I think this has been like this since
a0eaa86e7537
 "libxl: add device backend listener in order to launch backends"
and subsequent commits have just reorganised things but not
fundamentally changed them.  I've CC'd Roger who wrote this code.

I think:

>  switch(ddev->dev->backend_kind) {
> +case LIBXL__DEVICE_KIND_VDISPL:
> +case LIBXL__DEVICE_KIND_VSND:
> +case LIBXL__DEVICE_KIND_VINPUT:
>  case LIBXL__DEVICE_KIND_VBD:
>  case LIBXL__DEVICE_KIND_VIF:

If we do want this to handle *all* kinds of device, maybe it should
have a fallback that aborts, or something ?  (I don't think it is
easy to make it a compile error to forget to add an entry here but if
we could do that it would probably be best.)

All of that assuming that the basic idea is right, which I would like
Roger's opinion about.

Thanks,
Ian.

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

[Xen-devel] [PATCH for-4.13] x86/VT-d: Drop unhelpful information in diagnostics

[Andrew Cooper]

The virtual address of the base of the IOMMU's regsters is not useful for
diagnostic purposes, and is quite voluminous.  The PCI coordinates is by far
the most useful piece of identifying information.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Juergen Gross 

Surrounding printk()s also identify the IOMMU by Xen's internal ID, but that
is also pretty useless information when diagnosing problems.

RFC for-4.13.  This is a nice to have stylistic improvement.
---
 xen/drivers/passthrough/vtd/iommu.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index f08eec070d..0522ecd3bc 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -842,26 +842,26 @@ static int iommu_page_fault_do_one(struct vtd_iommu 
*iommu, int type,
 case DMA_REMAP:
 printk(XENLOG_G_WARNING VTDPREFIX
"DMAR:[%s] Request device [%04x:%02x:%02x.%u] "
-   "fault addr %"PRIx64", iommu reg = %p\n",
+   "fault addr %"PRIx64"\n",
(type ? "DMA Read" : "DMA Write"),
seg, PCI_BUS(source_id), PCI_SLOT(source_id),
-   PCI_FUNC(source_id), addr, iommu->reg);
+   PCI_FUNC(source_id), addr);
 kind = "DMAR";
 break;
 case INTR_REMAP:
 printk(XENLOG_G_WARNING VTDPREFIX
"INTR-REMAP: Request device [%04x:%02x:%02x.%u] "
-   "fault index %"PRIx64", iommu reg = %p\n",
+   "fault index %"PRIx64"\n",
seg, PCI_BUS(source_id), PCI_SLOT(source_id),
-   PCI_FUNC(source_id), addr >> 48, iommu->reg);
+   PCI_FUNC(source_id), addr >> 48);
 kind = "INTR-REMAP";
 break;
 default:
 printk(XENLOG_G_WARNING VTDPREFIX
"UNKNOWN: Request device [%04x:%02x:%02x.%u] "
-   "fault addr %"PRIx64", iommu reg = %p\n",
+   "fault addr %"PRIx64"\n",
seg, PCI_BUS(source_id), PCI_SLOT(source_id),
-   PCI_FUNC(source_id), addr, iommu->reg);
+   PCI_FUNC(source_id), addr);
 kind = "UNKNOWN";
 break;
 }
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v1 1/2] libxl: introduce new backend type VINPUT

[Ian Jackson]

Oleksandr Grytsov writes ("[PATCH v1 1/2] libxl: introduce new backend type 
VINPUT"):
> From: Oleksandr Grytsov 
> 
> There are two kind of VKBD devices: with QEMU backend and user space
> backend. In current implementation they can't be distinguished as both use
> VKBD backend type. As result, user space KBD backend is started and
> stopped as QEMU backend. This commit adds new device kind VINPUT to be
> used as backend type for user space KBD backend.

I find this confusing.  I'm not sure this change is right.  But I'm
afraid the original patches in this area passed me by so I don't know
much about it.

I think it was a48e00f14a2d "libxl: add backend type and id to vkb"
which introduced what you are calling "user space" backends.  It
appears that the vkb backend type enum was introduced there
specifically to distinguish between these two situations.  For reasons

Am I wrong ?  If not, why is this not working or not suitable ?

I also don't understand why the "user space" kbd backend seems to be
"linux" in the enum.  Where is the implementation of this user space
backend ?  Is it be controlled entirely through xenstore ?

Ian.

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

[Xen-devel] [libvirt test] 142584: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  668dc9fe8c95e919d028356f729404a5ad49e678
baseline version:
 libvirt  2346b2f6564ae9f7ba35bc863cb0fab39cadeb12

Last test of basis   142252  2019-10-04 04:23:56 Z7 days
Failing since142345  2019-10-06 04:19:12 Z5 days6 attempts
Testing same since   142584  2019-10-11 04:23:36 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Collin Walling 
  Daniel Henrique Barboza 
  Daniel P. Berrangé 
  Daniel Veillard 
  Fabiano Fidêncio 
  Ivan Kardykov 
  Jiri Denemark 
  Jonathon Jongsma 
  Ján Tomko 
  Marek Marczykowski-Górecki 
  Michal Privoznik 
  Pavel Mores 
  Peter Krempa 

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



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

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

Explanation of these reports, and of osstest in 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 

Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic

[Jürgen Groß]

On 11.10.19 15:31, Ian Jackson wrote:

George Dunlap writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: 
Overhaul passthrough setting logic"):

On Thu, Oct 10, 2019 at 4:12 PM Ian Jackson  wrote:

LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
version of this code) is doing double duty.  We actually need all of
the following to be specificable:
   * default ("unknown"): enable PT iff we have devices to
 pass through specified in the initial config file.


I realize this may be a bit late, but I find "unknown" to be a very
strange word to use to indicate, "please choose the best option for
me".  For USB device type I used "auto", meaning, "automatically
choose the best option for me".  Paul didn't like "auto", which is
fair enough, but I really don't see how "unknown" is better.

Anyway, not meaning to block, just a suggestion.


I do not have a strong opinion about this.  I would be happy with
"auto" (or "default" maybe).


"unspecified"?


Juergen

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

Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic

[Ian Jackson]

Julien Grall writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: 
Overhaul passthrough setting logic"):
> libxl treats Arm guest as PVH now. Note that we seamlessly convert
> PV to PVH in libxl__arch_domain_{build, create}_info_setdefault().
> 
> So as long as this is called after any of those calls, then we
> should be fine.

I'll check this.

This means that the algorithm is quite different on ARM to on x86:
ARM guests are always PVH and need PT_SHARE; on x86, PVH is not
compatible with passthrough at all.

So I need to put this logic in an arch-specific function.

Ian.

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

Re: [Xen-devel] [PATCH for-4.13] xen/arm: mm: Allow generic xen page-tables helpers to be called early

[Julien Grall]

(+ Andrew and Jan)

Hi,

On 11/10/2019 01:27, Stefano Stabellini wrote:

On Thu, 10 Oct 2019, Julien Grall wrote:

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index be23acfe26..a6637ce347 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -964,11 +964,40 @@ static int create_xen_table(lpae_t *entry)
  
  static lpae_t *xen_map_table(mfn_t mfn)

  {
+/*
+ * We may require to map the page table before map_domain_page() is
+ * useable. The requirements here is it must be useable as soon as
+ * page-tables are allocated dynamically via alloc_boot_pages().
+ *
+ * We need to do the check on physical address rather than virtual
+ * address to avoid truncation on Arm32. Therefore is_kernel() cannot
+ * be used.
+ */
+if ( system_state == SYS_STATE_early_boot )
+{
+const mfn_t mstart = virt_to_mfn(_start);
+const mfn_t mend = virt_to_mfn(_end);
+
+if ( (mfn_x(mstart) <= mfn_x(mfn)) && (mfn_x(mfn) < mfn_x(mend)) )
+{


The patch is good. Actually I noticed that we already have
is_xen_fixed_mfn(), looks like it is made for this. I think we should
use it here, except that is_xen_fixed_mfn has:


Thanks, I thought we had one but I couldn't remember the name :(.



  (mfn_to_maddr(mfn) <= virt_to_maddr(&_end)))

I think it should actually be:

  (mfn_to_maddr(mfn) < virt_to_maddr(&_end)))

Maybe we could fix that at the same time in one patch? However, it is
the same definition as on x86, so I don't know what is going on there.


For Arm we should definitely use < and not <=.

I am assuming this is the same for x86. Andrew? Jan?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: 
Overhaul passthrough setting logic"):
> On Thu, Oct 10, 2019 at 4:12 PM Ian Jackson  wrote:
> > LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
> > version of this code) is doing double duty.  We actually need all of
> > the following to be specificable:
> >   * default ("unknown"): enable PT iff we have devices to
> > pass through specified in the initial config file.
> 
> I realize this may be a bit late, but I find "unknown" to be a very
> strange word to use to indicate, "please choose the best option for
> me".  For USB device type I used "auto", meaning, "automatically
> choose the best option for me".  Paul didn't like "auto", which is
> fair enough, but I really don't see how "unknown" is better.
> 
> Anyway, not meaning to block, just a suggestion.

I do not have a strong opinion about this.  I would be happy with
"auto" (or "default" maybe).

None of this was in 4.12 so we are still free to change it.  Now would
be the time!

Ian.

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

[Xen-devel] [ovmf bisection] complete test-amd64-i386-xl-qemuu-ovmf-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  2de1f611be06ded3a59726a4052a9039be7d459b
  Bug not present: 410c4d00d9f7e369d1ce183e9e8de98cb59c4d20
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/142602/


  commit 2de1f611be06ded3a59726a4052a9039be7d459b
  Author: Pete Batard 
  Date:   Wed Sep 25 23:50:05 2019 +0800
  
  MdeModulePkg/BdsDxe: Also call PlatformBootManagerWaitCallback on 0
  
  The existing loop is set to call PlatformBootManagerWaitCallback every
  second except the last one. We believe this is a mistake as it prevents
  the called code from performing timeout expiration tasks such as, for
  instance, ensuring that the last segment of a progress bar is displayed
  before continuing (which is a current issue for the RPi3 platform).
  
  Signed-off-by: Pete Batard 
  Reviewed-by: Liming Gao 
  Reviewed-by: Ray Ni 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/ovmf/test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install
 --summary-out=tmp/142602.bisection-summary --basis-template=142423 
--blessings=real,real-bisect ovmf test-amd64-i386-xl-qemuu-ovmf-amd64 
debian-hvm-install
Searching for failure / basis pass:
 142567 fail [host=baroque1] / 142423 [host=baroque0] 142274 [host=debina1] 
142250 [host=huxelrebe0] 142117 [host=chardonnay1] 142070 [host=elbling0] 
142017 [host=italia0] 141988 [host=albana0] 141966 [host=albana1] 141907 
[host=pinot0] 141888 [host=pinot1] 141845 [host=debina0] 141798 
[host=chardonnay0] 141742 ok.
Failure / basis pass flights: 142567 / 141742
(tree with no url: minios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 42327896f194f256e5a361e0069985bc8d209b42 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
976d0353a6ce48149039849b52bb67527be5b580 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
f93abf0315efef861270c25d83c8047fd6a54ec4
Basis pass b10ab5e2c476b69689bc0c46d309471b597c880c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
670c903a68f214463f12c0c9619c162a0f342518 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
cef9660618a880ced798375a0fd16a8ad80bd0f0 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
1014f47c7a808e025b8920ab80bfe73a2888b3e5
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#b10ab5e2c476b69689bc0c46d309471b597c880c-42327896f194f256e5a361e0069985bc8d209b42
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
https://github.com/tianocore/edk2.git#670c903a68f214463f12c0c9619c162a0f342518-976d0353a6ce48149039849b52bb67527be5b580
 git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484f\
 e09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 
git://xenbits.xen.org/qemu-xen.git#cef9660618a880ced798375a0fd16a8ad80bd0f0-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#43f5df79dad6738d52ea79d072de2b56eb96a91f-43f5df79dad6738d52ea79d072de2b56eb96a91f
 
git://xenbits.xen.org/xen.git#1014f47c7a808e025b8920ab80bfe73a2888b3e5-f93abf0315efef861270c25d83c8047fd6a54ec4
Loaded 4004 nodes in revision graph
Searching for test results:
 141742 pass b10ab5e2c476b69689bc0c46d309471b597c880c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
670c903a68f214463f12c0c9619c162a0f342518 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
cef9660618a880ced798375a0fd16a8ad80bd0f0 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
1014f47c7a808e025b8920ab80bfe73a2888b3e5
 141798 [host=chardonnay0]
 141845 [host=debina0]
 141888 [host=pinot1]
 141907 [host=pinot0]
 141988 [host=albana0]
 141966 [host=albana1]
 142017 [host=italia0]
 142070 [host=elbling0]
 142117 [host=chardonnay1]
 142274 [host=debina1]
 142250 [host=huxelrebe0]
 

[Xen-devel] [linux-4.4 test] 142571: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142521 REGR. 
vs. 139698

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail in 142521 pass in 142571
 test-amd64-amd64-xl-pvshim   12 guest-startfail pass in 142521
 test-armhf-armhf-libvirt-raw 10 debian-di-install  fail pass in 142521

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

version targeted for testing:
 linux

Re: [Xen-devel] [PATCH for-4.13] xen/arm: mm: Allow generic xen page-tables helpers to be called early

[Julien Grall]

Hi Stefano,

On 11/10/2019 01:27, Stefano Stabellini wrote:

On Thu, 10 Oct 2019, Julien Grall wrote:

The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those helpers are used to
map/unmap page tables while update Xen page-tables.

Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()", setup_fixmap() will make use of the helpers
mentioned above. When booting Xen using GRUB, setup_fixmap() may be used
before map_domain_page() can be called. This will result to data abort:

(XEN) Data Abort Trap. Syndrome=0x5
(XEN) CPU0: Unexpected Trap: Data Abort

[...]

(XEN) Xen call trace:
(XEN)[<0025ab6c>] mm.c#xen_pt_update+0x2b4/0x59c (PC)
(XEN)[<0025ab20>] mm.c#xen_pt_update+0x268/0x59c (LR)
(XEN)[<0025ae70>] set_fixmap+0x1c/0x2c
(XEN)[<002a9c98>] copy_from_paddr+0x7c/0xdc
(XEN)[<002a4ae0>] has_xsm_magic+0x18/0x34
(XEN)[<002a5b5c>] bootfdt.c#early_scan_node+0x398/0x560
(XEN)[<002a5de0>] device_tree_for_each_node+0xbc/0x144
(XEN)[<002a5ed4>] boot_fdt_info+0x6c/0x260
(XEN)[<002ac0d0>] start_xen+0x108/0xc74
(XEN)[<0020044c>] arm64/head.o#paging+0x60/0x88

During early boot, the page tables are either statically allocated in
Xen binary or allocated via alloc_boot_pages().

For statically allocated page-tables, they will already be mapped as
part of Xen binary. So we can easily find the virtual address.

For dynamically allocated page-tables, we need to rely
map_domain_page() to be functionally working.

For arm32, the call will be usable much before page can be dynamically
allocated (see setup_pagetables()). For arm64, the call will be usable
after setup_xenheap_mappings().

In both cases, memory are given to the boot allocator afterwards. So we
can rely on map_domain_page() for mapping page tables allocated
dynamically.

The helpers xen_{map, unmap}_table() are now updated to take into
account the case where page-tables are part of Xen binary.

Fixes: 022387ee1a ('xen/arm: mm: Don't open-code Xen PT update in {set, 
clear}_fixmap()')
Signed-off-by: Julien Grall 
Release-acked-by: Juergen Gross 

---
 Changes in v2:
 - Add RaB Juergen
 - Rework the check to avoid truncation
---
  xen/arch/arm/mm.c | 29 +
  1 file changed, 29 insertions(+)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index be23acfe26..a6637ce347 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -964,11 +964,40 @@ static int create_xen_table(lpae_t *entry)
  
  static lpae_t *xen_map_table(mfn_t mfn)

  {
+/*
+ * We may require to map the page table before map_domain_page() is
+ * useable. The requirements here is it must be useable as soon as
+ * page-tables are allocated dynamically via alloc_boot_pages().
+ *
+ * We need to do the check on physical address rather than virtual
+ * address to avoid truncation on Arm32. Therefore is_kernel() cannot
+ * be used.
+ */
+if ( system_state == SYS_STATE_early_boot )
+{
+const mfn_t mstart = virt_to_mfn(_start);
+const mfn_t mend = virt_to_mfn(_end);
+
+if ( (mfn_x(mstart) <= mfn_x(mfn)) && (mfn_x(mfn) < mfn_x(mend)) )
+{


The patch is good. Actually I noticed that we already have
is_xen_fixed_mfn(), looks like it is made for this. I think we should
use it here, except that is_xen_fixed_mfn has:

  (mfn_to_maddr(mfn) <= virt_to_maddr(&_end)))

I think it should actually be:

  (mfn_to_maddr(mfn) < virt_to_maddr(&_end)))

Maybe we could fix that at the same time in one patch? However, it is
the same definition as on x86, so I don't know what is going on there.



+vaddr_t offset = mfn_to_maddr(mfn) - mfn_to_maddr(mstart);
+return (lpae_t *)(XEN_VIRT_START + offset);


I know this is safe in this case thanks to the `if' above, so there are
no risks. But in general it is not a great idea to have a hidden 64-bit
to 32-bit cast (also it is not MISRA compliant.) I would add an explicit
cast: >
   vaddr_t offset = (vaddr_t)(mfn_to_maddr(mfn) - mfn_to_maddr(mstart));


You would still need a comment for this case as it is unclear why the cast is 
necessary/safe. So I feel a comment would be sufficient here:


/*
 * The address belongs to Xen binary and will always fit in vaddr_t.
 * It is therefore fine to demote the type.
 */

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

On 11/10/2019, 09:32, "Jan Beulich"  wrote:

On 10.10.2019 20:30, Lars Kurth wrote:
> On 10/10/2019, 18:05, "Andrew Cooper"  wrote:
> On 10/10/2019 13:34, Lars Kurth wrote:
> > Existing formats and licenses
> > * Hypercall ABI Documentation generated from Xen public headers
> > Format: kerndoc
> > License: typically BSD-3-Clause (documentation is generated from 
public headers)
> 
> Its homegrown markup, superimposed on what used to be doxygen in
> the past.
> 
> Oh, I forgot
> 
> I wasn't planning on reusing any of the markup, and wasn't expecting 
to
> use much of the text either.  I'm still considering the option of
> defining that xen/public/* isn't the canonical description of the ABI,
> because C is the wrong tool for the job.
> 
> Its fine to provide a C set of headers implementing an ABI, but there 
is
> a very deliberate reason why the canonical migration v2 spec is in a
> text document.
> 
> @Stefano: as you and I believe Brian will be spending time on improving 
the
> ABI docs, I think we need to build some agreement here on what/how
> to do it. I was assuming that generally the consensus was to have
> docs close to the code in source, but this does not seem to be the case.

Well, for migration v2 having the spec in a text file seems sensible
to me. For the public ABI, however, I think it's more helpful to have
the doc next to the actual definitions. Considering the possible use
of languages other than C I can certainly see why separating both
would be even more clean, but I think here we want to weigh practical
purposes against cleanliness.

I think that is an area where we need to build some consensus. The problem
falls under what is considered "traceability" in safety speak: in other words, 
for the ABI documentation use-case it must be easy to be able to
keep documentation and code in sync. And ideally, we would be able to
check this automatically somehow, or have a bot provide hints such as 
"You changed XYZ and should have a look and check whether ABC needs
changing also".

I have thought about the problem of "traceability" for some time, which
goes far beyond what we need for this use-case. Typical things that need
to be maintained for a "traceable (safety) documentation set" are

## Keeping key docs and code in sync 
The use-cases here are things such as
- keep man pages and xl sources in sync
- keep ABI docs and headers in sync
- keep documents such as the migration b2 spec in sync with
  actual source
 
This is a problem we already have today and where we do this often
fairly poorly manually (as can be seen on how out-of-date
man pages often are)

Possible solutions for this are
- store docs alongside headers (maybe using the same base
file name) => that would work for ABI docs

- have some tagging or meta-information scheme which links
specific source files to docs files => that would work for most
other docs (albeit not always perfectly - e.g. when functionality
is spread over many files and just portions of them)

For example: tools/xl/xl_cmdtable.c  
is linked to files in docs/man/xl*

This means creating a bot/tool which warns that when you change
foo.c to also look at foo.rst and/or ../../docs/.../bar.rst should be
relatively straightforward. It would require some initial effort
to create initial mappings, but these would never really change,
unless we refactor code significantly.
 
## Keeping dependent documents (or portions of documents) in sync
This is something we have not really faced, because we do not
have a lot of docs.  

In a large documentation set having the right chapter/tree
structure enables this. In waterfall software engineering
models, where you start off with high-level documents/
requirements/specs/etc. documents which become
increasingly detailed this is done through a chapter/tree
structure, with the capability to make separate documents
(or sections thereof) on other documents (or sections
thereof). When you change something, a tool such as DOORS 
forces you review and sign off child documents.

This is conceptually similar to what we would need for
"linking" sources to docs as outlined above, only that
the "linking" is between docs. It would also be easy enough
to check and highlight, what else may have to be looked at.  

## Proving that your tests verify design claims and that *all claims* are tested
This is typically the hardest problem to solve. It requires
for test cases (be it a document or actual code) to
link to claims (in a design, architecture, spec, ...)
and to prove that all of them are tested.

If there is linkage capability, then it is straightforward
to verify automatically that all your branches have
test-case leaves in your documentation tree. But at least
in a safety context you would also have to augment this
with code coverage 

Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic

[George Dunlap]

On Thu, Oct 10, 2019 at 4:12 PM Ian Jackson  wrote:
>
> LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
> version of this code) is doing double duty.  We actually need all of
> the following to be specificable:
>   * default ("unknown"): enable PT iff we have devices to
> pass through specified in the initial config file.

I realize this may be a bit late, but I find "unknown" to be a very
strange word to use to indicate, "please choose the best option for
me".  For USB device type I used "auto", meaning, "automatically
choose the best option for me".  Paul didn't like "auto", which is
fair enough, but I really don't see how "unknown" is better.

Anyway, not meaning to block, just a suggestion.

 -George

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

[Xen-devel] [PATCH v9 01/28] linkage: Introduce new macros for assembler symbols

[Jiri Slaby]

Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.

So introduce macros with clear use to annotate assembly as follows:

a) Support macros for the ones below
   SYM_T_FUNC -- type used by assembler to mark functions
   SYM_T_OBJECT -- type used by assembler to mark data
   SYM_T_NONE -- type used by assembler to mark entries of unknown type

   They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE
   respectively. According to the gas manual, this is the most portable
   way. I am not sure about other assemblers, so this can be switched
   back to %function and %object if this turns into a problem.
   Architectures can also override them by something like ", @function"
   if they need.

   SYM_A_ALIGN, SYM_A_NONE -- align the symbol?
   SYM_L_GLOBAL, SYM_L_WEAK, SYM_L_LOCAL -- linkage of symbols

b) Mostly internal annotations, used by the ones below
   SYM_ENTRY -- use only if you have to (for non-paired symbols)
   SYM_START -- use only if you have to (for paired symbols)
   SYM_END -- use only if you have to (for paired symbols)

c) Annotations for code
   SYM_INNER_LABEL_ALIGN -- only for labels in the middle of code
   SYM_INNER_LABEL -- only for labels in the middle of code

   SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for
one function
   SYM_FUNC_START_ALIAS -- use where there are two global names for one
function
   SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed function

   SYM_FUNC_START -- use for global functions
   SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment
   SYM_FUNC_START_LOCAL -- use for local functions
   SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o
alignment
   SYM_FUNC_START_WEAK -- use for weak functions
   SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment
   SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START,
SYM_FUNC_START_WEAK, ...

   For functions with special (non-C) calling conventions:
   SYM_CODE_START -- use for non-C (special) functions
   SYM_CODE_START_NOALIGN -- use for non-C (special) functions, w/o
alignment
   SYM_CODE_START_LOCAL -- use for local non-C (special) functions
   SYM_CODE_START_LOCAL_NOALIGN -- use for local non-C (special)
functions, w/o alignment
   SYM_CODE_END -- the end of SYM_CODE_START_LOCAL or SYM_CODE_START

d) For data
   SYM_DATA_START -- global data symbol
   SYM_DATA_START_LOCAL -- local data symbol
   SYM_DATA_END -- the end of the SYM_DATA_START symbol
   SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol
   SYM_DATA -- start+end wrapper around simple global data
   SYM_DATA_LOCAL -- start+end wrapper around simple local data

==

The macros allow to pair starts and ends of functions and mark functions
correctly in the output ELF objects.

All users of the old macros in x86 are converted to use these in further
patches.

Signed-off-by: Jiri Slaby 
Cc: Andrew Morton 
Cc: Boris Ostrovsky 
Cc: h...@zytor.com
Cc: Ingo Molnar 
Cc: jpoim...@redhat.com
Cc: Juergen Gross 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: Borislav Petkov 
Cc: mi...@redhat.com
Cc: Pavel Machek 
Cc: Peter Zijlstra 
Cc: "Rafael J. Wysocki" 
Cc: Thomas Gleixner 
Cc: xen-devel@lists.xenproject.org
Cc: x...@kernel.org
---

Notes:
[v2]
* use SYM_ prefix and sane names
* add SYM_START and SYM_END and parametrize all the macros

[v3]
* add SYM_DATA, SYM_DATA_LOCAL, and SYM_DATA_END_LABEL

[v4]
* add _NOALIGN versions of some macros
* add _CODE_ derivates of _FUNC_ macros

[v5]
* drop "SIMPLE" from data annotations
* switch NOALIGN and ALIGN variants of inner labels
* s/visibility/linkage/; s@SYM_V_@SYM_L_@
* add Documentation

[v6]
* fixed typos found by Randy Dunlap
* remove doubled INNER_LABEL macros, one pair was unused

[v8]
* use lkml.kernel.org for links
* link the docs from index.rst (by Boris)
* fixed typos on the docs

[v9]
* updated the docs as requested by Boris

 Documentation/asm-annotations.rst | 216 ++
 Documentation/index.rst   |   8 +
 arch/x86/include/asm/linkage.h|  10 +-
 include/linux/linkage.h   | 245 +-
 4 files changed, 468 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/asm-annotations.rst

diff --git a/Documentation/asm-annotations.rst 
b/Documentation/asm-annotations.rst
new file mode 100644
index ..29ccd6e61fe5
--- /dev/null
+++ b/Documentation/asm-annotations.rst
@@ -0,0 +1,216 @@
+Assembler Annotations
+=
+
+Copyright (c) 2017-2019 Jiri Slaby
+
+This document describes the new macros for annotation of data and code in
+assembly. In 

[Xen-devel] [PATCH v9 20/28] x86/asm: Make some functions local

[Jiri Slaby]

There is a couple of assembly functions, which are invoked only locally
in the file they are defined. In C, they are marked "static". In
assembly, annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch
their ENDPROC to SYM_{FUNC,CODE}_END too). Whether FUNC or CODE is used,
depends on whether ENDPROC or END was used for a particular function
before.

Signed-off-by: Jiri Slaby 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: x...@kernel.org
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: linux-...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/boot/compressed/efi_thunk_64.S |  8 
 arch/x86/entry/entry_64.S   | 21 +++--
 arch/x86/lib/copy_page_64.S |  4 ++--
 arch/x86/lib/memcpy_64.S| 12 ++--
 arch/x86/lib/memset_64.S|  8 
 arch/x86/platform/efi/efi_thunk_64.S| 12 ++--
 arch/x86/platform/pvh/head.S|  4 ++--
 7 files changed, 35 insertions(+), 34 deletions(-)

diff --git a/arch/x86/boot/compressed/efi_thunk_64.S 
b/arch/x86/boot/compressed/efi_thunk_64.S
index d66000d23921..31312070db22 100644
--- a/arch/x86/boot/compressed/efi_thunk_64.S
+++ b/arch/x86/boot/compressed/efi_thunk_64.S
@@ -99,12 +99,12 @@ ENTRY(efi64_thunk)
ret
 ENDPROC(efi64_thunk)
 
-ENTRY(efi_exit32)
+SYM_FUNC_START_LOCAL(efi_exit32)
movqfunc_rt_ptr(%rip), %rax
push%rax
mov %rdi, %rax
ret
-ENDPROC(efi_exit32)
+SYM_FUNC_END(efi_exit32)
 
.code32
 /*
@@ -112,7 +112,7 @@ ENDPROC(efi_exit32)
  *
  * The stack should represent the 32-bit calling convention.
  */
-ENTRY(efi_enter32)
+SYM_FUNC_START_LOCAL(efi_enter32)
movl$__KERNEL_DS, %eax
movl%eax, %ds
movl%eax, %es
@@ -172,7 +172,7 @@ ENTRY(efi_enter32)
btsl$X86_CR0_PG_BIT, %eax
movl%eax, %cr0
lret
-ENDPROC(efi_enter32)
+SYM_FUNC_END(efi_enter32)
 
.data
.balign 8
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 57d246048ac6..1568da63bf16 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1101,7 +1101,8 @@ idtentry hypervisor_callback xen_do_hypervisor_callback 
has_error_code=0
  * existing activation in its critical region -- if so, we pop the current
  * activation and restart the handler using the previous one.
  */
-ENTRY(xen_do_hypervisor_callback)  /* 
do_hypervisor_callback(struct *pt_regs) */
+/* do_hypervisor_callback(struct *pt_regs) */
+SYM_CODE_START_LOCAL(xen_do_hypervisor_callback)
 
 /*
  * Since we don't modify %rdi, evtchn_do_upall(struct *pt_regs) will
@@ -1119,7 +1120,7 @@ ENTRY(xen_do_hypervisor_callback) /* 
do_hypervisor_callback(struct *pt_regs) */
callxen_maybe_preempt_hcall
 #endif
jmp error_exit
-END(xen_do_hypervisor_callback)
+SYM_CODE_END(xen_do_hypervisor_callback)
 
 /*
  * Hypervisor uses this for application faults while it executes.
@@ -1214,7 +1215,7 @@ idtentry machine_checkdo_mce  
has_error_code=0paranoid=1
  * Use slow, but surefire "are we in kernel?" check.
  * Return: ebx=0: need swapgs on exit, ebx=1: otherwise
  */
-ENTRY(paranoid_entry)
+SYM_CODE_START_LOCAL(paranoid_entry)
UNWIND_HINT_FUNC
cld
PUSH_AND_CLEAR_REGS save_ret=1
@@ -1248,7 +1249,7 @@ ENTRY(paranoid_entry)
FENCE_SWAPGS_KERNEL_ENTRY
 
ret
-END(paranoid_entry)
+SYM_CODE_END(paranoid_entry)
 
 /*
  * "Paranoid" exit path from exception stack.  This is invoked
@@ -1262,7 +1263,7 @@ END(paranoid_entry)
  *
  * On entry, ebx is "no swapgs" flag (1: don't need swapgs, 0: need it)
  */
-ENTRY(paranoid_exit)
+SYM_CODE_START_LOCAL(paranoid_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF_DEBUG
@@ -1279,12 +1280,12 @@ ENTRY(paranoid_exit)
RESTORE_CR3 scratch_reg=%rbx save_reg=%r14
 .Lparanoid_exit_restore:
jmp restore_regs_and_return_to_kernel
-END(paranoid_exit)
+SYM_CODE_END(paranoid_exit)
 
 /*
  * Save all registers in pt_regs, and switch GS if needed.
  */
-ENTRY(error_entry)
+SYM_CODE_START_LOCAL(error_entry)
UNWIND_HINT_FUNC
cld
PUSH_AND_CLEAR_REGS save_ret=1
@@ -1364,16 +1365,16 @@ ENTRY(error_entry)
callfixup_bad_iret
mov %rax, %rsp
jmp .Lerror_entry_from_usermode_after_swapgs
-END(error_entry)
+SYM_CODE_END(error_entry)
 
-ENTRY(error_exit)
+SYM_CODE_START_LOCAL(error_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF
testb   $3, CS(%rsp)
jz  retint_kernel
jmp .Lretint_user
-END(error_exit)
+SYM_CODE_END(error_exit)
 
 /*
  * Runs on exception stack.  Xen PV does not go through this path at all,
diff --git a/arch/x86/lib/copy_page_64.S b/arch/x86/lib/copy_page_64.S
index fd2d09afa097..f505870bd93b 100644
--- 

[Xen-devel] [PATCH v9 22/28] x86_64/asm: Add ENDs to some functions and relabel with SYM_CODE_*

[Jiri Slaby]

All these are functions which are invoked from elsewhere, but they are
not typical C functions. So they are annotated using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END appropriately too.

Signed-off-by: Jiri Slaby 
Reviewed-by: Boris Ostrovsky  [xen bits]
Cc: Borislav Petkov 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/boot/compressed/head_64.S   |  6 --
 arch/x86/platform/olpc/xo1-wakeup.S  |  3 ++-
 arch/x86/power/hibernate_asm_64.S|  6 --
 arch/x86/realmode/rm/reboot.S|  3 ++-
 arch/x86/realmode/rm/trampoline_64.S | 10 +++---
 arch/x86/realmode/rm/wakeup_asm.S|  3 ++-
 arch/x86/xen/xen-asm_64.S|  6 --
 7 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index ca762ea6a681..55800467ce5c 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -250,7 +250,7 @@ ENDPROC(efi32_stub_entry)
 
.code64
.org 0x200
-ENTRY(startup_64)
+SYM_CODE_START(startup_64)
/*
 * 64bit entry is 0x200 and it is ABI so immutable!
 * We come here either from startup_32 or directly from a
@@ -442,6 +442,7 @@ trampoline_return:
  */
leaq.Lrelocated(%rbx), %rax
jmp *%rax
+SYM_CODE_END(startup_64)
 
 #ifdef CONFIG_EFI_STUB
 
@@ -571,7 +572,7 @@ SYM_FUNC_END(.Lrelocated)
  * ECX contains the base address of the trampoline memory.
  * Non zero RDX means trampoline needs to enable 5-level paging.
  */
-ENTRY(trampoline_32bit_src)
+SYM_CODE_START(trampoline_32bit_src)
/* Set up data and stack segments */
movl$__KERNEL_DS, %eax
movl%eax, %ds
@@ -634,6 +635,7 @@ ENTRY(trampoline_32bit_src)
movl%eax, %cr0
 
lret
+SYM_CODE_END(trampoline_32bit_src)
 
.code64
 SYM_FUNC_START_LOCAL_NOALIGN(.Lpaging_enabled)
diff --git a/arch/x86/platform/olpc/xo1-wakeup.S 
b/arch/x86/platform/olpc/xo1-wakeup.S
index 5fee3a2c2fd4..75f4faff8468 100644
--- a/arch/x86/platform/olpc/xo1-wakeup.S
+++ b/arch/x86/platform/olpc/xo1-wakeup.S
@@ -90,7 +90,7 @@ restore_registers:
 
ret
 
-ENTRY(do_olpc_suspend_lowlevel)
+SYM_CODE_START(do_olpc_suspend_lowlevel)
callsave_processor_state
callsave_registers
 
@@ -110,6 +110,7 @@ ret_point:
callrestore_registers
callrestore_processor_state
ret
+SYM_CODE_END(do_olpc_suspend_lowlevel)
 
 .data
 saved_gdt: .long   0,0
diff --git a/arch/x86/power/hibernate_asm_64.S 
b/arch/x86/power/hibernate_asm_64.S
index a4d5eb0a7ece..4057cd5af7e2 100644
--- a/arch/x86/power/hibernate_asm_64.S
+++ b/arch/x86/power/hibernate_asm_64.S
@@ -52,7 +52,7 @@ ENTRY(swsusp_arch_suspend)
ret
 ENDPROC(swsusp_arch_suspend)
 
-ENTRY(restore_image)
+SYM_CODE_START(restore_image)
/* prepare to jump to the image kernel */
movqrestore_jump_address(%rip), %r8
movqrestore_cr3(%rip), %r9
@@ -67,9 +67,10 @@ ENTRY(restore_image)
/* jump to relocated restore code */
movqrelocated_restore_code(%rip), %rcx
jmpq*%rcx
+SYM_CODE_END(restore_image)
 
/* code below has been relocated to a safe page */
-ENTRY(core_restore_code)
+SYM_CODE_START(core_restore_code)
/* switch to temporary page tables */
movq%rax, %cr3
/* flush TLB */
@@ -97,6 +98,7 @@ ENTRY(core_restore_code)
 .Ldone:
/* jump to the restore_registers address from the image header */
jmpq*%r8
+SYM_CODE_END(core_restore_code)
 
 /* code below belongs to the image kernel */
.align PAGE_SIZE
diff --git a/arch/x86/realmode/rm/reboot.S b/arch/x86/realmode/rm/reboot.S
index 424826afb501..f10515b10e0a 100644
--- a/arch/x86/realmode/rm/reboot.S
+++ b/arch/x86/realmode/rm/reboot.S
@@ -19,7 +19,7 @@
  */
.section ".text32", "ax"
.code32
-ENTRY(machine_real_restart_asm)
+SYM_CODE_START(machine_real_restart_asm)
 
 #ifdef CONFIG_X86_64
/* Switch to trampoline GDT as it is guaranteed < 4 GiB */
@@ -63,6 +63,7 @@ SYM_INNER_LABEL(machine_real_restart_paging_off, SYM_L_GLOBAL)
movl%ecx, %gs
movl%ecx, %ss
ljmpw   $8, $1f
+SYM_CODE_END(machine_real_restart_asm)
 
 /*
  * This is 16-bit protected mode code to disable paging and the cache,
diff --git a/arch/x86/realmode/rm/trampoline_64.S 
b/arch/x86/realmode/rm/trampoline_64.S
index c1aeab1dae25..251758ed7443 100644
--- a/arch/x86/realmode/rm/trampoline_64.S
+++ b/arch/x86/realmode/rm/trampoline_64.S
@@ -38,7 +38,7 @@
.code16
 
.balign PAGE_SIZE
-ENTRY(trampoline_start)
+SYM_CODE_START(trampoline_start)
cli # We should be safe anyway
wbinvd
 
@@ -78,12 +78,14 @@ ENTRY(trampoline_start)
 

[Xen-devel] [PATCH v9 24/28] x86_64/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*

[Jiri Slaby]

These are all functions which are invoked from elsewhere, so annotate
them as global using the new SYM_FUNC_START. And their ENDPROC's by
SYM_FUNC_END.

And make sure ENTRY/ENDPROC is not defined on X86_64, given these were
the last users.

Signed-off-by: Jiri Slaby 
Reviewed-by: Rafael J. Wysocki  [hibernate]
Reviewed-by: Boris Ostrovsky  [xen bits]
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: x...@kernel.org
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: linux-cry...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/boot/compressed/efi_thunk_64.S  |  4 +-
 arch/x86/boot/compressed/head_64.S   | 16 +++---
 arch/x86/boot/compressed/mem_encrypt.S   |  8 +--
 arch/x86/crypto/aegis128-aesni-asm.S | 28 -
 arch/x86/crypto/aes_ctrby8_avx-x86_64.S  | 12 ++--
 arch/x86/crypto/aesni-intel_asm.S| 60 ++--
 arch/x86/crypto/aesni-intel_avx-x86_64.S | 32 +--
 arch/x86/crypto/blowfish-x86_64-asm_64.S | 16 +++---
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  | 24 
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 24 
 arch/x86/crypto/camellia-x86_64-asm_64.S | 16 +++---
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S| 16 +++---
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S| 24 
 arch/x86/crypto/chacha-avx2-x86_64.S | 12 ++--
 arch/x86/crypto/chacha-avx512vl-x86_64.S | 12 ++--
 arch/x86/crypto/chacha-ssse3-x86_64.S| 12 ++--
 arch/x86/crypto/crc32-pclmul_asm.S   |  4 +-
 arch/x86/crypto/crc32c-pcl-intel-asm_64.S|  4 +-
 arch/x86/crypto/crct10dif-pcl-asm_64.S   |  4 +-
 arch/x86/crypto/des3_ede-asm_64.S|  8 +--
 arch/x86/crypto/ghash-clmulni-intel_asm.S|  8 +--
 arch/x86/crypto/nh-avx2-x86_64.S |  4 +-
 arch/x86/crypto/nh-sse2-x86_64.S |  4 +-
 arch/x86/crypto/poly1305-avx2-x86_64.S   |  4 +-
 arch/x86/crypto/poly1305-sse2-x86_64.S   |  8 +--
 arch/x86/crypto/serpent-avx-x86_64-asm_64.S  | 24 
 arch/x86/crypto/serpent-avx2-asm_64.S| 24 
 arch/x86/crypto/serpent-sse2-x86_64-asm_64.S |  8 +--
 arch/x86/crypto/sha1_avx2_x86_64_asm.S   |  4 +-
 arch/x86/crypto/sha1_ni_asm.S|  4 +-
 arch/x86/crypto/sha1_ssse3_asm.S |  4 +-
 arch/x86/crypto/sha256-avx-asm.S |  4 +-
 arch/x86/crypto/sha256-avx2-asm.S|  4 +-
 arch/x86/crypto/sha256-ssse3-asm.S   |  4 +-
 arch/x86/crypto/sha256_ni_asm.S  |  4 +-
 arch/x86/crypto/sha512-avx-asm.S |  4 +-
 arch/x86/crypto/sha512-avx2-asm.S|  4 +-
 arch/x86/crypto/sha512-ssse3-asm.S   |  4 +-
 arch/x86/crypto/twofish-avx-x86_64-asm_64.S  | 24 
 arch/x86/crypto/twofish-x86_64-asm_64-3way.S |  8 +--
 arch/x86/crypto/twofish-x86_64-asm_64.S  |  8 +--
 arch/x86/entry/entry_64.S| 10 ++--
 arch/x86/entry/entry_64_compat.S |  4 +-
 arch/x86/kernel/acpi/wakeup_64.S |  8 +--
 arch/x86/kernel/ftrace_64.S  | 20 +++
 arch/x86/kernel/irqflags.S   |  8 +--
 arch/x86/kvm/vmx/vmenter.S   | 12 ++--
 arch/x86/lib/checksum_32.S   |  8 +--
 arch/x86/lib/clear_page_64.S | 12 ++--
 arch/x86/lib/cmpxchg16b_emu.S|  4 +-
 arch/x86/lib/cmpxchg8b_emu.S |  4 +-
 arch/x86/lib/copy_page_64.S  |  4 +-
 arch/x86/lib/copy_user_64.S  | 16 +++---
 arch/x86/lib/csum-copy_64.S  |  4 +-
 arch/x86/lib/getuser.S   | 16 +++---
 arch/x86/lib/hweight.S   |  8 +--
 arch/x86/lib/iomap_copy_64.S |  4 +-
 arch/x86/lib/memcpy_64.S |  4 +-
 arch/x86/lib/memmove_64.S|  4 +-
 arch/x86/lib/memset_64.S |  4 +-
 arch/x86/lib/msr-reg.S   |  8 +--
 arch/x86/lib/putuser.S   | 16 +++---
 arch/x86/lib/retpoline.S |  4 +-
 arch/x86/mm/mem_encrypt_boot.S   |  8 +--
 arch/x86/platform/efi/efi_stub_64.S  |  4 +-
 arch/x86/platform/efi/efi_thunk_64.S |  4 +-
 arch/x86/power/hibernate_asm_64.S|  8 +--
 arch/x86/xen/xen-asm.S   | 28 -
 arch/x86/xen/xen-asm_64.S| 16 +++---
 include/linux/linkage.h  |  4 ++
 70 files changed, 379 insertions(+), 375 deletions(-)

diff --git a/arch/x86/boot/compressed/efi_thunk_64.S 
b/arch/x86/boot/compressed/efi_thunk_64.S
index 31312070db22..593913692d16 100644
--- a/arch/x86/boot/compressed/efi_thunk_64.S
+++ b/arch/x86/boot/compressed/efi_thunk_64.S
@@ -23,7 +23,7 @@
 

[Xen-devel] [PATCH v9 09/28] x86/asm: Annotate aliases

[Jiri Slaby]

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy as it avoid nesting and double symbols.

Signed-off-by: Jiri Slaby 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: 
Cc: Boris Ostrovsky 
Reviewed-by: Juergen Gross  [xen parts]
Cc: 
Cc: 
---
 arch/x86/crypto/aesni-intel_asm.S | 5 ++---
 arch/x86/lib/memcpy_64.S  | 4 ++--
 arch/x86/lib/memmove_64.S | 4 ++--
 arch/x86/lib/memset_64.S  | 4 ++--
 arch/x86/xen/xen-asm_64.S | 4 ++--
 5 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index e0a5fb462a0a..9d8d5f2296e1 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1757,8 +1757,7 @@ ENDPROC(aesni_gcm_finalize)
 #endif
 
 
-.align 4
-_key_expansion_128:
+SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128)
 SYM_FUNC_START_LOCAL(_key_expansion_256a)
pshufd $0b, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
@@ -1769,8 +1768,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a)
movaps %xmm0, (TKEYP)
add $0x10, TKEYP
ret
-ENDPROC(_key_expansion_128)
 SYM_FUNC_END(_key_expansion_256a)
+SYM_FUNC_END_ALIAS(_key_expansion_128)
 
 SYM_FUNC_START_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 92748660ba51..57a64266ba69 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -28,7 +28,7 @@
  * Output:
  * rax original destination
  */
-ENTRY(__memcpy)
+SYM_FUNC_START_ALIAS(__memcpy)
 ENTRY(memcpy)
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
  "jmp memcpy_erms", X86_FEATURE_ERMS
@@ -42,7 +42,7 @@ ENTRY(memcpy)
rep movsb
ret
 ENDPROC(memcpy)
-ENDPROC(__memcpy)
+SYM_FUNC_END_ALIAS(__memcpy)
 EXPORT_SYMBOL(memcpy)
 EXPORT_SYMBOL(__memcpy)
 
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index bbec69d8223b..50c1648311b3 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -26,7 +26,7 @@
  */
 .weak memmove
 
-ENTRY(memmove)
+SYM_FUNC_START_ALIAS(memmove)
 ENTRY(__memmove)
 
/* Handle more 32 bytes in loop */
@@ -208,6 +208,6 @@ ENTRY(__memmove)
 13:
retq
 ENDPROC(__memmove)
-ENDPROC(memmove)
+SYM_FUNC_END_ALIAS(memmove)
 EXPORT_SYMBOL(__memmove)
 EXPORT_SYMBOL(memmove)
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 9bc861c71e75..927ac44d34aa 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -19,7 +19,7 @@
  *
  * rax   original destination
  */
-ENTRY(memset)
+SYM_FUNC_START_ALIAS(memset)
 ENTRY(__memset)
/*
 * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
@@ -43,8 +43,8 @@ ENTRY(__memset)
rep stosb
movq %r9,%rax
ret
-ENDPROC(memset)
 ENDPROC(__memset)
+SYM_FUNC_END_ALIAS(memset)
 EXPORT_SYMBOL(memset)
 EXPORT_SYMBOL(__memset)
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index ebf610b49c06..45c1249f370d 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -167,13 +167,13 @@ ENDPROC(xen_sysenter_target)
 
 #else /* !CONFIG_IA32_EMULATION */
 
-ENTRY(xen_syscall32_target)
+SYM_FUNC_START_ALIAS(xen_syscall32_target)
 ENTRY(xen_sysenter_target)
lea 16(%rsp), %rsp  /* strip %rcx, %r11 */
mov $-ENOSYS, %rax
pushq $0
jmp hypercall_iret
-ENDPROC(xen_syscall32_target)
 ENDPROC(xen_sysenter_target)
+SYM_FUNC_END_ALIAS(xen_syscall32_target)
 
 #endif /* CONFIG_IA32_EMULATION */
-- 
2.23.0


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

[Xen-devel] [PATCH v9 25/28] x86_32/asm: Add ENDs to some functions and relabel with SYM_CODE_*

[Jiri Slaby]

All these are functions which are invoked from elsewhere, but they are
not typical C functions. So they are annotated using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriately.

Signed-off-by: Jiri Slaby 
Reviewed-by: Boris Ostrovsky  [xen bits]
Reviewed-by: Rafael J. Wysocki  [hibernate]
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: linux...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/entry/entry_32.S| 3 ++-
 arch/x86/kernel/acpi/wakeup_32.S | 7 ---
 arch/x86/kernel/ftrace_32.S  | 3 ++-
 arch/x86/kernel/head_32.S| 3 ++-
 arch/x86/power/hibernate_asm_32.S| 6 --
 arch/x86/realmode/rm/trampoline_32.S | 6 --
 arch/x86/xen/xen-asm_32.S| 7 ---
 7 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 4900a6a5e125..64fe7aa50ad2 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -847,9 +847,10 @@ SYM_ENTRY(__begin_SYSENTER_singlestep_region, 
SYM_L_GLOBAL, SYM_A_NONE)
  * Xen doesn't set %esp to be precisely what the normal SYSENTER
  * entry point expects, so fix it up before using the normal path.
  */
-ENTRY(xen_sysenter_target)
+SYM_CODE_START(xen_sysenter_target)
addl$5*4, %esp  /* remove xen-provided frame */
jmp .Lsysenter_past_esp
+SYM_CODE_END(xen_sysenter_target)
 #endif
 
 /*
diff --git a/arch/x86/kernel/acpi/wakeup_32.S b/arch/x86/kernel/acpi/wakeup_32.S
index 427249292aef..daf88f8143c5 100644
--- a/arch/x86/kernel/acpi/wakeup_32.S
+++ b/arch/x86/kernel/acpi/wakeup_32.S
@@ -9,8 +9,7 @@
.code32
ALIGN
 
-ENTRY(wakeup_pmode_return)
-wakeup_pmode_return:
+SYM_CODE_START(wakeup_pmode_return)
movw$__KERNEL_DS, %ax
movw%ax, %ss
movw%ax, %fs
@@ -39,6 +38,7 @@ wakeup_pmode_return:
# jump to place where we left off
movlsaved_eip, %eax
jmp *%eax
+SYM_CODE_END(wakeup_pmode_return)
 
 bogus_magic:
jmp bogus_magic
@@ -72,7 +72,7 @@ restore_registers:
popfl
ret
 
-ENTRY(do_suspend_lowlevel)
+SYM_CODE_START(do_suspend_lowlevel)
callsave_processor_state
callsave_registers
pushl   $3
@@ -87,6 +87,7 @@ ret_point:
callrestore_registers
callrestore_processor_state
ret
+SYM_CODE_END(do_suspend_lowlevel)
 
 .data
 ALIGN
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 219be1309c37..a43ed4c0402d 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -89,7 +89,7 @@ WEAK(ftrace_stub)
ret
 END(ftrace_caller)
 
-ENTRY(ftrace_regs_caller)
+SYM_CODE_START(ftrace_regs_caller)
/*
 * We're here from an mcount/fentry CALL, and the stack frame looks 
like:
 *
@@ -163,6 +163,7 @@ SYM_INNER_LABEL(ftrace_regs_call, SYM_L_GLOBAL)
popl%eax
 
jmp .Lftrace_ret
+SYM_CODE_END(ftrace_regs_caller)
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 ENTRY(ftrace_graph_caller)
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index e2b3e6cf86ca..7029bbaccc41 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -64,7 +64,7 @@ RESERVE_BRK(pagetables, INIT_MAP_SIZE)
  * can.
  */
 __HEAD
-ENTRY(startup_32)
+SYM_CODE_START(startup_32)
movl pa(initial_stack),%ecx

/* test KEEP_SEGMENTS flag to see if the bootloader is asking
@@ -172,6 +172,7 @@ num_subarch_entries = (. - subarch_entries) / 4
 #else
jmp .Ldefault_entry
 #endif /* CONFIG_PARAVIRT */
+SYM_CODE_END(startup_32)
 
 #ifdef CONFIG_HOTPLUG_CPU
 /*
diff --git a/arch/x86/power/hibernate_asm_32.S 
b/arch/x86/power/hibernate_asm_32.S
index 6fe383002125..a19ed3d23185 100644
--- a/arch/x86/power/hibernate_asm_32.S
+++ b/arch/x86/power/hibernate_asm_32.S
@@ -35,7 +35,7 @@ ENTRY(swsusp_arch_suspend)
ret
 ENDPROC(swsusp_arch_suspend)
 
-ENTRY(restore_image)
+SYM_CODE_START(restore_image)
/* prepare to jump to the image kernel */
movlrestore_jump_address, %ebx
movlrestore_cr3, %ebp
@@ -45,9 +45,10 @@ ENTRY(restore_image)
/* jump to relocated restore code */
movlrelocated_restore_code, %eax
jmpl*%eax
+SYM_CODE_END(restore_image)
 
 /* code below has been relocated to a safe page */
-ENTRY(core_restore_code)
+SYM_CODE_START(core_restore_code)
movltemp_pgt, %eax
movl%eax, %cr3
 
@@ -77,6 +78,7 @@ copy_loop:
 
 done:
jmpl*%ebx
+SYM_CODE_END(core_restore_code)
 
/* code below belongs to the image kernel */
.align PAGE_SIZE
diff --git a/arch/x86/realmode/rm/trampoline_32.S 
b/arch/x86/realmode/rm/trampoline_32.S
index 

[Xen-devel] [PATCH v9 14/28] xen/pvh: Annotate data appropriately

[Jiri Slaby]

Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros to have:
   8 OBJECT  LOCAL  DEFAULT6 gdt
  000832 OBJECT  LOCAL  DEFAULT6 gdt_start
  0028 0 OBJECT  LOCAL  DEFAULT6 gdt_end
  0028   256 OBJECT  LOCAL  DEFAULT6 early_stack
  0128 0 OBJECT  LOCAL  DEFAULT6 early_stack

Signed-off-by: Jiri Slaby 
Reviewed-by: Boris Ostrovsky 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/platform/pvh/head.S | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
index 1f8825bbaffb..4e63480bb223 100644
--- a/arch/x86/platform/pvh/head.S
+++ b/arch/x86/platform/pvh/head.S
@@ -150,11 +150,12 @@ END(pvh_start_xen)
 
.section ".init.data","aw"
.balign 8
-gdt:
+SYM_DATA_START_LOCAL(gdt)
.word gdt_end - gdt_start
.long _pa(gdt_start)
.word 0
-gdt_start:
+SYM_DATA_END(gdt)
+SYM_DATA_START_LOCAL(gdt_start)
.quad 0x/* NULL descriptor */
 #ifdef CONFIG_X86_64
.quad GDT_ENTRY(0xa09a, 0, 0xf) /* PVH_CS_SEL */
@@ -163,15 +164,14 @@ gdt_start:
 #endif
.quad GDT_ENTRY(0xc092, 0, 0xf) /* PVH_DS_SEL */
.quad GDT_ENTRY(0x4090, 0, 0x18)/* PVH_CANARY_SEL */
-gdt_end:
+SYM_DATA_END_LABEL(gdt_start, SYM_L_LOCAL, gdt_end)
 
.balign 16
-canary:
-   .fill 48, 1, 0
+SYM_DATA_LOCAL(canary, .fill 48, 1, 0)
 
-early_stack:
+SYM_DATA_START_LOCAL(early_stack)
.fill BOOT_STACK_SIZE, 1, 0
-early_stack_end:
+SYM_DATA_END_LABEL(early_stack, SYM_L_LOCAL, early_stack_end)
 
ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,
 _ASM_PTR (pvh_start_xen - __START_KERNEL_map))
-- 
2.23.0


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

[Xen-devel] [PATCH v9 23/28] x86_64/asm: Change all ENTRY+END to SYM_CODE_*

[Jiri Slaby]

Here, all assembly code which is marked using END (and not ENDPROC) is
changed. All these are switched to appropriate new markings
SYM_CODE_START and SYM_CODE_END.

Signed-off-by: Jiri Slaby 
Reviewed-by: Boris Ostrovsky  [xen bits]
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/entry/entry_64.S| 52 
 arch/x86/entry/entry_64_compat.S |  8 ++---
 arch/x86/kernel/ftrace_64.S  |  4 +--
 arch/x86/kernel/head_64.S| 12 
 arch/x86/xen/xen-asm_64.S|  8 ++---
 arch/x86/xen/xen-head.S  |  8 ++---
 6 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 1568da63bf16..13e4fe378e5a 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -46,11 +46,11 @@
 .section .entry.text, "ax"
 
 #ifdef CONFIG_PARAVIRT
-ENTRY(native_usergs_sysret64)
+SYM_CODE_START(native_usergs_sysret64)
UNWIND_HINT_EMPTY
swapgs
sysretq
-END(native_usergs_sysret64)
+SYM_CODE_END(native_usergs_sysret64)
 #endif /* CONFIG_PARAVIRT */
 
 .macro TRACE_IRQS_FLAGS flags:req
@@ -142,7 +142,7 @@ END(native_usergs_sysret64)
  * with them due to bugs in both AMD and Intel CPUs.
  */
 
-ENTRY(entry_SYSCALL_64)
+SYM_CODE_START(entry_SYSCALL_64)
UNWIND_HINT_EMPTY
/*
 * Interrupts are off on entry.
@@ -273,13 +273,13 @@ syscall_return_via_sysret:
popq%rdi
popq%rsp
USERGS_SYSRET64
-END(entry_SYSCALL_64)
+SYM_CODE_END(entry_SYSCALL_64)
 
 /*
  * %rdi: prev task
  * %rsi: next task
  */
-ENTRY(__switch_to_asm)
+SYM_CODE_START(__switch_to_asm)
UNWIND_HINT_FUNC
/*
 * Save callee-saved registers
@@ -321,7 +321,7 @@ ENTRY(__switch_to_asm)
popq%rbp
 
jmp __switch_to
-END(__switch_to_asm)
+SYM_CODE_END(__switch_to_asm)
 
 /*
  * A newly forked process directly context switches into this address.
@@ -330,7 +330,7 @@ END(__switch_to_asm)
  * rbx: kernel thread func (NULL for user thread)
  * r12: kernel thread arg
  */
-ENTRY(ret_from_fork)
+SYM_CODE_START(ret_from_fork)
UNWIND_HINT_EMPTY
movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
@@ -357,14 +357,14 @@ ENTRY(ret_from_fork)
 */
movq$0, RAX(%rsp)
jmp 2b
-END(ret_from_fork)
+SYM_CODE_END(ret_from_fork)
 
 /*
  * Build the entry stubs with some assembler magic.
  * We pack 1 stub into every 8-byte block.
  */
.align 8
-ENTRY(irq_entries_start)
+SYM_CODE_START(irq_entries_start)
 vector=FIRST_EXTERNAL_VECTOR
 .rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR)
UNWIND_HINT_IRET_REGS
@@ -373,10 +373,10 @@ ENTRY(irq_entries_start)
.align  8
vector=vector+1
 .endr
-END(irq_entries_start)
+SYM_CODE_END(irq_entries_start)
 
.align 8
-ENTRY(spurious_entries_start)
+SYM_CODE_START(spurious_entries_start)
 vector=FIRST_SYSTEM_VECTOR
 .rept (NR_VECTORS - FIRST_SYSTEM_VECTOR)
UNWIND_HINT_IRET_REGS
@@ -385,7 +385,7 @@ ENTRY(spurious_entries_start)
.align  8
vector=vector+1
 .endr
-END(spurious_entries_start)
+SYM_CODE_END(spurious_entries_start)
 
 .macro DEBUG_ENTRY_ASSERT_IRQS_OFF
 #ifdef CONFIG_DEBUG_ENTRY
@@ -511,7 +511,7 @@ END(spurious_entries_start)
  * | return address|
  * ++
  */
-ENTRY(interrupt_entry)
+SYM_CODE_START(interrupt_entry)
UNWIND_HINT_FUNC
ASM_CLAC
cld
@@ -579,7 +579,7 @@ ENTRY(interrupt_entry)
TRACE_IRQS_OFF
 
ret
-END(interrupt_entry)
+SYM_CODE_END(interrupt_entry)
 _ASM_NOKPROBE(interrupt_entry)
 
 
@@ -795,7 +795,7 @@ _ASM_NOKPROBE(common_interrupt)
  * APIC interrupts.
  */
 .macro apicinterrupt3 num sym do_sym
-ENTRY(\sym)
+SYM_CODE_START(\sym)
UNWIND_HINT_IRET_REGS
pushq   $~(\num)
 .Lcommon_\sym:
@@ -803,7 +803,7 @@ ENTRY(\sym)
UNWIND_HINT_REGS indirect=1
call\do_sym /* rdi points to pt_regs */
jmp ret_from_intr
-END(\sym)
+SYM_CODE_END(\sym)
 _ASM_NOKPROBE(\sym)
 .endm
 
@@ -968,7 +968,7 @@ apicinterrupt IRQ_WORK_VECTOR   
irq_work_interrupt  smp_irq_work_interrupt
  * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS.
  */
 .macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 
ist_offset=0 create_gap=0 read_cr2=0
-ENTRY(\sym)
+SYM_CODE_START(\sym)
UNWIND_HINT_IRET_REGS offset=\has_error_code*8
 
/* Sanity check */
@@ -1018,7 +1018,7 @@ ENTRY(\sym)
.endif
 
 _ASM_NOKPROBE(\sym)
-END(\sym)
+SYM_CODE_END(\sym)
 .endm
 
 idtentry divide_error  do_divide_error 
has_error_code=0
@@ -1135,7 

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

On 11/10/2019, 02:24, "Stefano Stabellini"  wrote:

On Thu, 10 Oct 2019, Lars Kurth wrote:
> * Would we ever include API docs generated from GPLv2 code? E.g. for 
safety use-cases?
> @Stefano, @Artem: I guess this one is for you. 
> I suppose if we would have a similar issue for a safety manual
> I am also assuming we would want to use sphinx docs and rst to generate a 
future safety manual

Hi Lars,

Thanks for putting this email together.

In terms of formats, I don't have a preference between rst and pandoc,
but if we are going to use rst going forward, I'd say to try to use rst
for everything, including converting all the old stuff. The fewer
different formats, the better.

I think the proposal that needs to follow on from this (which would at some
point need to be voted on) would then be to go for rst. 

As I mentioned during the FuSa call, I agree with you, Andrew, and
others that it would be best to have the docs under a CC license. I do
expect that we'll end up copy/pasting snippets of in-code comments into
the docs, so I think it is important that we are allowed to do that from
a license perspective. It is great that GPLv2 allows it (we need to be
sure about this).

The GPL does *not* allow this, but (c) law and fair use clauses do. So typically
stuff such as
* Referring to function names, signatures, etc. tend to be all fine
* Copying large portions of in-line comments would not be fine, but
If they are large, they would in most cases be re-written in a more suitable
language. 

So, I think overall, we should be fine. It's a bit of a grey area though.

And as you point out below, most of the code in question is typically BSD 

Yes, I expect that some docs might be automatically generated, but from
header files, not from source code. Especailly public/ header files,
which are typically BSD, not GPLv2. I cannot come up with examples of
docs we need to generated from GPLv2-only code at the moment, hopefully
there won't be any.

That makes things a lot easier.
 
> I wasn't planning on reusing any of the markup, and wasn't expecting 
to
> use much of the text either.  I'm still considering the option of
> defining that xen/public/* isn't the canonical description of the ABI,
> because C is the wrong tool for the job.
> 
> Its fine to provide a C set of headers implementing an ABI, but there 
is
> a very deliberate reason why the canonical migration v2 spec is in a
> text document.
> 
> @Stefano: as you and I believe Brian will be spending time on improving 
the
> ABI docs, I think we need to build some agreement here on what/how
> to do it. I was assuming that generally the consensus was to have
> docs close to the code in source, but this does not seem to be the case.
> 
> But if we do have stuff separately, ideally we would have a tool that 
helps
> point people editing headers to also look at the relevant docs. Otherwise 
it will
> be hard to keep them in sync.

In general, it is a good idea to keep the docs close to the code to make
it easier to keep them up to date. But there is no one-size-fits-all
here. For public ABI descriptions, I agree with Andrew that ideally they
should not be defined as C header files.

But it is not an issue: any work that we do here won't be wasted. For
instance, we could start by adding more comments to the current header
files. Then, as a second step, take all the comments and turn them into
a proper ABI description document without any C function declarations.
It is easy to move English text around, as long as the license allows it
-- that is the only potential blocker I can see.

This is likely to be problematic. First of all, we are talking about 
BSD-3-Clause
or BSD-2-Clause code (the latter is more dominant in headers I believe) in
all known cases.

The main properties of the BSD are
1: Can be pretty much used anywhere for any purpose
2: Can be modified for any purpose 
3: But the original license header must be retained in derivates

Does *not* have requirements around attribution as CC-BY-4: however,
as we store everything in git attribution is handled by us by default

CC-BY-4 also has properties 1-3
In addition: it does require that 
4: Derived works are giving appropriate credit to authors 
We could clarify in a COPYING how we prefer to do this
4.1: We could say that "referring to the Xen Project community" 
is sufficient to comply with the attribution clause
4.2: We could require individual authors to be credited: in that
case we probably ought to lead by example and list the authors
in a credit/license section and extract the information from
git logs when we generate it (at some point in the future)
5: You give an indication 

[Xen-devel] [ovmf test] 142567: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
142423

version targeted for testing:
 ovmf 976d0353a6ce48149039849b52bb67527be5b580
baseline version:
 ovmf 410c4d00d9f7e369d1ce183e9e8de98cb59c4d20

Last test of basis   142423  2019-10-08 01:39:34 Z3 days
Failing since142455  2019-10-08 19:21:52 Z2 days4 attempts
Testing same since   142495  2019-10-09 12:29:18 Z1 days3 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Laszlo Ersek 
  Pete Batard 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic

[Julien Grall]

Hi,

On 11/10/2019 10:47, Andrew Cooper wrote:

On 10/10/2019 16:11, Ian Jackson wrote:

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 69971c97b6..fccb6a6271 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -968,6 +957,50 @@ int libxl__domain_config_setdefault(libxl__gc *gc,
  goto error_out;
  }
  
+bool need_pt = d_config->num_pcidevs || d_config->num_dtdevs;

+if (c_info->passthrough == LIBXL_PASSTHROUGH_UNKNOWN) {
+c_info->passthrough = need_pt
+? LIBXL_PASSTHROUGH_ENABLED : LIBXL_PASSTHROUGH_DISABLED;
+}
+
+bool iommu_enabled = physinfo.cap_hvm_directio;
+if (c_info->passthrough != LIBXL_PASSTHROUGH_DISABLED && !iommu_enabled) {
+LOGD(ERROR, domid,
+ "ERROR: passthrough not supported on this platform\n");
+ret = ERROR_INVAL;
+goto error_out;
+}
+
+if (c_info->passthrough == LIBXL_PASSTHROUGH_DISABLED && need_pt) {
+LOGD(ERROR, domid,
+ "passthrough disabled but devices are specified");


This is the only log message which isn't prefixed with ERROR:


+ret = ERROR_INVAL;
+goto error_out;
+}
+
+const char *whynot_pt_share =
+c_info->type == LIBXL_DOMAIN_TYPE_PV ? "not valid for PV domain" :
+!physinfo.cap_iommu_hap_pt_share ? "not supported on this platform" :
+NULL;


This is a little more complicated.

For ARM, doesn't libxl treat guests as PV, or has that been fixed now?


libxl treats Arm guest as PVH now. Note that we seamlessly convert PV to PVH in 
libxl__arch_domain_{build, create}_info_setdefault().


So as long as this is called after any of those calls, then we should be fine.


ARM's only passthrough mode is PT_SHARE.


Correct.

Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable test] 142563: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
vs. 141822
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 
141822

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 141822
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 141822

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

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Artem Mygaiev]

Hi Lars

On Thu, 2019-10-10 at 12:34 +, Lars Kurth wrote:
> * Possibly stuff such as 
> https://urldefense.com/v3/__https://xenbits.xen.org/docs/unstable/support-matrix.html__;!K6dmGCEab4ueJg!lwAwYJi7cUkbX7CUXnOD9i7laj_9xcyafF714u6PO04tu0CYUKDHWBHAy2XD0mvEiA$
>   (which is currently GPL-2,
>but we could relicense to say GPL-2 and CC-BY-4 if we had to)
> The implication is that the sphinx docs would not be fully CC-BY-4,
> but the bulk of the pages would be
> 
> * Would we ever include API docs generated from GPLv2 code? E.g. for
> safety use-cases?
> @Stefano, @Artem: I guess this one is for you. 
> I suppose if we would have a similar issue for a safety manual
> I am also assuming we would want to use sphinx docs and rst to
> generate a future safety manual
> 

Yes, I think we will have to use some API docs in safety related
documentation. But I do not see any issue with that because using
"description" part of headers in documentation can be treated as "fair
use" and thus will not create a license conflict as confirmed in 
https://www.gnu.org/licenses/gpl-faq.en.html#SourceCodeInDocumentation

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

Re: [Xen-devel] [PATCH v2 1/2] x2APIC: translate IO-APIC entries when enabling the IOMMU

[Roger Pau Monné]

On Fri, Oct 11, 2019 at 12:01:36PM +0200, Jan Beulich wrote:
> On 11.10.2019 11:28, Roger Pau Monné  wrote:
> > On Fri, Oct 11, 2019 at 09:52:35AM +0200, Jan Beulich wrote:
> >> On 10.10.2019 17:19, Roger Pau Monné  wrote:
> >>> On Thu, Oct 10, 2019 at 03:46:45PM +0200, Jan Beulich wrote:
>  On 10.10.2019 15:12, Roger Pau Monné  wrote:
> > On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
> >> On 10.10.2019 14:13, Roger Pau Monné  wrote:
> >>> On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
>  On 10.10.2019 13:33, Roger Pau Monne wrote:
> > When interrupt remapping is enabled as part of enabling x2APIC the
> 
>  Perhaps "unmasked" instead of "the"?
> 
> > IO-APIC entries also need to be translated to the new format and 
> > added
> > to the interrupt remapping table.
> >
> > This prevents IOMMU interrupt remapping faults when booting on
> > hardware that has unmasked IO-APIC pins.
> 
>  But in the end it only papers over whatever the spurious interrupts
>  result form, doesn't it? Which isn't to say this isn't an
>  improvement. Calling out the ExtInt case here may be worthwhile as
>  well, as would be pointing out that this case still won't work on
>  AMD IOMMUs.
> >>>
> >>> But the fix for the ExtINT AMD issue should be done in
> >>> amd_iommu_ioapic_update_ire then, so that it can properly handle
> >>> ExtINT delivery mode, not to this part of the code. I will look
> >>> into it, but I think it's kind of tangential to the issue here.
> >>
> >> I'm not talking of you working on fixing this right away. I'm merely
> >> asking that you mention here (a) the ExtInt special case and (b)
> >> that this special case will (continue to) not work in the AMD case.
> >>
> > --- a/xen/arch/x86/apic.c
> > +++ b/xen/arch/x86/apic.c
> > @@ -515,7 +515,7 @@ static void resume_x2apic(void)
> >  iommu_enable_x2apic();
> >  __enable_x2apic();
> >  
> > -restore_IO_APIC_setup(ioapic_entries);
> > +restore_IO_APIC_setup(ioapic_entries, true);
> >  unmask_8259A();
> >  
> >  out:
> > @@ -961,7 +961,12 @@ void __init x2apic_bsp_setup(void)
> >  printk("Switched to APIC driver %s\n", genapic.name);
> >  
> >  restore_out:
> > -restore_IO_APIC_setup(ioapic_entries);
> > +/*
> > + * NB: do not use raw mode when restoring entries if the iommu 
> > has been
> > + * enabled during the process, because the entries need to be 
> > translated
> > + * and added to the remapping table in that case.
> > + */
> > +restore_IO_APIC_setup(ioapic_entries, !x2apic_enabled);
> 
>  How is this different in the resume_x2apic() case? The IOMMU gets
>  enabled in the course of that as well. I.e. I'd expect you want
>  to pass "false" there, not "true".
> >>>
> >>> In the resume_x2apic case interrupt remapping should already be
> >>> enabled or not, but that function is not going to enable interrupt
> >>> remapping if it wasn't enabled before, hence the IO-APIC entries
> >>> should already be using the interrupt remapping table and no
> >>> translation is needed.
> >>
> >> Who / what would have enabled the IOMMU in the resume case?
> >
> > I don't think the question is who enables interrupt remapping in the
> > resume case (which is resume_x2apic when calling iommu_enable_x2apic
> > AFAICT), the point here is that on resume the entries in the IO-APIC
> > will already match the state of interrupt remapping, so they shouldn't
> > be translated. If interrupt remapping was off before suspend it will
> > still be off after resume, and there won't be any translation needed.
> > The same is true if interrupt remapping is on before suspend.
> 
>  I disagree: save_IO_APIC_setup() gets called from resume_x2apic(),
>  not prior to suspend.
> >>>
> >>> Oh, so maybe that's a misunderstanding on my side. I don't seem to be
> >>> able to find a statement about the contents of the IO-APIC registers
> >>> (and more specifically the entries) when getting back from
> >>> suspension. Are all entries cleared and masked?
> >>>
> >>> Are the values previous to suspension stored?
> >>
> >> See ioapic_suspend() / ioapic_resume(): Looks like there's some
> >> redundancy here - I don't think it makes sense for the LAPIC
> >> code to fiddle with all the RTEs if subsequently (I assume;
> >> didn't check) they'll all be overwritten anyway. I would seem
> >> more logical to me if they'd just all get masked for IOMMU
> >> enabling, deferring to ioapic_resume() for everything else.
> > 
> > Yes, it seems like resume_x2apic 

Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early

[Julien Grall]

Hi,

On 11/10/2019 01:32, Stefano Stabellini wrote:

On Thu, 10 Oct 2019, Julien Grall wrote:

On 08/10/2019 23:24, Stefano Stabellini wrote:

On Tue, 8 Oct 2019, Julien Grall wrote:

On 10/8/19 1:18 AM, Stefano Stabellini wrote:

On Mon, 7 Oct 2019, Julien Grall wrote:

Hi,

On 03/10/2019 02:02, Stefano Stabellini wrote:

On Fri, 20 Sep 2019, Julien Grall wrote:

That's not correct. alloc_boot_pages() is actually here to allow
dynamic
allocation before the memory subsystem (and therefore the runtime
allocator)
is initialized.


Let me change the question then: is the system_state ==
SYS_STATE_early_boot check strictly necessary? It looks like it is
not:
the patch would work even if it was just:


I had a few thoughts about it. On Arm32, this only really works for
32-bits machine address (it can go up to 40-bits). I haven't really
fully investigated what could go wrong, but it would be best to keep
it
only for early boot.

Also, I don't really want to rely on this "workaround" after boot.
Maybe
we would want to keep them unmapped in the future.


Yes, no problems, we agree on that. I am not asking in regards to the
check system_state == SYS_STATE_early_boot with the goal of asking you
to get rid of it. I am fine with keeping the check. (Maybe we want to
add
an `unlikely()' around the check.)

I am trying to understand whether the code actually relies on
system_state == SYS_STATE_early_boot, and, if so, why. The goal is to
make sure that if there are some limitations that they are documented,
or just to double-check that there are no limitations.


The check is not strictly necessary.



In regards to your comment about only working for 32-bit addresses on
Arm32, you have a point. At least we should be careful with the mfn to
vaddr conversion because mfn_to_maddr returns a paddr_t which is 64-bit
and vaddr_t is 32-bit. I imagine that theoretically, even with
system_state == SYS_STATE_early_boot, it could get truncated with the
wrong combination of mfn and phys_offset.

If nothing else, maybe we should add a truncation check for safety?


Except that phys_offset is not defined correctly, so your check below will
break some setup :(. Let's take the following example:

 Xen is loaded at PA 0x10

The boot offset is computed using 32-bit address (see head.S):
  PA - VA = 0x10 - 0x20
  = 0xfff0

This value will be passed to C code as an unsigned long. But then we will
store it in a uint64_t/paddr_t (see phys_offset which is set in
setup_page_tables). Because this is a conversion from unsigned to
unsigned,
the "sign bit" will not be propagated.

This means that phys_offset will be equal to 0xfff0 and not
0xfff0!

Therefore if we try to convert 0x10 (where Xen has been loaded) back
to
its VA, the resulting value will be 0x00200100.

Looking at the code, I think pte_of_xenaddr() has also the exact problem.
:(


One way to fix it would be to change phys_offset to register_t (or just
declare it as unsigned long on arm32 and unsigned long long on arm64):


sizeof (unsigned long) = 32 (resp. 64) on Arm32 (resp. arm64). This is what we
already rely on for boot_phys_offset (see setup_pagetables). So I am not sure
why phys_offset needs to be defined differently.

An alternative is to use vaddr_t.


Yes, I meant like vaddr_t or just "unsigned long" like boot_phys_offset.
Even with your latest patch
(https://marc.info/?l=xen-devel=157073004830894) which I like as a way
to solve the original GRUB booting issue, it looks like we also need to
change phys_addr to unsigned long to fix other arm32 problems.

Are you going to send the patch for that too?


I am looking at dropping phys_offset completely.

Regarding Xen 4.13, the issue would only happen if you place Xen below 2MB on 
Arm32. Yet, I believe this works fine because of side effect (MFN can only be 
32-bit).


This is not pretty, but I don't view this as critical to fix for Xen 4.13. So I 
am thinking to defer this post 4.13.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic

[Ian Jackson]

Andrew Cooper writes ("Re: [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul 
passthrough setting logic"):
> On 10/10/2019 16:11, Ian Jackson wrote:
> > +if (c_info->passthrough == LIBXL_PASSTHROUGH_DISABLED && need_pt) {
> > +LOGD(ERROR, domid,
> > + "passthrough disabled but devices are specified");
> 
> This is the only log message which isn't prefixed with ERROR:

I will strip the ERROR: out of the others.  I think I inherited them
from when this code was in xl, where it's just fprintf stderr.  Here
the priority is an argument to LOGD.

> > +const char *whynot_pt_share =
> > +c_info->type == LIBXL_DOMAIN_TYPE_PV ? "not valid for PV domain" :
> > +!physinfo.cap_iommu_hap_pt_share ? "not supported on this 
> > platform" :
> > +NULL;
> 
> This is a little more complicated.

I aimed to replicate the logic prior to my series.  FTAOD I think this
means this was already broken in xl ?  Anyway:

> For ARM, doesn't libxl treat guests as PV, or has that been fixed now? 
> ARM's only passthrough mode is PT_SHARE.

I think this means that I need to move the calculation of
whynot_pt_share into arch-specific code.  I'll wait and see what ARM
folks say.

> On x86 for PVH, passthrough doesn't work yet.  This may not be an
> argument against constructing the guest suitably, but we should check
> that things don't explode in new and interesting ways from this change.

If we know it doesn't work, it's not a good idea to accept it.  I will
arrange to reject it.

> For x86 HVM, PT_SHARE is only available for HAP guests, so shadow guests
> must use PT_SYNC.

I will add a check for c_info->hap.

> > +/* An explicit setting should now have been chosen */
> > +assert(c_info->passthrough != LIBXL_PASSTHROUGH_UNKNOWN);
> > +assert(c_info->passthrough != LIBXL_PASSTHROUGH_ENABLED);
> 
> This is confusing.  I think it would help if ...
...
> ... this had a comment explaining enabled is just interim value.
> 
> (2, "enabled"), # becomes {sync,share}_pt once defaults are evaluated

Good idea, thanks.

Ian.

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

Re: [Xen-devel] [PATCH v2 1/2] x2APIC: translate IO-APIC entries when enabling the IOMMU

[Jan Beulich]

On 11.10.2019 11:28, Roger Pau Monné  wrote:
> On Fri, Oct 11, 2019 at 09:52:35AM +0200, Jan Beulich wrote:
>> On 10.10.2019 17:19, Roger Pau Monné  wrote:
>>> On Thu, Oct 10, 2019 at 03:46:45PM +0200, Jan Beulich wrote:
 On 10.10.2019 15:12, Roger Pau Monné  wrote:
> On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
>> On 10.10.2019 14:13, Roger Pau Monné  wrote:
>>> On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
 On 10.10.2019 13:33, Roger Pau Monne wrote:
> When interrupt remapping is enabled as part of enabling x2APIC the

 Perhaps "unmasked" instead of "the"?

> IO-APIC entries also need to be translated to the new format and added
> to the interrupt remapping table.
>
> This prevents IOMMU interrupt remapping faults when booting on
> hardware that has unmasked IO-APIC pins.

 But in the end it only papers over whatever the spurious interrupts
 result form, doesn't it? Which isn't to say this isn't an
 improvement. Calling out the ExtInt case here may be worthwhile as
 well, as would be pointing out that this case still won't work on
 AMD IOMMUs.
>>>
>>> But the fix for the ExtINT AMD issue should be done in
>>> amd_iommu_ioapic_update_ire then, so that it can properly handle
>>> ExtINT delivery mode, not to this part of the code. I will look
>>> into it, but I think it's kind of tangential to the issue here.
>>
>> I'm not talking of you working on fixing this right away. I'm merely
>> asking that you mention here (a) the ExtInt special case and (b)
>> that this special case will (continue to) not work in the AMD case.
>>
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -515,7 +515,7 @@ static void resume_x2apic(void)
>  iommu_enable_x2apic();
>  __enable_x2apic();
>  
> -restore_IO_APIC_setup(ioapic_entries);
> +restore_IO_APIC_setup(ioapic_entries, true);
>  unmask_8259A();
>  
>  out:
> @@ -961,7 +961,12 @@ void __init x2apic_bsp_setup(void)
>  printk("Switched to APIC driver %s\n", genapic.name);
>  
>  restore_out:
> -restore_IO_APIC_setup(ioapic_entries);
> +/*
> + * NB: do not use raw mode when restoring entries if the iommu 
> has been
> + * enabled during the process, because the entries need to be 
> translated
> + * and added to the remapping table in that case.
> + */
> +restore_IO_APIC_setup(ioapic_entries, !x2apic_enabled);

 How is this different in the resume_x2apic() case? The IOMMU gets
 enabled in the course of that as well. I.e. I'd expect you want
 to pass "false" there, not "true".
>>>
>>> In the resume_x2apic case interrupt remapping should already be
>>> enabled or not, but that function is not going to enable interrupt
>>> remapping if it wasn't enabled before, hence the IO-APIC entries
>>> should already be using the interrupt remapping table and no
>>> translation is needed.
>>
>> Who / what would have enabled the IOMMU in the resume case?
>
> I don't think the question is who enables interrupt remapping in the
> resume case (which is resume_x2apic when calling iommu_enable_x2apic
> AFAICT), the point here is that on resume the entries in the IO-APIC
> will already match the state of interrupt remapping, so they shouldn't
> be translated. If interrupt remapping was off before suspend it will
> still be off after resume, and there won't be any translation needed.
> The same is true if interrupt remapping is on before suspend.

 I disagree: save_IO_APIC_setup() gets called from resume_x2apic(),
 not prior to suspend.
>>>
>>> Oh, so maybe that's a misunderstanding on my side. I don't seem to be
>>> able to find a statement about the contents of the IO-APIC registers
>>> (and more specifically the entries) when getting back from
>>> suspension. Are all entries cleared and masked?
>>>
>>> Are the values previous to suspension stored?
>>
>> See ioapic_suspend() / ioapic_resume(): Looks like there's some
>> redundancy here - I don't think it makes sense for the LAPIC
>> code to fiddle with all the RTEs if subsequently (I assume;
>> didn't check) they'll all be overwritten anyway. I would seem
>> more logical to me if they'd just all get masked for IOMMU
>> enabling, deferring to ioapic_resume() for everything else.
> 
> Yes, it seems like resume_x2apic shouldn't need to play with the
> entries at all TBH, just enabling interrupt remapping should be enough
> given that the entries are already save and restored by
> ioapic_{suspend/resume}.
> 
> Would you agree to leave that as-is in this patch, ie: always pass
> 

Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early

[Xia, Hongyan]

Not commenting on the patch, but I had exactly the same problem when
removing the direct map in x86. map_domain_page has to be usable
without the direct map and even before alloc_boot_pages can be used (so
that I can map the bootmem_regions_list, although I have made it
statically allocated now).

The direct map teardown series in the end introduces a persistent
mapping infrastructure to map page tables which occupies a few fixmap
entries, and avoid set_fixmap but instead modify the entries directly
to avoid invocation loops. The result is that map_xen_pagetable and
map_domain_page is usable from the very beginning of start_xen.

Hongyan

On Tue, 2019-09-17 at 17:02 +0100, Julien Grall wrote:
> The current implementations of xen_{map, unmap}_table() expect
> {map, unmap}_domain_page() to be usable. Those helpers are used to
> map/unmap page tables while update Xen page-tables.
> 
> Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update
> in
> {set, clear}_fixmap()", setup_fixmap() will make use of the helpers
> mentioned above. When booting Xen using GRUB, setup_fixmap() may be
> used
> before map_domain_page() can be called. This will result to data
> abort:
> 
> (XEN) Data Abort Trap. Syndrome=0x5
> (XEN) CPU0: Unexpected Trap: Data Abort
> 
> [...]
> 
> (XEN) Xen call trace:
> (XEN)[<0025ab6c>] mm.c#xen_pt_update+0x2b4/0x59c (PC)
> (XEN)[<0025ab20>] mm.c#xen_pt_update+0x268/0x59c (LR)
> (XEN)[<0025ae70>] set_fixmap+0x1c/0x2c
> (XEN)[<002a9c98>] copy_from_paddr+0x7c/0xdc
> (XEN)[<002a4ae0>] has_xsm_magic+0x18/0x34
> (XEN)[<002a5b5c>] bootfdt.c#early_scan_node+0x398/0x560
> (XEN)[<002a5de0>] device_tree_for_each_node+0xbc/0x144
> (XEN)[<002a5ed4>] boot_fdt_info+0x6c/0x260
> (XEN)[<002ac0d0>] start_xen+0x108/0xc74
> (XEN)[<0020044c>] arm64/head.o#paging+0x60/0x88
> 
> During early boot, the page tables are either statically allocated in
> Xen binary or allocated via alloc_boot_pages().
> 
> For statically allocated page-tables, they will already be mapped as
> part of Xen binary. So we can easily find the virtual address.
> 
> For dynamically allocated page-tables, we need to rely
> map_domain_page() to be functionally working.
> 
> For arm32, the call will be usable much before page can be
> dynamically
> allocated (see setup_pagetables()). For arm64, the call will be
> usable
> after setup_xenheap_mappings().
> 
> In both cases, memory are given to the boot allocator afterwards. So
> we
> can rely on map_domain_page() for mapping page tables allocated
> dynamically.
> 
> The helpers xen_{map, unmap}_table() are now updated to take into
> account the case where page-tables are part of Xen binary.
> 
> Fixes: 022387ee1a ('xen/arm: mm: Don't open-code Xen PT update in
> {set, clear}_fixmap()')
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/mm.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index e1cdeaaf2f..da6303a8fd 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -950,11 +950,31 @@ static int create_xen_table(lpae_t *entry)
>  
>  static lpae_t *xen_map_table(mfn_t mfn)
>  {
> +/*
> + * We may require to map the page table before map_domain_page()
> is
> + * useable. The requirements here is it must be useable as soon
> as
> + * page-tables are allocated dynamically via alloc_boot_pages().
> + */
> +if ( system_state == SYS_STATE_early_boot )
> +{
> +vaddr_t va = mfn_to_maddr(mfn) - phys_offset;
> +
> +if ( is_kernel(va) )
> +return (lpae_t *)va;
> +}
> +
>  return map_domain_page(mfn);
>  }
>  
>  static void xen_unmap_table(const lpae_t *table)
>  {
> +/*
> + * During early boot, xen_map_table() will not use
> map_domain_page()
> + * for page-tables residing in Xen binary. So skip the unmap
> part.
> + */
> +if ( system_state == SYS_STATE_early_boot && is_kernel(table) )
> +return;
> +
>  unmap_domain_page(table);
>  }
>  
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic

[Andrew Cooper]

On 10/10/2019 16:11, Ian Jackson wrote:
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 69971c97b6..fccb6a6271 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -968,6 +957,50 @@ int libxl__domain_config_setdefault(libxl__gc *gc,
>  goto error_out;
>  }
>  
> +bool need_pt = d_config->num_pcidevs || d_config->num_dtdevs;
> +if (c_info->passthrough == LIBXL_PASSTHROUGH_UNKNOWN) {
> +c_info->passthrough = need_pt
> +? LIBXL_PASSTHROUGH_ENABLED : LIBXL_PASSTHROUGH_DISABLED;
> +}
> +
> +bool iommu_enabled = physinfo.cap_hvm_directio;
> +if (c_info->passthrough != LIBXL_PASSTHROUGH_DISABLED && !iommu_enabled) 
> {
> +LOGD(ERROR, domid,
> + "ERROR: passthrough not supported on this platform\n");
> +ret = ERROR_INVAL;
> +goto error_out;
> +}
> +
> +if (c_info->passthrough == LIBXL_PASSTHROUGH_DISABLED && need_pt) {
> +LOGD(ERROR, domid,
> + "passthrough disabled but devices are specified");

This is the only log message which isn't prefixed with ERROR:

> +ret = ERROR_INVAL;
> +goto error_out;
> +}
> +
> +const char *whynot_pt_share =
> +c_info->type == LIBXL_DOMAIN_TYPE_PV ? "not valid for PV domain" :
> +!physinfo.cap_iommu_hap_pt_share ? "not supported on this platform" :
> +NULL;

This is a little more complicated.

For ARM, doesn't libxl treat guests as PV, or has that been fixed now? 
ARM's only passthrough mode is PT_SHARE.

On x86 for PVH, passthrough doesn't work yet.  This may not be an
argument against constructing the guest suitably, but we should check
that things don't explode in new and interesting ways from this change.

For x86 HVM, PT_SHARE is only available for HAP guests, so shadow guests
must use PT_SYNC.


> +
> +if (c_info->passthrough == LIBXL_PASSTHROUGH_ENABLED) {
> +assert(iommu_enabled);
> +c_info->passthrough = whynot_pt_share
> +? LIBXL_PASSTHROUGH_SYNC_PT : LIBXL_PASSTHROUGH_SHARE_PT;
> +}
> +
> +if (c_info->passthrough == LIBXL_PASSTHROUGH_SHARE_PT && 
> whynot_pt_share) {
> +LOGD(ERROR, domid,
> + "ERROR: passthrough=\"share_pt\" %s\n",
> + whynot_pt_share);
> +ret = ERROR_INVAL;
> +goto error_out;
> +}
> +
> +/* An explicit setting should now have been chosen */
> +assert(c_info->passthrough != LIBXL_PASSTHROUGH_UNKNOWN);
> +assert(c_info->passthrough != LIBXL_PASSTHROUGH_ENABLED);

This is confusing.  I think it would help if ...

> +
>  /* If target_memkb is smaller than max_memkb, the subsequent call
>   * to libxc when building HVM domain will enable PoD mode.
>   */
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 3ac9494b80..2441c0c233 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -266,8 +266,9 @@ libxl_vkb_backend = Enumeration("vkb_backend", [
>  libxl_passthrough = Enumeration("passthrough", [
>  (0, "unknown"),
>  (1, "disabled"),
> -(2, "sync_pt"),
> -(3, "share_pt"),
> +(2, "enabled"),
> +(3, "sync_pt"),
> +(4, "share_pt"),

... this had a comment explaining enabled is just interim value.

(2, "enabled"), # becomes {sync,share}_pt once defaults are evaluated

~Andrew

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

Re: [Xen-devel] [PATCH v2 1/2] x2APIC: translate IO-APIC entries when enabling the IOMMU

[Roger Pau Monné]

On Fri, Oct 11, 2019 at 09:52:35AM +0200, Jan Beulich wrote:
> On 10.10.2019 17:19, Roger Pau Monné  wrote:
> > On Thu, Oct 10, 2019 at 03:46:45PM +0200, Jan Beulich wrote:
> >> On 10.10.2019 15:12, Roger Pau Monné  wrote:
> >>> On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
>  On 10.10.2019 14:13, Roger Pau Monné  wrote:
> > On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
> >> On 10.10.2019 13:33, Roger Pau Monne wrote:
> >>> When interrupt remapping is enabled as part of enabling x2APIC the
> >>
> >> Perhaps "unmasked" instead of "the"?
> >>
> >>> IO-APIC entries also need to be translated to the new format and added
> >>> to the interrupt remapping table.
> >>>
> >>> This prevents IOMMU interrupt remapping faults when booting on
> >>> hardware that has unmasked IO-APIC pins.
> >>
> >> But in the end it only papers over whatever the spurious interrupts
> >> result form, doesn't it? Which isn't to say this isn't an
> >> improvement. Calling out the ExtInt case here may be worthwhile as
> >> well, as would be pointing out that this case still won't work on
> >> AMD IOMMUs.
> >
> > But the fix for the ExtINT AMD issue should be done in
> > amd_iommu_ioapic_update_ire then, so that it can properly handle
> > ExtINT delivery mode, not to this part of the code. I will look
> > into it, but I think it's kind of tangential to the issue here.
> 
>  I'm not talking of you working on fixing this right away. I'm merely
>  asking that you mention here (a) the ExtInt special case and (b)
>  that this special case will (continue to) not work in the AMD case.
> 
> >>> --- a/xen/arch/x86/apic.c
> >>> +++ b/xen/arch/x86/apic.c
> >>> @@ -515,7 +515,7 @@ static void resume_x2apic(void)
> >>>  iommu_enable_x2apic();
> >>>  __enable_x2apic();
> >>>  
> >>> -restore_IO_APIC_setup(ioapic_entries);
> >>> +restore_IO_APIC_setup(ioapic_entries, true);
> >>>  unmask_8259A();
> >>>  
> >>>  out:
> >>> @@ -961,7 +961,12 @@ void __init x2apic_bsp_setup(void)
> >>>  printk("Switched to APIC driver %s\n", genapic.name);
> >>>  
> >>>  restore_out:
> >>> -restore_IO_APIC_setup(ioapic_entries);
> >>> +/*
> >>> + * NB: do not use raw mode when restoring entries if the iommu 
> >>> has been
> >>> + * enabled during the process, because the entries need to be 
> >>> translated
> >>> + * and added to the remapping table in that case.
> >>> + */
> >>> +restore_IO_APIC_setup(ioapic_entries, !x2apic_enabled);
> >>
> >> How is this different in the resume_x2apic() case? The IOMMU gets
> >> enabled in the course of that as well. I.e. I'd expect you want
> >> to pass "false" there, not "true".
> >
> > In the resume_x2apic case interrupt remapping should already be
> > enabled or not, but that function is not going to enable interrupt
> > remapping if it wasn't enabled before, hence the IO-APIC entries
> > should already be using the interrupt remapping table and no
> > translation is needed.
> 
>  Who / what would have enabled the IOMMU in the resume case?
> >>>
> >>> I don't think the question is who enables interrupt remapping in the
> >>> resume case (which is resume_x2apic when calling iommu_enable_x2apic
> >>> AFAICT), the point here is that on resume the entries in the IO-APIC
> >>> will already match the state of interrupt remapping, so they shouldn't
> >>> be translated. If interrupt remapping was off before suspend it will
> >>> still be off after resume, and there won't be any translation needed.
> >>> The same is true if interrupt remapping is on before suspend.
> >>
> >> I disagree: save_IO_APIC_setup() gets called from resume_x2apic(),
> >> not prior to suspend.
> > 
> > Oh, so maybe that's a misunderstanding on my side. I don't seem to be
> > able to find a statement about the contents of the IO-APIC registers
> > (and more specifically the entries) when getting back from
> > suspension. Are all entries cleared and masked?
> > 
> > Are the values previous to suspension stored?
> 
> See ioapic_suspend() / ioapic_resume(): Looks like there's some
> redundancy here - I don't think it makes sense for the LAPIC
> code to fiddle with all the RTEs if subsequently (I assume;
> didn't check) they'll all be overwritten anyway. I would seem
> more logical to me if they'd just all get masked for IOMMU
> enabling, deferring to ioapic_resume() for everything else.

Yes, it seems like resume_x2apic shouldn't need to play with the
entries at all TBH, just enabling interrupt remapping should be enough
given that the entries are already save and restored by
ioapic_{suspend/resume}.

Would you agree to leave that as-is in this patch, ie: always pass
true to restore_IO_APIC_setup in resume_x2apic?

> >> Also how 

Re: [Xen-devel] [XEN PATCH for-4.13 v2 7/9] libxl: create: setdefault: Make libxl_physinfo info[1]

[Wei Liu]

On Thu, Oct 10, 2019 at 04:11:09PM +0100, Ian Jackson wrote:
> No functional change.  This will let us make it into a pointer without
> textual change other than to the definition.
> 
> While we are here, fix some style errors (missing { }).
> 
> Signed-off-by: Ian Jackson 


Acked-by: Wei Liu 

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

Re: [Xen-devel] [XEN PATCH for-4.13 v2 9/9] libxl/xl: Overhaul passthrough setting logic

[Wei Liu]

On Thu, Oct 10, 2019 at 04:11:11PM +0100, Ian Jackson wrote:
> LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
> version of this code) is doing double duty.  We actually need all of
> the following to be specificable:
>   * default ("unknown"): enable PT iff we have devices to
> pass through specified in the initial config file.
>   * "enabled" (and fail if the platform doesn't support it).
>   * "disabled" (and reject future PT hotplug).
>   * "share_pt"/"sync_pt": enable PT and set a specific PT mode.
> 
> Defaulting and error checking should be done in libxl.  So, we make
> several changes here.
> 
> We introduce "enabled".  (And we document "unknown".)
> 
> We move all of the error checking and defaulting code from xl into
> libxl.  Now, libxl__domain_config_setdefault has all of the necessary
> information to get this right.  So we can do it all there, in one
> place.
> 
> We can also arrange to have only one place each which calculates
> (i) whether passthrough needs to be enabled because pt devices were
> specified (ii) whether pt_share can be used.
> 
> xl now only has to parse the enum in the same way as it parses all
> other enums.
> 
> This change fixes a regression from earlier 4.13-pre: until recent
> changes, passthrough was only enabled by default if passthrough
> devices were specified.  We restore this behaviour.
> 
> This will hide, from the point of view of libvirt tests in osstest, a
> separate hypervisor regression which prevents migration of a domain
> with passthrough enabled but without actual PT devices.

I think Jan committed a patch to fix that, so this may need deleting.

I will let Jan and Paul confirm this.

Wei.

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

Re: [Xen-devel] [XEN PATCH for-4.13 v2 8/9] libxl: create: setdefault: Move physinfo into config_setdefault

[Wei Liu]

On Thu, Oct 10, 2019 at 04:11:10PM +0100, Ian Jackson wrote:
> No functional change.  This will let us refer to it in code we are
> about to add to this function.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Jan Beulich]

On 10.10.2019 20:30, Lars Kurth wrote:
> On 10/10/2019, 18:05, "Andrew Cooper"  wrote:
> On 10/10/2019 13:34, Lars Kurth wrote:
> > Existing formats and licenses
> > * Hypercall ABI Documentation generated from Xen public headers
> > Format: kerndoc
> > License: typically BSD-3-Clause (documentation is generated from public 
> headers)
> 
> Its homegrown markup, superimposed on what used to be doxygen in
> the past.
> 
> Oh, I forgot
> 
> I wasn't planning on reusing any of the markup, and wasn't expecting to
> use much of the text either.  I'm still considering the option of
> defining that xen/public/* isn't the canonical description of the ABI,
> because C is the wrong tool for the job.
> 
> Its fine to provide a C set of headers implementing an ABI, but there is
> a very deliberate reason why the canonical migration v2 spec is in a
> text document.
> 
> @Stefano: as you and I believe Brian will be spending time on improving the
> ABI docs, I think we need to build some agreement here on what/how
> to do it. I was assuming that generally the consensus was to have
> docs close to the code in source, but this does not seem to be the case.

Well, for migration v2 having the spec in a text file seems sensible
to me. For the public ABI, however, I think it's more helpful to have
the doc next to the actual definitions. Considering the possible use
of languages other than C I can certainly see why separating both
would be even more clean, but I think here we want to weigh practical
purposes against cleanliness.

Jan

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

Re: [Xen-devel] [PATCH v2 1/2] x2APIC: translate IO-APIC entries when enabling the IOMMU

[Jan Beulich]

On 10.10.2019 17:19, Roger Pau Monné  wrote:
> On Thu, Oct 10, 2019 at 03:46:45PM +0200, Jan Beulich wrote:
>> On 10.10.2019 15:12, Roger Pau Monné  wrote:
>>> On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
 On 10.10.2019 14:13, Roger Pau Monné  wrote:
> On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
>> On 10.10.2019 13:33, Roger Pau Monne wrote:
>>> When interrupt remapping is enabled as part of enabling x2APIC the
>>
>> Perhaps "unmasked" instead of "the"?
>>
>>> IO-APIC entries also need to be translated to the new format and added
>>> to the interrupt remapping table.
>>>
>>> This prevents IOMMU interrupt remapping faults when booting on
>>> hardware that has unmasked IO-APIC pins.
>>
>> But in the end it only papers over whatever the spurious interrupts
>> result form, doesn't it? Which isn't to say this isn't an
>> improvement. Calling out the ExtInt case here may be worthwhile as
>> well, as would be pointing out that this case still won't work on
>> AMD IOMMUs.
>
> But the fix for the ExtINT AMD issue should be done in
> amd_iommu_ioapic_update_ire then, so that it can properly handle
> ExtINT delivery mode, not to this part of the code. I will look
> into it, but I think it's kind of tangential to the issue here.

 I'm not talking of you working on fixing this right away. I'm merely
 asking that you mention here (a) the ExtInt special case and (b)
 that this special case will (continue to) not work in the AMD case.

>>> --- a/xen/arch/x86/apic.c
>>> +++ b/xen/arch/x86/apic.c
>>> @@ -515,7 +515,7 @@ static void resume_x2apic(void)
>>>  iommu_enable_x2apic();
>>>  __enable_x2apic();
>>>  
>>> -restore_IO_APIC_setup(ioapic_entries);
>>> +restore_IO_APIC_setup(ioapic_entries, true);
>>>  unmask_8259A();
>>>  
>>>  out:
>>> @@ -961,7 +961,12 @@ void __init x2apic_bsp_setup(void)
>>>  printk("Switched to APIC driver %s\n", genapic.name);
>>>  
>>>  restore_out:
>>> -restore_IO_APIC_setup(ioapic_entries);
>>> +/*
>>> + * NB: do not use raw mode when restoring entries if the iommu has 
>>> been
>>> + * enabled during the process, because the entries need to be 
>>> translated
>>> + * and added to the remapping table in that case.
>>> + */
>>> +restore_IO_APIC_setup(ioapic_entries, !x2apic_enabled);
>>
>> How is this different in the resume_x2apic() case? The IOMMU gets
>> enabled in the course of that as well. I.e. I'd expect you want
>> to pass "false" there, not "true".
>
> In the resume_x2apic case interrupt remapping should already be
> enabled or not, but that function is not going to enable interrupt
> remapping if it wasn't enabled before, hence the IO-APIC entries
> should already be using the interrupt remapping table and no
> translation is needed.

 Who / what would have enabled the IOMMU in the resume case?
>>>
>>> I don't think the question is who enables interrupt remapping in the
>>> resume case (which is resume_x2apic when calling iommu_enable_x2apic
>>> AFAICT), the point here is that on resume the entries in the IO-APIC
>>> will already match the state of interrupt remapping, so they shouldn't
>>> be translated. If interrupt remapping was off before suspend it will
>>> still be off after resume, and there won't be any translation needed.
>>> The same is true if interrupt remapping is on before suspend.
>>
>> I disagree: save_IO_APIC_setup() gets called from resume_x2apic(),
>> not prior to suspend.
> 
> Oh, so maybe that's a misunderstanding on my side. I don't seem to be
> able to find a statement about the contents of the IO-APIC registers
> (and more specifically the entries) when getting back from
> suspension. Are all entries cleared and masked?
> 
> Are the values previous to suspension stored?

See ioapic_suspend() / ioapic_resume(): Looks like there's some
redundancy here - I don't think it makes sense for the LAPIC
code to fiddle with all the RTEs if subsequently (I assume;
didn't check) they'll all be overwritten anyway. I would seem
more logical to me if they'd just all get masked for IOMMU
enabling, deferring to ioapic_resume() for everything else.

>> Also how would "x2apic_enabled" reflect the transition? It may
>> have been "true" already before entering the function here.
>
> If x2apic_enabled == true at the point where restore_IO_APIC_setup
> is called interrupt remapping must be enabled, because AFAICT at this
> point it's not possible to have x2apic_enabled == true and interrupt
> remapping disabled.
>
> The issue I can see here is what happens if interrupt remapping was
> already enabled by the hardware, and entries in the IO-APIC are
> already using the remapping table. I would have to 

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

[osstest service owner]

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

Regressions :-(

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

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