Re: [PATCH v2] docs/misra: add 14.3

[Jan Beulich]

On 07.09.2023 03:22, Stefano Stabellini wrote:
> @@ -385,6 +386,17 @@ maintainers if you want to suggest a change.
>   - A loop counter shall not have essentially floating type
>   -
>  
> +   * - `Rule 14.3 
> `_
> + - Required
> + - Controlling expressions shall not be invariant
> + - Due to the extensive usage of IS_ENABLED, sizeof compile-time
> +   checks, and other constructs that are detected as errors by MISRA
> +   C scanners, managing the configuration of a MISRA C scanner for
> +   this rule would be unmanageable. Thus, this rule is adopted with
> +   a project-wide deviation on if ?: and switch statements.

Do we want to go as far as permitting this uniformly for all switch()? In
my earlier reply I had included sizeof() for a reason.

Also (nit) there's at least a comma missing after "if". To make clear it's
keywords that are meant, maybe better use if() / switch()?

Jan

Re: [XEN PATCH v2 1/2] xen: apply deviation for Rule 8.4 (asm-only definitions)

[Jan Beulich]

On 07.09.2023 03:08, Stefano Stabellini wrote:
> On Wed, 6 Sep 2023, Nicola Vetrini wrote:
>> As stated in 'docs/misra/rules.rst' the functions that are used only by
>> asm modules do not need to conform to MISRA C:2012 Rule 8.4.
>> The deviations are carried out with a SAF comment.
>>
>> Signed-off-by: Nicola Vetrini 
> 
> This is better
> 
> Reviewed-by: Stefano Stabellini 

Acked-by: Jan Beulich 

[PATCH v3] MAINTAINERS: generalize vm-event/monitor entry

[Jan Beulich]

Replace Arm- and x86-specific lines with wildcard ones, thus covering
all architectures. Uniformly permit an extra sub-directory level to be
used, as is already the case for xen/include/.

Signed-off-by: Jan Beulich 
---
v3: Unfold, for F: not being handled as originally expected.
v2: Further fold patterns.
---
Triggered by me looking at the entry in the context of Oleksii's RISC-V
preparatory patch.

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -559,14 +559,18 @@ R:Alexandru Isaila 
 S: Supported
 F: tools/misc/xen-access.c
+F: xen/arch/*/*/mem_access.c
+F: xen/arch/*/*/monitor.c
+F: xen/arch/*/*/vm_event.c
+F: xen/arch/*/include/asm/*/mem_access.h
+F: xen/arch/*/include/asm/*/monitor.h
+F: xen/arch/*/include/asm/*/vm_event.h
+F: xen/arch/*/include/asm/mem_access.h
+F: xen/arch/*/include/asm/monitor.h
+F: xen/arch/*/include/asm/vm_event.h
+F: xen/arch/*/mem_access.c
 F: xen/arch/*/monitor.c
 F: xen/arch/*/vm_event.c
-F: xen/arch/arm/mem_access.c
-F: xen/arch/x86/include/asm/hvm/monitor.h
-F: xen/arch/x86/include/asm/hvm/vm_event.h
-F: xen/arch/x86/mm/mem_access.c
-F: xen/arch/x86/hvm/monitor.c
-F: xen/arch/x86/hvm/vm_event.c
 F: xen/common/mem_access.c
 F: xen/common/monitor.c
 F: xen/common/vm_event.c

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-migrupgrade 11 xen-install/dst_host fail pass in 182716-retest

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

version targeted for testing:
 xen  9a216e92de9f9011097e4f1fb55ff67ba0a21704
baseline version:
 xen  74b725a64d800822e007e0f449317ff0a8249971

Last test of basis   182632  2023-09-05 11:40:21 Z1

[ovmf test] 182715: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf bbf182229587958b17336c114e0a1525c4f90f3d
baseline version:
 ovmf 4d196352f35ac516b477e568265b4e537b0283d8

Last test of basis   182665  2023-09-06 11:10:57 Z0 days
Testing same since   182715  2023-09-07 06:40:47 Z0 days1 attempts


People who touched revisions under test:
  Sheng Wei 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   4d196352f3..bbf1822295  bbf182229587958b17336c114e0a1525c4f90f3d -> 
xen-tested-master

[PATCH v6 2/2] xen: move arm/include/asm/vm_event.h to asm-generic

[Oleksii Kurochko]

asm/vm_event.h is common for ARM and RISC-V so it will be moved to
asm-generic dir.

Original asm/vm_event.h from ARM was updated:
 * use SPDX-License-Identifier.
 * update comment messages of stubs.
 * update #ifdef
 * instead of "include " -> "public/vm_event.h"

As vm_event.h was moved to asm-generic then it is needed to create
Makefile in arm/include/asm/ and add generated-y += vm_event.h to
it.

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - update the commit message.
---
Changes in V5:
 - Update the commit message
 - Remove Acked-by:...
 - Switch ARM to use asm-generic/vm_event.h
---
Changes in V4:
 - update path of vm_event.h from include/asm-generic/asm to include/asm-generic
---
Changes in V3:
 - add Acked-by: Stefano Stabellini  for "xen: move 
arm/include/asm/vm_event.h to asm-generic"
 - update SPDX tag.
 - move asm/vm_event.h to asm-generic.
---
Changes in V2:
 - change public/domctl.h to public/vm_event.h.
 - update commit message of [PATCH v2 2/2] xen: move arm/include/asm/vm_event.h 
to stubs
---
 xen/arch/arm/include/asm/Makefile   |  2 +
 xen/arch/arm/include/asm/vm_event.h | 66 -
 xen/include/asm-generic/vm_event.h  | 55 
 3 files changed, 57 insertions(+), 66 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/Makefile
 delete mode 100644 xen/arch/arm/include/asm/vm_event.h
 create mode 100644 xen/include/asm-generic/vm_event.h

