[ovmf test] 182393: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 00b51e0d78a547dd78119ec44fcc74a01b6f79c8
baseline version:
 ovmf 48089f3a7cdf308651234f5bf8d8a301f4b8acf9

Last test of basis   182383  2023-08-18 12:42:20 Z0 days
Testing same since   182393  2023-08-19 03:40:57 Z0 days1 attempts


People who touched revisions under test:
  Leif Lindholm 
  Oliver Smith-Denny 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   48089f3a7c..00b51e0d78  00b51e0d78a547dd78119ec44fcc74a01b6f79c8 -> 
xen-tested-master

[xen-unstable test] 182387: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  5cd6585177e99947a5f62345edbe657663ad9fcc
baseline version:
 xen  38ba0466a1e262edd031500d24919fbf4e48c794

Last test of basis   182377  2023-08-18 05:14:40 Z0 days
Testing same since   182387  2023-08-18 18:08:44 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jens Wiklander 
  Juergen Gross 
  

[linux-linus test] 182378: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 18 guest-localmigrate/x10 
fail REGR. vs. 182357

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-credit2 20 guest-localmigrate/x10 fail pass in 
182390-retest
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail pass in 
182390-retest
 test-amd64-amd64-xl-credit1  23 guest-start.2   fail pass in 182390-retest

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

version targeted for testing:
 linux0e8860d2125f51ba9bca67a520d826cb8f66cf42
baseline version:
 linux4853c74bd7ab7fdb83f319bd9ace8a08c031e9b6

Last test of basis   182357  2023-08-16 07:44:20 Z2 days
Failing since182371  2023-08-17 15:10:27 Z1 days3 attempts
Testing same since   182378  2023-08-18 08:43:36 Z0 days1 attempts


People who touched revisions under test:
  Abel Wu 
  Aleksandr Loktionov 
  Alex Deucher 
 

[PATCH] docs/misra: add exceptions to rules

[Stefano Stabellini]

From: Stefano Stabellini 

During the discussions that led to the acceptable of the Rules, we
decided on a few exceptions that were not properly recorded in
rules.rst. Other times, the exceptions were decided later when it came
to enabling a rule in ECLAIR.

Either way, update rules.rst with appropriate notes.

Signed-off-by: Stefano Stabellini 
---
Note that there might be more to add, but the below look correct to me
---
 docs/misra/rules.rst | 41 +
 1 file changed, 33 insertions(+), 8 deletions(-)

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 8f0e4d3f25..ecbb04da96 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -59,7 +59,8 @@ maintainers if you want to suggest a change.
  - Required
  - Precautions shall be taken in order to prevent the contents of a
header file being included more than once
- -
+ - Files that are intended to be included more than once do not need to
+   conform to the directive (e.g. autogenerated or empty header files)
 
* - `Dir 4.11 
`_
  - Required
@@ -106,7 +107,23 @@ maintainers if you want to suggest a change.
* - `Rule 2.1 
`_
  - Required
  - A project shall not contain unreachable code
- -
+ - The following are allowed:
+ - Invariantly constant conditions (e.g. while(0) { S; })
+ - Switch with a controlling value incompatible with labeled
+   statements
+ - Functions that are intended to be never referenced from C
+   code, or are referenced in builds not under analysis (e.g.
+   'do_trap_fiq' for the former and 'check_for_unexpected_msi'
+   for the latter)
+ - Unreachability caused by the following macros/functions is
+   deliberate: BUG, assert_failed, ERROR_EXIT, ERROR_EXIT_DOM,
+   PIN_FAIL, __builtin_unreachable, panic, do_unexpected_trap,
+   machine_halt, machine_restart, machine_reboot,
+   ASSERT_UNREACHABLE
+ - asm-offsets.c, as they are not linked deliberately, because
+   they are used to generate definitions for asm modules
+ - pure declarations (i.e. declarations without
+   initialization) are safe, as they are not executed
 
* - `Rule 2.6 
`_
  - Advisory
@@ -117,7 +134,7 @@ maintainers if you want to suggest a change.
  - Required
  - The character sequences /* and // shall not be used within a
comment
- -
+ - Comments containing hyperlinks inside C-style block comments are safe
 
* - `Rule 3.2 
`_
  - Required
@@ -167,7 +184,7 @@ maintainers if you want to suggest a change.
* - `Rule 5.6 
`_
  - Required
  - A typedef name shall be a unique identifier
- -
+ - BOOLEAN, UINT{8,32,64} and INT{8,32,64} are allowed
 
* - `Rule 6.1 
`_
  - Required
@@ -183,7 +200,10 @@ maintainers if you want to suggest a change.
* - `Rule 7.1 
`_
  - Required
  - Octal constants shall not be used
- -
+ - Usage of the following constants is safe, since they are given
+   as-is in the inflate algorithm specification and there is
+   therefore no risk of them being interpreted as decimal constants:
+   ^0(007|37|070|213|236|300|321|330|331|332|333|334|335|337|371)$
 
* - `Rule 7.2 
`_
  - Required
@@ -239,13 +259,16 @@ maintainers if you want to suggest a change.
  - Required
  - All declarations of an object or function shall use the same
names and type qualifiers
- -
+ - The type ret_t is deliberately used and defined as int or long
+   depending on the architecture
 
* - `Rule 8.4 
`_
  - Required
  - A compatible declaration shall be visible when an object or
function with external linkage is defined
- -
+ - Allowed exceptions: asm-offsets.c (definitions for asm modules
+   not called from C code), gcov_base.c (definitions only used in
+   non-release builds)
 
* - `Rule 8.5 
`_
  - Required
@@ -369,7 +392,9 @@ maintainers if you want to suggest a change.
  - Required
  - Expressions resulting from 

[XEN][PATCH v9 15/19] xen/arm: Implement device tree node removal functionalities

[Vikram Garhwal]

Introduce sysctl XEN_SYSCTL_dt_overlay to remove device-tree nodes added using
device tree overlay.

xl dt-overlay remove file.dtbo:
Removes all the nodes in a given dtbo.
First, removes IRQ permissions and MMIO accesses. Next, it finds the nodes
in dt_host and delete the device node entries from dt_host.

The nodes get removed only if it is not used by any of dom0 or domio.

Also, added overlay_track struct to keep the track of added node through device
tree overlay. overlay_track has dt_host_new which is unflattened form of updated
fdt and name of overlay nodes. When a node is removed, we also free the memory
used by overlay_track for the particular overlay node.

Nested overlay removal is supported in sequential manner only i.e. if
overlay_child nests under overlay_parent, it is assumed that user first removes
overlay_child and then removes overlay_parent.
Also, this is an experimental feature so it is expected from user to make sure
correct device tree overlays are used when adding nodes and making sure devices
are not being used by other domain before removing them from Xen tree.
Partially added/removed i.e. failures while removing the overlay may cause other
failures and might need a system reboot.

Signed-off-by: Vikram Garhwal 

---
Changes from v8:
Remove IRQs and IOMMU entries using rangesets instead of parsing each node.
Changes from v7:
Add dt-overlay.c in MAINTAINERS.
Add comments for dt_overlay_remove_node.
Rename handle_remove_irq_iommu() to remove_resources().
Add comment regarding false mapping flag for reason behind not removing the
mapping..
Remove irq_access_premitted() check.
Add error handling for remove_all_descendant_nodes
Change read_lock with write_lock.
Remove check_overlay_fdt() call from handle_remove_overlay_nodes().
Re-organize dt_sysctl and reutnr -EOPNOSTSUPP for error cases. Also, renamed
this function to dt_overlay_sysctl.
Remove unnecessary header includes in dt-overlay.h
Correct indentation and make func   tion inputs const wherever possible.
Make overlay_fdt const_void inside xen_sysctl_dt_overlay{}.
Add comment regarding why we not removing IRQ and MMIO mappings.
Move overlay_node_count() out of this patch as it's not being used here
anymore.
Changes from v6:
Add explicit padding for xen_system_dt_overlay{}
Update license.
Rearrange xfree in dt_sysctl()
Update overlay_track struct comment with relevant message.
Fix missing xen/errno.h for builds without CONFIG_OVERLAY_DTB cases.
Fix header formatting.
---
---
 MAINTAINERS  |   1 +
 xen/arch/arm/sysctl.c|  16 +-
 xen/common/Makefile  |   1 +
 xen/common/dt-overlay.c  | 402 +++
 xen/include/public/sysctl.h  |  24 +++
 xen/include/xen/dt-overlay.h |  63 ++
 6 files changed, 506 insertions(+), 1 deletion(-)
 create mode 100644 xen/common/dt-overlay.c
 create mode 100644 xen/include/xen/dt-overlay.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a0805d35cd..c41a7c5440 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -301,6 +301,7 @@ M:  Julien Grall 
 S: Supported
 F: xen/common/libfdt/
 F: xen/common/device_tree.c
+F: xen/common/dt-overlay.c
 F: xen/include/xen/libfdt/
 F: xen/include/xen/device_tree.h
 F: xen/drivers/passthrough/device_tree.c
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index e9a0661146..5cda0dc674 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,7 +26,20 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 long arch_do_sysctl(struct xen_sysctl *sysctl,
 XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
-return -ENOSYS;
+long ret;
+
+switch ( sysctl->cmd )
+{
+case XEN_SYSCTL_dt_overlay:
+ret = dt_overlay_sysctl(>u.dt_overlay);
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+return ret;
 }
 
 /*
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 46049eac35..e7e96b1087 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
+obj-$(CONFIG_OVERLAY_DTB) += dt-overlay.o
 obj-y += event_2l.o
 obj-y += event_channel.o
 obj-y += event_fifo.o
diff --git a/xen/common/dt-overlay.c b/xen/common/dt-overlay.c
new file mode 100644
index 00..60bedf0852
--- /dev/null
+++ b/xen/common/dt-overlay.c
@@ -0,0 +1,402 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * xen/common/dt-overlay.c
+ *
+ * Device tree overlay support in Xen.
+ *
+ * Copyright (C) 2023, Advanced Micro Devices, Inc. All Rights Reserved.
+ * Written by Vikram Garhwal 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static 

[XEN][PATCH v9 18/19] tools/libs/light: Implement new libxl functions for device tree overlay ops

[Vikram Garhwal]

Signed-off-by: Vikram Garhwal 
Reviewed-by: Anthony PERARD 
---
 tools/include/libxl.h   | 11 +
 tools/libs/light/Makefile   |  3 ++
 tools/libs/light/libxl_dt_overlay.c | 71 +
 3 files changed, 85 insertions(+)
 create mode 100644 tools/libs/light/libxl_dt_overlay.c

diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index aa5b1c98d4..b4f2a69b34 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -259,6 +259,12 @@
  */
 #define LIBXL_HAVE_DEVICETREE_PASSTHROUGH 1
 
+#if defined(__arm__) || defined(__aarch64__)
+/**
+ * This means Device Tree Overlay is supported.
+ */
+#define LIBXL_HAVE_DT_OVERLAY 1
+#endif
 /*
  * libxl_domain_build_info has device_model_user to specify the user to
  * run the device model with. See docs/misc/qemu-deprivilege.txt.
@@ -2493,6 +2499,11 @@ libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, 
uint32_t domid,
 int *num);
 void libxl_device_pci_list_free(libxl_device_pci* list, int num);
 
+#if defined(__arm__) || defined(__aarch64__)
+int libxl_dt_overlay(libxl_ctx *ctx, void *overlay,
+ uint32_t overlay_size, uint8_t overlay_op);
+#endif
+
 /*
  * Turns the current process into a backend device service daemon
  * for a driver domain.
diff --git a/tools/libs/light/Makefile b/tools/libs/light/Makefile
index 5d7ff94b05..ba4c1b7933 100644
--- a/tools/libs/light/Makefile
+++ b/tools/libs/light/Makefile
@@ -112,6 +112,9 @@ OBJS-y += _libxl_types.o
 OBJS-y += libxl_flask.o
 OBJS-y += _libxl_types_internal.o
 
+# Device tree overlay is enabled only for ARM architecture.
+OBJS-$(CONFIG_ARM) += libxl_dt_overlay.o
+
 ifeq ($(CONFIG_LIBNL),y)
 CFLAGS_LIBXL += $(LIBNL3_CFLAGS)
 endif
diff --git a/tools/libs/light/libxl_dt_overlay.c 
b/tools/libs/light/libxl_dt_overlay.c
new file mode 100644
index 00..a6c709a6dc
--- /dev/null
+++ b/tools/libs/light/libxl_dt_overlay.c
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2021 Xilinx Inc.
+ * Author Vikram Garhwal 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * 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 Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxl_internal.h"
+#include 
+#include 
+
+static int check_overlay_fdt(libxl__gc *gc, void *fdt, size_t size)
+{
+int r;
+
+if (fdt_magic(fdt) != FDT_MAGIC) {
+LOG(ERROR, "Overlay FDT is not a valid Flat Device Tree");
+return ERROR_FAIL;
+}
+
+r = fdt_check_header(fdt);
+if (r) {
+LOG(ERROR, "Failed to check the overlay FDT (%d)", r);
+return ERROR_FAIL;
+}
+
+if (fdt_totalsize(fdt) > size) {
+LOG(ERROR, "Overlay FDT totalsize is too big");
+return ERROR_FAIL;
+}
+
+return 0;
+}
+
+int libxl_dt_overlay(libxl_ctx *ctx, void *overlay_dt, uint32_t 
overlay_dt_size,
+ uint8_t overlay_op)
+{
+int rc;
+int r;
+GC_INIT(ctx);
+
+if (check_overlay_fdt(gc, overlay_dt, overlay_dt_size)) {
+LOG(ERROR, "Overlay DTB check failed");
+rc = ERROR_FAIL;
+goto out;
+} else {
+LOG(DEBUG, "Overlay DTB check passed");
+rc = 0;
+}
+
+r = xc_dt_overlay(ctx->xch, overlay_dt, overlay_dt_size, overlay_op);
+
+if (r) {
+LOG(ERROR, "%s: Adding/Removing overlay dtb failed.", __func__);
+rc = ERROR_FAIL;
+}
+
+out:
+GC_FREE;
+return rc;
+}
+
-- 
2.17.1

[PATCH] docs/misra: document gcc-specific behavior with shifting signed integers

[Stefano Stabellini]

From: Stefano Stabellini 

Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- use "shift" instead of << or >>
- use All Architectures (I haven't changed all the other instances of
x86/arm in the file yet)
---
 docs/misra/C-language-toolchain.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/docs/misra/C-language-toolchain.rst 
b/docs/misra/C-language-toolchain.rst
index 785aed1eaf..f5ca7bd2c8 100644
--- a/docs/misra/C-language-toolchain.rst
+++ b/docs/misra/C-language-toolchain.rst
@@ -200,6 +200,12 @@ The table columns are as follows:
  - ARM64, X86_64
  - See Section "6.29 Designated Initializers" of GCC_MANUAL
 
+   * - Signed shift acts on negative numbers by sign extension
+ - All architectures
+ - See Section "4.5 Integers" of GCC_MANUAL. As an extension to the
+   C language, GCC does not use the latitude given in C99 and C11
+   only to treat certain aspects of signed shift as undefined.
+
 
 Translation Limits
 __
-- 
2.25.1

[XEN][PATCH v9 19/19] tools/xl: Add new xl command overlay for device tree overlay support

[Vikram Garhwal]

Signed-off-by: Vikram Garhwal 
Reviewed-by: Anthony PERARD 
---
 tools/xl/xl.h   |  1 +
 tools/xl/xl_cmdtable.c  |  6 +
 tools/xl/xl_vmcontrol.c | 52 +
 3 files changed, 59 insertions(+)

diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 72538d6a81..a923daccd3 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -138,6 +138,7 @@ int main_shutdown(int argc, char **argv);
 int main_reboot(int argc, char **argv);
 int main_list(int argc, char **argv);
 int main_vm_list(int argc, char **argv);
+int main_dt_overlay(int argc, char **argv);
 int main_create(int argc, char **argv);
 int main_config_update(int argc, char **argv);
 int main_button_press(int argc, char **argv);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 67604e9536..2463521156 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -631,6 +631,12 @@ const struct cmd_spec cmd_table[] = {
   "Issue a qemu monitor command to the device model of a domain",
   " ",
 },
+{ "dt-overlay",
+  _dt_overlay, 0, 1,
+  "Add/Remove a device tree overlay",
+  "add/remove <.dtbo>"
+  "-h print this help\n"
+},
 };
 
 const int cmdtable_len = ARRAY_SIZE(cmd_table);
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 03971927e9..cea5b4a88e 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -1265,6 +1265,58 @@ int main_create(int argc, char **argv)
 return 0;
 }
 
+int main_dt_overlay(int argc, char **argv)
+{
+const char *overlay_ops = NULL;
+const char *overlay_config_file = NULL;
+void *overlay_dtb = NULL;
+int rc;
+uint8_t op;
+int overlay_dtb_size = 0;
+const int overlay_add_op = 1;
+const int overlay_remove_op = 2;
+
+if (argc < 2) {
+help("dt_overlay");
+return EXIT_FAILURE;
+}
+
+overlay_ops = argv[1];
+overlay_config_file = argv[2];
+
+if (strcmp(overlay_ops, "add") == 0)
+op = overlay_add_op;
+else if (strcmp(overlay_ops, "remove") == 0)
+op = overlay_remove_op;
+else {
+fprintf(stderr, "Invalid dt overlay operation\n");
+return EXIT_FAILURE;
+}
+
+if (overlay_config_file) {
+rc = libxl_read_file_contents(ctx, overlay_config_file,
+  _dtb, _dtb_size);
+
+if (rc) {
+fprintf(stderr, "failed to read the overlay device tree file %s\n",
+overlay_config_file);
+free(overlay_dtb);
+return ERROR_FAIL;
+}
+} else {
+fprintf(stderr, "overlay dtbo file not provided\n");
+return ERROR_FAIL;
+}
+
+rc = libxl_dt_overlay(ctx, overlay_dtb, overlay_dtb_size, op);
+
+free(overlay_dtb);
+
+if (rc)
+return EXIT_FAILURE;
+
+return rc;
+}
 /*
  * Local variables:
  * mode: C
-- 
2.17.1

[XEN][PATCH v9 16/19] xen/arm: Implement device tree node addition functionalities

[Vikram Garhwal]

Update sysctl XEN_SYSCTL_dt_overlay to enable support for dtbo nodes addition
using device tree overlay.

xl dt-overlay add file.dtbo:
Each time overlay nodes are added using .dtbo, a new fdt(memcpy of
device_tree_flattened) is created and updated with overlay nodes. This
updated fdt is further unflattened to a dt_host_new. Next, it checks if any
of the overlay nodes already exists in the dt_host. If overlay nodes doesn't
exist then find the overlay nodes in dt_host_new, find the overlay node's
parent in dt_host and add the nodes as child under their parent in the
dt_host. The node is attached as the last node under target parent.

Finally, add IRQs, add device to IOMMUs, set permissions and map MMIO for 
the
overlay node.

When a node is added using overlay, a new entry is allocated in the
overlay_track to keep the track of memory allocation due to addition of overlay
node. This is helpful for freeing the memory allocated when a device tree node
is removed.

The main purpose of this to address first part of dynamic programming i.e.
making xen aware of new device tree node which means updating the dt_host with
overlay node information. Here we are adding/removing node from dt_host, and
checking/setting IOMMU and IRQ permission but never mapping them to any domain.
Right now, mapping/Un-mapping will happen only when a new domU is
created/destroyed using "xl create".

Signed-off-by: Vikram Garhwal 

---
Changes from v8:
Add rangeset to keep IRQs and IOMEM information.
Changes from v7:
Move overlay_node_count() in this patch.
Fix indent with goto statements.
Rename handle_add_irq_iommu() to add_resources().
Changes from v6:
Fix comment style and add comment regarding false flag in irq mapping.
Move malloc for nodes_full_path to handle_add_overlay_nodes.
Move node_num define to start of overlay_get_nodes_info().
Remove "domain *d" from handle_add_irq_iommu().
Fix error handling for handle_add_irq_iommu().
Split handle_add_overlay_nodes to two functions.
Create a separate function for freeing nodes_full_path.
Fix xfree for dt_sysctl.
---
---
 xen/common/dt-overlay.c | 599 
 1 file changed, 599 insertions(+)

diff --git a/xen/common/dt-overlay.c b/xen/common/dt-overlay.c
index 60bedf0852..8b47e41491 100644
--- a/xen/common/dt-overlay.c
+++ b/xen/common/dt-overlay.c
@@ -34,6 +34,25 @@ find_last_descendants_node(const struct dt_device_node 
*device_node)
 return child_node;
 }
 
+/*
+ * Returns next node to the input node. If node has children then return
+ * last descendant's next node.
+*/
+static struct dt_device_node *
+dt_find_next_node(struct dt_device_node *dt, const struct dt_device_node *node)
+{
+struct dt_device_node *np;
+
+dt_for_each_device_node(dt, np)
+if ( np == node )
+break;
+
+if ( np->child )
+np = find_last_descendants_node(np);
+
+return np->allnext;
+}
+
 static int dt_overlay_remove_node(struct dt_device_node *device_node)
 {
 struct dt_device_node *np;
@@ -111,6 +130,78 @@ static int dt_overlay_remove_node(struct dt_device_node 
*device_node)
 return 0;
 }
 
