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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-freebsd11-amd64 18 guest-saverestore.2 fail pass in 
186452-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 186444
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186444
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 186444
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 186444
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 186444
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 186444
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-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-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-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-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-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-amd64-amd64-libvirt-vhd 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-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-xl-qcow214 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-qcow215 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-raw  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-raw  15 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  9e7c26ad8532c3efda174dee5ab8bdbeef1e4f6d
baseline version:
 xen  62071a1c16c4dbe765491e58e456fd3a19b33298

Last test of basis   186444  2024-06-21 07:49:49 Z0 days
Testing same since   186448  2024-06-21 18:40:23 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Matthew Barnes 

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

[linux-6.1 test] 186445: tolerable FAIL - PUSHED

[osstest service owner]

flight 186445 linux-6.1 real [real]
flight 186450 linux-6.1 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186445/
http://logs.test-lab.xenproject.org/osstest/logs/186450/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 186450-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 186370
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 186370
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 186370
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186370
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 186370
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 186370
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-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-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-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-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-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-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-qcow214 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-qcow215 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-raw  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-raw  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-checkfail   never pass

version targeted for testing:
 linuxa6398e37309000e35cedb5cc328a0f8d00d7d7b9
baseline version:
 linuxeb44d83053d66372327e69145e8d2fa7400a4991

Last test of basis   186370  2024-06-16 12:15:05 Z5 days
Testing same since   186445  2024-06-21 12:46:38 Z0 days1 attempts


People who touched revisions under test:
  "Csókás, Bence" 
  Aapo Vienamo 
  Adam Miotk 
  Alan Stern 
  Aleksandr Mishin 
  Alex Deucher 
  Alexander Shishkin 
  Alexey Kodanev 
  Allen Pais 
  Amit Sunil Dhamne 
  Amjad Ouled-Ameur 
  Andi Shyti 
  Andi Shyti 
  Andrei Coardos 
  Andrei Vagin 
  Andrew Morton 
  Andrii Nakryiko 
  Andy Shevchenko 
  Antonio Quartulli 
  Apurva Nandan 
  Armin Wolf 
  Arpana Arland

[PATCH v2] docs/misra: rules for mass adoption

[Stefano Stabellini]

From: Stefano Stabellini 

This patch adds a bunch of rules to rules.rst that are uncontroversial
and have zero violations in Xen. As such, they have been approved for
adoption.

All the ones that regard the standard library have the link to the
existing footnote in the notes.

Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- replicate the Xen doesn't provide a stdlib message for 22.8, 22.9, 22.10
- remove stray empty bullet for 22.1
---
 docs/misra/rules.rst | 99 
 1 file changed, 99 insertions(+)

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 80e5e972ad..6158bad31c 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -580,6 +580,11 @@ maintainers if you want to suggest a change.
  - The relational operators > >= < and <= shall not be applied to objects 
of pointer type except where they point into the same object
  -
 
+   * - `Rule 18.8 
`_
+ - Required
+ - Variable-length array types shall not be used
+ -
+
* - `Rule 19.1 
`_
  - Mandatory
  - An object shall not be assigned or copied to an overlapping
@@ -589,11 +594,29 @@ maintainers if you want to suggest a change.
instances where Eclair is unable to verify that the code is valid
in regard to Rule 19.1. Caution reports are not violations.
 
+   * - `Rule 20.2 
`_
+ - Required
+ - The ', " or \ characters and the /* or // character sequences
+   shall not occur in a header file name
+ -
+
+   * - `Rule 20.3 
`_
+ - Required
+ - The #include directive shall be followed by either a 
+   or "filename" sequence
+ -
+
* - `Rule 20.4 
`_
  - Required
  - A macro shall not be defined with the same name as a keyword
  -
 
+   * - `Rule 20.6 
`_
+ - Required
+ - Tokens that look like a preprocessing directive shall not occur
+   within a macro argument
+ -
+
* - `Rule 20.7 
`_
  - Required
  - Expressions resulting from the expansion of macro parameters
@@ -609,6 +632,12 @@ maintainers if you want to suggest a change.
evaluation
  -
 
+   * - `Rule 20.11 
`_
+ - Required
+ - A macro parameter immediately following a # operator shall not
+   immediately be followed by a ## operator
+ -
+
* - `Rule 20.12 
`_
  - Required
  - A macro parameter used as an operand to the # or ## operators,
@@ -651,11 +680,39 @@ maintainers if you want to suggest a change.
declared
  - See comment for Rule 21.1
 