diff --git a/xen/arch/arm/include/asm/Makefile 
b/xen/arch/arm/include/asm/Makefile
new file mode 100644
index 00..821addb0bf
--- /dev/null
+++ b/xen/arch/arm/include/asm/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+generic-y += vm_event.h
diff --git a/xen/arch/arm/include/asm/vm_event.h 
b/xen/arch/arm/include/asm/vm_event.h
deleted file mode 100644
index 4d861373b3..00
--- a/xen/arch/arm/include/asm/vm_event.h
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * vm_event.h: architecture specific vm_event handling routines
- *
- * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; If not, see .
- */
-
-#ifndef __ASM_ARM_VM_EVENT_H__
-#define __ASM_ARM_VM_EVENT_H__
-
-#include 
-#include 
-
-static inline int vm_event_init_domain(struct domain *d)
-{
-/* Nothing to do. */
-return 0;
-}
-
-static inline void vm_event_cleanup_domain(struct domain *d)
-{
-memset(&d->monitor, 0, sizeof(d->monitor));
-}
-
-static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v,
-  vm_event_response_t *rsp)
-{
-/* Not supported on ARM. */
-}
-
-static inline
-void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
-{
-/* Not supported on ARM. */
-}
-
-static inline
-void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
-{
-/* Not supported on ARM. */
-}
-
-static inline
-void vm_event_sync_event(struct vcpu *v, bool value)
-{
-/* Not supported on ARM. */
-}
-
-static inline
-void vm_event_reset_vmtrace(struct vcpu *v)
-{
-/* Not supported on ARM. */
-}
-
-#endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-generic/vm_event.h 
b/xen/include/asm-generic/vm_event.h
new file mode 100644
index 00..29ab1b01b4
--- /dev/null
+++ b/xen/include/asm-generic/vm_event.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier:  GPL-2.0-only */
+/*
+ * vm_event.h: stubs for architecture specific vm_event handling routines
+ *
+ * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
+ */
+
+#ifndef __ASM_STUB_VM_EVENT_H__
+#define __ASM_STUB_VM_EVENT_H__
+
+#include 
+#include 
+
+static inline int vm_event_init_domain(struct domain *d)
+{
+/* Nothing to do. */
+return 0;
+}
+
+static inline void vm_event_cleanup_domain(struct domain *d)
+{
+memset(&d->monitor, 0, sizeof(d->monitor));
+}
+
+static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v,
+  vm_event_response_t *rsp)
+{
+/* Nothing to do. */
+}
+
+static inline
+void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
+{
+/* Nothing to do. */
+}
+
+static inline
+void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
+{
+/* Nothing to do. */
+}
+
+static inline
+void vm_event_sync_event(struct vcpu *v, bool value)
+{
+/* Nothing to do. */
+}
+
+static inline
+void vm_event_reset_vmtrace(st

[PATCH v6 1/2] xen: asm-generic support

[Oleksii Kurochko]

Some headers are shared between individual architectures or are empty.
To avoid duplication of these headers, asm-generic is introduced.

With the following patch, an architecture uses generic headers
mentioned in the file arch/$(ARCH)/include/asm/Makefile

To use a generic header is needed to add to
arch/$(ARCH)/include/asm/Makefile :
generic-y += 

For each mentioned header in arch/$(ARCH)/include/asm/Makefile,
the necessary wrapper in arch/$(ARCH)/include/generated/asm will be
generated.

As the base Makefile.asm-generic from Linux kernel was taken.
( 06c2afb862f9da8 "Linux 6.5-rc1" ).

Signed-off-by: Oleksii Kurochko 
---
Changes in V6:
 - introduce $(asm-generic) macro in Kbuild.include.
 - move "asm-generic" after the rule "__distclean".
---
Changes in V5:
 - Update the commit message
 - Update SPDX license in Makefile.
 - Remove code related to UML
 - Include $(src)/Makefile instead of $(kbuild-file) 
 - Update comment message in Makefile.asm-generic
 - Update .gitignore
 - Update path to generated headers in CFLAGS.
 - Use the latest version of Linux's Makefile.asm-generic
---
Changes in V4:
 - introduce asm-generic support
 - update commit message
---
Changes in V3:
 - Rename stubs dir to asm-generic
---
Changes in V2:
 - Nothing changed.
---
 .gitignore   |  1 +
 xen/Makefile |  9 +-
 xen/scripts/Kbuild.include   |  6 
 xen/scripts/Makefile.asm-generic | 53 
 4 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 xen/scripts/Makefile.asm-generic

diff --git a/.gitignore b/.gitignore
index 50273adb8d..287166f8fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -267,6 +267,7 @@ xen/arch/*/efi/efi.h
 xen/arch/*/efi/pe.c
 xen/arch/*/efi/runtime.c
 xen/arch/*/include/asm/asm-offsets.h
+xen/arch/*/include/generated
 xen/build-dir-cppcheck/
 xen/common/config_data.S
 xen/common/config.gz
diff --git a/xen/Makefile b/xen/Makefile
index f57e5a596c..2dc5e3526d 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -438,6 +438,7 @@ ifdef building_out_of_srctree
 endif
 CFLAGS += -I$(srctree)/include
 CFLAGS += -I$(srctree)/arch/$(SRCARCH)/include
+CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include/generated
 
 # Note that link order matters!
 ALL_OBJS-y:= common/built_in.o
@@ -580,16 +581,22 @@ _clean:
rm -f $(TARGET).efi $(TARGET).efi.map $(TARGET).efi.elf 
$(TARGET).efi.stripped
rm -f asm-offsets.s arch/*/include/asm/asm-offsets.h
rm -f .banner .allconfig.tmp include/xen/compile.h
+   rm -rf $(objtree)/arch/*/include/generated
 
 .PHONY: _distclean
 _distclean: clean
rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out 
GTAGS GPATH GRTAGS GSYMS .config source
 
+# Support for using generic headers in asm-generic
+PHONY += asm-generic
+asm-generic:
+   $(Q)$(MAKE) $(asm-generic)=arch/$(SRCARCH)/include/generated/asm
+
 $(TARGET).gz: $(TARGET)
gzip -n -f -9 < $< > $@.new
mv $@.new $@
 
-$(TARGET): outputmakefile FORCE
+$(TARGET): outputmakefile asm-generic FORCE
$(Q)$(MAKE) $(build)=tools
$(Q)$(MAKE) $(build)=. include/xen/compile.h
$(Q)$(MAKE) $(build)=include all
diff --git a/xen/scripts/Kbuild.include b/xen/scripts/Kbuild.include
index 785a32c32e..c2bd8498e1 100644
--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -91,6 +91,12 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 
] && echo $(3) || e
 
 clang-ifversion = $(shell [ $(CONFIG_CLANG_VERSION)0 $(1) $(2)000 ] && echo 
$(3) || echo $(4))
 
+###
+# Shorthand for $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.asm-generic obj
+# Usage:
+# $(Q)$(MAKE) $(asm-generic)=dir
+asm-generic := -f $(srctree)/scripts/Makefile.asm-generic obj
+
 ###
 # Shorthand for $(Q)$(MAKE) -f scripts/Makefile.build obj=
 # Usage:
diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
new file mode 100644
index 00..92a3a741c5
--- /dev/null
+++ b/xen/scripts/Makefile.asm-generic
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# include/asm-generic contains a lot of files that are used
+# verbatim by several architectures.
+#
+# This Makefile reads the file arch/$(SRCARCH)/include/asm/Makefile
+# and for each file listed in this file with generic-y creates
+# a small wrapper file in arch/$(SRCARCH)/include/generated/asm.
+
+PHONY := all
+all:
+
+src := $(subst /generated,,$(obj))
+
+include $(srctree)/scripts/Kbuild.include
+-include $(src)/Makefile
+
+redundant := $(filter $(mandatory-y) $(generated-y), $(generic-y))
+redundant += $(foreach f, $(generic-y), $(if $(wildcard 
$(srctree)/$(src)/$(f)),$(f)))
+redundant := $(sort $(redundant))
+$(if $(redundant),\
+   $(warning redundant generic-y found in $(src)/Kbuild: $(redundant)))
+
+# If arch does not implement mandatory headers, fallback to asm-generic ones.
+mandatory-y := $(filter-out $(generated-y), $(mandatory-y))
+generic-y   += $(foreach f, $(man

[PATCH v6 0/2] introduce stub directory to storing empty/stub headers

[Oleksii Kurochko]

A lot of empty/stub headers should be introduced during the early steps of 
adding
support of new architecture.

An example can be found here:
1. 
https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kuroc...@gmail.com/
2. 
https://lore.kernel.org/xen-devel/a92f99e8f697da99d77bfde562a549dbef3760ce.1692816595.git.sanasta...@raptorengineering.com/

As part of the patch series, asm/vm_event.h was moved to the stubs directory 
because
It is the same for ARM, PPC, and RISC-V.

---
Changes in V6:
 - introduce $(asm-generic) macro in Kbuild.include.
 - move "asm-generic" after the rule "__distclean".
 - update the commit message.
---
Changes in V5:
- Update SPDX license.
- Remove code related to UML in Makefile.asm-generic.
- Include $(src)/Makefile instead of $(kbuild-file).
- Update comment message in Makefile.asm-generic.
- Update .gitignore.
- Update path to generated headers in CFLAGS.
- Use the latest version of Linux's Makefile.asm-generic.
- Introduce asm-generic's vm_event.h.
- Switch ARM to use asm-generic/vm_event.h.
---
Changes in V4:
 - add asm-generic support
 - update path of vm_event.h from include/asm-generic/asm to include/asm-generic
---
Changes in V3:
 - add Acked-by: Stefano Stabellini  for "xen: move 
arm/include/asm/vm_event.h to asm-generic"
 - update SPDX tag.
 - move asm/vm_event.h to asm-generic.
 - rename stubs dir to asm-generic.

---
Changes in V2:
 - change public/domctl.h to public/vm_event.h.
 - update commit message of [PATCH v2 2/2] xen: move arm/include/asm/vm_event.h 
to stubs

Oleksii Kurochko (2):
  xen: asm-generic support
  xen: move arm/include/asm/vm_event.h to asm-generic

 .gitignore  |  1 +
 xen/Makefile|  9 +++-
 xen/arch/arm/include/asm/Makefile   |  2 +
 xen/arch/arm/include/asm/vm_event.h | 66 -
 xen/include/asm-generic/vm_event.h  | 55 
 xen/scripts/Kbuild.include  |  6 +++
 xen/scripts/Makefile.asm-generic| 53 +++
 7 files changed, 125 insertions(+), 67 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/Makefile
 delete mode 100644 xen/arch/arm/include/asm/vm_event.h
 create mode 100644 xen/include/asm-generic/vm_event.h
 create mode 100644 xen/scripts/Makefile.asm-generic

-- 
2.41.0

Re: [PATCH v3] MAINTAINERS: generalize vm-event/monitor entry

[Anthony PERARD]

On Thu, Sep 07, 2023 at 09:45:55AM +0200, Jan Beulich wrote:
> Replace Arm- and x86-specific lines with wildcard ones, thus covering
> all architectures. Uniformly permit an extra sub-directory level to be
> used, as is already the case for xen/include/.
> 
> Signed-off-by: Jan Beulich 
> ---
> v3: Unfold, for F: not being handled as originally expected.

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

Re: [PATCH v6 01/13] xen/arm64: head.S: Introduce enable_{boot,secondary}_cpu_mm()

[Ayan Kumar Halder]

Hi Henry,

On 28/08/2023 02:32, Henry Wang wrote:

CAUTION: This message has originated from an External Source. Please use proper 
judgment and caution when opening attachments, clicking links, or responding to 
this email.


From: Wei Chen 

At the moment, on MMU system, enable_mmu() will return to an
address in the 1:1 mapping, then each path is responsible to
switch to virtual runtime mapping. Then remove_identity_mapping()
is called on the boot CPU to remove all 1:1 mapping.

Since remove_identity_mapping() is not necessary on Non-MMU system,
and we also avoid creating empty function for Non-MMU system, trying
to keep only one codeflow in arm64/head.S, we move path switch and
remove_identity_mapping() in enable_mmu() on MMU system.

As the remove_identity_mapping should only be called for the boot
CPU only, so we introduce enable_boot_cpu_mm() for boot CPU and
enable_secondary_cpu_mm() for secondary CPUs in this patch.

Signed-off-by: Wei Chen 
Signed-off-by: Penny Zheng 
Signed-off-by: Henry Wang 
Reviewed-by: Julien Grall 
---
v6:
- Add Julien's Reviewed-by tag.
v5:
- Add missing "()" in title.
- Use more generic comment in enable_{boot,secondary}_cpu_mm() to
   mention function will return to the vaddr requested by the caller.
- Move 'mov lr, x5' closer to 'b remove_identity_mapping'.
- Drop the 'b fail' for unreachable code in enable_boot_cpu_mm().
v4:
- Clarify remove_identity_mapping() is called on boot CPU and keep
   the function/proc format consistent in commit msg.
- Drop inaccurate (due to the refactor) in-code comment.
- Rename enable_{boot,runtime}_mmu to enable_{boot,secondary}_cpu_mm.
- Reword the in-code comment on top of enable_{boot,secondary}_cpu_mm.
- Call "fail" for unreachable code.
v3:
- new patch
---
  xen/arch/arm/arm64/head.S | 83 ++-
  1 file changed, 64 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 5029013a14..f25a41d36c 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -325,21 +325,11 @@ real_start_efi:

  blcheck_cpu_mode
  blcpu_init
-blcreate_page_tables
-load_paddr x0, boot_pgtable
-blenable_mmu

-/* We are still in the 1:1 mapping. Jump to the runtime Virtual 
Address. */
-ldr   x0, =primary_switched
-brx0
+ldr   lr, =primary_switched
+b enable_boot_cpu_mm
+
  primary_switched:
-/*
- * The 1:1 map may clash with other parts of the Xen virtual memory
- * layout. As it is not used anymore, remove it completely to
- * avoid having to worry about replacing existing mapping
- * afterwards.
- */
-blremove_identity_mapping
  blsetup_fixmap
  #ifdef CONFIG_EARLY_PRINTK
  /* Use a virtual address to access the UART. */
@@ -384,13 +374,10 @@ GLOBAL(init_secondary)
  #endif
  blcheck_cpu_mode
  blcpu_init
-load_paddr x0, init_ttbr
-ldr   x0, [x0]
-blenable_mmu

-/* We are still in the 1:1 mapping. Jump to the runtime Virtual 
Address. */
-ldr   x0, =secondary_switched
-brx0
+ldr   lr, =secondary_switched
+b enable_secondary_cpu_mm
+
  secondary_switched:
  #ifdef CONFIG_EARLY_PRINTK
  /* Use a virtual address to access the UART. */
@@ -748,6 +735,64 @@ enable_mmu:
  ret
  ENDPROC(enable_mmu)

+/*
+ * Enable mm (turn on the data cache and the MMU) for secondary CPUs.
+ * The function will return to the virtual address provided in LR (e.g. the
+ * runtime mapping).
+ *
+ * Inputs:
+ *   lr : Virtual address to return to.
+ *
+ * Clobbers x0 - x5
+ */
+enable_secondary_cpu_mm:
+mov   x5, lr
+
+load_paddr x0, init_ttbr
+ldr   x0, [x0]
+
+blenable_mmu
+mov   lr, x5
+
+/* Return to the virtual address requested by the caller. */
+ret
+ENDPROC(enable_secondary_cpu_mm)
+
+/*
+ * Enable mm (turn on the data cache and the MMU) for the boot CPU.
+ * The function will return to the virtual address provided in LR (e.g. the
+ * runtime mapping).
+ *
+ * Inputs:
+ *   lr : Virtual address to return to.
+ *
+ * Clobbers x0 - x5
+ */
+enable_boot_cpu_mm:
+mov   x5, lr
+
+blcreate_page_tables
+load_paddr x0, boot_pgtable
+
+blenable_mmu
+
+/*
+ * The MMU is turned on and we are in the 1:1 mapping. Switch
+ * to the runtime mapping.
+ */
+ldr   x0, =1f
+brx0
+1:
+mov   lr, x5
+/*
+ * The 1:1 map may clash with other parts of the Xen virtual memory
+ * layout. As it is not used anymore, remove it completely to avoid
+ * having to worry about replacing existing mapping afterwards.
+ * Function will return to the virtual address requested by the caller.
+ */
+b remove_iden

Re: [PATCH v6 2/2] xen: move arm/include/asm/vm_event.h to asm-generic

[Jan Beulich]

On 07.09.2023 11:32, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/vm_event.h
> @@ -0,0 +1,55 @@
> +/* SPDX-License-Identifier:  GPL-2.0-only */
> +/*
> + * vm_event.h: stubs for architecture specific vm_event handling routines
> + *
> + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)

Tamas is the maintainer of these files (no matter where they live), so
please make sure to Cc him in order to get his ack.

> + */
> +
> +#ifndef __ASM_STUB_VM_EVENT_H__
> +#define __ASM_STUB_VM_EVENT_H__

Nit: s/STUB/GENERIC/ ?

Jan

Re: [PATCH v6 1/2] xen: asm-generic support

[Anthony PERARD]

On Thu, Sep 07, 2023 at 12:32:56PM +0300, Oleksii Kurochko wrote:
> diff --git a/xen/scripts/Makefile.asm-generic 
> b/xen/scripts/Makefile.asm-generic
> new file mode 100644
> index 00..92a3a741c5
> --- /dev/null
> +++ b/xen/scripts/Makefile.asm-generic
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +# include/asm-generic contains a lot of files that are used
> +# verbatim by several architectures.
> +#
> +# This Makefile reads the file arch/$(SRCARCH)/include/asm/Makefile
> +# and for each file listed in this file with generic-y creates
> +# a small wrapper file in arch/$(SRCARCH)/include/generated/asm.
> +
> +PHONY := all
> +all:
> +
> +src := $(subst /generated,,$(obj))
> +
> +include $(srctree)/scripts/Kbuild.include
> +-include $(src)/Makefile
> +
> +redundant := $(filter $(mandatory-y) $(generated-y), $(generic-y))
> +redundant += $(foreach f, $(generic-y), $(if $(wildcard 
> $(srctree)/$(src)/$(f)),$(f)))
> +redundant := $(sort $(redundant))
> +$(if $(redundant),\
> + $(warning redundant generic-y found in $(src)/Kbuild: $(redundant)))

This warning would need to say "$(src)/Makefile" now instead of Kbuild.

Beside this, patch looks fine to me:
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

Re: [PATCH v2] tests/vpci: install test

[Anthony PERARD]

On Mon, Mar 13, 2023 at 01:12:26PM +0100, Roger Pau Monne wrote:
> diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
> index 5075bc2be2..11f1ee7126 100644
> --- a/tools/tests/vpci/Makefile
> +++ b/tools/tests/vpci/Makefile
> @@ -1,27 +1,37 @@
>  XEN_ROOT=$(CURDIR)/../../..
>  include $(XEN_ROOT)/tools/Rules.mk
>  
> -TARGET := test_vpci
> +TARGET := test-vpci
>  
>  .PHONY: all
>  all: $(TARGET)
>  
>  .PHONY: run
>  run: $(TARGET)
> +ifeq ($(CC),$(HOSTCC))
>   ./$(TARGET)
> +else
> + $(warning HOSTCC != CC, cannot run test)
> +endif
>  
>  $(TARGET): vpci.c vpci.h list.h main.c emul.h
> - $(HOSTCC) -g -o $@ vpci.c main.c
> + $(CC) $(CFLAGS) -o $@ vpci.c main.c

This now needs $(CFLAGS_xeninclude) to build, so
"CFLAGS += $(CFLAGS_xeninclude)" somewhere in the file.


Also, there's another change needed as we've got this error:

vpci.c:344:29: error: ‘dom_xen’ undeclared (first use in this function)
  344 | pdev = pci_get_pdev(dom_xen, sbdf);


Otherwise, patch looks fine to me.

Thanks,

-- 
Anthony PERARD

Re: [PATCH v6 1/2] xen: asm-generic support

[Jan Beulich]

On 07.09.2023 11:32, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/scripts/Makefile.asm-generic
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +# include/asm-generic contains a lot of files that are used
> +# verbatim by several architectures.
> +#
> +# This Makefile reads the file arch/$(SRCARCH)/include/asm/Makefile
> +# and for each file listed in this file with generic-y creates
> +# a small wrapper file in arch/$(SRCARCH)/include/generated/asm.
> +
> +PHONY := all
> +all:
> +
> +src := $(subst /generated,,$(obj))
> +
> +include $(srctree)/scripts/Kbuild.include
> +-include $(src)/Makefile

With the definition of src above, is this correct for out-of-tree builds?
You want to reference the Makefile in the source tree, ...

> +redundant := $(filter $(mandatory-y) $(generated-y), $(generic-y))
> +redundant += $(foreach f, $(generic-y), $(if $(wildcard 
> $(srctree)/$(src)/$(f)),$(f)))

... much like $(srctree) is used here (and similarly again further down).

Jan

Re: [PATCH v6 01/13] xen/arm64: head.S: Introduce enable_{boot,secondary}_cpu_mm()

[Penny Zheng]

Hi Ayan

On 2023/9/7 17:44, Ayan Kumar Halder wrote:

Hi Henry,

On 28/08/2023 02:32, Henry Wang wrote:
CAUTION: This message has originated from an External Source. Please 
use proper judgment and caution when opening attachments, clicking 
links, or responding to this email.



From: Wei Chen 

At the moment, on MMU system, enable_mmu() will return to an
address in the 1:1 mapping, then each path is responsible to
switch to virtual runtime mapping. Then remove_identity_mapping()
is called on the boot CPU to remove all 1:1 mapping.

Since remove_identity_mapping() is not necessary on Non-MMU system,
and we also avoid creating empty function for Non-MMU system, trying
to keep only one codeflow in arm64/head.S, we move path switch and
remove_identity_mapping() in enable_mmu() on MMU system.

As the remove_identity_mapping should only be called for the boot
CPU only, so we introduce enable_boot_cpu_mm() for boot CPU and
enable_secondary_cpu_mm() for secondary CPUs in this patch.

Signed-off-by: Wei Chen 
Signed-off-by: Penny Zheng 
Signed-off-by: Henry Wang 
Reviewed-by: Julien Grall 
---
v6:
- Add Julien's Reviewed-by tag.
v5:
- Add missing "()" in title.
- Use more generic comment in enable_{boot,secondary}_cpu_mm() to
   mention function will return to the vaddr requested by the caller.
- Move 'mov lr, x5' closer to 'b remove_identity_mapping'.
- Drop the 'b fail' for unreachable code in enable_boot_cpu_mm().
v4:
- Clarify remove_identity_mapping() is called on boot CPU and keep
   the function/proc format consistent in commit msg.
- Drop inaccurate (due to the refactor) in-code comment.
- Rename enable_{boot,runtime}_mmu to enable_{boot,secondary}_cpu_mm.
- Reword the in-code comment on top of enable_{boot,secondary}_cpu_mm.
- Call "fail" for unreachable code.
v3:
- new patch
---
  xen/arch/arm/arm64/head.S | 83 ++-
  1 file changed, 64 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 5029013a14..f25a41d36c 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -325,21 +325,11 @@ real_start_efi:

  bl    check_cpu_mode
  bl    cpu_init
-    bl    create_page_tables
-    load_paddr x0, boot_pgtable
-    bl    enable_mmu

-    /* We are still in the 1:1 mapping. Jump to the runtime 
Virtual Address. */

-    ldr   x0, =primary_switched
-    br    x0
+    ldr   lr, =primary_switched
+    b enable_boot_cpu_mm
+
  primary_switched:
-    /*
- * The 1:1 map may clash with other parts of the Xen virtual 
memory

- * layout. As it is not used anymore, remove it completely to
- * avoid having to worry about replacing existing mapping
- * afterwards.
- */
-    bl    remove_identity_mapping
  bl    setup_fixmap
  #ifdef CONFIG_EARLY_PRINTK
  /* Use a virtual address to access the UART. */
@@ -384,13 +374,10 @@ GLOBAL(init_secondary)
  #endif
  bl    check_cpu_mode
  bl    cpu_init
-    load_paddr x0, init_ttbr
-    ldr   x0, [x0]
-    bl    enable_mmu

-    /* We are still in the 1:1 mapping. Jump to the runtime 
Virtual Address. */

-    ldr   x0, =secondary_switched
-    br    x0
+    ldr   lr, =secondary_switched
+    b enable_secondary_cpu_mm
+
  secondary_switched:
  #ifdef CONFIG_EARLY_PRINTK
  /* Use a virtual address to access the UART. */
@@ -748,6 +735,64 @@ enable_mmu:
  ret
  ENDPROC(enable_mmu)

+/*
+ * Enable mm (turn on the data cache and the MMU) for secondary CPUs.
+ * The function will return to the virtual address provided in LR 
(e.g. the

+ * runtime mapping).
+ *
+ * Inputs:
+ *   lr : Virtual address to return to.
+ *
+ * Clobbers x0 - x5
+ */
+enable_secondary_cpu_mm:
+    mov   x5, lr
+
+    load_paddr x0, init_ttbr
+    ldr   x0, [x0]
+
+    bl    enable_mmu
+    mov   lr, x5
+
+    /* Return to the virtual address requested by the caller. */
+    ret
+ENDPROC(enable_secondary_cpu_mm)
+
+/*
+ * Enable mm (turn on the data cache and the MMU) for the boot CPU.
+ * The function will return to the virtual address provided in LR 
(e.g. the

+ * runtime mapping).
+ *
+ * Inputs:
+ *   lr : Virtual address to return to.
+ *
+ * Clobbers x0 - x5
+ */
+enable_boot_cpu_mm:
+    mov   x5, lr
+
+    bl    create_page_tables
+    load_paddr x0, boot_pgtable
+
+    bl    enable_mmu
+
+    /*
+ * The MMU is turned on and we are in the 1:1 mapping. Switch
+ * to the runtime mapping.
+ */
+    ldr   x0, =1f
+    br    x0
+1:
+    mov   lr, x5
+    /*
+ * The 1:1 map may clash with other parts of the Xen virtual 
memory
+ * layout. As it is not used anymore, remove it completely to 
avoid

+ * having to worry about replacing existing mapping afterwards.
+ * Function will return to the virtual address

Re: [PATCH v7 9/9] swiotlb: search the software IO TLB only if the device makes use of it

[Petr Tesařík]

Hi all,

sorry for my late reply; I've been away from my work setup for a
month...

On Wed, 30 Aug 2023 08:55:51 -0600
Jonathan Corbet  wrote:

> So it seems this code got merged without this question ever being
> answered.  Sorry if it's a dumb one, but I don't think this
> functionality works as advertised...

Yes, I believe the check was originally in is_swiotlb_buffer(), but it
got lost during one of the numerous rebases of this patch set. Let me
send a follow-up patch after making sure it actually works.

Petr T

> Thanks,
> 
> jon
> 
> Jonathan Corbet  writes:
> 
> > Petr Tesarik  writes:
> >  
> >> From: Petr Tesarik 
> >>
> >> Skip searching the software IO TLB if a device has never used it,
> >> making sure these devices are not affected by the introduction of
> >> multiple IO TLB memory pools.
> >>
> >> Additional memory barrier is required to ensure that the new value
> >> of the flag is visible to other CPUs after mapping a new bounce
> >> buffer. For efficiency, the flag check should be inlined, and then
> >> the memory barrier must be moved to is_swiotlb_buffer(). However,
> >> it can replace the existing barrier in swiotlb_find_pool(),
> >> because all callers use is_swiotlb_buffer() first to verify that
> >> the buffer address belongs to the software IO TLB.
> >>
> >> Signed-off-by: Petr Tesarik 
> >> ---  
> >
> > Excuse me if this is a silly question, but I'm not able to figure
> > it out on my own...
> >  
> >>  include/linux/device.h  |  2 ++
> >>  include/linux/swiotlb.h |  7 ++-
> >>  kernel/dma/swiotlb.c| 14 ++
> >>  3 files changed, 14 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/include/linux/device.h b/include/linux/device.h
> >> index 5fd89c9d005c..6fc808d22bfd 100644
> >> --- a/include/linux/device.h
> >> +++ b/include/linux/device.h
> >> @@ -628,6 +628,7 @@ struct device_physical_location {
> >>   * @dma_io_tlb_mem: Software IO TLB allocator.  Not for driver
> >> use.
> >>   * @dma_io_tlb_pools: List of transient swiotlb memory
> >> pools.
> >>   * @dma_io_tlb_lock:  Protects changes to the list of
> >> active pools.
> >> + * @dma_uses_io_tlb: %true if device has used the software IO TLB.
> >>   * @archdata: For arch-specific additions.
> >>   * @of_node:  Associated device tree node.
> >>   * @fwnode:   Associated device node supplied by platform
> >> firmware. @@ -737,6 +738,7 @@ struct device {
> >>  #ifdef CONFIG_SWIOTLB_DYNAMIC
> >>struct list_head dma_io_tlb_pools;
> >>spinlock_t dma_io_tlb_lock;
> >> +  bool dma_uses_io_tlb;  
> >
> > You add this new member here, fine...
> >  
> >>  #endif
> >>/* arch specific additions */
> >>struct dev_archdata archdata;
> >> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> >> index 8371c92a0271..b4536626f8ff 100644
> >> --- a/include/linux/swiotlb.h
> >> +++ b/include/linux/swiotlb.h
> >> @@ -172,8 +172,13 @@ static inline bool is_swiotlb_buffer(struct
> >> device *dev, phys_addr_t paddr) if (!mem)
> >>return false;
> >>  
> >> -  if (IS_ENABLED(CONFIG_SWIOTLB_DYNAMIC))
> >> +  if (IS_ENABLED(CONFIG_SWIOTLB_DYNAMIC)) {
> >> +  /* Pairs with smp_wmb() in swiotlb_find_slots()
> >> and
> >> +   * swiotlb_dyn_alloc(), which modify the RCU
> >> lists.
> >> +   */
> >> +  smp_rmb();
> >>return swiotlb_find_pool(dev, paddr);
> >> +  }
> >>return paddr >= mem->defpool.start && paddr <
> >> mem->defpool.end; }
> >>  
> >> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> >> index adf80dec42d7..d7eac84f975b 100644
> >> --- a/kernel/dma/swiotlb.c
> >> +++ b/kernel/dma/swiotlb.c
> >> @@ -730,7 +730,7 @@ static void swiotlb_dyn_alloc(struct
> >> work_struct *work) 
> >>add_mem_pool(mem, pool);
> >>  
> >> -  /* Pairs with smp_rmb() in swiotlb_find_pool(). */
> >> +  /* Pairs with smp_rmb() in is_swiotlb_buffer(). */
> >>smp_wmb();
> >>  }
> >>  
> >> @@ -764,11 +764,6 @@ struct io_tlb_pool *swiotlb_find_pool(struct
> >> device *dev, phys_addr_t paddr) struct io_tlb_mem *mem =
> >> dev->dma_io_tlb_mem; struct io_tlb_pool *pool;
> >>  
> >> -  /* Pairs with smp_wmb() in swiotlb_find_slots() and
> >> -   * swiotlb_dyn_alloc(), which modify the RCU lists.
> >> -   */
> >> -  smp_rmb();
> >> -
> >>rcu_read_lock();
> >>list_for_each_entry_rcu(pool, &mem->pools, node) {
> >>if (paddr >= pool->start && paddr < pool->end)
> >> @@ -813,6 +808,7 @@ void swiotlb_dev_init(struct device *dev)
> >>  #ifdef CONFIG_SWIOTLB_DYNAMIC
> >>INIT_LIST_HEAD(&dev->dma_io_tlb_pools);
> >>spin_lock_init(&dev->dma_io_tlb_lock);
> >> +  dev->dma_uses_io_tlb = false;  
> >
> > ...here you initialize it, fine...
> >  
> >>  #endif
> >>  }
> >>  
> >> @@ -1157,9 +1153,11 @@ static int swiotlb_find_slots(struct device
> >> *dev, phys_addr_t orig_addr, list_add_rcu(&pool->node,
> >> &dev->dma_io_tlb_pools);
> >> spin_unlock_irqrestore(&dev->dma_io_tlb_lock, flags); 
> >> -  /* Pairs with smp_rmb

Re: [PATCH v6 09/13] xen/arm: Extract MMU-specific MM code

[Ayan Kumar Halder]

Hi Henry,

On 28/08/2023 02:32, Henry Wang wrote:

CAUTION: This message has originated from an External Source. Please use proper 
judgment and caution when opening attachments, clicking links, or responding to 
this email.


Currently, most of the code is in arm/mm.{c,h} and arm/arm64/mm.c
is MMU-specific. To make the MM code extendable, this commit extracts
the MMU-specific MM code.

Extract the boot CPU MM bringup code from arm/mm.c to mmu/setup.c.
Move arm/arm64/mm.c to arm/arm64/mmu/mm.c. Since the function
setup_directmap_mappings() has different implementations between
arm32 and arm64, move their arch-specific implementation to
arch-specific arm{32,64}/mmu/mm.c instead using #ifdef again.

For header files, move MMU-related function declarations in
asm/mm.h and the declaration of dump_pt_walk() in asm/page.h to
asm/mmu/mm.h

Also modify the build system (Makefiles in this case) to pick above
mentioned code changes.

Take the opportunity to fix the in-code comment coding styles when
possible, and drop the unnecessary #include headers in the original
arm/mm.c.

Signed-off-by: Henry Wang 
Signed-off-by: Penny Zheng 
---
v6:
- Rework the original patch
   "[v5,07/13] xen/arm: Extract MMU-specific code"
---
  xen/arch/arm/arm32/Makefile   |   1 +
  xen/arch/arm/arm32/mmu/Makefile   |   1 +
  xen/arch/arm/arm32/mmu/mm.c   |  31 +++
  xen/arch/arm/arm64/Makefile   |   1 -
  xen/arch/arm/arm64/mmu/Makefile   |   1 +
  xen/arch/arm/arm64/{ => mmu}/mm.c |  37 +++
  xen/arch/arm/include/asm/mm.h |  22 +-
  xen/arch/arm/include/asm/mmu/mm.h |  47 
  xen/arch/arm/include/asm/page.h   |  15 --
  xen/arch/arm/mm.c | 381 --
  xen/arch/arm/mmu/Makefile |   1 +
  xen/arch/arm/mmu/setup.c  | 345 +++
  12 files changed, 470 insertions(+), 413 deletions(-)
  create mode 100644 xen/arch/arm/arm32/mmu/Makefile
  create mode 100644 xen/arch/arm/arm32/mmu/mm.c
  rename xen/arch/arm/arm64/{ => mmu}/mm.c (75%)
  create mode 100644 xen/arch/arm/include/asm/mmu/mm.h
  create mode 100644 xen/arch/arm/mmu/setup.c

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 520fb42054..40a2b4803f 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -1,4 +1,5 @@
  obj-y += lib/
+obj-$(CONFIG_MMU) += mmu/

  obj-$(CONFIG_EARLY_PRINTK) += debug.o
  obj-y += domctl.o
diff --git a/xen/arch/arm/arm32/mmu/Makefile b/xen/arch/arm/arm32/mmu/Makefile
new file mode 100644
index 00..b18cec4836
--- /dev/null
+++ b/xen/arch/arm/arm32/mmu/Makefile
@@ -0,0 +1 @@
+obj-y += mm.o
diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
new file mode 100644
index 00..647baf4a81
--- /dev/null
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include 
+#include 
+
+/*
+ * Set up the direct-mapped xenheap:
+ * up to 1GB of contiguous, always-mapped memory.
+ */
+void __init setup_directmap_mappings(unsigned long base_mfn,
+ unsigned long nr_mfns)
+{
+int rc;
+
+rc = map_pages_to_xen(XENHEAP_VIRT_START, _mfn(base_mfn), nr_mfns,
+  PAGE_HYPERVISOR_RW | _PAGE_BLOCK);
+if ( rc )
+panic("Unable to setup the directmap mappings.\n");
+
+/* Record where the directmap is, for translation routines. */
+directmap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index f89d5fb4fb..72161ff22e 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -11,7 +11,6 @@ obj-y += entry.o
  obj-y += head.o
  obj-y += insn.o
  obj-$(CONFIG_LIVEPATCH) += livepatch.o
-obj-y += mm.o
  obj-y += smc.o
  obj-y += smpboot.o
  obj-$(CONFIG_ARM64_SVE) += sve.o sve-asm.o
diff --git a/xen/arch/arm/arm64/mmu/Makefile b/xen/arch/arm/arm64/mmu/Makefile
index 3340058c08..a8a750a3d0 100644
--- a/xen/arch/arm/arm64/mmu/Makefile
+++ b/xen/arch/arm/arm64/mmu/Makefile
@@ -1 +1,2 @@
  obj-y += head.o
+obj-y += mm.o
diff --git a/xen/arch/arm/arm64/mm.c b/xen/arch/arm/arm64/mmu/mm.c
similarity index 75%
rename from xen/arch/arm/arm64/mm.c
rename to xen/arch/arm/arm64/mmu/mm.c
index 78b7c7eb00..36073041ed 100644
--- a/xen/arch/arm/arm64/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -151,6 +151,43 @@ void __init switch_ttbr(uint64_t ttbr)
  update_identity_mapping(false);
  }

+/* Map the region in the directmap area. */
+void __init setup_directmap_mappings(unsigned long base_mfn,
+ unsigned long nr_mfns)
+{
+int rc;
+
+/* First call sets the directmap physical and virtual offset. */
+if ( mfn_eq(directmap_mfn_start, INVALID_MFN) )
+{
+unsigned long mfn_gb = base_mfn & ~((FIRST_SIZE >> PAGE_SHIFT) - 1);
+
+di

[linux-linus test] 182689: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-vhd   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-pvshim8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-ws16-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-credit1   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-libvirt-xsm  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-shadow8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemut-win7-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-win7-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-libvirt-raw  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start   fail REGR. vs. 182531
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-freebsd12-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-xl-multivcpu  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-libvirt-qcow2  8 xen-boot   fail REGR. vs. 182531
 test-amd64-amd64-qemuu-nested-intel  8 xen-boot  fail REGR. vs. 182531
 test-amd64-amd64-pair12 xen-boot/src_hostfail REGR. vs. 182531
 test-amd64-amd64-pair13 xen-boot/dst_hostfail REGR. vs. 182531
 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host   fail REGR. vs. 182531
 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host   fail REGR. vs. 182531
 test-amd64-amd64-xl-xsm   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemut-ws16-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-qemuu-nested-amd  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-xl-pvhv2-amd  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-ovmf-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 8 xen-boot fail REGR. 
vs. 182531
 test-amd64-amd64-xl-qemut-debianhvm-amd64  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 182531
 test-amd64-amd64-xl   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-pvhv2-intel  8 xen-boot  fail REGR. vs. 182531
 test-amd64-amd64-libvirt  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-freebsd11-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 
182531
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail REGR. 
vs. 182531
 test-amd64-amd64-pygrub   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-credit2   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-examine-uefi  8 reboot  fail REGR. vs. 182531
 test-amd64-amd64-examine-bios  8 reboot  fail REGR. vs. 182531
 test-amd64-coresched-amd64-xl  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 8 xen-boot fail REGR. vs. 
182531

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  8 xen-boot fail REGR. vs. 182531

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 182531
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 182531
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 182531
 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-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-x

Re: [PATCH v6 01/13] xen/arm64: head.S: Introduce enable_{boot,secondary}_cpu_mm()

[Ayan Kumar Halder]

On 07/09/2023 11:58, Penny Zheng wrote:

Hi Ayan

Hi Penny,


On 2023/9/7 17:44, Ayan Kumar Halder wrote:

Hi Henry,

On 28/08/2023 02:32, Henry Wang wrote:
CAUTION: This message has originated from an External Source. Please 
use proper judgment and caution when opening attachments, clicking 
links, or responding to this email.



From: Wei Chen 

At the moment, on MMU system, enable_mmu() will return to an
address in the 1:1 mapping, then each path is responsible to
switch to virtual runtime mapping. Then remove_identity_mapping()
is called on the boot CPU to remove all 1:1 mapping.

Since remove_identity_mapping() is not necessary on Non-MMU system,
and we also avoid creating empty function for Non-MMU system, trying
to keep only one codeflow in arm64/head.S, we move path switch and
remove_identity_mapping() in enable_mmu() on MMU system.

As the remove_identity_mapping should only be called for the boot
CPU only, so we introduce enable_boot_cpu_mm() for boot CPU and
enable_secondary_cpu_mm() for secondary CPUs in this patch.

Signed-off-by: Wei Chen 
Signed-off-by: Penny Zheng 
Signed-off-by: Henry Wang 
Reviewed-by: Julien Grall 

Reviewed-by: Ayan Kumar Halder 

---
v6:
- Add Julien's Reviewed-by tag.
v5:
- Add missing "()" in title.
- Use more generic comment in enable_{boot,secondary}_cpu_mm() to
   mention function will return to the vaddr requested by the caller.
- Move 'mov lr, x5' closer to 'b remove_identity_mapping'.
- Drop the 'b fail' for unreachable code in enable_boot_cpu_mm().
v4:
- Clarify remove_identity_mapping() is called on boot CPU and keep
   the function/proc format consistent in commit msg.
- Drop inaccurate (due to the refactor) in-code comment.
- Rename enable_{boot,runtime}_mmu to enable_{boot,secondary}_cpu_mm.
- Reword the in-code comment on top of enable_{boot,secondary}_cpu_mm.
- Call "fail" for unreachable code.
v3:
- new patch
---
  xen/arch/arm/arm64/head.S | 83 
++-

  1 file changed, 64 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 5029013a14..f25a41d36c 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -325,21 +325,11 @@ real_start_efi:

  bl    check_cpu_mode
  bl    cpu_init
-    bl    create_page_tables
-    load_paddr x0, boot_pgtable
-    bl    enable_mmu

-    /* We are still in the 1:1 mapping. Jump to the runtime 
Virtual Address. */

-    ldr   x0, =primary_switched
-    br    x0
+    ldr   lr, =primary_switched
+    b enable_boot_cpu_mm
+
  primary_switched:
-    /*
- * The 1:1 map may clash with other parts of the Xen 
virtual memory

- * layout. As it is not used anymore, remove it completely to
- * avoid having to worry about replacing existing mapping
- * afterwards.
- */
-    bl    remove_identity_mapping
  bl    setup_fixmap
  #ifdef CONFIG_EARLY_PRINTK
  /* Use a virtual address to access the UART. */
@@ -384,13 +374,10 @@ GLOBAL(init_secondary)
  #endif
  bl    check_cpu_mode
  bl    cpu_init
-    load_paddr x0, init_ttbr
-    ldr   x0, [x0]
-    bl    enable_mmu

-    /* We are still in the 1:1 mapping. Jump to the runtime 
Virtual Address. */

-    ldr   x0, =secondary_switched
-    br    x0
+    ldr   lr, =secondary_switched
+    b enable_secondary_cpu_mm
+
  secondary_switched:
  #ifdef CONFIG_EARLY_PRINTK
  /* Use a virtual address to access the UART. */
@@ -748,6 +735,64 @@ enable_mmu:
  ret
  ENDPROC(enable_mmu)

+/*
+ * Enable mm (turn on the data cache and the MMU) for secondary CPUs.
+ * The function will return to the virtual address provided in LR 
(e.g. the

+ * runtime mapping).
+ *
+ * Inputs:
+ *   lr : Virtual address to return to.
+ *
+ * Clobbers x0 - x5
+ */
+enable_secondary_cpu_mm:
+    mov   x5, lr
+
+    load_paddr x0, init_ttbr
+    ldr   x0, [x0]
+
+    bl    enable_mmu
+    mov   lr, x5
+
+    /* Return to the virtual address requested by the caller. */
+    ret
+ENDPROC(enable_secondary_cpu_mm)
+
+/*
+ * Enable mm (turn on the data cache and the MMU) for the boot CPU.
+ * The function will return to the virtual address provided in LR 
(e.g. the

+ * runtime mapping).
+ *
+ * Inputs:
+ *   lr : Virtual address to return to.
+ *
+ * Clobbers x0 - x5
+ */
+enable_boot_cpu_mm:
+    mov   x5, lr
+
+    bl    create_page_tables
+    load_paddr x0, boot_pgtable
+
+    bl    enable_mmu
+
+    /*
+ * The MMU is turned on and we are in the 1:1 mapping. Switch
+ * to the runtime mapping.
+ */
+    ldr   x0, =1f
+    br    x0
+1:
+    mov   lr, x5
+    /*
+ * The 1:1 map may clash with other parts of the Xen 
virtual memory
+ * layout. As it is not used anymore, remove it completely 
to avoid
+ * having to worry about repl

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

[osstest service owner]

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

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  03f64b54a1d14893e7851a60ba4855fb75abf30a
baseline version:
 xen  b2dd946ece74e2b6e0601f28caef72f4f9950102

Last test of basis   182709  2023-09-07 02:00:31 Z0 days
Testing same since   182718  2023-09-07 08:00:25 Z0 days1 attempts


People who touched revisions under test:
  Henry Wang 
  Jan Beulich 
  Nicola Vetrini 
  Stefano Stabellini 

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
   b2dd946ece..03f64b54a1  03f64b54a1d14893e7851a60ba4855fb75abf30a -> smoke

Re: [PATCH v6 1/2] xen: asm-generic support

[Oleksii]

On Thu, 2023-09-07 at 11:08 +0100, Anthony PERARD wrote:
> On Thu, Sep 07, 2023 at 12:32:56PM +0300, Oleksii Kurochko wrote:
> > diff --git a/xen/scripts/Makefile.asm-generic
> > b/xen/scripts/Makefile.asm-generic
> > new file mode 100644
> > index 00..92a3a741c5
> > --- /dev/null
> > +++ b/xen/scripts/Makefile.asm-generic
> > @@ -0,0 +1,53 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +# include/asm-generic contains a lot of files that are used
> > +# verbatim by several architectures.
> > +#
> > +# This Makefile reads the file
> > arch/$(SRCARCH)/include/asm/Makefile
> > +# and for each file listed in this file with generic-y creates
> > +# a small wrapper file in arch/$(SRCARCH)/include/generated/asm.
> > +
> > +PHONY := all
> > +all:
> > +
> > +src := $(subst /generated,,$(obj))
> > +
> > +include $(srctree)/scripts/Kbuild.include
> > +-include $(src)/Makefile
> > +
> > +redundant := $(filter $(mandatory-y) $(generated-y), $(generic-y))
> > +redundant += $(foreach f, $(generic-y), $(if $(wildcard
> > $(srctree)/$(src)/$(f)),$(f)))
> > +redundant := $(sort $(redundant))
> > +$(if $(redundant),\
> > +   $(warning redundant generic-y found in $(src)/Kbuild:
> > $(redundant)))
> 
> This warning would need to say "$(src)/Makefile" now instead of
> Kbuild.
Thanks. Missed that.

> 
> Beside this, patch looks fine to me:
> Reviewed-by: Anthony PERARD 
> 
> Thanks,
> 

~ Oleksii

[PATCH v2] x86/HVM: adjust hvm_interrupt_blocked()

[Jan Beulich]

First of all, hvm_intsrc_mce was not considered here at all, yet nothing
blocks #MC (other than an already in-progress #MC, but dealing with this
is not the purpose of this patch).

While nominally STI-shadow only blocks maskable interrupts, but not NMI,
at least Intel offers more leeway: "Nonmaskable interrupts and system-
management interrupts may also be inhibited on the instruction boundary
following such an execution of STI." In case guest kernels might rely on
such behavior, keep the STI check together with the MOV-SS one.

Additionally EFLAGS.IF being clear affects neither #MC nor NMI.

Signed-off-by: Jan Beulich 
---
The EFLAGS.IF check may want moving yet further down, i.e. also past the
TPR check. Otoh it may also be okay to keep the original condition, just
after the added MCE conditional. Except for hvm_intblk_tpr, the specific
types returned here aren't really of interest to callers. The special
case in vmx_intr_assist() concering hvm_intblk_tpr looks to prefer to
have the check done last (i.e. all other blocking reasons to be
prefered). For the one in nvmx_intr_intercept() it's not as clear to me,
though.
---
v2: Keep STI and MOV-SS together.

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3904,9 +3904,8 @@ enum hvm_intblk hvm_interrupt_blocked(st
 return intr;
 }
 
-if ( (intack.source != hvm_intsrc_nmi) &&
- !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
-return hvm_intblk_rflags_ie;
+if ( intack.source == hvm_intsrc_mce )
+return hvm_intblk_none;
 
 intr_shadow = alternative_call(hvm_funcs.get_interrupt_shadow, v);
 
@@ -3917,6 +3916,9 @@ enum hvm_intblk hvm_interrupt_blocked(st
 return ((intr_shadow & HVM_INTR_SHADOW_NMI) ?
 hvm_intblk_nmi_iret : hvm_intblk_none);
 
+if ( !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
+return hvm_intblk_rflags_ie;
+
 if ( intack.source == hvm_intsrc_lapic )
 {
 uint32_t tpr = vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) & 0xF0;

Re: [PATCH v2 2/2] xen/ppc: Drop support for pseries/OpenFirmware

[Jan Beulich]

On 07.09.2023 02:01, Shawn Anastasio wrote:
> Since QEMU's PowerNV support has matured to the point where it is
> now suitable for development, drop support for booting on the
> paravirtualized pseries machine type and its associated interfaces.
> 
> Support for booting on pseries was broken by 74b725a64d80 ('xen/ppc:
> Implement initial Radix MMU support'), and since there is little
> practical value in continuing to support pseries as a target, just drop
> support for it entirely.
> 
> Signed-off-by: Shawn Anastasio 
> Fixes: 74b725a64d80 ('xen/ppc: Implement initial Radix MMU support')

(Nit: Fixes: tag first please.)

Acked-by: Jan Beulich 

Re: [XEN PATCH 1/4] x86/genapic: address a violation of MISRA C:2012 Rule 8.3

[Jan Beulich]

On 06.09.2023 10:57, Federico Serafini wrote:
> Make function delcaration consistent with the corresponding definition.
> No functional change.
> 
> Signed-off-by: Federico Serafini 

Acked-by: Jan Beulich 

Re: [XEN PATCH 2/4] x86/io: address violations of MISRA C:2012 Rule 8.3

[Jan Beulich]

On 06.09.2023 10:57, Federico Serafini wrote:
> Make declarations consistent, no functional change.
> 
> Signed-off-by: Federico Serafini 

Acked-by: Jan Beulich 

Re: [XEN PATCH 3/4] x86/io_apic: address violations of MISRA C:2012 Rules 8.2 and 8.3

[Jan Beulich]

On 06.09.2023 10:57, Federico Serafini wrote:
> Add missing parameter names and make function declarations and
> definitions consistent.
> 
> No functional change.
> 
> Signed-off-by: Federico Serafini 

Acked-by: Jan Beulich 

Re: [XEN PATCH 4/4] xen/vpci: address a violation of MISRA C:2012 Rule 8.3

[Jan Beulich]

On 06.09.2023 10:57, Federico Serafini wrote:
> --- a/xen/arch/x86/include/asm/hap.h
> +++ b/xen/arch/x86/include/asm/hap.h
> @@ -30,7 +30,7 @@ void  hap_vcpu_init(struct vcpu *v);
>  int   hap_track_dirty_vram(struct domain *d,
> unsigned long begin_pfn,
> unsigned int nr_frames,
> -   XEN_GUEST_HANDLE(void) dirty_bitmap);
> +   XEN_GUEST_HANDLE(void) guest_dirty_bitmap);
>  
>  extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
>  int hap_set_allocation(struct domain *d, unsigned int pages, bool 
> *preempted);

How is this related to vPCI? Plus if you change the HAP function, please
adjust its shadow counterpart too.

Jan

Re: [PATCH v6 1/2] xen: asm-generic support

[Oleksii]

On Thu, 2023-09-07 at 12:48 +0200, Jan Beulich wrote:
> On 07.09.2023 11:32, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/scripts/Makefile.asm-generic
> > @@ -0,0 +1,53 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +# include/asm-generic contains a lot of files that are used
> > +# verbatim by several architectures.
> > +#
> > +# This Makefile reads the file
> > arch/$(SRCARCH)/include/asm/Makefile
> > +# and for each file listed in this file with generic-y creates
> > +# a small wrapper file in arch/$(SRCARCH)/include/generated/asm.
> > +
> > +PHONY := all
> > +all:
> > +
> > +src := $(subst /generated,,$(obj))
> > +
> > +include $(srctree)/scripts/Kbuild.include
> > +-include $(src)/Makefile
> 
> With the definition of src above, is this correct for out-of-tree
> builds?
Logically you are right and I think it would be better to use
$(srctree)/$src but it works for out-of-tree builds too.

$ CONTAINER_NO_PULL=1 CONTAINER=riscv64
./automation/scripts/containerize make O=xen-build V=2
XEN_TARGET_ARCH=riscv64 -C xen build

$ ls -la xen/xen-build/arch/riscv/include/generated/asm/vm_event.h
-rw-r--r--. 1 ok ok 34 вер  7 16:27 xen/xen-
build/arch/riscv/include/generated/asm/vm_event.h

> You want to reference the Makefile in the source tree, ...
> 
> > +redundant := $(filter $(mandatory-y) $(generated-y), $(generic-y))
> > +redundant += $(foreach f, $(generic-y), $(if $(wildcard
> > $(srctree)/$(src)/$(f)),$(f)))
> 
> ... much like $(srctree) is used here (and similarly again further
> down).
> 
~ Oleksii

Re: [PATCH v6 2/2] xen: move arm/include/asm/vm_event.h to asm-generic

[Oleksii]

On Thu, 2023-09-07 at 11:59 +0200, Jan Beulich wrote:
> On 07.09.2023 11:32, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/vm_event.h
> > @@ -0,0 +1,55 @@
> > +/* SPDX-License-Identifier:  GPL-2.0-only */
> > +/*
> > + * vm_event.h: stubs for architecture specific vm_event handling
> > routines
> > + *
> > + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
> 
> Tamas is the maintainer of these files (no matter where they live),
> so
> please make sure to Cc him in order to get his ack.
Thanks. I'll add him to CC.
> 
> > + */
> > +
> > +#ifndef __ASM_STUB_VM_EVENT_H__
> > +#define __ASM_STUB_VM_EVENT_H__
> 
> Nit: s/STUB/GENERIC/ ?
Yeah, it should be generic. I'll update that. Thanks.

~ Oleksii

Re: [PATCH v2] acpi/processor: sanitize _PDC buffer bits when running as Xen dom0

[Wilczynski, Michal]

Hi,

On 9/6/2023 8:21 PM, Jason Andryuk wrote:
> From: Roger Pau Monne 
>
> The Processor _PDC buffer bits notify ACPI of the OS capabilities, and
> so ACPI can adjust the return of other Processor methods taking the OS
> capabilities into account.

_PDC method is deprecated for this purpose, since 2018, and is dropped from
spec since 6.5

We made the switch in linux since 6.6:
95272641338a ("ACPI: processor: Use _OSC to convey OSPM processor support 
information")

>
> When Linux is running as a Xen dom0, it's the hypervisor the entity
> in charge of processor power management, and hence Xen needs to make
> sure the capabilities reported in the _PDC buffer match the
> capabilities of the driver in Xen.

So I guess you would need to sanitize buffer passed to _OSC method instead ?

>
> Introduce a small helper to sanitize the buffer when running as Xen
> dom0.
>
> When Xen supports HWP, this serves as the equivalent of commit
> a21211672c9a ("ACPI / processor: Request native thermal interrupt
> handling via _OSC") to avoid SMM crashes.  Xen will set bit 12 in the
> _PDC bits and the _PDC call will apply it.
>
> [ jandryuk: Mention Xen HWP's need.  Move local variables ]
> Signed-off-by: Roger Pau Monné 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jason Andryuk 
> ---
> v2:
> Move local variables in acpi_processor_eval_pdc() to reuse in both conditions.
> ---
>  arch/x86/include/asm/xen/hypervisor.h |  6 ++
>  arch/x86/xen/enlighten.c  | 19 +++
>  drivers/acpi/processor_pdc.c  | 22 --
>  3 files changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/include/asm/xen/hypervisor.h 
> b/arch/x86/include/asm/xen/hypervisor.h
> index 5fc35f889cd1..0f88a7e450d3 100644
> --- a/arch/x86/include/asm/xen/hypervisor.h
> +++ b/arch/x86/include/asm/xen/hypervisor.h
> @@ -63,4 +63,10 @@ void __init xen_pvh_init(struct boot_params *boot_params);
>  void __init mem_map_via_hcall(struct boot_params *boot_params_p);
>  #endif
>  
> +#ifdef CONFIG_XEN_DOM0
> +void xen_sanitize_pdc(uint32_t *buf);
> +#else
> +static inline void xen_sanitize_pdc(uint32_t *buf) { BUG(); }
> +#endif
> +
>  #endif /* _ASM_X86_XEN_HYPERVISOR_H */
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index b8db2148c07d..9f7fc11330a3 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -346,3 +346,22 @@ void xen_arch_unregister_cpu(int num)
>  }
>  EXPORT_SYMBOL(xen_arch_unregister_cpu);
>  #endif
> +
> +#ifdef CONFIG_XEN_DOM0
> +void xen_sanitize_pdc(uint32_t *buf)
> +{
> + struct xen_platform_op op = {
> + .cmd= XENPF_set_processor_pminfo,
> + .interface_version  = XENPF_INTERFACE_VERSION,
> + .u.set_pminfo.id= -1,
> + .u.set_pminfo.type  = XEN_PM_PDC,
> + };
> + int ret;
> +
> + set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
> + ret = HYPERVISOR_platform_op(&op);
> + if (ret)
> + pr_info("sanitize of _PDC buffer bits from Xen failed: %d\n",
> + ret);
> +}
> +#endif
> diff --git a/drivers/acpi/processor_pdc.c b/drivers/acpi/processor_pdc.c
> index 18fb04523f93..9393dd4a3158 100644
> --- a/drivers/acpi/processor_pdc.c
> +++ b/drivers/acpi/processor_pdc.c
> @@ -122,6 +122,11 @@ static acpi_status
>  acpi_processor_eval_pdc(acpi_handle handle, struct acpi_object_list *pdc_in)
>  {
>   acpi_status status = AE_OK;
> + union acpi_object *obj;
> + u32 *buffer = NULL;
> +
> + obj = pdc_in->pointer;
> + buffer = (u32 *)(obj->buffer.pointer);
>  
>   if (boot_option_idle_override == IDLE_NOMWAIT) {
>   /*
> @@ -129,14 +134,19 @@ acpi_processor_eval_pdc(acpi_handle handle, struct 
> acpi_object_list *pdc_in)
>* mode will be disabled in the parameter of _PDC object.
>* Of course C1_FFH access mode will also be disabled.
>*/
> - union acpi_object *obj;
> - u32 *buffer = NULL;
> -
> - obj = pdc_in->pointer;
> - buffer = (u32 *)(obj->buffer.pointer);
>   buffer[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
> -
>   }
> +
> + if (xen_initial_domain()) {
> + /*
> +  * When Linux is running as Xen dom0, the hypervisor is the
> +  * entity in charge of the processor power management, and so
> +  * Xen needs to check the OS capabilities reported in the _PDC
> +  * buffer matches what the hypervisor driver supports.
> +  */
> + xen_sanitize_pdc(buffer);
> + }
> +
>   status = acpi_evaluate_object(handle, "_PDC", pdc_in, NULL);
>  
>   if (ACPI_FAILURE(status))

Re: [PATCH v6 1/2] xen: asm-generic support

[Jan Beulich]

On 07.09.2023 15:45, Oleksii wrote:
> On Thu, 2023-09-07 at 12:48 +0200, Jan Beulich wrote:
>> On 07.09.2023 11:32, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/scripts/Makefile.asm-generic
>>> @@ -0,0 +1,53 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only
>>> +# include/asm-generic contains a lot of files that are used
>>> +# verbatim by several architectures.
>>> +#
>>> +# This Makefile reads the file
>>> arch/$(SRCARCH)/include/asm/Makefile
>>> +# and for each file listed in this file with generic-y creates
>>> +# a small wrapper file in arch/$(SRCARCH)/include/generated/asm.
>>> +
>>> +PHONY := all
>>> +all:
>>> +
>>> +src := $(subst /generated,,$(obj))
>>> +
>>> +include $(srctree)/scripts/Kbuild.include
>>> +-include $(src)/Makefile
>>
>> With the definition of src above, is this correct for out-of-tree
>> builds?
> Logically you are right and I think it would be better to use
> $(srctree)/$src but it works for out-of-tree builds too.
> 
> $ CONTAINER_NO_PULL=1 CONTAINER=riscv64
> ./automation/scripts/containerize make O=xen-build V=2
> XEN_TARGET_ARCH=riscv64 -C xen build
> 
> $ ls -la xen/xen-build/arch/riscv/include/generated/asm/vm_event.h
> -rw-r--r--. 1 ok ok 34 вер  7 16:27 xen/xen-
> build/arch/riscv/include/generated/asm/vm_event.h

Oh, right, aiui because of VPATH being set to $(srctree), and therefore
in the absence of a Makefile in $(objtree)/$(src)/ it'll go look for
one in $(srctree)/$(src)/. Never mind then:
Acked-by: Jan Beulich 

Jan

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

[Jan Beulich]

On 18.08.2023 15:44, Julien Grall wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1896,6 +1896,13 @@ This option is ignored in **pv-shim** mode.
>  ### nr_irqs (x86)
>  > `= `
>  
> +### no_timer_works (x86)
> +> `=`
> +
> +> Default: `true`
> +
> +Disables the code which tests for broken timer IRQ sources.

In description and code it's "check", but here it's "works". Likely
just a typo. But I'd prefer if we didn't introduce any new "no*"
options which then can be negated to "no-no*". Make it "timer-check"
(also avoiding the underscore, no matter that Linux uses it), or
alternatively make it a truly positive option, e.g. "timer-irq-works".

I also think it wants emphasizing that if this option is used and then
something doesn't work, people are on their own.

Jan

Re: [PATCH v6 1/2] xen: asm-generic support

[Oleksii]

On Thu, 2023-09-07 at 15:56 +0200, Jan Beulich wrote:
> On 07.09.2023 15:45, Oleksii wrote:
> > On Thu, 2023-09-07 at 12:48 +0200, Jan Beulich wrote:
> > > On 07.09.2023 11:32, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/scripts/Makefile.asm-generic
> > > > @@ -0,0 +1,53 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-only
> > > > +# include/asm-generic contains a lot of files that are used
> > > > +# verbatim by several architectures.
> > > > +#
> > > > +# This Makefile reads the file
> > > > arch/$(SRCARCH)/include/asm/Makefile
> > > > +# and for each file listed in this file with generic-y creates
> > > > +# a small wrapper file in
> > > > arch/$(SRCARCH)/include/generated/asm.
> > > > +
> > > > +PHONY := all
> > > > +all:
> > > > +
> > > > +src := $(subst /generated,,$(obj))
> > > > +
> > > > +include $(srctree)/scripts/Kbuild.include
> > > > +-include $(src)/Makefile
> > > 
> > > With the definition of src above, is this correct for out-of-tree
> > > builds?
> > Logically you are right and I think it would be better to use
> > $(srctree)/$src but it works for out-of-tree builds too.
> > 
> > $ CONTAINER_NO_PULL=1 CONTAINER=riscv64
> > ./automation/scripts/containerize make O=xen-build V=2
> > XEN_TARGET_ARCH=riscv64 -C xen build
> > 
> > $ ls -la xen/xen-build/arch/riscv/include/generated/asm/vm_event.h
> > -rw-r--r--. 1 ok ok 34 вер  7 16:27 xen/xen-
> > build/arch/riscv/include/generated/asm/vm_event.h
> 
> Oh, right, aiui because of VPATH being set to $(srctree), and
> therefore
> in the absence of a Makefile in $(objtree)/$(src)/ it'll go look for
> one in $(srctree)/$(src)/. Never mind then:
> Acked-by: Jan Beulich 
> 
Thanks for explanation.


~ Oleksii

[PATCH] cmdline: move irq-max-guests doc entry

[Jan Beulich]

... to adhere to intended sorting.

Fixes: e373bc1bdc59 ("x86/IRQ: make max number of guests for a shared IRQ 
configurable")
Signed-off-by: Jan Beulich 

--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1630,6 +1630,16 @@ wait descriptor timed out', try increasi
 **WARNING: This command line option is deprecated, and superseded by
 _dom0-iommu=map-inclusive_ - using both options in combination is undefined.**
 
+### irq-max-guests (x86)
+> `= `
+
+> Default: `32`
+
+Maximum number of guests any individual IRQ could be shared between,
+i.e. a limit on the number of guests it is possible to start each having
+assigned a device sharing a common interrupt line.  Accepts values between
+1 and 255.
+
 ### irq_ratelimit (x86)
 > `= `
 
@@ -1914,16 +1924,6 @@ This option is ignored in **pv-shim** mo
 ### nr_irqs (x86)
 > `= `
 
-### irq-max-guests (x86)
-> `= `
-
-> Default: `32`
-
-Maximum number of guests any individual IRQ could be shared between,
-i.e. a limit on the number of guests it is possible to start each having
-assigned a device sharing a common interrupt line.  Accepts values between
-1 and 255.
-
 ### numa (x86)
 > `= on | off | fake= | noacpi`
 

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

[Jan Beulich]

On 18.08.2023 15:44, Julien Grall wrote:
> From: Julien Grall 
> 
> Currently timer_irq_works() will wait the full 100ms before checking
> that pit0_ticks has been incremented at least 4 times.
> 
> However, the bulk of the BIOS/platform should not have a buggy timer.
> So waiting for the full 100ms is a bit harsh.
> 
> Rework the logic to only wait until 100ms passed or we saw more than
> 4 ticks. So now, in the good case, this will reduce the wait time
> to ~50ms.
> 
> Signed-off-by: Julien Grall 

In principle this is all fine. There's a secondary aspect though which
may call for a slight rework of the patch.

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -1509,6 +1509,8 @@ static void __init setup_ioapic_ids_from_mpc(void)
>  static int __init timer_irq_works(void)
>  {
>  unsigned long t1, flags;
> +/* Wait for maximum 10 ticks */
> +unsigned long msec = (10 * 1000) / HZ;

(Minor remark: I don't think this needs to be unsigned long; unsigned
in will suffice.)

> @@ -1517,19 +1519,25 @@ static int __init timer_irq_works(void)
>  
>  local_save_flags(flags);
>  local_irq_enable();
> -/* Let ten ticks pass... */
> -mdelay((10 * 1000) / HZ);
> -local_irq_restore(flags);
>  
> -/*
> - * Expect a few ticks at least, to be sure some possible
> - * glue logic does not lock up after one or two first
> - * ticks in a non-ExtINT mode.  Also the local APIC
> - * might have cached one ExtINT interrupt.  Finally, at
> - * least one tick may be lost due to delays.
> - */
> -if ( (ACCESS_ONCE(pit0_ticks) - t1) > 4 )
> +while ( msec-- )
> +{
> +mdelay(1);
> +/*
> + * Expect a few ticks at least, to be sure some possible
> + * glue logic does not lock up after one or two first
> + * ticks in a non-ExtINT mode.  Also the local APIC
> + * might have cached one ExtINT interrupt.  Finally, at
> + * least one tick may be lost due to delays.
> + */
> +if ( (ACCESS_ONCE(pit0_ticks) - t1) <= 4 )
> +continue;
> +
> +local_irq_restore(flags);
>  return 1;
> +}
> +
> +local_irq_restore(flags);
>  
>  return 0;
>  }

While Andrew has a patch pending (not sure why it didn't go in yet)
to simplify local_irq_restore(), and while further it shouldn't really
need using here (local_irq_disable() ought to be fine), I can see that
you don't want to make such an adjustment here. But then I'd prefer if
we got away with just a single instance, adjusting the final return
statement accordingly (easiest would likely be to go from the value of
"msec").

Jan

Re: [PATCH] coverage: update gcov info for newer versions of gcc

[Jan Beulich]

On 02.09.2023 17:11, Javi Merino wrote:
> --- a/xen/common/coverage/Makefile
> +++ b/xen/common/coverage/Makefile
> @@ -5,7 +5,9 @@ obj-y += $(call cc-ifversion,-lt,0407, \
>   gcc_3_4.o, $(call cc-ifversion,-lt,0409, \
>   gcc_4_7.o, $(call cc-ifversion,-lt,0500, \
>   gcc_4_9.o, $(call cc-ifversion,-lt,0700, \
> - gcc_5.o, gcc_7.o
> + gcc_5.o, $(call cc-ifversion,-lt,1000, \
> + gcc_7.o,  $(call cc-ifversion,-lt,1200, \
> + gcc_10.o, gcc_12.o))

This is getting unwieldy, so I think we ought to try to limit the number
of different files we have. Already gcc_4_9.c and gcc_7.c specify the
same GCOV_COUNTERS and differ only in the version checks (which could be
combined). Therefore ...

> --- /dev/null
> +++ b/xen/common/coverage/gcc_10.c
> @@ -0,0 +1,31 @@
> +/*
> + *  This code provides functions to handle gcc's profiling data format
> + *  introduced with gcc 10.
> + *
> + *  For a better understanding, refer to gcc source:
> + *  gcc/gcov-io.h
> + *  libgcc/libgcov.c
> + *
> + *  Uses gcc-internal data definitions.
> + */
> +
> +#include "gcov.h"
> +
> +#if GCC_VERSION < 10 || GCC_VERSION > 12
> +#error "Wrong version of GCC used to compile gcov"
> +#endif
> +
> +#define GCOV_COUNTERS 8
> +#define GCOV_UNIT_SIZE 1
> +
> +#include "gcc_4_7.c"

... this could simply re-use gcc_4_7.c directly, with just the version
check there suitably tweaked.

> --- a/xen/common/coverage/gcc_4_7.c
> +++ b/xen/common/coverage/gcc_4_7.c
> @@ -27,6 +27,7 @@
>  #  error "Wrong version of GCC used to compile gcov"
>  # endif
>  #define GCOV_COUNTERS 8
> +#define GCOV_UNIT_SIZE 1
>  #endif

If further this became a separate #ifdef, ...

> --- a/xen/common/coverage/gcc_4_9.c
> +++ b/xen/common/coverage/gcc_4_9.c
> @@ -19,6 +19,7 @@
>  #endif
>  
>  #define GCOV_COUNTERS 9
> +#define GCOV_UNIT_SIZE 1
>  
>  #include "gcc_4_7.c"
>  
> --- a/xen/common/coverage/gcc_5.c
> +++ b/xen/common/coverage/gcc_5.c
> @@ -19,6 +19,7 @@
>  #endif
>  
>  #define GCOV_COUNTERS 10
> +#define GCOV_UNIT_SIZE 1
>  
>  #include "gcc_4_7.c"
>  

... touching these two files could be avoided altogether.

Henry - afaict this was submitted after the feature submission deadline,
so you may want to consider giving it an exception.

Jan

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

[Oleksii]

Hello Bobby and Alistair,

Could you kindly take a moment to examine this series of patches?
Your input would be highly valued.

Thanks in advance.

~ Oleksii

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

Re: [PATCH v6 2/2] xen: move arm/include/asm/vm_event.h to asm-generic

[Oleksii]

On Thu, 2023-09-07 at 10:53 -0400, Tamas K Lengyel wrote:
> On Thu, Sep 7, 2023 at 9:46 AM Oleksii 
> wrote:
> > 
> > On Thu, 2023-09-07 at 11:59 +0200, Jan Beulich wrote:
> > > On 07.09.2023 11:32, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/include/asm-generic/vm_event.h
> > > > @@ -0,0 +1,55 @@
> > > > +/* SPDX-License-Identifier:  GPL-2.0-only */
> > > > +/*
> > > > + * vm_event.h: stubs for architecture specific vm_event
> > > > handling
> > > > routines
> > > > + *
> > > > + * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
> > > 
> > > Tamas is the maintainer of these files (no matter where they
> > > live),
> > > so
> > > please make sure to Cc him in order to get his ack.
> > Thanks. I'll add him to CC.
> 
> Sent ack on v5 of the patch.
Thank you.

~ Oleksii

[PATCH v7 2/2] xen: move arm/include/asm/vm_event.h to asm-generic

[Oleksii Kurochko]

asm/vm_event.h is common for ARM and RISC-V so it will be moved to
asm-generic dir.

Original asm/vm_event.h from ARM was updated:
 * use SPDX-License-Identifier.
 * update comment messages of stubs.
 * update #ifdef
 * instead of "include " -> "public/vm_event.h"

As vm_event.h was moved to asm-generic then it is needed to create
Makefile in arm/include/asm/ and add generated-y += vm_event.h to
it.

Signed-off-by: Oleksii Kurochko 
Acked-by: Tamas K Lengyel 
---
Changes in V7:
 - update guards in asm-generic/vm_event.h.
 - add Acked-by: Tamas K Lengyel 
---
Changes in V6:
 - update the commit message.
---
Changes in V5:
 - Update the commit message
 - Remove Acked-by:...
 - Switch ARM to use asm-generic/vm_event.h
---
Changes in V4:
 - update path of vm_event.h from include/asm-generic/asm to include/asm-generic
---
Changes in V3:
 - add Acked-by: Stefano Stabellini  for "xen: move 
arm/include/asm/vm_event.h to asm-generic"
 - update SPDX tag.
 - move asm/vm_event.h to asm-generic.
---
Changes in V2:
 - change public/domctl.h to public/vm_event.h.
 - update commit message of [PATCH v2 2/2] xen: move arm/include/asm/vm_event.h 
to stubs
---
 xen/arch/arm/include/asm/Makefile   |  2 +
 xen/arch/arm/include/asm/vm_event.h | 66 -
 xen/include/asm-generic/vm_event.h  | 55 
 3 files changed, 57 insertions(+), 66 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/Makefile
 delete mode 100644 xen/arch/arm/include/asm/vm_event.h
 create mode 100644 xen/include/asm-generic/vm_event.h

diff --git a/xen/arch/arm/include/asm/Makefile 
b/xen/arch/arm/include/asm/Makefile
new file mode 100644
index 00..821addb0bf
--- /dev/null
+++ b/xen/arch/arm/include/asm/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+generic-y += vm_event.h
diff --git a/xen/arch/arm/include/asm/vm_event.h 
b/xen/arch/arm/include/asm/vm_event.h
deleted file mode 100644
index 4d861373b3..00
--- a/xen/arch/arm/include/asm/vm_event.h
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * vm_event.h: architecture specific vm_event handling routines
- *
- * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; If not, see .
- */
-
-#ifndef __ASM_ARM_VM_EVENT_H__
-#define __ASM_ARM_VM_EVENT_H__
-
-#include 
-#include 
-
-static inline int vm_event_init_domain(struct domain *d)
-{
-/* Nothing to do. */
-return 0;
-}
-
-static inline void vm_event_cleanup_domain(struct domain *d)
-{
-memset(&d->monitor, 0, sizeof(d->monitor));
-}
-
-static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v,
-  vm_event_response_t *rsp)
-{
-/* Not supported on ARM. */
-}
-
-static inline
-void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
-{
-/* Not supported on ARM. */
-}
-
-static inline
-void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
-{
-/* Not supported on ARM. */
-}
-
-static inline
-void vm_event_sync_event(struct vcpu *v, bool value)
-{
-/* Not supported on ARM. */
-}
-
-static inline
-void vm_event_reset_vmtrace(struct vcpu *v)
-{
-/* Not supported on ARM. */
-}
-
-#endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-generic/vm_event.h 
b/xen/include/asm-generic/vm_event.h
new file mode 100644
index 00..620c7b971c
--- /dev/null
+++ b/xen/include/asm-generic/vm_event.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier:  GPL-2.0-only */
+/*
+ * vm_event.h: stubs for architecture specific vm_event handling routines
+ *
+ * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
+ */
+
+#ifndef __ASM_GENERIC_VM_EVENT_H__
+#define __ASM_GENERIC_VM_EVENT_H__
+
+#include 
+#include 
+
+static inline int vm_event_init_domain(struct domain *d)
+{
+/* Nothing to do. */
+return 0;
+}
+
+static inline void vm_event_cleanup_domain(struct domain *d)
+{
+memset(&d->monitor, 0, sizeof(d->monitor));
+}
+
+static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v,
+  vm_event_response_t *rsp)
+{
+/* Nothing to do. */
+}
+
+static inline
+void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
+{
+/* Nothing to do. */
+}
+
+static inline
+void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
+{
+/* Nothing to do. */
+}
+
+static inline
+voi

[PATCH v7 0/2] introduce stub directory to storing empty/stub headers

[Oleksii Kurochko]

A lot of empty/stub headers should be introduced during the early steps of 
adding
support of new architecture.

An example can be found here:
1. 
https://lore.kernel.org/xen-devel/cover.1692181079.git.oleksii.kuroc...@gmail.com/
2. 
https://lore.kernel.org/xen-devel/a92f99e8f697da99d77bfde562a549dbef3760ce.1692816595.git.sanasta...@raptorengineering.com/

As part of the patch series, asm/vm_event.h was moved to the stubs directory 
because
It is the same for ARM, PPC, and RISC-V.
---
Changes in V7:
- update warning message in Makefile.asm-generic
- add Reviewed-by: Anthony PERARD  for patch 1
- add Acked-by: Jan Beulich  for patch 1
- update header guards in asm-generic/vm_event.h.
- add Acked-by: Tamas K Lengyel  for patch 2
---
Changes in V6:
 - introduce $(asm-generic) macro in Kbuild.include.
 - move "asm-generic" after the rule "__distclean".
 - update the commit message.
---
Changes in V5:
- Update SPDX license.
- Remove code related to UML in Makefile.asm-generic.
- Include $(src)/Makefile instead of $(kbuild-file).
- Update comment message in Makefile.asm-generic.
- Update .gitignore.
- Update path to generated headers in CFLAGS.
- Use the latest version of Linux's Makefile.asm-generic.
- Introduce asm-generic's vm_event.h.
- Switch ARM to use asm-generic/vm_event.h.
---
Changes in V4:
 - add asm-generic support
 - update path of vm_event.h from include/asm-generic/asm to include/asm-generic
---
Changes in V3:
 - add Acked-by: Stefano Stabellini  for "xen: move 
arm/include/asm/vm_event.h to asm-generic"
 - update SPDX tag.
 - move asm/vm_event.h to asm-generic.
 - rename stubs dir to asm-generic.

---
Changes in V2:
 - change public/domctl.h to public/vm_event.h.
 - update commit message of [PATCH v2 2/2] xen: move arm/include/asm/vm_event.h 
to stubs

Oleksii Kurochko (2):
  xen: asm-generic support
  xen: move arm/include/asm/vm_event.h to asm-generic

 .gitignore  |  1 +
 xen/Makefile|  9 +++-
 xen/arch/arm/include/asm/Makefile   |  2 +
 xen/arch/arm/include/asm/vm_event.h | 66 -
 xen/include/asm-generic/vm_event.h  | 55 
 xen/scripts/Kbuild.include  |  6 +++
 xen/scripts/Makefile.asm-generic| 53 +++
 7 files changed, 125 insertions(+), 67 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/Makefile
 delete mode 100644 xen/arch/arm/include/asm/vm_event.h
 create mode 100644 xen/include/asm-generic/vm_event.h
 create mode 100644 xen/scripts/Makefile.asm-generic

-- 
2.41.0

[PATCH v7 1/2] xen: asm-generic support

[Oleksii Kurochko]

Some headers are shared between individual architectures or are empty.
To avoid duplication of these headers, asm-generic is introduced.

With the following patch, an architecture uses generic headers
mentioned in the file arch/$(ARCH)/include/asm/Makefile

To use a generic header is needed to add to
arch/$(ARCH)/include/asm/Makefile :
generic-y += 

For each mentioned header in arch/$(ARCH)/include/asm/Makefile,
the necessary wrapper in arch/$(ARCH)/include/generated/asm will be
generated.

As the base Makefile.asm-generic from Linux kernel was taken.
( 06c2afb862f9da8 "Linux 6.5-rc1" ).

Signed-off-by: Oleksii Kurochko 
Reviewed-by: Anthony PERARD 
Acked-by: Jan Beulich 
---
Changes in V7:
 - update warning message in Makefile.asm-generic
 - add Reviewed-by: Anthony PERARD 
 - add Acked-by: Jan Beulich 
---
Changes in V6:
 - introduce $(asm-generic) macro in Kbuild.include.
 - move "asm-generic" after the rule "__distclean".
---
Changes in V5:
 - Update the commit message
 - Update SPDX license in Makefile.
 - Remove code related to UML
 - Include $(src)/Makefile instead of $(kbuild-file) 
 - Update comment message in Makefile.asm-generic
 - Update .gitignore
 - Update path to generated headers in CFLAGS.
 - Use the latest version of Linux's Makefile.asm-generic
---
Changes in V4:
 - introduce asm-generic support
 - update commit message
---
Changes in V3:
 - Rename stubs dir to asm-generic
---
Changes in V2:
 - Nothing changed.
---
 .gitignore   |  1 +
 xen/Makefile |  9 +-
 xen/scripts/Kbuild.include   |  6 
 xen/scripts/Makefile.asm-generic | 53 
 4 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 xen/scripts/Makefile.asm-generic

diff --git a/.gitignore b/.gitignore
index 50273adb8d..287166f8fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -267,6 +267,7 @@ xen/arch/*/efi/efi.h
 xen/arch/*/efi/pe.c
 xen/arch/*/efi/runtime.c
 xen/arch/*/include/asm/asm-offsets.h
+xen/arch/*/include/generated
 xen/build-dir-cppcheck/
 xen/common/config_data.S
 xen/common/config.gz
diff --git a/xen/Makefile b/xen/Makefile
index f57e5a596c..2dc5e3526d 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -438,6 +438,7 @@ ifdef building_out_of_srctree
 endif
 CFLAGS += -I$(srctree)/include
 CFLAGS += -I$(srctree)/arch/$(SRCARCH)/include
+CFLAGS += -I$(objtree)/arch/$(SRCARCH)/include/generated
 
 # Note that link order matters!
 ALL_OBJS-y:= common/built_in.o
@@ -580,16 +581,22 @@ _clean:
rm -f $(TARGET).efi $(TARGET).efi.map $(TARGET).efi.elf 
$(TARGET).efi.stripped
rm -f asm-offsets.s arch/*/include/asm/asm-offsets.h
rm -f .banner .allconfig.tmp include/xen/compile.h
+   rm -rf $(objtree)/arch/*/include/generated
 
 .PHONY: _distclean
 _distclean: clean
rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out 
GTAGS GPATH GRTAGS GSYMS .config source
 
+# Support for using generic headers in asm-generic
+PHONY += asm-generic
+asm-generic:
+   $(Q)$(MAKE) $(asm-generic)=arch/$(SRCARCH)/include/generated/asm
+
 $(TARGET).gz: $(TARGET)
gzip -n -f -9 < $< > $@.new
mv $@.new $@
 
-$(TARGET): outputmakefile FORCE
+$(TARGET): outputmakefile asm-generic FORCE
$(Q)$(MAKE) $(build)=tools
$(Q)$(MAKE) $(build)=. include/xen/compile.h
$(Q)$(MAKE) $(build)=include all
diff --git a/xen/scripts/Kbuild.include b/xen/scripts/Kbuild.include
index 785a32c32e..c2bd8498e1 100644
--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -91,6 +91,12 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 
] && echo $(3) || e
 
 clang-ifversion = $(shell [ $(CONFIG_CLANG_VERSION)0 $(1) $(2)000 ] && echo 
$(3) || echo $(4))
 
+###
+# Shorthand for $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.asm-generic obj
+# Usage:
+# $(Q)$(MAKE) $(asm-generic)=dir
+asm-generic := -f $(srctree)/scripts/Makefile.asm-generic obj
+
 ###
 # Shorthand for $(Q)$(MAKE) -f scripts/Makefile.build obj=
 # Usage:
diff --git a/xen/scripts/Makefile.asm-generic b/xen/scripts/Makefile.asm-generic
new file mode 100644
index 00..b0d356bfa3
--- /dev/null
+++ b/xen/scripts/Makefile.asm-generic
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# include/asm-generic contains a lot of files that are used
+# verbatim by several architectures.
+#
+# This Makefile reads the file arch/$(SRCARCH)/include/asm/Makefile
+# and for each file listed in this file with generic-y creates
+# a small wrapper file in arch/$(SRCARCH)/include/generated/asm.
+
+PHONY := all
+all:
+
+src := $(subst /generated,,$(obj))
+
+include $(srctree)/scripts/Kbuild.include
+-include $(src)/Makefile
+
+redundant := $(filter $(mandatory-y) $(generated-y), $(generic-y))
+redundant += $(foreach f, $(generic-y), $(if $(wildcard 
$(srctree)/$(src)/$(f)),$(f)))
+redundant := $(sort $(redundant))
+$(if $(redundant),\
+   $(warning redundant generic-y found in $(src)/Makefile: $(

Re: Xens handling of MCE

[Elliott Mitchell]

On Thu, Sep 07, 2023 at 08:56:51AM +0200, Jan Beulich wrote:
> On 06.09.2023 23:38, Elliott Mitchell wrote:
> > On Thu, Aug 31, 2023 at 07:52:05PM +, Development wrote:
> >>
> >> However, in 2009-02, "cegger" wrote MCA/MCE_in_Xen, a proposal for 
> >> having xen start checking the information
> >> Xen started accessing the EDAC information (now called "MCE") at some 
> >> point after that, which blocks the linux kernel in dom0 from accessing it.
> >> (I also found what appears to be related sides from a presentation 
> >> from 2012 at: 
> >> https://lkml.iu.edu/hypermail/linux/kernel/1206.3/01304/xen_vMCE_design_%28v0_2%29.pdf
> >>  )
> >>
> > 
> > I hadn't seen that before.  Clearly shows someone who had no idea what
> > they were doing designed it.  The author was thinking "virtualize 
> > everything!", whereas MCE is a perfect situation for paravirtualization.
> > Let Dom0 process MCE events (which allows use of Linux's more up to date
> > MCE drivers), then let Dom0 notify Xen if action is needed (a page was
> > corrupted, tell the effected domain).
> > 
> > There was a recent proposal to simply import Linux's rather more recent
> > MCE/EDAC source.  This hasn't happened yet.  For people using Xen this
> > has been a very concerning issue for some time.
> 
> I'm unaware of such a proposal; do you have a reference? EDAC drivers
> typically are vendor- or even chipset-specific aiui. At least the latter
> wouldn't make them a good fit to import into Xen. Along of what you say
> earlier, they instead want to become Xen-aware (to deal with address
> translation as necessary). That'll also have better chances of things
> staying up-to-date.

I don't recall who wrote the message, I think it was less than 6 months
ago though.  I read it as $person had been pondering the idea of simply
ripping out Xen's MCE implementation and replacing it with minimally
adjusted Linux MCE implementation.

What you describe matches my thinking.  Even though the EDAC hardware is
fully attached to processors now, it doesn't need virtualization similar
to page tables.  Instead EDAC should be handled similar to most hardware
devices and go through Domain 0.

The approach for Xen should also differ.  Instead of first telling the
OS, it might be better to immediately unmap the page and trigger a page
fault if it is accessed.  Then notify the OS a page has disappeared.
Mainly immitate how Linux handles MCE events for a userspace process,
rather than the usual paravirtualization.

I'm not on sufficiently intimate terms with the drivers or hardware to
try this right now.  Yet the number of complaints about this is rather
substantial (okay, I'm aware since this is no small concern for me too).


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

[ovmf test] 182721: all pass - PUSHED

[osstest service owner]

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

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

Last test of basis   182715  2023-09-07 06:40:47 Z0 days
Testing same since   182721  2023-09-07 14:10:43 Z0 days1 attempts


People who touched revisions under test:
  Alexander Goncharov 
  Gerd Hoffmann 
  Joursoir 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   bbf1822295..b81557a00c  b81557a00c61cc80ab118828f16ed9ce79455880 -> 
xen-tested-master

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

[osstest service owner]

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

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  1f79fce10a75f88d2c2a6ace469a4046bc1b9cb5
baseline version:
 xen  03f64b54a1d14893e7851a60ba4855fb75abf30a

Last test of basis   182718  2023-09-07 08:00:25 Z0 days
Testing same since   182720  2023-09-07 14:03:27 Z0 days1 attempts


People who touched revisions under test:
  Federico Serafini 
  Jan Beulich 

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
   03f64b54a1..1f79fce10a  1f79fce10a75f88d2c2a6ace469a4046bc1b9cb5 -> smoke

Re: [PATCH] coverage: update gcov info for newer versions of gcc

[Javi Merino]

On Thu, Sep 07, 2023 at 04:41:59PM +0200, Jan Beulich wrote:
> On 02.09.2023 17:11, Javi Merino wrote:
> > --- a/xen/common/coverage/Makefile
> > +++ b/xen/common/coverage/Makefile
> > @@ -5,7 +5,9 @@ obj-y += $(call cc-ifversion,-lt,0407, \
> > gcc_3_4.o, $(call cc-ifversion,-lt,0409, \
> > gcc_4_7.o, $(call cc-ifversion,-lt,0500, \
> > gcc_4_9.o, $(call cc-ifversion,-lt,0700, \
> > -   gcc_5.o, gcc_7.o
> > +   gcc_5.o, $(call cc-ifversion,-lt,1000, \
> > +   gcc_7.o,  $(call cc-ifversion,-lt,1200, \
> > +   gcc_10.o, gcc_12.o))
> 
> This is getting unwieldy, so I think we ought to try to limit the number
> of different files we have. Already gcc_4_9.c and gcc_7.c specify the
> same GCOV_COUNTERS and differ only in the version checks (which could be
> combined). Therefore ...

Right!  I tried to keep the current structure but I agree: it is
simpler if they were all combined in gcc_4_7.c.  This is what linux
does.  I'll simplify it as you suggest and send a v2.

Cheers,
Javi

[ovmf test] 182722: all pass - PUSHED

[osstest service owner]

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

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

Last test of basis   182721  2023-09-07 14:10:43 Z0 days
Testing same since   182722  2023-09-07 16:10:41 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Gerd Hoffmann 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   b81557a00c..b29150aa3e  b29150aa3e9157908052c212d3afacbff8dbab1b -> 
xen-tested-master

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuuc152379422a204109f34ca2b43ecc538c7d738ae
baseline version:
 qemuu2d8fbcb1eecd8d39171f457e583428758321d69d

Last test of basis   182638  2023-09-05 15:37:11 Z2 days
Testing same since   182707  2023-09-07 00:28:57 Z0 days1 attempts


People who touched revisions under test:
  Bilal Elmoussaoui 
  Cédric Le Goater 
  dengpengcheng 
  Dmitry Frolov 
  Guoyi Tu 
  Hang Yu 
  Helge Deller 
  Ilya Leoshkevich 
  Joel Stanley 
  Marc-André Lureau 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Philippe Mathieu-Daudé 
  Philippe Mathieu-Daudé 
  Richard Henderson 
  Stefan Hajnoczi 

jobs:
 build-amd64-xsm 

[PATCH v3 2/2] xen/ppc: Drop support for pseries/OpenFirmware

[Shawn Anastasio]

Since QEMU's PowerNV support has matured to the point where it is
now suitable for development, drop support for booting on the
paravirtualized pseries machine type and its associated interfaces.

Support for booting on pseries was broken by 74b725a64d80 ('xen/ppc:
Implement initial Radix MMU support'), and since there is little
practical value in continuing to support pseries as a target, just drop
support for it entirely.

Fixes: 74b725a64d80 ('xen/ppc: Implement initial Radix MMU support')
Signed-off-by: Shawn Anastasio 
Acked-by: Jan Beulich 
---
 xen/arch/ppc/Makefile   |   1 -
 xen/arch/ppc/boot-of.c  | 113 
 xen/arch/ppc/include/asm/boot.h |  19 --
 xen/arch/ppc/ppc64/Makefile |   1 -
 xen/arch/ppc/ppc64/of-call.S|  83 ---
 xen/arch/ppc/setup.c|  11 +---
 6 files changed, 3 insertions(+), 225 deletions(-)
 delete mode 100644 xen/arch/ppc/boot-of.c
 delete mode 100644 xen/arch/ppc/ppc64/of-call.S

diff --git a/xen/arch/ppc/Makefile b/xen/arch/ppc/Makefile
index a059ac4c0a..b3205b8f7a 100644
--- a/xen/arch/ppc/Makefile
+++ b/xen/arch/ppc/Makefile
@@ -1,6 +1,5 @@
 obj-$(CONFIG_PPC64) += ppc64/

-obj-y += boot-of.init.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.init.o
 obj-y += mm-radix.o
 obj-y += opal.o
diff --git a/xen/arch/ppc/boot-of.c b/xen/arch/ppc/boot-of.c
deleted file mode 100644
index d6755ccc8e..00
--- a/xen/arch/ppc/boot-of.c
+++ /dev/null
@@ -1,113 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * This file was derived from Xen 3.2's xen/arch/powerpc/boot_of.c,
- * originally licensed under GPL version 2 or later.
- *
- * Copyright IBM Corp. 2005, 2006, 2007
- * Copyright Raptor Engineering, LLC
- *
- * Authors: Jimi Xenidis 
- *  Hollis Blanchard 
- *  Shawn Anastasio 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/*
- * The Open Firmware client interface is called in 32-bit mode with the MMU 
off,
- * so any addresses passed to it must be physical addresses under 4GB.
- *
- * Since the client interface is only used during early boot before the MMU is 
on
- * and Xen itself was loaded by Open Firmware (and therefore resides below 
4GB),
- * we can achieve the desired result with a simple cast to uint32_t.
- */
-#define ADDR(x) ((uint32_t)(unsigned long)(x))
-
-/* OF entrypoint*/
-static unsigned long __initdata of_vec;
-
-static int __initdata of_out;
-
-static int __init of_call(const char *service, uint32_t nargs, uint32_t nrets,
-  int32_t rets[], ...)
-{
-int rc;
-va_list args;
-unsigned int i;
-struct of_service s;
-
-s.ofs_service = cpu_to_be32(ADDR(service));
-s.ofs_nargs = cpu_to_be32(nargs);
-s.ofs_nrets = cpu_to_be32(nrets);
-
-/* Copy all the params into the args array */
-va_start(args, rets);
-
-for ( i = 0; i < nargs; i++ )
-s.ofs_args[i] = cpu_to_be32(va_arg(args, uint32_t));
-
-va_end(args);
-
-rc = enter_of(&s, of_vec);
-
-/* Copy all return values to the output rets array */
-for ( i = 0; i < nrets; i++ )
-rets[i] = be32_to_cpu(s.ofs_args[i + nargs]);
-
-return rc;
-}
-
-static int __init of_finddevice(const char *devspec)
-{
-int32_t rets[1] = { OF_FAILURE };
-
-of_call("finddevice", 1, ARRAY_SIZE(rets), rets, ADDR(devspec));
-return rets[0];
-}
-
-static int __init of_getprop(int ph, const char *name, void *buf, uint32_t 
buflen)
-{
-int32_t rets[1] = { OF_FAILURE };
-
-of_call("getprop", 4, ARRAY_SIZE(rets), rets, ph, ADDR(name), ADDR(buf),
-buflen);
-return rets[0];
-}
-
-int __init of_write(int ih, const char *addr, uint32_t len)
-{
-int32_t rets[1] = { OF_FAILURE };
-
-of_call("write", 3, ARRAY_SIZE(rets), rets, ih, ADDR(addr), len);
-return rets[0];
-}
-
-static void __init of_putchar(char c)
-{
-if ( c == '\n' )
-{
-char buf = '\r';
-of_write(of_out, &buf, 1);
-}
-of_write(of_out, &c, 1);
-}
-
-void __init boot_of_init(unsigned long vec)
-{
-int bof_chosen;
-
-of_vec = vec;
-
-/* Get a handle to the default console */
-bof_chosen = of_finddevice("/chosen");
-of_getprop(bof_chosen, "stdout", &of_out, sizeof(of_out));
-of_out = be32_to_cpu(of_out);
-
-early_printk_init(of_putchar);
-}
diff --git a/xen/arch/ppc/include/asm/boot.h b/xen/arch/ppc/include/asm/boot.h
index 296539cd9e..d62c3ff6e0 100644
--- a/xen/arch/ppc/include/asm/boot.h
+++ b/xen/arch/ppc/include/asm/boot.h
@@ -4,25 +4,6 @@

 #include 

-/*
- * OpenFirmware boot interfaces
- */
-
-enum {
-OF_FAILURE = -1,
-OF_SUCCESS = 0,
-};
-
-struct of_service {
-__be32 ofs_service;
-__be32 ofs_nargs;
-__be32 ofs_nrets;
-__be32 ofs_args[10];
-};
-
-int enter_of(struct of_service *args, unsigned long entry);
-void boot_of_init(unsigned long vec);
-
 /*
  * OPAL boot interfaces
  */
diff --git a/xen/arch/ppc/ppc64/Mak

[PATCH v3 1/2] automation: Switch ppc64le tests to PowerNV machine type

[Shawn Anastasio]

Run ppc64le tests with the PowerNV machine type (bare metal) instead of
the paravirtualized pseries machine. This requires a more modern version
of QEMU than is present in debian bullseye's repository, so update the
dockerfile to build QEMU from source.

Support for booting on pseries was broken by 74b725a64d80 ('xen/ppc:
Implement initial Radix MMU support') which resulted in CI failures. In
preparation for removing pseries support entirely, switch the CI
infrastructure to the PowerNV machine type.

Signed-off-by: Shawn Anastasio 
---
v3: Use test-artifact for custom QEMU build

 .../build/debian/bullseye-ppc64le.dockerfile  |  5 ++-
 automation/gitlab-ci/build.yaml   | 14 +++
 automation/gitlab-ci/test.yaml|  5 ++-
 automation/scripts/qemu-smoke-ppc64le.sh  |  3 +-
 .../qemu-system-ppc64/8.1.0-ppc64.dockerfile  | 37 +++
 5 files changed, 59 insertions(+), 5 deletions(-)
 create mode 100644 
automation/tests-artifacts/qemu-system-ppc64/8.1.0-ppc64.dockerfile

diff --git a/automation/build/debian/bullseye-ppc64le.dockerfile 
b/automation/build/debian/bullseye-ppc64le.dockerfile
index 8fad26e903..4de8458445 100644
--- a/automation/build/debian/bullseye-ppc64le.dockerfile
+++ b/automation/build/debian/bullseye-ppc64le.dockerfile
@@ -22,8 +22,9 @@ RUN apt-get update && \
 gcc-powerpc64le-linux-gnu \
 make \
 python3-minimal \
-# for test phase
-qemu-system-ppc \
+# QEMU runtime dependencies for test phase
+libglib2.0-0 \
+libpixman-1-0 \
 && \
 apt-get autoremove -y && \
 apt-get clean && \
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index b633facff4..1619e9a558 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -306,6 +306,20 @@ qemu-system-aarch64-6.0.0-arm32-export:
   tags:
 - arm64

+# ppc64 test artifacts
+
+qemu-system-ppc64-8.1.0-ppc64-export:
+  extends: .test-jobs-artifact-common
+  image: 
registry.gitlab.com/xen-project/xen/tests-artifacts/qemu-system-ppc64:8.1.0-ppc64
+  script:
+- mkdir binaries && cp /qemu-system-ppc64 /skiboot.lid binaries/
+  artifacts:
+paths:
+  - binaries/qemu-system-ppc64
+  - binaries/skiboot.lid
+  tags:
+- x86_64
+
 # x86_64 test artifacts

 alpine-3.18-rootfs-export:
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 9aa8deabea..4b836bf047 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -454,9 +454,10 @@ qemu-smoke-riscv64-gcc:
   needs:
 - archlinux-current-gcc-riscv64-debug

-qemu-smoke-ppc64le-pseries-gcc:
+qemu-smoke-ppc64le-powernv9-gcc:
   extends: .qemu-ppc64le
   script:
-- ./automation/scripts/qemu-smoke-ppc64le.sh pseries-5.2 2>&1 | tee 
${LOGFILE}
+- ./automation/scripts/qemu-smoke-ppc64le.sh powernv9 2>&1 | tee ${LOGFILE}
   needs:
+- qemu-system-ppc64-8.1.0-ppc64-export
 - debian-bullseye-gcc-ppc64le-debug
diff --git a/automation/scripts/qemu-smoke-ppc64le.sh 
b/automation/scripts/qemu-smoke-ppc64le.sh
index eb55221221..2adbdac87e 100755
--- a/automation/scripts/qemu-smoke-ppc64le.sh
+++ b/automation/scripts/qemu-smoke-ppc64le.sh
@@ -12,7 +12,8 @@ set +e
 touch smoke.serial

 timeout -k 1 20 \
-qemu-system-ppc64 \
+binaries/qemu-system-ppc64 \
+-bios binaries/skiboot.lid \
 -M $machine \
 -m 2g \
 -smp 1 \
diff --git 
a/automation/tests-artifacts/qemu-system-ppc64/8.1.0-ppc64.dockerfile 
b/automation/tests-artifacts/qemu-system-ppc64/8.1.0-ppc64.dockerfile
new file mode 100644
index 00..7376ca46ff
--- /dev/null
+++ b/automation/tests-artifacts/qemu-system-ppc64/8.1.0-ppc64.dockerfile
@@ -0,0 +1,37 @@
+FROM debian:bullseye-slim
+LABEL maintainer.name="The Xen Project" \
+  maintainer.email="xen-devel@lists.xenproject.org"
+
+ENV DEBIAN_FRONTEND=noninteractive
+ENV QEMU_VERSION=8.1.0
+ENV USER root
+
+RUN mkdir /build
+WORKDIR /build
+
+# build depends
+RUN apt-get update && \
+apt-get --quiet --yes install \
+build-essential \
+curl \
+python3 \
+python3-pip \
+python3-elementpath \
+ninja-build \
+pkg-config \
+libglib2.0-dev \
+libpixman-1-dev \
+&& \
+\
+curl -fsSLO https://download.qemu.org/qemu-"$QEMU_VERSION".tar.xz && \
+tar xvJf qemu-"$QEMU_VERSION".tar.xz && \
+cd qemu-"$QEMU_VERSION" && \
+./configure --target-list=ppc64-softmmu && \
+make -j$(nproc) && \
+cp ./build/qemu-system-ppc64 / && \
+cp ./build/qemu-bundle/usr/local/share/qemu/skiboot.lid / && \
+cd /build && \
+rm -rf qemu-"$QEMU_VERSION"* && \
+apt-get autoremove -y && \
+apt-get clean && \
+rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/*
--
2.30.2

[PATCH v3 0/2] ppc: Drop support for QEMU pseries

[Shawn Anastasio]

Hello all,

This small series drops support for the QEMU paravirtualized pseries
machine type in favor of the bare metal PowerNV platform. pseries
support was broken by 74b725a64d80 ('xen/ppc: Implement initial Radix
MMU support'), and instead of maintaining separate code paths to retain
support for the platform, I think it makes the most sense to drop it
entirely.

pseries was originally targeted for initial bringup since it has
historically been much better supported by QEMU, but PowerNV support in
QEMU has recently developed to the point where this is no longer a
concern.  Since I can think of very little practical use for running Xen
under pseries, and supporting it requires non-trivial duplication of
effort, drop support for it entirely.

This also requires a change to the ppc64le CI dockerfile to build a
newer version of QEMU than is available in the bullseye repository.

Thanks,
Shawn

--
v3: Build QEMU as test-artifact
v2: Add Fixes: tag to patch 2, add references to broken state of pseries

Shawn Anastasio (2):
  automation: Switch ppc64le tests to PowerNV machine type
  xen/ppc: Drop support for pseries/OpenFirmware

 .../build/debian/bullseye-ppc64le.dockerfile  |   5 +-
 automation/gitlab-ci/build.yaml   |  14 +++
 automation/gitlab-ci/test.yaml|   5 +-
 automation/scripts/qemu-smoke-ppc64le.sh  |   3 +-
 .../qemu-system-ppc64/8.1.0-ppc64.dockerfile  |  37 ++
 xen/arch/ppc/Makefile |   1 -
 xen/arch/ppc/boot-of.c| 113 --
 xen/arch/ppc/include/asm/boot.h   |  19 ---
 xen/arch/ppc/ppc64/Makefile   |   1 -
 xen/arch/ppc/ppc64/of-call.S  |  83 -
 xen/arch/ppc/setup.c  |  11 +-
 11 files changed, 62 insertions(+), 230 deletions(-)
 create mode 100644 
automation/tests-artifacts/qemu-system-ppc64/8.1.0-ppc64.dockerfile
 delete mode 100644 xen/arch/ppc/boot-of.c
 delete mode 100644 xen/arch/ppc/ppc64/of-call.S

--
2.30.2

Re: [PATCH v3 1/5] xen/ppc: Implement atomic.h

[Shawn Anastasio]

On 9/5/23 9:58 AM, Jan Beulich wrote:
> On 01.09.2023 20:25, Shawn Anastasio wrote:
>> +static inline atomic_t atomic_compareandswap(atomic_t old, atomic_t new,
>> + atomic_t *v)
>> +{
>> +atomic_t rc;
>> +rc.counter = __cmpxchg(&v->counter, old.counter, new.counter, 
>> sizeof(int));
> 
> I can't seem to be able to spot where __cmpxchg() is defined. (I really
> only wanted to check why it needs the 4th argument, which here rather
> would want to be e.g. sizeof(v->counter). If it can't be omitted.)
>

As you later saw, it's defined in system.h later in patch 3. This was an
error I made when splitting up the changes into this patchset. If you're
fine with it I'll just add a mention in the commit message that the
definitions in this commit are not yet fully usable.

Also I will change the size parameter to sizeof(v->counter) per your
suggestion.

>> +return rc;
>> +}
>> +
>> +#define arch_cmpxchg(ptr, o, n) 
>>\
>> +({  
>>\
>> +__typeof__(*(ptr)) o_ = (o);
>>\
>> +__typeof__(*(ptr)) n_ = (n);
>>\
>> +(__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long) o_,   
>>\
>> +   (unsigned long) n_, sizeof(*(ptr))); 
>>\
> 
> Nit: Stray blanks again after cast specifiers.
>

Will fix.

>> --- /dev/null
>> +++ b/xen/arch/ppc/include/asm/memory.h
>> @@ -0,0 +1,21 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * Copyright (C) IBM Corp. 2005
>> + *
>> + * Authors: Jimi Xenidis 
>> + */
>> +
>> +#ifndef _ASM_MEMORY_H_
>> +#define _ASM_MEMORY_H_
>> +
>> +#include 
> 
> As mentioned before - no need for this explicit #include.
>

Will drop.

>> +#ifdef CONFIG_SMP
>> +#define PPC_ATOMIC_ENTRY_BARRIER "sync\n"
>> +#define PPC_ATOMIC_EXIT_BARRIER  "sync\n"
>> +#else
>> +#define PPC_ATOMIC_ENTRY_BARRIER
>> +#define PPC_ATOMIC_EXIT_BARRIER
>> +#endif
> 
> Is this correct, considering that we have no CONFIG_SMP and assume SMP
> in all cases?
> 
> I'm sorry for not paying attention earlier.
>

Good observation, and no problem. I will remove the ifdef and the !SMP
case.

> Jan

Thanks,
Shawn

Re: [PATCH v5 4/5] xen/vpci: header: status register handler

[Stewart Hildebrand]

On 9/6/23 04:22, Jan Beulich wrote:
> On 01.09.2023 06:57, Stewart Hildebrand wrote:
>> Introduce a handler for the PCI status register, with ability to mask the
>> capabilities bit. The status register contains reserved bits, read-only bits,
>> and write-1-to-clear bits, so introduce bitmasks to handle these in vPCI. If 
>> a
>> bit in the bitmask is set, then the special meaning applies:
>>
>>   res_mask: read as zero, write ignore
>>   ro_mask: read normal, write ignore
>>   rw1c_mask: read normal, write 1 to clear
> 
> With the last one's name being descriptive of what the behavior is, would
> it make sense to name the first one "raz_mask"? (Also a question to Roger
> as the maintainer of this code.)

Another possible name is rsvdz_mask. See below.

>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -413,6 +413,18 @@ static void cf_check cmd_write(
>>  pci_conf_write16(pdev->sbdf, reg, cmd);
>>  }
>>
>> +static uint32_t cf_check status_read(const struct pci_dev *pdev,
>> + unsigned int reg, void *data)
>> +{
>> +struct vpci_header *header = data;
>> +uint32_t status = pci_conf_read16(pdev->sbdf, reg);
>> +
>> +if ( header->mask_cap_list )
>> +status &= ~PCI_STATUS_CAP_LIST;
>> +
>> +return status;
>> +}
> 
> Do you actually need this function? Can't you ...
> 
>> @@ -544,6 +556,12 @@ static int cf_check init_bars(struct pci_dev *pdev)
>>  if ( rc )
>>  return rc;
>>
>> +rc = vpci_add_register_mask(pdev->vpci, status_read, vpci_hw_write16,
>> +PCI_STATUS, 2, header, 
>> PCI_STATUS_RESERVED_MASK,
>> +PCI_STATUS_RO_MASK, PCI_STATUS_RW1C_MASK);
> 
> ... conditionally OR in PCI_STATUS_CAP_LIST right here? Without
> capabilities the CAP_LIST bit becomes kind of reserved anyway.

Hm. The PCI_STATUS_CAP_LIST bit is a read-only bit according to spec. Given the 
rationale below, we would want to preserve the value of r/o bits during writes, 
so this would essentially want to become a RsvdP bit. I wasn't planning on 
adding support for RsvdP bits here since there aren't any proper RsvdP bits in 
the status register. If instead we are okay with treating the 
PCI_STATUS_CAP_LIST bit as RsvdZ, then we could do as you suggest, but I'll 
plan to keep it as is for now.

>> @@ -424,9 +450,13 @@ static void vpci_write_helper(const struct pci_dev 
>> *pdev,
>>  uint32_t val;
>>
>>  val = r->read(pdev, r->offset, r->private);
>> +val &= ~r->res_mask;
>> +val &= ~r->rw1c_mask;
> 
> Personally I'd fold these two lines into just one (and similarly below).

Will do.

>>  data = merge_result(val, data, size, offset);
>>  }
>>
>> +data &= ~r->res_mask;
>> +data &= ~r->ro_mask;
> 
> This seems risky to me. I'd rather see the same value being written back
> for r/o bits, just in case a device doesn't actually implement a bit as
> mandated. 

Regarding writes to read-only bits: okay, I'll assume that Xen should take care 
of preserving the r/o bits (discarding the guests write value for the r/o bits).

If, on the other hand, we would want to rely on the guest to preserve the r/o 
bits during a write, then the ro_mask would effectively not be doing anything, 
so may as well be removed.

In either case, for partial register writes, Xen will take care of preserving 
the r/o bits for the remaining bytes in the register.

I'll make this change for the next version of the series (assuming Xen will 
handle preserving the r/o bits).

> For reserved flags it's less clear what's best, because in
> principle they could also become rw1c once defined.

Well, it depends on what version of the spec we read.

PCI Local Bus 3.0 spec section 6.1 says: "On writes, software must ensure that 
the values of reserved bit positions are preserved." PCI Local Bus 3.0 spec 
section 6.2.3 also says that we can essentially treat the whole status register 
as rw1c. Huh, that's odd.

PCI Express Base 4.0 spec defines two reserved bit types:
RsvdP: Reserved and Preserved - Reserved for future RW implementations. 
Software must preserve the value read for writes to bits.
RsvdZ: Reserved and Zero - Reserved for future RW1C implementations. Software 
must use 0b for writes to bits.
Both RsvdP and RsvdZ are read as zero.

I'm favoring using the definitions in the newer PCI Express Base 4.0 spec since 
they are clearer.

Regarding writes to rsvdp bits: there are none of these in the status register 
according to the PCI Express Base 4.0 spec. The older PCI Local Bus 3.0 spec is 
in conflict with this definition, but at the same time the PCI Local Bus 3.0 
spec also conflicts with itself by saying that the entire status register is 
essentially a rw1c register with reserved bits that should be preserved, which 
doesn't make sense. The newer PCI Express Base 4.0 spec is clearer, and appears 
to have resolved this inconsistency, so I'm favoring adher

Re: [XEN PATCH] x86/ACPI: Ignore entries with invalid APIC IDs when parsing MADT

[Stefano Stabellini]

On Thu, 7 Sep 2023, Jan Beulich wrote:
> On 06.09.2023 22:49, Stefano Stabellini wrote:
> > On Fri, 1 Sep 2023, Jan Beulich wrote:
> >> On 07.08.2023 11:38, Simon Gaiser wrote:
> >>> It seems some firmwares put dummy entries in the ACPI MADT table for non
> >>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
> >>> 0xff. Linux already has code to handle those cases both in
> >>> acpi_parse_lapic [1] as well as in acpi_parse_x2apic [2]. So add the
> >>> same check to Xen.
> >>>
> >>> Note that on some older (2nd gen Core i) laptop of mine I also saw dummy
> >>> entries with a valid APIC ID. Linux would still ignore those because
> >>> they have !ACPI_MADT_ENABLED && !ACPI_MADT_ONLINE_CAPABLE. But in Xen
> >>> this check is only active for madt_revision >= 5. But since this version
> >>> check seems to be intentionally I leave that alone.
> >>>
> >>> Link: 
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f3bf1dbe64b62a2058dd1944c00990df203e8e7a
> >>>  # [1]
> >>> Link: 
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10daf10ab154e31237a8c07242be3063fb6a9bf4
> >>>  # [2]
> >>> Signed-off-by: Simon Gaiser 
> >>
> >> This patch was committed with unaddressed review comments. The normal 
> >> action
> >> in such a case would be to revert, expecting a v2 to arrive. One 
> >> alternative
> >> here would be a timely incremental patch submission. Another alternative,
> >> considering in particular Thomas's most recent reply, would be to properly
> >> downgrade CPU hotplug support in SUPPORT.md (with a corresponding entry in
> >> CHANGELOG.md).
> > 
> > I am in favor of downgrading physical CPU hotplug support in
> > SUPPORT.md.
> > 
> > I noticed that there is no entry for physical CPU hotplug support in
> > SUPPORT.md today. Should we assume that it is not supported already as
> > it is not listed as supported?
> 
> Hmm, I see
> 
> ## Host hardware support
> 
> ### Physical CPU Hotplug
> 
> Status, x86: Supported
> 
> pretty close to the top of the file.

Ops, it must have been the case-sensitive search that failed me


> > Specifically, would it be a good idea to add a sentence at the top of
> > the file saying that anything not explicitly listed is not supported?
> 
> Iirc that was the plan to do for 4.18, but then we need to be sure that
> things don't unintentionally become unsupported. I've no clear idea how
> this plan was meant to be carried out, though.

it would be interesting to discuss it again

Re: [PATCH v2] docs/misra: add 14.3

[Stefano Stabellini]

On Thu, 7 Sep 2023, Jan Beulich wrote:
> On 07.09.2023 03:22, Stefano Stabellini wrote:
> > @@ -385,6 +386,17 @@ maintainers if you want to suggest a change.
> >   - A loop counter shall not have essentially floating type
> >   -
> >  
> > +   * - `Rule 14.3 
> > `_
> > + - Required
> > + - Controlling expressions shall not be invariant
> > + - Due to the extensive usage of IS_ENABLED, sizeof compile-time
> > +   checks, and other constructs that are detected as errors by MISRA
> > +   C scanners, managing the configuration of a MISRA C scanner for
> > +   this rule would be unmanageable. Thus, this rule is adopted with
> > +   a project-wide deviation on if ?: and switch statements.
> 
> Do we want to go as far as permitting this uniformly for all switch()? In
> my earlier reply I had included sizeof() for a reason.
 
I agree with you that it would be better to restrict it to only some
switch uses, rather than all of them.

But if we are going to restrict the deviation to switch(sizeof()), which
I think is a good idea and I am in favor, wouldn't it be better to
handle these cases as individual deviations? E.g. docs/misra/safe.json?
I am assuming there are only few cases like that and adding it here
makes the rule more complicated.

I am happy either way but I wanted to provide that as an option.


> Also (nit) there's at least a comma missing after "if". To make clear it's
> keywords that are meant, maybe better use if() / switch()?

OK I'll do that

[libvirt test] 182714: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 libvirt  bfe53e9145cd5996a791c5caff0686572b850f82
baseline version:
 libvirt  abecd6633e2b5c191080b6838c4c7658af3fddd8

Last test of basis   182642  2023-09-06 04:20:16 Z1 days
Testing same since   182714  2023-09-07 04:18:47 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Michal Privoznik 
  Peter Krempa 
  Tim Wiederhake 

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


--

Re: [PATCH v3 2/5] xen/ppc: Implement bitops.h

[Shawn Anastasio]

On 9/5/23 10:19 AM, Jan Beulich wrote:
> On 01.09.2023 20:25, Shawn Anastasio wrote:
>> Implement bitops.h, based on Linux's implementation as of commit
>> 5321d1b1afb9a17302c6cec79f0cbf823eb0d3fc. Though it is based off of
>> Linux's implementation, this code diverges significantly in a number of
>> ways:
>>   - Bitmap entries changed to 32-bit words to match X86 and Arm on Xen
>>   - PPC32-specific code paths dropped
>>   - Formatting completely re-done to more closely line up with Xen.
>> Including 4 space indentation.
> 
> Isn't ...
> 
>> Signed-off-by: Shawn Anastasio 
>> ---
>> v3:
>>   - Fix style of inline asm blocks.
>>   - Fix underscore-prefixed macro parameters/variables
>>   - Use __builtin_popcount for hweight* implementation
> 
> ... this also a divergence worth calling out?
>

Sure, I could mention that. But the hweight implementation from the
earlier patch diverged from linux's implementation too, for what it's
worth.

>> --- a/xen/arch/ppc/include/asm/bitops.h
>> +++ b/xen/arch/ppc/include/asm/bitops.h
>> @@ -1,9 +1,333 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * Adapted from Linux's arch/powerpc/include/asm/bitops.h.
>> + *
>> + * Merged version by David Gibson .
>> + * Based on ppc64 versions by: Dave Engebretsen, Todd Inglett, Don
>> + * Reed, Pat McCarthy, Peter Bergner, Anton Blanchard.  They
>> + * originally took it from the ppc32 code.
>> + */
>>  #ifndef _ASM_PPC_BITOPS_H
>>  #define _ASM_PPC_BITOPS_H
>>
>> +#include 
>> +
>> +#define __set_bit(n, p) set_bit(n, p)
>> +#define __clear_bit(n, p)   clear_bit(n, p)
>> +
>> +#define BITOP_BITS_PER_WORD 32
>> +#define BITOP_MASK(nr)  (1UL << ((nr) % BITOP_BITS_PER_WORD))
> 
> With the switch to 32-bit operations, doesn't this want to be 1U?
>

Sure, I'll make that change.

>> +#define BITOP_WORD(nr)  ((nr) / BITOP_BITS_PER_WORD)
>> +#define BITS_PER_BYTE   8
>> +
>>  /* PPC bit number conversion */
>> -#define PPC_BITLSHIFT(be)   (BITS_PER_LONG - 1 - (be))
>> -#define PPC_BIT(bit)(1UL << PPC_BITLSHIFT(bit))
>> -#define PPC_BITMASK(bs, be) ((PPC_BIT(bs) - PPC_BIT(be)) | PPC_BIT(bs))
>> +#define PPC_BITLSHIFT(be)(BITS_PER_LONG - 1 - (be))
>> +#define PPC_BIT(bit) (1UL << PPC_BITLSHIFT(bit))
>> +#define PPC_BITMASK(bs, be)  ((PPC_BIT(bs) - PPC_BIT(be)) | PPC_BIT(bs))
>> +
>> +/* Macro for generating the ***_bits() functions */
>> +#define DEFINE_BITOP(fn, op, prefix)
>>\
>> +static inline void fn(unsigned long mask,   
>>\
>> +  volatile unsigned int *p_)
>>\
>> +{   
>>\
>> +unsigned long old;  
>>\
>> +unsigned int *p = (unsigned int *)p_;   
>>\
>> +asm volatile ( prefix   
>>\
>> +   "1: lwarx %0,0,%3,0\n"   
>>\
>> +   #op "%I2 %0,%0,%2\n" 
>>\
>> +   "stwcx. %0,0,%3\n"   
>>\
>> +   "bne- 1b\n"  
>>\
>> +   : "=&r" (old), "+m" (*p) 
>>\
>> +   : "rK" (mask), "r" (p)   
>>\
>> +   : "cc", "memory" );  
>>\
>> +}
>> +
>> +DEFINE_BITOP(set_bits, or, "")
>> +DEFINE_BITOP(change_bits, xor, "")
>> +
>> +#define DEFINE_CLROP(fn, prefix)
>>\
>> +static inline void fn(unsigned long mask, volatile unsigned int *_p)
>>\
> 
> Leftover leading underscore.
>

Good catch. Will fix.

>> +{   
>>\
>> +unsigned long old;  
>>\
>> +unsigned int *p = (unsigned int *)_p;   
>>\
>> +asm volatile ( prefix   
>>\
>> +   "1: lwarx %0,0,%3,0\n"   
>>\
>> +   "andc %0,%0,%2\n"
>>\
>> +   "stwcx. %0,0,%3\n"   
>>\
>> +   "bne- 1b\n"  
>>\
>> +   : "=&r" (old), "+m" (*p) 
>>\
>> +   : "r" (mask), "r" (p)
>>\
>> +   : "cc", "memory" );  
>>\
>> +}
>> +
>>

Re: [XEN PATCH 1/3] docs/misra: add documentation skeleton for MISRA C:2012 Dir 4.1

[Stefano Stabellini]

On Fri, 1 Sep 2023, Nicola Vetrini wrote:
> The aforementioned directive requires the project to supply documentation
> on the measures taken towards the minimization of run-time failures.
> 
> The actual content of the documentation is yet to be written.
> 
> The 'rules.rst' file is updated accordingly to mention the newly
> added documentation.
> 
> Signed-off-by: Nicola Vetrini 
> ---
>  docs/misra/C-runtime-failures.rst | 239 ++
>  docs/misra/rules.rst  |   7 +-
>  2 files changed, 245 insertions(+), 1 deletion(-)
>  create mode 100644 docs/misra/C-runtime-failures.rst
> 
> diff --git a/docs/misra/C-runtime-failures.rst 
> b/docs/misra/C-runtime-failures.rst
> new file mode 100644
> index ..0d8d5adce231
> --- /dev/null
> +++ b/docs/misra/C-runtime-failures.rst
> @@ -0,0 +1,239 @@
> +===
> +Measures taken towards the minimization of Run-time failures in Xen
> +===
> +
> +This document specifies which procedures and techinques are used troughout 
> the
> +Xen codebase to prevent or minimize the impact of certain classes of run-time
> +errors that can occurr in the execution of a C program, due to the very 
> minimal
> +built-in checks that are present in the language.
> +
> +The presence of such documentation is requested by MISRA C:2012 Directive 
> 4.1,
> +whose headline states: "Run-time failures shall be minimized".
> +
> +
> +Documentation for MISRA C:2012 Dir 4.1: overflow
> +
> +
> +To be written.
> +Example: Pervasive use of assertions and extensive test suite.

Can we just say:
Pervasive use of assertions and extensive test suite.

Without "Example:" and without "To be written". It is clear that more
information is needed but we don't need to repeat it every time.



> +Documentation for MISRA C:2012 Dir 4.1: unexpected wrapping
> +___
> +
> +To be written.
> +Example: The only wrapping the is present in the code concerns
> +unsigned integers and they are all expected.

Same here, and also below (I won't repeat it every time)


> +Documentation for MISRA C:2012 Dir 4.1: invalid shift
> +_
> +
> +To be written.
> +Example: Pervasive use of assertions and extensive test suite.
> +
> +
> +Documentation for MISRA C:2012 Dir 4.1: division/remainder by zero
> +__
> +
> +To be written.
> +Example:
> +There division or remainder operations in the project code ensure that
> +their second argument is never zero.
> +
> +
> +Documentation for MISRA C:2012 Dir 4.1: unsequenced side effects
> +
> +
> +To be written.
> +Example:
> +No function in this project is meant to be executed from interrupt handlers
> +or in multi-threading environments.

This would not be true. We have code that is executed in interrupt
handlers, but we take care to use spinlocks and/or disable interrupts at
the right locations to avoid unsequenced side effects



> +Documentation for MISRA C:2012 Dir 4.1: read from uninitialized automatic 
> object
> +
> +
> +To be written.
> +Example:
> +Automatic variables are used to store temporary parameters and they
> +are always initialized to either a default value or a proper value
> +before usage.
> +
> +
> +Documentation for MISRA C:2012 Dir 4.1: read from uninitialized allocated 
> object
> +
> +
> +To be written.
> +Example:
> +The code does not use dynamically allocated storage.

We do use dynamically allocated storage with xzalloc but xzalloc
initializes the object to zero


> +Documentation for MISRA C:2012 Dir 4.1: write to string literal or const 
> object
> +___
> +
> +To be written.
> +Example:
> +The toolchain puts every string literal and const object into a read-only
> +section of memory.  The hardware exception raised when a write is attempted
> +on such a memory section is correctly handled.
> +
> +
> +Documentation for MISRA C:2012 Dir 4.1: non-volatile access to volatile 
> object
> +__
> +
> +To be written.
> +Example:
> +Volatile access is limited to registers that are always accessed
> +through macros or inline functions.

Or very specific limited code chucks that are only used to access a
register


> +Documentation for MISRA C:2012 Dir 4.1: access to dead allocated object
> +___
> +
> +To be written.
> +Example:
> +The code does not use dynam

Re: [XEN PATCH 2/3] docs: make the docs for MISRA C:2012 Dir 4.1 visible to ECLAIR

[Stefano Stabellini]

On Fri, 1 Sep 2023, Nicola Vetrini wrote:
> To be able to check for the existence of the necessary subsections in
> the documentation for MISRA C:2012 Dir 4.1, ECLAIR needs to have a source
> file that is built.
> 
> This file is generated from 'C-runtime-failures.rst' in docs/misra
> and the configuration is updated accordingly.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> Changes from RFC:
> - Dropped unused/useless code
> - Revised the sed command
> - Revised the clean target
> ---
>  docs/Makefile   |  7 ++-
>  docs/misra/Makefile | 17 +
>  2 files changed, 23 insertions(+), 1 deletion(-)
>  create mode 100644 docs/misra/Makefile
> 
> diff --git a/docs/Makefile b/docs/Makefile
> index 966a104490ac..ff991a0c3ca2 100644
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -43,7 +43,7 @@ DOC_PDF  := $(patsubst %.pandoc,pdf/%.pdf,$(PANDOCSRC-y)) \
>  all: build
>  
>  .PHONY: build
> -build: html txt pdf man-pages figs
> +build: html txt pdf man-pages figs misra
>  
>  .PHONY: sphinx-html
>  sphinx-html:
> @@ -66,9 +66,14 @@ endif
>  .PHONY: pdf
>  pdf: $(DOC_PDF)
>  
> +.PHONY: misra
> +misra:
> + $(MAKE) -C misra
> +
>  .PHONY: clean
>  clean: clean-man-pages
>   $(MAKE) -C figs clean
> + $(MAKE) -C misra clean
>   rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~
>   rm -rf *.ilg *.log *.ind *.toc *.bak *.tmp core
>   rm -rf html txt pdf sphinx/html
> diff --git a/docs/misra/Makefile b/docs/misra/Makefile
> new file mode 100644
> index ..8ea0505c8a20
> --- /dev/null
> +++ b/docs/misra/Makefile
> @@ -0,0 +1,17 @@
> +TARGETS := C-runtime-failures.o
> +
> +all: $(TARGETS)
> +
> +# sed is used in place of cat to prevent occurrences of '*/'
> +# in the .rst from breaking the compilation

Please expand this comment with what you are doing in this makefile and
specifically what kind of .c file you are generating and why.

Everything else looks good.


> +$(TARGETS:.o=.c): %.c: %.rst
> + echo "/*\n" > $@.tmp
> + sed -e 's|\*/|*//*|g' $< >> $@.tmp
> + echo "\n*/" >> $@.tmp
> + mv $@.tmp $@
> +
> +%.o: %.c
> + $(CC) -c $< -o $@
> +
> +clean:
> + rm -f C-runtime-failures.c *.o *.tmp
> -- 
> 2.34.1
> 

Re: [XEN PATCH 3/3] automation/eclair: build docs/misra to address MISRA C:2012 Dir 4.1

[Stefano Stabellini]

On Fri, 1 Sep 2023, Nicola Vetrini wrote:
> The documentation pertaining Directive 4.1 is contained in docs/misra.
> The build script driving the analysis is amended to allow ECLAIR to
> analyze such file.
> 
> Signed-off-by: Nicola Vetrini 
> ---
>  automation/eclair_analysis/build.sh   | 11 ---
>  automation/eclair_analysis/prepare.sh |  5 +++--
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/automation/eclair_analysis/build.sh 
> b/automation/eclair_analysis/build.sh
> index ec087dd822fa..556ed698bf8b 100755
> --- a/automation/eclair_analysis/build.sh
> +++ b/automation/eclair_analysis/build.sh
> @@ -34,11 +34,16 @@ else
>  fi
>  
>  (
> -  cd xen
> -
>make "-j${PROCESSORS}" "-l${PROCESSORS}.0"\
> "CROSS_COMPILE=${CROSS_COMPILE}" \
> "CC=${CROSS_COMPILE}gcc-12"  \
> "CXX=${CROSS_COMPILE}g++-12" \
> -   "XEN_TARGET_ARCH=${XEN_TARGET_ARCH}"
> +   "XEN_TARGET_ARCH=${XEN_TARGET_ARCH}" \
> +   -C docs misra

I don't think you need all these options to generate docs and misra.
Probably it would be sufficient just make -C docs misra

However given that they are not harmful:

Reviewed-by: Stefano Stabellini 


> +  make "-j${PROCESSORS}" "-l${PROCESSORS}.0"\
> +   "CROSS_COMPILE=${CROSS_COMPILE}" \
> +   "CC=${CROSS_COMPILE}gcc-12"  \
> +   "CXX=${CROSS_COMPILE}g++-12" \
> +   "XEN_TARGET_ARCH=${XEN_TARGET_ARCH}" \
> +  -C xen
>  )
> diff --git a/automation/eclair_analysis/prepare.sh 
> b/automation/eclair_analysis/prepare.sh
> index 275a1a3f517c..452e309b658b 100755
> --- a/automation/eclair_analysis/prepare.sh
> +++ b/automation/eclair_analysis/prepare.sh
> @@ -35,8 +35,9 @@ else
>  fi
>  
>  (
> -cd xen
> -cp "${CONFIG_FILE}" .config
> +./configure
> +cp "${CONFIG_FILE}" xen/.config
>  make clean
> +cd xen
>  make -f ${script_dir}/Makefile.prepare prepare
>  )
> -- 
> 2.34.1
> 

[xen-unstable test] 182717: tolerable trouble: fail/pass/starved - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-migrupgrade  11 xen-install/dst_host fail  like 182650
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 182650
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 182650
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 182650
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 182650
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 182650
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 182650
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 182650
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 182650
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 182650
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 182650
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 182650
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 182650
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-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-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-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-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-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-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-i386-libvirt-raw  14 migrate-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-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 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-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-arm64-arm64-xl-vhd   3 hosts-allocate   starved  n/a

version targeted for testing:
 xen  b2dd946ece74e2b6e0601f28caef72f4f9950102
baseline version:
 xen  9a216e92de9f9011097e4f1fb55ff67ba0a21704

Last test of basis   182650  2023-09-06 06:53:04 Z1 days
Testing same since   182717  2023-09-07 07:54:20 Z0 days1 attempts


People who touched revisions under test:
  David Gibson 
  Henry Wang 
  Jens Wiklander 
  Julien Gra

Re: [PATCH] coverage: update gcov info for newer versions of gcc

[Henry Wang]

Hi Jan,

> On Sep 7, 2023, at 22:41, Jan Beulich  wrote:
> 
> Henry - afaict this was submitted after the feature submission deadline,
> so you may want to consider giving it an exception.

Yes I am ok to include this in 4.18.

Kind regards,
Henry

> 
> Jan

Re: [PATCH v6 09/13] xen/arm: Extract MMU-specific MM code

[Henry Wang]

Hi Ayan,

> On Sep 7, 2023, at 19:34, Ayan Kumar Halder  wrote:
> 
> Hi Henry,
> 
>> +
>> +extern mfn_t directmap_mfn_start, directmap_mfn_end;
> 
> As you are declaring them for MMU specific , you also need this change :-
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 89ecb54be2..19b60c5d1b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -670,7 +670,7 @@ void __init populate_boot_allocator(void)
> 
>  s = bootinfo.reserved_mem.bank[i].start;
>  e = s + bootinfo.reserved_mem.bank[i].size;
> -#ifdef CONFIG_ARM_32
> +#if (CONFIG_ARM_32 && CONFIG_MMU)
>  /* Avoid the xenheap, note that the xenheap cannot across a bank 
> */
>  if ( s <= mfn_to_maddr(directmap_mfn_start) &&
>   e >= mfn_to_maddr(directmap_mfn_end) )
> @@ -708,7 +708,7 @@ void __init populate_boot_allocator(void)
>  if ( e > bank_end )
>  e = bank_end;
> 
> -#ifdef CONFIG_ARM_32
> +#if (CONFIG_ARM_32 && CONFIG_MMU)
>  /* Avoid the xenheap */
>  if ( s < mfn_to_maddr(directmap_mfn_end) &&
>   mfn_to_maddr(directmap_mfn_start) < e )
> 
> So that directmap_mfn_end and directmap_mfn_start is used only when MMU is 
> enabled.

I am not 100% sure on this, because currently there is no MPU code at
all, indicating all setup.c is MMU specific. In this case adding “&& CONFIG_MMU”
seems a little bit redundant to me. But I agree you made a point and it is 
correct
that when the MPU code is in, these “directmap” part should be gated with
CONFIG_MMU (or maybe split the code between arm32/arm64 to different helpers
to avoid #ifdef). Hence I would prefer doing these change when the MPU code is 
added.

Let’s see what maintainers will say. I am happy to do the change once we have
an agreement.

Kind regards,
Henry

> 
> - Ayan

[PATCH] Revert "EDAC/mce_amd: Do not load edac_mce_amd module on guests"

[Elliott Mitchell]

This reverts commit 767f4b620edadac579c9b8b6660761d4285fa6f9.

There are at least 3 valid reasons why a VM may see MCE events/registers.

First, the hypervisor may have a bug.  Ideally this should be dealt with
by fixing the hypervisor.  Failing that, the hypervisor and versions
effected need to be identified so only they are flagged as buggy.

Second, the Linux kernel may be handling adminstrative duties/hardware
for a hypervisor.  In this case, the events need to be processed and
potentially passed back through the hypervisor.

Third, the hypervisor may do full virtualization of MCE events.  In such
case, they should be handled normally.

Any of these blanket disabling the functionality is bad.  The original
patch was wrong.
---
 drivers/edac/mce_amd.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c
index 9215c06783df..1b7fccfbb654 100644
--- a/drivers/edac/mce_amd.c
+++ b/drivers/edac/mce_amd.c
@@ -1361,9 +1361,6 @@ static int __init mce_amd_init(void)
c->x86_vendor != X86_VENDOR_HYGON)
return -ENODEV;
 
-   if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR))
-   return -ENODEV;
-
if (boot_cpu_has(X86_FEATURE_SMCA)) {
xec_mask = 0x3f;
goto out;
-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Re: [PATCH] Revert "EDAC/mce_amd: Do not load edac_mce_amd module on guests"

[Borislav Petkov]

On Thu, Sep 07, 2023 at 08:08:00PM -0700, Elliott Mitchell wrote:
> This reverts commit 767f4b620edadac579c9b8b6660761d4285fa6f9.
> 
> There are at least 3 valid reasons why a VM may see MCE events/registers.

Hmm, so they all read like a bunch of handwaving to me, with those
probable hypothetical "may" formulations.

How about we cut to the chase and you explain what exactly is the
concrete issue you're encountering and trying to solve?

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[linux-linus test] 182719: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-vhd   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-pvshim8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-ws16-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-credit1   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-libvirt-xsm  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-shadow8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemut-win7-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-win7-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-libvirt-raw  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start   fail REGR. vs. 182531
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-freebsd12-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-xl-multivcpu  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-libvirt-qcow2  8 xen-boot   fail REGR. vs. 182531
 test-amd64-amd64-qemuu-nested-intel  8 xen-boot  fail REGR. vs. 182531
 test-amd64-amd64-pair12 xen-boot/src_hostfail REGR. vs. 182531
 test-amd64-amd64-pair13 xen-boot/dst_hostfail REGR. vs. 182531
 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host   fail REGR. vs. 182531
 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host   fail REGR. vs. 182531
 test-amd64-amd64-xl-xsm   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemut-ws16-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-qemuu-nested-amd  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-xl-pvhv2-amd  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-ovmf-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 8 xen-boot fail REGR. 
vs. 182531
 test-amd64-amd64-xl-qemut-debianhvm-amd64  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 182531
 test-amd64-amd64-xl   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-pvhv2-intel  8 xen-boot  fail REGR. vs. 182531
 test-amd64-amd64-libvirt  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-freebsd11-amd64  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 8 xen-boot fail REGR. vs. 
182531
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail REGR. 
vs. 182531
 test-amd64-amd64-pygrub   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-xl-credit2   8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-examine-uefi  8 reboot  fail REGR. vs. 182531
 test-amd64-amd64-examine-bios  8 reboot  fail REGR. vs. 182531
 test-amd64-coresched-amd64-xl  8 xen-bootfail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  8 xen-boot fail REGR. vs. 182531
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 182531
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 8 xen-boot fail REGR. vs. 
182531

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  8 xen-boot fail REGR. vs. 182531

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 182531
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 182531
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 182531
 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  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-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-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-x

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

[osstest service owner]

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

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  cba6d44a13d5e25334d164e27cb1b1d7674aa05e
baseline version:
 xen  1f79fce10a75f88d2c2a6ace469a4046bc1b9cb5

Last test of basis   182720  2023-09-07 14:03:27 Z0 days
Testing same since   182726  2023-09-08 02:00:26 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Nicola Vetrini 
  Olaf Hering 
  Shawn Anastasio 
  Stefano Stabellini 

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
   1f79fce10a..cba6d44a13  cba6d44a13d5e25334d164e27cb1b1d7674aa05e -> smoke

Re: [PATCH v2] docs/misra: add 14.3

[Jan Beulich]

On 07.09.2023 23:45, Stefano Stabellini wrote:
> On Thu, 7 Sep 2023, Jan Beulich wrote:
>> On 07.09.2023 03:22, Stefano Stabellini wrote:
>>> @@ -385,6 +386,17 @@ maintainers if you want to suggest a change.
>>>   - A loop counter shall not have essentially floating type
>>>   -
>>>  
>>> +   * - `Rule 14.3 
>>> `_
>>> + - Required
>>> + - Controlling expressions shall not be invariant
>>> + - Due to the extensive usage of IS_ENABLED, sizeof compile-time
>>> +   checks, and other constructs that are detected as errors by MISRA
>>> +   C scanners, managing the configuration of a MISRA C scanner for
>>> +   this rule would be unmanageable. Thus, this rule is adopted with
>>> +   a project-wide deviation on if ?: and switch statements.
>>
>> Do we want to go as far as permitting this uniformly for all switch()? In
>> my earlier reply I had included sizeof() for a reason.
>  
> I agree with you that it would be better to restrict it to only some
> switch uses, rather than all of them.
> 
> But if we are going to restrict the deviation to switch(sizeof()), which
> I think is a good idea and I am in favor, wouldn't it be better to
> handle these cases as individual deviations? E.g. docs/misra/safe.json?
> I am assuming there are only few cases like that and adding it here
> makes the rule more complicated.

Personally I think it wants to be both anyway. For one, anything written
here still needs respective SAF annotations for scanners to be uniformly
aware (dealing with deviations in just the Eclair configuration is imo
dubious). And then my general view is that by stating patterns here we
make clear that we tolerate new instances of such constructs, whereas in
other cases we'd be aiming at no deviations in new code.

Jan

Re: [PATCH v3 1/5] xen/ppc: Implement atomic.h

[Jan Beulich]

On 07.09.2023 22:10, Shawn Anastasio wrote:
> On 9/5/23 9:58 AM, Jan Beulich wrote:
>> On 01.09.2023 20:25, Shawn Anastasio wrote:
>>> +static inline atomic_t atomic_compareandswap(atomic_t old, atomic_t new,
>>> + atomic_t *v)
>>> +{
>>> +atomic_t rc;
>>> +rc.counter = __cmpxchg(&v->counter, old.counter, new.counter, 
>>> sizeof(int));
>>
>> I can't seem to be able to spot where __cmpxchg() is defined. (I really
>> only wanted to check why it needs the 4th argument, which here rather
>> would want to be e.g. sizeof(v->counter). If it can't be omitted.)
>>
> 
> As you later saw, it's defined in system.h later in patch 3. This was an
> error I made when splitting up the changes into this patchset. If you're
> fine with it I'll just add a mention in the commit message that the
> definitions in this commit are not yet fully usable.

Sure, that's going to be okay.

Jan

Re: [PATCH v3 2/5] xen/ppc: Implement bitops.h

[Jan Beulich]

On 08.09.2023 01:12, Shawn Anastasio wrote:
> On 9/5/23 10:19 AM, Jan Beulich wrote:
>> On 01.09.2023 20:25, Shawn Anastasio wrote:
>>> +#define DEFINE_TESTOP(fn, op, eh)  
>>> \
>>> +static inline unsigned long fn(unsigned long mask, volatile unsigned int 
>>> *_p)  \
>>> +{  
>>> \
>>> +unsigned long old, t;  
>>> \
>>> +unsigned int *p = (unsigned int *)_p;  
>>> \
>>> +asm volatile ( PPC_ATOMIC_ENTRY_BARRIER
>>> \
>>> +   "1: lwarx %0,0,%3,%4\n" 
>>> \
>>> +   #op "%I2 %1,%0,%2\n"
>>> \
>>> +   "stwcx. %1,0,%3\n"  
>>> \
>>> +   "bne- 1b\n" 
>>> \
>>> +   PPC_ATOMIC_EXIT_BARRIER 
>>> \
>>> +   : "=&r" (old), "=&r" (t)
>>> \
>>> +   : "rK" (mask), "r" (p), "n" (eh)
>>> \
>>> +   : "cc", "memory" ); 
>>> \
>>> +return (old & mask);   
>>> \
>>> +}
>>> +
>>> +DEFINE_TESTOP(test_and_set_bits, or, 0)
>>
>> Why can't test_and_clear_bits() not use this macro-ization? And if it
>> can't and hence there's only this single use, wouldn't it make sense
>> to avoid going through a macro here, too?
>>
> 
> I've just tried this, but unfortunately the "rK" constraint on the mask
> operand only works when instructions have both a reg/reg/reg as well as
> a reg/reg/imm16 form. This is the case for `or` but not `andc`. I guess
> it would be better to keep the two separate implementations rather than
> try to accomodate both cases in the macro somehow (e.g, by making the
> constraint's type a macro parameter as well).
> 
> I can also change the macro template into a standard function for just
> test_and_set_bits, given that it's the only user as you pointed out.
> 
> As for your previous observation about the superfluous `p` variable, it
> would seem the same applies to the macro here. Other than casting away
> the volatile qualifier on `p_` it doesn't seem to be doing much, so I'm
> inclined to remove it.

Right. Comments like this are generally intended to apply to the entire
patch or even entire series.

Jan

[ovmf test] 182727: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 634192665ea22eb610ad54f10bad8143ef77076d
baseline version:
 ovmf b29150aa3e9157908052c212d3afacbff8dbab1b

Last test of basis   182722  2023-09-07 16:10:41 Z0 days
Testing same since   182727  2023-09-08 03:42:30 Z0 days1 attempts


People who touched revisions under test:
  Michael Kubacki 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   b29150aa3e..634192665e  634192665ea22eb610ad54f10bad8143ef77076d -> 
xen-tested-master

Re: [PATCH v5 4/5] xen/vpci: header: status register handler

[Jan Beulich]

On 07.09.2023 23:29, Stewart Hildebrand wrote:
> On 9/6/23 04:22, Jan Beulich wrote:
>> On 01.09.2023 06:57, Stewart Hildebrand wrote:
>>> Introduce a handler for the PCI status register, with ability to mask the
>>> capabilities bit. The status register contains reserved bits, read-only 
>>> bits,
>>> and write-1-to-clear bits, so introduce bitmasks to handle these in vPCI. 
>>> If a
>>> bit in the bitmask is set, then the special meaning applies:
>>>
>>>   res_mask: read as zero, write ignore
>>>   ro_mask: read normal, write ignore
>>>   rw1c_mask: read normal, write 1 to clear
>>
>> With the last one's name being descriptive of what the behavior is, would
>> it make sense to name the first one "raz_mask"? (Also a question to Roger
>> as the maintainer of this code.)
> 
> Another possible name is rsvdz_mask. See below.

Ah, yes, that's better even if for now we won't need rsvdp support.

>>> --- a/xen/drivers/vpci/header.c
>>> +++ b/xen/drivers/vpci/header.c
>>> @@ -413,6 +413,18 @@ static void cf_check cmd_write(
>>>  pci_conf_write16(pdev->sbdf, reg, cmd);
>>>  }
>>>
>>> +static uint32_t cf_check status_read(const struct pci_dev *pdev,
>>> + unsigned int reg, void *data)
>>> +{
>>> +struct vpci_header *header = data;
>>> +uint32_t status = pci_conf_read16(pdev->sbdf, reg);
>>> +
>>> +if ( header->mask_cap_list )
>>> +status &= ~PCI_STATUS_CAP_LIST;
>>> +
>>> +return status;
>>> +}
>>
>> Do you actually need this function? Can't you ...
>>
>>> @@ -544,6 +556,12 @@ static int cf_check init_bars(struct pci_dev *pdev)
>>>  if ( rc )
>>>  return rc;
>>>
>>> +rc = vpci_add_register_mask(pdev->vpci, status_read, vpci_hw_write16,
>>> +PCI_STATUS, 2, header, 
>>> PCI_STATUS_RESERVED_MASK,
>>> +PCI_STATUS_RO_MASK, PCI_STATUS_RW1C_MASK);
>>
>> ... conditionally OR in PCI_STATUS_CAP_LIST right here? Without
>> capabilities the CAP_LIST bit becomes kind of reserved anyway.
> 
> Hm. The PCI_STATUS_CAP_LIST bit is a read-only bit according to spec. Given 
> the rationale below, we would want to preserve the value of r/o bits during 
> writes, so this would essentially want to become a RsvdP bit. I wasn't 
> planning on adding support for RsvdP bits here since there aren't any proper 
> RsvdP bits in the status register. If instead we are okay with treating the 
> PCI_STATUS_CAP_LIST bit as RsvdZ, then we could do as you suggest, but I'll 
> plan to keep it as is for now.

I'd say leverage rsvdz (with a comment) for the time being, but let's see
what Roger thinks.

>>> @@ -424,9 +450,13 @@ static void vpci_write_helper(const struct pci_dev 
>>> *pdev,
>>>  uint32_t val;
>>>
>>>  val = r->read(pdev, r->offset, r->private);
>>> +val &= ~r->res_mask;
>>> +val &= ~r->rw1c_mask;
>>
>> Personally I'd fold these two lines into just one (and similarly below).
> 
> Will do.
> 
>>>  data = merge_result(val, data, size, offset);
>>>  }
>>>
>>> +data &= ~r->res_mask;
>>> +data &= ~r->ro_mask;
>>
>> This seems risky to me. I'd rather see the same value being written back
>> for r/o bits, just in case a device doesn't actually implement a bit as
>> mandated. 
> 
> Regarding writes to read-only bits: okay, I'll assume that Xen should take 
> care of preserving the r/o bits (discarding the guests write value for the 
> r/o bits).
> 
> If, on the other hand, we would want to rely on the guest to preserve the r/o 
> bits during a write, then the ro_mask would effectively not be doing 
> anything, so may as well be removed.

We may never rely on the guest doing anything the way we want it.

> In either case, for partial register writes, Xen will take care of preserving 
> the r/o bits for the remaining bytes in the register.
> 
> I'll make this change for the next version of the series (assuming Xen will 
> handle preserving the r/o bits).
> 
>> For reserved flags it's less clear what's best, because in
>> principle they could also become rw1c once defined.
> 
> Well, it depends on what version of the spec we read.
> 
> PCI Local Bus 3.0 spec section 6.1 says: "On writes, software must ensure 
> that the values of reserved bit positions are preserved." PCI Local Bus 3.0 
> spec section 6.2.3 also says that we can essentially treat the whole status 
> register as rw1c. Huh, that's odd.
> 
> PCI Express Base 4.0 spec defines two reserved bit types:
> RsvdP: Reserved and Preserved - Reserved for future RW implementations. 
> Software must preserve the value read for writes to bits.
> RsvdZ: Reserved and Zero - Reserved for future RW1C implementations. Software 
> must use 0b for writes to bits.
> Both RsvdP and RsvdZ are read as zero.
> 
> I'm favoring using the definitions in the newer PCI Express Base 4.0 spec 
> since they are clearer.

+1

> Regarding writes to rsvdp bits: there are none of these in the status 
> register according to the

[qemu-mainline test] 182723: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-vhd1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-raw   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-coresched-i386-xl  1 build-check(1)   blocked  n/a
 test-amd64-coresched-amd64-xl  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-dom0pvh-xl-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-dom0pvh-xl-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt

Re: [XEN PATCH 1/3] docs/misra: add documentation skeleton for MISRA C:2012 Dir 4.1

[Jan Beulich]

On 08.09.2023 02:20, Stefano Stabellini wrote:
> On Fri, 1 Sep 2023, Nicola Vetrini wrote:
>> +Documentation for MISRA C:2012 Dir 4.1: read from uninitialized allocated 
>> object
>> +
>> +
>> +To be written.
>> +Example:
>> +The code does not use dynamically allocated storage.
> 
> We do use dynamically allocated storage with xzalloc but xzalloc
> initializes the object to zero

Just at the example of this: I'm not sure in how far the examples given
were actually meant to (remotely) apply to our code base. As to your
reply - there's also xmalloc() which doesn't, and the page allocator,
and other more specialized ones.

Jan