+static int dt_overlay_add_node(struct dt_device_node *device_node,
+   const char *parent_node_path)
+{
+struct dt_device_node *parent_node;
+struct dt_device_node *next_node;
+
+parent_node = dt_find_node_by_path(parent_node_path);
+
+if ( parent_node == NULL )
+{
+dt_dprintk("Parent node %s not found. Overlay node will not be 
added\n",
+   parent_node_path);
+return -EINVAL;
+}
+
+/* If parent has no child. */
+if ( parent_node->child == NULL )
+{
+next_node = parent_node->allnext;
+device_node->parent = parent_node;
+parent_node->allnext = device_node;
+parent_node->child = device_node;
+}
+else
+{
+struct dt_device_node *np;
+/*
+ * If parent has at least one child node.
+ * Iterate to the last child node of parent.
+ */
+for ( np = parent_node->child; np->sibling != NULL; np = np->sibling );
+
+/* Iterate over all child nodes of np node. */
+if ( np->child )
+{
+struct dt_device_node *np_last_descendant;
+
+np_last_descendant = find_last_descendants_node(np);
+
+next_node = np_last_descendant->allnext;
+np_last_descendant->allnext = device_node;
+}
+else
+{
+next_node = np->allnext;
+np->allnext = device_node;
+}
+
+device_node->parent = parent_node;
+np->sibling = device_node;
+np->sibling->sibling = NULL;
+}
+
+/* Iterate over all child nodes of device_node to add children too. */
+if ( device_node->child )
+{
+struct dt_device_node *device_node_last_descendant;
+
+

[XEN][PATCH v9 17/19] tools/libs/ctrl: Implement new xc interfaces for dt overlay

[Vikram Garhwal]

xc_dt_overlay() sends the device tree binary overlay, size of .dtbo and overlay
operation type i.e. add or remove to xen.

Signed-off-by: Vikram Garhwal 
---
 tools/include/xenctrl.h |  5 
 tools/libs/ctrl/Makefile.common |  1 +
 tools/libs/ctrl/xc_dt_overlay.c | 51 +
 3 files changed, 57 insertions(+)
 create mode 100644 tools/libs/ctrl/xc_dt_overlay.c

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index faec1dd824..3da602586c 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -2643,6 +2643,11 @@ int xc_livepatch_replace(xc_interface *xch, char *name, 
uint32_t timeout, uint32
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
  xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
 
+#if defined(__arm__) || defined(__aarch64__)
+int xc_dt_overlay(xc_interface *xch, void *overlay_fdt,
+  uint32_t overlay_fdt_size, uint8_t overlay_op);
+#endif
+
 /* Compat shims */
 #include "xenctrl_compat.h"
 
diff --git a/tools/libs/ctrl/Makefile.common b/tools/libs/ctrl/Makefile.common
index 0a09c28fd3..247afbe5f9 100644
--- a/tools/libs/ctrl/Makefile.common
+++ b/tools/libs/ctrl/Makefile.common
@@ -24,6 +24,7 @@ OBJS-y   += xc_hcall_buf.o
 OBJS-y   += xc_foreign_memory.o
 OBJS-y   += xc_kexec.o
 OBJS-y   += xc_resource.o
+OBJS-$(CONFIG_ARM)  += xc_dt_overlay.o
 OBJS-$(CONFIG_X86) += xc_psr.o
 OBJS-$(CONFIG_X86) += xc_pagetab.o
 OBJS-$(CONFIG_Linux) += xc_linux.o
diff --git a/tools/libs/ctrl/xc_dt_overlay.c b/tools/libs/ctrl/xc_dt_overlay.c
new file mode 100644
index 00..58283b9ef6
--- /dev/null
+++ b/tools/libs/ctrl/xc_dt_overlay.c
@@ -0,0 +1,51 @@
+/*
+ *
+ * Device Tree Overlay functions.
+ * Copyright (C) 2021 Xilinx Inc.
+ * Author Vikram Garhwal 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+
+#include "xc_private.h"
+
+int xc_dt_overlay(xc_interface *xch, void *overlay_fdt,
+  uint32_t overlay_fdt_size, uint8_t overlay_op)
+{
+int err;
+DECLARE_SYSCTL;
+
+DECLARE_HYPERCALL_BOUNCE(overlay_fdt, overlay_fdt_size,
+ XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+if ( (err = xc_hypercall_bounce_pre(xch, overlay_fdt)) )
+goto err;
+
+sysctl.cmd = XEN_SYSCTL_dt_overlay;
+sysctl.u.dt_overlay.overlay_op = overlay_op;
+sysctl.u.dt_overlay.overlay_fdt_size = overlay_fdt_size;
+sysctl.u.dt_overlay.pad[0]= 0;
+sysctl.u.dt_overlay.pad[1]= 0;
+sysctl.u.dt_overlay.pad[2]= 0;
+
+set_xen_guest_handle(sysctl.u.dt_overlay.overlay_fdt, overlay_fdt);
+
+if ( (err = do_sysctl(xch, )) != 0 )
+PERROR("%s failed", __func__);
+
+err:
+xc_hypercall_bounce_post(xch, overlay_fdt);
+
+return err;
+}
-- 
2.17.1

[XEN][PATCH v9 13/19] asm/smp.h: Fix circular dependency for device_tree.h and rwlock.h

[Vikram Garhwal]

Dynamic programming ops will modify the dt_host and there might be other
function which are browsing the dt_host at the same time. To avoid the race
conditions, we will need to add a rwlock to protect access to the dt_host.
However, adding rwlock in device_tree.h causes following circular dependency:
device_tree.h->rwlock.h->smp.h->asm/smp.h->device_tree.h

To fix this, removed the "#include  and forward declared
"struct dt_device_node".

Signed-off-by: Vikram Garhwal 
Reviewed-by: Henry Wang 
Reviewed-by: Michal Orzel 

---
Changes from v7:
Move struct dt_device_node declaration just above arch_cpu_init().
---
---
 xen/arch/arm/include/asm/smp.h | 4 +++-
 xen/arch/arm/smpboot.c | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/smp.h b/xen/arch/arm/include/asm/smp.h
index a37ca55bff..4fabdf5310 100644
--- a/xen/arch/arm/include/asm/smp.h
+++ b/xen/arch/arm/include/asm/smp.h
@@ -3,7 +3,6 @@
 
 #ifndef __ASSEMBLY__
 #include 
-#include 
 #include 
 #endif
 
@@ -23,6 +22,9 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
 extern void noreturn stop_cpu(void);
 
 extern int arch_smp_init(void);
+
+struct dt_device_node;
+
 extern int arch_cpu_init(int cpu, struct dt_device_node *dn);
 extern int arch_cpu_up(int cpu);
 extern void arch_cpu_up_finish(void);
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index e107b86b7b..eeb76cd551 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.17.1

[XEN][PATCH v9 11/19] xen/iommu: Introduce iommu_remove_dt_device()

[Vikram Garhwal]

Remove master device from the IOMMU. This will be helpful when removing the
overlay nodes using dynamic programming during run time.

Signed-off-by: Vikram Garhwal 
Acked-by: Jan Beulich 

---
Changes from v7:
Add check if IOMMU is enabled.
Fix indentation of fail.
---
---
 xen/drivers/passthrough/device_tree.c | 44 +++
 xen/include/xen/iommu.h   |  1 +
 2 files changed, 45 insertions(+)

diff --git a/xen/drivers/passthrough/device_tree.c 
b/xen/drivers/passthrough/device_tree.c
index 096ef2dd68..4cb32dc0b3 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -128,6 +128,50 @@ int iommu_release_dt_devices(struct domain *d)
 return 0;
 }
 
+int iommu_remove_dt_device(struct dt_device_node *np)
+{
+const struct iommu_ops *ops = iommu_get_ops();
+struct device *dev = dt_to_dev(np);
+int rc;
+
+if ( !iommu_enabled )
+return 1;
+
+if ( !ops )
+return -EOPNOTSUPP;
+
+spin_lock(_lock);
+
+if ( iommu_dt_device_is_assigned_locked(np) )
+{
+rc = -EBUSY;
+goto fail;
+}
+
+/*
+ * The driver which supports generic IOMMU DT bindings must have this
+ * callback implemented.
+ */
+if ( !ops->remove_device )
+{
+rc = -EOPNOTSUPP;
+goto fail;
+}
+
+/*
+ * Remove master device from the IOMMU if latter is present and available.
+ * The driver is responsible for removing is_protected flag.
+ */
+rc = ops->remove_device(0, dev);
+
+if ( !rc )
+iommu_fwspec_free(dev);
+
+ fail:
+spin_unlock(_lock);
+return rc;
+}
+
 int iommu_add_dt_device(struct dt_device_node *np)
 {
 const struct iommu_ops *ops = iommu_get_ops();
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 110693c59f..a8e9bc9a2d 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -233,6 +233,7 @@ int iommu_add_dt_device(struct dt_device_node *np);
 
 int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
+int iommu_remove_dt_device(struct dt_device_node *np);
 
 #endif /* HAS_DEVICE_TREE */
 
-- 
2.17.1

[XEN][PATCH v9 10/19] xen/iommu: protect iommu_add_dt_device() with dtdevs_lock

[Vikram Garhwal]

Protect iommu_add_dt_device() with dtdevs_lock to prevent concurrent access
to add/remove/assign/deassign.
With addition of dynamic programming feature(follow-up patches in this series),
this function can be concurrently access by pci device assign/deassign and also
by dynamic node add/remove using device tree overlays.

Signed-off-by: Vikram Garhwal 
Reviewed-by: Luca Fancellu 
Reviewed-by: Michal Orzel 

---
Changes from v7:
Update commit message and fix indent.
---
---
 xen/drivers/passthrough/device_tree.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/device_tree.c 
b/xen/drivers/passthrough/device_tree.c
index 5796ee1f93..096ef2dd68 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -148,6 +148,8 @@ int iommu_add_dt_device(struct dt_device_node *np)
 if ( dev_iommu_fwspec_get(dev) )
 return 0;
 
+spin_lock(_lock);
+
 /*
  * According to the Documentation/devicetree/bindings/iommu/iommu.txt
  * from Linux.
@@ -160,7 +162,10 @@ int iommu_add_dt_device(struct dt_device_node *np)
  * these callback implemented.
  */
 if ( !ops->add_device || !ops->dt_xlate )
-return -EINVAL;
+{
+rc = -EINVAL;
+goto fail;
+}
 
 if ( !dt_device_is_available(iommu_spec.np) )
 break;
@@ -191,6 +196,8 @@ int iommu_add_dt_device(struct dt_device_node *np)
 if ( rc < 0 )
 iommu_fwspec_free(dev);
 
+ fail:
+spin_unlock(_lock);
 return rc;
 }
 
-- 
2.17.1

[XEN][PATCH v9 09/19] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller

[Vikram Garhwal]

Rename iommu_dt_device_is_assigned() to iommu_dt_device_is_assigned_locked().
Remove static type so this can also be used by SMMU drivers to check if the
device is being used before removing.

Moving spin_lock to caller was done to prevent the concurrent access to
iommu_dt_device_is_assigned while doing add/remove/assign/deassign. Follow-up
patches in this series introduces node add/remove feature.

Also, caller is required hold the correct lock so moved the function prototype
to a private header.

Signed-off-by: Vikram Garhwal 

---
Changes from v7:
Update commit message.
Add ASSERT().
---
---
 xen/drivers/passthrough/device_tree.c | 26 +
 xen/include/xen/iommu-private.h   | 28 +++
 2 files changed, 50 insertions(+), 4 deletions(-)
 create mode 100644 xen/include/xen/iommu-private.h

diff --git a/xen/drivers/passthrough/device_tree.c 
b/xen/drivers/passthrough/device_tree.c
index 1c32d7b50c..5796ee1f93 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -83,16 +84,16 @@ fail:
 return rc;
 }
 
-static bool_t iommu_dt_device_is_assigned(const struct dt_device_node *dev)
+bool_t iommu_dt_device_is_assigned_locked(const struct dt_device_node *dev)
 {
 bool_t assigned = 0;
 
+ASSERT(spin_is_locked(_lock));
+
 if ( !dt_device_is_protected(dev) )
 return 0;
 
-spin_lock(_lock);
 assigned = !list_empty(>domain_list);
-spin_unlock(_lock);
 
 return assigned;
 }
@@ -213,27 +214,44 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct 
domain *d,
 if ( (d && d->is_dying) || domctl->u.assign_device.flags )
 break;
 
+/*
+ * To ensure that the dev doesn't disappear between the time we look it
+ * up with dt_find_node_by_gpath() and we check the assignment later.
+ */
+spin_lock(_lock);
+
 ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
 domctl->u.assign_device.u.dt.size,
 );
 if ( ret )
+{
+spin_unlock(_lock);
 break;
+}
 
 ret = xsm_assign_dtdevice(XSM_HOOK, d, dt_node_full_name(dev));
 if ( ret )
+{
+spin_unlock(_lock);
 break;
+}
 
 if ( domctl->cmd == XEN_DOMCTL_test_assign_device )
 {
-if ( iommu_dt_device_is_assigned(dev) )
+
+if ( iommu_dt_device_is_assigned_locked(dev) )
 {
 printk(XENLOG_G_ERR "%s already assigned.\n",
dt_node_full_name(dev));
 ret = -EINVAL;
 }
+
+spin_unlock(_lock);
 break;
 }
 
+spin_unlock(_lock);
+
 if ( d == dom_io )
 return -EINVAL;
 
diff --git a/xen/include/xen/iommu-private.h b/xen/include/xen/iommu-private.h
new file mode 100644
index 00..bb5c94e7a6
--- /dev/null
+++ b/xen/include/xen/iommu-private.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * xen/iommu-private.h
+ */
+#ifndef __XEN_IOMMU_PRIVATE_H__
+#define __XEN_IOMMU_PRIVATE_H__
+
+#ifdef CONFIG_HAS_DEVICE_TREE
+#include 
+
+/*
+ * Checks if dt_device_node is assigned to a domain or not. This function
+ * expects to be called with dtdevs_lock acquired by caller.
+ */
+bool_t iommu_dt_device_is_assigned_locked(const struct dt_device_node *dev);
+#endif
+
+#endif /* __XEN_IOMMU_PRIVATE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.17.1

[XEN][PATCH v9 14/19] common/device_tree: Add rwlock for dt_host

[Vikram Garhwal]

 Dynamic programming ops will modify the dt_host and there might be other
 function which are browsing the dt_host at the same time. To avoid the race
 conditions, adding rwlock for browsing the dt_host during runtime. dt_host
 writer will be added in the follow-up patch titled "xen/arm: Implement device
 tree node addition functionalities."

 Reason behind adding rwlock instead of spinlock:
For now, dynamic programming is the sole modifier of dt_host in Xen during
run time. All other access functions like iommu_release_dt_device() are
just reading the dt_host during run-time. So, there is a need to protect
others from browsing the dt_host while dynamic programming is modifying
it. rwlock is better suitable for this task as spinlock won't be able to
differentiate between read and write access.

Signed-off-by: Vikram Garhwal 

---
Changes from v7:
Keep one lock for dt_host instead of lock for each node under dt_host.
---
---
 xen/common/device_tree.c  |  5 +
 xen/drivers/passthrough/device_tree.c | 15 +++
 xen/include/xen/device_tree.h |  6 ++
 3 files changed, 26 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0f10037745..6b934fe036 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -31,6 +31,7 @@ dt_irq_xlate_func dt_irq_xlate;
 struct dt_device_node *dt_host;
 /* Interrupt controller node*/
 const struct dt_device_node *dt_interrupt_controller;
+rwlock_t dt_host_lock;
 
 /**
  * struct dt_alias_prop - Alias property in 'aliases' node
@@ -2137,7 +2138,11 @@ int unflatten_device_tree(const void *fdt, struct 
dt_device_node **mynodes)
 
 dt_dprintk(" <- unflatten_device_tree()\n");
 
+/* Init r/w lock for host device tree. */
+rwlock_init(_host_lock);
+
 return 0;
+
 }
 
 static void dt_alias_add(struct dt_alias_prop *ap,
diff --git a/xen/drivers/passthrough/device_tree.c 
b/xen/drivers/passthrough/device_tree.c
index 4cb32dc0b3..31815d2b60 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -114,6 +114,8 @@ int iommu_release_dt_devices(struct domain *d)
 if ( !is_iommu_enabled(d) )
 return 0;
 
+read_lock(_host_lock);
+
 list_for_each_entry_safe(dev, _dev, >dt_devices, domain_list)
 {
 rc = iommu_deassign_dt_device(d, dev);
@@ -121,10 +123,14 @@ int iommu_release_dt_devices(struct domain *d)
 {
 dprintk(XENLOG_ERR, "Failed to deassign %s in domain %u\n",
 dt_node_full_name(dev), d->domain_id);
+
+read_unlock(_host_lock);
 return rc;
 }
 }
 
+read_unlock(_host_lock);
+
 return 0;
 }
 
@@ -251,6 +257,8 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct 
domain *d,
 int ret;
 struct dt_device_node *dev;
 
+read_lock(_host_lock);
+
 switch ( domctl->cmd )
 {
 case XEN_DOMCTL_assign_device:
@@ -304,7 +312,10 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct 
domain *d,
 spin_unlock(_lock);
 
 if ( d == dom_io )
+{
+read_unlock(_host_lock);
 return -EINVAL;
+}
 
 ret = iommu_add_dt_device(dev);
 if ( ret < 0 )
@@ -342,7 +353,10 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct 
domain *d,
 break;
 
 if ( d == dom_io )
+{
+read_unlock(_host_lock);
 return -EINVAL;
+}
 
 ret = iommu_deassign_dt_device(d, dev);
 
@@ -357,5 +371,6 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct 
domain *d,
 break;
 }
 
+read_unlock(_host_lock);
 return ret;
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index e507658b23..8191f30197 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DEVICE_TREE_MAX_DEPTH 16
 
@@ -216,6 +217,11 @@ extern struct dt_device_node *dt_host;
  */
 extern const struct dt_device_node *dt_interrupt_controller;
 