+   * - `Rule 21.3 
`_
+ - Required
+ - The memory allocation and deallocation functions of 
+   shall not be used
+ - Xen doesn't provide, use, or link against a Standard Library 
[#xen-stdlib]_
+
+   * - `Rule 21.4 
`_
+ - Required
+ - The standard header file  shall not be used
+ - Xen doesn't provide, use, or link against a Standard Library 
[#xen-stdlib]_
+
+   * - `Rule 21.5 
`_
+ - Required
+ - The standard header file  shall not be used
+ - Xen doesn't provide, use, or link against a Standard Library 
[#xen-stdlib]_
+
* - `Rule 21.6 
`_
  - Required
  - The Standard Library input/output routines shall not be used
  - Xen doesn't provide, use, or link against a Standard Library 
[#xen-stdlib]_
 
+   * - `Rule 21.7 
`_
+ - Required
+ - The Standard Library functions atof, atoi, atol and atoll of
+shall not be used
+ - Xen doesn't provide, use, or link against a Standard Library 
[#xen-stdlib]_
+
+   * - `Rule 21.8 
`_
+ - Required
+ - The Standard Library functions abort, exit and system of
+shall not be used
+ - Xen doesn't provide, use, or link against a Standard Library

Re: [PATCH] docs/misra: rules for mass adoption

[Stefano Stabellini]

On Thu, 23 May 2024, Jan Beulich wrote:
> On 23.05.2024 03:26, Stefano Stabellini wrote:
> > @@ -725,12 +787,25 @@ maintainers if you want to suggest a change.
> >   - The Standard Library function system of  shall not be used
> >   -
> >  
> > +   * - `Rule 22.1 
> > `_
> > + - Required
> > + - All resources obtained dynamically by means of Standard Library
> > +   functions shall be explicitly released
> > + -
> > + - Xen doesn't provide, use, or link against a Standard Library 
> > [#xen-stdlib]_
> 
> The empty sub-bullet-point looks stray here.

Good catch, thanks!


> > @@ -748,6 +823,31 @@ maintainers if you want to suggest a change.
> > stream has been closed
> >   -
> >  
> > +   * - `Rule 22.7 
> > `_
> > + - Required
> > + - The macro EOF shall only be compared with the unmodified return
> > +   value from any Standard Library function capable of returning EOF
> > + - Xen doesn't provide, use, or link against a Standard Library 
> > [#xen-stdlib]_
> 
> Shouldn't this remark also be replicated ...
> 
> > +   * - `Rule 22.8 
> > `_
> > + - Required
> > + - The value of errno shall be set to zero prior to a call to an
> > +   errno-setting-function
> > + -
> > +
> > +   * - `Rule 22.9 
> > `_
> > + - Required
> > + - The value of errno shall be tested against zero after calling an
> > +   errno-setting-function
> > + -
> > +
> > +   * - `Rule 22.10 
> > `_
> > + - Required
> > + - The value of errno shall only be tested when the last function to
> > +   be called was an errno-setting-function
> > + -
> 
> ... for all three of these, seeing that errno is something a (standard) 
> library
> would provide? Or alternatively should remarks here say that we simply have no
> errno?

I'll replicate the full message

Re: [RFC PATCH v2] iommu/xen: Add Xen PV-IOMMU driver

[Robin Murphy]

On 2024-06-21 5:08 pm, TSnake41 wrote:

From: Teddy Astie 

In the context of Xen, Linux runs as Dom0 and doesn't have access to the
machine IOMMU. Although, a IOMMU is mandatory to use some kernel features
such as VFIO or DMA protection.

In Xen, we added a paravirtualized IOMMU with iommu_op hypercall in order to
allow Dom0 to implement such feature. This commit introduces a new IOMMU driver
that uses this new hypercall interface.

Signed-off-by Teddy Astie 
---
Changes since v1 :
* formatting changes
* applied Jan Beulich proposed changes : removed vim notes at end of pv-iommu.h
* applied Jason Gunthorpe proposed changes : use new ops and remove redundant
checks
---
  arch/x86/include/asm/xen/hypercall.h |   6 +
  drivers/iommu/Kconfig|   9 +
  drivers/iommu/Makefile   |   1 +
  drivers/iommu/xen-iommu.c| 489 +++
  include/xen/interface/memory.h   |  33 ++
  include/xen/interface/pv-iommu.h | 104 ++
  include/xen/interface/xen.h  |   1 +
  7 files changed, 643 insertions(+)
  create mode 100644 drivers/iommu/xen-iommu.c
  create mode 100644 include/xen/interface/pv-iommu.h

diff --git a/arch/x86/include/asm/xen/hypercall.h 
b/arch/x86/include/asm/xen/hypercall.h
index a2dd24947eb8..6b1857f27c14 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -490,6 +490,12 @@ HYPERVISOR_xenpmu_op(unsigned int op, void *arg)
return _hypercall2(int, xenpmu_op, op, arg);
  }
  
+static inline int

+HYPERVISOR_iommu_op(void *arg)
+{
+   return _hypercall1(int, iommu_op, arg);
+}
+
  static inline int
  HYPERVISOR_dm_op(
domid_t dom, unsigned int nr_bufs, struct xen_dm_op_buf *bufs)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 0af39bbbe3a3..242cefac77c9 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -480,6 +480,15 @@ config VIRTIO_IOMMU
  
  	  Say Y here if you intend to run this kernel as a guest.
  
+config XEN_IOMMU

+   bool "Xen IOMMU driver"
+   depends on XEN_DOM0


Clearly this depends on X86 as well.


+   select IOMMU_API
+   help
+   Xen PV-IOMMU driver for Dom0.
+
+   Say Y here if you intend to run this guest as Xen Dom0.
+
  config SPRD_IOMMU
tristate "Unisoc IOMMU Support"
depends on ARCH_SPRD || COMPILE_TEST
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 542760d963ec..393afe22c901 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IOMMU_SVA) += iommu-sva.o
  obj-$(CONFIG_IOMMU_IOPF) += io-pgfault.o
  obj-$(CONFIG_SPRD_IOMMU) += sprd-iommu.o
  obj-$(CONFIG_APPLE_DART) += apple-dart.o
+obj-$(CONFIG_XEN_IOMMU) += xen-iommu.o
\ No newline at end of file
diff --git a/drivers/iommu/xen-iommu.c b/drivers/iommu/xen-iommu.c
new file mode 100644
index ..b765445d27cd
--- /dev/null
+++ b/drivers/iommu/xen-iommu.c
@@ -0,0 +1,489 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xen PV-IOMMU driver.
+ *
+ * Copyright (C) 2024 Vates SAS
+ *
+ * Author: Teddy Astie 
+ *
+ */
+
+#define pr_fmt(fmt)"xen-iommu: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 


Please drop this; it's a driver, not a DMA ops implementation.


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_DESCRIPTION("Xen IOMMU driver");
+MODULE_AUTHOR("Teddy Astie ");
+MODULE_LICENSE("GPL");
+
+#define MSI_RANGE_START(0xfee0)
+#define MSI_RANGE_END  (0xfeef)
+
+#define XEN_IOMMU_PGSIZES   (0x1000)
+
+struct xen_iommu_domain {
+   struct iommu_domain domain;
+
+   u16 ctx_no; /* Xen PV-IOMMU context number */
+};
+
+static struct iommu_device xen_iommu_device;
+
+static uint32_t max_nr_pages;
+static uint64_t max_iova_addr;
+
+static spinlock_t lock;


Not a great name - usually it's good to name a lock after what it 
protects. Although perhaps it is already, since AFAICS this isn't 
actually used anywhere anyway.



+static inline struct xen_iommu_domain *to_xen_iommu_domain(struct iommu_domain 
*dom)
+{
+   return container_of(dom, struct xen_iommu_domain, domain);
+}
+
+static inline u64 addr_to_pfn(u64 addr)
+{
+   return addr >> 12;
+}
+
+static inline u64 pfn_to_addr(u64 pfn)
+{
+   return pfn << 12;
+}
+
+bool xen_iommu_capable(struct device *dev, enum iommu_cap cap)
+{
+   switch (cap) {
+   case IOMMU_CAP_CACHE_COHERENCY:
+   return true;


Will the PV-IOMMU only ever be exposed on hardware where that really is 
always true?



+
+   default:
+   return false;
+   }
+}
+
+struct iommu_domain *xen_iommu_domain_alloc_paging(struct device *dev)
+{
+   struct xen_iommu_domain *domain;
+   int ret;
+
+   struct pv_iommu_op op = {
+   

Re: [PATCH 1/2] automation/eclair_analysis: deviate MISRA C Rule 21.2

[Stefano Stabellini]

On Fri, 21 Jun 2024, Jan Beulich wrote:
> On 21.06.2024 03:02, Stefano Stabellini wrote:
> > On Thu, 20 Jun 2024, Jan Beulich wrote:
> >> On 19.06.2024 19:09, Alessandro Zucchelli wrote:
> >>> Rule 21.2 reports identifiers reserved for the C and POSIX standard
> >>> libraries: all xen's translation units are compiled with option
> >>> -nostdinc, this guarantees that these libraries are not used, therefore
> >>> a justification is provided for allowing uses of such identifiers in
> >>> the project.
> >>> Builtins starting with "__builtin_" still remain available.
> >>>
> >>> No functional change.
> >>>
> >>> Signed-off-by: Alessandro Zucchelli 
> >>> ---
> >>>  automation/eclair_analysis/ECLAIR/deviations.ecl | 11 +++
> >>>  1 file changed, 11 insertions(+)
> >>>
> >>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> >>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> index 447c1e6661..9fa9a7f01c 100644
> >>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> @@ -487,6 +487,17 @@ leads to a violation of the Rule are deviated."
> >>>  # Series 21.
> >>>  #
> >>>  
> >>> +-doc_begin="Rules 21.1 and 21.2 report identifiers reserved for the C 
> >>> and POSIX
> >>> +standard libraries: if these libraries are not used there is no reason 
> >>> to avoid such
> >>> +identifiers. All xen's translation units are compiled with option 
> >>> -nostdinc,
> >>> +this guarantees that these libraries are not used. Some compilers could 
> >>> perform
> >>> +optimization using built-in functions: this risk is partially addressed 
> >>> by
> >>> +using the compilation option -fno-builtin. Builtins starting with 
> >>> \"__builtin_\"
> >>> +still remain available."
> >>
> >> While the sub-section "Reserved Identifiers" is part of Section 7,
> >> "Library", close coordination is needed between the library and the
> >> compiler, which only together form an "implementation". Therefore any
> >> use of identifiers beginning with two underscores or beginning with an
> >> underscore and an upper case letter is at risk of colliding not only
> >> with a particular library implementation (which we don't use), but
> >> also of such with a particular compiler implementation (which we cannot
> >> avoid to use). How can we permit use of such potentially problematic
> >> identifiers?
> > 
> > Alternative question: is there a way we can check if there is clash of
> > some sort between a compiler implementation of something and a MACRO or
> > identifier we have in Xen? An error or a warning from the compiler for
> > instance? That could be an easy way to prove we are safe.
> 
> Well. I think it is the default for the compiler to warn when re-#define-
> ing a previously #define-d (by the compiler or by us) symbol, so on that
> side we ought to be safe at any given point in time,

OK, that's good. It seems to me that this explanation should be part of
the deviation text.


> yet we're still latently unsafe (as to compilers introducing new
> pre-defines).

Sure, but we don't need to be safe in relation to future compiler. Right
now, we are targeting gcc-12.1.0 as written in
docs/misra/C-language-toolchain.rst. When we decide to enable a new
compiler in Xen we can fix/change any specific define as needed. Also
note the large amount of things written in C-language-toolchain.rst that
need to be checked and verified for a new compiler to make sure we can
actually use it safely (we make many assumptions).


> For built-in declarations, though, there's nothing I'm aware of that
> would indicate collisions.

For builtins, Alessandro was suggesting -fno-builtin. One question to
Alessandro is why would -fno-builtin only "partially" address the
problem.

Another question for Jan and also Alessandro: given that builtins
starting with __builtin_ remain available, any drawbacks in using
-fno-builtin in a Xen build?



> > Also, can we use the fact that the compiler we use is the same compiler
> > used to compile Linux, and Linux makes extensive use of identifiers and
> > macros starting with underscores as one of the reason for being safe
> > from clashes?
> 
> I think we could, but I don't think we should.

Re: [XEN PATCH v2] xen: add explicit comment to identify notifier patterns

[Stefano Stabellini]

On Fri, 21 Jun 2024, Federico Serafini wrote:
> On 21/06/24 03:13, Stefano Stabellini wrote:
> > On Thu, 20 Jun 2024, Federico Serafini wrote:
> > > On 19/06/24 13:17, Julien Grall wrote:
> > > > Hi Federico,
> > > > 
> > > > On 19/06/2024 10:29, Federico Serafini wrote:
> > > > > MISRA C Rule 16.4 states that every `switch' statement shall have a
> > > > > `default' label" and a statement or a comment prior to the
> > > > > terminating break statement.
> > > > > 
> > > > > This patch addresses some violations of the rule related to the
> > > > > "notifier pattern": a frequently-used pattern whereby only a few
> > > > > values
> > > > > are handled by the switch statement and nothing should be done for
> > > > > others (nothing to do in the default case).
> > > > > 
> > > > > Note that for function mwait_idle_cpu_init() in
> > > > > xen/arch/x86/cpu/mwait-idle.c the /* Notifier pattern. */ comment is
> > > > > not added: differently from the other functions covered in this patch,
> > > > > the default label has a return statement that does not violates Rule
> > > > > 16.4.
> > > > > 
> > > > > No functional change.
> > > > > 
> > > > > Signed-off-by: Federico Serafini 
> > > > > ---
> > > > > Changes in v2:
> > > > > as Jan pointed out, in the v1 some patterns were not explicitly
> > > > > identified
> > > > > (https://lore.kernel.org/xen-devel/cad05a5c-e2d8-4e5d-af05-30ae6f959...@bugseng.com/).
> > > > > 
> > > > > This version adds the /* Notifier pattern. */ to all the pattern
> > > > > present
> > > > > in
> > > > > the Xen codebase except for mwait_idle_cpu_init().
> > > > > ---
> > > > >    xen/arch/arm/cpuerrata.c | 1 +
> > > > >    xen/arch/arm/gic-v3-lpi.c    | 4 
> > > > >    xen/arch/arm/gic.c   | 1 +
> > > > >    xen/arch/arm/irq.c   | 4 
> > > > >    xen/arch/arm/mmu/p2m.c   | 1 +
> > > > >    xen/arch/arm/percpu.c    | 1 +
> > > > >    xen/arch/arm/smpboot.c   | 1 +
> > > > >    xen/arch/arm/time.c  | 1 +
> > > > >    xen/arch/arm/vgic-v3-its.c   | 2 ++
> > > > >    xen/arch/x86/acpi/cpu_idle.c | 4 
> > > > >    xen/arch/x86/cpu/mcheck/mce.c    | 4 
> > > > >    xen/arch/x86/cpu/mcheck/mce_intel.c  | 4 
> > > > >    xen/arch/x86/genapic/x2apic.c    | 3 +++
> > > > >    xen/arch/x86/hvm/hvm.c   | 1 +
> > > > >    xen/arch/x86/nmi.c   | 1 +
> > > > >    xen/arch/x86/percpu.c    | 3 +++
> > > > >    xen/arch/x86/psr.c   | 3 +++
> > > > >    xen/arch/x86/smpboot.c   | 3 +++
> > > > >    xen/common/kexec.c   | 1 +
> > > > >    xen/common/rcupdate.c    | 1 +
> > > > >    xen/common/sched/core.c  | 1 +
> > > > >    xen/common/sched/cpupool.c   | 1 +
> > > > >    xen/common/spinlock.c    | 1 +
> > > > >    xen/common/tasklet.c | 1 +
> > > > >    xen/common/timer.c   | 1 +
> > > > >    xen/drivers/cpufreq/cpufreq.c    | 1 +
> > > > >    xen/drivers/cpufreq/cpufreq_misc_governors.c | 3 +++
> > > > >    xen/drivers/passthrough/x86/hvm.c    | 3 +++
> > > > >    xen/drivers/passthrough/x86/iommu.c  | 3 +++
> > > > >    29 files changed, 59 insertions(+)
> > > > > 
> > > > > diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> > > > > index 2b7101ea25..69c30aecd8 100644
> > > > > --- a/xen/arch/arm/cpuerrata.c
> > > > > +++ b/xen/arch/arm/cpuerrata.c
> > > > > @@ -730,6 +730,7 @@ static int cpu_errata_callback(struct
> > > > > notifier_block
> > > > > *nfb,
> > > > >    rc = enable_nonboot_cpu_caps(arm_errata);
> > > > >    break;
> > > > >    default:
> > > > > +    /* Notifier pattern. */
> > > > Without looking at the commit message (which may not be trivial when
> > > > committed), it is not clear to me what this is supposed to mean. Will
> > > > there
> > > > be a longer explanation in the MISRA doc? Should this be a SAF-*
> > > > comment?
> > > > 
> > > > >    break;
> > > > >    }
> > > > > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> > > > > index eb0a5535e4..4c2bd35403 100644
> > > > > --- a/xen/arch/arm/gic-v3-lpi.c
> > > > > +++ b/xen/arch/arm/gic-v3-lpi.c
> > > > > @@ -389,6 +389,10 @@ static int cpu_callback(struct notifier_block
> > > > > *nfb,
> > > > > unsigned long action,
> > > > >    printk(XENLOG_ERR "Unable to allocate the pendtable for
> > > > > CPU%lu\n",
> > > > >   cpu);
> > > > >    break;
> > > > > +
> > > > > +    default:
> > > > > +    /* Notifier pattern. */
> > > > > +    break;
> > > > 
> > > > Skimming through v1, it was pointe

Re: [XEN PATCH v3] automation/eclair: add deviation for MISRA C Rule 17.7

[Stefano Stabellini]

On Wed, 19 Jun 2024, Stefano Stabellini wrote:
> On Fri, 14 Jun 2024, Federico Serafini wrote:
> > Update ECLAIR configuration to deviate some cases where not using
> > the return value of a function is not dangerous.
> > 
> > Signed-off-by: Federico Serafini 
> 
> Acked-by: Stefano Stabellini 
 
I would like to request a release ack, as this patch only affects the
ECLAIR analysis for R17.7, which is non-blocking anyway (meaning: it
cannot cause a gitlab-ci failure, it is only informative).



> > ---
> > Changes in v3:
> > - removed unwanted underscores;
> > - grammar fixed;
> > - do not constraint to the first actual argument.
> > Changes in v2:
> > - do not deviate strlcpy and strlcat.
> > ---
> >  automation/eclair_analysis/ECLAIR/deviations.ecl | 4 
> >  docs/misra/deviations.rst| 9 +
> >  2 files changed, 13 insertions(+)
> > 
> > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> > b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > index 447c1e6661..97281082a8 100644
> > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > @@ -413,6 +413,10 @@ explicit comment indicating the fallthrough intention 
> > is present."
> >  -config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
> >  -doc_end
> >  
> > +-doc_begin="Not using the return value of a function does not endanger 
> > safety if it coincides with an actual argument."
> > +-config=MC3R1.R17.7,calls+={safe, "any()", 
> > "decl(name(__builtin_memcpy||__builtin_memmove||__builtin_memset||cpumask_check))"}
> > +-doc_end
> > +
> >  #
> >  # Series 18.
> >  #
> > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> > index 36959aa44a..f3abe31eb5 100644
> > --- a/docs/misra/deviations.rst
> > +++ b/docs/misra/deviations.rst
> > @@ -364,6 +364,15 @@ Deviations related to MISRA C:2012 Rules:
> > by `stdarg.h`.
> >   - Tagged as `deliberate` for ECLAIR.
> >  
> > +   * - R17.7
> > + - Not using the return value of a function does not endanger safety 
> > if it
> > +   coincides with an actual argument.
> > + - Tagged as `safe` for ECLAIR. Such functions are:
> > + - __builtin_memcpy()
> > + - __builtin_memmove()
> > + - __builtin_memset()
> > + - cpumask_check()
> > +
> > * - R20.4
> >   - The override of the keyword \"inline\" in xen/compiler.h is present 
> > so
> > that section contents checks pass when the compiler chooses not to
> > -- 
> > 2.34.1
> > 
> 

Re: [XEN PATCH] automation/eclair: add deviations of MISRA C Rule 5.5

[Stefano Stabellini]

On Thu, 20 Jun 2024, Stefano Stabellini wrote:
> On Thu, 20 Jun 2024, Federico Serafini wrote:
> > MISRA C Rule 5.5 states that "Identifiers shall be distinct from macro
> > names".
> > 
> > Update ECLAIR configuration to deviate:
> > - macros expanding to their own name;
> > - clashes between macros and non-callable entities;
> > - clashes related to the selection of specific implementations of string
> >   handling functions.
> > 
> > Signed-off-by: Federico Serafini 
> 
> Reviewed-by: Stefano Stabellini 

I would like to ask for a release-ack as its effect is limited to ECLAIR
analysis results and rule 5.5 is not blocking anyway (it is allowed to
fail).

Re: [PATCH v2] automation/eclair_analysis: deviate and|or|xor|not for MISRA C Rule 21.2

[Stefano Stabellini]

On Fri, 21 Jun 2024, Alessandro Zucchelli wrote:
> Rule 21.2 reports identifiers reserved for the C and POSIX standard
> libraries: or, and, not and xor are reserved identifiers because they
> constitute alternate spellings for the corresponding operators (they are
> defined as macros by iso646.h); however Xen doesn't use standard library
> headers, so there is no risk of overlap.
> 
> This addresses violations arising from x86_emulate/x86_emulate.c, where
> label statements named as or, and and xor appear.
> 
> No functional change.
> 
> Signed-off-by: Alessandro Zucchelli 
> Acked-by: Stefano Stabellini 
> ---
> Changes from v1:
> Added deviation for 'not' identifier.
> Added explanation of where these identifiers are defined, specifically in the
> 'iso646.h' file of the Standard Library.
> ---
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 069519e380..14c7afb39e 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -501,7 +501,7 @@ still remain available."
>  -doc_begin="or, and and xor are reserved identifiers because they constitute 
> alternate
>  spellings for the corresponding operators (they are defined as macros by 
> iso646.h).
>  However, Xen doesn't use standard library headers, so there is no risk of 
> overlap."
> --config=MC3R1.R21.2,reports+={safe, 
> "any_area(stmt(ref(kind(label)&&^(or|and|xor)$)))"}
> +-config=MC3R1.R21.2,reports+={safe, 
> "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>  -doc_end

It looks like this patch relies on the previous version to be applied?
Maybe you forgot to squash your changes with your previous patch?

Re: [PATCH 2/2] xen/multicall: Change nr_calls to uniformly be unsigned long

[Stefano Stabellini]

On Fri, 21 Jun 2024, Andrew Cooper wrote:
> Right now, the non-compat declaration and definition of do_multicall()
> differing types for the nr_calls parameter.
> 
> This is a MISRA rule 8.3 violation, but it's also time-bomb waiting for the
> first 128bit architecture (RISC-V looks as if it might get there first).
> 
> Worse, the type chosen here has a side effect of truncating the guest
> parameter, because Xen still doesn't have a clean hypercall ABI definition.
> 
> Switch uniformly to using unsigned long.
> 
> This addresses the MISRA violation, and while it is a guest-visible ABI
> change, it's only in the corner case where the guest kernel passed a
> bogus-but-correct-when-truncated value.  I can't find any any users of
> mutilcall which pass a bad size to begin with, so this should have no
> practical effect on guests.
> 
> In fact, this brings the behaviour of multicalls more in line with the header
> description of how it behaves.
> 
> With this fix, Xen is now fully clean to Rule 8.3, so mark it so.
> 
> Signed-off-by: Andrew Cooper 

I am in favor of this approach. I have 2 suggestions which are
nice-to-have, not must-have.

We all know that "unsigned long" is register size. However, the C
standard doesn't define it that way. I tried to make it clear in
docs/misra/C-language-toolchain.rst. However, nowhere in the public
Xen headers we say that by "unsigned long" we mean register size. I
think we should say that somewhere in the headers, but I can see it
doesn't have to be part of this patch. It would be nice to add a comment
in xen/include/public/xen.h saying "unsigned long is register size" or
"refer to docs/misra/C-language-toolchain.rst for type sizes and
definitions", but it is not a hard request.

The second observation, if we are concerned about invalid nr_calls
values, we could add a check at the beginning of do_multicall:

  if ( nr_calls >= UINT32_MAX )

I am not sure it is an improvement, but maybe it is.


Given that both the above suggestions are nice-to-have:

Reviewed-by: Stefano Stabellini 





> ---
> CC: George Dunlap 
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Roger Pau Monné 
> CC: Stefano Stabellini 
> CC: Roberto Bagnara 
> CC: consult...@bugseng.com 
> CC: Oleksii Kurochko 
> 
> I know this isn't going to be universally liked, but we need to do something,
> and this is my very strong vote for the least bad way out of the current mess.
> ---
>  automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
>  xen/common/multicall.c| 4 ++--
>  xen/include/hypercall-defs.c  | 4 ++--
>  xen/include/public/xen.h  | 2 +-
>  4 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl 
> b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index b829655ca0bc..3d06a1aad410 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -45,6 +45,7 @@ MC3R1.R7.2||
>  MC3R1.R7.4||
>  MC3R1.R8.1||
>  MC3R1.R8.2||
> +MC3R1.R8.3||
>  MC3R1.R8.5||
>  MC3R1.R8.6||
>  MC3R1.R8.8||
> diff --git a/xen/common/multicall.c b/xen/common/multicall.c
> index 1f0cc4cb267c..ce394c5efcfe 100644
> --- a/xen/common/multicall.c
> +++ b/xen/common/multicall.c
> @@ -34,11 +34,11 @@ static void trace_multicall_call(multicall_entry_t *call)
>  }
>  
>  ret_t do_multicall(
> -XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, uint32_t nr_calls)
> +XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, unsigned long 
> nr_calls)
>  {
>  struct vcpu *curr = current;
>  struct mc_state *mcs = &curr->mc_state;
> -uint32_t i;
> +unsigned longi;
>  int  rc = 0;
>  enum mc_disposition disp = mc_continue;
>  
> diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
> index 47c093acc84d..7720a29ade0b 100644
> --- a/xen/include/hypercall-defs.c
> +++ b/xen/include/hypercall-defs.c
> @@ -135,7 +135,7 @@ xenoprof_op(int op, void *arg)
>  #ifdef CONFIG_COMPAT
>  prefix: compat
>  set_timer_op(uint32_t lo, uint32_t hi)
> -multicall(multicall_entry_compat_t *call_list, uint32_t nr_calls)
> +multicall(multicall_entry_compat_t *call_list, unsigned long nr_calls)
>  memory_op(unsigned int cmd, void *arg)
>  #ifdef CONFIG_IOREQ_SERVER
>  dm_op(domid_t domid, unsigned int nr_bufs, void *bufs)
> @@ -172,7 +172,7 @@ console_io(unsigned int cmd, unsigned int count, char 
> *buffer)
>  vm_assist(unsigned int cmd, unsigned int type)
>  event_channel_op(int cmd, void *arg)
>  mmuext_op(mmuext_op_t *uops, unsigned int count, unsigned int *pdone, 
> unsigned int foreigndom)
> -multicall(multicall_entry_t *call_list, unsigned int nr_calls)
> +multicall(multicall_entry_t *call_list, unsigned long nr_calls)
>  #ifdef CONFIG_PV
>  mmu_update(mmu_update_t *ureqs, unsigned int count, unsigned int *pdone, 
> unsigned int foreigndom)
>  stack_switch(unsigned long ss, unsigned long esp)
> di

Re: [PATCH for-4.19 v2] tools/xl: Open xldevd.log with O_CLOEXEC

[Demi Marie Obenour]

On Fri, Jun 21, 2024 at 05:16:56PM +0100, Andrew Cooper wrote:
> `xl devd` has been observed leaking /var/log/xldevd.log into children.
> 
> Note this is specifically safe; dup2() leaves O_CLOEXEC disabled on newfd, so
> after setting up stdout/stderr, it's only the logfile fd which will close on
> exec().
> 
> Link: https://github.com/QubesOS/qubes-issues/issues/8292
> Reported-by: Demi Marie Obenour 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Juergen Gross 
> CC: Demi Marie Obenour 
> CC: Marek Marczykowski-Górecki 
> CC: Oleksii Kurochko 
> 
> Also entirely speculative based on the QubesOS ticket.
> 
> v2:
>  * Extend the commit message to explain why stdout/stderr aren't closed by
>this change
> 
> For 4.19.  This bugfix was posted earlier, but fell between the cracks.
> ---
>  tools/xl/xl_utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/xl/xl_utils.c b/tools/xl/xl_utils.c
> index 17489d182954..060186db3a59 100644
> --- a/tools/xl/xl_utils.c
> +++ b/tools/xl/xl_utils.c
> @@ -270,7 +270,7 @@ int do_daemonize(const char *name, const char *pidfile)
>  exit(-1);
>  }
>  
> -CHK_SYSCALL(logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND, 0644));
> +CHK_SYSCALL(logfile = open(fullname, O_WRONLY | O_CREAT | O_APPEND | 
> O_CLOEXEC, 0644));
>  free(fullname);
>  assert(logfile >= 3);

Definitely an improvement.  I would also add O_NOCTTY to work around a
particularly unfortunate Linux kernel design decision, but that can
either be fixed up on commit or be a separate patch.

Reviewed-by: Demi Marie Obenour 
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab


signature.asc
Description: PGP signature

Re: [PATCH 1/2] x86/pagewalk: Address MISRA R8.3 violation in guest_walk_tables()

[Stefano Stabellini]

On Fri, 21 Jun 2024, Andrew Cooper wrote:
> Commit 4c5d78a10dc8 ("x86/pagewalk: Re-implement the pagetable walker")
> intentionally renamed guest_walk_tables()'s 'pfec' parameter to 'walk' because
> it's not a PageFault Error Code, despite the name of some of the constants
> passed in.  Sadly the constants-cleanup I've been meaning to do since then
> still hasn't come to pass.
> 
> Update the declaration to match, to placate MISRA.
> 
> Fixes: 4c5d78a10dc8 ("x86/pagewalk: Re-implement the pagetable walker")
> Signed-off-by: Andrew Cooper 

Reviewed-by: Stefano Stabellini 

Re: [XEN PATCH] automation/eclair: add more guidelines to the monitored set

[Stefano Stabellini]

On Fri, 21 Jun 2024, Federico Serafini wrote:
> Add more accepted guidelines to the monitored set to check them at each
> commit.
> 
> Signed-off-by: Federico Serafini 

Acked-by: Stefano Stabellini 

Asking for a release ack: this allows us to see more violations in the
regular ECLAIR scanning results. But they are not blocking, so they
won't cause additional new failures in the pipeline. It is just
informative.


> ---
>  automation/eclair_analysis/ECLAIR/monitored.ecl | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl 
> b/automation/eclair_analysis/ECLAIR/monitored.ecl
> index 4daecb0c83..9ffaebbdc3 100644
> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
> @@ -18,10 +18,13 @@
>  -enable=MC3R1.R12.5
>  -enable=MC3R1.R1.3
>  -enable=MC3R1.R13.6
> +-enable=MC3R1.R13.1
>  -enable=MC3R1.R1.4
>  -enable=MC3R1.R14.1
>  -enable=MC3R1.R14.4
>  -enable=MC3R1.R16.2
> +-enable=MC3R1.R16.3
> +-enable=MC3R1.R16.4
>  -enable=MC3R1.R16.6
>  -enable=MC3R1.R16.7
>  -enable=MC3R1.R17.1
> @@ -34,6 +37,7 @@
>  -enable=MC3R1.R20.13
>  -enable=MC3R1.R20.14
>  -enable=MC3R1.R20.4
> +-enable=MC3R1.R20.7
>  -enable=MC3R1.R20.9
>  -enable=MC3R1.R2.1
>  -enable=MC3R1.R21.10
> @@ -58,6 +62,7 @@
>  -enable=MC3R1.R5.2
>  -enable=MC3R1.R5.3
>  -enable=MC3R1.R5.4
> +-enable=MC3R1.R5.5
>  -enable=MC3R1.R5.6
>  -enable=MC3R1.R6.1
>  -enable=MC3R1.R6.2
> -- 
> 2.34.1
> 

Re: [PATCH v2] common/unlzo: address violation of MISRA C Rule 7.3

[Stefano Stabellini]

On Fri, 21 Jun 2024, Alessandro Zucchelli wrote:
> This addresses violations of MISRA C:2012 Rule 7.3 which states as
> following: the lowercase character `l' shall not be used in a literal
> suffix.
> 
> The file common/unlzo.c defines the non-compliant constant LZO_BLOCK_SIZE with
> having a lowercase 'l'.
> It is now defined as '256*1024L'.
> 
> No functional change.
> 
> Signed-off-by: Alessandro Zucchelli 

Reviewed-by: Stefano Stabellini 

Asking for a release ack for this trivial change


> ---
> Changes from v1:
> Instead of deviating /common/unlzo.c reports fro Rule 7.3 they are addressed 
> by
> changing the non-compliant definition of LZO_BLOCK_SIZE.
> ---
>  xen/common/unlzo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/common/unlzo.c b/xen/common/unlzo.c
> index bdcefa95b3..acb8dff600 100644
> --- a/xen/common/unlzo.c
> +++ b/xen/common/unlzo.c
> @@ -52,7 +52,7 @@ static inline u32 get_unaligned_be32(const void *p)
>  static const unsigned char lzop_magic[] = {
>   0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a };
>  
> -#define LZO_BLOCK_SIZE(256*1024l)
> +#define LZO_BLOCK_SIZE(256*1024L)
>  #define HEADER_HAS_FILTER  0x0800L
>  #define HEADER_SIZE_MIN   (9 + 7 + 4 + 8 + 1   + 4)
>  #define HEADER_SIZE_MAX   (9 + 7 + 1 + 8 + 8 + 4 + 1 + 255 + 4)
> -- 
> 2.34.1
> 

Re: [XEN PATCH v2] common/sched: address a violation of MISRA C Rule 8.8

[Federico Serafini]

Hi,

On 21/06/24 21:59, victorm.l...@amd.com wrote:

From: Victor Lira 

Rule 8.8: "The static storage class specifier shall be used in all
declarations of objects and functions that have internal linkage"


What you are addressing with this patch seems to be a violation of
Rule 8.7: "Functions and objects should not be defined with external
linkage if they are referenced in only one translation unit".



This patch fixes this by adding the static specifier.
No functional changes.

Reported-by: Stewart Hildebrand stewart.hildebr...@amd.com
Signed-off-by: Victor Lira 
Acked-by: George Dunlap 
---
Changes from v1:
- adjust indentation and line width.
---
Cc: George Dunlap 
Cc: Dario Faggioli 
Cc: Juergen Gross 
Cc: xen-devel@lists.xenproject.org
---
  xen/common/sched/credit2.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 685929c290..b4e03e2a63 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -1476,8 +1476,8 @@ static inline void runq_remove(struct csched2_unit *svc)
  list_del_init(&svc->runq_elem);
  }
  
-void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_unit *svc,

-  s_time_t now);
+static void burn_credits(struct csched2_runqueue_data *rqd,
+ struct csched2_unit *svc, s_time_t now);
  
  static inline void

  tickle_cpu(unsigned int cpu, struct csched2_runqueue_data *rqd)
@@ -1855,8 +1855,8 @@ static void reset_credit(int cpu, s_time_t now, struct 
csched2_unit *snext)
  /* No need to resort runqueue, as everyone's order should be the same. */
  }
  
-void burn_credits(struct csched2_runqueue_data *rqd,

-  struct csched2_unit *svc, s_time_t now)
+static void burn_credits(struct csched2_runqueue_data *rqd,
+ struct csched2_unit *svc, s_time_t now)
  {
  s_time_t delta;
  


--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)

[PATCH for-4.19 0/2] Xen: Final MISRA R8.3 fixes

[Andrew Cooper]

This gets Xen clean to R8.3 and marks it as blocking in Gitlab.

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

Andrew Cooper (2):
  x86/pagewalk: Address MISRA R8.3 violation in guest_walk_tables()
  xen/multicall: Change nr_calls to uniformly be unsigned long

 automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
 xen/arch/x86/include/asm/guest_pt.h   | 2 +-
 xen/common/multicall.c| 4 ++--
 xen/include/hypercall-defs.c  | 4 ++--
 xen/include/public/xen.h  | 2 +-
 5 files changed, 7 insertions(+), 6 deletions(-)


base-commit: 9e7c26ad8532c3efda174dee5ab8bdbeef1e4f6d
-- 
2.39.2

[PATCH 2/2] xen/multicall: Change nr_calls to uniformly be unsigned long

[Andrew Cooper]

Right now, the non-compat declaration and definition of do_multicall()
differing types for the nr_calls parameter.

This is a MISRA rule 8.3 violation, but it's also time-bomb waiting for the
first 128bit architecture (RISC-V looks as if it might get there first).

Worse, the type chosen here has a side effect of truncating the guest
parameter, because Xen still doesn't have a clean hypercall ABI definition.

Switch uniformly to using unsigned long.

This addresses the MISRA violation, and while it is a guest-visible ABI
change, it's only in the corner case where the guest kernel passed a
bogus-but-correct-when-truncated value.  I can't find any any users of
mutilcall which pass a bad size to begin with, so this should have no
practical effect on guests.

In fact, this brings the behaviour of multicalls more in line with the header
description of how it behaves.

With this fix, Xen is now fully clean to Rule 8.3, so mark it so.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Roberto Bagnara 
CC: consult...@bugseng.com 
CC: Oleksii Kurochko 

I know this isn't going to be universally liked, but we need to do something,
and this is my very strong vote for the least bad way out of the current mess.
---
 automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
 xen/common/multicall.c| 4 ++--
 xen/include/hypercall-defs.c  | 4 ++--
 xen/include/public/xen.h  | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl 
b/automation/eclair_analysis/ECLAIR/tagging.ecl
index b829655ca0bc..3d06a1aad410 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -45,6 +45,7 @@ MC3R1.R7.2||
 MC3R1.R7.4||
 MC3R1.R8.1||
 MC3R1.R8.2||
+MC3R1.R8.3||
 MC3R1.R8.5||
 MC3R1.R8.6||
 MC3R1.R8.8||
diff --git a/xen/common/multicall.c b/xen/common/multicall.c
index 1f0cc4cb267c..ce394c5efcfe 100644
--- a/xen/common/multicall.c
+++ b/xen/common/multicall.c
@@ -34,11 +34,11 @@ static void trace_multicall_call(multicall_entry_t *call)
 }
 
 ret_t do_multicall(
-XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, uint32_t nr_calls)
+XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, unsigned long 
nr_calls)
 {
 struct vcpu *curr = current;
 struct mc_state *mcs = &curr->mc_state;
-uint32_t i;
+unsigned longi;
 int  rc = 0;
 enum mc_disposition disp = mc_continue;
 
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 47c093acc84d..7720a29ade0b 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -135,7 +135,7 @@ xenoprof_op(int op, void *arg)
 #ifdef CONFIG_COMPAT
 prefix: compat
 set_timer_op(uint32_t lo, uint32_t hi)
-multicall(multicall_entry_compat_t *call_list, uint32_t nr_calls)
+multicall(multicall_entry_compat_t *call_list, unsigned long nr_calls)
 memory_op(unsigned int cmd, void *arg)
 #ifdef CONFIG_IOREQ_SERVER
 dm_op(domid_t domid, unsigned int nr_bufs, void *bufs)
@@ -172,7 +172,7 @@ console_io(unsigned int cmd, unsigned int count, char 
*buffer)
 vm_assist(unsigned int cmd, unsigned int type)
 event_channel_op(int cmd, void *arg)
 mmuext_op(mmuext_op_t *uops, unsigned int count, unsigned int *pdone, unsigned 
int foreigndom)
-multicall(multicall_entry_t *call_list, unsigned int nr_calls)
+multicall(multicall_entry_t *call_list, unsigned long nr_calls)
 #ifdef CONFIG_PV
 mmu_update(mmu_update_t *ureqs, unsigned int count, unsigned int *pdone, 
unsigned int foreigndom)
 stack_switch(unsigned long ss, unsigned long esp)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b47d48d0e2d6..e051f989a5ca 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -623,7 +623,7 @@ DEFINE_XEN_GUEST_HANDLE(mmu_update_t);
 /*
  * ` enum neg_errnoval
  * ` HYPERVISOR_multicall(multicall_entry_t call_list[],
- * `  uint32_t nr_calls);
+ * `  unsigned long nr_calls);
  *
  * NB. The fields are logically the natural register size for this
  * architecture. In cases where xen_ulong_t is larger than this then
-- 
2.39.2

[PATCH 1/2] x86/pagewalk: Address MISRA R8.3 violation in guest_walk_tables()

[Andrew Cooper]

Commit 4c5d78a10dc8 ("x86/pagewalk: Re-implement the pagetable walker")
intentionally renamed guest_walk_tables()'s 'pfec' parameter to 'walk' because
it's not a PageFault Error Code, despite the name of some of the constants
passed in.  Sadly the constants-cleanup I've been meaning to do since then
still hasn't come to pass.

Update the declaration to match, to placate MISRA.

Fixes: 4c5d78a10dc8 ("x86/pagewalk: Re-implement the pagetable walker")
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Roberto Bagnara 
CC: consult...@bugseng.com 
CC: Oleksii Kurochko 
---
 xen/arch/x86/include/asm/guest_pt.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/include/asm/guest_pt.h 
b/xen/arch/x86/include/asm/guest_pt.h
index bc312343cdf1..7b0c9b005c1f 100644
--- a/xen/arch/x86/include/asm/guest_pt.h
+++ b/xen/arch/x86/include/asm/guest_pt.h
@@ -422,7 +422,7 @@ static inline unsigned int guest_walk_to_page_order(const 
walk_t *gw)
 
 bool
 guest_walk_tables(const struct vcpu *v, struct p2m_domain *p2m,
-  unsigned long va, walk_t *gw, uint32_t pfec,
+  unsigned long va, walk_t *gw, uint32_t walk,
   gfn_t top_gfn, mfn_t top_mfn, void *top_map);
 
 /* Pretty-print the contents of a guest-walk */
-- 
2.39.2

[PATCH 1/3] xen/riscv: Drop legacy __ro_after_init definition

[Andrew Cooper]

Hide the legacy __ro_after_init definition in xen/cache.h for RISC-V, to avoid
its use creeping in.  Only mm.c needs adjusting as a consequence

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 

https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1342686294
---
 xen/arch/riscv/mm.c | 2 +-
 xen/include/xen/cache.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 053f043a3d2a..3ebaf6da01cc 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,11 +1,11 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/xen/include/xen/cache.h b/xen/include/xen/cache.h
index 55456823c543..82a3ba38e3e7 100644
--- a/xen/include/xen/cache.h
+++ b/xen/include/xen/cache.h
@@ -15,7 +15,9 @@
 #define __cacheline_aligned __attribute__((__aligned__(SMP_CACHE_BYTES)))
 #endif
 
+#if defined(CONFIG_ARM) || defined(CONFIG_X86) || defined(CONFIG_PPC64)
 /* TODO: Phase out the use of this via cache.h */
 #define __ro_after_init __section(".data.ro_after_init")
+#endif
 
 #endif /* __LINUX_CACHE_H */
-- 
2.39.2

[PATCH 3/3] xen/ppc: Avoid using the legacy __read_mostly/__ro_after_init definitions

[Andrew Cooper]

RISC-V wants to introduce a full build of Xen without using the legacy
definitions.  PPC64 has the most minimal full build of Xen right now, so make
it compile without the legacy definitions.

Mostly this is just including xen/sections.h in a variety of common files.  In
a couple of cases, we can drop an inclusion of {xen,asm}/cache.h, but almost
all files get the definitions transitively.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 

https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1342714126
---
 xen/arch/ppc/include/asm/cache.h | 3 ---
 xen/arch/ppc/mm-radix.c  | 1 +
 xen/arch/ppc/stubs.c | 1 +
 xen/common/argo.c| 1 +
 xen/common/cpu.c | 1 +
 xen/common/debugtrace.c  | 1 +
 xen/common/domain.c  | 1 +
 xen/common/event_channel.c   | 2 ++
 xen/common/keyhandler.c  | 1 +
 xen/common/memory.c  | 1 +
 xen/common/page_alloc.c  | 1 +
 xen/common/pdx.c | 1 +
 xen/common/radix-tree.c  | 1 +
 xen/common/random.c  | 2 +-
 xen/common/rcupdate.c| 1 +
 xen/common/sched/core.c  | 1 +
 xen/common/sched/cpupool.c   | 1 +
 xen/common/sched/credit.c| 1 +
 xen/common/sched/credit2.c   | 1 +
 xen/common/shutdown.c| 1 +
 xen/common/spinlock.c| 1 +
 xen/common/timer.c   | 1 +
 xen/common/version.c | 3 +--
 xen/common/virtual_region.c  | 1 +
 xen/common/vmap.c| 2 +-
 xen/drivers/char/console.c   | 1 +
 xen/drivers/char/ns16550.c   | 1 +
 xen/drivers/char/serial.c| 2 +-
 xen/include/xen/cache.h  | 2 +-
 xen/include/xen/hypfs.h  | 1 +
 30 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/xen/arch/ppc/include/asm/cache.h b/xen/arch/ppc/include/asm/cache.h
index 13c0bf3242c8..8a0a6b7b1756 100644
--- a/xen/arch/ppc/include/asm/cache.h
+++ b/xen/arch/ppc/include/asm/cache.h
@@ -3,7 +3,4 @@
 #ifndef _ASM_PPC_CACHE_H
 #define _ASM_PPC_CACHE_H
 
-/* TODO: Phase out the use of this via cache.h */
-#define __read_mostly __section(".data.read_mostly")
-
 #endif /* _ASM_PPC_CACHE_H */
diff --git a/xen/arch/ppc/mm-radix.c b/xen/arch/ppc/mm-radix.c
index ab5a10695c5f..0a47959e64f2 100644
--- a/xen/arch/ppc/mm-radix.c
+++ b/xen/arch/ppc/mm-radix.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c
index a10691165b1b..0e7a26dadbc1 100644
--- a/xen/arch/ppc/stubs.c
+++ b/xen/arch/ppc/stubs.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/argo.c b/xen/common/argo.c
index 901f41eb2dbe..df19006744a3 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 6e35b114c080..f09af0444b6a 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/common/debugtrace.c b/xen/common/debugtrace.c
index a272e5e43761..ca883ad9198d 100644
--- a/xen/common/debugtrace.c
+++ b/xen/common/debugtrace.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 67cadb7c3f4f..3db0e0b793f9 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a67feff98976..822b2c982489 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 
 #include 
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 127ca506965c..674e7be39e9d 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/memory.c b/xen/common/memory.c
index de2cc7ad92a5..a6f2f6d1b348 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 054b7edb3989..33c8c917d984 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -134,6 +134,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
index d3d63b075032..b8384e6189df 100644
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * Maximum (non-inclusive) u

[PATCH 2/3] xen/ppc: Adjust ppc64_defconfig

[Andrew Cooper]

All of CONFIG_SCHED_*, and CONFIG_HYPFS build fine.

Add a stub for share_xen_page_with_guest(), which is all that is necessary to
make CONFIG_TRACEBUFFER build.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Shawn Anastasio 
CC: Oleksii Kurochko 
CC: George Dunlap 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 

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

This is in aid of getting wider compiler coverage with the subseqeuent patch
---
 xen/arch/ppc/configs/ppc64_defconfig | 6 --
 xen/arch/ppc/stubs.c | 6 ++
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/ppc/configs/ppc64_defconfig 
b/xen/arch/ppc/configs/ppc64_defconfig
index 48a053237afd..4924d881a27c 100644
--- a/xen/arch/ppc/configs/ppc64_defconfig
+++ b/xen/arch/ppc/configs/ppc64_defconfig
@@ -1,9 +1,3 @@
-# CONFIG_SCHED_CREDIT is not set
-# CONFIG_SCHED_RTDS is not set
-# CONFIG_SCHED_NULL is not set
-# CONFIG_SCHED_ARINC653 is not set
-# CONFIG_TRACEBUFFER is not set
-# CONFIG_HYPFS is not set
 # CONFIG_GRANT_TABLE is not set
 # CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
 # CONFIG_MEM_ACCESS is not set
diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c
index 923f0e7b2095..a10691165b1b 100644
--- a/xen/arch/ppc/stubs.c
+++ b/xen/arch/ppc/stubs.c
@@ -333,3 +333,9 @@ void udelay(unsigned long usecs)
 {
 BUG_ON("unimplemented");
 }
+
+void share_xen_page_with_guest(struct page_info *page, struct domain *d,
+   enum XENSHARE_flags flags)
+{
+BUG_ON("unimplemented");
+}
-- 
2.39.2

[PATCH for-4.19? 0/3] xen: build adjustments for __read_mostly/__ro_after_init

[Andrew Cooper]

In aid of getting the RISC-V build working without introducing more technical
debt.  It's done by making PPC shed it's copy of said technical debt.

Build tested quite thoroughly, including in Gitlab.

Andrew Cooper (3):
  xen/riscv: Drop legacy __ro_after_init definition
  xen/ppc: Adjust ppc64_defconfig
  xen/ppc: Avoid using the legacy __read_mostly/__ro_after_init
definitions

 xen/arch/ppc/configs/ppc64_defconfig | 6 --
 xen/arch/ppc/include/asm/cache.h | 3 ---
 xen/arch/ppc/mm-radix.c  | 1 +
 xen/arch/ppc/stubs.c | 7 +++
 xen/arch/riscv/mm.c  | 2 +-
 xen/common/argo.c| 1 +
 xen/common/cpu.c | 1 +
 xen/common/debugtrace.c  | 1 +
 xen/common/domain.c  | 1 +
 xen/common/event_channel.c   | 2 ++
 xen/common/keyhandler.c  | 1 +
 xen/common/memory.c  | 1 +
 xen/common/page_alloc.c  | 1 +
 xen/common/pdx.c | 1 +
 xen/common/radix-tree.c  | 1 +
 xen/common/random.c  | 2 +-
 xen/common/rcupdate.c| 1 +
 xen/common/sched/core.c  | 1 +
 xen/common/sched/cpupool.c   | 1 +
 xen/common/sched/credit.c| 1 +
 xen/common/sched/credit2.c   | 1 +
 xen/common/shutdown.c| 1 +
 xen/common/spinlock.c| 1 +
 xen/common/timer.c   | 1 +
 xen/common/version.c | 3 +--
 xen/common/virtual_region.c  | 1 +
 xen/common/vmap.c| 2 +-
 xen/drivers/char/console.c   | 1 +
 xen/drivers/char/ns16550.c   | 1 +
 xen/drivers/char/serial.c| 2 +-
 xen/include/xen/cache.h  | 2 ++
 xen/include/xen/hypfs.h  | 1 +
 32 files changed, 38 insertions(+), 15 deletions(-)

-- 
2.39.2

[XEN PATCH v2] common/sched: address a violation of MISRA C Rule 8.8

[victorm.lira]

From: Victor Lira 

Rule 8.8: "The static storage class specifier shall be used in all
declarations of objects and functions that have internal linkage"

This patch fixes this by adding the static specifier.
No functional changes.

Reported-by: Stewart Hildebrand stewart.hildebr...@amd.com
Signed-off-by: Victor Lira 
Acked-by: George Dunlap 
---
Changes from v1:
- adjust indentation and line width.
---
Cc: George Dunlap 
Cc: Dario Faggioli 
Cc: Juergen Gross 
Cc: xen-devel@lists.xenproject.org
---
 xen/common/sched/credit2.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 685929c290..b4e03e2a63 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -1476,8 +1476,8 @@ static inline void runq_remove(struct csched2_unit *svc)
 list_del_init(&svc->runq_elem);
 }
 
-void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_unit *svc,
-  s_time_t now);
+static void burn_credits(struct csched2_runqueue_data *rqd,
+ struct csched2_unit *svc, s_time_t now);
 
 static inline void
 tickle_cpu(unsigned int cpu, struct csched2_runqueue_data *rqd)
@@ -1855,8 +1855,8 @@ static void reset_credit(int cpu, s_time_t now, struct 
csched2_unit *snext)
 /* No need to resort runqueue, as everyone's order should be the same. */
 }
 
-void burn_credits(struct csched2_runqueue_data *rqd,
-  struct csched2_unit *svc, s_time_t now)
+static void burn_credits(struct csched2_runqueue_data *rqd,
+ struct csched2_unit *svc, s_time_t now)
 {
 s_time_t delta;
 
-- 
2.37.6

[PATCH 1/2] Add libfuzzer target to fuzz/x86_instruction_emulator

[Tamas K Lengyel]

This target enables integration into oss-fuzz.

Signed-off-by: Tamas K Lengyel 
---
 tools/fuzz/x86_instruction_emulator/Makefile| 10 --
 tools/fuzz/x86_instruction_emulator/fuzz-emul.c |  6 ++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/Makefile 
b/tools/fuzz/x86_instruction_emulator/Makefile
index 1e4c6b37f5..de5f1e7e30 100644
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 .PHONY: x86-insn-fuzz-all
 ifeq ($(CONFIG_X86_64),y)
-x86-insn-fuzz-all: x86-insn-fuzzer.a fuzz-emul.o afl
+x86-insn-fuzz-all: x86-insn-fuzzer.a fuzz-emul.o afl libfuzzer
 else
 x86-insn-fuzz-all:
 endif
@@ -58,6 +58,9 @@ afl-harness: afl-harness.o $(OBJS) cpuid.o wrappers.o
 afl-harness-cov: afl-harness-cov.o $(patsubst %.o,%-cov.o,$(OBJS)) cpuid.o 
wrappers.o
$(CC) $(CFLAGS) $(GCOV_FLAGS) $(addprefix 
-Wl$(comma)--wrap=,$(WRAPPED)) $^ -o $@
 
+libfuzzer-harness: $(OBJS) cpuid.o
+   $(CC) $(CFLAGS) $(LIB_FUZZING_ENGINE) -fsanitize=fuzzer $^ -o $@
+
 # Common targets
 .PHONY: all
 all: x86-insn-fuzz-all
@@ -67,7 +70,7 @@ distclean: clean
 
 .PHONY: clean
 clean:
-   rm -f *.a *.o $(DEPS_RM) afl-harness afl-harness-cov *.gcda *.gcno 
*.gcov
+   rm -f *.a *.o $(DEPS_RM) afl-harness afl-harness-cov *.gcda *.gcno 
*.gcov libfuzzer-harness
rm -rf x86_emulate x86-emulate.c x86-emulate.h wrappers.c cpuid.c
 
 .PHONY: install
@@ -81,4 +84,7 @@ afl: afl-harness
 .PHONY: afl-cov
 afl-cov: afl-harness-cov
 
+.PHONY: libfuzzer
+libfuzzer: libfuzzer-harness
+
 -include $(DEPS_INCLUDE)
diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c 
b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index eeeb6931f4..2ba9ca9e0b 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -906,14 +906,12 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t 
size)
 
 if ( size <= DATA_OFFSET )
 {
-printf("Input too small\n");
-return 1;
+return -1;
 }
 
 if ( size > FUZZ_CORPUS_SIZE )
 {
-printf("Input too large\n");
-return 1;
+return -1;
 }
 
 memcpy(&input, data_p, size);
-- 
2.34.1

[PATCH 2/2] Add scripts/oss-fuzz/build.sh

[Tamas K Lengyel]

The build integration script for oss-fuzz targets.

Signed-off-by: Tamas K Lengyel 
---
 scripts/oss-fuzz/build.sh | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100755 scripts/oss-fuzz/build.sh

diff --git a/scripts/oss-fuzz/build.sh b/scripts/oss-fuzz/build.sh
new file mode 100755
index 00..48528bbfc2
--- /dev/null
+++ b/scripts/oss-fuzz/build.sh
@@ -0,0 +1,22 @@
+#!/bin/bash -eu
+# Copyright 2024 Google LLC
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#  http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+
+cd xen
+./configure clang=y --disable-stubdom --disable-pvshim --disable-docs 
--disable-xen
+make clang=y -C tools/include
+make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness
+cp tools/fuzz/x86_instruction_emulator/libfuzzer-harness 
$OUT/x86_instruction_emulator
-- 
2.34.1

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

[osstest service owner]

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

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  9e7c26ad8532c3efda174dee5ab8bdbeef1e4f6d
baseline version:
 xen  62071a1c16c4dbe765491e58e456fd3a19b33298

Last test of basis   186435  2024-06-20 14:00:22 Z1 days
Testing same since   186447  2024-06-21 15:04:10 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Matthew Barnes 

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
   62071a1c16..9e7c26ad85  9e7c26ad8532c3efda174dee5ab8bdbeef1e4f6d -> smoke

[PATCH for-4.19 v3 3/4] x86/shadow: Rework trace_shadow_emulate_other() as sh_trace_gfn_va()

[Andrew Cooper]

sh_trace_gfn_va() is very similar to sh_trace_gl1e_va(), and a rather shorter
name than trace_shadow_emulate_other().

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: George Dunlap 
CC: Oleksii Kurochko 

v2:
 * New
v3:
 * Retain __packed.
---
 xen/arch/x86/mm/shadow/multi.c | 38 --
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 75250c6f0f7c..7f95d50be397 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2010,29 +2010,30 @@ static void sh_trace_gl1e_va(uint32_t event, 
guest_l1e_t gl1e, guest_va_t va)
 }
 }
 
-static inline void trace_shadow_emulate_other(u32 event,
- guest_va_t va,
- gfn_t gfn)
+/* Shadow trace event with a gfn, linear address and flags. */
+static void sh_trace_gfn_va(uint32_t event, gfn_t gfn, guest_va_t va)
 {
 if ( tb_init_done )
 {
 struct __packed {
-/* for PAE, guest_l1e may be 64 while guest_va may be 32;
-   so put it first for alignment sake. */
+/*
+ * For GUEST_PAGING_LEVELS=3 (PAE paging), gfn is 64 while
+ * guest_va is 32.  Put it first to avoid padding.
+ */
 #if GUEST_PAGING_LEVELS == 2
-u32 gfn;
+uint32_t gfn;
 #else
-u64 gfn;
+uint64_t gfn;
 #endif
 guest_va_t va;
-} d;
-
-event |= ((GUEST_PAGING_LEVELS-2)<<8);
-
-d.gfn=gfn_x(gfn);
-d.va = va;
+uint32_t flags;
+} d = {
+.gfn   = gfn_x(gfn),
+.va= va,
+.flags = this_cpu(trace_shadow_path_flags),
+};
 
-trace(event, sizeof(d), &d);
+sh_trace(event, sizeof(d), &d);
 }
 }
 
@@ -2603,8 +2604,7 @@ static int cf_check sh_page_fault(
   mfn_x(gmfn));
 perfc_incr(shadow_fault_emulate_failed);
 shadow_remove_all_shadows(d, gmfn);
-trace_shadow_emulate_other(TRC_SHADOW_EMULATE_UNSHADOW_USER,
-  va, gfn);
+sh_trace_gfn_va(TRC_SHADOW_EMULATE_UNSHADOW_USER, gfn, va);
 goto done;
 }
 
@@ -2683,8 +2683,7 @@ static int cf_check sh_page_fault(
 }
 #endif
 shadow_remove_all_shadows(d, gmfn);
-trace_shadow_emulate_other(TRC_SHADOW_EMULATE_UNSHADOW_EVTINJ,
-   va, gfn);
+sh_trace_gfn_va(TRC_SHADOW_EMULATE_UNSHADOW_EVTINJ, gfn, va);
 return EXCRET_fault_fixed;
 }
 
@@ -2739,8 +2738,7 @@ static int cf_check sh_page_fault(
  * though, this is a hint that this page should not be shadowed. */
 shadow_remove_all_shadows(d, gmfn);
 
-trace_shadow_emulate_other(TRC_SHADOW_EMULATE_UNSHADOW_UNHANDLED,
-   va, gfn);
+sh_trace_gfn_va(TRC_SHADOW_EMULATE_UNSHADOW_UNHANDLED, gfn, va);
 goto emulate_done;
 }
 
-- 
2.39.2

[PATCH for-4.19 v3 0/4] x86/shadow: Trace fixes and cleanup

[Andrew Cooper]

Patches 1-3 were my review feedback to Jan's patch 4.

For 4.19.  Patch 4 (the bugfix) was Release-Acked after I posted the series
(cleanup and rebased bugfix), which suggests your happy for it in principle,
but I can't treat that as an implict release ack on the whole series.

It's a tracing fix, so is minimal risk to the 4.19 release.

v3:
 * Retain __packed attribute.

Andrew Cooper (3):
  x86/shadow: Rework trace_shadow_gen() into sh_trace_va()
  x86/shadow: Introduce sh_trace_gl1e_va()
  x86/shadow: Rework trace_shadow_emulate_other() as sh_trace_gfn_va()

Jan Beulich (1):
  x86/shadow: Don't leave trace record field uninitialized

 xen/arch/x86/mm/shadow/multi.c | 144 ++---
 1 file changed, 60 insertions(+), 84 deletions(-)


base-commit: 9e7c26ad8532c3efda174dee5ab8bdbeef1e4f6d
-- 
2.39.2

[PATCH for-4.19 v3 2/4] x86/shadow: Introduce sh_trace_gl1e_va()

[Andrew Cooper]

trace_shadow_fixup() and trace_not_shadow_fault() both write out identical
trace records.  Reimplement them in terms of a common sh_trace_gl1e_va().

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: George Dunlap 
CC: Oleksii Kurochko 

v2:
 * New
v3:
 * Retain the __packed to avoid introducing tail padding
---
 xen/arch/x86/mm/shadow/multi.c | 57 ++
 1 file changed, 16 insertions(+), 41 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 1775952d7e18..75250c6f0f7c 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1987,51 +1987,26 @@ static void sh_trace_va(uint32_t event, guest_va_t va)
 sh_trace(event, sizeof(va), &va);
 }
 
-static inline void trace_shadow_fixup(guest_l1e_t gl1e,
-  guest_va_t va)
+/* Shadow trace event with a gl1e, linear address and flags. */
+static void sh_trace_gl1e_va(uint32_t event, guest_l1e_t gl1e, guest_va_t va)
 {
 if ( tb_init_done )
 {
 struct __packed {
-/* for PAE, guest_l1e may be 64 while guest_va may be 32;
-   so put it first for alignment sake. */
-guest_l1e_t gl1e;
-guest_va_t va;
-u32 flags;
-} d;
-u32 event;
-
-event = TRC_SHADOW_FIXUP | ((GUEST_PAGING_LEVELS-2)<<8);
-
-d.gl1e = gl1e;
-d.va = va;
-d.flags = this_cpu(trace_shadow_path_flags);
-
-trace(event, sizeof(d), &d);
-}
-}
-
-static inline void trace_not_shadow_fault(guest_l1e_t gl1e,
-  guest_va_t va)
-{
-if ( tb_init_done )
-{
-struct __packed {
-/* for PAE, guest_l1e may be 64 while guest_va may be 32;
-   so put it first for alignment sake. */
+/*
+ * For GUEST_PAGING_LEVELS=3 (PAE paging), guest_l1e is 64 while
+ * guest_va is 32.  Put it first to avoid padding.
+ */
 guest_l1e_t gl1e;
 guest_va_t va;
-u32 flags;
-} d;
-u32 event;
-
-event = TRC_SHADOW_NOT_SHADOW | ((GUEST_PAGING_LEVELS-2)<<8);
-
-d.gl1e = gl1e;
-d.va = va;
-d.flags = this_cpu(trace_shadow_path_flags);
-
-trace(event, sizeof(d), &d);
+uint32_t flags;
+} d = {
+.gl1e  = gl1e,
+.va= va,
+.flags = this_cpu(trace_shadow_path_flags),
+};
+
+sh_trace(event, sizeof(d), &d);
 }
 }
 
@@ -2603,7 +2578,7 @@ static int cf_check sh_page_fault(
 d->arch.paging.log_dirty.fault_count++;
 sh_reset_early_unshadow(v);
 
-trace_shadow_fixup(gw.l1e, va);
+sh_trace_gl1e_va(TRC_SHADOW_FIXUP, gw.l1e, va);
  done: __maybe_unused;
 sh_audit_gw(v, &gw);
 SHADOW_PRINTK("fixed\n");
@@ -2857,7 +2832,7 @@ static int cf_check sh_page_fault(
 put_gfn(d, gfn_x(gfn));
 
 propagate:
-trace_not_shadow_fault(gw.l1e, va);
+sh_trace_gl1e_va(TRC_SHADOW_NOT_SHADOW, gw.l1e, va);
 
 return 0;
 }
-- 
2.39.2

[PATCH for-4.19 v3 1/4] x86/shadow: Rework trace_shadow_gen() into sh_trace_va()

[Andrew Cooper]

The ((GUEST_PAGING_LEVELS - 2) << 8) expression in the event field is common
to all shadow trace events, so introduce sh_trace() as a very thin wrapper
around trace().

Then, rename trace_shadow_gen() to sh_trace_va() to better describe what it is
doing, and to be more consistent with later cleanup.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: George Dunlap 
CC: Oleksii Kurochko 

v2:
 * New
---
 xen/arch/x86/mm/shadow/multi.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index bcd02b2d0037..1775952d7e18 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1974,13 +1974,17 @@ typedef u32 guest_va_t;
 typedef u32 guest_pa_t;
 #endif
 
-static inline void trace_shadow_gen(u32 event, guest_va_t va)
+/* Shadow trace event with GUEST_PAGING_LEVELS folded into the event field. */
+static void sh_trace(uint32_t event, unsigned int extra, const void 
*extra_data)
+{
+trace(event | ((GUEST_PAGING_LEVELS - 2) << 8), extra, extra_data);
+}
+
+/* Shadow trace event with the guest's linear address. */
+static void sh_trace_va(uint32_t event, guest_va_t va)
 {
 if ( tb_init_done )
-{
-event |= (GUEST_PAGING_LEVELS-2)<<8;
-trace(event, sizeof(va), &va);
-}
+sh_trace(event, sizeof(va), &va);
 }
 
 static inline void trace_shadow_fixup(guest_l1e_t gl1e,
@@ -2239,7 +2243,7 @@ static int cf_check sh_page_fault(
 sh_reset_early_unshadow(v);
 perfc_incr(shadow_fault_fast_gnp);
 SHADOW_PRINTK("fast path not-present\n");
-trace_shadow_gen(TRC_SHADOW_FAST_PROPAGATE, va);
+sh_trace_va(TRC_SHADOW_FAST_PROPAGATE, va);
 return 0;
 }
 #ifdef CONFIG_HVM
@@ -2250,7 +2254,7 @@ static int cf_check sh_page_fault(
 perfc_incr(shadow_fault_fast_mmio);
 SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
 sh_reset_early_unshadow(v);
-trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
+sh_trace_va(TRC_SHADOW_FAST_MMIO, va);
 return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT, access)
? EXCRET_fault_fixed : 0;
 #else
@@ -2265,7 +2269,7 @@ static int cf_check sh_page_fault(
  * Retry and let the hardware give us the right fault next time. */
 perfc_incr(shadow_fault_fast_fail);
 SHADOW_PRINTK("fast path false alarm!\n");
-trace_shadow_gen(TRC_SHADOW_FALSE_FAST_PATH, va);
+sh_trace_va(TRC_SHADOW_FALSE_FAST_PATH, va);
 return EXCRET_fault_fixed;
 }
 }
@@ -2481,7 +2485,7 @@ static int cf_check sh_page_fault(
 #endif
 paging_unlock(d);
 put_gfn(d, gfn_x(gfn));
-trace_shadow_gen(TRC_SHADOW_DOMF_DYING, va);
+sh_trace_va(TRC_SHADOW_DOMF_DYING, va);
 return 0;
 }
 
@@ -2569,7 +2573,7 @@ static int cf_check sh_page_fault(
 put_gfn(d, gfn_x(gfn));
 
 perfc_incr(shadow_fault_mmio);
-trace_shadow_gen(TRC_SHADOW_MMIO, va);
+sh_trace_va(TRC_SHADOW_MMIO, va);
 
 return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT, access)
? EXCRET_fault_fixed : 0;
-- 
2.39.2

[PATCH for-4.19 v3 4/4] x86/shadow: Don't leave trace record field uninitialized

[Andrew Cooper]

From: Jan Beulich 

The emulation_count field is set only conditionally right now. Convert
all field setting to an initializer, thus guaranteeing that field to be
set to 0 (default initialized) when GUEST_PAGING_LEVELS != 3.

Rework trace_shadow_emulate() to be consistent with the other trace helpers.

Coverity-ID: 1598430
Fixes: 9a86ac1aa3d2 ("xentrace 5/7: Additional tracing for the shadow code")
Signed-off-by: Jan Beulich 
Signed-off-by: Andrew Cooper 
Acked-by: Roger Pau Monné 
Acked-by: Jan Beulich 
Release-acked-by: Oleksii Kurochko 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: George Dunlap 
CC: Oleksii Kurochko 

v2:
 * Rebase over packing/sh_trace() cleanup.
---
 xen/arch/x86/mm/shadow/multi.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 7f95d50be397..71a2673682f4 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2063,30 +2063,29 @@ static void cf_check trace_emulate_write_val(
 #endif
 }
 
-static inline void trace_shadow_emulate(guest_l1e_t gl1e, unsigned long va)
+static inline void sh_trace_emulate(guest_l1e_t gl1e, unsigned long va)
 {
 if ( tb_init_done )
 {
 struct __packed {
-/* for PAE, guest_l1e may be 64 while guest_va may be 32;
-   so put it first for alignment sake. */
+/*
+ * For GUEST_PAGING_LEVELS=3 (PAE paging), guest_l1e is 64 while
+ * guest_va is 32.  Put it first to avoid padding.
+ */
 guest_l1e_t gl1e, write_val;
 guest_va_t va;
 uint32_t flags:29, emulation_count:3;
-} d;
-u32 event;
-
-event = TRC_SHADOW_EMULATE | ((GUEST_PAGING_LEVELS-2)<<8);
-
-d.gl1e = gl1e;
-d.write_val.l1 = this_cpu(trace_emulate_write_val);
-d.va = va;
+} d = {
+.gl1e = gl1e,
+.write_val.l1 = this_cpu(trace_emulate_write_val),
+.va = va,
 #if GUEST_PAGING_LEVELS == 3
-d.emulation_count = this_cpu(trace_extra_emulation_count);
+.emulation_count = this_cpu(trace_extra_emulation_count),
 #endif
-d.flags = this_cpu(trace_shadow_path_flags);
+.flags = this_cpu(trace_shadow_path_flags),
+};
 
-trace(event, sizeof(d), &d);
+sh_trace(TRC_SHADOW_EMULATE, sizeof(d), &d);
 }
 }
 #endif /* CONFIG_HVM */
@@ -2815,7 +2814,7 @@ static int cf_check sh_page_fault(
 }
 #endif /* PAE guest */
 
-trace_shadow_emulate(gw.l1e, va);
+sh_trace_emulate(gw.l1e, va);
  emulate_done:
 SHADOW_PRINTK("emulated\n");
 return EXCRET_fault_fixed;
-- 
2.39.2

Re: [PATCH for-4.19 v2] tools/xl: Open xldevd.log with O_CLOEXEC

[Andrew Cooper]

On 21/06/2024 5:55 pm, Anthony PERARD wrote:
> On Fri, Jun 21, 2024 at 05:16:56PM +0100, Andrew Cooper wrote:
>> `xl devd` has been observed leaking /var/log/xldevd.log into children.
>>
>> Note this is specifically safe; dup2() leaves O_CLOEXEC disabled on newfd, so
>> after setting up stdout/stderr, it's only the logfile fd which will close on
>> exec().
>>
>> Link: https://github.com/QubesOS/qubes-issues/issues/8292
>> Reported-by: Demi Marie Obenour 
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Anthony PERARD 
>> CC: Juergen Gross 
>> CC: Demi Marie Obenour 
>> CC: Marek Marczykowski-Górecki 
>> CC: Oleksii Kurochko 
>>
>> Also entirely speculative based on the QubesOS ticket.
>>
>> v2:
>>  * Extend the commit message to explain why stdout/stderr aren't closed by
>>this change
>>
>> For 4.19.  This bugfix was posted earlier, but fell between the cracks.
>> ---
>>  tools/xl/xl_utils.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/xl/xl_utils.c b/tools/xl/xl_utils.c
>> index 17489d182954..060186db3a59 100644
>> --- a/tools/xl/xl_utils.c
>> +++ b/tools/xl/xl_utils.c
>> @@ -270,7 +270,7 @@ int do_daemonize(const char *name, const char *pidfile)
>>  exit(-1);
>>  }
>>  
>> -CHK_SYSCALL(logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND, 0644));
>> +CHK_SYSCALL(logfile = open(fullname, O_WRONLY | O_CREAT | O_APPEND | 
>> O_CLOEXEC, 0644));
> Everytime we use O_CLOEXEC, we add in the C file
> #ifndef O_CLOEXEC
> #define O_CLOEXEC 0
> #endif
> we don't need to do that anymore?
> Or I guess we'll see if someone complain when they try to build on an
> ancien version of Linux.
>
> Acked-by: Anthony PERARD 

Thanks.  I did originally have that ifdefary here, but then I noticed
that this isn't the first instance like this in xl, and I'm going to be
using that as a justification soon to explicitly drop support for Linux
< 2.6.23.

~Andrew

Re: [PATCH for-4.19 v2] tools/xl: Open xldevd.log with O_CLOEXEC

[Anthony PERARD]

On Fri, Jun 21, 2024 at 05:16:56PM +0100, Andrew Cooper wrote:
> `xl devd` has been observed leaking /var/log/xldevd.log into children.
>
> Note this is specifically safe; dup2() leaves O_CLOEXEC disabled on newfd, so
> after setting up stdout/stderr, it's only the logfile fd which will close on
> exec().
>
> Link: https://github.com/QubesOS/qubes-issues/issues/8292
> Reported-by: Demi Marie Obenour 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Anthony PERARD 
> CC: Juergen Gross 
> CC: Demi Marie Obenour 
> CC: Marek Marczykowski-Górecki 
> CC: Oleksii Kurochko 
>
> Also entirely speculative based on the QubesOS ticket.
>
> v2:
>  * Extend the commit message to explain why stdout/stderr aren't closed by
>this change
>
> For 4.19.  This bugfix was posted earlier, but fell between the cracks.
> ---
>  tools/xl/xl_utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/xl/xl_utils.c b/tools/xl/xl_utils.c
> index 17489d182954..060186db3a59 100644
> --- a/tools/xl/xl_utils.c
> +++ b/tools/xl/xl_utils.c
> @@ -270,7 +270,7 @@ int do_daemonize(const char *name, const char *pidfile)
>  exit(-1);
>  }
>
> -CHK_SYSCALL(logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND, 0644));
> +CHK_SYSCALL(logfile = open(fullname, O_WRONLY | O_CREAT | O_APPEND | 
> O_CLOEXEC, 0644));

Everytime we use O_CLOEXEC, we add in the C file
#ifndef O_CLOEXEC
#define O_CLOEXEC 0
#endif
we don't need to do that anymore?
Or I guess we'll see if someone complain when they try to build on an
ancien version of Linux.

Acked-by: Anthony PERARD 

Thanks,

--

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH for-4.19 0/4] xen/xlat: Improvements to compat hypercall checking

[Andrew Cooper]

On 15/04/2024 4:41 pm, Andrew Cooper wrote:
> This started off as patch 3, and grew somewhat.
>
> Patches 1-3 are simple and hopefully non-controversial.
>
> Patch 4 is an attempt to make the headers less fragile, but came with an
> unexpected complication.  Details in the patch.
>
> Andrew Cooper (4):
>   xen/xlat: Sort out whitespace
>   xen/xlat: Sort structs per file
>   xen/gnttab: Perform compat/native gnttab_query_size check

I'm timing out waiting for a justification on the whitespace comment.

Oleksii: Can I get a release ack on this please?  Patch 3 is the main
bugfix, which is the insertion of a missing build-time cross-check, so
it's very low risk for the release.

Patch 4 was always RFC and not intended to go in as-was.

~Andrew

Re: [PATCH for-4.19 v2] tools/xl: Open xldevd.log with O_CLOEXEC

[Marek Marczykowski-Górecki]

On Fri, Jun 21, 2024 at 05:16:56PM +0100, Andrew Cooper wrote:
> `xl devd` has been observed leaking /var/log/xldevd.log into children.
> 
> Note this is specifically safe; dup2() leaves O_CLOEXEC disabled on newfd, so
> after setting up stdout/stderr, it's only the logfile fd which will close on
> exec().
> 
> Link: https://github.com/QubesOS/qubes-issues/issues/8292
> Reported-by: Demi Marie Obenour 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Marek Marczykowski-Górecki 

> ---
> CC: Anthony PERARD 
> CC: Juergen Gross 
> CC: Demi Marie Obenour 
> CC: Marek Marczykowski-Górecki 
> CC: Oleksii Kurochko 
> 
> Also entirely speculative based on the QubesOS ticket.
> 
> v2:
>  * Extend the commit message to explain why stdout/stderr aren't closed by
>this change
> 
> For 4.19.  This bugfix was posted earlier, but fell between the cracks.
> ---
>  tools/xl/xl_utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/xl/xl_utils.c b/tools/xl/xl_utils.c
> index 17489d182954..060186db3a59 100644
> --- a/tools/xl/xl_utils.c
> +++ b/tools/xl/xl_utils.c
> @@ -270,7 +270,7 @@ int do_daemonize(const char *name, const char *pidfile)
>  exit(-1);
>  }
>  
> -CHK_SYSCALL(logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND, 0644));
> +CHK_SYSCALL(logfile = open(fullname, O_WRONLY | O_CREAT | O_APPEND | 
> O_CLOEXEC, 0644));
>  free(fullname);
>  assert(logfile >= 3);
>  
> -- 
> 2.39.2
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature

[PATCH for-4.19 v2] tools/xl: Open xldevd.log with O_CLOEXEC

[Andrew Cooper]

`xl devd` has been observed leaking /var/log/xldevd.log into children.

Note this is specifically safe; dup2() leaves O_CLOEXEC disabled on newfd, so
after setting up stdout/stderr, it's only the logfile fd which will close on
exec().

Link: https://github.com/QubesOS/qubes-issues/issues/8292
Reported-by: Demi Marie Obenour 
Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Juergen Gross 
CC: Demi Marie Obenour 
CC: Marek Marczykowski-Górecki 
CC: Oleksii Kurochko 

Also entirely speculative based on the QubesOS ticket.

v2:
 * Extend the commit message to explain why stdout/stderr aren't closed by
   this change

For 4.19.  This bugfix was posted earlier, but fell between the cracks.
---
 tools/xl/xl_utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/xl/xl_utils.c b/tools/xl/xl_utils.c
index 17489d182954..060186db3a59 100644
--- a/tools/xl/xl_utils.c
+++ b/tools/xl/xl_utils.c
@@ -270,7 +270,7 @@ int do_daemonize(const char *name, const char *pidfile)
 exit(-1);
 }
 
-CHK_SYSCALL(logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND, 0644));
+CHK_SYSCALL(logfile = open(fullname, O_WRONLY | O_CREAT | O_APPEND | 
O_CLOEXEC, 0644));
 free(fullname);
 assert(logfile >= 3);
 
-- 
2.39.2

[RFC PATCH v2] iommu/xen: Add Xen PV-IOMMU driver

[TSnake41]

From: Teddy Astie 

In the context of Xen, Linux runs as Dom0 and doesn't have access to the
machine IOMMU. Although, a IOMMU is mandatory to use some kernel features
such as VFIO or DMA protection.

In Xen, we added a paravirtualized IOMMU with iommu_op hypercall in order to
allow Dom0 to implement such feature. This commit introduces a new IOMMU driver
that uses this new hypercall interface.

Signed-off-by Teddy Astie 
---
Changes since v1 :
* formatting changes
* applied Jan Beulich proposed changes : removed vim notes at end of pv-iommu.h
* applied Jason Gunthorpe proposed changes : use new ops and remove redundant
checks
---
 arch/x86/include/asm/xen/hypercall.h |   6 +
 drivers/iommu/Kconfig|   9 +
 drivers/iommu/Makefile   |   1 +
 drivers/iommu/xen-iommu.c| 489 +++
 include/xen/interface/memory.h   |  33 ++
 include/xen/interface/pv-iommu.h | 104 ++
 include/xen/interface/xen.h  |   1 +
 7 files changed, 643 insertions(+)
 create mode 100644 drivers/iommu/xen-iommu.c
 create mode 100644 include/xen/interface/pv-iommu.h

diff --git a/arch/x86/include/asm/xen/hypercall.h 
b/arch/x86/include/asm/xen/hypercall.h
index a2dd24947eb8..6b1857f27c14 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -490,6 +490,12 @@ HYPERVISOR_xenpmu_op(unsigned int op, void *arg)
return _hypercall2(int, xenpmu_op, op, arg);
 }
 
+static inline int
+HYPERVISOR_iommu_op(void *arg)
+{
+   return _hypercall1(int, iommu_op, arg);
+}
+
 static inline int
 HYPERVISOR_dm_op(
domid_t dom, unsigned int nr_bufs, struct xen_dm_op_buf *bufs)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 0af39bbbe3a3..242cefac77c9 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -480,6 +480,15 @@ config VIRTIO_IOMMU
 
  Say Y here if you intend to run this kernel as a guest.
 
+config XEN_IOMMU
+   bool "Xen IOMMU driver"
+   depends on XEN_DOM0
+   select IOMMU_API
+   help
+   Xen PV-IOMMU driver for Dom0.
+
+   Say Y here if you intend to run this guest as Xen Dom0.
+
 config SPRD_IOMMU
tristate "Unisoc IOMMU Support"
depends on ARCH_SPRD || COMPILE_TEST
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 542760d963ec..393afe22c901 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IOMMU_SVA) += iommu-sva.o
 obj-$(CONFIG_IOMMU_IOPF) += io-pgfault.o
 obj-$(CONFIG_SPRD_IOMMU) += sprd-iommu.o
 obj-$(CONFIG_APPLE_DART) += apple-dart.o
+obj-$(CONFIG_XEN_IOMMU) += xen-iommu.o
\ No newline at end of file
diff --git a/drivers/iommu/xen-iommu.c b/drivers/iommu/xen-iommu.c
new file mode 100644
index ..b765445d27cd
--- /dev/null
+++ b/drivers/iommu/xen-iommu.c
@@ -0,0 +1,489 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xen PV-IOMMU driver.
+ *
+ * Copyright (C) 2024 Vates SAS
+ *
+ * Author: Teddy Astie 
+ *
+ */
+
+#define pr_fmt(fmt)"xen-iommu: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_DESCRIPTION("Xen IOMMU driver");
+MODULE_AUTHOR("Teddy Astie ");
+MODULE_LICENSE("GPL");
+
+#define MSI_RANGE_START(0xfee0)
+#define MSI_RANGE_END  (0xfeef)
+
+#define XEN_IOMMU_PGSIZES   (0x1000)
+
+struct xen_iommu_domain {
+   struct iommu_domain domain;
+
+   u16 ctx_no; /* Xen PV-IOMMU context number */
+};
+
+static struct iommu_device xen_iommu_device;
+
+static uint32_t max_nr_pages;
+static uint64_t max_iova_addr;
+
+static spinlock_t lock;
+
+static inline struct xen_iommu_domain *to_xen_iommu_domain(struct iommu_domain 
*dom)
+{
+   return container_of(dom, struct xen_iommu_domain, domain);
+}
+
+static inline u64 addr_to_pfn(u64 addr)
+{
+   return addr >> 12;
+}
+
+static inline u64 pfn_to_addr(u64 pfn)
+{
+   return pfn << 12;
+}
+
+bool xen_iommu_capable(struct device *dev, enum iommu_cap cap)
+{
+   switch (cap) {
+   case IOMMU_CAP_CACHE_COHERENCY:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
+struct iommu_domain *xen_iommu_domain_alloc_paging(struct device *dev)
+{
+   struct xen_iommu_domain *domain;
+   int ret;
+
+   struct pv_iommu_op op = {
+   .ctx_no = 0,
+   .flags = 0,
+   .subop_id = IOMMUOP_alloc_context
+   };
+
+   ret = HYPERVISOR_iommu_op(&op);
+
+   if (ret) {
+   pr_err("Unable to create Xen IOMMU context (%d)", ret);
+   return ERR_PTR(ret);
+   }
+
+   domain = kzalloc(sizeof(*domain), GFP_KERNEL);
+
+   domain->ctx_no = op.ctx_no;
+
+   domain->domain.geometry.aperture_sta

Re: [XEN PATCH] tools/misc: xen-hvmcrash: Inject #DF instead of overwriting RIP

[Anthony PERARD]

On Mon, Jun 03, 2024 at 03:59:18PM +0100, Matthew Barnes wrote:
> diff --git a/tools/misc/xen-hvmcrash.c b/tools/misc/xen-hvmcrash.c
> index 1d058fa40a47..8ef1beb388f8 100644
> --- a/tools/misc/xen-hvmcrash.c
> +++ b/tools/misc/xen-hvmcrash.c
> @@ -38,22 +38,21 @@
>  #include 
>  #include 
>
> +#define XC_WANT_COMPAT_DEVICEMODEL_API
>  #include 
>  #include 
>  #include 
>  #include 

There's lots of headers that aren't used by the new codes and can be
removed. (They were probably way too many headers included when this
utility was introduced.)

> +for (vcpu_id = 0; vcpu_id <= dominfo.max_vcpu_id; vcpu_id++) {
> +printf("Injecting #DF to vcpu ID #%d...\n", vcpu_id);
> +ret = xc_hvm_inject_trap(xch, domid, vcpu_id,
> +X86_ABORT_DF,

In the definition of xendevicemodel_inject_event(), the comment say to
look at "enum x86_event_type" for possible event "type", but there's no
"#DF" type, can we add this new one there before using it? (It's going
to be something like X86_EVENTTYPE_*)

> +XEN_DMOP_EVENT_hw_exc, 0,
> +NULL, NULL);

The new code doesn't build, "NULL" aren't integers.

> +if (ret < 0) {
> +fprintf(stderr, "Could not inject #DF to vcpu ID #%d\n", 
> vcpu_id);
> +perror("xc_hvm_inject_trap");

Are you meant to print two error lines when there's an error? You can
also use strerror() to convert an "errno" to a string.

Also, perror() might print an error from fprintf() if that last one
failed.

Are you meant to keep inject into other vcpus even if one have failed?
Should `xen-hvmcrash` return success when it failed to inject the double
fault to all vcpus?

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

[XEN PATCH] automation/eclair: add more guidelines to the monitored set

[Federico Serafini]

Add more accepted guidelines to the monitored set to check them at each
commit.

Signed-off-by: Federico Serafini 
---
 automation/eclair_analysis/ECLAIR/monitored.ecl | 5 +
 1 file changed, 5 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl 
b/automation/eclair_analysis/ECLAIR/monitored.ecl
index 4daecb0c83..9ffaebbdc3 100644
--- a/automation/eclair_analysis/ECLAIR/monitored.ecl
+++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
@@ -18,10 +18,13 @@
 -enable=MC3R1.R12.5
 -enable=MC3R1.R1.3
 -enable=MC3R1.R13.6
+-enable=MC3R1.R13.1
 -enable=MC3R1.R1.4
 -enable=MC3R1.R14.1
 -enable=MC3R1.R14.4
 -enable=MC3R1.R16.2
+-enable=MC3R1.R16.3
+-enable=MC3R1.R16.4
 -enable=MC3R1.R16.6
 -enable=MC3R1.R16.7
 -enable=MC3R1.R17.1
@@ -34,6 +37,7 @@
 -enable=MC3R1.R20.13
 -enable=MC3R1.R20.14
 -enable=MC3R1.R20.4
+-enable=MC3R1.R20.7
 -enable=MC3R1.R20.9
 -enable=MC3R1.R2.1
 -enable=MC3R1.R21.10
@@ -58,6 +62,7 @@
 -enable=MC3R1.R5.2
 -enable=MC3R1.R5.3
 -enable=MC3R1.R5.4
+-enable=MC3R1.R5.5
 -enable=MC3R1.R5.6
 -enable=MC3R1.R6.1
 -enable=MC3R1.R6.2
-- 
2.34.1

Check out our Xen Summit highlights video!

[Kelly Choi]

Hi everyone,

Check out our Xen Summit highlights video on YouTube:
https://www.youtube.com/watch?v=qZcCCm_PaHs&ab_channel=TheXenProject

What a great reminder of how important our summits are, and the community
behind it!

Many thanks,
Kelly Choi

Community Manager
Xen Project

Re: [RFC PATCH] iommu/xen: Add Xen PV-IOMMU driver

[Teddy Astie]

Hello Jason,

Le 19/06/2024 à 18:30, Jason Gunthorpe a écrit :
> On Thu, Jun 13, 2024 at 01:50:22PM +, Teddy Astie wrote:
>
>> +struct iommu_domain *xen_iommu_domain_alloc(unsigned type)
>> +{
>> +struct xen_iommu_domain *domain;
>> +u16 ctx_no;
>> +int ret;
>> +
>> +if (type & IOMMU_DOMAIN_IDENTITY) {
>> +/* use default domain */
>> +ctx_no = 0;
>
> Please use the new ops, domain_alloc_paging and the static identity domain.

Yes, in the v2, I will use this newer interface.

I have a question on this new interface : is it valid to not have a
identity domain (and "default domain" being blocking); well in the
current implementation it doesn't really matter, but at some point, we
may want to allow not having it (thus making this driver mandatory).

>
>> +static struct iommu_group *xen_iommu_device_group(struct device *dev)
>> +{
>> +if (!dev_is_pci(dev))
>> +return ERR_PTR(-ENODEV);
>> +
>
> device_group is only called after probe_device, since you already
> exclude !pci during probe there is no need for this wrapper, just set
> the op directly to pci_device_group.
>
>> +if (!dev_is_pci(dev))
>> +return;
>
> No op is ever called on a non-probed device, remove all these checks.
>
>
> A paging domain should be the only domain ops that have a populated
> map so this should be made impossible by construction
Makes sense, will remove these redundant checks in v2.

>
>> +static void xen_iommu_release_device(struct device *dev)
>> +{
>> +int ret;
>> +struct pci_dev *pdev;
>> +struct pv_iommu_op op = {
>> +.subop_id = IOMMUOP_reattach_device,
>> +.flags = 0,
>> +.ctx_no = 0 /* reattach device back to default context */
>> +};
>
> Consider if you can use release_domain for this, I think this is
> probably a BLOCKED domain behavior.

The goal is to put back all devices where they were at the beginning
(the default "context"), which is what release_domain looks like it is
doing. Will use it for v2.

>
> Jason

Teddy


Teddy Astie | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

[xen-unstable test] 186444: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-raw   8 xen-boot fail in 186438 pass in 186444
 test-armhf-armhf-libvirt-vhd 17 guest-start/debian.repeat  fail pass in 186438

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 186438
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186438
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 186438
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 186438
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 186438
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 186438
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-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-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-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-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-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-amd64-amd64-libvirt-vhd 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-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-xl-qcow214 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-qcow215 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-raw  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-raw  15 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  62071a1c16c4dbe765491e58e456fd3a19b33298
baseline version:
 xen  62071a1c16c4dbe765491e58e456fd3a19b33298

Last test of basis   186444  2024-06-21 07:49:49 Z0 days
Testing same since  (not found) 0 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386

[PATCH v2] common/unlzo: address violation of MISRA C Rule 7.3

[Alessandro Zucchelli]

This addresses violations of MISRA C:2012 Rule 7.3 which states as
following: the lowercase character `l' shall not be used in a literal
suffix.

The file common/unlzo.c defines the non-compliant constant LZO_BLOCK_SIZE with
having a lowercase 'l'.
It is now defined as '256*1024L'.

No functional change.

Signed-off-by: Alessandro Zucchelli 
---
Changes from v1:
Instead of deviating /common/unlzo.c reports fro Rule 7.3 they are addressed by
changing the non-compliant definition of LZO_BLOCK_SIZE.
---
 xen/common/unlzo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/unlzo.c b/xen/common/unlzo.c
index bdcefa95b3..acb8dff600 100644
--- a/xen/common/unlzo.c
+++ b/xen/common/unlzo.c
@@ -52,7 +52,7 @@ static inline u32 get_unaligned_be32(const void *p)
 static const unsigned char lzop_magic[] = {
0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a };
 
-#define LZO_BLOCK_SIZE(256*1024l)
+#define LZO_BLOCK_SIZE(256*1024L)
 #define HEADER_HAS_FILTER  0x0800L
 #define HEADER_SIZE_MIN   (9 + 7 + 4 + 8 + 1   + 4)
 #define HEADER_SIZE_MAX   (9 + 7 + 1 + 8 + 8 + 4 + 1 + 255 + 4)
-- 
2.34.1

Re: [PATCH for-4.19? v6 6/9] xen: Make the maximum number of altp2m views configurable for x86

[Petr Beneš]

On Thu, Jun 20, 2024 at 9:25 AM Jan Beulich  wrote:
> Not exactly. You may not assert on idx. The assertion, if any, wants to
> check d->nr_altp2m against MAX_EPTP.

In addition to the check in arch_sanitize_domain? As a safeguard?

> You're again comparing cases where we control the index (in the loop) with
> cases where we don't (hypercall inputs).

So, replacing strictly the occurrences where we don't control the
index, and leave everything else as is. Okay.

P.

[PATCH v2] automation/eclair_analysis: deviate and|or|xor|not for MISRA C Rule 21.2

[Alessandro Zucchelli]

Rule 21.2 reports identifiers reserved for the C and POSIX standard
libraries: or, and, not and xor are reserved identifiers because they
constitute alternate spellings for the corresponding operators (they are
defined as macros by iso646.h); however Xen doesn't use standard library
headers, so there is no risk of overlap.

This addresses violations arising from x86_emulate/x86_emulate.c, where
label statements named as or, and and xor appear.

No functional change.

Signed-off-by: Alessandro Zucchelli 
Acked-by: Stefano Stabellini 
---
Changes from v1:
Added deviation for 'not' identifier.
Added explanation of where these identifiers are defined, specifically in the
'iso646.h' file of the Standard Library.
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 069519e380..14c7afb39e 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -501,7 +501,7 @@ still remain available."
 -doc_begin="or, and and xor are reserved identifiers because they constitute 
alternate
 spellings for the corresponding operators (they are defined as macros by 
iso646.h).
 However, Xen doesn't use standard library headers, so there is no risk of 
overlap."
--config=MC3R1.R21.2,reports+={safe, 
"any_area(stmt(ref(kind(label)&&^(or|and|xor)$)))"}
+-config=MC3R1.R21.2,reports+={safe, 
"any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
 -doc_end
 
 -doc_begin="Xen does not use the functions provided by the Standard Library, 
but
-- 
2.34.1

Re: [XEN PATCH v2] xen: add explicit comment to identify notifier patterns

[Federico Serafini]

On 21/06/24 03:13, Stefano Stabellini wrote:

On Thu, 20 Jun 2024, Federico Serafini wrote:

On 19/06/24 13:17, Julien Grall wrote:

Hi Federico,

On 19/06/2024 10:29, Federico Serafini wrote:

MISRA C Rule 16.4 states that every `switch' statement shall have a
`default' label" and a statement or a comment prior to the
terminating break statement.

This patch addresses some violations of the rule related to the
"notifier pattern": a frequently-used pattern whereby only a few values
are handled by the switch statement and nothing should be done for
others (nothing to do in the default case).

Note that for function mwait_idle_cpu_init() in
xen/arch/x86/cpu/mwait-idle.c the /* Notifier pattern. */ comment is
not added: differently from the other functions covered in this patch,
the default label has a return statement that does not violates Rule 16.4.

No functional change.

Signed-off-by: Federico Serafini 
---
Changes in v2:
as Jan pointed out, in the v1 some patterns were not explicitly identified
(https://lore.kernel.org/xen-devel/cad05a5c-e2d8-4e5d-af05-30ae6f959...@bugseng.com/).

This version adds the /* Notifier pattern. */ to all the pattern present
in
the Xen codebase except for mwait_idle_cpu_init().
---
   xen/arch/arm/cpuerrata.c | 1 +
   xen/arch/arm/gic-v3-lpi.c    | 4 
   xen/arch/arm/gic.c   | 1 +
   xen/arch/arm/irq.c   | 4 
   xen/arch/arm/mmu/p2m.c   | 1 +
   xen/arch/arm/percpu.c    | 1 +
   xen/arch/arm/smpboot.c   | 1 +
   xen/arch/arm/time.c  | 1 +
   xen/arch/arm/vgic-v3-its.c   | 2 ++
   xen/arch/x86/acpi/cpu_idle.c | 4 
   xen/arch/x86/cpu/mcheck/mce.c    | 4 
   xen/arch/x86/cpu/mcheck/mce_intel.c  | 4 
   xen/arch/x86/genapic/x2apic.c    | 3 +++
   xen/arch/x86/hvm/hvm.c   | 1 +
   xen/arch/x86/nmi.c   | 1 +
   xen/arch/x86/percpu.c    | 3 +++
   xen/arch/x86/psr.c   | 3 +++
   xen/arch/x86/smpboot.c   | 3 +++
   xen/common/kexec.c   | 1 +
   xen/common/rcupdate.c    | 1 +
   xen/common/sched/core.c  | 1 +
   xen/common/sched/cpupool.c   | 1 +
   xen/common/spinlock.c    | 1 +
   xen/common/tasklet.c | 1 +
   xen/common/timer.c   | 1 +
   xen/drivers/cpufreq/cpufreq.c    | 1 +
   xen/drivers/cpufreq/cpufreq_misc_governors.c | 3 +++
   xen/drivers/passthrough/x86/hvm.c    | 3 +++
   xen/drivers/passthrough/x86/iommu.c  | 3 +++
   29 files changed, 59 insertions(+)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 2b7101ea25..69c30aecd8 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -730,6 +730,7 @@ static int cpu_errata_callback(struct notifier_block
*nfb,
   rc = enable_nonboot_cpu_caps(arm_errata);
   break;
   default:
+    /* Notifier pattern. */

Without looking at the commit message (which may not be trivial when
committed), it is not clear to me what this is supposed to mean. Will there
be a longer explanation in the MISRA doc? Should this be a SAF-* comment?


   break;
   }
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index eb0a5535e4..4c2bd35403 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -389,6 +389,10 @@ static int cpu_callback(struct notifier_block *nfb,
unsigned long action,
   printk(XENLOG_ERR "Unable to allocate the pendtable for
CPU%lu\n",
  cpu);
   break;
+
+    default:
+    /* Notifier pattern. */
+    break;


Skimming through v1, it was pointed out that gic-v3-lpi may miss some cases.

Let me start with that I understand this patch is technically not changing
anything. However, it gives us an opportunity to check the notifier pattern.

Has anyone done any proper investigation? If so, what was the outcome? If
not, have we identified someone to do it?

The same question will apply for place where you add "default".


Yes, I also think this could be an opportunity to check the pattern
but no one has yet been identified to do this.


I don't think I understand Julien's question and/or your answer.

Is the question whether someone has done an analysis to make sure this
patch covers all notifier patters in the xen codebase?


I think Jan and Julien's concerns are about the fact that my patch
takes for granted that all the switch statements are doing the right
thing: someone should investigate the notifier patterns to confirm that
their are handling the different cases correctly.



If so, I expect that you have done an analysis simply by basing this
patch o

[RFC XEN PATCH] x86/mctelem: address violations of MISRA C: 2012 Rule 5.3

[Nicola Vetrini]

From: Alessandro Zucchelli 

This addresses violations of MISRA C:2012 Rule 5.3 which states as
following: An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope. In this case the shadowing is between
local variables "mctctl" and the file-scope static struct variable with the
same name.

No functional change.

Signed-off-by: Alessandro Zucchelli 
Signed-off-by: Nicola Vetrini 
---
RFC because I'm not 100% sure the semantics of the code is preserved.
I think so, and it passes gitlab pipelines [1], but there may be some missing
information.

[1] https://gitlab.com/xen-project/people/bugseng/xen/-/pipelines/134025883
---
 xen/arch/x86/cpu/mcheck/mctelem.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mctelem.c 
b/xen/arch/x86/cpu/mcheck/mctelem.c
index b8d0368a7d37..df1a31bffb61 100644
--- a/xen/arch/x86/cpu/mcheck/mctelem.c
+++ b/xen/arch/x86/cpu/mcheck/mctelem.c
@@ -168,14 +168,14 @@ static void mctelem_xchg_head(struct mctelem_ent **headp,
 void mctelem_defer(mctelem_cookie_t cookie, bool lmce)
 {
struct mctelem_ent *tep = COOKIE2MCTE(cookie);
-   struct mc_telem_cpu_ctl *mctctl = &this_cpu(mctctl);
+   struct mc_telem_cpu_ctl *mctctl_cpu = &this_cpu(mctctl);
 
-   ASSERT(mctctl->pending == NULL || mctctl->lmce_pending == NULL);
+   ASSERT(mctctl_cpu->pending == NULL || mctctl_cpu->lmce_pending == NULL);
 
-   if (mctctl->pending)
-   mctelem_xchg_head(&mctctl->pending, &tep->mcte_next, tep);
+   if (mctctl_cpu->pending)
+   mctelem_xchg_head(&mctctl_cpu->pending, &tep->mcte_next, tep);
else if (lmce)
-   mctelem_xchg_head(&mctctl->lmce_pending, &tep->mcte_next, tep);
+   mctelem_xchg_head(&mctctl_cpu->lmce_pending, &tep->mcte_next, 
tep);
else {
/*
 * LMCE is supported on Skylake-server and later CPUs, on
@@ -186,10 +186,10 @@ void mctelem_defer(mctelem_cookie_t cookie, bool lmce)
 * moment. As a result, the following two exchanges together
 * can be treated as atomic.
 */
-   if (mctctl->lmce_pending)
-   mctelem_xchg_head(&mctctl->lmce_pending,
- &mctctl->pending, NULL);
-   mctelem_xchg_head(&mctctl->pending, &tep->mcte_next, tep);
+   if (mctctl_cpu->lmce_pending)
+   mctelem_xchg_head(&mctctl_cpu->lmce_pending,
+ &mctctl_cpu->pending, NULL);
+   mctelem_xchg_head(&mctctl_cpu->pending, &tep->mcte_next, tep);
}
 }
 
@@ -213,7 +213,7 @@ void mctelem_process_deferred(unsigned int cpu,
 {
struct mctelem_ent *tep;
struct mctelem_ent *head, *prev;
-   struct mc_telem_cpu_ctl *mctctl = &per_cpu(mctctl, cpu);
+   struct mc_telem_cpu_ctl *mctctl_cpu = &per_cpu(mctctl, cpu);
int ret;
 
/*
@@ -232,7 +232,7 @@ void mctelem_process_deferred(unsigned int cpu,
 * Any MC# occurring after the following atomic exchange will be
 * handled by another round of MCE softirq.
 */
-   mctelem_xchg_head(lmce ? &mctctl->lmce_pending : &mctctl->pending,
+   mctelem_xchg_head(lmce ? &mctctl_cpu->lmce_pending : 
&mctctl_cpu->pending,
  &this_cpu(mctctl.processing), NULL);
 
head = this_cpu(mctctl.processing);
-- 
2.34.1

Re: [PATCH for-4.19] xen/arm: static-shmem: request host address to be specified for 1:1 domains

[Oleksii K.]

On Fri, 2024-06-21 at 11:22 +0200, Michal Orzel wrote:
> As a follow up to commit cb1ddafdc573 ("xen/arm/static-shmem: Static-
> shmem
> should be direct-mapped for direct-mapped domains") add a check to
> request that both host and guest physical address must be supplied
> for
> direct mapped domains. Otherwise return an error to prevent unwanted
> behavior.
> 
> Signed-off-by: Michal Orzel 
> ---
> Reasoning for 4.19:
> this is hardening the code to prevent a feature misuse and unwanted
> behavior.
> ---
Release-Acked-By: Oleksii Kurochko 

~ Oleksii
>  xen/arch/arm/static-shmem.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-
> shmem.c
> index cd48d2896b7e..aa80756c3ca5 100644
> --- a/xen/arch/arm/static-shmem.c
> +++ b/xen/arch/arm/static-shmem.c
> @@ -378,6 +378,13 @@ int __init process_shm(struct domain *d, struct
> kernel_info *kinfo,
>  const struct membank *alloc_bank =
>  find_shm_bank_by_id(get_shmem_heap_banks(), shm_id);
>  
> +    if ( is_domain_direct_mapped(d) )
> +    {
> +    printk("%pd: host and guest physical address must be
> supplied for direct-mapped domains\n",
> +   d);
> +    return -EINVAL;
> +    }
> +
>  /* guest phys address is right at the beginning */
>  gbase = dt_read_paddr(cells, addr_cells);
>  

[libvirt test] 186441: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 186427
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail 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-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 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-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-checkfail   never pass

version targeted for testing:
 libvirt  e6b94cba7ee1ea0ab3a49ebdd2520c4a6259a013
baseline version:
 libvirt  43d2edc08f5a7b5e1d0c3464580113e069d1efa7

Last test of basis   186427  2024-06-20 04:18:46 Z1 days
Testing same since   186441  2024-06-21 04:20:23 Z0 days1 attempts


People who touched revisions under test:
  Boris Fiuczynski 
  Michal Privoznik 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/libvirt.git
   43d2edc08f..e6b94cba7e  e6b94cba7ee1ea0ab3a49ebdd2520c4a6259a013 -> 
xen-tested-master

Re: [PATCH for-4.19?] libelf: avoid UB in elf_xen_feature_{get,set}()

[Oleksii K.]

On Thu, 2024-06-20 at 17:07 +0100, Andrew Cooper wrote:
> On 20/06/2024 4:34 pm, Jan Beulich wrote:
> > When the left shift amount is up to 31, the shifted quantity wants
> > to be
> > of unsigned int (or wider) type.
> > 
> > While there also adjust types: get doesn't alter the array and
> > returns a
> > boolean, while both don't really accept negative "nr". Drop a stray
> > blank each as well.
> > 
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper 
> 
> +1 for 4.19.
Release-Acked-By: Oleksii Kurochko 

~ Oleksii

> 
> > ---
> > Really I wonder why these exist at all; they're effectively
> > test_bit()
> > and __set_bit() in hypervisor terms, and iirc something like that
> > exists
> > in the tool stack as well.
> 
> The toolstack has tools/libs/ctrl/xc_bitops.h but they're not API
> compatible with Xen.
> 
> They're long-granular rather than int-granular, have swapped
> arguments,
> and are non-LOCKed.
> 
> ~Andrew

Re: [XEN for-4.19 PATCH] x86/apic: Fix signing in left bitshift

[Oleksii K.]

On Thu, 2024-06-20 at 16:16 +0100, Andrew Cooper wrote:
> On 20/06/2024 3:31 pm, Matthew Barnes wrote:
> > There exists a bitshift in the IOAPIC code where a signed integer
> > is
> > shifted to the left by at most 31 bits. This is undefined
> > behaviour,
> > and can cause faults in xtf tests such as pv64-pv-iopl~hypercall.
> > 
> > This patch fixes this by changing the integer from signed to
> > unsigned.
> > 
> > Signed-off-by: Matthew Barnes 
> 
> The code change itself is fine, but I'm going to recommend some
> adjustments to the commit message.
> 
> Its "x86/ioapic";  apic implies the Local APIC which is apic.c and
> distinct from the IO-APIC.  The subject would be clearer as "Fix
> signed
> shift in end_level_ioapic_irq_new()".
> 
> The XTF test has nothing to do with this, so shouldn't be mentioned
> like
> this.  The UBSAN failure was in an interrupt handler, and it was
> complete chance that it triggered while pv64-pv-iopl~hypercall was
> the
> test being ran.
> 
> I'm happy to fix all of that up on commit.
> 
> CC Oleksii for 4.19.  This is low risk, and found during testing with
> UBSAN active.
Release-Acked-By: Oleksii Kurochko 

~ Oleksii

[PATCH for-4.19] xen/arm: static-shmem: request host address to be specified for 1:1 domains

[Michal Orzel]

As a follow up to commit cb1ddafdc573 ("xen/arm/static-shmem: Static-shmem
should be direct-mapped for direct-mapped domains") add a check to
request that both host and guest physical address must be supplied for
direct mapped domains. Otherwise return an error to prevent unwanted
behavior.

Signed-off-by: Michal Orzel 
---
Reasoning for 4.19:
this is hardening the code to prevent a feature misuse and unwanted behavior.
---
 xen/arch/arm/static-shmem.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/arch/arm/static-shmem.c b/xen/arch/arm/static-shmem.c
index cd48d2896b7e..aa80756c3ca5 100644
--- a/xen/arch/arm/static-shmem.c
+++ b/xen/arch/arm/static-shmem.c
@@ -378,6 +378,13 @@ int __init process_shm(struct domain *d, struct 
kernel_info *kinfo,
 const struct membank *alloc_bank =
 find_shm_bank_by_id(get_shmem_heap_banks(), shm_id);
 
+if ( is_domain_direct_mapped(d) )
+{
+printk("%pd: host and guest physical address must be supplied 
for direct-mapped domains\n",
+   d);
+return -EINVAL;
+}
+
 /* guest phys address is right at the beginning */
 gbase = dt_read_paddr(cells, addr_cells);
 
-- 
2.25.1

[ovmf test] 186443: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf be38c01da2dd949e0a6f8bceeb88d2e19c8c65f7
baseline version:
 ovmf d512bd31293c7f2aeef9b60fb6f112d0e90adff3

Last test of basis   186440  2024-06-21 03:11:13 Z0 days
Testing same since   186443  2024-06-21 07:11:06 Z0 days1 attempts


People who touched revisions under test:
  Mike Maslenkin 

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



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
   d512bd3129..be38c01da2  be38c01da2dd949e0a6f8bceeb88d2e19c8c65f7 -> 
xen-tested-master

Re: [XEN PATCH] common/sched: address a violation of MISRA C Rule 8.8

[George Dunlap]

On Fri, Jun 21, 2024 at 1:21 AM  wrote:
>
> From: Victor Lira 
>
> Rule 8.8: "The static storage class specifier shall be used in all
> declarations of objects and functions that have internal linkage"
>
> This patch fixes this by adding the static specifier.
> No functional changes.
>
> Reported-by: Stewart Hildebrand 
> Signed-off-by: Victor Lira 

With the changes noted already:

Acked-by: George Dunlap 

Re: [XEN PATCH v10 4/5] tools: Add new function to get gsi from dev

[Chen, Jiqian]

On 2024/6/20 22:38, Anthony PERARD wrote:
> On Mon, Jun 17, 2024 at 05:00:34PM +0800, Jiqian Chen wrote:
>> diff --git a/tools/include/xencall.h b/tools/include/xencall.h
>> index fc95ed0fe58e..750aab070323 100644
>> --- a/tools/include/xencall.h
>> +++ b/tools/include/xencall.h
>> @@ -113,6 +113,8 @@ int xencall5(xencall_handle *xcall, unsigned int op,
>>   uint64_t arg1, uint64_t arg2, uint64_t arg3,
>>   uint64_t arg4, uint64_t arg5);
>>  
>> +int xen_oscall_gsi_from_dev(xencall_handle *xcall, unsigned int sbdf);
> 
> I don't think that an appropriate library for this new feature.
> libxencall is a generic lib to make hypercall.
Do you have a suggested place to put this new function?
This new function is to get gsi of a pci device, and only depend on the dom0 
kernel, doesn't need to interact with hypervisor.

> 
>>  /* Variant(s) of the above, as needed, returning "long" instead of "int". */
>>  long xencall2L(xencall_handle *xcall, unsigned int op,
>> uint64_t arg1, uint64_t arg2);
>> diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
>> index 9ceca0cffc2f..a0381f74d24b 100644
>> --- a/tools/include/xenctrl.h
>> +++ b/tools/include/xenctrl.h
>> @@ -1641,6 +1641,8 @@ int xc_physdev_unmap_pirq(xc_interface *xch,
>>uint32_t domid,
>>int pirq);
>>  
>> +int xc_physdev_gsi_from_dev(xc_interface *xch, uint32_t sbdf);
>> +
>>  /*
>>   *  LOGGING AND ERROR REPORTING
>>   */
>> diff --git a/tools/libs/call/core.c b/tools/libs/call/core.c
>> index 02c4f8e1aefa..6dae50c9a6ba 100644
>> --- a/tools/libs/call/core.c
>> +++ b/tools/libs/call/core.c
>> @@ -173,6 +173,11 @@ int xencall5(xencall_handle *xcall, unsigned int op,
>>  return osdep_hypercall(xcall, &call);
>>  }
>>  
>> +int xen_oscall_gsi_from_dev(xencall_handle *xcall, unsigned int sbdf)
>> +{
>> +return osdep_oscall(xcall, sbdf);
>> +}
>> +
>>  /*
>>   * Local variables:
>>   * mode: C
>> diff --git a/tools/libs/call/libxencall.map b/tools/libs/call/libxencall.map
>> index d18a3174e9dc..b92a0b5dc12c 100644
>> --- a/tools/libs/call/libxencall.map
>> +++ b/tools/libs/call/libxencall.map
>> @@ -10,6 +10,8 @@ VERS_1.0 {
>>  xencall4;
>>  xencall5;
>>  
>> +xen_oscall_gsi_from_dev;
> 
> FYI, never change already released version of a library, this would add
> a new function to libxencall.1.0. Instead, when adding a new function
> to a library that is supposed to be stable (they have a *.map file in
> xen case), add it to a new section, that woud be VERS_1.4 in this case.
> But libxencall isn't approriate for this new function, so just for
> future reference.
> 
>>  xencall_alloc_buffer;
>>  xencall_free_buffer;
>>  xencall_alloc_buffer_pages;
>> diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
>> index 6d588e6bea8f..92c740e176f2 100644
>> --- a/tools/libs/call/linux.c
>> +++ b/tools/libs/call/linux.c
>> @@ -85,6 +85,21 @@ long osdep_hypercall(xencall_handle *xcall, 
>> privcmd_hypercall_t *hypercall)
>>  return ioctl(xcall->fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
>>  }
>>  
>> +int osdep_oscall(xencall_handle *xcall, unsigned int sbdf)
>> +{
>> +privcmd_gsi_from_dev_t dev_gsi = {
>> +.sbdf = sbdf,
>> +.gsi = -1,
>> +};
>> +
>> +if (ioctl(xcall->fd, IOCTL_PRIVCMD_GSI_FROM_DEV, &dev_gsi)) {
> 
> Looks like libxencall is only for hypercall, and so I don't think
> it's the right place to introducing another ioctl() call.
It seems IOCTL_PRIVCMD_HYPERCALL is for hypercall.
What I do here is to introduce new call into privcmd fd.
Maybe I can open "/dev/xen/privcmd" directly, so that I don't have to add the 
*_oscal function.

> 
>> +PERROR("failed to get gsi from dev");
>> +return -1;
>> +}
>> +
>> +return dev_gsi.gsi;
>> +}
>> +
>>  static void *alloc_pages_bufdev(xencall_handle *xcall, size_t npages)
>>  {
>>  void *p;
>> diff --git a/tools/libs/call/private.h b/tools/libs/call/private.h
>> index 9c3aa432efe2..cd6eb5a3e66f 100644
>> --- a/tools/libs/call/private.h
>> +++ b/tools/libs/call/private.h
>> @@ -57,6 +57,15 @@ int osdep_xencall_close(xencall_handle *xcall);
>>  
>>  long osdep_hypercall(xencall_handle *xcall, privcmd_hypercall_t *hypercall);
>>  
>> +#if defined(__linux__)
>> +int osdep_oscall(xencall_handle *xcall, unsigned int sbdf);
>> +#else
>> +static inline int osdep_oscall(xencall_handle *xcall, unsigned int sbdf)
>> +{
>> +return -1;
>> +}
>> +#endif
>> +
>>  void *osdep_alloc_pages(xencall_handle *xcall, size_t nr_pages);
>>  void osdep_free_pages(xencall_handle *xcall, void *p, size_t nr_pages);
>>  
>> diff --git a/tools/libs/ctrl/xc_physdev.c b/tools/libs/ctrl/xc_physdev.c
>> index 460a8e779ce8..c1458f3a38b5 100644
>> --- a/tools/libs/ctrl/xc_physdev.c
>> +++ b/tools/libs/ctrl/xc_physdev.c
>> @@ -111,3 +111,7 @@ int xc_physdev_unmap_pirq(xc_interface *xch,
>>  return rc;
>>  }

Re: [XEN PATCH v10 5/5] domctl: Add XEN_DOMCTL_gsi_permission to grant gsi

[Chen, Jiqian]

On 2024/6/20 18:42, Jan Beulich wrote:
> On 20.06.2024 11:40, Chen, Jiqian wrote:
>> On 2024/6/18 17:23, Jan Beulich wrote:
>>> On 18.06.2024 10:23, Chen, Jiqian wrote:
 On 2024/6/17 23:32, Jan Beulich wrote:
> On 17.06.2024 11:00, Jiqian Chen wrote:
>> @@ -1516,14 +1519,39 @@ static void pci_add_dm_done(libxl__egc *egc,
>>  rc = ERROR_FAIL;
>>  goto out;
>>  }
>> -r = xc_domain_irq_permission(ctx->xch, domid, irq, 1);
>> +#ifdef CONFIG_X86
>> +/* If dom0 doesn't have PIRQs, need to use 
>> xc_domain_gsi_permission */
>> +r = xc_domain_getinfo_single(ctx->xch, 0, &info);
>
> Hard-coded 0 is imposing limitations. Ideally you would use DOMID_SELF, 
> but
> I didn't check if that can be used with the underlying hypercall(s). 
> Otherwise
>> From the commit 10ef7a91b5a8cb8c58903c60e2dd16ed490b3bcf, DOMID_SELF is not 
>> allowed for XEN_DOMCTL_getdomaininfo.
>> And now XEN_DOMCTL_getdomaininfo gets domain through rcu_lock_domain_by_id.
>>
> you want to pass the actual domid of the local domain here.
>> What is the local domain here?
> 
> The domain your code is running in.
> 
>> What is method for me to get its domid?
> 
> I hope there's an available function in one of the libraries to do that.
I didn't find relate function.
Hi Anthony, do you know?

> But I wouldn't even know what to look for; that's a question to (primarily)
> Anthony then, who sadly continues to be our only tool stack maintainer.
> 
> Alternatively we could maybe enable XEN_DOMCTL_getdomaininfo to permit
> DOMID_SELF.
It didn't permit DOMID_SELF since below commit. Does it still have the same 
problem if permit DOMID_SELF?

commit 10ef7a91b5a8cb8c58903c60e2dd16ed490b3bcf
Author: kfraser@localhost.localdomain 
Date:   Tue Aug 14 09:56:46 2007 +0100

xen: Do not accept DOMID_SELF as input to DOMCTL_getdomaininfo.
This was screwing up callers that loop on getdomaininfo(), if there
was a domain with domid DOMID_FIRST_RESERVED-1 (== DOMID_SELF-1).
They would see DOMID_SELF-1, then look up DOMID_SELF, which has domid
0 of course, and then start their domain-finding loop all over again!
Found by Kouya Shimura . Thanks!
Signed-off-by: Keir Fraser 

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 09a1e84d98e0..5d29667b7c3d 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -463,19 +463,13 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 case XEN_DOMCTL_getdomaininfo:
 {
 struct domain *d;
-domid_t dom;
-
-dom = op->domain;
-if ( dom == DOMID_SELF )
-dom = current->domain->domain_id;
+domid_t dom = op->domain;

 rcu_read_lock(&domlist_read_lock);

 for_each_domain ( d )
-{
 if ( d->domain_id >= dom )
 break;
-}

 if ( d == NULL )
 {

> 
 But the action of granting permission is from dom0 to domU, what I need to 
 get is the infomation of dom0,
 The actual domid here is domU's id I think, it is not useful.
>>>
>>> Note how I said DOMID_SELF and "local domain". There's no talk of using the
>>> DomU's domid. But what you apparently neglect is the fact that the hardware
>>> domain isn't necessarily Dom0 (see CONFIG_LATE_HWDOM in the hypervisor).
>>> While benign in most cases, this is relevant when it comes to referencing
>>> the hardware domain by domid. And it is the hardware domain which is going
>>> to drive the device re-assignment, as that domain is who's in possession of
>>> all the devices not yet assigned to any DomU.
>> OK, I need to get the information of hardware domain here?
> 
> Right, with (for this purpose) "hardware domain" == "local domain".
> 
> Jan

-- 
Best regards,
Jiqian Chen.

Re: [XEN PATCH v10 4/5] tools: Add new function to get gsi from dev

[Chen, Jiqian]

On 2024/6/20 18:37, Jan Beulich wrote:
> On 20.06.2024 12:23, Chen, Jiqian wrote:
>> On 2024/6/20 15:43, Jan Beulich wrote:
>>> On 20.06.2024 09:03, Chen, Jiqian wrote:
 On 2024/6/18 17:13, Jan Beulich wrote:
> On 18.06.2024 10:10, Chen, Jiqian wrote:
>> On 2024/6/17 23:10, Jan Beulich wrote:
>>> On 17.06.2024 11:00, Jiqian Chen wrote:
 --- a/tools/libs/light/libxl_pci.c
 +++ b/tools/libs/light/libxl_pci.c
 @@ -1406,6 +1406,12 @@ static bool pci_supp_legacy_irq(void)
  #endif
  }
  
 +#define PCI_DEVID(bus, devfn)\
 +uint16_t)(bus)) << 8) | ((devfn) & 0xff))
 +
 +#define PCI_SBDF(seg, bus, devfn) \
 +uint32_t)(seg)) << 16) | (PCI_DEVID(bus, devfn)))
>>>
>>> I'm not a maintainer of this file; if I were, I'd ask that for 
>>> readability's
>>> sake all excess parentheses be dropped from these.
>> Isn't it a coding requirement to enclose each element in parentheses in 
>> the macro definition?
>> It seems other files also do this. See tools/libs/light/libxl_internal.h
>
> As said, I'm not a maintainer of this code. Yet while I'm aware that libxl
> has its own CODING_STYLE, I can't spot anything towards excessive use of
> parentheses there.
 So, which parentheses do you think are excessive use?
>>>
>>> #define PCI_DEVID(bus, devfn)\
>>> (((uint16_t)(bus) << 8) | ((devfn) & 0xff))
>>>
>>> #define PCI_SBDF(seg, bus, devfn) \
>>> (((uint32_t)(seg) << 16) | PCI_DEVID(bus, devfn))
>> Thanks, will change in next version.
>>
>>>
 @@ -1486,6 +1496,18 @@ static void pci_add_dm_done(libxl__egc *egc,
  goto out_no_irq;
  }
  if ((fscanf(f, "%u", &irq) == 1) && irq) {
 +#ifdef CONFIG_X86
 +sbdf = PCI_SBDF(pci->domain, pci->bus,
 +(PCI_DEVFN(pci->dev, pci->func)));
 +gsi = xc_physdev_gsi_from_dev(ctx->xch, sbdf);
 +/*
 + * Old kernel version may not support this function,
>>>
>>> Just kernel?
>> Yes, xc_physdev_gsi_from_dev depends on the function implemented on 
>> linux kernel side.
>
> Okay, and when the kernel supports it but the underlying hypervisor 
> doesn't
> support what the kernel wants to use in order to fulfill the request, all
 I don't know what things you mentioned hypervisor doesn't support are,
 because xc_physdev_gsi_from_dev is to get the gsi of pcidev through sbdf 
 information,
 that relationship can be got only in dom0 instead of Xen hypervisor.

> is fine? (See also below for what may be needed in the hypervisor, even if
 You mean xc_physdev_map_pirq needs gsi?
>>>
>>> I'd put it slightly differently: You arrange for that function to now take a
>>> GSI when the caller is PVH. But yes, the function, when used with
>>> MAP_PIRQ_TYPE_GSI, clearly expects a GSI as input (see also below).
>>>
> this IOCTL would be satisfied by the kernel without needing to interact 
> with
> the hypervisor.)
>
 + * so if fail, keep using irq; if success, use gsi
 + */
 +if (gsi > 0) {
 +irq = gsi;
>>>
>>> I'm still puzzled by this, when by now I think we've sufficiently 
>>> clarified
>>> that IRQs and GSIs use two distinct numbering spaces.
>>>
>>> Also, as previously indicated, you call this for PV Dom0 as well. Aiui 
>>> on
>>> the assumption that it'll fail. What if we decide to make the 
>>> functionality
>>> available there, too (if only for informational purposes, or for
>>> consistency)? Suddenly you're fallback logic wouldn't work anymore, and
>>> you'd call ...
>>>
 +}
 +#endif
  r = xc_physdev_map_pirq(ctx->xch, domid, irq, &irq);
>>>
>>> ... the function with a GSI when a pIRQ is meant. Imo, as suggested 
>>> before,
>>> you strictly want to avoid the call on PV Dom0.
>>>
>>> Also for PVH Dom0: I don't think I've seen changes to the hypercall
>>> handling, yet. How can that be when GSI and IRQ aren't the same, and 
>>> hence
>>> incoming GSI would need translating to IRQ somewhere? I can once again 
>>> only
>>> assume all your testing was done with IRQs whose numbers happened to 
>>> match
>>> their GSI numbers. (The difference, imo, would also need calling out in 
>>> the
>>> public header, where the respective interface struct(s) is/are defined.)
>> I feel like you missed out on many of the previous discussions.
>> Without my changes, the original codes use irq (read from file 
>> /sys/bus/pci/devices//irq) to do xc_physdev_map_pirq,
>> but xc_physdev_map_pirq require passing into gsi instead of irq, so we 
>> need to use gsi whether dom0 is PV

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-raw   8 xen-bootfail pass in 186442-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-raw 14 migrate-support-check fail in 186442 never pass
 test-armhf-armhf-xl-raw 15 saverestore-support-check fail in 186442 never pass
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 186430
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186430
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 186430
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 186430
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 186430
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 186430
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-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-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-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-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-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-amd64-amd64-libvirt-vhd 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-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-vhd 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-xl-qcow214 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-qcow215 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  62071a1c16c4dbe765491e58e456fd3a19b33298
baseline version:
 xen  efa6e9f15ba943d154e8d7b29384581915b2aacd

Last test of basis   186430  2024-06-20 07:18:11 Z1 days
Testing same since   186438  2024-06-20 20:41:43 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Jan Beulich 
  Jason Andryuk 
  Julien Grall 
  Leigh Brown 
  Roger Pau Monné 
  Stefano Stabellini 

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