+/*
+ * Lock that protects r/w updates to unflattened device tree i.e. dt_host.
+ */
+extern rwlock_t dt_host_lock;
+
 /**
  * Find the interrupt controller
  * For the moment we handle only one interrupt controller: the first
-- 
2.17.1

[XEN][PATCH v9 07/19] libfdt: overlay: change overlay_get_target()

[Vikram Garhwal]

Rename overlay_get_target() to fdt_overlay_target_offset() and remove static
function type.

This is done to get the target path for the overlay nodes which is very useful
in many cases. For example, Xen hypervisor needs it when applying overlays
because Xen needs to do further processing of the overlay nodes, e.g. mapping of
resources(IRQs and IOMMUs) to other VMs, creation of SMMU pagetables, etc.

Signed-off-by: Vikram Garhwal 
Message-Id: <1637204036-382159-2-git-send-email-fnu.vik...@xilinx.com>
Signed-off-by: David Gibson 
Origin: git://git.kernel.org/pub/scm/utils/dtc/dtc.git 45f3d1a095dd

Signed-off-by: Vikram Garhwal 
Reviewed-by: Michal Orzel 
Reviewed-by: Henry Wang 
Acked-by: Juline Grall 
---
 xen/common/libfdt/fdt_overlay.c | 29 +++--
 xen/common/libfdt/version.lds   |  1 +
 xen/include/xen/libfdt/libfdt.h | 18 ++
 3 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/xen/common/libfdt/fdt_overlay.c b/xen/common/libfdt/fdt_overlay.c
index 7b95e2b639..acf0c4c2a6 100644
--- a/xen/common/libfdt/fdt_overlay.c
+++ b/xen/common/libfdt/fdt_overlay.c
@@ -41,37 +41,22 @@ static uint32_t overlay_get_target_phandle(const void 
*fdto, int fragment)
return fdt32_to_cpu(*val);
 }
 
-/**
- * overlay_get_target - retrieves the offset of a fragment's target
- * @fdt: Base device tree blob
- * @fdto: Device tree overlay blob
- * @fragment: node offset of the fragment in the overlay
- * @pathp: pointer which receives the path of the target (or NULL)
- *
- * overlay_get_target() retrieves the target offset in the base
- * device tree of a fragment, no matter how the actual targeting is
- * done (through a phandle or a path)
- *
- * returns:
- *  the targeted node offset in the base device tree
- *  Negative error code on error
- */
-static int overlay_get_target(const void *fdt, const void *fdto,
- int fragment, char const **pathp)
+int fdt_overlay_target_offset(const void *fdt, const void *fdto,
+ int fragment_offset, char const **pathp)
 {
uint32_t phandle;
const char *path = NULL;
int path_len = 0, ret;
 
/* Try first to do a phandle based lookup */
-   phandle = overlay_get_target_phandle(fdto, fragment);
+   phandle = overlay_get_target_phandle(fdto, fragment_offset);
if (phandle == (uint32_t)-1)
return -FDT_ERR_BADPHANDLE;
 
/* no phandle, try path */
if (!phandle) {
/* And then a path based lookup */
-   path = fdt_getprop(fdto, fragment, "target-path", _len);
+   path = fdt_getprop(fdto, fragment_offset, "target-path", 
_len);
if (path)
ret = fdt_path_offset(fdt, path);
else
@@ -638,7 +623,7 @@ static int overlay_merge(void *fdt, void *fdto)
if (overlay < 0)
return overlay;
 
-   target = overlay_get_target(fdt, fdto, fragment, NULL);
+   target = fdt_overlay_target_offset(fdt, fdto, fragment, NULL);
if (target < 0)
return target;
 
@@ -781,7 +766,7 @@ static int overlay_symbol_update(void *fdt, void *fdto)
return -FDT_ERR_BADOVERLAY;
 
/* get the target of the fragment */
-   ret = overlay_get_target(fdt, fdto, fragment, _path);
+   ret = fdt_overlay_target_offset(fdt, fdto, fragment, 
_path);
if (ret < 0)
return ret;
target = ret;
@@ -803,7 +788,7 @@ static int overlay_symbol_update(void *fdt, void *fdto)
 
if (!target_path) {
/* again in case setprop_placeholder changed it */
-   ret = overlay_get_target(fdt, fdto, fragment, 
_path);
+   ret = fdt_overlay_target_offset(fdt, fdto, fragment, 
_path);
if (ret < 0)
return ret;
target = ret;
diff --git a/xen/common/libfdt/version.lds b/xen/common/libfdt/version.lds
index 7ab85f1d9d..cbce5d4a8b 100644
--- a/xen/common/libfdt/version.lds
+++ b/xen/common/libfdt/version.lds
@@ -77,6 +77,7 @@ LIBFDT_1.2 {
fdt_appendprop_addrrange;
fdt_setprop_inplace_namelen_partial;
fdt_create_with_flags;
+   fdt_overlay_target_offset;
local:
*;
 };
diff --git a/xen/include/xen/libfdt/libfdt.h b/xen/include/xen/libfdt/libfdt.h
index c71689e2be..fabddbee8c 100644
--- a/xen/include/xen/libfdt/libfdt.h
+++ b/xen/include/xen/libfdt/libfdt.h
@@ -2109,6 +2109,24 @@ int fdt_del_node(void *fdt, int nodeoffset);
  */
 int fdt_overlay_apply(void *fdt, void *fdto);
 
+/**
+ * fdt_overlay_target_offset - retrieves the offset of a fragment's target
+ * @fdt: Base device tree blob
+ * @fdto: Device tree overlay blob
+ * 

[XEN][PATCH v9 12/19] xen/smmu: Add remove_device callback for smmu_iommu ops

[Vikram Garhwal]

Add remove_device callback for removing the device entry from smmu-master using
following steps:
1. Find if SMMU master exists for the device node.
2. Check if device is currently in use.
3. Remove the SMMU master.

Signed-off-by: Vikram Garhwal 
Reviewed-by: Luca Fancellu 
Reviewed-by: Michal Orzel 

---
 Changes from v7:
Added comments on arm_smmu_dt_remove_device_generic().
---
---
 xen/drivers/passthrough/arm/smmu.c | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index c37fa9af13..e1e8e4528d 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -815,6 +816,19 @@ static int insert_smmu_master(struct arm_smmu_device *smmu,
return 0;
 }
 
+static int remove_smmu_master(struct arm_smmu_device *smmu,
+ struct arm_smmu_master *master)
+{
+   if (!smmu->masters.rb_node) {
+   ASSERT_UNREACHABLE();
+   return -ENOENT;
+   }
+
+   rb_erase(>node, >masters);
+
+   return 0;
+}
+
 static int arm_smmu_dt_add_device_legacy(struct arm_smmu_device *smmu,
 struct device *dev,
 struct iommu_fwspec *fwspec)
@@ -852,6 +866,34 @@ static int arm_smmu_dt_add_device_legacy(struct 
arm_smmu_device *smmu,
return insert_smmu_master(smmu, master);
 }
 
+static int arm_smmu_dt_remove_device_legacy(struct arm_smmu_device *smmu,
+struct device *dev)
+{
+   struct arm_smmu_master *master;
+   struct device_node *dev_node = dev_get_dev_node(dev);
+   int ret;
+
+   master = find_smmu_master(smmu, dev_node);
+   if (master == NULL) {
+   dev_err(dev,
+   "No registrations found for master device %s\n",
+   dev_node->name);
+   return -EINVAL;
+   }
+
+   if (iommu_dt_device_is_assigned_locked(dev_to_dt(dev)))
+   return -EBUSY;
+
+   ret = remove_smmu_master(smmu, master);
+   if (ret)
+   return ret;
+
+   dev_node->is_protected = false;
+
+   kfree(master);
+   return 0;
+}
+
 static int register_smmu_master(struct arm_smmu_device *smmu,
struct device *dev,
struct of_phandle_args *masterspec)
@@ -875,6 +917,26 @@ static int register_smmu_master(struct arm_smmu_device 
*smmu,
 fwspec);
 }
 
+/*
+ * The driver which supports generic IOMMU DT bindings must have this
+ * callback implemented.
+ */
+static int arm_smmu_dt_remove_device_generic(u8 devfn, struct device *dev)
+{
+   struct arm_smmu_device *smmu;
+   struct iommu_fwspec *fwspec;
+
+   fwspec = dev_iommu_fwspec_get(dev);
+   if (fwspec == NULL)
+   return -ENXIO;
+
+   smmu = find_smmu(fwspec->iommu_dev);
+   if (smmu == NULL)
+   return -ENXIO;
+
+   return arm_smmu_dt_remove_device_legacy(smmu, dev);
+}
+
 static int arm_smmu_dt_add_device_generic(u8 devfn, struct device *dev)
 {
struct arm_smmu_device *smmu;
@@ -2859,6 +2921,7 @@ static const struct iommu_ops arm_smmu_iommu_ops = {
 .init = arm_smmu_iommu_domain_init,
 .hwdom_init = arch_iommu_hwdom_init,
 .add_device = arm_smmu_dt_add_device_generic,
+.remove_device = arm_smmu_dt_remove_device_generic,
 .teardown = arm_smmu_iommu_domain_teardown,
 .iotlb_flush = arm_smmu_iotlb_flush,
 .assign_device = arm_smmu_assign_dev,
-- 
2.17.1

[XEN][PATCH v9 06/19] libfdt: Keep fdt functions after init for CONFIG_OVERLAY_DTB.

[Vikram Garhwal]

This is done to access fdt library function which are required for adding device
tree overlay nodes for dynamic programming of nodes.

Signed-off-by: Vikram Garhwal 
Acked-by: Julien Grall 
---
 xen/common/libfdt/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index 75aaefa2e3..d50487aa6e 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -1,7 +1,11 @@
 include $(src)/Makefile.libfdt
 
 SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
+
+# For CONFIG_OVERLAY_DTB, libfdt functionalities will be needed during runtime.
+ifneq ($(CONFIG_OVERLAY_DTB),y)
 OBJCOPYFLAGS := $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s))
+endif
 
 obj-y += libfdt.o
 nocov-y += libfdt.o
-- 
2.17.1

[XEN][PATCH v9 04/19] common/device_tree: Export __unflatten_device_tree()

[Vikram Garhwal]

Following changes are done to __unflatten_device_tree():
1. __unflatten_device_tree() is renamed to unflatten_device_tree().
2. Remove __init and static function type.

The changes are done to make this function useable for dynamic node programming
where new device tree overlay nodes are added to fdt and further unflattend to
update xen device tree during runtime.

Signed-off-by: Vikram Garhwal 

---
Changes from v7:
Update the commit with why unflatten_device_tree() is changed.
Move function documentation to device_tree.h
---
---
 xen/common/device_tree.c  | 17 +++--
 xen/include/xen/device_tree.h | 12 
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index d70b6a7ac9..67e9b6de3e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -2082,18 +2082,7 @@ static unsigned long unflatten_dt_node(const void *fdt,
 return mem;
 }
 
-/**
- * __unflatten_device_tree - create tree of device_nodes from flat blob
- *
- * unflattens a device-tree, creating the
- * tree of struct device_node. It also fills the "name" and "type"
- * pointers of the nodes so the normal device-tree walking functions
- * can be used.
- * @fdt: The fdt to expand
- * @mynodes: The device_node tree created by the call
- */
-static int __init __unflatten_device_tree(const void *fdt,
-  struct dt_device_node **mynodes)
+int unflatten_device_tree(const void *fdt, struct dt_device_node **mynodes)
 {
 unsigned long start, mem, size;
 struct dt_device_node **allnextp = mynodes;
@@ -2232,10 +2221,10 @@ dt_find_interrupt_controller(const struct 
dt_device_match *matches)
 
 void __init dt_unflatten_host_device_tree(void)
 {
-int error = __unflatten_device_tree(device_tree_flattened, _host);
+int error = unflatten_device_tree(device_tree_flattened, _host);
 
 if ( error )
-panic("__unflatten_device_tree failed with error %d\n", error);
+panic("unflatten_device_tree failed with error %d\n", error);
 
 dt_alias_scan();
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 1d79e23b28..5941599eff 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -178,6 +178,18 @@ int device_tree_for_each_node(const void *fdt, int node,
  */
 void dt_unflatten_host_device_tree(void);
 
+/**
+ * unflatten_device_tree - create tree of device_nodes from flat blob
+ *
+ * unflattens a device-tree, creating the
+ * tree of struct device_node. It also fills the "name" and "type"
+ * pointers of the nodes so the normal device-tree walking functions
+ * can be used.
+ * @fdt: The fdt to expand
+ * @mynodes: The device_node tree created by the call
+ */
+int unflatten_device_tree(const void *fdt, struct dt_device_node **mynodes);
+
 /**
  * IRQ translation callback
  * TODO: For the moment we assume that we only have ONE
-- 
2.17.1

[XEN][PATCH v9 02/19] common/device_tree.c: unflatten_device_tree() propagate errors

[Vikram Garhwal]

This will be useful in dynamic node programming when new dt nodes are unflattend
during runtime. Invalid device tree node related errors should be propagated
back to the caller.

Signed-off-by: Vikram Garhwal 

---
Changes from v7:
Free allocated memory in case of errors when calling unflatten_dt_node.
---
---
 xen/common/device_tree.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index c91d54c493..cd9a6a5c93 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -2108,6 +2108,9 @@ static int __init __unflatten_device_tree(const void *fdt,
 /* First pass, scan for size */
 start = ((unsigned long)fdt) + fdt_off_dt_struct(fdt);
 size = unflatten_dt_node(fdt, 0, , NULL, NULL, 0);
+if ( !size )
+return -EINVAL;
+
 size = (size | 3) + 1;
 
 dt_dprintk("  size is %#lx allocating...\n", size);
@@ -2125,11 +2128,21 @@ static int __init __unflatten_device_tree(const void 
*fdt,
 start = ((unsigned long)fdt) + fdt_off_dt_struct(fdt);
 unflatten_dt_node(fdt, mem, , NULL, , 0);
 if ( be32_to_cpup((__be32 *)start) != FDT_END )
-printk(XENLOG_WARNING "Weird tag at end of tree: %08x\n",
+{
+printk(XENLOG_ERR "Weird tag at end of tree: %08x\n",
   *((u32 *)start));
+xfree((__be64 *)mem);
+return -EINVAL;
+}
+
 if ( be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeefU )
-printk(XENLOG_WARNING "End of tree marker overwritten: %08x\n",
+{
+printk(XENLOG_ERR "End of tree marker overwritten: %08x\n",
   be32_to_cpu(((__be32 *)mem)[size / 4]));
+xfree((__be64 *)mem);
+return -EINVAL;
+}
+
 *allnextp = NULL;
 
 dt_dprintk(" <- unflatten_device_tree()\n");
-- 
2.17.1

[XEN][PATCH v9 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree

[Vikram Garhwal]

Add device_tree_find_node_by_path() to find a matching node with path for a
dt_device_node.

Reason behind this function:
Each time overlay nodes are added using .dtbo, a new fdt(memcpy of
device_tree_flattened) is created and updated with overlay nodes. This
updated fdt is further unflattened to a dt_host_new. Next, we need to find
the overlay nodes in dt_host_new, find the overlay node's parent in dt_host
and add the nodes as child under their parent in the dt_host. Thus we need
this function to search for node in different unflattened device trees.

Also, make dt_find_node_by_path() static inline.

Signed-off-by: Vikram Garhwal 

---
Changes from v7:
Rename device_tree_find_node_by_path() to dt_find_node_by_path_from().
Fix indentation.
---
---
 xen/common/device_tree.c  |  5 +++--
 xen/include/xen/device_tree.h | 18 --
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 67e9b6de3e..0f10037745 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -358,11 +358,12 @@ struct dt_device_node *dt_find_node_by_type(struct 
dt_device_node *from,
 return np;
 }
 
-struct dt_device_node *dt_find_node_by_path(const char *path)
+struct dt_device_node *dt_find_node_by_path_from(struct dt_device_node *from,
+ const char *path)
 {
 struct dt_device_node *np;
 
-dt_for_each_device_node(dt_host, np)
+dt_for_each_device_node(from, np)
 if ( np->full_name && (dt_node_cmp(np->full_name, path) == 0) )
 break;
 
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 5941599eff..e507658b23 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -568,13 +568,27 @@ struct dt_device_node *dt_find_node_by_type(struct 
dt_device_node *from,
 struct dt_device_node *dt_find_node_by_alias(const char *alias);
 
 /**
- * dt_find_node_by_path - Find a node matching a full DT path
+ * dt_find_node_by_path_from - Generic function to find a node matching the
+ * full DT path for any given unflatten device tree
+ * @from: The device tree node to start searching from
  * @path: The full path to match
  *
  * Returns a node pointer.
  */
-struct dt_device_node *dt_find_node_by_path(const char *path);
+struct dt_device_node *
+dt_find_node_by_path_from(struct dt_device_node *from,
+  const char *path);
 
+/**
+ * dt_find_node_by_path - Find a node matching a full DT path in dt_host
+ * @path: The full path to match
+ *
+ * Returns a node pointer.
+ */
+static inline struct dt_device_node *dt_find_node_by_path(const char *path)
+{
+return dt_find_node_by_path_from(dt_host, path);
+}
 
 /**
  * dt_find_node_by_gpath - Same as dt_find_node_by_path but retrieve the
-- 
2.17.1

[XEN][PATCH v9 05/19] xen/arm: Add CONFIG_OVERLAY_DTB

[Vikram Garhwal]

Introduce a config option where the user can enable support for adding/removing
device tree nodes using a device tree binary overlay.

Update SUPPORT.md and CHANGELOG.md to state the Device Tree Overlays support for
Arm.

Signed-off-by: Vikram Garhwal 
Acked-by: Henry Wang 
Reviewed-by: Michal Orzel 

---
Changes from v7:
Add this feature as "experimental support" in CHANGELOG.md
---
---
 CHANGELOG.md | 3 ++-
 SUPPORT.md   | 6 ++
 xen/arch/arm/Kconfig | 5 +
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7d7e0590f8..47098dbfca 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -24,7 +24,8 @@ The format is based on [Keep a 
Changelog](https://keepachangelog.com/en/1.0.0/)
  - xl/libxl can customize SMBIOS strings for HVM guests.
  - Add support for AVX512-FP16 on x86.
  - On Arm, Xen supports guests running SVE/SVE2 instructions. (Tech Preview)
-
+ - On Arm, experimental support for dynamic addition/removal of Xen device tree
+   nodes using a device tree overlay binary(.dtbo).
 
 ## 
[4.17.0](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.17.0) 
- 2022-12-12
 
diff --git a/SUPPORT.md b/SUPPORT.md
index 35a6249e03..8eb006565c 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -844,6 +844,12 @@ No support for QEMU backends in a 16K or 64K domain.
 
 Status: Supported
 
+### Device Tree Overlays
+
+Add/Remove device tree nodes using a device tree overlay binary(.dtbo).
+
+Status, ARM: Experimental
+
 ### ARM: Guest ACPI support
 
 Status: Supported
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index fd57a82dd2..02c4796438 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -92,6 +92,11 @@ config HAS_ITS
 bool "GICv3 ITS MSI controller support (UNSUPPORTED)" if UNSUPPORTED
 depends on GICV3 && !NEW_VGIC && !ARM_32
 
+config OVERLAY_DTB
+   bool "DTB overlay support (UNSUPPORTED)" if UNSUPPORTED
+   help
+ Dynamic addition/removal of Xen device tree nodes using a dtbo.
+
 config HVM
 def_bool y
 
-- 
2.17.1

[XEN][PATCH v9 01/19] common/device_tree: handle memory allocation failure in __unflatten_device_tree()

[Vikram Garhwal]

Change __unflatten_device_tree() return type to integer so it can propagate
memory allocation failure. Add panic() in dt_unflatten_host_device_tree() for
memory allocation failure during boot.

Fixes: fb97eb614acf ("xen/arm: Create a hierarchical device tree")
Signed-off-by: Vikram Garhwal 
Reviewed-by: Henry Wang 
Reviewed-by: Michal Orzel 
Acked-by: Julien Grall 
---
 xen/common/device_tree.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0522fdf976..c91d54c493 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -2092,8 +2092,8 @@ static unsigned long __init unflatten_dt_node(const void 
*fdt,
  * @fdt: The fdt to expand
  * @mynodes: The device_node tree created by the call
  */
-static void __init __unflatten_device_tree(const void *fdt,
-   struct dt_device_node **mynodes)
+static int __init __unflatten_device_tree(const void *fdt,
+  struct dt_device_node **mynodes)
 {
 unsigned long start, mem, size;
 struct dt_device_node **allnextp = mynodes;
@@ -2114,6 +2114,8 @@ static void __init __unflatten_device_tree(const void 
*fdt,
 
 /* Allocate memory for the expanded device tree */
 mem = (unsigned long)_xmalloc (size + 4, __alignof__(struct 
dt_device_node));
+if ( !mem )
+return -ENOMEM;
 
 ((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeefU);
 
@@ -2131,6 +2133,8 @@ static void __init __unflatten_device_tree(const void 
*fdt,
 *allnextp = NULL;
 
 dt_dprintk(" <- unflatten_device_tree()\n");
+
+return 0;
 }
 
 static void dt_alias_add(struct dt_alias_prop *ap,
@@ -2215,7 +2219,11 @@ dt_find_interrupt_controller(const struct 
dt_device_match *matches)
 
 void __init dt_unflatten_host_device_tree(void)
 {
-__unflatten_device_tree(device_tree_flattened, _host);
+int error = __unflatten_device_tree(device_tree_flattened, _host);
+
+if ( error )
+panic("__unflatten_device_tree failed with error %d\n", error);
+
 dt_alias_scan();
 }
 
-- 
2.17.1

[XEN][PATCH v9 03/19] xen/arm/device: Remove __init from function type

[Vikram Garhwal]

Remove __init from following function to access during runtime:
1. map_irq_to_domain()
2. handle_device_interrupts()
3. map_range_to_domain()
4. unflatten_dt_node()

Move map_irq_to_domain() prototype from domain_build.h to setup.h.

To avoid breaking the build, following changes are also done:
1. Move map_irq_to_domain(), handle_device_interrupts() and 
map_range_to_domain()
to device.c. After removing __init type,  these functions are not specific
to domain building, so moving them out of domain_build.c to device.c.
2. Remove static type from handle_device_interrupt().

Overall, these changes are done to support the dynamic programming of a nodes
where an overlay node will be added to fdt and unflattened node will be added to
dt_host. Furthermore, IRQ and mmio mapping will be done for the added node.

Signed-off-by: Vikram Garhwal 
Reviewed-by: Michal Orzel 
---
 xen/arch/arm/device.c   | 149 
 xen/arch/arm/domain_build.c | 147 ---
 xen/arch/arm/include/asm/domain_build.h |   2 -
 xen/arch/arm/include/asm/setup.h|   6 +
 xen/common/device_tree.c|  12 +-
 5 files changed, 161 insertions(+), 155 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index ca8539dee5..1652d765bd 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -9,8 +9,10 @@
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 extern const struct device_desc _sdevice[], _edevice[];
@@ -75,6 +77,153 @@ enum device_class device_get_class(const struct 
dt_device_node *dev)
 return DEVICE_UNKNOWN;
 }
 
+int map_irq_to_domain(struct domain *d, unsigned int irq,
+  bool need_mapping, const char *devname)
+{
+int res;
+
+res = irq_permit_access(d, irq);
+if ( res )
+{
+printk(XENLOG_ERR "Unable to permit to %pd access to IRQ %u\n", d, 
irq);
+return res;
+}
+
+if ( need_mapping )
+{
+/*
+ * Checking the return of vgic_reserve_virq is not
+ * necessary. It should not fail except when we try to map
+ * the IRQ twice. This can legitimately happen if the IRQ is shared
+ */
+vgic_reserve_virq(d, irq);
+
+res = route_irq_to_guest(d, irq, irq, devname);
+if ( res < 0 )
+{
+printk(XENLOG_ERR "Unable to map IRQ%u to %pd\n", irq, d);
+return res;
+}
+}
+
+dt_dprintk("  - IRQ: %u\n", irq);
+return 0;
+}
+
+int map_range_to_domain(const struct dt_device_node *dev,
+uint64_t addr, uint64_t len, void *data)
+{
+struct map_range_data *mr_data = data;
+struct domain *d = mr_data->d;
+int res;
+
+if ( (addr != (paddr_t)addr) || (((paddr_t)~0 - addr) < len) )
+{
+printk(XENLOG_ERR "%s: [0x%"PRIx64", 0x%"PRIx64"] exceeds the maximum 
allowed PA width (%u bits)",
+   dt_node_full_name(dev), addr, (addr + len), PADDR_BITS);
+return -ERANGE;
+}
+
+/*
+ * reserved-memory regions are RAM carved out for a special purpose.
+ * They are not MMIO and therefore a domain should not be able to
+ * manage them via the IOMEM interface.
+ */
+if ( strncasecmp(dt_node_full_name(dev), "/reserved-memory/",
+ strlen("/reserved-memory/")) != 0 )
+{
+res = iomem_permit_access(d, paddr_to_pfn(addr),
+paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
+if ( res )
+{
+printk(XENLOG_ERR "Unable to permit to dom%d access to"
+" 0x%"PRIx64" - 0x%"PRIx64"\n",
+d->domain_id,
+addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
+return res;
+}
+}
+
+if ( !mr_data->skip_mapping )
+{
+res = map_regions_p2mt(d,
+   gaddr_to_gfn(addr),
+   PFN_UP(len),
+   maddr_to_mfn(addr),
+   mr_data->p2mt);
+
+if ( res < 0 )
+{
+printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+   " - 0x%"PRIx64" in domain %d\n",
+   addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1,
+   d->domain_id);
+return res;
+}
+}
+
+dt_dprintk("  - MMIO: %010"PRIx64" - %010"PRIx64" P2MType=%x\n",
+   addr, addr + len, mr_data->p2mt);
+
+return 0;
+}
+
+/*
+ * handle_device_interrupts retrieves the interrupts configuration from
+ * a device tree node and maps those interrupts to the target domain.
+ *
+ * Returns:
+ *   < 0 error
+ *   0   success
+ */
+int handle_device_interrupts(struct domain *d,
+ struct dt_device_node *dev,
+ bool need_mapping)
+{
+unsigned int i, nirq;
+int res;
+struct dt_raw_irq rirq;
+
+nirq = 

[XEN][PATCH v9 00/19] dynamic node programming using overlay dtbo

[Vikram Garhwal]

Hi,
This patch series is for introducing dynamic programming i.e. add/remove the
devices during run time. Using "xl dt_overlay" a device can be added/removed
with dtbo.

For adding a node using dynamic programming:
1. flatten device tree overlay node will be added to a fdt
2. Updated fdt will be unflattened to a new dt_host_new
3. Extract the newly added node information from dt_host_new
4. Add the added node under correct parent in original dt_host.
3. Map/Permit interrupt and iomem region as required.

For removing a node:
1. Find the node with given path.
2. Check if the node is used by any of domus. Removes the node only when
it's not used by any domain.
3. Removes IRQ permissions and MMIO access.
5. Find the node in dt_host and delete the device node entry from dt_host.
6. Free the overlay_tracker entry which means free dt_host_new also(created
in adding node step).

The main purpose of this series to address first part of the dynamic programming
i.e. making Xen aware of new device tree node which means updating the dt_host
with overlay node information. Here we are adding/removing node from dt_host,
and checking/set IOMMU and IRQ permission but never mapping them to any domain.
Right now, mapping/Un-mapping will happen only when a new domU is
created/destroyed using "xl create".

To map IOREQ and IOMMU during runtime, there will be another small series after
this one where we will do the actual IOMMU and IRQ mapping to a running domain
and will call unmap_mmio_regions() to remove the mapping.

Change Log:
 v5 -> v6:
Add separate patch for memory allocation failure in 
__unflatten_device_tree().
Move __unflatten_device_tree() function type changes to single patch.
Add error propagation for failures in unflatten_dt_node.
Change CONFIG_OVERLAY_DTB status to "ARM: Tech Preview".
xen/smmu: Add remove_device callback for smmu_iommu ops:
Added check to see if device is currently used.
common/device_tree: Add rwlock for dt_host:
Addressed feedback from Henry to rearrange code.
xen/arm: Implement device tree node removal functionalities:
Changed file name to dash format.
Addressed Michal's comments.
Rectified formatting related errors pointed by Michal.

 v4 -> v5:
Split patch 01/16 to two patches. One with function type changes and another
with changes inside unflatten_device_tree().
Change dt_overlay xl command to dt-overlay.
Protect overlay functionality with CONFIG(arm).
Fix rwlock issues.
Move include "device_tree.h" to c file where arch_cpu_init() is called and
forward declare dt_device_node. This was done to avoid circular deps b/w
device_tree.h and rwlock.h
Address Michal's comment on coding style.

 v3 -> v4:
Add support for adding node's children.
Add rwlock to dt_host functions.
Corrected fdt size issue when applying overlay into it.
Add memory allocation fail handling for unflatten_device_tree().
Changed xl overlay to xl dt_overlay.
Correct commit messages.
Addressed code issue from v3 review.

 v2 -> v3:
Moved overlay functionalities to dt_overlay.c file.
Renamed XEN_SYSCTL_overlay to XEN_SYSCTL_dt_overlay.
Add dt_* prefix to overlay_add/remove_nodes.
Added dtdevs_lock to protect iommu_add_dt_device().
For iommu, moved spin_lock to caller.
Address code issue from v2 review.

 v1 -> v2:
Add support for multiple node addition/removal using dtbo.
Replaced fpga-add and fpga-remove with one hypercall overlay_op.
Moved common domain_build.c function to device.c
Add OVERLAY_DTB configuration.
Renamed overlay_get_target() to fdt_overlay_get_target().
Split remove_device patch into two patches.
Moved overlay_add/remove code to sysctl and changed it from domctl to 
sysctl.
Added all overlay code under CONFIG_OVERLAY_DTB
Renamed all tool domains fpga function to overlay
Addressed code issues from v1 review.

Regards,
Vikram

Vikram Garhwal (19):
  common/device_tree: handle memory allocation failure in
__unflatten_device_tree()
  common/device_tree.c: unflatten_device_tree() propagate errors
  xen/arm/device: Remove __init from function type
  common/device_tree: Export __unflatten_device_tree()
  xen/arm: Add CONFIG_OVERLAY_DTB
  libfdt: Keep fdt functions after init for CONFIG_OVERLAY_DTB.
  libfdt: overlay: change overlay_get_target()
  xen/device-tree: Add device_tree_find_node_by_path() to find nodes in
device tree
  xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller
  xen/iommu: protect iommu_add_dt_device() with dtdevs_lock
  xen/iommu: Introduce iommu_remove_dt_device()
  xen/smmu: Add remove_device callback for smmu_iommu ops
  asm/smp.h: Fix circular dependency for device_tree.h and rwlock.h
  common/device_tree: Add rwlock for dt_host
  xen/arm: Implement device tree node removal functionalities
  xen/arm: Implement device 

Re: Community Manager update - August 2023

[Chuck Zmudzinski]

On 8/18/2023 6:55 AM, Kelly Choi wrote:
> Hi everyone! :) 
> 
> I hope you're all well. 
> 
> If we haven't met before, I'd like to introduce myself. I'm Kelly, the 
> Community Manager for The Xen Project. My role is to support everyone and 
> make sure the project is healthy and thriving. 
> 
> *The latest update below requires your attention:*
> *
> *
> 
>   * *We will be moving IRC channels fully to Matrix in September 2023. Once 
> the channels have been created, further information will be shared. *
>   * *New Mission Statement, goals, and purpose is attached to this email and 
> will be shared publicly.*
> 
> *Should anyone have any concerns or feedback, please let me know*
> 
> Many thanks,
> Kelly Choi
> 
> Open Source Community Manager, XenServer
> Cloud Software Group

This looks good, but I thought IBM rebranded Softlayer as IBM Cloud several 
years ago. Maybe IBM Softlayer should be changed to IBM Cloud? Thanks.

Chuck

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  b2865c2b6f164d2c379177cdd1cb200e4eaba549
baseline version:
 xen  cd36188b2762a05c322a5f56bcfce59c2d9cac2e

Last test of basis   182386  2023-08-18 16:02:00 Z0 days
Testing same since   182388  2023-08-18 20:03:50 Z0 days1 attempts


People who touched revisions under test:
  Jinoh Kang 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   cd36188b27..b2865c2b6f  b2865c2b6f164d2c379177cdd1cb200e4eaba549 -> smoke

[xtf test] 182389: all pass - PUSHED

[osstest service owner]

flight 182389 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182389/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  cec23a34c03ffcf12d68d35f0e1d7f9ae85ab49c
baseline version:
 xtf  bf1c4eb6cb52785cf539eb83752dfcecfe66c5d1

Last test of basis   176259  2023-01-27 21:12:33 Z  203 days
Testing same since   182389  2023-08-18 20:10:53 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xtf.git
   bf1c4eb..cec23a3  cec23a34c03ffcf12d68d35f0e1d7f9ae85ab49c -> 
xen-tested-master

Re: [XEN][PATCH v8 09/19] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller

[Julien Grall]

Hi Vikram,

On 18/08/2023 20:52, Vikram Garhwal wrote:

Hi Jan
On Thu, Aug 17, 2023 at 09:05:44AM +0200, Jan Beulich wrote:

On 17.08.2023 02:39, Vikram Garhwal wrote:

--- /dev/null
+++ b/xen/include/xen/iommu-private.h


I don't think private headers should live in include/xen/. Judging from only
the patches I was Cc-ed on, ...

Thank you for suggestion. Do you where can i place it then?
Please see another comment down regarding who might be using this function.



@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * xen/iommu-private.h
+ */
+#ifndef __XEN_IOMMU_PRIVATE_H__
+#define __XEN_IOMMU_PRIVATE_H__
+
+#ifdef CONFIG_HAS_DEVICE_TREE
+#include 
+
+/*
+ * Checks if dt_device_node is assigned to a domain or not. This function
+ * expects to be called with dtdevs_lock acquired by caller.
+ */
+bool_t iommu_dt_device_is_assigned_locked(const struct dt_device_node *dev);
+#endif


... I don't even see the need for the declaration, as the function is used
only from the file also defining it. But of course if there is a use
elsewhere (in Arm-only code, as is suggested by the description here), then
the header (under a suitable name) wants to live under drivers/passthrough/
(and of course be included only from anywhere in that sub-tree).


This is also use in smmu.c:arm_smmu_dt_remove_device_legacy(). This is added in
12/19 patch(xen/smmu: Add remove_device callback for smmu_iommu ops).


AFAICT, the caller of this function (iommu_remove_dt_device()) will 
already check if the device was assigned and bail out if that's the case.



So why do we need to check it again in the SMMU driver?

And if you really need to then you most likely want to check the 
internal state of the SMMU driver rather than the generic state.


Cheers,

--
Julien Grall

Re: [PATCH 0/6] x86/debug: fix guest dr6 value for single stepping and HW breakpoints

[Andrew Cooper]

On 18/08/2023 4:44 pm, Jinoh Kang wrote:
> Xen has a bug where hardware breakpoint exceptions (DR_TRAP) are
> erroneously recognized as single-stepping exceptions (DR_STEP).

I expected this to come back and bite.

https://lore.kernel.org/xen-devel/1528120755-17455-1-git-send-email-andrew.coop...@citrix.com/

Xen's %dr6 handling is very broken, and then Spectre/Meltdown happened
and some how my bugfixes are now 5 years old and still incomplete.  I've
got a form of this series rebased onto staging, which I'll need to dust off.


That said, I was not aware of this specific case going wrong.  (But I
can't say I'm surprised.)

Thankyou for the test case.  If I'm reading it right, the problem is
that when %dr0 genuinely triggers, we VMExit (to break #DB infinite
loops), and on re-injecting the #DB back to the guest, we blindly set
singlestep?

This is wrong for #DB faults, and you're using an instruction breakpoint
so that matches.

However, it is far more complicated for #DB traps, where hardware leaves
it up to the VMM to merge status bits, and it's different between PV,
VT-x and SVM.

Worse than that, there is an bug on Intel hardware where if a singlestep
is genuinely pending, then data breakpoint information isn't passed to
the VMM on VMExit.  I have yet to persuade Intel to fix this, despite
quite a lot of trying.

Looking at patch 3, I think I can see how it fixes your bug, but I don't
think the logic is correct in all cases.  In particular, look at my
series for the cases where  X86_DR6_DEFAULT is used to flip polarity. 
Notably, PV and SVM have different dr6 polarity to VT-x's pending_dbg field.

Also, on Intel you're supposed to leave pending bits in pending_dbg and
not inject #DB directly, in order for the pipeline to get the exception
priority in the right order.  This I didn't get around to fixing at the
time.


I suspect what we'll need to do is combine parts of your series and
parts of mine.  I never got around to fixing the introspection bugs in
mine (that's a far larger task to do nicely), and yours is more targetted.

~Andrew

Re: Community Manager update - August 2023

[Stefano Stabellini]

On Fri, 18 Aug 2023, Bertrand Marquis wrote:
> Hi Kelly,
> 
> > On 18 Aug 2023, at 12:55, Kelly Choi  wrote:
> >
> > Hi everyone! :)
> >
> > I hope you're all well.
> >
> > If we haven't met before, I'd like to introduce myself. I'm Kelly, the 
> > Community Manager for The Xen Project. My role is to support
> everyone and make sure the project is healthy and thriving.
> >
> > The latest update below requires your attention:
> >
> > • We will be moving IRC channels fully to Matrix in September 2023. 
> >Once the channels have been created, further information will be
> shared.
> > • New Mission Statement, goals, and purpose is attached to this email 
> >and will be shared publicly.
> > Should anyone have any concerns or feedback, please let me know
> 
> In embedded and automotive in particular one keyword that would be 
> interesting to have is "Safety".
> 
> We could add it in the mission statement and in the embedded technology goals:
> - The project aims to enable innovation, scalability, safety and security in 
> virtualization solutions.
> - Transform embedded and automotive sectors with mature, safe and secure 
> solutions.
> 
> What do other think ?

I agree, good idea.


> >
> > Many thanks,
> > Kelly Choi
> >
> > Open Source Community Manager, XenServer
> > Cloud Software Group
> 
> 
> 

Re: [PATCH 3/6] x86: don't assume #DB is always caused by singlestep if EFLAGS.TF is set

[Jinoh Kang]

On 8/19/23 00:47, Jinoh Kang wrote:
> Today, when a HVM (or PVH) guest triggers a hardware breakpoint while
> EFLAGS.TF is set, Xen incorrectly assumes that this is a single stepping
> exception and sets DR_STEP in dr6 in addition to DR_TRAP.
> 
> This causes problems with Linux HW breakpoint handler, which ignores
> DR_TRAP bits when DR_STEP is set.  This prevents user-mode debuggers
> from recognizing hardware breakpoints if EFLAGS.TF is set.
> 
> Fix this by not setting DR_STEP in {vmx,svm}_inject_event, unless the
> emulator explicitly signals the single-stepping mode via the newly added
> "singlestep" boolean field of struct x86_event.

s/the newly added "singlestep" boolean field/the 'extra' field/.  oops.

> 
> Fixes: 8b831f4189 ("x86: single step after instruction emulation")
> Signed-off-by: Jinoh Kang 
> ---
>  xen/arch/x86/hvm/emulate.c |  3 ++-
>  xen/arch/x86/hvm/svm/svm.c |  6 +++---
>  xen/arch/x86/hvm/vmx/vmx.c |  6 +++---
>  xen/arch/x86/include/asm/hvm/hvm.h | 12 
>  xen/arch/x86/mm/shadow/multi.c |  5 +++--
>  xen/arch/x86/x86_emulate/x86_emulate.h |  4 +++-
>  6 files changed, 26 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 9b6e4c8bc61b..5ad372466e1d 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct hvmemul_cache
>  {
> @@ -2673,7 +2674,7 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
> *hvmemul_ctxt,
>  }
>  
>  if ( hvmemul_ctxt->ctxt.retire.singlestep )
> -hvm_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
> +hvm_inject_debug_exception(DR_STEP);
>  
>  new_intr_shadow = hvmemul_ctxt->intr_shadow;
>  
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index d5e8cb0722ca..f25d6a53f092 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -96,7 +96,7 @@ void __update_guest_eip(struct cpu_user_regs *regs, 
> unsigned int inst_len)
>  curr->arch.hvm.svm.vmcb->int_stat.intr_shadow = 0;
>  
>  if ( regs->eflags & X86_EFLAGS_TF )
> -hvm_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
> +hvm_inject_debug_exception(DR_STEP);
>  }
>  
>  static void cf_check svm_cpu_down(void)
> @@ -1328,10 +1328,10 @@ static void cf_check svm_inject_event(const struct 
> x86_event *event)
>  switch ( _event.vector | -(_event.type == X86_EVENTTYPE_SW_INTERRUPT) )
>  {
>  case X86_EXC_DB:
> -if ( regs->eflags & X86_EFLAGS_TF )
> +if ( event->extra )
>  {
>  __restore_debug_registers(vmcb, curr);
> -vmcb_set_dr6(vmcb, vmcb_get_dr6(vmcb) | DR_STEP);
> +vmcb_set_dr6(vmcb, vmcb_get_dr6(vmcb) | event->extra);
>  }
>  /* fall through */
>  case X86_EXC_BP:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 8823ca13e55d..1795b9479cf9 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2022,10 +2022,10 @@ static void cf_check vmx_inject_event(const struct 
> x86_event *event)
>  switch ( _event.vector | -(_event.type == X86_EVENTTYPE_SW_INTERRUPT) )
>  {
>  case X86_EXC_DB:
> -if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF )
> +if ( event->extra )
>  {
>  __restore_debug_registers(curr);
> -write_debugreg(6, read_debugreg(6) | DR_STEP);
> +write_debugreg(6, read_debugreg(6) | event->extra);
>  }
>  if ( !nestedhvm_vcpu_in_guestmode(curr) ||
>   !nvmx_intercepts_exception(curr, X86_EXC_DB, _event.error_code) 
> )
> @@ -3068,7 +3068,7 @@ void update_guest_eip(void)
>  }
>  
>  if ( regs->eflags & X86_EFLAGS_TF )
> -hvm_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
> +hvm_inject_debug_exception(DR_STEP);
>  }
>  
>  static void cf_check vmx_fpu_dirty_intercept(void)
> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h 
> b/xen/arch/x86/include/asm/hvm/hvm.h
> index f3f6310ab684..6a0b9e3ff01e 100644
> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -538,6 +538,18 @@ static inline void hvm_inject_page_fault(int errcode, 
> unsigned long cr2)
>  hvm_inject_event();
>  }
>  
> +static inline void hvm_inject_debug_exception(unsigned long pending_dbg)
> +{
> +struct x86_event event = {
> +.vector = X86_EXC_DB,
> +.type = X86_EVENTTYPE_HW_EXCEPTION,
> +.error_code = X86_EVENT_NO_EC,
> +.extra = pending_dbg,
> +};
> +
> +hvm_inject_event();
> +}
> +
>  static inline bool hvm_event_pending(const struct vcpu *v)
>  {
>  return alternative_call(hvm_funcs.event_pending, v);
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index cf74fdf5dda6..365af5169750 100644
> --- 

Re: [XEN][PATCH v8 09/19] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller

[Vikram Garhwal]

Hi Jan
On Thu, Aug 17, 2023 at 09:05:44AM +0200, Jan Beulich wrote:
> On 17.08.2023 02:39, Vikram Garhwal wrote:
> > --- /dev/null
> > +++ b/xen/include/xen/iommu-private.h
> 
> I don't think private headers should live in include/xen/. Judging from only
> the patches I was Cc-ed on, ...
Thank you for suggestion. Do you where can i place it then?
Please see another comment down regarding who might be using this function.
> 
> > @@ -0,0 +1,28 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * xen/iommu-private.h
> > + */
> > +#ifndef __XEN_IOMMU_PRIVATE_H__
> > +#define __XEN_IOMMU_PRIVATE_H__
> > +
> > +#ifdef CONFIG_HAS_DEVICE_TREE
> > +#include 
> > +
> > +/*
> > + * Checks if dt_device_node is assigned to a domain or not. This function
> > + * expects to be called with dtdevs_lock acquired by caller.
> > + */
> > +bool_t iommu_dt_device_is_assigned_locked(const struct dt_device_node 
> > *dev);
> > +#endif
> 
> ... I don't even see the need for the declaration, as the function is used
> only from the file also defining it. But of course if there is a use
> elsewhere (in Arm-only code, as is suggested by the description here), then
> the header (under a suitable name) wants to live under drivers/passthrough/
> (and of course be included only from anywhere in that sub-tree).
> 
This is also use in smmu.c:arm_smmu_dt_remove_device_legacy(). This is added in
12/19 patch(xen/smmu: Add remove_device callback for smmu_iommu ops).

I will make sure to cc you for all the patches in v9 series. I plan to send
it today.

> Jan

Re: [XTF PATCH] xtf-runner: python3 fix

[Andrew Cooper]

On 17/08/2023 11:51 am, Anthony PERARD wrote:
> issue:
>   File "/home/xtf/xtf-runner", line 410, in interpret_selection
> if not line.startswith("xen_caps"):
>^^^
> TypeError: startswith first arg must be bytes or a tuple of bytes, not str
>
> Adding `universal_newlines` open stdout as text file, so line should
> be a `str`. `universal_newlines` is available on python 2.7. A new
> alias `text` is only available in python 3.7.
>
> Signed-off-by: Anthony PERARD 
> ---
>
> Notes:
> I've only tested the patch on Debian Bookworm, with python-is-python3
> package (python symlink) as osstest run `./xtf-runner ...`.
> 
> I haven't tried python2.7.

Seems to work on Py2.7.

Reviewed-by: Andrew Cooper  and pushed.  Thanks.

Re: [PATCH] x86/svm: invert valid condition in svm_get_pending_event()

[Andrew Cooper]

On 18/08/2023 5:03 pm, Jinoh Kang wrote:
> Fixes: 9864841914c2 ("x86/vm_event: add support for 
> VM_EVENT_REASON_INTERRUPT")
> Signed-off-by: Jinoh Kang 

Yeah, that's just straight up broken.  I'm not aware of anyone having
used this in anger on AMD systems yet.

Reviewed-by: Andrew Cooper 

I've tweaked the commit message a little bit on commit, to make it
clearer what you're doing.  (You're not making the valid condition
invalid, which is one interpretation of "invert" in that context).

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  cd36188b2762a05c322a5f56bcfce59c2d9cac2e
baseline version:
 xen  5cd6585177e99947a5f62345edbe657663ad9fcc

Last test of basis   182385  2023-08-18 13:00:25 Z0 days
Testing same since   182386  2023-08-18 16:02:00 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   5cd6585177..cd36188b27  cd36188b2762a05c322a5f56bcfce59c2d9cac2e -> smoke

[xen-unstable test] 182377: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  38ba0466a1e262edd031500d24919fbf4e48c794
baseline version:
 xen  38ba0466a1e262edd031500d24919fbf4e48c794

Last test of basis   182377  2023-08-18 05:14:40 Z0 days
Testing same since  (not found) 0 attempts

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

Re: [PATCH 1/2] tools/libs: light: Remove the variable 'domainid' do_pci_remove()

[Anthony PERARD]

On Wed, Aug 09, 2023 at 11:33:04AM +0100, Julien Grall wrote:
> From: Julien Grall 
> 
> The function do_pci_remove() has two local variables 'domid' and
> 'domainid' containing the same value.
> 
> Looking at the history, until 2cf3b50dcd8b ("libxl_pci: Use
> libxl__ao_device with pci_remove") the two variables may have
> different value when using a stubdomain.
> 
> As this is not the case now, remove 'domainid'. This will reduce
> the confusion between the two variables.
> 
> Note that there are other places in libxl_pci.c which are using
> the two confusing names within the same function. They are left
> unchanged for now.
> 
> No functional changes intented.
> 
> Signed-off-by: Julien Grall 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

Re: [PATCH 2/2] tools/light: Revoke permissions when a PCI detach for HVM domain

[Anthony PERARD]

On Wed, Aug 09, 2023 at 11:33:05AM +0100, Julien Grall wrote:
> From: Julien Grall 
> 
> Currently, libxl will grant IOMEM, I/O port and IRQ permissions when
> a PCI is attached (see pci_add_dm_done()) for all domain types. However,
> the permissions are only revoked for non-HVM domain (see do_pci_remove()).
> 
> This means that HVM domains will be left with extra permissions. While
> this look bad on the paper, the IRQ permissions should be revoked
> when the Device Model call xc_physdev_unmap_pirq() and such domain
> cannot directly mapped I/O port and IOMEM regions. Instead, this has to
> be done by a Device Model.
> 
> The Device Model can only run in dom0 or PV stubdomain (upstream libxl
> doesn't have support for HVM/PVH stubdomain).
> 
> For PV/PVH stubdomain, the permission are properly revoked, so there is
> no security concern.
> 
> This leaves dom0. There are two cases:
>   1) Privileged: Anyone gaining access to the Device Model would already
>  have large control on the host.
>   2) Deprivileged: PCI passthrough require PHYSDEV operations which
>  are not accessible when the Device Model is restricted.
> 
> So overall, it is believed that the extra permissions cannot be exploited.
> 
> Rework the code so the permissions are all removed for HVM domains.
> This needs to happen after the QEMU has detached the device. So
> the revocation is now moved in a separate function which is called
> from pci_remove_detached().
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> TODO: I am getting a bit confused with the async work in libxl. I am
> not entirely sure whether pci_remove_detached() is the correct place
> to revoke.

Whenever an async task in libxl takes more than one function to
complete, the next function (or callback) that is going to be executed
is further down in the current source file (usually). This is to try to
avoid too much confusion when reading through a set of async calls. So
pci_remove_detached() is after all the DM stuff are done, and it's
before we deal with stubdom case which will go through these step again,
so it seems appropriate.

So, this new pci_revoke_permissions() function been place before
do_pci_remove() will make it harder to follow what do_pci_remove() does.
Does it need to be a separate function? Can't you inline it in
pci_remove_detached() ?

If it does needs to be a separate function, a better way to lay it down
would be to replace calls to pci_remove_detached() by
pci_revoke_permissions() as appropriate, and rename it with the prefixed
"pci_remove_", that is pci_remove_revoke_permissions().

> TODO: For HVM, we are now getting the following error on detach:
> libxl: error: libxl_pci.c:2009:pci_revoke_permissions: Domain 
> 3:xc_physdev_unmap_pirq irq=23: Invalid argument
> 
> This is because the IRQ was unmapped by QEMU. It doesn't feel
> right to skip the call. So maybe we can ignore the error?

The error is already ignore. But I guess you just want to skip writing
an error message. But I think we should still write something, at least
a DEBUG message. Also add a comment that QEMU also unmap it, so errors
are expected.

> diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
> index 7f5f170e6eb0..f5a4b88eb2c0 100644
> --- a/tools/libs/light/libxl_pci.c
> +++ b/tools/libs/light/libxl_pci.c
> @@ -1980,75 +2052,19 @@ static void do_pci_remove(libxl__egc *egc, 
> pci_remove_state *prs)
>  prs->xswait.timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
>  prs->xswait.callback = pci_remove_qemu_trad_watch_state_cb;
>  rc = libxl__xswait_start(gc, >xswait);
> -if (rc) goto out_fail;
> -return;
> +if (!rc) return;

This is confusing, we usually check for error condition in libxl, not
success condition. So the currently written code is better.

> +break;
>  case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
>  pci_remove_qmp_device_del(egc, prs); /* must be last */
>  return;
>  default:
>  rc = ERROR_INVAL;
> -goto out_fail;
> +break;

You can keep the goto here, this is the usual way to deal with error.
(except a label named "out" would be more appropriate, but out_fail is
fine).

>  }
>  } else {
> +rc = 0;

You don't need to set rc in the else block and just set it after the if.
The true block of the "if(hvm)" can skip to out_fail on error to avoid
the rc=0. That's an expected pattern in libxl.


>  }
> -skip_irq:
> -rc = 0;
> +
>  out_fail:
>  pci_remove_detached(egc, prs, rc); /* must be last */
>  }
> @@ -2242,6 +2258,8 @@ static void pci_remove_detached(libxl__egc *egc,
>  if (rc && !prs->force)
>  goto out;
>  
> +pci_revoke_permissions(egc, prs);
> +
>  isstubdom = libxl_is_stubdom(CTX, domid, );
>  
>  /* don't do multiple resets while some functions are still passed 
> through */

Thanks,

-- 
Anthony PERARD

[PATCH] x86/svm: invert valid condition in svm_get_pending_event()

[Jinoh Kang]

Fixes: 9864841914c2 ("x86/vm_event: add support for VM_EVENT_REASON_INTERRUPT")
Signed-off-by: Jinoh Kang 
---
 xen/arch/x86/hvm/svm/svm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 01dd592d9b83..beb076ea8d62 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2415,7 +2415,7 @@ static bool cf_check svm_get_pending_event(
 {
 const struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 
-if ( vmcb->event_inj.v )
+if ( !vmcb->event_inj.v )
 return false;
 
 info->vector = vmcb->event_inj.vector;
-- 
2.41.0

[libvirt test] 182376: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 
182382-retest

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

version targeted for testing:
 libvirt  edfce77ba210fe840ee4aede3e1a68b0b14a8ad6
baseline version:
 libvirt  5d8e842a0fe093e707e8e8e56d70923a0e8a58fe

Last test of basis   182368  2023-08-17 04:22:00 Z1 days
Testing same since   182376  2023-08-18 04:18:56 Z0 days1 attempts


People who touched revisions under test:
  Göran Uddeborg 
  Michal Privoznik 

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   fail
 test-armhf-armhf-libvirt-qcow2   pass
 test-arm64-arm64-libvirt-raw pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-libvirt-vhd pass

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  5cd6585177e99947a5f62345edbe657663ad9fcc
baseline version:
 xen  e6cb27f2f20d09dd2ba135fbc341a4dc98656e10

Last test of basis   182379  2023-08-18 09:00:26 Z0 days
Testing same since   182385  2023-08-18 13:00:25 Z0 days1 attempts


People who touched revisions under test:
  Juergen Gross 
  Julien Grall 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   e6cb27f2f2..5cd6585177  5cd6585177e99947a5f62345edbe657663ad9fcc -> smoke

[PATCH 6/6] x86/debug: actually plumb pending_dbg through the monitor and devicemodel interfaces

[Jinoh Kang]

Commit 21867648033d ("x86/debug: Plumb pending_dbg through the monitor
and devicemodel interfaces") introduced pending_dbg, but did not
actually populate or use the field.

Signed-off-by: Jinoh Kang 
---
 xen/arch/x86/hvm/svm/svm.c | 34 +++---
 xen/arch/x86/hvm/vmx/vmx.c | 32 
 2 files changed, 55 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index f25d6a53f092..139be9902dae 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2422,6 +2422,14 @@ static bool cf_check svm_get_pending_event(
 info->type = vmcb->event_inj.type;
 info->error_code = vmcb->event_inj.ec;
 
+if ( info->type == X86_EVENTTYPE_HW_EXCEPTION &&
+ info->vector == X86_EXC_DB )
+{
+unsigned long dr6 = v->arch.hvm.flag_dr_dirty ?
+vmcb_get_dr6(vmcb) : v->arch.dr6;
+info->extra = dr6 & ~DR_STATUS_RESERVED_ONE;
+}
+
 return true;
 }
 
@@ -2733,16 +2741,28 @@ void svm_vmexit_handler(void)
 if ( !v->domain->debugger_attached )
 {
 unsigned int trap_type;
+unsigned long exit_pending_dbg;
 
 if ( likely(exit_reason != VMEXIT_ICEBP) )
 {
 trap_type = X86_EVENTTYPE_HW_EXCEPTION;
 insn_len = 0;
+
+__restore_debug_registers(vmcb, v);
+
+/*
+ * NOTE: This is slightly wrong; old bits in dr6 are not
+ * automatically cleared by CPU on #DB, so it's not exactly
+ * equivalent to PENDING_DBG_EXCEPTIONS in semantics.
+ */
+exit_pending_dbg = vmcb_get_dr6(vmcb) & 
~DR_STATUS_RESERVED_ONE;
+vmcb_set_dr6(vmcb, DR_STATUS_RESERVED_ONE);
 }
 else
 {
 trap_type = X86_EVENTTYPE_PRI_SW_EXCEPTION;
 insn_len = svm_get_insn_len(v, INSTR_ICEBP);
+exit_pending_dbg = 0;
 
 if ( !insn_len )
 break;
@@ -2750,12 +2770,20 @@ void svm_vmexit_handler(void)
 
 rc = hvm_monitor_debug(regs->rip,
HVM_MONITOR_DEBUG_EXCEPTION,
-   trap_type, insn_len, 0);
+   trap_type, insn_len, exit_pending_dbg);
 if ( rc < 0 )
 goto unexpected_exit_type;
 if ( !rc )
-hvm_inject_exception(X86_EXC_DB,
- trap_type, insn_len, X86_EVENT_NO_EC);
+{
+if (trap_type == X86_EVENTTYPE_HW_EXCEPTION)
+{
+/* Updates DR6 where debugger can peek. */
+hvm_inject_debug_exception(exit_pending_dbg);
+}
+else
+hvm_inject_exception(X86_EXC_DB,
+ trap_type, insn_len, X86_EVENT_NO_EC);
+}
 }
 else
 domain_pause_for_debugger();
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 1795b9479cf9..63411b62cb94 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2469,6 +2469,14 @@ static bool cf_check vmx_get_pending_event(
 info->type = MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK);
 info->error_code = error_code;
 
+if ( info->type == X86_EVENTTYPE_HW_EXCEPTION &&
+ info->vector == X86_EXC_DB )
+{
+unsigned long dr6 = v->arch.hvm.flag_dr_dirty ?
+read_debugreg(6) : v->arch.dr6;
+info->extra = dr6 & ~DR_STATUS_RESERVED_ONE;
+}
+
 return true;
 }
 
@@ -4240,13 +4248,11 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
 case X86_EXC_DB:
 /*
- * Updates DR6 where debugger can peek (See 3B 23.2.1,
- * Table 23-1, "Exit Qualification for Debug Exceptions").
+ * See 3B 23.2.1, Table 23-1, "Exit Qualification for Debug
+ * Exceptions".
  */
 __vmread(EXIT_QUALIFICATION, _qualification);
 HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
-__restore_debug_registers(v);
-write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
 
 /*
  * Work around SingleStep + STI/MovSS VMEntry failures.
@@ -4285,22 +4291,32 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 
 if ( !v->domain->debugger_attached )
 {
-unsigned long insn_len = 0;
+unsigned long exit_pending_dbg = 0, insn_len = 0;
 int rc;
 unsigned long trap_type = MASK_EXTR(intr_info,
 INTR_INFO_INTR_TYPE_MASK);
 
-if ( trap_type >= X86_EVENTTYPE_SW_INTERRUPT )
+

[PATCH 5/6] x86/pv: factor out single-step debug trap injection

[Jinoh Kang]

Add pv_inject_debug_exception() helper and use it wherever
applicable.

This helper corresponds to hvm_inject_debug_exception() in HVM.

Signed-off-by: Jinoh Kang 
---
 xen/arch/x86/include/asm/domain.h | 12 
 xen/arch/x86/pv/emulate.c |  5 +
 xen/arch/x86/pv/ro-page-fault.c   |  5 +
 xen/arch/x86/pv/traps.c   | 10 ++
 4 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/include/asm/domain.h 
b/xen/arch/x86/include/asm/domain.h
index 0e445cff5c08..cfeb63da6cd6 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -741,6 +741,18 @@ static inline void pv_inject_page_fault(int errcode, 
unsigned long cr2)
 pv_inject_event();
 }
 
+static inline void pv_inject_debug_exception(unsigned long pending_dbg)
+{
+const struct x86_event event = {
+.vector = X86_EXC_DB,
+.type = X86_EVENTTYPE_HW_EXCEPTION,
+.error_code = X86_EVENT_NO_EC,
+.extra = pending_dbg,
+};
+
+pv_inject_event();
+}
+
 static inline void pv_inject_sw_interrupt(unsigned int vector)
 {
 const struct x86_event event = {
diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
index e7a1c0a2cc4f..865b05337192 100644
--- a/xen/arch/x86/pv/emulate.c
+++ b/xen/arch/x86/pv/emulate.c
@@ -72,10 +72,7 @@ void pv_emul_instruction_done(struct cpu_user_regs *regs, 
unsigned long rip)
 regs->rip = rip;
 regs->eflags &= ~X86_EFLAGS_RF;
 if ( regs->eflags & X86_EFLAGS_TF )
-{
-current->arch.dr6 |= DR_STEP | DR_STATUS_RESERVED_ONE;
-pv_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
-}
+pv_inject_debug_exception(DR_STEP);
 }
 
 uint64_t pv_get_reg(struct vcpu *v, unsigned int reg)
diff --git a/xen/arch/x86/pv/ro-page-fault.c b/xen/arch/x86/pv/ro-page-fault.c
index 238bfbeb4ac4..9c6042cab3b2 100644
--- a/xen/arch/x86/pv/ro-page-fault.c
+++ b/xen/arch/x86/pv/ro-page-fault.c
@@ -391,10 +391,7 @@ int pv_ro_page_fault(unsigned long addr, struct 
cpu_user_regs *regs)
 /* Fallthrough */
 case X86EMUL_OKAY:
 if ( ctxt.retire.singlestep )
-{
-current->arch.dr6 |= DR_STEP | DR_STATUS_RESERVED_ONE;
-pv_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
-}
+pv_inject_debug_exception(DR_STEP);
 
 /* Fallthrough */
 case X86EMUL_RETRY:
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index e5c9734b8204..4cf31558ac2f 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 void pv_inject_event(const struct x86_event *event)
@@ -64,7 +65,16 @@ void pv_inject_event(const struct x86_event *event)
 trace_pv_page_fault(event->extra, error_code);
 }
 else
+{
+if ( event->type == X86_EVENTTYPE_HW_EXCEPTION &&
+ vector == X86_EXC_DB )
+{
+if ( event->extra )
+curr->arch.dr6 |= event->extra | DR_STATUS_RESERVED_ONE;
+}
+
 trace_pv_trap(vector, regs->rip, use_error_code, error_code);
+}
 
 if ( use_error_code )
 {
-- 
2.41.0

[PATCH 3/6] x86: don't assume #DB is always caused by singlestep if EFLAGS.TF is set

[Jinoh Kang]

Today, when a HVM (or PVH) guest triggers a hardware breakpoint while
EFLAGS.TF is set, Xen incorrectly assumes that this is a single stepping
exception and sets DR_STEP in dr6 in addition to DR_TRAP.

This causes problems with Linux HW breakpoint handler, which ignores
DR_TRAP bits when DR_STEP is set.  This prevents user-mode debuggers
from recognizing hardware breakpoints if EFLAGS.TF is set.

Fix this by not setting DR_STEP in {vmx,svm}_inject_event, unless the
emulator explicitly signals the single-stepping mode via the newly added
"singlestep" boolean field of struct x86_event.

Fixes: 8b831f4189 ("x86: single step after instruction emulation")
Signed-off-by: Jinoh Kang 
---
 xen/arch/x86/hvm/emulate.c |  3 ++-
 xen/arch/x86/hvm/svm/svm.c |  6 +++---
 xen/arch/x86/hvm/vmx/vmx.c |  6 +++---
 xen/arch/x86/include/asm/hvm/hvm.h | 12 
 xen/arch/x86/mm/shadow/multi.c |  5 +++--
 xen/arch/x86/x86_emulate/x86_emulate.h |  4 +++-
 6 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 9b6e4c8bc61b..5ad372466e1d 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct hvmemul_cache
 {
@@ -2673,7 +2674,7 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
*hvmemul_ctxt,
 }
 
 if ( hvmemul_ctxt->ctxt.retire.singlestep )
-hvm_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
+hvm_inject_debug_exception(DR_STEP);
 
 new_intr_shadow = hvmemul_ctxt->intr_shadow;
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index d5e8cb0722ca..f25d6a53f092 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -96,7 +96,7 @@ void __update_guest_eip(struct cpu_user_regs *regs, unsigned 
int inst_len)
 curr->arch.hvm.svm.vmcb->int_stat.intr_shadow = 0;
 
 if ( regs->eflags & X86_EFLAGS_TF )
-hvm_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
+hvm_inject_debug_exception(DR_STEP);
 }
 
 static void cf_check svm_cpu_down(void)
@@ -1328,10 +1328,10 @@ static void cf_check svm_inject_event(const struct 
x86_event *event)
 switch ( _event.vector | -(_event.type == X86_EVENTTYPE_SW_INTERRUPT) )
 {
 case X86_EXC_DB:
-if ( regs->eflags & X86_EFLAGS_TF )
+if ( event->extra )
 {
 __restore_debug_registers(vmcb, curr);
-vmcb_set_dr6(vmcb, vmcb_get_dr6(vmcb) | DR_STEP);
+vmcb_set_dr6(vmcb, vmcb_get_dr6(vmcb) | event->extra);
 }
 /* fall through */
 case X86_EXC_BP:
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 8823ca13e55d..1795b9479cf9 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2022,10 +2022,10 @@ static void cf_check vmx_inject_event(const struct 
x86_event *event)
 switch ( _event.vector | -(_event.type == X86_EVENTTYPE_SW_INTERRUPT) )
 {
 case X86_EXC_DB:
-if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF )
+if ( event->extra )
 {
 __restore_debug_registers(curr);
-write_debugreg(6, read_debugreg(6) | DR_STEP);
+write_debugreg(6, read_debugreg(6) | event->extra);
 }
 if ( !nestedhvm_vcpu_in_guestmode(curr) ||
  !nvmx_intercepts_exception(curr, X86_EXC_DB, _event.error_code) )
@@ -3068,7 +3068,7 @@ void update_guest_eip(void)
 }
 
 if ( regs->eflags & X86_EFLAGS_TF )
-hvm_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
+hvm_inject_debug_exception(DR_STEP);
 }
 
 static void cf_check vmx_fpu_dirty_intercept(void)
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h 
b/xen/arch/x86/include/asm/hvm/hvm.h
index f3f6310ab684..6a0b9e3ff01e 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -538,6 +538,18 @@ static inline void hvm_inject_page_fault(int errcode, 
unsigned long cr2)
 hvm_inject_event();
 }
 
+static inline void hvm_inject_debug_exception(unsigned long pending_dbg)
+{
+struct x86_event event = {
+.vector = X86_EXC_DB,
+.type = X86_EVENTTYPE_HW_EXCEPTION,
+.error_code = X86_EVENT_NO_EC,
+.extra = pending_dbg,
+};
+
+hvm_inject_event();
+}
+
 static inline bool hvm_event_pending(const struct vcpu *v)
 {
 return alternative_call(hvm_funcs.event_pending, v);
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index cf74fdf5dda6..365af5169750 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "private.h"
 #include "types.h"
@@ -2788,7 +2789,7 @@ static int cf_check sh_page_fault(
 #endif
 
 if ( emul_ctxt.ctxt.retire.singlestep )
-hvm_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
+

[PATCH 4/6] x86/pv: set DR_STEP if single-stepping after ro page fault emulation

[Jinoh Kang]

Signed-off-by: Jinoh Kang 
---
 xen/arch/x86/pv/ro-page-fault.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/x86/pv/ro-page-fault.c b/xen/arch/x86/pv/ro-page-fault.c
index cad28ef928ad..238bfbeb4ac4 100644
--- a/xen/arch/x86/pv/ro-page-fault.c
+++ b/xen/arch/x86/pv/ro-page-fault.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 
 #include "emulate.h"
 #include "mm.h"
@@ -390,7 +391,10 @@ int pv_ro_page_fault(unsigned long addr, struct 
cpu_user_regs *regs)
 /* Fallthrough */
 case X86EMUL_OKAY:
 if ( ctxt.retire.singlestep )
+{
+current->arch.dr6 |= DR_STEP | DR_STATUS_RESERVED_ONE;
 pv_inject_hw_exception(X86_EXC_DB, X86_EVENT_NO_EC);
+}
 
 /* Fallthrough */
 case X86EMUL_RETRY:
-- 
2.41.0

[PATCH 2/6] x86emul: rename field 'cr2' of struct x86_event to 'extra'

[Jinoh Kang]

XEN_DMOP_inject_event() copies the 'cr2' argument to struct x86_event.
'cr2' is overladed to mean pending_dbg for a debug trap, but consumers
of struct x86_event always interpret it as CR2.

Clarify the role of the 'cr2' field by renaming it to 'extra', in
preparation for an upcoming patch that uses it to actually populate dr6.

Signed-off-by: Jinoh Kang 
---
 xen/arch/x86/hvm/dm.c  | 2 +-
 xen/arch/x86/hvm/hvm.c | 4 ++--
 xen/arch/x86/hvm/svm/nestedsvm.c   | 2 +-
 xen/arch/x86/hvm/svm/svm.c | 8 
 xen/arch/x86/hvm/vmx/vmx.c | 2 +-
 xen/arch/x86/include/asm/domain.h  | 2 +-
 xen/arch/x86/include/asm/hvm/hvm.h | 2 +-
 xen/arch/x86/pv/traps.c| 8 
 xen/arch/x86/x86_emulate/x86_emulate.h | 4 ++--
 9 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 462691f91d3c..48a0c09f7af3 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -314,7 +314,7 @@ static int inject_event(struct domain *d,
 v->arch.hvm.inject_event.type = data->type;
 v->arch.hvm.inject_event.insn_len = data->insn_len;
 v->arch.hvm.inject_event.error_code = data->error_code;
-v->arch.hvm.inject_event.cr2 = data->cr2;
+v->arch.hvm.inject_event.extra = data->cr2;
 smp_wmb();
 v->arch.hvm.inject_event.vector = data->vector;
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 48a77524f198..1abdec35257b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -507,7 +507,7 @@ static bool hvm_get_pending_event(struct vcpu *v, struct 
x86_event *info)
 
 if ( info->type == X86_EVENTTYPE_HW_EXCEPTION &&
  info->vector == X86_EXC_PF )
-info->cr2 = v->arch.hvm.guest_cr[2];
+info->extra = v->arch.hvm.guest_cr[2];
 
 return true;
 }
@@ -548,7 +548,7 @@ void hvm_do_resume(struct vcpu *v)
 if ( hvm_get_pending_event(v, ) )
 {
 hvm_monitor_interrupt(info.vector, info.type, info.error_code,
-  info.cr2);
+  info.extra);
 v->arch.monitor.next_interrupt_enabled = false;
 }
 }
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index a09b6abaaeaf..9bd2a304ac01 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -842,7 +842,7 @@ int cf_check nsvm_vcpu_vmexit_event(
 ASSERT(vcpu_nestedhvm(v).nv_vvmcx != NULL);
 
 nestedsvm_vmexit_defer(v, VMEXIT_EXCEPTION_DE + event->vector,
-   event->error_code, event->cr2);
+   event->error_code, event->extra);
 return NESTEDHVM_VMEXIT_DONE;
 }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 01dd592d9b83..d5e8cb0722ca 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1252,7 +1252,7 @@ static void svm_emul_swint_injection(struct x86_event 
*event)
 {
 fault = X86_EXC_PF;
 ec = pfinfo.ec;
-event->cr2 = pfinfo.linear;
+event->extra = pfinfo.linear;
 }
 
 goto raise_exception;
@@ -1345,8 +1345,8 @@ static void cf_check svm_inject_event(const struct 
x86_event *event)
 
 case X86_EXC_PF:
 ASSERT(_event.type == X86_EVENTTYPE_HW_EXCEPTION);
-curr->arch.hvm.guest_cr[2] = _event.cr2;
-vmcb_set_cr2(vmcb, _event.cr2);
+curr->arch.hvm.guest_cr[2] = _event.extra;
+vmcb_set_cr2(vmcb, _event.extra);
 break;
 }
 
@@ -1430,7 +1430,7 @@ static void cf_check svm_inject_event(const struct 
x86_event *event)
 if ( _event.vector == X86_EXC_PF &&
  _event.type == X86_EVENTTYPE_HW_EXCEPTION )
 HVMTRACE_LONG_2D(PF_INJECT, _event.error_code,
- TRC_PAR_LONG(_event.cr2));
+ TRC_PAR_LONG(_event.extra));
 else
 HVMTRACE_2D(INJ_EXC, _event.vector, _event.error_code);
 }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 7ec44018d4ed..8823ca13e55d 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2051,7 +2051,7 @@ static void cf_check vmx_inject_event(const struct 
x86_event *event)
 
 case X86_EXC_PF:
 ASSERT(_event.type == X86_EVENTTYPE_HW_EXCEPTION);
-curr->arch.hvm.guest_cr[2] = _event.cr2;
+curr->arch.hvm.guest_cr[2] = _event.extra;
 break;
 }
 
diff --git a/xen/arch/x86/include/asm/domain.h 
b/xen/arch/x86/include/asm/domain.h
index c2d9fc333be5..0e445cff5c08 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -735,7 +735,7 @@ static inline void pv_inject_page_fault(int errcode, 
unsigned long cr2)
 .vector = X86_EXC_PF,
 .type = X86_EVENTTYPE_HW_EXCEPTION,
 .error_code = errcode,
-.cr2 = cr2,
+.extra = cr2,
 };
 
 

[PATCH 1/6] x86/hvm: only populate info->cr2 for #PF in hvm_get_pending_event()

[Jinoh Kang]

Prepare for an upcoming patch that overloads the 'cr2' field for #DB.

Signed-off-by: Jinoh Kang 
---
 xen/arch/x86/hvm/hvm.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 3a99c0ff20be..48a77524f198 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -502,9 +502,14 @@ void hvm_migrate_pirqs(struct vcpu *v)
 
 static bool hvm_get_pending_event(struct vcpu *v, struct x86_event *info)
 {
-info->cr2 = v->arch.hvm.guest_cr[2];
+if ( !alternative_call(hvm_funcs.get_pending_event, v, info) )
+return false;
+
+if ( info->type == X86_EVENTTYPE_HW_EXCEPTION &&
+ info->vector == X86_EXC_PF )
+info->cr2 = v->arch.hvm.guest_cr[2];
 
-return alternative_call(hvm_funcs.get_pending_event, v, info);
+return true;
 }
 
 void hvm_do_resume(struct vcpu *v)
-- 
2.41.0

[PATCH 0/6] x86/debug: fix guest dr6 value for single stepping and HW breakpoints

[Jinoh Kang]

Xen has a bug where hardware breakpoint exceptions (DR_TRAP) are
erroneously recognized as single-stepping exceptions (DR_STEP).  This
interferes with userland debugging and allows (otherwise restricted)
usermode programs to detect Xen HVM (or PVH).  This patch series aim to
fix this.

The last patch is optional and finishes incomplete plumbing work
initiated by commit 21867648033d (x86/debug: Plumb pending_dbg through
the monitor and devicemodel interfaces, 2018-05-31).

The following Linux x86-64 program demonstrates the bug:

--- (snip) ---

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define ABORT_ON_ERR(x) if ((x) == -1) abort();

int main(void)
{
unsigned long cur_rip, cur_eflags, cur_dr6;
int wstatus, exit_code;
pid_t pid;

ABORT_ON_ERR(pid = fork());
if (pid == 0) {
ABORT_ON_ERR(ptrace(PTRACE_TRACEME, 0, NULL, NULL));
ABORT_ON_ERR(raise(SIGSTOP));
_exit(0);
}

/* Wait for first ptrace event */
if (waitpid(pid, , 0) != pid) abort();
if (!WIFSTOPPED(wstatus)) abort();

/* Obtain current RIP value and perform sanity check */
cur_rip = ptrace(PTRACE_PEEKUSER, pid, (void *)offsetof(struct user, 
regs.rip), _rip);
cur_dr6 = ptrace(PTRACE_PEEKUSER, pid, (void *)offsetof(struct user, 
u_debugreg[6]), _dr6);
assert(cur_dr6 == 0x0ff0UL);

/* Set up debug registers and set EFLAGS.TF */
cur_eflags = ptrace(PTRACE_PEEKUSER, pid, (void *)offsetof(struct user, 
regs.eflags), _eflags);
ABORT_ON_ERR(ptrace(PTRACE_POKEUSER, pid, (void *)offsetof(struct user, 
regs.eflags), (void *)(cur_eflags | 0x100UL)));
ABORT_ON_ERR(ptrace(PTRACE_POKEUSER, pid, (void *)offsetof(struct user, 
u_debugreg[0]), (void *)cur_rip));
ABORT_ON_ERR(ptrace(PTRACE_POKEUSER, pid, (void *)offsetof(struct user, 
u_debugreg[7]), (void *)1L));

/* Continue execution to trigger hardware breakpoint */
ABORT_ON_ERR(ptrace(PTRACE_CONT, pid, NULL, (unsigned long)0));
if (waitpid(pid, , 0) != pid) abort();
if (!(WIFSTOPPED(wstatus) && WSTOPSIG(wstatus) == SIGTRAP)) abort();

/* Detect if Xen has tampered with DR6 */
cur_dr6 = ptrace(PTRACE_PEEKUSER, pid, (void *)offsetof(struct user, 
u_debugreg[6]), _dr6);
fprintf(stderr, "DR6 = 0x%08lx\n", cur_dr6);
if (cur_dr6 == 0x0ff1UL)
{
fputs("Running on bare-metal, Xen PV, or non-Xen VMM\n", stdout);
exit_code = EXIT_FAILURE;
}
else
{
fputs("Running on Xen HVM\n", stdout);
exit_code = EXIT_SUCCESS;
}

/* Tear down debug registers and unset EFLAGS.TF */
cur_eflags = ptrace(PTRACE_PEEKUSER, pid, (void *)offsetof(struct user, 
regs.eflags), _eflags);
ABORT_ON_ERR(ptrace(PTRACE_POKEUSER, pid, (void *)offsetof(struct user, 
regs.eflags), (void *)(cur_eflags & ~0x100UL)));
ABORT_ON_ERR(ptrace(PTRACE_POKEUSER, pid, (void *)offsetof(struct user, 
u_debugreg[7]), (void *)0L));

/* Continue execution to let child process exit */
ABORT_ON_ERR(ptrace(PTRACE_CONT, pid, NULL, (unsigned long)0));
if (waitpid(pid, , 0) != pid) abort();
if (!(WIFEXITED(wstatus) && WEXITSTATUS(wstatus) == 0)) abort();

return exit_code;
}

--- (snip) ---

Jinoh Kang (6):
  x86/hvm: only populate info->cr2 for #PF in hvm_get_pending_event()
  x86emul: rename field 'cr2' of struct x86_event to 'extra'
  x86: don't assume #DB is always caused by singlestep if EFLAGS.TF is
set
  x86/pv: set DR_STEP if single-stepping after ro page fault emulation
  x86/pv: factor out single-step debug trap injection
  x86/debug: actually plumb pending_dbg through the monitor and
devicemodel interfaces

 xen/arch/x86/hvm/dm.c  |  2 +-
 xen/arch/x86/hvm/emulate.c |  3 +-
 xen/arch/x86/hvm/hvm.c | 11 --
 xen/arch/x86/hvm/svm/nestedsvm.c   |  2 +-
 xen/arch/x86/hvm/svm/svm.c | 48 --
 xen/arch/x86/hvm/vmx/vmx.c | 40 ++---
 xen/arch/x86/include/asm/domain.h  | 14 +++-
 xen/arch/x86/include/asm/hvm/hvm.h | 14 +++-
 xen/arch/x86/mm/shadow/multi.c |  5 +--
 xen/arch/x86/pv/emulate.c  |  5 +--
 xen/arch/x86/pv/ro-page-fault.c|  3 +-
 xen/arch/x86/pv/traps.c| 18 +++---
 xen/arch/x86/x86_emulate/x86_emulate.h |  6 ++--
 13 files changed, 128 insertions(+), 43 deletions(-)

-- 
2.41.0

Re: [PATCH v2 4/4] virtio-blk: remove batch notification BH

[Eric Blake]

On Thu, Aug 17, 2023 at 11:58:47AM -0400, Stefan Hajnoczi wrote:
> There is a batching mechanism for virtio-blk Used Buffer Notifications
> that is no longer needed because the previous commit added batching to
> virtio_notify_irqfd().
> 
> Note that this mechanism was rarely used in practice because it is only
> enabled when EVENT_IDX is not negotiated by the driver. Modern drivers
> enable EVENT_IDX.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  hw/block/dataplane/virtio-blk.c | 48 +
>  1 file changed, 1 insertion(+), 47 deletions(-)
>

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org

Re: [PATCH v2 3/4] virtio: use defer_call() in virtio_irqfd_notify()

[Eric Blake]

On Thu, Aug 17, 2023 at 11:58:46AM -0400, Stefan Hajnoczi wrote:
> virtio-blk and virtio-scsi invoke virtio_irqfd_notify() to send Used
> Buffer Notifications from an IOThread. This involves an eventfd
> write(2) syscall. Calling this repeatedly when completing multiple I/O
> requests in a row is wasteful.
> 
> Use the defer_call() API to batch together virtio_irqfd_notify() calls
> made during thread pool (aio=threads), Linux AIO (aio=native), and
> io_uring (aio=io_uring) completion processing.
> 
> Behavior is unchanged for emulated devices that do not use
> defer_call_begin()/defer_call_end() since defer_call() immediately
> invokes the callback when called outside a
> defer_call_begin()/defer_call_end() region.
> 
> fio rw=randread bs=4k iodepth=64 numjobs=8 IOPS increases by ~9% with a
> single IOThread and 8 vCPUs. iodepth=1 decreases by ~1% but this could
> be noise. Detailed performance data and configuration specifics are
> available here:
> https://gitlab.com/stefanha/virt-playbooks/-/tree/blk_io_plug-irqfd
> 
> This duplicates the BH that virtio-blk uses for batching. The next
> commit will remove it.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  block/io_uring.c   |  6 ++
>  block/linux-aio.c  |  4 
>  hw/virtio/virtio.c | 11 ++-
>  util/thread-pool.c |  5 +
>  4 files changed, 25 insertions(+), 1 deletion(-)

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org

[ovmf test] 182383: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 48089f3a7cdf308651234f5bf8d8a301f4b8acf9
baseline version:
 ovmf eaffa1d7ff915d5af484e5e230a4dde41e4b9a00

Last test of basis   182331  2023-08-14 15:12:20 Z3 days
Testing same since   182383  2023-08-18 12:42:20 Z0 days1 attempts


People who touched revisions under test:
  Corvin Köhne 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   eaffa1d7ff..48089f3a7c  48089f3a7cdf308651234f5bf8d8a301f4b8acf9 -> 
xen-tested-master

Re: [PATCH] Drop remains of prior SCMs

[Julien Grall]

Hi Andrew,

On 18/08/2023 15:45, Andrew Cooper wrote:

None of the mercurial metadata has been updated since around Xen 4.2, making
them more than a decade stale.

Signed-off-by: Andrew Cooper 


Acked-by: Julien Grall 

Cheers,


---
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Wei Liu 
CC: Julien Grall 
---
  .hgignore | 329 --
  .hgsigs   |  11 --
  .hgtags   |  59 --
  3 files changed, 399 deletions(-)
  delete mode 100644 .hgignore
  delete mode 100644 .hgsigs
  delete mode 100644 .hgtags

diff --git a/.hgignore b/.hgignore
deleted file mode 100644
index 2d416706321b..
--- a/.hgignore
+++ /dev/null
@@ -1,329 +0,0 @@
-.*\.a$
-.*\.cmi$
-.*\.cmo$
-.*\.cmx$
-\..*\.d$
-.*\.o$
-.*\.opic$
-.*\.pyc$
-.*\.so$
-.*\.so\..*$
-.*\.tar\.bz2$
-.*\.tar\.gz$
-.*~$
-.*\.swp$
-.*\.tmp$
-.*\.flc$
-.*\.orig$
-.*\.rej$
-.*\.spot$
-.*\.spit$
-.*\.gcno$
-.*\.gcda$
-.*/a\.out$
-.*/Modules\.symvers$
-.*/cscope\..*$
-^cscope.*$
-^[^/]*\.bz2$
-^\.config$
-^\.pc
-(^|/)(tags|TAGS)$
-(^|/)(GTAGS|GPATH|GSYMS|GRTAGS)$
-^autom4te\.cache$
-^config\.log$
-^config\.status$
-^config\.cache$
-^config/Toplevel\.mk$
-^build-.*$
-^dist/.*$
-^docs/autom4te\.cache$
-^docs/config\.log$
-^docs/config\.status
-^docs/config/Toplevel\.mk
-^docs/.*\.aux$
-^docs/.*\.dvi$
-^docs/.*\.log$
-^docs/.*\.pdf$
-^docs/.*\.ps$
-^docs/.*\.toc$
-^docs/api/.*$
-^docs/figs/xenserver\.eps$
-^docs/html/.*$
-^docs/interface/WARNINGS$
-^docs/interface/images\.pl$
-^docs/interface/images\.tex$
-^docs/interface/img1\.png$
-^docs/interface/index\.html$
-^docs/interface/interface\.css$
-^docs/interface/interface\.html$
-^docs/interface/labels\.pl$
-^docs/figs/.*\.png
-^docs/man1/
-^docs/man5/
-^docs/pdf/.*$
-^docs/ps/.*$
-^docs/user/WARNINGS$
-^docs/user/images\.pl$
-^docs/user/images\.tex$
-^docs/user/img1\.png$
-^docs/user/img2\.png$
-^docs/user/img3\.png$
-^docs/user/index\.html$
-^docs/user/internals\.pl$
-^docs/user/labels\.pl$
-^docs/user/user\.css$
-^docs/user/user\.html$
-^docs/txt/.*$
-^docs/xen-api/vm_lifecycle.eps$
-^docs/xen-api/xenapi-datamodel-graph.eps$
-^docs/xen-api/xenapi.out$
-^extras/mini-os/include/list\.h$
-^extras/mini-os/include/mini-os$
-^extras/mini-os/include/x86/mini-os$
-^extras/mini-os/include/xen$
-^extras/mini-os/mini-os.*$
-^install/.*$
-^linux-[^/]*-paravirt/.*$
-^linux-2.6[^/]*/.*$
-^linux-[^/]*-rc/.*$
-^linux-[^/]*-tip/.*$
-^linux-[^/]*-git/.*$
-^linux-[^/]*\.patch$
-^mkddbxen$
-^netbsd-[^/]*-tools/.*$
-^netbsd-[^/]*-xen0/.*$
-^netbsd-[^/]*-xenU/.*$
-^netbsd-[^/]*\.patch$
-^patches/.*/\.makedep$
-^patches/ebtables-brnf-5_vs_2\.4\.25\.diff$
-^patches/ebtables\.diff$
-^patches/tmp/.*$
-^pristine-.*$
-^ref-.*$
-^tmp-.*$
-^stubdom/autom4te\.cache$
-^stubdom/binutils-.*$
-^stubdom/config\.log$
-^stubdom/config\.status$
-^stubdom/config\.cache$
-^stubdom/cross-root-.*$
-^stubdom/gcc-.*$
-^stubdom/include$
-^stubdom/ioemu$
-^stubdom/xenstore$
-^stubdom/libxc-.*$
-^stubdom/lwip-.*$
-^stubdom/mini-os-.*$
-^stubdom/mk-headers-.*$
-^stubdom/newlib-.*$
-^stubdom/pciutils-.*$
-^stubdom/zlib-.*$
-^stubdom/grub-.*$
-^stubdom/polarssl-.*$
-^stubdom/gmp-.*$
-^stubdom/tpm_emulator-.*$
-^stubdom/ocaml-.*$
-^stubdom/lwip/
-^stubdom/ioemu/
-^stubdom/stubdompath\.sh$
-^stubdom/vtpm/vtpm_manager\.h$
-^tools/.*/build/lib.*/.*\.py$
-^tools/check/\..*$
-^tools/console/xenconsole$
-^tools/console/xenconsoled$
-^tools/debugger/gdb/gdb-6\.2\.1-linux-i386-xen/.*$
-^tools/debugger/gdb/gdb-6\.2\.1/.*$
-^tools/debugger/gdb/gdb-6\.2\.1\.tar\.bz2$
-^tools/debugger/gdbsx/gdbsx$
-^tools/debugger/kdd/kdd$
-^tools/debugger/xenitp/xenitp$
-^tools/firmware/.*/biossums$
-^tools/firmware/.*\.bin$
-^tools/firmware/.*\.sym$
-^tools/firmware/.*bios/.*bios.*\.txt$
-^tools/firmware/etherboot/eb-roms\.h$
-^tools/firmware/etherboot/ipxe/.*$
-^tools/firmware/etherboot/ipxe\.git/.*$
-^tools/firmware/extboot/extboot.img$
-^tools/firmware/extboot/signrom$
-^tools/firmware/hvmloader/acpi/mk_dsdt$
-^tools/firmware/hvmloader/acpi/dsdt.*\.c$
-^tools/firmware/hvmloader/acpi/dsdt_.*\.asl$
-^tools/firmware/hvmloader/acpi/ssdt_.*\.h$
-^tools/firmware/hvmloader/hvmloader$
-^tools/firmware/hvmloader/roms\.inc$
-^tools/firmware/rombios/BIOS-bochs-[^/]*$
-^tools/firmware/rombios/_rombios[^/]*_\.c$
-^tools/firmware/rombios/rombios[^/]*\.s$
-^tools/firmware/rombios/32bit/32bitbios_flat\.h$
-^tools/firmware/vgabios/vbetables-gen$
-^tools/firmware/vgabios/vbetables\.h$
-^tools/firmware/xen-dir/.*\.old$
-^tools/firmware/xen-dir/linkfarm.stamp.*$
-^tools/firmware/xen-dir/xen-root$
-^tools/firmware/xen-dir/xen-shim$
-^tools/firmware/xen-dir/xen-shim-syms$
-^tools/flask/utils/flask-getenforce$
-^tools/flask/utils/flask-get-bool$
-^tools/flask/utils/flask-loadpolicy$
-^tools/flask/utils/flask-setenforce$
-^tools/flask/utils/flask-set-bool$
-^tools/flask/utils/flask-label-pci$
-^tools/fs-back/fs-backend$
-^tools/hotplug/common/hotplugpath\.sh$
-^tools/include/xen/.*$
-^tools/include/xen-foreign/.*\.(c|h|size)$

[PATCH] Drop remains of prior SCMs

[Andrew Cooper]

None of the mercurial metadata has been updated since around Xen 4.2, making
them more than a decade stale.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Wei Liu 
CC: Julien Grall 
---
 .hgignore | 329 --
 .hgsigs   |  11 --
 .hgtags   |  59 --
 3 files changed, 399 deletions(-)
 delete mode 100644 .hgignore
 delete mode 100644 .hgsigs
 delete mode 100644 .hgtags

diff --git a/.hgignore b/.hgignore
deleted file mode 100644
index 2d416706321b..
--- a/.hgignore
+++ /dev/null
@@ -1,329 +0,0 @@
-.*\.a$
-.*\.cmi$
-.*\.cmo$
-.*\.cmx$
-\..*\.d$
-.*\.o$
-.*\.opic$
-.*\.pyc$
-.*\.so$
-.*\.so\..*$
-.*\.tar\.bz2$
-.*\.tar\.gz$
-.*~$
-.*\.swp$
-.*\.tmp$
-.*\.flc$
-.*\.orig$
-.*\.rej$
-.*\.spot$
-.*\.spit$
-.*\.gcno$
-.*\.gcda$
-.*/a\.out$
-.*/Modules\.symvers$
-.*/cscope\..*$
-^cscope.*$
-^[^/]*\.bz2$
-^\.config$
-^\.pc
-(^|/)(tags|TAGS)$
-(^|/)(GTAGS|GPATH|GSYMS|GRTAGS)$
-^autom4te\.cache$
-^config\.log$
-^config\.status$
-^config\.cache$
-^config/Toplevel\.mk$
-^build-.*$
-^dist/.*$
-^docs/autom4te\.cache$
-^docs/config\.log$
-^docs/config\.status
-^docs/config/Toplevel\.mk
-^docs/.*\.aux$
-^docs/.*\.dvi$
-^docs/.*\.log$
-^docs/.*\.pdf$
-^docs/.*\.ps$
-^docs/.*\.toc$
-^docs/api/.*$
-^docs/figs/xenserver\.eps$
-^docs/html/.*$
-^docs/interface/WARNINGS$
-^docs/interface/images\.pl$
-^docs/interface/images\.tex$
-^docs/interface/img1\.png$
-^docs/interface/index\.html$
-^docs/interface/interface\.css$
-^docs/interface/interface\.html$
-^docs/interface/labels\.pl$
-^docs/figs/.*\.png
-^docs/man1/
-^docs/man5/
-^docs/pdf/.*$
-^docs/ps/.*$
-^docs/user/WARNINGS$
-^docs/user/images\.pl$
-^docs/user/images\.tex$
-^docs/user/img1\.png$
-^docs/user/img2\.png$
-^docs/user/img3\.png$
-^docs/user/index\.html$
-^docs/user/internals\.pl$
-^docs/user/labels\.pl$
-^docs/user/user\.css$
-^docs/user/user\.html$
-^docs/txt/.*$
-^docs/xen-api/vm_lifecycle.eps$
-^docs/xen-api/xenapi-datamodel-graph.eps$
-^docs/xen-api/xenapi.out$
-^extras/mini-os/include/list\.h$
-^extras/mini-os/include/mini-os$
-^extras/mini-os/include/x86/mini-os$
-^extras/mini-os/include/xen$
-^extras/mini-os/mini-os.*$
-^install/.*$
-^linux-[^/]*-paravirt/.*$
-^linux-2.6[^/]*/.*$
-^linux-[^/]*-rc/.*$
-^linux-[^/]*-tip/.*$
-^linux-[^/]*-git/.*$
-^linux-[^/]*\.patch$
-^mkddbxen$
-^netbsd-[^/]*-tools/.*$
-^netbsd-[^/]*-xen0/.*$
-^netbsd-[^/]*-xenU/.*$
-^netbsd-[^/]*\.patch$
-^patches/.*/\.makedep$
-^patches/ebtables-brnf-5_vs_2\.4\.25\.diff$
-^patches/ebtables\.diff$
-^patches/tmp/.*$
-^pristine-.*$
-^ref-.*$
-^tmp-.*$
-^stubdom/autom4te\.cache$
-^stubdom/binutils-.*$
-^stubdom/config\.log$
-^stubdom/config\.status$
-^stubdom/config\.cache$
-^stubdom/cross-root-.*$
-^stubdom/gcc-.*$
-^stubdom/include$
-^stubdom/ioemu$
-^stubdom/xenstore$
-^stubdom/libxc-.*$
-^stubdom/lwip-.*$
-^stubdom/mini-os-.*$
-^stubdom/mk-headers-.*$
-^stubdom/newlib-.*$
-^stubdom/pciutils-.*$
-^stubdom/zlib-.*$
-^stubdom/grub-.*$
-^stubdom/polarssl-.*$
-^stubdom/gmp-.*$
-^stubdom/tpm_emulator-.*$
-^stubdom/ocaml-.*$
-^stubdom/lwip/
-^stubdom/ioemu/
-^stubdom/stubdompath\.sh$
-^stubdom/vtpm/vtpm_manager\.h$
-^tools/.*/build/lib.*/.*\.py$
-^tools/check/\..*$
-^tools/console/xenconsole$
-^tools/console/xenconsoled$
-^tools/debugger/gdb/gdb-6\.2\.1-linux-i386-xen/.*$
-^tools/debugger/gdb/gdb-6\.2\.1/.*$
-^tools/debugger/gdb/gdb-6\.2\.1\.tar\.bz2$
-^tools/debugger/gdbsx/gdbsx$
-^tools/debugger/kdd/kdd$
-^tools/debugger/xenitp/xenitp$
-^tools/firmware/.*/biossums$
-^tools/firmware/.*\.bin$
-^tools/firmware/.*\.sym$
-^tools/firmware/.*bios/.*bios.*\.txt$
-^tools/firmware/etherboot/eb-roms\.h$
-^tools/firmware/etherboot/ipxe/.*$
-^tools/firmware/etherboot/ipxe\.git/.*$
-^tools/firmware/extboot/extboot.img$
-^tools/firmware/extboot/signrom$
-^tools/firmware/hvmloader/acpi/mk_dsdt$
-^tools/firmware/hvmloader/acpi/dsdt.*\.c$
-^tools/firmware/hvmloader/acpi/dsdt_.*\.asl$
-^tools/firmware/hvmloader/acpi/ssdt_.*\.h$
-^tools/firmware/hvmloader/hvmloader$
-^tools/firmware/hvmloader/roms\.inc$
-^tools/firmware/rombios/BIOS-bochs-[^/]*$
-^tools/firmware/rombios/_rombios[^/]*_\.c$
-^tools/firmware/rombios/rombios[^/]*\.s$
-^tools/firmware/rombios/32bit/32bitbios_flat\.h$
-^tools/firmware/vgabios/vbetables-gen$
-^tools/firmware/vgabios/vbetables\.h$
-^tools/firmware/xen-dir/.*\.old$
-^tools/firmware/xen-dir/linkfarm.stamp.*$
-^tools/firmware/xen-dir/xen-root$
-^tools/firmware/xen-dir/xen-shim$
-^tools/firmware/xen-dir/xen-shim-syms$
-^tools/flask/utils/flask-getenforce$
-^tools/flask/utils/flask-get-bool$
-^tools/flask/utils/flask-loadpolicy$
-^tools/flask/utils/flask-setenforce$
-^tools/flask/utils/flask-set-bool$
-^tools/flask/utils/flask-label-pci$
-^tools/fs-back/fs-backend$
-^tools/hotplug/common/hotplugpath\.sh$
-^tools/include/xen/.*$
-^tools/include/xen-foreign/.*\.(c|h|size)$
-^tools/include/xen-foreign/checker$
-^tools/libxl/_.*\.h$
-^tools/libxl/_.*\.c$

Re: [PATCH v5] tools/xenstore: move xenstored sources into dedicated directory

[Andrew Cooper]

On 18/08/2023 3:08 pm, Juergen Gross wrote:
> diff --git a/.gitignore b/.gitignore
> index c1b73b0968..c6489c4e70 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -237,22 +237,22 @@ tools/xenmon/xentrace_setmask
>  tools/xenmon/xenbaked
>  tools/xenpaging/xenpaging
>  tools/xenpmd/xenpmd
> -tools/xenstore/xenstore
> -tools/xenstore/xenstore-chmod
> -tools/xenstore/xenstore-control
> -tools/xenstore/xenstore-exists
> -tools/xenstore/xenstore-list
> -tools/xenstore/xenstore-ls
> -tools/xenstore/xenstore-read
> -tools/xenstore/xenstore-rm
> -tools/xenstore/xenstore-watch
> -tools/xenstore/xenstore-write
> -tools/xenstore/xenstored
> +tools/xenstored/xenstored
>  tools/xentop/xentop
>  tools/xentrace/xentrace_setsize
>  tools/xentrace/tbctl
>  tools/xentrace/xenctx
>  tools/xentrace/xentrace
> +tools/xs-clients/xenstore
> +tools/xs-clients/xenstore-chmod
> +tools/xs-clients/xenstore-control
> +tools/xs-clients/xenstore-exists
> +tools/xs-clients/xenstore-list
> +tools/xs-clients/xenstore-ls
> +tools/xs-clients/xenstore-read
> +tools/xs-clients/xenstore-rm
> +tools/xs-clients/xenstore-watch
> +tools/xs-clients/xenstore-write
>  xen/**/*.i
>  xen/**/*.s
>  xen/.banner

Please take the opportunity to move these into local .gitignore files. 
One less area of churn in future renaming.  Probably can be fixed on
commit as its only mechanical.

~Andrew

[PATCH v5] tools/xenstore: move xenstored sources into dedicated directory

[Juergen Gross]

In tools/xenstore there are living xenstored and xenstore clients.
They are no longer sharing anything apart from the "xenstore" in their
names.

Move the xenstored sources into a new directory tools/xenstored while
dropping the "xenstored_" prefix from their names. This will make it
clearer that xenstore clients and xenstored are independent from each
other.

In order to avoid two very similar named directories below tools,
rename tools/xenstore to tools/xs-clients.

Signed-off-by: Juergen Gross 
---
After the large overhaul of xenstored I think such a reorg would make
sense to go into the same Xen version. Delaying it until the next
version would make potential backports for 4.18 harder.
V4:
- new patch
V5:
- rename xenstore directory to xs-clients (Julien Grall)
---
 .gitignore| 22 -
 MAINTAINERS   |  3 +-
 stubdom/Makefile  |  4 +-
 tools/Makefile|  3 +-
 tools/xenstored/Makefile  | 48 +++
 tools/{xenstore => xenstored}/Makefile.common | 13 +++--
 tools/{xenstore => xenstored}/README  |  0
 .../control.c}|  8 ++--
 .../control.h}|  0
 .../xenstored_core.c => xenstored/core.c} | 14 +++---
 .../xenstored_core.h => xenstored/core.h} |  0
 .../xenstored_domain.c => xenstored/domain.c} | 10 ++--
 .../xenstored_domain.h => xenstored/domain.h} |  0
 tools/{xenstore => xenstored}/hashtable.c |  0
 tools/{xenstore => xenstored}/hashtable.h |  0
 tools/{xenstore => xenstored}/list.h  |  0
 .../xenstored_lu.c => xenstored/lu.c} |  8 ++--
 .../xenstored_lu.h => xenstored/lu.h} |  0
 .../lu_daemon.c}  |  4 +-
 .../lu_minios.c}  |  2 +-
 .../xenstored_minios.c => xenstored/minios.c} |  2 +-
 .../xenstored_osdep.h => xenstored/osdep.h}   |  0
 .../xenstored_posix.c => xenstored/posix.c}   |  4 +-
 tools/{xenstore => xenstored}/talloc.c|  0
 tools/{xenstore => xenstored}/talloc.h|  0
 .../{xenstore => xenstored}/talloc_guide.txt  |  0
 .../transaction.c}|  6 +--
 .../transaction.h}|  2 +-
 tools/{xenstore => xenstored}/utils.c |  0
 tools/{xenstore => xenstored}/utils.h |  0
 .../xenstored_watch.c => xenstored/watch.c}   |  6 +--
 .../xenstored_watch.h => xenstored/watch.h}   |  2 +-
 .../include => xenstored}/xenstore_state.h|  0
 tools/{xenstore => xs-clients}/Makefile   | 30 ++--
 .../xenstore_client.c |  0
 .../xenstore_control.c|  0
 36 files changed, 110 insertions(+), 81 deletions(-)
 create mode 100644 tools/xenstored/Makefile
 rename tools/{xenstore => xenstored}/Makefile.common (50%)
 rename tools/{xenstore => xenstored}/README (100%)
 rename tools/{xenstore/xenstored_control.c => xenstored/control.c} (98%)
 rename tools/{xenstore/xenstored_control.h => xenstored/control.h} (100%)
 rename tools/{xenstore/xenstored_core.c => xenstored/core.c} (99%)
 rename tools/{xenstore/xenstored_core.h => xenstored/core.h} (100%)
 rename tools/{xenstore/xenstored_domain.c => xenstored/domain.c} (99%)
 rename tools/{xenstore/xenstored_domain.h => xenstored/domain.h} (100%)
 rename tools/{xenstore => xenstored}/hashtable.c (100%)
 rename tools/{xenstore => xenstored}/hashtable.h (100%)
 rename tools/{xenstore => xenstored}/list.h (100%)
 rename tools/{xenstore/xenstored_lu.c => xenstored/lu.c} (98%)
 rename tools/{xenstore/xenstored_lu.h => xenstored/lu.h} (100%)
 rename tools/{xenstore/xenstored_lu_daemon.c => xenstored/lu_daemon.c} (97%)
 rename tools/{xenstore/xenstored_lu_minios.c => xenstored/lu_minios.c} (98%)
 rename tools/{xenstore/xenstored_minios.c => xenstored/minios.c} (97%)
 rename tools/{xenstore/xenstored_osdep.h => xenstored/osdep.h} (100%)
 rename tools/{xenstore/xenstored_posix.c => xenstored/posix.c} (98%)
 rename tools/{xenstore => xenstored}/talloc.c (100%)
 rename tools/{xenstore => xenstored}/talloc.h (100%)
 rename tools/{xenstore => xenstored}/talloc_guide.txt (100%)
 rename tools/{xenstore/xenstored_transaction.c => xenstored/transaction.c} 
(99%)
 rename tools/{xenstore/xenstored_transaction.h => xenstored/transaction.h} 
(98%)
 rename tools/{xenstore => xenstored}/utils.c (100%)
 rename tools/{xenstore => xenstored}/utils.h (100%)
 rename tools/{xenstore/xenstored_watch.c => xenstored/watch.c} (98%)
 rename tools/{xenstore/xenstored_watch.h => xenstored/watch.h} (98%)
 rename tools/{xenstore/include => xenstored}/xenstore_state.h (100%)
 rename tools/{xenstore => xs-clients}/Makefile (74%)
 rename tools/{xenstore => xs-clients}/xenstore_client.c (100%)
 rename tools/{xenstore => xs-clients}/xenstore_control.c (100%)

diff --git a/.gitignore b/.gitignore
index c1b73b0968..c6489c4e70 100644
--- a/.gitignore
+++ 

[PATCH 0/2] xen/x86: Optimize timer_irq_works()

[Julien Grall]

From: Julien Grall 

Hi all,

At the moment timer_irq_works() will always wait 100ms even with
enough ticks elapsed. This is a bit wasteful when most of the HW
should not be buggy.

The admin may also know that their HW is not buggy so they could
decide to skip the full 100ms. Also, looking at Linux changes, it
was pointed out that the timer_irq_works() may always return false
on when using para-virtualized delay. It is not a problem for Xen,
but still it makes sense to provide an option to disable the timer
check.

Patch #1 of the series will add the command line option while patch
#2 will optimize timer_irq_works() for the good case.

Cheers,

Julien Grall (2):
  xen/x86: io_apic: Introduce a command line option to skip timer check
  xen/x86: ioapic: Bail out from timer_irq_works() as soon as possible

 docs/misc/xen-command-line.pandoc |  7 ++
 xen/arch/x86/io_apic.c| 41 ++-
 2 files changed, 37 insertions(+), 11 deletions(-)

-- 
2.40.1

[PATCH 1/2] xen/x86: io_apic: Introduce a command line option to skip timer check

[Julien Grall]

From: Julien Grall 

Currently, Xen will spend ~100ms to check if the timer works. If the
Admin knows their platform have a working timer, then it would be
handy to be able to bypass the check.

Introduce a command line option 'no_timer_check' (the name is
matching the Linux parameter) for this purpose.

Signed-off-by: Julien Grall 
---
 docs/misc/xen-command-line.pandoc |  7 +++
 xen/arch/x86/io_apic.c| 11 +++
 2 files changed, 18 insertions(+)

diff --git a/docs/misc/xen-command-line.pandoc 
b/docs/misc/xen-command-line.pandoc
index 4872b9098e83..1f9d3106383f 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1896,6 +1896,13 @@ This option is ignored in **pv-shim** mode.
 ### nr_irqs (x86)
 > `= `
 
+### no_timer_works (x86)
+> `=`
+
+> Default: `true`
+
+Disables the code which tests for broken timer IRQ sources.
+
 ### irq-max-guests (x86)
 > `= `
 
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index b3afef8933d7..4875bb97003f 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -57,6 +57,14 @@ bool __initdata ioapic_ack_forced;
 int __read_mostly nr_ioapic_entries[MAX_IO_APICS];
 int __read_mostly nr_ioapics;
 
+/*
+ * The logic to check if the timer is working is expensive. So allow
+ * the admin to bypass it if they know their platform doesn't have
+ * a buggy timer.
+ */
+static bool __initdata no_timer_check;
+boolean_param("no_timer_check", no_timer_check);
+
 /*
  * Rough estimation of how many shared IRQs there are, can
  * be changed anytime.
@@ -1502,6 +1510,9 @@ static int __init timer_irq_works(void)
 {
 unsigned long t1, flags;
 
+if ( no_timer_check )
+return 1;
+
 t1 = ACCESS_ONCE(pit0_ticks);
 
 local_save_flags(flags);
-- 
2.40.1

[PATCH 2/2] xen/x86: ioapic: Bail out from timer_irq_works() as soon as possible

[Julien Grall]

From: Julien Grall 

Currently timer_irq_works() will wait the full 100ms before checking
that pit0_ticks has been incremented at least 4 times.

However, the bulk of the BIOS/platform should not have a buggy timer.
So waiting for the full 100ms is a bit harsh.

Rework the logic to only wait until 100ms passed or we saw more than
4 ticks. So now, in the good case, this will reduce the wait time
to ~50ms.

Signed-off-by: Julien Grall 
---
 xen/arch/x86/io_apic.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 4875bb97003f..0bd774962a68 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1509,6 +1509,8 @@ static void __init setup_ioapic_ids_from_mpc(void)
 static int __init timer_irq_works(void)
 {
 unsigned long t1, flags;
+/* Wait for maximum 10 ticks */
+unsigned long msec = (10 * 1000) / HZ;
 
 if ( no_timer_check )
 return 1;
@@ -1517,19 +1519,25 @@ static int __init timer_irq_works(void)
 
 local_save_flags(flags);
 local_irq_enable();
-/* Let ten ticks pass... */
-mdelay((10 * 1000) / HZ);
-local_irq_restore(flags);
 
-/*
- * Expect a few ticks at least, to be sure some possible
- * glue logic does not lock up after one or two first
- * ticks in a non-ExtINT mode.  Also the local APIC
- * might have cached one ExtINT interrupt.  Finally, at
- * least one tick may be lost due to delays.
- */
-if ( (ACCESS_ONCE(pit0_ticks) - t1) > 4 )
+while ( msec-- )
+{
+mdelay(1);
+/*
+ * Expect a few ticks at least, to be sure some possible
+ * glue logic does not lock up after one or two first
+ * ticks in a non-ExtINT mode.  Also the local APIC
+ * might have cached one ExtINT interrupt.  Finally, at
+ * least one tick may be lost due to delays.
+ */
+if ( (ACCESS_ONCE(pit0_ticks) - t1) <= 4 )
+continue;
+
+local_irq_restore(flags);
 return 1;
+}
+
+local_irq_restore(flags);
 
 return 0;
 }
-- 
2.40.1

Re: [PATCH 0/2] Rombios build fixes

[Andrew Cooper]

On 18/08/2023 2:13 pm, Jan Beulich wrote:
> On 18.08.2023 15:05, Andrew Cooper wrote:
>> On 18/08/2023 1:57 pm, Andrew Cooper wrote:
>>> Andrew Cooper (2):
>>>   rombios: Avoid using K function syntax
>>>   rombiosn: Remove the use of egrep
>>>
>>>  tools/firmware/rombios/32bit/Makefile  |  2 +-
>>>  tools/firmware/rombios/32bit/tcgbios/tcgbios.c | 10 +-
>>>  2 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>>
>>> base-commit: e6cb27f2f20d09dd2ba135fbc341a4dc98656e10
>> Urgh, forgot to write what I meant to write.
>>
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/972116359
>>
>> This gives a clean CI run when ROMBios is explicitly (re)activated.
> On irc you said "more array bounds issues in GET_BDA", yet nothing further
> is being adjusted here in that regard?

So yes, I did end up being confused about those.

They're from the iPXE build, not the RomBIOS build.  They can be seen in
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/4899807239 but
there's clearly no -Werror going on.

I'm going to leave it for now.  The only reasonable fix would be to bump
the version of iPXE and I don't have time to that right now.

~Andrew

Re: [PATCH 0/2] Rombios build fixes

[Jan Beulich]

On 18.08.2023 15:05, Andrew Cooper wrote:
> On 18/08/2023 1:57 pm, Andrew Cooper wrote:
>> Andrew Cooper (2):
>>   rombios: Avoid using K function syntax
>>   rombiosn: Remove the use of egrep
>>
>>  tools/firmware/rombios/32bit/Makefile  |  2 +-
>>  tools/firmware/rombios/32bit/tcgbios/tcgbios.c | 10 +-
>>  2 files changed, 6 insertions(+), 6 deletions(-)
>>
>>
>> base-commit: e6cb27f2f20d09dd2ba135fbc341a4dc98656e10
> 
> Urgh, forgot to write what I meant to write.
> 
> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/972116359
> 
> This gives a clean CI run when ROMBios is explicitly (re)activated.

On irc you said "more array bounds issues in GET_BDA", yet nothing further
is being adjusted here in that regard?

Jan

Re: [PATCH 2/2] rombiosn: Remove the use of egrep

[Jan Beulich]

On 18.08.2023 14:57, Andrew Cooper wrote:
> As Alpine 3.18 container notes:
> 
>   egrep: warning: egrep is obsolescent; using grep -E
> 
> Adjust it.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 

Re: [PATCH 1/2] rombios: Avoid using K function syntax

[Jan Beulich]

On 18.08.2023 14:57, Andrew Cooper wrote:
> The declarations for these functions in 32bitprotos.h are already Ansi
> compatible.  Update the definitions to match.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 

Re: [PATCH 0/2] Rombios build fixes

[Andrew Cooper]

On 18/08/2023 1:57 pm, Andrew Cooper wrote:
> Andrew Cooper (2):
>   rombios: Avoid using K function syntax
>   rombiosn: Remove the use of egrep
>
>  tools/firmware/rombios/32bit/Makefile  |  2 +-
>  tools/firmware/rombios/32bit/tcgbios/tcgbios.c | 10 +-
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
>
> base-commit: e6cb27f2f20d09dd2ba135fbc341a4dc98656e10

Urgh, forgot to write what I meant to write.

https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/972116359

This gives a clean CI run when ROMBios is explicitly (re)activated.

~Andrew

[PATCH 1/2] rombios: Avoid using K function syntax

[Andrew Cooper]

The declarations for these functions in 32bitprotos.h are already Ansi
compatible.  Update the definitions to match.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
---
 tools/firmware/rombios/32bit/tcgbios/tcgbios.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/rombios/32bit/tcgbios/tcgbios.c 
b/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
index fa22c4460aac..ad0eac0d20c2 100644
--- a/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
+++ b/tools/firmware/rombios/32bit/tcgbios/tcgbios.c
@@ -595,7 +595,7 @@ static void tcpa_add_measurement(uint32_t pcrIndex,
 /*
  * Add measurement to log about call of int 19h
  */
-void tcpa_calling_int19h()
+void tcpa_calling_int19h(void)
 {
tcpa_add_measurement(4, EV_ACTION, 0);
 }
@@ -603,7 +603,7 @@ void tcpa_calling_int19h()
 /*
  * Add measurement to log about retuning from int 19h
  */
-void tcpa_returned_int19h()
+void tcpa_returned_int19h(void)
 {
tcpa_add_measurement(4, EV_ACTION, 1);
 }
@@ -611,7 +611,7 @@ void tcpa_returned_int19h()
 /*
  * Add event separators for PCRs 0 to 7; specs 8.2.3
  */
-void tcpa_add_event_separators()
+void tcpa_add_event_separators(void)
 {
uint32_t pcrIndex = 0;
while (pcrIndex <= 7) {
@@ -624,7 +624,7 @@ void tcpa_add_event_separators()
 /*
  * Add a wake event to the log
  */
-void tcpa_wake_event()
+void tcpa_wake_event(void)
 {
tcpa_add_measurement_to_log(6,
EV_ACTION,
@@ -659,7 +659,7 @@ void tcpa_add_bootdevice(uint32_t bootcd, uint32_t bootdrv)
  * Add measurement to the log about option rom scan
  * 10.4.3 : action 14
  */
-void tcpa_start_option_rom_scan()
+void tcpa_start_option_rom_scan(void)
 {
tcpa_add_measurement(2, EV_ACTION, 14);
 }
-- 
2.30.2

[PATCH 2/2] rombiosn: Remove the use of egrep

[Andrew Cooper]

As Alpine 3.18 container notes:

  egrep: warning: egrep is obsolescent; using grep -E

Adjust it.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
---
 tools/firmware/rombios/32bit/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware/rombios/32bit/Makefile 
b/tools/firmware/rombios/32bit/Makefile
index c058c715514c..50d45647c23d 100644
--- a/tools/firmware/rombios/32bit/Makefile
+++ b/tools/firmware/rombios/32bit/Makefile
@@ -26,7 +26,7 @@ $(TARGET): 32bitbios_all.o
 32bitbios_all.o: 32bitbios.o tcgbios/tcgbiosext.o util.o pmm.o
$(LD) $(LDFLAGS_DIRECT) -s -r $^ -o 32bitbios_all.o
@nm 32bitbios_all.o |\
- egrep '^ +U ' >/dev/null && {  \
+ grep -E '^ +U ' >/dev/null && {\
echo "There are undefined symbols in the BIOS:"; \
nm -u 32bitbios_all.o;   \
exit 11; \
-- 
2.30.2

[PATCH 0/2] Rombios build fixes

[Andrew Cooper]

Andrew Cooper (2):
  rombios: Avoid using K function syntax
  rombiosn: Remove the use of egrep

 tools/firmware/rombios/32bit/Makefile  |  2 +-
 tools/firmware/rombios/32bit/tcgbios/tcgbios.c | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)


base-commit: e6cb27f2f20d09dd2ba135fbc341a4dc98656e10
-- 
2.30.2

Re: [XEN PATCH 07/11] xen: address MISRA C:2012 Rule 2.1

[Nicola Vetrini]

Jan has a point: I think we should record all our deviations and unique
ways to interpret the rules under docs/misra. And the Eclair
configuration should reflect that. It is not a good idea to only keep
the information in the Eclair config because, even if it is now 
upstream

in xen.git, it is still a tool-specific configuration file -- it is not
a proper document. MISRA C and its interpretation is important enough
that we should have a plain English document to cover it (which now is
docs/misra/rules.rst).

Nicola, I volunteer to send patches to make any necessary updates to
docs/misra/rules.rst and other docs. Please send out to me a list of
deviations/configurations and I'll make sure to reflect them under
docs/misra so that they are in sync.

Cheers,

Stefano


Sure, I'll let you know when I have it.
Thanks,

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [PATCH v4 00/19] tools/xenstore: drop TDB

[Julien Grall]

Hi Juergen,

On 14/08/2023 08:46, Juergen Gross wrote:

Juergen Gross (19):
   tools/xenstore: make hashtable key parameter const
   tools/xenstore: let hashtable_add() fail in case of existing entry
   tools/xenstore: add hashtable_replace() function
   tools/xenstore: drop use of tdb
   tools/xenstore: remove tdb code
   tools/xenstore: let db_delete() return void
   tools/xenstore: change talloc_free() to take a const pointer
   tools/xenstore: move copying of node data out of db_fetch()
   tools/xenstore: rework struct xs_tdb_record_hdr
   tools/xenstore: don't use struct node_perms in struct node
   tools/xenstore: use struct node_hdr in struct node
   tools/xenstore: alloc new memory in domain_adjust_node_perms()
   tools/xenstore: introduce read_node_const()
   tools/xenstore: merge get_spec_node() into get_node_canonicalized()
   tools/xenstore: merge is_valid_nodename() into canonicalize()
   tools/xenstore: rework get_node()
   tools/xenstore: introduce get_node_const()
   tools/config: add XEN_RUN_STORED to config.h


I have committed up to this patch.

Cheers,


--
Julien Grall

Re: [PATCH v4 19/19] tools/xenstore: move xenstored sources into dedicated directory

[Juergen Gross]

On 18.08.23 14:42, Julien Grall wrote:

Hi Juergen,

On 18/08/2023 13:14, Juergen Gross wrote:

On 18.08.23 13:22, Julien Grall wrote:

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

In tools/xenstore there are living xenstored and xenstore clients.
They are no longer sharing anything apart from the "xenstore" in their
names.

Move the xenstored sources into a new directory tools/xenstored while
dropping the "xenstored_" prefix from their names. This will make it
clearer that xenstore clients and xenstored are independent from each
other.


In term of naming, I would prefer if we follow what was done for the console. 
I.e:


xenstore/client: All the clients
xenstore/daemon: C Xenstored

This would avoid the one character difference between the two directories.


Yes, that would be the alternative (apart from renaming the xenstore directory
to something different, e.g. xs-clients).


xs-clients would be OK. I guess you didn't suggest xenstore-clients because it 
is too long?


I was more thinking about path name completion when typing. Using xs-clients
would allow to use the  after the second character already. :-)





The reason I was leaning towards my solution was that the clients are meant to
be used with any xenstored implementation. This wouldn't be reflected by using
a common tools/xenstore parent directory for the clients and C xenstored.


You have a point. I was also trying to avoid to have too many directoy in tools. 
But we already have 'qemu-trad' and 'qemu-upstream'...




In the end I could live with your proposal, too.


My main concern with your proposal was the one character difference in the name. 
xenstored and xs-clients/xenstore-clients would work for me.


Okay, thanks.

With above reasoning I'm leaning towards xs-clients.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 19/19] tools/xenstore: move xenstored sources into dedicated directory

[Julien Grall]

Hi Juergen,

On 18/08/2023 13:14, Juergen Gross wrote:

On 18.08.23 13:22, Julien Grall wrote:

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

In tools/xenstore there are living xenstored and xenstore clients.
They are no longer sharing anything apart from the "xenstore" in their
names.

Move the xenstored sources into a new directory tools/xenstored while
dropping the "xenstored_" prefix from their names. This will make it
clearer that xenstore clients and xenstored are independent from each
other.


In term of naming, I would prefer if we follow what was done for the 
console. I.e:


xenstore/client: All the clients
xenstore/daemon: C Xenstored

This would avoid the one character difference between the two 
directories.


Yes, that would be the alternative (apart from renaming the xenstore 
directory

to something different, e.g. xs-clients).


xs-clients would be OK. I guess you didn't suggest xenstore-clients 
because it is too long?




The reason I was leaning towards my solution was that the clients are 
meant to
be used with any xenstored implementation. This wouldn't be reflected by 
using

a common tools/xenstore parent directory for the clients and C xenstored.


You have a point. I was also trying to avoid to have too many directoy 
in tools. But we already have 'qemu-trad' and 'qemu-upstream'...




In the end I could live with your proposal, too.


My main concern with your proposal was the one character difference in 
the name. xenstored and xs-clients/xenstore-clients would work for me.


Cheers,

--
Julien Grall

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  e6cb27f2f20d09dd2ba135fbc341a4dc98656e10
baseline version:
 xen  38ba0466a1e262edd031500d24919fbf4e48c794

Last test of basis   182370  2023-08-17 15:03:44 Z0 days
Testing same since   182379  2023-08-18 09:00:26 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jens Wiklander 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   38ba0466a1..e6cb27f2f2  e6cb27f2f20d09dd2ba135fbc341a4dc98656e10 -> smoke

Re: Community Manager update - August 2023

[Bertrand Marquis]

Hi Kelly,

> On 18 Aug 2023, at 12:55, Kelly Choi  wrote:
>
> Hi everyone! :)
>
> I hope you're all well.
>
> If we haven't met before, I'd like to introduce myself. I'm Kelly, the 
> Community Manager for The Xen Project. My role is to support everyone and 
> make sure the project is healthy and thriving.
>
> The latest update below requires your attention:
>
> • We will be moving IRC channels fully to Matrix in September 2023. Once 
> the channels have been created, further information will be shared.
> • New Mission Statement, goals, and purpose is attached to this email and 
> will be shared publicly.
> Should anyone have any concerns or feedback, please let me know

In embedded and automotive in particular one keyword that would be interesting 
to have is "Safety".

We could add it in the mission statement and in the embedded technology goals:
- The project aims to enable innovation, scalability, safety and security in 
virtualization solutions.
- Transform embedded and automotive sectors with mature, safe and secure 
solutions.

What do other think ?

Regards
Bertrand


>
> Many thanks,
> Kelly Choi
>
> Open Source Community Manager, XenServer
> Cloud Software Group



New mission statement_.pdf
Description: New mission statement_.pdf

Re: [PATCH v4 19/19] tools/xenstore: move xenstored sources into dedicated directory

[Juergen Gross]

On 18.08.23 13:22, Julien Grall wrote:

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

In tools/xenstore there are living xenstored and xenstore clients.
They are no longer sharing anything apart from the "xenstore" in their
names.

Move the xenstored sources into a new directory tools/xenstored while
dropping the "xenstored_" prefix from their names. This will make it
clearer that xenstore clients and xenstored are independent from each
other.


In term of naming, I would prefer if we follow what was done for the console. 
I.e:

xenstore/client: All the clients
xenstore/daemon: C Xenstored

This would avoid the one character difference between the two directories.


Yes, that would be the alternative (apart from renaming the xenstore directory
to something different, e.g. xs-clients).

The reason I was leaning towards my solution was that the clients are meant to
be used with any xenstored implementation. This wouldn't be reflected by using
a common tools/xenstore parent directory for the clients and C xenstored.

In the end I could live with your proposal, too.



What do the other thinks?



Signed-off-by: Juergen Gross 
---
After the large overhaul of xenstored I think such a reorg would make
sense to go into the same Xen version. Delaying it until the next
version would make potential backports for 4.18 harder.


+1.


Thanks,


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 19/19] tools/xenstore: move xenstored sources into dedicated directory

[Julien Grall]

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

In tools/xenstore there are living xenstored and xenstore clients.
They are no longer sharing anything apart from the "xenstore" in their
names.

Move the xenstored sources into a new directory tools/xenstored while
dropping the "xenstored_" prefix from their names. This will make it
clearer that xenstore clients and xenstored are independent from each
other.


In term of naming, I would prefer if we follow what was done for the 
console. I.e:


xenstore/client: All the clients
xenstore/daemon: C Xenstored

This would avoid the one character difference between the two directories.

What do the other thinks?



Signed-off-by: Juergen Gross 
---
After the large overhaul of xenstored I think such a reorg would make
sense to go into the same Xen version. Delaying it until the next
version would make potential backports for 4.18 harder.


+1.

Cheers,

--
Julien Grall

Re: [PATCH v4 17/19] tools/xenstore: introduce get_node_const()

[Julien Grall]

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

Add a variant of get_node() returning a const struct node pointer.

Note that all callers of this new variant don't supply a pointer where
to store the canonical node name, while all callers needing a non-const
node do supply this pointer. This results in an asymmetric
simplification of the two variants.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v4 16/19] tools/xenstore: rework get_node()

[Julien Grall]

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

Today get_node_canonicalized() is the only caller of get_node().

In order to prepare introducing a get_node() variant returning a
pointer to const struct node, do the following restructuring:

- move the call of read_node() from get_node() into
   get_node_canonicalized()

- rename get_node() to get_node_chk_perm()

- rename get_node_canonicalized() to get_node()

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v4 15/19] tools/xenstore: merge is_valid_nodename() into canonicalize()

[Julien Grall]

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

Today is_valid_nodename() is always called directly after calling
canonicalize(), with the exception of do_unwatch(), where the call
is missing (which is not correct, but results just in a wrong error
reason being returned).

Merge is_valid_nodename() into canonicalize(). While at it merge
valid_chars() into it, too.


You don't valid_chars() anymore. So the second sentence can be removed.

I can do the change while committing.



Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v7 0/2] xen/riscv: introduce identity mapping

[Oleksii]

Hello Alistair and Bobby,

Could you please review this patch series when you have a moment? Your
insights would be greatly appreciated.

Thanks in advance.

~ Oleksii

On Tue, 2023-08-08 at 18:14 +0300, Oleksii Kurochko wrote:
> The patch series introduces things necessary to implement identity
> mapping:
>   1. Make identity mapping for the entire Xen.
>   2. Enable MMU.
>   3. Jump to the virtual address world
>   4. Remove identity mapping.
> 
> Also current patch series introduces the calculation of physical
> offset before
> MMU is enabled as access to physical offset will be calculated wrong
> after
> MMU will be enabled because access to phys_off variable is PC-
> relative and
> in the case when linker address != load address, it will cause MMU
> fault.
> 
> The reason for this patch series can be found here:
> https://lore.kernel.org/xen-devel/4e336121-fc0c-b007-bf7b-430352563...@citrix.com/
> 
> ---
> Changes in V7:
>  - use srli instruction to be consistent with slli instruction in
> turn_on_mmu()
> ---
> Changes in V6:
>   - Update calc_phys_offset() after rebase.
>   - Refactor turn_on_mmu() and a way how an argument of turn_on_mmu()
> is
>     calculated.
> ---
> Changes in V5:
> - update the algo of identity mapping removing.
> - introduce IDENT_AREA_SIZE.
> - introduce turn_on_mmu() function to enable and switch from
> 1:1 mapping.
> - fix typo in PGTBL_INITIAL_COUNT define.
> - update the comment above PGTBL_INITIAL_COUNT.
> - update prototype of calc_phys_offset(). now it returns
> phys_offset.
> - declare phys_offset as static.
> - save returned value of calc_phys_offset to register s2.
> ---
> Changes in V4:
>   - drop patch  [PATCH v3 1/3] xen/riscv: add SPDX tag to config.h as
> it was
>     merged to staging
>   - remove definition of ARRAY_SIZE and ROUNDUP as  was
> introduced where these macros are located now.
> - update definition of PGTBL_INITIAL_COUNT
> - update the commit message for patch 'xen/riscv: introduce
> identity mapping'
> - update the comments in head.S
>   - update the algo of identity mapping removing 
> ---
> Changes in V3:
>  - Update the patch series message.
>  - The following patches were merged to staging so droped from the
> patch series:
>    * xen/riscv: add .sbss section to .bss
>    * xen/riscv: introduce reset_stack() function
>    * xen/riscv: move extern of cpu0_boot_stack to header
>    * xen/riscv: add SPDX tags
>  - move save/restore of a0/a1 registers from patch 4 to patch 2 (
> numbers are
>    from the previous patch series version )
>  - add SPDX tag in config.h
>  - update definition of PGTBL_INITIAL_COUNT taking into account
> identity mapping.
>  - refactor remove_identity_mapping() function.
>  - add explanatory comments in xen.lds.S and mm.c.
> ---
> Changes in V2:
>  - update the patch series message.
>  - drop patches from the previous version of the patch series:
>    * xen/riscv: add __ASSEMBLY__ guards". ( merged )
>    * xen/riscv: make sure that identity mapping isn't bigger then
> page size
>  ( entire Xen is 1:1 mapped so there is no need for the checks
> from the patch )
>  - add .sbss.* and put it befor .bss* .
>  - move out reset_stack() to .text section.
>  - add '__ro_after_init' for phys_offset variable.
>  - add '__init' for calc_phys_offset().
>  - declaring variable phys_off as non static as it will be used in
> head.S.
>  - update definition of PGTBL_INITIAL_COUNT and the comment above.
>  - code style fixes.
>  - remove id_addrs array becase entire Xen is mapped.
>  - reverse condition for cycle inside remove_identity_mapping().
>  - fix page table walk in remove_identity_mapping().
>  - save hart_id and dtb_addr before call MMU related C functions
>  - use phys_offset variable instead of doing calcultations to get
> phys offset
>    in head.S file. ( it can be easily done as entire Xen is 1:1
> mapped now )
>  - declare enable_muu() as __init.
>  - Update SPDX tags.
>  - Add Review-By/Suggested-By for some patches.
>  - code style fixes.
> 
> Oleksii Kurochko (2):
>   xen/riscv: introduce function for physical offset calculation
>   xen/riscv: introduce identity mapping
> 
>  xen/arch/riscv/include/asm/acpi.h   |   6 ++
>  xen/arch/riscv/include/asm/config.h |   2 +
>  xen/arch/riscv/include/asm/mm.h |   7 +-
>  xen/arch/riscv/mm.c | 109 +-
> --
>  xen/arch/riscv/riscv64/head.S   |  44 +++
>  xen/arch/riscv/setup.c  |  14 +---
>  xen/arch/riscv/xen.lds.S    |  11 +++
>  7 files changed, 136 insertions(+), 57 deletions(-)
>  create mode 100644 xen/arch/riscv/include/asm/acpi.h
> 

Re: [PATCH v4 14/19] tools/xenstore: merge get_spec_node() into get_node_canonicalized()

[Julien Grall]

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

Add a "allow_special" parameter to get_node_canonicalized() allowing
to merge get_spec_node() into get_node_canonicalized().

Add the same parameter to is_valid_nodename(), as this will simplify
check_watch_path().

This is done in preparation to introducing a get_node() variant
returning a pointer to const struct node.

Note that this will change how special node names are going to be
validated, as now the normal restrictions for node names will be
applied:

- they can't end with "/"
- they can't contain "//"
- they can't contain characters other than the ones allowed for normal
   nodes
- the length of the node name is restricted by the max path length
   quota

For defined special node names this isn't any real restriction, though.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v2 1/4] block: rename blk_io_plug_call() API to defer_call()

[Paul Durrant]

On 17/08/2023 16:58, Stefan Hajnoczi wrote:

Prepare to move the blk_io_plug_call() API out of the block layer so
that other subsystems call use this deferred call mechanism. Rename it
to defer_call() but leave the code in block/plug.c.

The next commit will move the code out of the block layer.

Suggested-by: Ilya Maximets 
Signed-off-by: Stefan Hajnoczi 
---
  include/sysemu/block-backend-io.h |   6 +-
  block/blkio.c |   8 +--
  block/io_uring.c  |   4 +-
  block/linux-aio.c |   4 +-
  block/nvme.c  |   4 +-
  block/plug.c  | 109 +++---
  hw/block/dataplane/xen-block.c|  10 +--
  hw/block/virtio-blk.c |   4 +-
  hw/scsi/virtio-scsi.c |   6 +-
  9 files changed, 76 insertions(+), 79 deletions(-)



Reviewed-by: Paul Durrant 

Re: [PATCH v4 13/19] tools/xenstore: introduce read_node_const()

[Julien Grall]

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

Introduce a read_node() variant returning a pointer to const struct
node, which doesn't do a copy of the node data after retrieval from
the data base.

Call this variant where appropriate.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v4 12/19]tools/xenstore: alloc new memory in domain_adjust_node_perms()

[Julien Grall]

Hi Juergen,

On 14/08/2023 08:47, Juergen Gross wrote:

In order to avoid modifying the node data in the data base in case a
domain is gone, let domain_adjust_node_perms() allocate new memory for
the permissions in case they need to be modified. As this should
happen only in very rare cases, it is fine to do this even when having
copied the node data already.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v4 11/19] tools/xenstore: use struct node_hdr in struct node

[Julien Grall]

Hi Juergen,

On 14/08/2023 08:46, Juergen Gross wrote:

Replace some individual fields in struct node with struct node_hdr.

This allows to add a helper for calculating the accounted memory size
of a node.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Community Manager update - August 2023

[Kelly Choi]

Hi everyone! :)

I hope you're all well.

If we haven't met before, I'd like to introduce myself. I'm Kelly, the
Community Manager for The Xen Project. My role is to support everyone and
make sure the project is healthy and thriving.

*The latest update below requires your attention:*


   - *We will be moving IRC channels fully to Matrix in September 2023.
   Once the channels have been created, further information will be shared. *
   - *New Mission Statement, goals, and purpose is attached to this email
   and will be shared publicly.*

*Should anyone have any concerns or feedback, please let me know*

Many thanks,
Kelly Choi

Open Source Community Manager, XenServer
Cloud Software Group


New mission statement_.pdf
Description: Adobe PDF document

Re: [PATCH 1/2] code-of-conduct.rst: Remove Ian Jackson as a team member

[George Dunlap]

On Fri, Aug 18, 2023 at 11:45 AM Andrew Cooper 
wrote:

> On 18/08/2023 11:33 am, George Dunlap wrote:
>
>
> On Fri, Aug 18, 2023 at 11:32 AM George Dunlap 
> wrote:
>
>> Ian Jackson is no longer involved with the Xen Project.
>>
>> Signed-off-by: George Dunlap 
>>
>
> NB that I don't consider these changes as needing a full vote; I'll check
> them in on Monday unless someone wants to argue otherwise.
>
>
> FWIW, Acked-by: Andrew Cooper 
> 
>

Thanks.


> I don't see any reason to delay these at all.  No amount of community
> voting is going to get Ian back, or change the email address your employer
> has given you...
>

Bitter experience has taught me that just because I can't *think* of any
objection doesn't mean there aren't any.  My low estimation of probability
is why I'm only giving one business day to object. :-)

 -George

Re: [PATCH 1/2] code-of-conduct.rst: Remove Ian Jackson as a team member

[Andrew Cooper]

On 18/08/2023 11:33 am, George Dunlap wrote:
>
> On Fri, Aug 18, 2023 at 11:32 AM George Dunlap
>  wrote:
>
> Ian Jackson is no longer involved with the Xen Project.
>
> Signed-off-by: George Dunlap 
>
>
> NB that I don't consider these changes as needing a full vote; I'll
> check them in on Monday unless someone wants to argue otherwise.

FWIW, Acked-by: Andrew Cooper 

I don't see any reason to delay these at all.  No amount of community
voting is going to get Ian back, or change the email address your
employer has given you...

~Andrew

Re: [PATCH 1/2] code-of-conduct.rst: Remove Ian Jackson as a team member

[George Dunlap]

On Fri, Aug 18, 2023 at 11:32 AM George Dunlap 
wrote:

> Ian Jackson is no longer involved with the Xen Project.
>
> Signed-off-by: George Dunlap 
>

NB that I don't consider these changes as needing a full vote; I'll check
them in on Monday unless someone wants to argue otherwise.

Thanks,
 -George

[PATCH 1/2] code-of-conduct.rst: Remove Ian Jackson as a team member

[George Dunlap]

Ian Jackson is no longer involved with the Xen Project.

Signed-off-by: George Dunlap 
---
 source/code-of-conduct.rst | 1 -
 1 file changed, 1 deletion(-)

diff --git a/source/code-of-conduct.rst b/source/code-of-conduct.rst
index 963d605..c6003bb 100644
--- a/source/code-of-conduct.rst
+++ b/source/code-of-conduct.rst
@@ -80,7 +80,6 @@ Conduct Team members are project leadership team members from 
any
 sub-project. The current list of Conduct Team members is:
 
 * George Dunlap 
-* Ian Jackson 
 * Stefano Stabellini 
 
 Conduct Team members are changed by proposing a change to this document,
-- 
2.40.0

[PATCH 2/2] code-of-conduct.rst: Update George Dunlap's email address

[George Dunlap]

Signed-off-by: George Dunlap 
---
 source/code-of-conduct.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/code-of-conduct.rst b/source/code-of-conduct.rst
index c6003bb..6ef11c8 100644
--- a/source/code-of-conduct.rst
+++ b/source/code-of-conduct.rst
@@ -79,7 +79,7 @@ Conduct Team members
 Conduct Team members are project leadership team members from any
 sub-project. The current list of Conduct Team members is:
 
-* George Dunlap 
+* George Dunlap 
 * Stefano Stabellini 
 
 Conduct Team members are changed by proposing a change to this document,
-- 
2.40.0

Re: [PATCH] rombios: Work around GCC issue 99578

[Andrew Cooper]

On 18/08/2023 11:09 am, Jan Beulich wrote:
> On 18.08.2023 11:44, Andrew Cooper wrote:
>> On 18/08/2023 7:50 am, Jan Beulich wrote:
>>> On 17.08.2023 22:45, Andrew Cooper wrote:
 GCC 12 objects to pointers derived from a constant:

   util.c: In function 'find_rsdp':
   util.c:429:16: error: array subscript 0 is outside array bounds of 
 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
 429 | ebda_seg = *(uint16_t *)ADDR_FROM_SEG_OFF(0x40, 0xe);
   cc1: all warnings being treated as errors

>>> Yet supposedly the bug was fixed in 12.1 (and the fix also backported to
>>> 11.3). Did you spot anything in ADDR_FROM_SEG_OFF() and this particular
>>> use of it that is different from the patterns mentioned in that bug?
>> $ gcc --version
>> gcc (GCC) 12.2.1 20221121
>>
>> At a guess, only a partial fix was backported into 12.1.  AIUI, it was
>> an area of logic which had already seen significant development in 13
>> before the behaviour was reverted.
> Hmm, for 12 I didn't think there was any backporting involved.
>
>> The only thing interesting about ADDR_FROM_SEG_OFF() is the constant
>> folding required for the expression to become *(uint16_t *)0x40e, which
>> (I suspect) is why it compiles fine at -Og but fails at -O2.
> Oh, the relevant aspect may be that is is below 4k (which I think is
> their heuristic offset to guess "almost NULL" dereferencing).

Ah yes, I remember that aspect now you've pointed it out.

Yeah, that's probably it.

 This is a GCC bug, but work around it rather than turning array-bounds
 checking off generally.
>>> I certainly agree here. I guess it's not worth trying to restrict the
>>> workaround for rombios (I will want to try doing so in the hypervisor).
>> Can I translate this to an ack?
> You can now:
> Acked-by: Jan Beulich 

Thanks.

Re: [PATCH] rombios: Work around GCC issue 99578

[Jan Beulich]

On 18.08.2023 11:44, Andrew Cooper wrote:
> On 18/08/2023 7:50 am, Jan Beulich wrote:
>> On 17.08.2023 22:45, Andrew Cooper wrote:
>>> GCC 12 objects to pointers derived from a constant:
>>>
>>>   util.c: In function 'find_rsdp':
>>>   util.c:429:16: error: array subscript 0 is outside array bounds of 
>>> 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
>>> 429 | ebda_seg = *(uint16_t *)ADDR_FROM_SEG_OFF(0x40, 0xe);
>>>   cc1: all warnings being treated as errors
>>>
>> Yet supposedly the bug was fixed in 12.1 (and the fix also backported to
>> 11.3). Did you spot anything in ADDR_FROM_SEG_OFF() and this particular
>> use of it that is different from the patterns mentioned in that bug?
> 
> $ gcc --version
> gcc (GCC) 12.2.1 20221121
> 
> At a guess, only a partial fix was backported into 12.1.  AIUI, it was
> an area of logic which had already seen significant development in 13
> before the behaviour was reverted.

Hmm, for 12 I didn't think there was any backporting involved.

> The only thing interesting about ADDR_FROM_SEG_OFF() is the constant
> folding required for the expression to become *(uint16_t *)0x40e, which
> (I suspect) is why it compiles fine at -Og but fails at -O2.

Oh, the relevant aspect may be that is is below 4k (which I think is
their heuristic offset to guess "almost NULL" dereferencing).

>>> This is a GCC bug, but work around it rather than turning array-bounds
>>> checking off generally.
>> I certainly agree here. I guess it's not worth trying to restrict the
>> workaround for rombios (I will want to try doing so in the hypervisor).
> 
> Can I translate this to an ack?

You can now:
Acked-by: Jan Beulich 

I wanted to at least have a vague idea of why this fails with gcc12,
when I thought it shouldn't. In light of the 4k aspect maybe the bug
reference wants adjusting / dropping.

Jan

Re: [PATCH] rombios: Work around GCC issue 99578

[Andrew Cooper]

On 18/08/2023 7:50 am, Jan Beulich wrote:
> On 17.08.2023 22:45, Andrew Cooper wrote:
>> GCC 12 objects to pointers derived from a constant:
>>
>>   util.c: In function 'find_rsdp':
>>   util.c:429:16: error: array subscript 0 is outside array bounds of 
>> 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
>> 429 | ebda_seg = *(uint16_t *)ADDR_FROM_SEG_OFF(0x40, 0xe);
>>   cc1: all warnings being treated as errors
>>
> Yet supposedly the bug was fixed in 12.1 (and the fix also backported to
> 11.3). Did you spot anything in ADDR_FROM_SEG_OFF() and this particular
> use of it that is different from the patterns mentioned in that bug?

$ gcc --version
gcc (GCC) 12.2.1 20221121

At a guess, only a partial fix was backported into 12.1.  AIUI, it was
an area of logic which had already seen significant development in 13
before the behaviour was reverted.

The only thing interesting about ADDR_FROM_SEG_OFF() is the constant
folding required for the expression to become *(uint16_t *)0x40e, which
(I suspect) is why it compiles fine at -Og but fails at -O2.

>> This is a GCC bug, but work around it rather than turning array-bounds
>> checking off generally.
> I certainly agree here. I guess it's not worth trying to restrict the
> workaround for rombios (I will want to try doing so in the hypervisor).

Can I translate this to an ack?

~Andrew

Re: [PATCH v1 02/57] xen/riscv: add public arch-riscv.h

[Oleksii]

On Thu, 2023-08-17 at 17:00 +0200, Jan Beulich wrote:
> On 16.08.2023 12:19, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/public/arch-riscv.h
> > @@ -0,0 +1,90 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/*
> > + * Guest OS interface to RISC-V Xen.
> > + * Initially based on the ARM implementation.
> > + */
> > +
> > +#ifndef __XEN_PUBLIC_ARCH_RISCV_H__
> > +#define __XEN_PUBLIC_ARCH_RISCV_H__
> > +
> > +#define  int64_aligned_t  int64_t __attribute__((__aligned__(8)))
> > +#define uint64_aligned_t uint64_t __attribute__((__aligned__(8)))
> > +
> > +#ifndef __ASSEMBLY__
> > +#define ___DEFINE_XEN_GUEST_HANDLE(name, type)  \
> > +    typedef union { type *p; unsigned long q; } \
> > +    __guest_handle_ ## name;    \
> > +    typedef union { type *p; uint64_aligned_t q; }  \
> > +    __guest_handle_64_ ## name
> > +
> > +/*
> > + * XEN_GUEST_HANDLE represents a guest pointer, when passed as a
> > field
> > + * in a struct in memory. On RISCV is always 8 bytes sizes and 8
> > bytes
> > + * aligned.
> > + * XEN_GUEST_HANDLE_PARAM represents a guest pointer, when passed
> > as an
> > + * hypercall argument. It is 4 bytes on aarch32 and 8 bytes on
> > aarch64.
> 
> Nit: aarch{32,64}?
Thanks. It should be updated to RISC-V.
> 
> > + */
> > +#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
> > +    ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
> > +    ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> > +#define DEFINE_XEN_GUEST_HANDLE(name)  
> > __DEFINE_XEN_GUEST_HANDLE(name, name)
> > +#define __XEN_GUEST_HANDLE(name)    __guest_handle_64_ ## name
> > +#define XEN_GUEST_HANDLE(name)  __XEN_GUEST_HANDLE(name)
> > +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
> > +#define set_xen_guest_handle_raw(hnd, val)  \
> > +    do {    \
> > +    typeof(&(hnd)) _sxghr_tmp = &(hnd); \
> > +    _sxghr_tmp->q = 0;  \
> > +    _sxghr_tmp->p = (val);  \
> > +    } while ( 0 )
> 
> While I realize you simply took this from Arm, in new code I think it
> would be helpful to avoid name space violations from the beginning.
> Hence no leading underscore please for macro local variables.
> Trailing
> underscores is what we mean to use instead.
> 
> It's also not really valid to use a gcc extension here, but I guess
> that's hard to avoid.
Thank you. Understood. I'll make the update.
> 
> > +#define set_xen_guest_handle(hnd, val)
> > set_xen_guest_handle_raw(hnd, val)
> > +
> > +typedef uint64_t xen_pfn_t;
> > +#define PRI_xen_pfn PRIx64
> > +#define PRIu_xen_pfn PRIu64
> > +
> > +typedef uint64_t xen_ulong_t;
> > +#define PRI_xen_ulong PRIx64
> > +
> > +#if defined(__XEN__) || defined(__XEN_TOOLS__)
> > +
> > +struct vcpu_guest_context {
> > +};
> > +typedef struct vcpu_guest_context vcpu_guest_context_t;
> > +DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
> > +
> > +struct xen_arch_domainconfig {
> > +};
> 
> While these are okay to remain empty, ...
> 
> > +#endif
> > +
> > +struct arch_vcpu_info {
> > +};
> > +typedef struct arch_vcpu_info arch_vcpu_info_t;
> > +
> > +struct arch_shared_info {
> > +};
> > +typedef struct arch_shared_info arch_shared_info_t;
> 
> ... these two need to gain a "todo" marker so that we won't forget
> to at least add a placeholder entry if no real ones surface.
I'll make the update. Thanks.

> 
> > +/* Maximum number of virtual CPUs in legacy multi-processor
> > guests. */
> > +/* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
> 
> Nit: Style (missing full stop). And quite likely the two comments
> could
> be joined to a single one.
I'll take it into account.
> 
> > +#define XEN_LEGACY_MAX_VCPUS 1
> > +
> > +#endif /* __ASSEMBLY__ */
> > +
> > +#ifndef __ASSEMBLY__
> 
> Why not continue the earlier !__ASSEMBLY__ section?
Sure, we can continue the earlier !__ASSEBLY__ section. I'll update
this part.

~ Oleksii

Re: [PATCH 3/3] xen/public: arch-arm: All PSR_* defines should be unsigned

[Julien Grall]

Hi Jan,

On 18/08/2023 09:14, Jan Beulich wrote:

On 18.08.2023 09:39, Julien Grall wrote:

On 18/08/2023 07:33, Jan Beulich wrote:

As an aside I wonder why they're here: They look like definitions of
processor registers, which aren't under our (Xen's) control.


I agree they are not under Xen's control. However, they are used by the
toolstack and IIRC back then they were not available in any other headers.

Note that they are only available by the tools and the hypervisor (see
#ifdef above).


Yes, I did notice that (or else I would have used stronger wording).


I ask in
part because the presence of such constants may then be taken as
justification to add similar things in new ports. Yet such definitions
shouldn't be put here.


  From my understanding we are using the public headers to provide
macros/defines that are used by both the toolstack and the hypervisor.
If they are not meant to be exposed to the guest, then they will be
protected with "#if defined(__XEN__) || defined(__XEN_TOOLS__)".

I think we are in a similar situation here. So it is not clear where
they should be put if we need to share them between the hypervisor and
the toolstack.


On x86 we simply arrange for certain hypervisor headers to be re-usable
from the toolstack. See in particular arch/x86/include/asm/x86-*.h. And
of course everything under include/xen/lib/x86/, but those are our own
definitions, not ones meant to solely express relevant hw spec aspects.


Even if they are defined by the HW, we still need them to easily create 
some hypercalls field.


If we are planning to have a stable toolstack ABI (as Juergen 
suggested), then I would find a bit odd that onewould need to include 
lib/ (or provide their own header) in order to update the fields.


Anyway, I am not planning to do any re-ordering anytime soon for the 
public. But I would be happy to take part of the discussion if there are 
a general agreement to split further and someone wants to write patches.


Cheers,

--
Julien Grall

Re: [PATCH 3/3] xen/public: arch-arm: All PSR_* defines should be unsigned

[Julien Grall]

Hi Juergen,

On 18/08/2023 09:25, Juergen Gross wrote:

On 18.08.23 10:05, Julien Grall wrote:

Hi,

On 18/08/2023 09:00, Juergen Gross wrote:

On 18.08.23 09:39, Julien Grall wrote:

Hi Jan,

On 18/08/2023 07:33, Jan Beulich wrote:

On 17.08.2023 23:43, Julien Grall wrote:

--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -339,36 +339,36 @@ typedef uint64_t xen_callback_t;
  /* PSR bits (CPSR, SPSR) */
-#define PSR_THUMB   (1<<5)    /* Thumb Mode enable */
-#define PSR_FIQ_MASK    (1<<6)    /* Fast Interrupt mask */
-#define PSR_IRQ_MASK    (1<<7)    /* Interrupt mask */
-#define PSR_ABT_MASK    (1<<8)    /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN  (1<<9)    /* arm32: Big Endian Mode */
-#define PSR_DBG_MASK    (1<<9)    /* arm64: Debug Exception 
mask */

-#define PSR_IT_MASK (0x0600fc00)  /* Thumb If-Then Mask */
-#define PSR_JAZELLE (1<<24)   /* Jazelle Mode */
-#define PSR_Z   (1<<30)   /* Zero condition flag */
+#define PSR_THUMB   (1U <<5)  /* Thumb Mode enable */
+#define PSR_FIQ_MASK    (1U <<6)  /* Fast Interrupt mask */
+#define PSR_IRQ_MASK    (1U <<7)  /* Interrupt mask */
+#define PSR_ABT_MASK    (1U <<8)  /* Asynchronous Abort mask */


Nit: Did you mean to insert blanks also on the rhs of the <<, like 
you ...



+#define PSR_BIG_ENDIAN  (1U << 9) /* arm32: Big Endian Mode */
+#define PSR_DBG_MASK    (1U << 9) /* arm64: Debug Exception 
mask */

+#define PSR_IT_MASK (0x0600fc00U) /* Thumb If-Then Mask */
+#define PSR_JAZELLE (1U << 24)    /* Jazelle Mode */
+#define PSR_Z   (1U << 30)    /* Zero condition flag */


... did everywhere here?


Yes I did. I will update the patch.



As an aside I wonder why they're here: They look like definitions of
processor registers, which aren't under our (Xen's) control.


I agree they are not under Xen's control. However, they are used by 
the toolstack and IIRC back then they were not available in any 
other headers.


Note that they are only available by the tools and the hypervisor 
(see #ifdef above).



I ask in
part because the presence of such constants may then be taken as
justification to add similar things in new ports. Yet such definitions
shouldn't be put here.


 From my understanding we are using the public headers to provide 
macros/defines that are used by both the toolstack and the 
hypervisor. If they are not meant to be exposed to the guest, then 
they will be protected with "#if defined(__XEN__) || 
defined(__XEN_TOOLS__)".


I think we are in a similar situation here. So it is not clear where 
they should be put if we need to share them between the hypervisor 
and the toolstack.


What about include/xen/lib? There are headers below that linked at 
build time

via tools/include/Makefile to tools/include/xen/lib.


To me, the question is why would we want to move PSR_* in xen/lib (or 
whatever name we decide) but all the other defines that are only used 
by the toolstack would still be in public/.


So are you suggesting to move all the tools only information in xen/lib?


I didn't want to suggest that, especially with our general desire to 
switch the

tools' interfaces to stable ones.


Ok. If there are a desire to switch the tools interface to stables one. 
Then...




I just wanted to point out that there are other locations available already
where such information could be shared between hypervisor and tools. 
Especially
information related to hardware (so not an interface we are defining) 
might be

a good candidate for such an alternative location.


... I disagree with moving PSR_* outside of the public interface because 
they are those defines are used in hypercalls. So they would be part of 
the ABI.


Cheers,

--
Julien Grall

[linux-linus test] 182374: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 20 guest-start/debianhvm.repeat 
fail REGR. vs. 182357
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 20 guest-start/debianhvm.repeat 
fail in 182371 REGR. vs. 182357

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 8 xen-boot fail in 182371 pass in 
182374
 test-armhf-armhf-xl   8 xen-boot fail in 182371 pass in 182374
 test-amd64-amd64-xl-shadow 20 guest-localmigrate/x10 fail in 182371 pass in 
182374
 test-amd64-amd64-dom0pvh-xl-amd 22 guest-start/debian.repeat fail in 182371 
pass in 182374
 test-armhf-armhf-libvirt-qcow2 13 guest-startfail in 182371 pass in 182374
 test-amd64-amd64-xl-pvhv2-amd  8 xen-boot  fail pass in 182371
 test-amd64-amd64-xl  20 guest-localmigrate/x10 fail pass in 182371
 test-amd64-amd64-xl-multivcpu 20 guest-localmigrate/x10fail pass in 182371
 test-amd64-amd64-dom0pvh-xl-intel 20 guest-localmigrate/x10 fail pass in 182371
 test-amd64-amd64-xl-credit1  22 guest-start/debian.repeat  fail pass in 182371
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail pass in 
182371
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 182371
 test-amd64-amd64-xl-qemuu-ovmf-amd64 20 guest-start/debianhvm.repeat fail pass 
in 182371

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

Re: [PATCH v2 1/4] block: rename blk_io_plug_call() API to defer_call()

[Philippe Mathieu-Daudé]

On 17/8/23 17:58, Stefan Hajnoczi wrote:

Prepare to move the blk_io_plug_call() API out of the block layer so
that other subsystems call use this deferred call mechanism. Rename it
to defer_call() but leave the code in block/plug.c.

The next commit will move the code out of the block layer.

Suggested-by: Ilya Maximets 
Signed-off-by: Stefan Hajnoczi 
---
  include/sysemu/block-backend-io.h |   6 +-
  block/blkio.c |   8 +--
  block/io_uring.c  |   4 +-
  block/linux-aio.c |   4 +-
  block/nvme.c  |   4 +-
  block/plug.c  | 109 +++---
  hw/block/dataplane/xen-block.c|  10 +--
  hw/block/virtio-blk.c |   4 +-
  hw/scsi/virtio-scsi.c |   6 +-
  9 files changed, 76 insertions(+), 79 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [XEN PATCH v11 00/14] Xen FF-A mediator

[Julien Grall]

Hi Jens,

On 31/07/2023 13:15, Jens Wiklander wrote:

Jens Wiklander (14):
   xen/arm: ffa: add direct request support
   xen/arm: ffa: map SPMC rx/tx buffers
   xen/arm: ffa: send guest events to Secure Partitions
   xen/arm: ffa: support mapping guest RX/TX buffers
   xen/arm: ffa: support guest FFA_PARTITION_INFO_GET
   xen/arm: move regpair_to_uint64() and uint64_to_regpair() to regs.h
   xen/arm: ffa: add defines for sharing memory
   xen/arm: ffa: add ABI structs for sharing memory
   xen/arm: ffa: support sharing memory
   xen/arm: ffa: add support to reclaim shared memory
   xen/arm: ffa: improve lock granularity
   xen/arm: ffa: list current limitations
   tools: add Arm FF-A mediator
   docs: add Arm FF-A mediator


The series is now committed. Note, I had to resolve a context conflict 
in the CHANGELOG.md.


Cheers,

--
Julien Grall

Re: [PATCH v2 2/4] util/defer-call: move defer_call() to util/

[Philippe Mathieu-Daudé]

Hi Stefan,

On 17/8/23 17:58, Stefan Hajnoczi wrote:

The networking subsystem may wish to use defer_call(), so move the code
to util/ where it can be reused.

As a reminder of what defer_call() does:

This API defers a function call within a defer_call_begin()/defer_call_end()
section, allowing multiple calls to batch up. This is a performance
optimization that is used in the block layer to submit several I/O requests
at once instead of individually:

   defer_call_begin(); <-- start of section
   ...
   defer_call(my_func, my_obj); <-- deferred my_func(my_obj) call
   defer_call(my_func, my_obj); <-- another
   defer_call(my_func, my_obj); <-- another
   ...
   defer_call_end(); <-- end of section, my_func(my_obj) is called once

Suggested-by: Ilya Maximets 
Signed-off-by: Stefan Hajnoczi 
---
  MAINTAINERS   |  3 ++-
  include/qemu/defer-call.h | 15 +++
  include/sysemu/block-backend-io.h |  4 
  block/blkio.c |  1 +
  block/io_uring.c  |  1 +
  block/linux-aio.c |  1 +
  block/nvme.c  |  1 +
  hw/block/dataplane/xen-block.c|  1 +
  hw/block/virtio-blk.c |  1 +
  hw/scsi/virtio-scsi.c |  1 +
  block/plug.c => util/defer-call.c |  2 +-
  block/meson.build |  1 -
  util/meson.build  |  1 +
  13 files changed, 26 insertions(+), 7 deletions(-)
  create mode 100644 include/qemu/defer-call.h
  rename block/plug.c => util/defer-call.c (99%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6111b6b4d9..7cd7132ffc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2676,12 +2676,13 @@ S: Supported
  F: util/async.c
  F: util/aio-*.c
  F: util/aio-*.h
+F: util/defer-call.c


If used by network/other backends, maybe worth adding a
brand new section instead, rather than "Block I/O path".


  F: util/fdmon-*.c
  F: block/io.c
-F: block/plug.c
  F: migration/block*
  F: include/block/aio.h
  F: include/block/aio-wait.h
+F: include/qemu/defer-call.h
  F: scripts/qemugdb/aio.py
  F: tests/unit/test-fdmon-epoll.c
  T: git https://github.com/stefanha/qemu.git block
diff --git a/include/qemu/defer-call.h b/include/qemu/defer-call.h
new file mode 100644
index 00..291f86c987
--- /dev/null
+++ b/include/qemu/defer-call.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Deferred calls
+ *
+ * Copyright Red Hat.
+ */
+
+#ifndef QEMU_DEFER_CALL_H
+#define QEMU_DEFER_CALL_H
+


Please add smth like:

   /* See documentation in util/defer-call.c */


+void defer_call_begin(void);
+void defer_call_end(void);
+void defer_call(void (*fn)(void *), void *opaque);
+
+#endif /* QEMU_DEFER_CALL_H */


Reviewed-by: Philippe Mathieu-Daudé