[PATCH v5 0/2] xen: Linker scripts synchronization

[Michal Orzel]

This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defined in just one place.

The first patch creates an empty header file xen.lds.h to store the
constructs mutual to both x86 and arm linker scripts. It also includes
this header in the scripts.

The second patch populates xen.lds.h with the first portion of common
macros and replaces the original contructs with these helpers.

Michal Orzel (2):
  xen: Introduce a header to store common linker scripts content
  xen: Populate xen.lds.h and make use of its macros

 xen/arch/arm/xen.lds.S|  45 +++--
 xen/arch/x86/xen.lds.S|  97 +++
 xen/include/xen/xen.lds.h | 137 ++
 3 files changed, 157 insertions(+), 122 deletions(-)
 create mode 100644 xen/include/xen/xen.lds.h

-- 
2.25.1

[PATCH v5 2/2] xen: Populate xen.lds.h and make use of its macros

[Michal Orzel]

Populate header file xen.lds.h with the first portion of macros storing
constructs common to x86 and arm linker scripts. Replace the original
constructs with these helpers.

No functional improvements to x86 linker script.

Making use of common macros improves arm linker script with:
- explicit list of debug sections that otherwise are seen as "orphans"
  by the linker. This will allow to fix issues after enabling linker
  option --orphan-handling one day,
- extended list of discarded section to include: .discard, destructors
  related sections, .fini_array which can reference .text.exit,
- sections not related to debugging that are placed by ld.lld. Even
  though we do not support linking with LLD on Arm, these sections do
  not cause problem to GNU ld,

As we are replacing hardcoded boundary specified as an argument to ALIGN
function with POINTER_ALIGN, this changes the alignment in HYPFS_PARAM
construct for arm32 from 8 to 4. It is fine as there are no 64bit values
used in struct param_hypfs.

Please note that this patch does not aim to perform the full sync up
between the linker scripts. It creates a base for further work.

Signed-off-by: Michal Orzel 
Reviewed-by: Jan Beulich 
---
Changes since v4:
-update commit msg with a note about changed alignment for HYPFS_PARAM on arm32
Changes since v3:
-use POINTER_ALIGN in debug sections when needed
-modify comment about ELF_DETAILS_SECTIONS
Changes since v2:
-refactor commit msg
-move constructs together with surrounding ifdefery
-list constructs other than *_SECTIONS in alphabetical order
-add comment about EFI vs EFI support
Changes since v1:
-merge x86 and arm changes into single patch
-do not propagate issues by generalizing CTORS
-extract sections not related to debugging into separate macro
-get rid of _SECTION suffix in favor of using more meaningful suffixes
---
 xen/arch/arm/xen.lds.S|  44 +++--
 xen/arch/x86/xen.lds.S|  96 +++-
 xen/include/xen/xen.lds.h | 129 ++
 3 files changed, 147 insertions(+), 122 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index d20e5e94e4..1e986e211f 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -69,12 +69,7 @@ SECTIONS
*(.proc.info)
__proc_info_end = .;
 
-#ifdef CONFIG_HAS_VPCI
-   . = ALIGN(POINTER_ALIGN);
-   __start_vpci_array = .;
-   *(SORT(.data.vpci.*))
-   __end_vpci_array = .;
-#endif
+   VPCI_ARRAY
   } :text
 
 #if defined(BUILD_ID)
@@ -110,12 +105,7 @@ SECTIONS
*(.data.schedulers)
__end_schedulers_array = .;
 
-#ifdef CONFIG_HYPFS
-   . = ALIGN(8);
-   __paramhypfs_start = .;
-   *(.data.paramhypfs)
-   __paramhypfs_end = .;
-#endif
+   HYPFS_PARAM
 
*(.data .data.*)
CONSTRUCTORS
@@ -179,12 +169,7 @@ SECTIONS
*(.altinstructions)
__alt_instructions_end = .;
 
-#ifdef CONFIG_DEBUG_LOCK_PROFILE
-   . = ALIGN(POINTER_ALIGN);
-   __lock_profile_start = .;
-   *(.lockprofile.data)
-   __lock_profile_end = .;
-#endif
+   LOCK_PROFILE_DATA
 
*(.init.data)
*(.init.data.rel)
@@ -223,22 +208,13 @@ SECTIONS
   /* Section for the device tree blob (if any). */
   .dtb : { *(.dtb) } :text
 
-  /* Sections to be discarded */
-  /DISCARD/ : {
-   *(.exit.text)
-   *(.exit.data)
-   *(.exitcall.exit)
-   *(.eh_frame)
-  }
-
-  /* Stabs debugging sections.  */
-  .stab 0 : { *(.stab) }
-  .stabstr 0 : { *(.stabstr) }
-  .stab.excl 0 : { *(.stab.excl) }
-  .stab.exclstr 0 : { *(.stab.exclstr) }
-  .stab.index 0 : { *(.stab.index) }
-  .stab.indexstr 0 : { *(.stab.indexstr) }
-  .comment 0 : { *(.comment) }
+  DWARF2_DEBUG_SECTIONS
+
+  DISCARD_SECTIONS
+
+  STABS_DEBUG_SECTIONS
+
+  ELF_DETAILS_SECTIONS
 }
 
 /*
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 1fcd8ab7c5..68501c7186 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -14,13 +14,6 @@
 #undef __XEN_VIRT_START
 #define __XEN_VIRT_START __image_base__
 #define DECL_SECTION(x) x :
-/*
- * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld
- * for PE output, in order to record that we'd prefer these sections to not
- * be loaded into memory.
- */
-#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) }
-#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) }
 
 ENTRY(efi_start)
 
@@ -28,8 +21,6 @@ ENTRY(efi_start)
 
 #define FORMAT "elf64-x86-64"
 #define DECL_SECTION(x) #x : AT(ADDR(#x) - __XEN_VIRT_START)
-#define DECL_DEBUG(x, a) #x 0 : { *(x) }
-#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
 
 ENTRY(start_pa)
 
@@ -160,12 +151,7 @@ SECTIONS
*(.note.gnu.build-id)
__note_gnu_build_id_end = .;
 #endif
-#ifdef CONFIG_HAS_VPCI
-   . = ALIGN(POINTER_ALIGN);
-   __start_vpci_array = .;
-   *(SORT(.data.vpci.*))
-   __end_vpci_array = .;
-#endif
+   VPCI_ARRAY
   } PHDR(text)
 
 #if defi

[PATCH v5 1/2] xen: Introduce a header to store common linker scripts content

[Michal Orzel]

Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen.lds.h to store the internals mutual to all
the linker scripts.

Include this header in linker scripts for x86 and arm.
This patch serves as an intermediate step before populating xen.lds.h
and making use of its content in the linker scripts later on.

Signed-off-by: Michal Orzel 
Acked-by: Jan Beulich 
---
Changes since v4:
-rebased
Changes since v2,v3:
-none
Changes since v1:
-rename header to xen.lds.h to be coherent with Linux kernel
-include empty header in linker scripts
---
 xen/arch/arm/xen.lds.S| 1 +
 xen/arch/x86/xen.lds.S| 1 +
 xen/include/xen/xen.lds.h | 8 
 3 files changed, 10 insertions(+)
 create mode 100644 xen/include/xen/xen.lds.h

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index ad7f966f0e..d20e5e94e4 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #undef ENTRY
 #undef ALIGN
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6926e88e54..1fcd8ab7c5 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #undef ENTRY
 #undef ALIGN
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
new file mode 100644
index 00..dd292fa7dc
--- /dev/null
+++ b/xen/include/xen/xen.lds.h
@@ -0,0 +1,8 @@
+#ifndef __XEN_LDS_H__
+#define __XEN_LDS_H__
+
+/*
+ * Common macros to be used in architecture specific linker scripts.
+ */
+
+#endif /* __XEN_LDS_H__ */
-- 
2.25.1

[ovmf test] 169297: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   41 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  319 attempts
Testing same since   169287  2022-04-10 21:10:35 Z0 days8 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [xen-unstable test] 169172: tolerable FAIL

[Roger Pau Monné]

On Wed, Apr 06, 2022 at 09:00:01AM +0200, Jan Beulich wrote:
> On 06.04.2022 00:30, osstest service owner wrote:
> > flight 169172 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/169172/
> > 
> > Failures :-/ but no regressions.
> > [...]
> > version targeted for testing:
> >  xen  e270af94280e6a9610705ebc1fdd1d7a9b1f8a98
> > baseline version:
> >  xen  e270af94280e6a9610705ebc1fdd1d7a9b1f8a98
> > 
> > Last test of basis   169172  2022-04-05 04:42:27 Z0 days
> > Testing same since  (not found) 0 attempts
> 
> I just happened to spot this. Perhaps not a big problem, but somewhat
> odd and present in earlier flight reports as well when those were
> simply re-testing an already tested (and pushed) revision.

Hm, indeed.  I will see if I can figure out what's wrong.

Thanks, Roger.

Re: osstest: boxes pending comission

[Roger Pau Monné]

On Mon, Apr 04, 2022 at 12:04:03PM +0200, Roger Pau Monné wrote:
> Hello,
> 
> We have the following boxes pending commission:
> 
> italias
>  * Commission flight at:
>http://logs.test-lab.xenproject.org/osstest/logs/169015/
>  * Issues:
>All fine except for the leak-check errors:
>  LEAKED [process 14559 run-parts] process: root 14559 14558  0 19:29 
> ?00:00:00 run-parts --report /etc/cron.daily 
>  LEAKED [process 14558 /bin/sh] process: root 14558  2252  0 19:29 ?  
>   00:00:00 /bin/sh -c run-parts --report /etc/cron.daily 
>  LEAKED [process 14564 /bin/sh] process: root 14564 14559  0 19:29 ?  
>   00:00:00 /bin/sh /etc/cron.daily/apt-compat 
>  LEAKED [process 14571 sleep] process: root 14571 14564  0 19:29 ?
> 00:00:00 sleep 1091 
>Those processes are from tasks started by cron. Disabling cron in
>rc.d during the host install doesn't seem to be honored later on,
>I'm looking into a fix for this.

This fix for this has been committed and passed pretest, so I'm going
to put the italias into service, the last flight LGTM and can be found
here:

http://logs.test-lab.xenproject.org/osstest/logs/169244/

Roger.

Re: [PATCH v6 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

> On 11 Apr 2022, at 07:15, Jan Beulich  wrote:
> 
> On 08.04.2022 22:25, Stefano Stabellini wrote:
>> On Fri, 8 Apr 2022, Jan Beulich wrote:
>>> On 08.04.2022 13:37, Luca Fancellu wrote:
 
 
> On 8 Apr 2022, at 10:01, Jan Beulich  wrote:
> 
> On 08.04.2022 10:45, Luca Fancellu wrote:
>> ---
>> docs/misc/arm/device-tree/cpupools.txt | 140 +
>> xen/arch/arm/include/asm/smp.h | 3 +
>> xen/common/Kconfig | 7 +
>> xen/common/Makefile | 1 +
>> xen/common/boot_cpupools.c | 207 +
>> xen/common/sched/cpupool.c | 12 +-
>> xen/include/xen/sched.h | 14 ++
>> 7 files changed, 383 insertions(+), 1 deletion(-)
>> create mode 100644 docs/misc/arm/device-tree/cpupools.txt
>> create mode 100644 xen/common/boot_cpupools.c
> 
> Under whose maintainership is the new file to fall? Without an
> addition to ./MAINTAINERS and without the file being placed in
> xen/common/sched/, it'll be REST maintainers, which I think would
> better be avoided. Would it perhaps make sense to have this as
> xen/common/sched/boot.c, allowing other boot-only code to
> potentially be moved there over time? This would then also avoid
> me asking about the underscore in the file name: Underscores are
> a somewhat artificial thing for use in places where dashes can't
> be used. Yet in the file system dashes are fine, and dashes are
> (slightly) easier to type.
> 
 
 Ok I can put the new file under xen/common/sched/ as boot.c, should this 
 new
 file be under this section?
 
 CPU POOLS
 M: Juergen Gross 
 M: Dario Faggioli 
 S: Supported
 F: xen/common/sched/cpupool.c
 + F: xen/common/sched/boot.c
>>> 
>>> If it's to hold general scheduler code (which this shorter name would
>>> suggest), it shouldn't need any change to ./MAINTAINERS as the
>>> scheduler section would already cover it then. If it was to remain
>>> CPU-pools-specific, then you'd need to stick to the longer name and
>>> put it in the section you have reproduced above.
>> 
>> In my opinion it is best if the maintenance of boot_cpupools.c falls
>> under "CPU POOLS". Luca, you can retain my reviewed-by when you add
>> the change to MAINTAINERS or rename the file.
> 
> Yet even then, with cpupools.c living in sched/, ...
> 
>> I don't have an opinion if it should be called
>> xen/common/boot_cpupools.c or xen/common/boot-cpupools.c
>> 
> 
> ... this one may want living there are well.

Yes I agree with you all, I will rename it to xen/common/sched/boot-cpupool.c
and add it in MAINTAINERS.

> 
> Jan

Re: [PATCH v6 5/6] arm/dom0less: assign dom0less guests to cpupools

[Luca Fancellu]

> On 8 Apr 2022, at 13:10, Jan Beulich  wrote:
> 
> On 08.04.2022 13:15, Luca Fancellu wrote:
>> 
>> 
>>> On 8 Apr 2022, at 11:24, Jan Beulich  wrote:
>>> 
>>> On 08.04.2022 11:39, Luca Fancellu wrote:
 
 
> On 8 Apr 2022, at 10:10, Jan Beulich  wrote:
> 
> On 08.04.2022 10:45, Luca Fancellu wrote:
>> @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
>> /* Per-vCPU buffer size in bytes. 0 to disable. */
>> uint32_t vmtrace_size;
>> 
>> + uint32_t cpupool_id;
> 
> This could do with a comment explaining default behavior. In particular
> I wonder what 0 means: Looking at cpupool_destroy() I can't see that it
> would be impossible to delete pool 0 (but there may of course be
> reasons elsewhere, e.g. preventing pool 0 to ever go empty) - Jürgen?
> Yet if pool 0 can be removed, zero being passed in here should imo not
> lead to failure of VM creation. Otoh I understand that this would
> already happen ahead of your change, preventing of which would
> apparently possible only via passing CPUPOOLID_NONE here.
 
 Pool-0 can’t be emptied because Dom0 is sitting there (the patch is 
 modifying
 cpupool_id only for DomUs).
>>> 
>>> But we're talking about dom0less as per the subject of the patch here.
>> 
>> Domains started using dom0less feature are not privileged and can’t do any 
>> operation
>> on cpu pools, that’s why I thought about Dom0.
> 
> It's all a matter of XSM policy what a domain may or may not be able
> to carry out.

Yes you are right, however I didn’t see so far this use case with a domU and 
the tool stack,
probably because it would need also xenstore etc… I’m aware that there is some 
work going
on to enable it also for dom0less domUs, so my question is:

Do you see this as a blocker for this patch? Are you ok if I send this patch 
with just the comment
below or in your opinion this patch requires some other work?

> 
 I thought the name was self explanatory, but if I have to put a comment, 
 would
 It work something like that:
 
 /* Cpupool id where the domain will be assigned on creation */
>>> 
>>> I don't view this kind of comment as necessary. I was really after
>>> calling out default behavior, along the lines of "0 to disable" that
>>> you can see in patch context.
>> 
>> Ok, could this work?
>> 
>> /* Domain cpupool id on creation. Default 0 as Pool-0 is always present. */
> 
> Hmm, I may have misguided you by talking about "default". There's no
> default here, as it's the caller's responsibility to set the field,
> and what's there will be used. Maybe "CPU pool to use; specify 0
> unless a specific existing pool is to be used".

Thank you, I will use it and update the patch.

> 
> Jan

[ovmf test] 169299: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   41 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  320 attempts
Testing same since   169287  2022-04-10 21:10:35 Z0 days9 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [PATCH v6 5/6] arm/dom0less: assign dom0less guests to cpupools

[Jan Beulich]

On 11.04.2022 10:54, Luca Fancellu wrote:
>> On 8 Apr 2022, at 13:10, Jan Beulich  wrote:
>> On 08.04.2022 13:15, Luca Fancellu wrote:
 On 8 Apr 2022, at 11:24, Jan Beulich  wrote:
 On 08.04.2022 11:39, Luca Fancellu wrote:
>> On 8 Apr 2022, at 10:10, Jan Beulich  wrote:
>> On 08.04.2022 10:45, Luca Fancellu wrote:
>>> @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
>>> /* Per-vCPU buffer size in bytes. 0 to disable. */
>>> uint32_t vmtrace_size;
>>>
>>> + uint32_t cpupool_id;
>>
>> This could do with a comment explaining default behavior. In particular
>> I wonder what 0 means: Looking at cpupool_destroy() I can't see that it
>> would be impossible to delete pool 0 (but there may of course be
>> reasons elsewhere, e.g. preventing pool 0 to ever go empty) - Jürgen?
>> Yet if pool 0 can be removed, zero being passed in here should imo not
>> lead to failure of VM creation. Otoh I understand that this would
>> already happen ahead of your change, preventing of which would
>> apparently possible only via passing CPUPOOLID_NONE here.
>
> Pool-0 can’t be emptied because Dom0 is sitting there (the patch is 
> modifying
> cpupool_id only for DomUs).

 But we're talking about dom0less as per the subject of the patch here.
>>>
>>> Domains started using dom0less feature are not privileged and can’t do any 
>>> operation
>>> on cpu pools, that’s why I thought about Dom0.
>>
>> It's all a matter of XSM policy what a domain may or may not be able
>> to carry out.
> 
> Yes you are right, however I didn’t see so far this use case with a domU and 
> the tool stack,
> probably because it would need also xenstore etc… I’m aware that there is 
> some work going
> on to enable it also for dom0less domUs, so my question is:
> 
> Do you see this as a blocker for this patch? Are you ok if I send this patch 
> with just the comment
> below or in your opinion this patch requires some other work?

Agreement looks to be that there should be precautionary code added
to prevent the deleting of pool 0. This imo wants to be a prereq
change to the one here.

Jan

[PATCH 0/8] IOMMU: assorted follow-on to XSA-400

[Jan Beulich]

Considering how long it took to get the XSA-400 series ready, it is
probably quite natural that in the course of doing so some further
items were found which want dealing with. There we go ...

1: IOMMU/x86: drop locking from quarantine_init() hooks
2: VT-d: drop ROOT_ENTRY_NR
3: VT-d: plug memory leaks in iommu_alloc()
4: VT-d: refuse to use IOMMU with reserved CAP.ND value
5: AMD/IOMMU: replace a few PCI_BDF2()
6: IOMMU: log appropriate SBDF
7: PCI: replace stray uses of PCI_{DEVFN,BDF}2()
8: PCI: replace "secondary" flavors of PCI_{DEVFN,BDF,SBDF}()

Jan

[PATCH 1/8] IOMMU/x86: drop locking from quarantine_init() hooks

[Jan Beulich]

Prior extension of these functions to enable per-device quarantine page
tables already didn't add more locking there, but merely left in place
what had been there before. But really locking is unnecessary here:
We're running with pcidevs_lock held (i.e. multiple invocations of the
same function [or their teardown equivalents] are impossible, and hence
there are no "local" races), while all consuming of the data being
populated here can't race anyway due to happening sequentially
afterwards. See also the comment in struct arch_pci_dev.

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -699,15 +699,11 @@ int cf_check amd_iommu_quarantine_init(s
 union amd_iommu_pte *root;
 struct page_info *pgs[IOMMU_MAX_PT_LEVELS] = {};
 
-spin_lock(&hd->arch.mapping_lock);
-
 root = __map_domain_page(pdev->arch.amd.root_table);
 rc = fill_qpt(root, level - 1, pgs);
 unmap_domain_page(root);
 
 pdev->arch.leaf_mfn = page_to_mfn(pgs[0]);
-
-spin_unlock(&hd->arch.mapping_lock);
 }
 
 page_list_move(&pdev->arch.pgtables_list, &hd->arch.pgtables.list);
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -3054,15 +3054,11 @@ static int cf_check intel_iommu_quaranti
 struct dma_pte *root;
 struct page_info *pgs[6] = {};
 
-spin_lock(&hd->arch.mapping_lock);
-
 root = map_vtd_domain_page(pdev->arch.vtd.pgd_maddr);
 rc = fill_qpt(root, level - 1, pgs);
 unmap_vtd_domain_page(root);
 
 pdev->arch.leaf_mfn = page_to_mfn(pgs[0]);
-
-spin_unlock(&hd->arch.mapping_lock);
 }
 
 page_list_move(&pdev->arch.pgtables_list, &hd->arch.pgtables.list);

[PATCH 2/8] VT-d: drop ROOT_ENTRY_NR

[Jan Beulich]

It's not only misplaced, but entirely unused.

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -204,7 +204,6 @@ struct context_entry {
 __uint128_t full;
 };
 };
-#define ROOT_ENTRY_NR (PAGE_SIZE_4K/sizeof(struct root_entry))
 #define context_present(c) ((c).lo & 1)
 #define context_fault_disable(c) (((c).lo >> 1) & 1)
 #define context_translation_type(c) (((c).lo >> 2) & 3)

[PATCH 3/8] VT-d: plug memory leaks in iommu_alloc()

[Jan Beulich]

While 97af062b89d5 ("IOMMU/x86: maintain a per-device pseudo domain ID")
took care of not making things worse, plugging pre-existing leaks wasn't
the purpose of that change; they're not security relevant after all.

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1238,8 +1238,9 @@ int __init iommu_alloc(struct acpi_drhd_
 drhd->iommu = iommu;
 
 iommu->reg = ioremap(drhd->address, PAGE_SIZE);
+rc = -ENOMEM;
 if ( !iommu->reg )
-return -ENOMEM;
+goto free;
 iommu->index = nr_iommus++;
 
 iommu->cap = dmar_readq(iommu->reg, DMAR_CAP_REG);
@@ -1260,8 +1261,9 @@ int __init iommu_alloc(struct acpi_drhd_
 printk(VTDPREFIX "cap = %"PRIx64" ecap = %"PRIx64"\n",
iommu->cap, iommu->ecap);
 }
+rc = -ENODEV;
 if ( !(iommu->cap + 1) || !(iommu->ecap + 1) )
-return -ENODEV;
+goto free;
 
 quirk_iommu_caps(iommu);
 
@@ -1272,7 +1274,8 @@ int __init iommu_alloc(struct acpi_drhd_
 {
 printk(XENLOG_ERR VTDPREFIX "IOMMU: unsupported\n");
 print_iommu_regs(drhd);
-return -ENODEV;
+rc = -ENODEV;
+goto free;
 }
 
 /* Calculate number of pagetable levels: 3 or 4. */
@@ -1283,7 +1286,8 @@ int __init iommu_alloc(struct acpi_drhd_
 {
 printk(XENLOG_ERR VTDPREFIX "IOMMU: unsupported sagaw %x\n", sagaw);
 print_iommu_regs(drhd);
-return -ENODEV;
+rc = -ENODEV;
+goto free;
 }
 iommu->nr_pt_levels = agaw_to_level(agaw);
 
@@ -1298,8 +1302,9 @@ int __init iommu_alloc(struct acpi_drhd_
 iommu->domid_bitmap = xzalloc_array(unsigned long,
 BITS_TO_LONGS(nr_dom));
 iommu->domid_map = xzalloc_array(domid_t, nr_dom);
+rc = -ENOMEM;
 if ( !iommu->domid_bitmap || !iommu->domid_map )
-return -ENOMEM;
+goto free;
 
 /*
  * If Caching mode is set, then invalid translations are tagged

[PATCH 4/8] VT-d: refuse to use IOMMU with reserved CAP.ND value

[Jan Beulich]

The field taking the value 7 (resulting in 18-bit DIDs when using the
calculation in cap_ndoms(), when the DID fields are only 16 bits wide)
is reserved. Instead of misbehaving in case we would encounter such an
IOMMU, refuse to use it.

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1267,8 +1267,11 @@ int __init iommu_alloc(struct acpi_drhd_
 
 quirk_iommu_caps(iommu);
 
+nr_dom = cap_ndoms(iommu->cap);
+
 if ( cap_fault_reg_offset(iommu->cap) +
  cap_num_fault_regs(iommu->cap) * PRIMARY_FAULT_REG_LEN > PAGE_SIZE ||
+ ((nr_dom - 1) >> 16) /* I.e. cap.nd > 6 */ ||
  (has_register_based_invalidation(iommu) &&
   ecap_iotlb_offset(iommu->ecap) >= PAGE_SIZE) )
 {
@@ -1294,8 +1297,6 @@ int __init iommu_alloc(struct acpi_drhd_
 if ( !ecap_coherent(iommu->ecap) )
 iommu_non_coherent = true;
 
-nr_dom = cap_ndoms(iommu->cap);
-
 if ( nr_dom <= DOMID_MASK * 2 + cap_caching_mode(iommu->cap) )
 {
 /* Allocate domain id (bit) maps. */

[PATCH 5/8] AMD/IOMMU: replace a few PCI_BDF2()

[Jan Beulich]

struct pci_dev has the wanted value directly available; use it. Note
that this fixes a - imo benign - mistake in reassign_device(): The unity
map removal ought to be based on the passed in devfn (as is the case on
the establishing side). This is benign because the mappings would be
removed anyway a little later, when the "main" device gets processed.
While there also limit the scope of two variables in that function.

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -287,7 +287,7 @@ void amd_iommu_flush_iotlb(u8 devfn, con
 if ( !pci_ats_enabled(pdev->seg, pdev->bus, pdev->devfn) )
 return;
 
-iommu = find_iommu_for_device(pdev->seg, PCI_BDF2(pdev->bus, pdev->devfn));
+iommu = find_iommu_for_device(pdev->seg, pdev->sbdf.bdf);
 
 if ( !iommu )
 {
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -617,7 +617,7 @@ int cf_check amd_iommu_msi_msg_update_ir
 unsigned int i, nr = 1;
 u32 data;
 
-bdf = pdev ? PCI_BDF2(pdev->bus, pdev->devfn) : hpet_sbdf.bdf;
+bdf = pdev ? pdev->sbdf.bdf : hpet_sbdf.bdf;
 seg = pdev ? pdev->seg : hpet_sbdf.seg;
 
 iommu = _find_iommu_for_device(seg, bdf);
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -455,11 +455,9 @@ static int cf_check reassign_device(
 struct pci_dev *pdev)
 {
 struct amd_iommu *iommu;
-int bdf, rc;
-const struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(pdev->seg);
+int rc;
 
-bdf = PCI_BDF2(pdev->bus, pdev->devfn);
-iommu = find_iommu_for_device(pdev->seg, bdf);
+iommu = find_iommu_for_device(pdev->seg, pdev->sbdf.bdf);
 if ( !iommu )
 {
 AMD_IOMMU_WARN("failed to find IOMMU: %pp cannot be assigned to %pd\n",
@@ -489,6 +487,9 @@ static int cf_check reassign_device(
  */
 if ( !is_hardware_domain(source) )
 {
+const struct ivrs_mappings *ivrs_mappings = 
get_ivrs_mappings(pdev->seg);
+unsigned int bdf = PCI_BDF2(pdev->bus, devfn);
+
 rc = amd_iommu_reserve_domain_unity_unmap(
  source,
  ivrs_mappings[get_dma_requestor_id(pdev->seg, 
bdf)].unity_map);
@@ -558,13 +559,11 @@ static int cf_check amd_iommu_add_device
 if ( !pdev->domain )
 return -EINVAL;
 
-bdf = PCI_BDF2(pdev->bus, pdev->devfn);
-
 for_each_amd_iommu(iommu)
-if ( pdev->seg == iommu->seg && bdf == iommu->bdf )
+if ( pdev->seg == iommu->seg && pdev->sbdf.bdf == iommu->bdf )
 return is_hardware_domain(pdev->domain) ? 0 : -ENODEV;
 
-iommu = find_iommu_for_device(pdev->seg, bdf);
+iommu = find_iommu_for_device(pdev->seg, pdev->sbdf.bdf);
 if ( unlikely(!iommu) )
 {
 /* Filter bridge devices. */
@@ -648,8 +647,7 @@ static int cf_check amd_iommu_remove_dev
 if ( !pdev->domain )
 return -EINVAL;
 
-bdf = PCI_BDF2(pdev->bus, pdev->devfn);
-iommu = find_iommu_for_device(pdev->seg, bdf);
+iommu = find_iommu_for_device(pdev->seg, pdev->sbdf.bdf);
 if ( !iommu )
 {
 AMD_IOMMU_WARN("failed to find IOMMU: %pp cannot be removed from 
%pd\n",

[PATCH 7/8] PCI: replace stray uses of PCI_{DEVFN,BDF}2()

[Jan Beulich]

There's no good reason to use these when we already have a pci_sbdf_t
type object available. This extends to the use of PCI_BUS() in
pci_ecam_map_bus() as well.

No change to generated code (with gcc11 at least, and I have to admit
that I didn't expect compilers to necessarily be able to spot the
optimization potential on the original code).

Signed-off-by: Jan Beulich 
---
Note that the Arm changes are "blind": I haven't been able to spot a way
to at least compile test the changes there; the code looks to be
entirely dead.

--- a/xen/arch/arm/pci/ecam.c
+++ b/xen/arch/arm/pci/ecam.c
@@ -28,8 +28,7 @@ void __iomem *pci_ecam_map_bus(struct pc
 container_of(bridge->ops, const struct pci_ecam_ops, pci_ops);
 unsigned int devfn_shift = ops->bus_shift - 8;
 void __iomem *base;
-
-unsigned int busn = PCI_BUS(sbdf.bdf);
+unsigned int busn = sbdf.bus;
 
 if ( busn < cfg->busn_start || busn > cfg->busn_end )
 return NULL;
@@ -37,7 +36,7 @@ void __iomem *pci_ecam_map_bus(struct pc
 busn -= cfg->busn_start;
 base = cfg->win + (busn << ops->bus_shift);
 
-return base + (PCI_DEVFN2(sbdf.bdf) << devfn_shift) + where;
+return base + (sbdf.df << devfn_shift) + where;
 }
 
 bool __init pci_ecam_need_p2m_hwdom_mapping(struct domain *d,
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -839,7 +839,7 @@ static int msix_capability_init(struct p
 pbus = dev->info.physfn.bus;
 pslot = PCI_SLOT(dev->info.physfn.devfn);
 pfunc = PCI_FUNC(dev->info.physfn.devfn);
-vf = PCI_BDF2(dev->bus, dev->devfn);
+vf = dev->sbdf.bdf;
 }
 
 table_paddr = read_pci_mem_bar(seg, pbus, pslot, pfunc, bir, vf);
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -267,7 +267,7 @@ int qinval_device_iotlb_sync(struct vtd_
 qinval_entry->q.dev_iotlb_inv_dsc.lo.res_1 = 0;
 qinval_entry->q.dev_iotlb_inv_dsc.lo.max_invs_pend = pdev->ats.queue_depth;
 qinval_entry->q.dev_iotlb_inv_dsc.lo.res_2 = 0;
-qinval_entry->q.dev_iotlb_inv_dsc.lo.sid = PCI_BDF2(pdev->bus, 
pdev->devfn);
+qinval_entry->q.dev_iotlb_inv_dsc.lo.sid = pdev->sbdf.bdf;
 qinval_entry->q.dev_iotlb_inv_dsc.lo.res_3 = 0;
 
 qinval_entry->q.dev_iotlb_inv_dsc.hi.size = size;

[PATCH 6/8] IOMMU: log appropriate SBDF

[Jan Beulich]

To handle phantom devices, several functions are passed separate "devfn"
arguments besides a PCI device. In such cases we want to log the phantom
device's coordinates instead of the main one's. (Note that not all of
the instances being changed are fallout from the referenced commit.)

Fixes: 1ee1441835f4 ("print: introduce a format specifier for pci_sbdf_t")
Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -291,7 +291,8 @@ void amd_iommu_flush_iotlb(u8 devfn, con
 
 if ( !iommu )
 {
-AMD_IOMMU_WARN("can't find IOMMU for %pp\n", &pdev->sbdf);
+AMD_IOMMU_WARN("can't find IOMMU for %pp\n",
+   &PCI_SBDF3(pdev->seg, pdev->bus, devfn));
 return;
 }
 
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -461,7 +461,7 @@ static int cf_check reassign_device(
 if ( !iommu )
 {
 AMD_IOMMU_WARN("failed to find IOMMU: %pp cannot be assigned to %pd\n",
-   &pdev->sbdf, target);
+   &PCI_SBDF3(pdev->seg, pdev->bus, devfn), target);
 return -ENODEV;
 }
 
@@ -497,8 +497,8 @@ static int cf_check reassign_device(
 return rc;
 }
 
-AMD_IOMMU_DEBUG("Re-assign %pp from dom%d to dom%d\n",
-&pdev->sbdf, source->domain_id, target->domain_id);
+AMD_IOMMU_DEBUG("Re-assign %pp from %pd to %pd\n",
+&PCI_SBDF3(pdev->seg, pdev->bus, devfn), source, target);
 
 return 0;
 }
@@ -575,7 +575,7 @@ static int cf_check amd_iommu_add_device
 }
 
 AMD_IOMMU_WARN("no IOMMU for %pp; cannot be handed to %pd\n",
-&pdev->sbdf, pdev->domain);
+&PCI_SBDF3(pdev->seg, pdev->bus, devfn), pdev->domain);
 return -ENODEV;
 }
 
@@ -618,7 +618,7 @@ static int cf_check amd_iommu_add_device
  ivrs_mappings[ivrs_mappings[bdf].dte_requestor_id].unity_map,
  0) )
 AMD_IOMMU_WARN("%pd: unity mapping failed for %pp\n",
-   pdev->domain, &pdev->sbdf);
+   pdev->domain, &PCI_SBDF2(pdev->seg, bdf));
 
 if ( iommu_quarantine && pdev->arch.pseudo_domid == DOMID_INVALID )
 {
@@ -651,7 +651,7 @@ static int cf_check amd_iommu_remove_dev
 if ( !iommu )
 {
 AMD_IOMMU_WARN("failed to find IOMMU: %pp cannot be removed from 
%pd\n",
-&pdev->sbdf, pdev->domain);
+&PCI_SBDF3(pdev->seg, pdev->bus, devfn), pdev->domain);
 return -ENODEV;
 }
 
@@ -664,7 +664,7 @@ static int cf_check amd_iommu_remove_dev
  pdev->domain,
  ivrs_mappings[ivrs_mappings[bdf].dte_requestor_id].unity_map) )
 AMD_IOMMU_WARN("%pd: unity unmapping failed for %pp\n",
-   pdev->domain, &pdev->sbdf);
+   pdev->domain, &PCI_SBDF2(pdev->seg, bdf));
 
 amd_iommu_quarantine_teardown(pdev);
 
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1406,7 +1406,7 @@ static int iommu_add_device(struct pci_d
 rc = iommu_call(hd->platform_ops, add_device, devfn, pci_to_dev(pdev));
 if ( rc )
 printk(XENLOG_WARNING "IOMMU: add %pp failed (%d)\n",
-   &pdev->sbdf, rc);
+   &PCI_SBDF3(pdev->seg, pdev->bus, devfn), rc);
 }
 }
 
@@ -1451,7 +1451,8 @@ static int iommu_remove_device(struct pc
 if ( !rc )
 continue;
 
-printk(XENLOG_ERR "IOMMU: remove %pp failed (%d)\n", &pdev->sbdf, rc);
+printk(XENLOG_ERR "IOMMU: remove %pp failed (%d)\n",
+   &PCI_SBDF3(pdev->seg, pdev->bus, devfn), rc);
 return rc;
 }
 

[PATCH 8/8] PCI: replace "secondary" flavors of PCI_{DEVFN,BDF,SBDF}()

[Jan Beulich]

At their use sites the numeric suffixes are at least odd to read, first
and foremost for PCI_DEVFN2() where the suffix doesn't even match the
number of arguments. Make use of count_args() such that a single flavor
each suffices (leaving aside helper macros, which aren't supposed to be
used from the outside).

In parse_ppr_log_entry() take the opportunity and drop two local
variables and convert an assignment to an initializer.

In VT-d code fold a number of bus+devfn comparison pairs into a single
BDF comparison.

No change to generated code for the vast majority of the adjustments.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4902,7 +4902,7 @@ int cf_check mmcfg_intercept_write(
 if ( pci_conf_write_intercept(mmio_ctxt->seg, mmio_ctxt->bdf,
   offset, bytes, p_data) >= 0 )
 pci_mmcfg_write(mmio_ctxt->seg, PCI_BUS(mmio_ctxt->bdf),
-PCI_DEVFN2(mmio_ctxt->bdf), offset, bytes,
+PCI_DEVFN(mmio_ctxt->bdf), offset, bytes,
 *(uint32_t *)p_data);
 
 return X86EMUL_OKAY;
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -90,7 +90,7 @@ int pci_conf_write_intercept(unsigned in
 
 pcidevs_lock();
 
-pdev = pci_get_pdev(seg, PCI_BUS(bdf), PCI_DEVFN2(bdf));
+pdev = pci_get_pdev(seg, PCI_BUS(bdf), PCI_DEVFN(bdf));
 if ( pdev )
 rc = pci_msi_conf_write_intercept(pdev, reg, size, data);
 
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -313,7 +313,7 @@ static int __init pci_mmcfg_check_hostbr
 for (i = 0; !name && i < ARRAY_SIZE(pci_mmcfg_probes); i++) {
 bus =  pci_mmcfg_probes[i].bus;
 devfn = pci_mmcfg_probes[i].devfn;
-l = pci_conf_read32(PCI_SBDF3(0, bus, devfn), 0);
+l = pci_conf_read32(PCI_SBDF(0, bus, devfn), 0);
 vendor = l & 0x;
 device = (l >> 16) & 0x;
 
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -27,8 +27,8 @@ static int cf_check get_reserved_device_
 xen_pfn_t start, xen_ulong_t nr, u32 id, void *ctxt)
 {
 struct get_reserved_device_memory *grdm = ctxt;
-uint32_t sbdf = PCI_SBDF3(grdm->map.dev.pci.seg, grdm->map.dev.pci.bus,
-  grdm->map.dev.pci.devfn).sbdf;
+uint32_t sbdf = PCI_SBDF(grdm->map.dev.pci.seg, grdm->map.dev.pci.bus,
+ grdm->map.dev.pci.devfn).sbdf;
 
 if ( !(grdm->map.flags & XENMEM_RDM_ALL) && (sbdf != id) )
 return 0;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1055,8 +1055,8 @@ static int cf_check get_reserved_device_
 xen_pfn_t start, xen_ulong_t nr, u32 id, void *ctxt)
 {
 struct get_reserved_device_memory *grdm = ctxt;
-uint32_t sbdf = PCI_SBDF3(grdm->map.dev.pci.seg, grdm->map.dev.pci.bus,
-  grdm->map.dev.pci.devfn).sbdf;
+uint32_t sbdf = PCI_SBDF(grdm->map.dev.pci.seg, grdm->map.dev.pci.bus,
+ grdm->map.dev.pci.devfn).sbdf;
 
 if ( !(grdm->map.flags & XENMEM_RDM_ALL) && (sbdf != id) )
 return 0;
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -96,7 +96,7 @@ static void __init add_ivrs_mapping_entr
 
 if ( !ivrs_mappings[alias_id].intremap_table )
 panic("No memory for %pp's IRT\n",
-  &PCI_SBDF2(iommu->seg, alias_id));
+  &PCI_SBDF(iommu->seg, alias_id));
 }
 }
 
@@ -790,7 +790,7 @@ static u16 __init parse_ivhd_device_spec
 }
 
 AMD_IOMMU_DEBUG("IVHD Special: %pp variety %#x handle %#x\n",
-&PCI_SBDF2(seg, bdf), special->variety, special->handle);
+&PCI_SBDF(seg, bdf), special->variety, special->handle);
 add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, 0, true,
iommu);
 
@@ -816,7 +816,7 @@ static u16 __init parse_ivhd_device_spec
 AMD_IOMMU_DEBUG("IVHD: Command line override present for IO-APIC 
%#x"
 "(IVRS: %#x devID %pp)\n",
 ioapic_sbdf[idx].id, special->handle,
-&PCI_SBDF2(seg, bdf));
+&PCI_SBDF(seg, bdf));
 break;
 }
 
@@ -888,7 +888,7 @@ static u16 __init parse_ivhd_device_spec
 AMD_IOMMU_DEBUG("IVHD: Command line override present for HPET %#x "
 "(IVRS: %#x devID %pp)\n",
 hpet_sbdf.id, special->handle,
-&PCI_SBDF2(seg, bdf));
+&PCI_SBDF(seg, bdf));
 break;
 case HPET_NONE:
 /* set device id of hpet */
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -40,7 +40,7 @@ static void send_iommu_command(struct am
  IOMMU_RIN

[PATCH v4] IOMMU/x86: disallow device assignment to PoD guests

[Jan Beulich]

While it is okay for IOMMU page tables to be set up for guests starting
in PoD mode, actual device assignment may only occur once all PoD
entries have been removed from the P2M. So far this was enforced only
for boot-time assignment, and only in the tool stack.

Also use the new function to replace p2m_pod_entry_count(): Its unlocked
access to p2m->pod.entry_count wasn't really okay (irrespective of the
result being stale by the time the caller gets to see it). Nor was the
use of that function in line with the immediately preceding comment: A
PoD guest isn't just one with a non-zero entry count, but also one with
a non-empty cache (e.g. prior to actually launching the guest).

To allow the tool stack to see a consistent snapshot of PoD state, move
the tail of XENMEM_{get,set}_pod_target handling into a function, adding
proper locking there.

In libxl take the liberty to use the new local variable r also for a
pre-existing call into libxc.

Signed-off-by: Jan Beulich 
---
If p2m->pod.entry_count == p2m->pod.count it is in principle possible to
permit device assignment by actively resolving all remaining PoD entries.

Initially I thought this was introduced by f89f555827a6 ("remove late
(on-demand) construction of IOMMU page tables"), but without
arch_iommu_use_permitted() checking for PoD I think the issue has been
there before that.
---
v4: Drop tool stack side change (superseded by 07449ecfa425). Extend VM
event related paragraph of description.
v3: In p2m_pod_set_mem_target() move check down.
v2: New.

--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -20,6 +20,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -360,7 +361,10 @@ p2m_pod_set_mem_target(struct domain *d,
 
 ASSERT( pod_target >= p2m->pod.count );
 
-ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
+if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
+ret = -ENOTEMPTY;
+else
+ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
 
 out:
 pod_unlock(p2m);
@@ -368,6 +372,23 @@ out:
 return ret;
 }
 
+void p2m_pod_get_mem_target(const struct domain *d, xen_pod_target_t *target)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+ASSERT(is_hvm_domain(d));
+
+pod_lock(p2m);
+lock_page_alloc(p2m);
+
+target->tot_pages   = domain_tot_pages(d);
+target->pod_cache_pages = p2m->pod.count;
+target->pod_entries = p2m->pod.entry_count;
+
+unlock_page_alloc(p2m);
+pod_unlock(p2m);
+}
+
 int p2m_pod_empty_cache(struct domain *d)
 {
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1391,6 +1412,9 @@ guest_physmap_mark_populate_on_demand(st
 if ( !paging_mode_translate(d) )
 return -EINVAL;
 
+if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
+return -ENOTEMPTY;
+
 do {
 rc = mark_populate_on_demand(d, gfn, chunk_order);
 
@@ -1412,3 +1436,20 @@ void p2m_pod_init(struct p2m_domain *p2m
 for ( i = 0; i < ARRAY_SIZE(p2m->pod.mrp.list); ++i )
 p2m->pod.mrp.list[i] = gfn_x(INVALID_GFN);
 }
+
+bool p2m_pod_active(const struct domain *d)
+{
+struct p2m_domain *p2m;
+bool res;
+
+if ( !is_hvm_domain(d) )
+return false;
+
+p2m = p2m_get_hostp2m(d);
+
+pod_lock(p2m);
+res = p2m->pod.entry_count | p2m->pod.count;
+pod_unlock(p2m);
+
+return res;
+}
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4804,7 +4804,6 @@ long arch_memory_op(unsigned long cmd, X
 {
 xen_pod_target_t target;
 struct domain *d;
-struct p2m_domain *p2m;
 
 if ( copy_from_guest(&target, arg, 1) )
 return -EFAULT;
@@ -4835,10 +4834,7 @@ long arch_memory_op(unsigned long cmd, X
 }
 else if ( rc >= 0 )
 {
-p2m = p2m_get_hostp2m(d);
-target.tot_pages   = domain_tot_pages(d);
-target.pod_cache_pages = p2m->pod.count;
-target.pod_entries = p2m->pod.entry_count;
+p2m_pod_get_mem_target(d, &target);
 
 if ( __copy_to_guest(arg, &target, 1) )
 rc = -EFAULT;
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -639,7 +639,7 @@ int vm_event_domctl(struct domain *d, st
 
 rc = -EXDEV;
 /* Disallow paging in a PoD guest */
-if ( p2m_pod_entry_count(p2m_get_hostp2m(d)) )
+if ( p2m_pod_active(d) )
 break;
 
 /* domain_pause() not required here, see XSA-99 */
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -513,11 +513,12 @@ bool arch_iommu_use_permitted(const stru
 {
 /*
  * Prevent device assign if mem paging, mem sharing or log-dirty
- * have been enabled for this domain.
+ * have been enabled for this domain, or if PoD is still in active use.
  */
 return d == dom_io ||
(likely(!mem_sharing_enabled(d)) &&
 likely(!mem_paging_en

Ping: [PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes

[Jan Beulich]

On 06.04.2022 16:23, Jan Beulich wrote:
> On 05.04.2022 10:45, Roger Pau Monné wrote:
>> On Thu, Mar 31, 2022 at 11:44:10AM +0200, Jan Beulich wrote:
>>> GrUB2 can be told to leave the screen in the graphics mode it has been
>>> using (or any other one), via "set gfxpayload=keep" (or suitable
>>> variants thereof). In this case we can avoid doing another mode switch
>>> ourselves. This in particular avoids possibly setting the screen to a
>>> less desirable mode: On one of my test systems the set of modes
>>> reported available by the VESA BIOS depends on whether the interposed
>>> KVM switch has that machine set as the active one. If it's not active,
>>> only modes up to 1024x768 get reported, while when active 1280x1024
>>> modes are also included. For things to always work with an explicitly
>>> specified mode (via the "vga=" option), that mode therefore needs be a
>>> 1024x768 one.
>>>
>>> For some reason this only works for me with "multiboot2" (and
>>> "module2"); "multiboot" (and "module") still forces the screen into text
>>> mode, despite my reading of the sources suggesting otherwise.
>>>
>>> For starters I'm limiting this to graphics modes; I do think this ought
>>> to also work for text modes, but
>>> - I can't tell whether GrUB2 can set any text mode other than 80x25
>>>   (I've only found plain "text" to be valid as a "gfxpayload" setting),
>>> - I'm uncertain whether supporting that is worth it, since I'm uncertain
>>>   how many people would be running their systems/screens in text mode,
>>> - I'd like to limit the amount of code added to the realmode trampoline.
>>>
>>> For starters I'm also limiting mode information retrieval to raw BIOS
>>> accesses. This will allow things to work (in principle) also with other
>>> boot environments where a graphics mode can be left in place. The
>>> downside is that this then still is dependent upon switching back to
>>> real mode, so retrieving the needed information from multiboot info is
>>> likely going to be desirable down the road.
>>>
>>> Signed-off-by: Jan Beulich 
>>
>> Acked-by: Roger Pau Monné 
> 
> May I ask for an ack or otherwise for the changelog entry, please?

Ping? This is the only thing missing for me to commit the remaining
parts of this series.

Thanks, Jan

[ovmf test] 169300: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   41 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  321 attempts
Testing same since   169287  2022-04-10 21:10:35 Z0 days   10 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [PATCH 1/8] IOMMU/x86: drop locking from quarantine_init() hooks

[Andrew Cooper]

On 11/04/2022 10:35, Jan Beulich wrote:
> Prior extension of these functions to enable per-device quarantine page
> tables already didn't add more locking there, but merely left in place
> what had been there before. But really locking is unnecessary here:
> We're running with pcidevs_lock held (i.e. multiple invocations of the
> same function [or their teardown equivalents] are impossible, and hence
> there are no "local" races), while all consuming of the data being
> populated here can't race anyway due to happening sequentially
> afterwards. See also the comment in struct arch_pci_dev.
>
> Signed-off-by: Jan Beulich 

It is only legitimate to drop these calls if you delete the mapping_lock
entirely.  Otherwise you're breaking the semantics of mapping_lock.

Your argument of "well this is already guarded by the pci lock" means
that these are uncontended lock/unlock operations, and therefore not
interesting to drop in the first place.

This patch is specifically setting us up for an XSA in the future when
the behaviour of the the PCI lock changes, the fix for which will be
revert this patch.

~Andrew

RE: Ping: [PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes

[Henry Wang]

Hi Jan,

> >>> Signed-off-by: Jan Beulich 
> >>
> >> Acked-by: Roger Pau Monné 
> >
> > May I ask for an ack or otherwise for the changelog entry, please?
> 
> Ping? This is the only thing missing for me to commit the remaining
> parts of this series.

Sorry for the late response, the previous e-mail that you directly
"to"ed me fell through the cracks somehow.

Acked-by: Henry Wang 

Since you also mentioned the changelog entry, I will take a note of this
series and we can have a discussion about adding it when we do the
next Xen release (4.17). Would that sound ok with you?

Kind regards,
Henry

> 
> Thanks, Jan

[xen-unstable test] 169292: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64   6 xen-buildfail REGR. vs. 169273

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 20 guest-localmigrate/x10 fail in 169273 pass in 
169292
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 
169273 pass in 169292
 test-armhf-armhf-xl  13 debian-fixup   fail pass in 169273

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

Re: Ping: [PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes

[Jan Beulich]

On 11.04.2022 12:11, Henry Wang wrote:
> Signed-off-by: Jan Beulich 

 Acked-by: Roger Pau Monné 
>>>
>>> May I ask for an ack or otherwise for the changelog entry, please?
>>
>> Ping? This is the only thing missing for me to commit the remaining
>> parts of this series.
> 
> Sorry for the late response, the previous e-mail that you directly
> "to"ed me fell through the cracks somehow.
> 
> Acked-by: Henry Wang 

Thanks.

> Since you also mentioned the changelog entry, I will take a note of this
> series and we can have a discussion about adding it when we do the
> next Xen release (4.17). Would that sound ok with you?

"Adding it" where? Maybe you mean to the release notes, but that's not
entirely clear.

Jan

Re: [PATCH v5 1/2] xen: Introduce a header to store common linker scripts content

[Julien Grall]

Hi Michal,

On 11/04/2022 08:02, Michal Orzel wrote:

Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen.lds.h to store the internals mutual to all
the linker scripts.

Include this header in linker scripts for x86 and arm.
This patch serves as an intermediate step before populating xen.lds.h
and making use of its content in the linker scripts later on.

Signed-off-by: Michal Orzel 
Acked-by: Jan Beulich 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v5 2/2] xen: Populate xen.lds.h and make use of its macros

[Julien Grall]

Hi Michal,

On 11/04/2022 08:03, Michal Orzel wrote:

Populate header file xen.lds.h with the first portion of macros storing
constructs common to x86 and arm linker scripts. Replace the original
constructs with these helpers.

No functional improvements to x86 linker script.

Making use of common macros improves arm linker script with:
- explicit list of debug sections that otherwise are seen as "orphans"
   by the linker. This will allow to fix issues after enabling linker
   option --orphan-handling one day,
- extended list of discarded section to include: .discard, destructors
   related sections, .fini_array which can reference .text.exit,
- sections not related to debugging that are placed by ld.lld. Even
   though we do not support linking with LLD on Arm, these sections do
   not cause problem to GNU ld,

As we are replacing hardcoded boundary specified as an argument to ALIGN
function with POINTER_ALIGN, this changes the alignment in HYPFS_PARAM
construct for arm32 from 8 to 4. It is fine as there are no 64bit values
used in struct param_hypfs.

Please note that this patch does not aim to perform the full sync up
between the linker scripts. It creates a base for further work.

Signed-off-by: Michal Orzel 
Reviewed-by: Jan Beulich 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH 1/8] IOMMU/x86: drop locking from quarantine_init() hooks

[Jan Beulich]

On 11.04.2022 12:01, Andrew Cooper wrote:
> On 11/04/2022 10:35, Jan Beulich wrote:
>> Prior extension of these functions to enable per-device quarantine page
>> tables already didn't add more locking there, but merely left in place
>> what had been there before. But really locking is unnecessary here:
>> We're running with pcidevs_lock held (i.e. multiple invocations of the
>> same function [or their teardown equivalents] are impossible, and hence
>> there are no "local" races), while all consuming of the data being
>> populated here can't race anyway due to happening sequentially
>> afterwards. See also the comment in struct arch_pci_dev.
>>
>> Signed-off-by: Jan Beulich 
> 
> It is only legitimate to drop these calls if you delete the mapping_lock
> entirely.  Otherwise you're breaking the semantics of mapping_lock.

Not for all domains other than DomIO. And DomIO is, well, special. As
is at what times quarantine_init() is actually being invoked.

> Your argument of "well this is already guarded by the pci lock" means
> that these are uncontended lock/unlock operations, and therefore not
> interesting to drop in the first place.
> 
> This patch is specifically setting us up for an XSA in the future when
> the behaviour of the the PCI lock changes, the fix for which will be
> revert this patch.

That wouldn't suffice then. As said in the description, and as discussed
during the development of the XSA-400 series, further locking would need
adding then.

Jan

Re: [PATCH v6 5/6] arm/dom0less: assign dom0less guests to cpupools

[Luca Fancellu]

> On 11 Apr 2022, at 10:08, Jan Beulich  wrote:
> 
> On 11.04.2022 10:54, Luca Fancellu wrote:
>>> On 8 Apr 2022, at 13:10, Jan Beulich  wrote:
>>> On 08.04.2022 13:15, Luca Fancellu wrote:
> On 8 Apr 2022, at 11:24, Jan Beulich  wrote:
> On 08.04.2022 11:39, Luca Fancellu wrote:
>>> On 8 Apr 2022, at 10:10, Jan Beulich  wrote:
>>> On 08.04.2022 10:45, Luca Fancellu wrote:
 @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
 /* Per-vCPU buffer size in bytes. 0 to disable. */
 uint32_t vmtrace_size;
 
 + uint32_t cpupool_id;
>>> 
>>> This could do with a comment explaining default behavior. In particular
>>> I wonder what 0 means: Looking at cpupool_destroy() I can't see that it
>>> would be impossible to delete pool 0 (but there may of course be
>>> reasons elsewhere, e.g. preventing pool 0 to ever go empty) - Jürgen?
>>> Yet if pool 0 can be removed, zero being passed in here should imo not
>>> lead to failure of VM creation. Otoh I understand that this would
>>> already happen ahead of your change, preventing of which would
>>> apparently possible only via passing CPUPOOLID_NONE here.
>> 
>> Pool-0 can’t be emptied because Dom0 is sitting there (the patch is 
>> modifying
>> cpupool_id only for DomUs).
> 
> But we're talking about dom0less as per the subject of the patch here.
 
 Domains started using dom0less feature are not privileged and can’t do any 
 operation
 on cpu pools, that’s why I thought about Dom0.
>>> 
>>> It's all a matter of XSM policy what a domain may or may not be able
>>> to carry out.
>> 
>> Yes you are right, however I didn’t see so far this use case with a domU and 
>> the tool stack,
>> probably because it would need also xenstore etc… I’m aware that there is 
>> some work going
>> on to enable it also for dom0less domUs, so my question is:
>> 
>> Do you see this as a blocker for this patch? Are you ok if I send this patch 
>> with just the comment
>> below or in your opinion this patch requires some other work?
> 
> Agreement looks to be that there should be precautionary code added
> to prevent the deleting of pool 0. This imo wants to be a prereq
> change to the one here.

Since we have the requirement of having cpu0 in pool-0, I’m thinking about a 
check to don’t allow
Cpu0 to be removed from pool-0, that will cover also the destroy case because 
we can’t destroy
a cpupool that is not empty.

In your opinion is it ok to proceed with a separate patch as prereq work having 
this change?

> 
> Jan

Re: [PATCH V4 1/2] xen/arm: Add i.MX lpuart driver

[Julien Grall]

Hi,

On 11/04/2022 07:26, Michal Orzel wrote:

On 08.04.2022 16:09, Peng Fan (OSS) wrote:

From: Peng Fan 

The i.MX LPUART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
Chatper 13.6 Low Power Universal Asynchronous Receiver/
Transmitter (LPUART)

Tested-by: Henry Wang 
Signed-off-by: Peng Fan 
---
  xen/arch/arm/include/asm/imx-lpuart.h |  64 ++
  xen/drivers/char/Kconfig  |   7 +
  xen/drivers/char/Makefile |   1 +
  xen/drivers/char/imx-lpuart.c | 276 ++
  4 files changed, 348 insertions(+)
  create mode 100644 xen/arch/arm/include/asm/imx-lpuart.h
  create mode 100644 xen/drivers/char/imx-lpuart.c

diff --git a/xen/arch/arm/include/asm/imx-lpuart.h 
b/xen/arch/arm/include/asm/imx-lpuart.h
new file mode 100644
index 00..26e2cf0249
--- /dev/null
+++ b/xen/arch/arm/include/asm/imx-lpuart.h
@@ -0,0 +1,64 @@
+/*
+ * xen/arch/arm/include/asm/imx-lpuart.h
+ *
+ * Common constant definition between early printk and the LPUART driver
+ *
+ * Peng Fan 
+ * Copyright 2022 NXP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARM_IMX_LPUART_H__
+#define __ASM_ARM_IMX_LPUART_H__
+
+/* 32-bit register definition */
+#define UARTBAUD  (0x10)
+#define UARTSTAT  (0x14)
+#define UARTCTRL  (0x18)
+#define UARTDATA  (0x1C)
+#define UARTMATCH (0x20)
+#define UARTMODIR (0x24)
+#define UARTFIFO  (0x28)
+#define UARTWATER (0x2c)
+
+#define UARTSTAT_TDRE BIT(23, UL)
+#define UARTSTAT_TC   BIT(22, UL)
+#define UARTSTAT_RDRF BIT(21, UL)
+#define UARTSTAT_OR   BIT(19, UL)
+
+#define UARTBAUD_OSR_SHIFT (24)
+#define UARTBAUD_OSR_MASK (0x1f)
+#define UARTBAUD_SBR_MASK (0x1fff)
+#define UARTBAUD_BOTHEDGE (0x0002)
+#define UARTBAUD_TDMAE(0x0080)
+#define UARTBAUD_RDMAE(0x0020)It seems like you missed my comment 
about alignment from the previous patch version.

Please keep the same alignment of values within the same section.


I haven't yet reviewed this patch. But if this is the only comment, then 
I can update the alignment on commit.


Cheers,

--
Julien Grall

Re: [PATCH v6 5/6] arm/dom0less: assign dom0less guests to cpupools

[Jan Beulich]

On 11.04.2022 12:20, Luca Fancellu wrote:
> 
> 
>> On 11 Apr 2022, at 10:08, Jan Beulich  wrote:
>>
>> On 11.04.2022 10:54, Luca Fancellu wrote:
 On 8 Apr 2022, at 13:10, Jan Beulich  wrote:
 On 08.04.2022 13:15, Luca Fancellu wrote:
>> On 8 Apr 2022, at 11:24, Jan Beulich  wrote:
>> On 08.04.2022 11:39, Luca Fancellu wrote:
 On 8 Apr 2022, at 10:10, Jan Beulich  wrote:
 On 08.04.2022 10:45, Luca Fancellu wrote:
> @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
> /* Per-vCPU buffer size in bytes. 0 to disable. */
> uint32_t vmtrace_size;
>
> + uint32_t cpupool_id;

 This could do with a comment explaining default behavior. In particular
 I wonder what 0 means: Looking at cpupool_destroy() I can't see that it
 would be impossible to delete pool 0 (but there may of course be
 reasons elsewhere, e.g. preventing pool 0 to ever go empty) - Jürgen?
 Yet if pool 0 can be removed, zero being passed in here should imo not
 lead to failure of VM creation. Otoh I understand that this would
 already happen ahead of your change, preventing of which would
 apparently possible only via passing CPUPOOLID_NONE here.
>>>
>>> Pool-0 can’t be emptied because Dom0 is sitting there (the patch is 
>>> modifying
>>> cpupool_id only for DomUs).
>>
>> But we're talking about dom0less as per the subject of the patch here.
>
> Domains started using dom0less feature are not privileged and can’t do 
> any operation
> on cpu pools, that’s why I thought about Dom0.

 It's all a matter of XSM policy what a domain may or may not be able
 to carry out.
>>>
>>> Yes you are right, however I didn’t see so far this use case with a domU 
>>> and the tool stack,
>>> probably because it would need also xenstore etc… I’m aware that there is 
>>> some work going
>>> on to enable it also for dom0less domUs, so my question is:
>>>
>>> Do you see this as a blocker for this patch? Are you ok if I send this 
>>> patch with just the comment
>>> below or in your opinion this patch requires some other work?
>>
>> Agreement looks to be that there should be precautionary code added
>> to prevent the deleting of pool 0. This imo wants to be a prereq
>> change to the one here.
> 
> Since we have the requirement of having cpu0 in pool-0, I’m thinking about a 
> check to don’t allow
> Cpu0 to be removed from pool-0, that will cover also the destroy case because 
> we can’t destroy
> a cpupool that is not empty.
> 
> In your opinion is it ok to proceed with a separate patch as prereq work 
> having this change?

Well, I did already say so (see context above).

Jan

Re: [PATCH V4 2/2] xen/arm: Add i.MX lpuart early printk support

[Julien Grall]

Hi,

On 11/04/2022 07:24, Michal Orzel wrote:

On 08.04.2022 16:09, Peng Fan (OSS) wrote:

From: Peng Fan 

Signed-off-by: Peng Fan 
---
  xen/arch/arm/Kconfig.debug  | 14 +++
  xen/arch/arm/arm64/debug-imx-lpuart.inc | 52 +
  2 files changed, 66 insertions(+)
  create mode 100644 xen/arch/arm/arm64/debug-imx-lpuart.inc

diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
index 35ccd13273..842d768280 100644
--- a/xen/arch/arm/Kconfig.debug
+++ b/xen/arch/arm/Kconfig.debug
@@ -58,6 +58,16 @@ choice
This option is preferred over the platform specific
options; the platform specific options are deprecated
and will soon be removed.
+   config EARLY_UART_CHOICE_IMX_LPUART
+   select EARLY_UART_IMX_LPUART
+   depends on ARM_64
+   bool "Early printk via i.MX LPUART"
+   help
+   Say Y here if you wish the early printk to direct their
+   output to a i.MX LPUART. You can use this option to
+   provide the parameters for the i.MX LPUART rather than
+   selecting one of the platform specific options below if
+   you know the parameters for the port.
config EARLY_UART_CHOICE_MESON
select EARLY_UART_MESON
depends on ARM_64
@@ -186,6 +196,9 @@ config EARLY_UART_CADENCE
  config EARLY_UART_EXYNOS4210
select EARLY_PRINTK
bool
+config EARLY_UART_IMX_LPUART
+   select EARLY_PRINTK
+   bool
  config EARLY_UART_MESON
select EARLY_PRINTK
bool
@@ -283,6 +296,7 @@ config EARLY_PRINTK_INC
default "debug-8250.inc" if EARLY_UART_8250
default "debug-cadence.inc" if EARLY_UART_CADENCE
default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
+   default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART
default "debug-meson.inc" if EARLY_UART_MESON
default "debug-mvebu.inc" if EARLY_UART_MVEBU
default "debug-pl011.inc" if EARLY_UART_PL011
diff --git a/xen/arch/arm/arm64/debug-imx-lpuart.inc 
b/xen/arch/arm/arm64/debug-imx-lpuart.inc
new file mode 100644
index 00..f68252da86
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-imx-lpuart.inc
@@ -0,0 +1,52 @@
+/*
+ * xen/arch/arm/arm64/debug-imx-lpuart.inc
+ *
+ * i.MX8QM specific debug code
+ *
+ * Peng Fan 
+ * Copyright 2022 NXP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+.macro early_uart_init wb wc wd
+/* Already initialized in bootloader */
+.endm
+

FWICS, early_uart_init call is protected with CONFIG_EARLY_UART_INIT that is set
only for PL011 UART. So I think there is no need to implement this empty macro,
unless we want to keep the same macros across the files no matter whether in 
use or not.
I think you need to ask Julien.


The call to early_uart_init is indeed protected by #ifdef 
CONFIG_EARLY_UART_INIT. The goal was to avoid having all debug-*.inc to 
implement dummy helper.


So I would prefer if early_uart_init is not implemented for 
debug-imx-lpuart.inc.


Cheers,

--
Julien Grall

Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()

[Julien Grall]

Hi,

On 11/04/2022 07:13, Jan Beulich wrote:

--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
unsigned int port;
struct evtchn *chn;

+/*

+ * The work done below is an attempt to keep pIRQ-s on the pCPU-s that the
+ * vCPU-s they're to be delivered to run on. In order to limit lock
+ * contention, check for an empty list prior to acquiring the lock. In the
+ * worst case a pIRQ just bound to this vCPU will be delivered elsewhere
+ * until the vCPU is migrated (again) to another pCPU.
+ */


AFAIU, the downside is another pCPU (and therefore vCPU) will get
disturbed by the interrupt.


But only rarely, i.e. in case a race would actually have occurred.


Maybe I am too paranoid here. The other side of race is controlled by a
domain. So wouldn't it be possible to increase how often the race is hit?


Yes, of course - just to harm itself.


Are you sure? Wouldn't this also harm the next vCPU running on the pCPU 
because it will get interrupted more often?


Cheers,

--
Julien Grall

Re: [PATCH v6 4/6] xen/cpupool: Create different cpupools at boot time

[Dario Faggioli]

On Mon, 2022-04-11 at 08:29 +, Luca Fancellu wrote:
> > On 11 Apr 2022, at 07:15, Jan Beulich  wrote:
> > On 08.04.2022 22:25, Stefano Stabellini wrote:
> > > In my opinion it is best if the maintenance of boot_cpupools.c
> > > falls
> > > under "CPU POOLS". Luca, you can retain my reviewed-by when you
> > > add
> > > the change to MAINTAINERS or rename the file.
> > 
> > Yet even then, with cpupools.c living in sched/, ...
> > 
> > > I don't have an opinion if it should be called
> > > xen/common/boot_cpupools.c or xen/common/boot-cpupools.c
> > > 
> > 
> > ... this one may want living there are well.
> 
> Yes I agree with you all, I will rename it to xen/common/sched/boot-
> cpupool.c
> and add it in MAINTAINERS.
> 
FWIW, I agree as well. With something like this, IMO:

CPU POOLS
M:  Juergen Gross 
M:  Dario Faggioli 
S:  Supported
F:  xen/common/sched/*cpupool.c

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


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

Re: [PATCH v4] IOMMU/x86: disallow device assignment to PoD guests

[Roger Pau Monné]

On Mon, Apr 11, 2022 at 11:47:46AM +0200, Jan Beulich wrote:
> While it is okay for IOMMU page tables to be set up for guests starting
> in PoD mode, actual device assignment may only occur once all PoD
> entries have been removed from the P2M. So far this was enforced only
> for boot-time assignment, and only in the tool stack.
> 
> Also use the new function to replace p2m_pod_entry_count(): Its unlocked
> access to p2m->pod.entry_count wasn't really okay (irrespective of the
> result being stale by the time the caller gets to see it). Nor was the
> use of that function in line with the immediately preceding comment: A
> PoD guest isn't just one with a non-zero entry count, but also one with
> a non-empty cache (e.g. prior to actually launching the guest).
> 
> To allow the tool stack to see a consistent snapshot of PoD state, move
> the tail of XENMEM_{get,set}_pod_target handling into a function, adding
> proper locking there.
> 
> In libxl take the liberty to use the new local variable r also for a
> pre-existing call into libxc.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

Just one comment below.

> ---
> If p2m->pod.entry_count == p2m->pod.count it is in principle possible to
> permit device assignment by actively resolving all remaining PoD entries.
> 
> Initially I thought this was introduced by f89f555827a6 ("remove late
> (on-demand) construction of IOMMU page tables"), but without
> arch_iommu_use_permitted() checking for PoD I think the issue has been
> there before that.
> ---
> v4: Drop tool stack side change (superseded by 07449ecfa425). Extend VM
> event related paragraph of description.
> v3: In p2m_pod_set_mem_target() move check down.
> v2: New.
> 
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -20,6 +20,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -360,7 +361,10 @@ p2m_pod_set_mem_target(struct domain *d,
>  
>  ASSERT( pod_target >= p2m->pod.count );
>  
> -ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
> +if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
> +ret = -ENOTEMPTY;

ENOTEMPTY seems weird here.  I think the reasoning is that the set of
passthrough devices is not empty? IMO it's confusing as the function
itself is related to buffer management, so returning ENOTEMPTY could
be confused with some other condition.

Might be less ambiguous to use EXDEV.

Thanks, Roger.

RE: Ping: [PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes

[Henry Wang]

Hi Jan,

> -Original Message-
> From: Jan Beulich 
> > Since you also mentioned the changelog entry, I will take a note of this
> > series and we can have a discussion about adding it when we do the
> > next Xen release (4.17). Would that sound ok with you?
> 
> "Adding it" where? Maybe you mean to the release notes, but that's not
> entirely clear.

Yeah, I meant the release notes. Thanks for pointing out that I did not use
accurate wording.

Kind regards,
Henry

> 
> Jan

Re: [PATCH v5 0/2] xen: Linker scripts synchronization

[Julien Grall]

Hi Michal,

On 11/04/2022 08:02, Michal Orzel wrote:

This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defined in just one place.

The first patch creates an empty header file xen.lds.h to store the
constructs mutual to both x86 and arm linker scripts. It also includes
this header in the scripts.

The second patch populates xen.lds.h with the first portion of common
macros and replaces the original contructs with these helpers.

Michal Orzel (2):
   xen: Introduce a header to store common linker scripts content
   xen: Populate xen.lds.h and make use of its macros


I have committed the two patches.

Cheers,

--
Julien Grall

[libvirt test] 169296: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 151777
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 151777
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 151777

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  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-raw   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-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

version targeted for testing:
 libvirt  c11fb2132f313b9aa25ad7c57becc72923623874
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  640 days
Failing since151818  2020-07-11 04:18:52 Z  639 days  621 attempts
Testing same since   169254  2022-04-09 04:20:15 Z2 days3 attempts


People who touched revisions under test:
Adolfo Jayme Barrientos 
  Aleksandr Alekseev 
  Aleksei Zakharov 
  Amneesh Singh 
  Andika Triwidada 
  Andrea Bolognani 
  Andrew Melnychenko 
  Ani Sinha 
  Balázs Meskó 
  Barrett Schonefeld 
  Bastian Germann 
  Bastien Orivel 
  BiaoXiang Ye 
  Bihong Yu 
  Binfeng Wu 
  Bjoern Walk 
  Boris Fiuczynski 
  Brad Laue 
  Brian Turek 
  Bruno Haible 
  Chris Mayo 
  Christian Borntraeger 
  Christian Ehrhardt 
  Christian Kirbach 
  Christian Schoenebeck 
  Christophe Fergeau 
  Claudio Fontana 
  Cole Robinson 
  Collin Walling 
  Cornelia Huck 
  Cédric Bosdonnat 
  Côme Borsoi 
  Daniel Henrique Barboza 
  Daniel Letai 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  Didik Supriadi 
  dinglimin 
  Divya Garg 
  Dmitrii Shcherbakov 
  Dmytro Linkin 
  Eiichi Tsukata 
  Emilio Herrera 
  Eric Farman 
  Erik Skultety 
  Fabian Affolter 
  Fabian Freyer 
  Fabiano Fidêncio 
  Fangge Jin 
  Farhan Ali 
  Fedora Weblate Translation 
  Franck Ridel 
  Gavi Teitz 
  gongwei 
  Guoyi Tu
  Göran Uddeborg 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Haonan Wang 
  Hela Basa 
  Helmut Grohne 
  Hiroki Narukawa 
  Hyman Huang(黄勇) 
  Ian Wienand 
  Ioanna Alifieraki 
  Ivan Teterevkov 
  Jakob Meng 
  Jamie Strandboge 
  Jamie Strandboge 
  Jan Kuparinen 
  jason lee 
  Jean-Baptiste Holcroft 
  Jia Zhou 
  Jianan Gao 
  Jim Fehlig 
  Jin Yan 
  Jing Qi 
  Jinsheng Zhang 
  Jiri Denemark 
  Joachim Falk 
  John Ferlan 
  John Levon 
  John Levon 
  Jonathan Watt 
  Jonathon Jongsma 
  Julio Faracco 
  Justin Gatzen 
  Ján Tomko 
  Kashyap Chamarthy 
  Kevin Locke 
  Kim InSoo 
  Koichi Murase 
  Kristina Hanicova 
  Laine Stump 
  Laszlo Ersek 
  Lee Yarwood 
  Lei Yang 
  Liao Pingfang 
  Lin Ma 
  Lin Ma 
  Lin Ma 
  Liu Yiding 
  Lubomir Rintel 
  Luke Yue 
  Luyao Zhong 
  Marc Hartmayer 
  Marc-André Lureau 
  Marek Marczykowski-Górecki 
  Markus Schade 
  Martin Kletzander 
  Martin Pitt 
  Masayoshi Mizuma 
  Matej Cepl 
  Matt Coleman 
  Matt Coleman 
  Mauro Matteo Cascella 
  Meina Li 
  Michal Privoznik 
  Michał Smyk 
  Milo Casagrande 
  Moshe Levi 
  Muha Aliss 
  Nathan 
  Neal Gompa 
  Nick Chevsky 
  Nick Shyrokovskiy 
  Nickys Music Group 
  Nico Pache 
  Nicolas Lécureuil 
  Nicolas Lécureuil 
  Nikolay Shirokovskiy 
  Nikolay Shirokovskiy 
  Olaf Hering 
  Olesya Gerasimenko 
  Or Ozeri 
  Orion Poplawski 
  Pany 
  Paolo Bonzini 
  Patrick Magauran 
  Paulo de Rezende Pinatti 
  Pavel Hrdina 
  Peng Liang 
  Peter Krempa 
  Pino Toscano 
  Pino Toscano 
  Piotr Drąg 
  Prathamesh Chavan 
  Praveen K Paladugu 
  Richard W.M. Jones 
  Ricky Tigg 
  Robin Lee 
  Rohit Kumar 
  Roman Bogorodskiy 

Re: [PATCH v4] IOMMU/x86: disallow device assignment to PoD guests

[Jan Beulich]

On 11.04.2022 12:29, Roger Pau Monné wrote:
> On Mon, Apr 11, 2022 at 11:47:46AM +0200, Jan Beulich wrote:
>> While it is okay for IOMMU page tables to be set up for guests starting
>> in PoD mode, actual device assignment may only occur once all PoD
>> entries have been removed from the P2M. So far this was enforced only
>> for boot-time assignment, and only in the tool stack.
>>
>> Also use the new function to replace p2m_pod_entry_count(): Its unlocked
>> access to p2m->pod.entry_count wasn't really okay (irrespective of the
>> result being stale by the time the caller gets to see it). Nor was the
>> use of that function in line with the immediately preceding comment: A
>> PoD guest isn't just one with a non-zero entry count, but also one with
>> a non-empty cache (e.g. prior to actually launching the guest).
>>
>> To allow the tool stack to see a consistent snapshot of PoD state, move
>> the tail of XENMEM_{get,set}_pod_target handling into a function, adding
>> proper locking there.
>>
>> In libxl take the liberty to use the new local variable r also for a
>> pre-existing call into libxc.
>>
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Roger Pau Monné 

Thanks.

>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -20,6 +20,7 @@
>>   */
>>  
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -360,7 +361,10 @@ p2m_pod_set_mem_target(struct domain *d,
>>  
>>  ASSERT( pod_target >= p2m->pod.count );
>>  
>> -ret = p2m_pod_set_cache_target(p2m, pod_target, 1/*preemptible*/);
>> +if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
>> +ret = -ENOTEMPTY;
> 
> ENOTEMPTY seems weird here.  I think the reasoning is that the set of
> passthrough devices is not empty?

Yes.

> IMO it's confusing as the function
> itself is related to buffer management, so returning ENOTEMPTY could
> be confused with some other condition.
> 
> Might be less ambiguous to use EXDEV.

I don't think there's any particularly good error code to use here.
Hence I've tried to pick one that makes some sense, and which isn't
widely used (this latter aspect would be EXDEV slightly less desirable).

Jan

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

[Bertrand Marquis]

Hi Stefano,

> On 9 Apr 2022, at 02:44, Stefano Stabellini  wrote:
> 
> On Fri, 8 Apr 2022, Stefano Stabellini wrote:
>> On Wed, 23 Mar 2022, Rahul Singh wrote:
>>> in dom0less system. This patch introduce the new feature to support the
>>> signaling between two domUs in dom0less system.
>>> 
>>> Signed-off-by: Rahul Singh 
>>> ---
>>> docs/designs/dom0less-evtchn.md | 96 +
>>> 1 file changed, 96 insertions(+)
>>> create mode 100644 docs/designs/dom0less-evtchn.md
>>> 
>>> diff --git a/docs/designs/dom0less-evtchn.md 
>>> b/docs/designs/dom0less-evtchn.md
>>> new file mode 100644
>>> index 00..6a1b7e8c22
>>> --- /dev/null
>>> +++ b/docs/designs/dom0less-evtchn.md
>>> @@ -0,0 +1,96 @@
>>> +# Signaling support between two domUs on dom0less system
>>> +
>>> +## Current state: Draft version
>>> +
>>> +## Proposer(s): Rahul Singh, Bertrand Marquis
>>> +
>>> +## Problem Statement:
>>> +
>>> +The goal of this work is to define a simple signaling system between Xen 
>>> guests
>>> +in dom0less systems.
>>> +
>>> +In dom0less system, we cannot make use of xenbus and xenstore that are 
>>> used in
>>> +normal systems with dynamic VMs to communicate between domains by 
>>> providing a
>>> +bus abstraction for paravirtualized drivers.
>>> +
>>> +One possible solution to implement the signaling system between domUs is 
>>> based
>>> +on event channels.
>> 
>> I suggest to reword this as follows:
>> 
>> ---
>> Dom0less guests would benefit from a statically-defined memory sharing
>> and signally system for communication. One that would be immediately
>> available at boot without any need for dynamic configurations.
>> 
>> In embedded a great variety of guest operating system kernels exist,
>> many of which don't have support for xenstore, grant table or other
>> complex drivers. Some of them are small kernel-space applications (often
>> called "baremetal", not to be confused with the term "baremetal" used in
>> datacenter which means "without hypervisors") or RTOSes.  Additionally,
>> for safety reasons, users often need to be able to configure the full
>> system statically so that it can be verified statically.
>> 
>> Event channels are very simple and can be added even to baremetal
>> applications. This proposal introduces a way to define them statically
>> to make them suitable to dom0less embedded deployments.
>> ---
>> 
>> 
>>> +## Proposal:
>>> +
>>> +Event channels are the basic primitive provided by Xen for event 
>>> notifications.
>>> +An event channel is a logical connection between 2 domains (more 
>>> specifically
>>> +between dom1,port1 and dom2,port2). They essentially store one bit of
>>> +information, the event of interest is signalled by transitioning this bit 
>>> from
>>> +0 to 1. An event is an equivalent of a hardware interrupt.
>>> +
>>> +Notifications are received by a guest via an interrupt from Xen to the 
>>> guest,
>>> +indicating when an event arrives (setting the bit). Further notifications 
>>> are
>>> +masked until the bit is cleared again. When a domain wants to wait for 
>>> data it
>>> +will block until an event arrives, and then send an event to signal that 
>>> data
>>> +has been consumed. Events are delivered asynchronously to guests and are
>>> +enqueued when the guest is not running.
>>> +
>>> +Event channel communication will be established statically between two domU
>>> +guests before unpausing the domains after domain creation. Event channel
>>> +connection information between domUs will be passed to XEN via device tree
>>> +node.
>>> +
>>> +Under the /chosen node, there needs to be sub nodes with compatible
>>> +"xen,evtchn" that descibes the event channel connection between two domUs.
>>> +
>>> +The event channel sub-node has the following properties:
>>> +
>>> +- compatible
>>> +
>>> +"xen,evtchn"
>>> +
>>> +- xen,evtchn
>>> +
>>> +The property is four numbers of tuples of
>>> +(local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:
>>> +
>>> +local-port-domU1 is an integer value that will be used to allocte local
>>> +port for domU1 to send an event notification to the remote domain.
>>> +
>>> +domU1-phandle is a single phandle to an domain to which 
>>> local-port-domU1
>>> +will be allocated.
>>> +
>>> +local-port-domU2 is an integer value that will be used to allocte local
>>> +port for domU2 to send an event notification to the remote domain.
>>> +
>>> +domU2-phandle is a single phandle to an domain to which 
>>> local-port-domU2
>>> +will be allocated.
>>> +
>>> +Example:
>>> +
>>> +chosen {
>>> +
>>> +
>>> +domU1: domU1 {
>>> +..
>>> +};
>>> +
>>> +domU2: domU2 {
>>> +..
>>> +};
>>> +
>>> +evtchn@1 {
>>> +compatible = "xen,evtchn";
>>> +xen,evtchn = <0xa &domU1 0xb &domU2>;
>>> +};
>>> +
>>> +evtchn@2 {
>>> +compatible = "xen,evtchn

Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()

[Jan Beulich]

On 11.04.2022 12:25, Julien Grall wrote:
> On 11/04/2022 07:13, Jan Beulich wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
>> unsigned int port;
>> struct evtchn *chn;
>> 
>> +/*
>> + * The work done below is an attempt to keep pIRQ-s on the pCPU-s 
>> that the
>> + * vCPU-s they're to be delivered to run on. In order to limit lock
>> + * contention, check for an empty list prior to acquiring the lock. 
>> In the
>> + * worst case a pIRQ just bound to this vCPU will be delivered 
>> elsewhere
>> + * until the vCPU is migrated (again) to another pCPU.
>> + */
>
> AFAIU, the downside is another pCPU (and therefore vCPU) will get
> disturbed by the interrupt.

 But only rarely, i.e. in case a race would actually have occurred.
>>>
>>> Maybe I am too paranoid here. The other side of race is controlled by a
>>> domain. So wouldn't it be possible to increase how often the race is hit?
>>
>> Yes, of course - just to harm itself.
> 
> Are you sure? Wouldn't this also harm the next vCPU running on the pCPU 
> because it will get interrupted more often?

Possibly, sure. But we don't make any promises here. And recall that
this optimization as a whole has been put under question in the past.
If we'd drop it, we'd also impact various vCPU-s in not really
predictable ways.

Jan

[ovmf test] 169302: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  322 attempts
Testing same since   169287  2022-04-10 21:10:35 Z0 days   11 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [PATCH v6 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi Luca,

On 08/04/2022 09:45, Luca Fancellu wrote:

diff --git a/docs/misc/arm/device-tree/cpupools.txt 
b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index ..40cc8135c66f
--- /dev/null
+++ b/docs/misc/arm/device-tree/cpupools.txt
@@ -0,0 +1,140 @@
+Boot time cpupools
+==
+
+When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible to
+create cpupools during boot phase by specifying them in the device tree.
+ACPI is not supported for this feature.
+
+Cpupools specification nodes shall be direct childs of /chosen node.
+Each cpupool node contains the following properties:
+
+- compatible (mandatory)
+
+Must always include the compatiblity string: "xen,cpupool".
+
+- cpupool-cpus (mandatory)
+
+Must be a list of device tree phandle to nodes describing cpus (e.g. having
+device_type = "cpu"), it can't be empty.
+
+- cpupool-sched (optional)
+
+Must be a string having the name of a Xen scheduler. Check the sched=<...>
+boot argument for allowed values [1]. When this property is omitted, the 
Xen
+default scheduler will be used.
+
+
+Constraints
+===
+
+If no cpupools are specified, all cpus will be assigned to one cpupool
+implicitly created (Pool-0).
+
+If cpupools node are specified, but not every cpu brought up by Xen is 
assigned,
+all the not assigned cpu will be assigned to an additional cpupool.
+
+If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen will
+stop.
+
+The boot cpu must be assigned to Pool-0, so the cpupool containing that core
+will become Pool-0 automatically.
+
+
+Examples
+
+
+A system having two types of core, the following device tree specification will
+instruct Xen to have two cpupools:
+
+- The cpupool with id 0 will have 4 cpus assigned.
+- The cpupool with id 1 will have 2 cpus assigned.


AFAIK, there are no guarantee that Xen will parse cpupool_a first. So it 
would be possible that the ID are inverted here.


This could happen if you want to keep the boot CPU in pool 0 and it is 
not cpu@0 (some bootloaders allows you to change the boot CPU).


Also, here you write "The cpupool with id X" but ...


+A system having the cpupools specification below will instruct Xen to have 
three
+cpupools:
+
+- The cpupool Pool-0 will have 2 cpus assigned.
+- The cpupool Pool-1 will have 2 cpus assigned.
+- The cpupool Pool-2 will have 2 cpus assigned (created by Xen with all the not
+  assigned cpus a53_3 and a53_4).


here you write "The cpupool Pool-X". Can you be consistent?

On a separate topic, I think dom0_max_vcpus() needs to be updated to by 
default (i.e when opt_dom0_max_vcpus == 0) the number of vCPUs match the 
number of vCPUs in the cpupool (I think 0) used to created dom0.


Cheers,

--
Julien Grall

Re: [xen-4.12-testing test] 169199: regressions - FAIL

[Julien Grall]

Hi,

On 08/04/2022 16:26, Roger Pau Monné wrote:

On Fri, Apr 08, 2022 at 12:24:27PM +0100, Julien Grall wrote:

Hi Roger,

On 08/04/2022 12:16, Roger Pau Monné wrote:

On Fri, Apr 08, 2022 at 12:08:02PM +0100, Julien Grall wrote:

Hi,

On 08/04/2022 12:01, Roger Pau Monné wrote:

I could add a suitable dom0_max_vcpus parameter to osstest.  XenServer
uses 16 for example.


I'm afraid a fixed number won't do, the more that iirc there are
systems with just a few cores in the pool (and you don't want to
over-commit by default).


But this won't over commit, it would just assign dom0 16 vCPUs at
most, if the system has less than 16 vCPUs that's what would be
assigned to dom0.


AFAICT, this is not the case on Arm. If you ask 16 vCPUs, then you will get
that number even if there are 8 pCPUs.

In fact, the documentation of dom0_max_vcpus suggests that the numbers of
vCPUs can be more than the number of pCPUs.


It was my understanding that you could only achieve that by using the
min-max nomenclature, so in order to force 16 vCPUs always you would
have to use:

dom0_max_vcpus=16-16

Otherwise the usage of '_max_' in the option name is pointless, and it
should instead be dom0_vcpus.

Anyway, I could use:

dom0_max_vcpus=1-16

Which is unambiguous and should get us 1 vCPU at least, or 16vCPUs at
most.


Unfortunately, Arm doesn't support the min-max nomenclature.


Hm, can we update the command line document then?

There's no mention that the min-max nomenclature is only available to
x86. I assume it's not possible to share the logic here so that both
Arm and x86 parse the option in the same way?


Looking at the x86 implementation, I think we can re-use everything but 
the pv_shim and NUMA bits.



We don't need to store this information anywhere I think. Since we
first install plain Debian and then install Xen we can always fetch
the number of physical CPUs when running plain Linux and use that to
calculate the amount to give to dom0?


You will need to check how that works with U-boot. I can't remember 
whether the script is loaded via tftp or stored on the local disk.


Cheers,

--
Julien Grall

Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()

[Julien Grall]

Hi,

On 11/04/2022 11:45, Jan Beulich wrote:

On 11.04.2022 12:25, Julien Grall wrote:

On 11/04/2022 07:13, Jan Beulich wrote:

--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
 unsigned int port;
 struct evtchn *chn;
 
+/*

+ * The work done below is an attempt to keep pIRQ-s on the pCPU-s that the
+ * vCPU-s they're to be delivered to run on. In order to limit lock
+ * contention, check for an empty list prior to acquiring the lock. In the
+ * worst case a pIRQ just bound to this vCPU will be delivered elsewhere
+ * until the vCPU is migrated (again) to another pCPU.
+ */


AFAIU, the downside is another pCPU (and therefore vCPU) will get
disturbed by the interrupt.


But only rarely, i.e. in case a race would actually have occurred.


Maybe I am too paranoid here. The other side of race is controlled by a
domain. So wouldn't it be possible to increase how often the race is hit?


Yes, of course - just to harm itself.


Are you sure? Wouldn't this also harm the next vCPU running on the pCPU
because it will get interrupted more often?


Possibly, sure. But we don't make any promises here. And recall that
this optimization as a whole has been put under question in the past.


I don't remember this discussion. Do you have a pointer?


If we'd drop it, we'd also impact various vCPU-s in not really
predictable ways.


Cheers,

--
Julien Grall

Re: [PATCH V4 1/2] xen/arm: Add i.MX lpuart driver

[Michal Orzel]

Hi Julien,

On 11.04.2022 12:20, Julien Grall wrote:
> Hi,
> 
> On 11/04/2022 07:26, Michal Orzel wrote:
>> On 08.04.2022 16:09, Peng Fan (OSS) wrote:
>>> From: Peng Fan 
>>>
>>> The i.MX LPUART Documentation:
>>> https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
>>> Chatper 13.6 Low Power Universal Asynchronous Receiver/
>>> Transmitter (LPUART)
>>>
>>> Tested-by: Henry Wang 
>>> Signed-off-by: Peng Fan 
>>> ---
>>>   xen/arch/arm/include/asm/imx-lpuart.h |  64 ++
>>>   xen/drivers/char/Kconfig  |   7 +
>>>   xen/drivers/char/Makefile |   1 +
>>>   xen/drivers/char/imx-lpuart.c | 276 ++
>>>   4 files changed, 348 insertions(+)
>>>   create mode 100644 xen/arch/arm/include/asm/imx-lpuart.h
>>>   create mode 100644 xen/drivers/char/imx-lpuart.c
>>>
>>> diff --git a/xen/arch/arm/include/asm/imx-lpuart.h 
>>> b/xen/arch/arm/include/asm/imx-lpuart.h
>>> new file mode 100644
>>> index 00..26e2cf0249
>>> --- /dev/null
>>> +++ b/xen/arch/arm/include/asm/imx-lpuart.h
>>> @@ -0,0 +1,64 @@
>>> +/*
>>> + * xen/arch/arm/include/asm/imx-lpuart.h
>>> + *
>>> + * Common constant definition between early printk and the LPUART driver
>>> + *
>>> + * Peng Fan 
>>> + * Copyright 2022 NXP
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#ifndef __ASM_ARM_IMX_LPUART_H__
>>> +#define __ASM_ARM_IMX_LPUART_H__
>>> +
>>> +/* 32-bit register definition */
>>> +#define UARTBAUD  (0x10)
>>> +#define UARTSTAT  (0x14)
>>> +#define UARTCTRL  (0x18)
>>> +#define UARTDATA  (0x1C)
>>> +#define UARTMATCH (0x20)
>>> +#define UARTMODIR (0x24)
>>> +#define UARTFIFO  (0x28)
>>> +#define UARTWATER (0x2c)
>>> +
>>> +#define UARTSTAT_TDRE BIT(23, UL)
>>> +#define UARTSTAT_TC   BIT(22, UL)
>>> +#define UARTSTAT_RDRF BIT(21, UL)
>>> +#define UARTSTAT_OR   BIT(19, UL)
>>> +
>>> +#define UARTBAUD_OSR_SHIFT (24)
>>> +#define UARTBAUD_OSR_MASK (0x1f)
>>> +#define UARTBAUD_SBR_MASK (0x1fff)
>>> +#define UARTBAUD_BOTHEDGE (0x0002)
>>> +#define UARTBAUD_TDMAE    (0x0080)
>>> +#define UARTBAUD_RDMAE    (0x0020)It seems like you missed my comment 
>>> about alignment from the previous patch version.
>> Please keep the same alignment of values within the same section.
> 
> I haven't yet reviewed this patch. But if this is the only comment, then I 
> can update the alignment on commit.
> 
> Cheers,
> 

All my other findings have already been fixed by Peng. This is the last one as 
it was forgotten.
Patch 2/2 still has sth to be fixed so the alignment can be fixed in the same 
shot as well.

Cheers,
Michal

Re: Xen Project management working group

[Olivier Lambert]

https://doodle.com/meeting/participate/id/b822G1ge


I will probably leave the Doodle opened for few days (like up to Monday 
evening) until we can decide the best schedule without waiting too long. When 
I'll have the validated time slot, I'll communicate about it here.



So, as planned, here is the selected date. I picked this Thursday, April the 
14th, at 4PM UTC (5PM London time, 6PM Paris time). Don't forget to add this to 
your calendar :)


Meeting place will be:

https://meet.vates.fr/xenmgmt


See you soon!




Regards,


Olivier Lambert | Vates CEO
XCP-ng & Xen Orchestra - Vates solutions
w: vates.fr | xcp-ng.org | xen-orchestra.com

Re: [PATCH V4 2/2] xen/arm: Add i.MX lpuart early printk support

[Michal Orzel]

Hi Julien,

On 11.04.2022 12:23, Julien Grall wrote:
> Hi,
> 
> On 11/04/2022 07:24, Michal Orzel wrote:
>> On 08.04.2022 16:09, Peng Fan (OSS) wrote:
>>> From: Peng Fan 
>>>
>>> Signed-off-by: Peng Fan 
>>> ---
>>>   xen/arch/arm/Kconfig.debug  | 14 +++
>>>   xen/arch/arm/arm64/debug-imx-lpuart.inc | 52 +
>>>   2 files changed, 66 insertions(+)
>>>   create mode 100644 xen/arch/arm/arm64/debug-imx-lpuart.inc
>>>
>>> diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
>>> index 35ccd13273..842d768280 100644
>>> --- a/xen/arch/arm/Kconfig.debug
>>> +++ b/xen/arch/arm/Kconfig.debug
>>> @@ -58,6 +58,16 @@ choice
>>>   This option is preferred over the platform specific
>>>   options; the platform specific options are deprecated
>>>   and will soon be removed.
>>> +    config EARLY_UART_CHOICE_IMX_LPUART
>>> +    select EARLY_UART_IMX_LPUART
>>> +    depends on ARM_64
>>> +    bool "Early printk via i.MX LPUART"
>>> +    help
>>> +    Say Y here if you wish the early printk to direct their
>>> +    output to a i.MX LPUART. You can use this option to
>>> +    provide the parameters for the i.MX LPUART rather than
>>> +    selecting one of the platform specific options below if
>>> +    you know the parameters for the port.
>>>   config EARLY_UART_CHOICE_MESON
>>>   select EARLY_UART_MESON
>>>   depends on ARM_64
>>> @@ -186,6 +196,9 @@ config EARLY_UART_CADENCE
>>>   config EARLY_UART_EXYNOS4210
>>>   select EARLY_PRINTK
>>>   bool
>>> +config EARLY_UART_IMX_LPUART
>>> +    select EARLY_PRINTK
>>> +    bool
>>>   config EARLY_UART_MESON
>>>   select EARLY_PRINTK
>>>   bool
>>> @@ -283,6 +296,7 @@ config EARLY_PRINTK_INC
>>>   default "debug-8250.inc" if EARLY_UART_8250
>>>   default "debug-cadence.inc" if EARLY_UART_CADENCE
>>>   default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
>>> +    default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART
>>>   default "debug-meson.inc" if EARLY_UART_MESON
>>>   default "debug-mvebu.inc" if EARLY_UART_MVEBU
>>>   default "debug-pl011.inc" if EARLY_UART_PL011
>>> diff --git a/xen/arch/arm/arm64/debug-imx-lpuart.inc 
>>> b/xen/arch/arm/arm64/debug-imx-lpuart.inc
>>> new file mode 100644
>>> index 00..f68252da86
>>> --- /dev/null
>>> +++ b/xen/arch/arm/arm64/debug-imx-lpuart.inc
>>> @@ -0,0 +1,52 @@
>>> +/*
>>> + * xen/arch/arm/arm64/debug-imx-lpuart.inc
>>> + *
>>> + * i.MX8QM specific debug code
>>> + *
>>> + * Peng Fan 
>>> + * Copyright 2022 NXP
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include 
>>> +
>>> +.macro early_uart_init wb wc wd
>>> +/* Already initialized in bootloader */
>>> +.endm
>>> +
>> FWICS, early_uart_init call is protected with CONFIG_EARLY_UART_INIT that is 
>> set
>> only for PL011 UART. So I think there is no need to implement this empty 
>> macro,
>> unless we want to keep the same macros across the files no matter whether in 
>> use or not.
>> I think you need to ask Julien.
> 
> The call to early_uart_init is indeed protected by #ifdef 
> CONFIG_EARLY_UART_INIT. The goal was to avoid having all debug-*.inc to 
> implement dummy helper.
> 
> So I would prefer if early_uart_init is not implemented for 
> debug-imx-lpuart.inc.
> 
> Cheers,
> 

I agree.
As a side note, do we still need to support platform specific options for early 
printk?
If not, I am happy to send a patch removing them.

Cheers,
Michal

Re: [PATCH v6 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

> On 11 Apr 2022, at 11:58, Julien Grall  wrote:
> 
> Hi Luca,
> 
> On 08/04/2022 09:45, Luca Fancellu wrote:
>> diff --git a/docs/misc/arm/device-tree/cpupools.txt 
>> b/docs/misc/arm/device-tree/cpupools.txt
>> new file mode 100644
>> index ..40cc8135c66f
>> --- /dev/null
>> +++ b/docs/misc/arm/device-tree/cpupools.txt
>> @@ -0,0 +1,140 @@
>> +Boot time cpupools
>> +==
>> +
>> +When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible 
>> to
>> +create cpupools during boot phase by specifying them in the device tree.
>> +ACPI is not supported for this feature.
>> +
>> +Cpupools specification nodes shall be direct childs of /chosen node.
>> +Each cpupool node contains the following properties:
>> +
>> +- compatible (mandatory)
>> +
>> +Must always include the compatiblity string: "xen,cpupool".
>> +
>> +- cpupool-cpus (mandatory)
>> +
>> +Must be a list of device tree phandle to nodes describing cpus (e.g. 
>> having
>> +device_type = "cpu"), it can't be empty.
>> +
>> +- cpupool-sched (optional)
>> +
>> +Must be a string having the name of a Xen scheduler. Check the 
>> sched=<...>
>> +boot argument for allowed values [1]. When this property is omitted, 
>> the Xen
>> +default scheduler will be used.
>> +
>> +
>> +Constraints
>> +===
>> +
>> +If no cpupools are specified, all cpus will be assigned to one cpupool
>> +implicitly created (Pool-0).
>> +
>> +If cpupools node are specified, but not every cpu brought up by Xen is 
>> assigned,
>> +all the not assigned cpu will be assigned to an additional cpupool.
>> +
>> +If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen 
>> will
>> +stop.
>> +
>> +The boot cpu must be assigned to Pool-0, so the cpupool containing that core
>> +will become Pool-0 automatically.
>> +
>> +
>> +Examples
>> +
>> +
>> +A system having two types of core, the following device tree specification 
>> will
>> +instruct Xen to have two cpupools:
>> +
>> +- The cpupool with id 0 will have 4 cpus assigned.
>> +- The cpupool with id 1 will have 2 cpus assigned.
> 
> AFAIK, there are no guarantee that Xen will parse cpupool_a first. So it 
> would be possible that the ID are inverted here.
> 
> This could happen if you want to keep the boot CPU in pool 0 and it is not 
> cpu@0 (some bootloaders allows you to change the boot CPU).

Hi Julien,

Yes I will specify that the boot cpu is listed in cpupool_a, so that cpupool 
will have id 0 regardless of the parsing order.

> 
> Also, here you write "The cpupool with id X" but ...
> 
>> +A system having the cpupools specification below will instruct Xen to have 
>> three
>> +cpupools:
>> +
>> +- The cpupool Pool-0 will have 2 cpus assigned.
>> +- The cpupool Pool-1 will have 2 cpus assigned.
>> +- The cpupool Pool-2 will have 2 cpus assigned (created by Xen with all the 
>> not
>> +  assigned cpus a53_3 and a53_4).
> 
> here you write "The cpupool Pool-X". Can you be consistent?

Sure, do you have a preference between “The cpupool with id X” and “Pool-X”? 
Otherwise I would go for Pool-X everywhere.

> 
> On a separate topic, I think dom0_max_vcpus() needs to be updated to by 
> default (i.e when opt_dom0_max_vcpus == 0) the number of vCPUs match the 
> number of vCPUs in the cpupool (I think 0) used to created dom0.

Yes right, I didn’t think about that, I think the change could be something 
like that:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9c67a483d4a4..9787104c3d31 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -73,7 +73,10 @@ custom_param("dom0_mem", parse_dom0_mem);
 unsigned int __init dom0_max_vcpus(void)
 {
 if ( opt_dom0_max_vcpus == 0 )
-opt_dom0_max_vcpus = num_online_cpus();
+{
+ASSERT(cpupool0);
+opt_dom0_max_vcpus = cpumask_weight(cpupool_valid_cpus(cpupool0));
+}
 if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
 opt_dom0_max_vcpus = MAX_VIRT_CPUS;

And if you agree I will include the changes for the v7.

Cheers,
Luca

> 
> Cheers,
> 
> -- 
> Julien Grall

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linuxce522ba9ef7e2d9fb22a39eb3371c0c64e2a433e
baseline version:
 linux8b57b3046107b50ebecb65537a172ef3d6cec673

Last test of basis   169286  2022-04-10 21:09:47 Z0 days
Testing same since   169294  2022-04-11 03:37:59 Z0 days1 attempts


People who touched revisions under test:
  Linus Torvalds 

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

[ovmf test] 169305: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  323 attempts
Testing same since   169287  2022-04-10 21:10:35 Z0 days   12 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [PATCH v6 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi Luca,

On 11/04/2022 12:30, Luca Fancellu wrote:

On 11 Apr 2022, at 11:58, Julien Grall  wrote:

Hi Luca,

On 08/04/2022 09:45, Luca Fancellu wrote:

diff --git a/docs/misc/arm/device-tree/cpupools.txt 
b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index ..40cc8135c66f
--- /dev/null
+++ b/docs/misc/arm/device-tree/cpupools.txt
@@ -0,0 +1,140 @@
+Boot time cpupools
+==
+
+When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible to
+create cpupools during boot phase by specifying them in the device tree.
+ACPI is not supported for this feature.
+
+Cpupools specification nodes shall be direct childs of /chosen node.
+Each cpupool node contains the following properties:
+
+- compatible (mandatory)
+
+Must always include the compatiblity string: "xen,cpupool".
+
+- cpupool-cpus (mandatory)
+
+Must be a list of device tree phandle to nodes describing cpus (e.g. having
+device_type = "cpu"), it can't be empty.
+
+- cpupool-sched (optional)
+
+Must be a string having the name of a Xen scheduler. Check the sched=<...>
+boot argument for allowed values [1]. When this property is omitted, the 
Xen
+default scheduler will be used.
+
+
+Constraints
+===
+
+If no cpupools are specified, all cpus will be assigned to one cpupool
+implicitly created (Pool-0).
+
+If cpupools node are specified, but not every cpu brought up by Xen is 
assigned,
+all the not assigned cpu will be assigned to an additional cpupool.
+
+If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen will
+stop.
+
+The boot cpu must be assigned to Pool-0, so the cpupool containing that core
+will become Pool-0 automatically.
+
+
+Examples
+
+
+A system having two types of core, the following device tree specification will
+instruct Xen to have two cpupools:
+
+- The cpupool with id 0 will have 4 cpus assigned.
+- The cpupool with id 1 will have 2 cpus assigned.


AFAIK, there are no guarantee that Xen will parse cpupool_a first. So it would 
be possible that the ID are inverted here.

This could happen if you want to keep the boot CPU in pool 0 and it is not 
cpu@0 (some bootloaders allows you to change the boot CPU).

Yes I will specify that the boot cpu is listed in cpupool_a, so that cpupool 
will have id 0 regardless of the parsing order.


This only covers the case where are two cpupools.

AFAIK, there are no guarantee that Xen will parse the DT or the compiler 
will generate the DT the way you want. So for three cpupools, we still 
don't know which pool will be ID 1/2.


See more below.





Also, here you write "The cpupool with id X" but ...


+A system having the cpupools specification below will instruct Xen to have 
three
+cpupools:
+
+- The cpupool Pool-0 will have 2 cpus assigned.
+- The cpupool Pool-1 will have 2 cpus assigned.
+- The cpupool Pool-2 will have 2 cpus assigned (created by Xen with all the not
+  assigned cpus a53_3 and a53_4).


here you write "The cpupool Pool-X". Can you be consistent?


Sure, do you have a preference between “The cpupool with id X” and “Pool-X”? 
Otherwise I would go for Pool-X everywhere.


Using "cpupool with ID 0" is definitely wrong. Pool-X is marginally 
better because an admin may think that this name will match what we have 
in Xen.


So I think it would be better to use the node name and mention that 
there are no guarantee in which ID will used by Xen.






On a separate topic, I think dom0_max_vcpus() needs to be updated to by default 
(i.e when opt_dom0_max_vcpus == 0) the number of vCPUs match the number of 
vCPUs in the cpupool (I think 0) used to created dom0.


Yes right, I didn’t think about that, I think the change could be something 
like that:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9c67a483d4a4..9787104c3d31 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -73,7 +73,10 @@ custom_param("dom0_mem", parse_dom0_mem);
  unsigned int __init dom0_max_vcpus(void)
  {
  if ( opt_dom0_max_vcpus == 0 )
-opt_dom0_max_vcpus = num_online_cpus();
+{
+ASSERT(cpupool0);
+opt_dom0_max_vcpus = cpumask_weight(cpupool_valid_cpus(cpupool0));
+}
  if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
  opt_dom0_max_vcpus = MAX_VIRT_CPUS;

And if you agree I will include the changes for the v7.


This should work.

Cheers,

--
Julien Grall

Re: [PATCH RFC] evtchn: add early-out to evtchn_move_pirqs()

[Jan Beulich]

On 11.04.2022 13:00, Julien Grall wrote:
> On 11/04/2022 11:45, Jan Beulich wrote:
>> On 11.04.2022 12:25, Julien Grall wrote:
>>> On 11/04/2022 07:13, Jan Beulich wrote:
 --- a/xen/common/event_channel.c
 +++ b/xen/common/event_channel.c
 @@ -1559,6 +1559,16 @@ void evtchn_move_pirqs(struct vcpu *v)
  unsigned int port;
  struct evtchn *chn;
  
 +/*
 + * The work done below is an attempt to keep pIRQ-s on the pCPU-s 
 that the
 + * vCPU-s they're to be delivered to run on. In order to limit 
 lock
 + * contention, check for an empty list prior to acquiring the 
 lock. In the
 + * worst case a pIRQ just bound to this vCPU will be delivered 
 elsewhere
 + * until the vCPU is migrated (again) to another pCPU.
 + */
>>>
>>> AFAIU, the downside is another pCPU (and therefore vCPU) will get
>>> disturbed by the interrupt.
>>
>> But only rarely, i.e. in case a race would actually have occurred.
>
> Maybe I am too paranoid here. The other side of race is controlled by a
> domain. So wouldn't it be possible to increase how often the race is hit?

 Yes, of course - just to harm itself.
>>>
>>> Are you sure? Wouldn't this also harm the next vCPU running on the pCPU
>>> because it will get interrupted more often?
>>
>> Possibly, sure. But we don't make any promises here. And recall that
>> this optimization as a whole has been put under question in the past.
> 
> I don't remember this discussion. Do you have a pointer?

I'm sorry, but no, I don't have a pointer. This may even have been on irc.
All I recall (or at least I think I do) is that it was Andrew who raised
the concern.

Jan

Re: [PATCH 24/27] block: remove QUEUE_FLAG_DISCARD

[Jan Höppner]

On 09/04/2022 06:50, Christoph Hellwig wrote:
> Just use a non-zero max_discard_sectors as an indicator for discard
> support, similar to what is done for write zeroes.
> 
> The only places where needs special attention is the RAID5 driver,
> which must clear discard support for security reasons by default,
> even if the default stacking rules would allow for it.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Martin K. Petersen 
> Acked-by: Christoph Böhmwalder  [btrfs]
> Acked-by: Coly Li  [bcache]
> ---

For 

>  drivers/s390/block/dasd_fba.c   |  1 -

Acked-by: Jan Höppner 

[ovmf test] 169306: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  324 attempts
Testing same since   169287  2022-04-10 21:10:35 Z0 days   13 attempts


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

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



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

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

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

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


Not pushing.

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

[ovmf test] 169307: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  325 attempts
Testing same since   169287  2022-04-10 21:10:35 Z0 days   14 attempts


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

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



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

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

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

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


Not pushing.

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

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

[osstest service owner]

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

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  f44201124e8713f6eff80f349351b5740001c6fc
baseline version:
 xen  8847ec08fd0eecbe3da944fdd49ca3d755e8a9bf

Last test of basis   169250  2022-04-08 20:03:24 Z2 days
Testing same since   169304  2022-04-11 11:00:27 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Henry Wang 
  Jan Beulich 
  Julien Grall 
  Michal Orzel 
  Roger Pau Monné 

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
   8847ec08fd..f44201124e  f44201124e8713f6eff80f349351b5740001c6fc -> smoke

Re: [PATCH 24/27] block: remove QUEUE_FLAG_DISCARD

[Keith Busch]

On Sat, Apr 09, 2022 at 06:50:40AM +0200, Christoph Hellwig wrote:
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index efb85c6d8e2d5..7e07dd69262a7 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1607,10 +1607,8 @@ static void nvme_config_discard(struct gendisk *disk, 
> struct nvme_ns *ns)
>   struct request_queue *queue = disk->queue;
>   u32 size = queue_logical_block_size(queue);
>  
> - if (ctrl->max_discard_sectors == 0) {
> - blk_queue_flag_clear(QUEUE_FLAG_DISCARD, queue);
> + if (ctrl->max_discard_sectors == 0)
>   return;
> - }

I think we need to update the queue limit in this condition. While unlikley,
the flag was cleared here in case the device changed support for discard from
the previous reset. 

[ovmf test] 169308: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  326 attempts
Testing same since   169287  2022-04-10 21:10:35 Z0 days   15 attempts


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

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



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

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

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

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


Not pushing.

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

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

[Dario Faggioli]

On Fri, 2022-04-08 at 11:20 +, Dario Faggioli wrote:
> On Thu, 2022-04-07 at 15:27 +0200, Jan Beulich wrote:
> > 
> > Credit2 moving the vCPU-s off of their initially assigned ones
> > right
> > away of course renders sched_select_initial_cpu()'s use of
> > cpu_cycle()
> > pretty useless.
> > 
> Mmm... you mean that Credit2 is moving the vCPUs off they're assigned
> ones _right_now_, or that it will, with this patch?
> 
> If you mean the former, I'm not sure it is. In fact, when
> sched_select_initial_cpu() is called for dom0, dom0's node affinity
> is
> just all nodes, isn't it? 
>
Actually, it's what results from dom0_nodes. I was forgetting that we
set d->node_affinity while parsing the parameter.

That said, I've added some logging, to better understand what is going
on, and there are some not obvious (at least, not to me) things that
are happening, and it seems that what is causing problems is the call
to sched_insert_unit(), within sched_init_vcpu().

I have to leave now, but I will report what I've found ASAP (probably
tomorrow, though).

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


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

POLL: Would you attend a Xen Summit in Cambridge UK in September?

[George Dunlap]

Hello all,

EXECUTIVE SUMMARY

The current form of the Xen Summit this year we’re considering is as follows:

1. Two days of “primarily virtual” talks, with a physical add-on for those in 
the Cambridge UK area, or willing to fly there.  This would be relatively 
low-key, probably hosted on a company premesis; listening to the talks in some 
conference rooms, with catered food / coffee provided, and pub / meal sessions 
in the evening.

2. Two days of “primarily physical” discussion sessions, at the same location.

To help with location planning, please fill out the following survey:

https://cryptpad.fr/form/#/2/form/view/93hTkvOnhFQhmzydZ4fONMTr8AABMPAEEou-SIS1hww/

BACKGROUND

We had initially planned to have a “primarily physical summit with a virtual 
add-on”, similar to the summits we’ve had in the past, in Romania this year.  
We have decided to do something else this year for a number of reasons:

1. Difficulties in scheduling with the originally intended venue

2. A war going on in the neighboring country

3. One of the important contributor companies (based in Cambridge) unlikely to 
be able to send anyone outside the country this year.

My original idea was to flip from “primarily physical with a virtual add-on” to 
“primarily virtual with a physical add-on”: have the talks primarily on Big 
Blue Button as with the last two years, but have some locations where people 
could watch the talks together in some conference rooms, and have evening pub 
sessions / meals for those on-site. This would allow people living within 
driving distance of Cambridge — and anyone willing to come to Cambridge for a 
few days — to get the face-to-face interaction which is so helpful for a 
project like ours, while not requiring us to find and pay for a full-blown 
conference venue.

At the last community call, however, it was pointed out that the design 
sessions are significantly reduced in effectiveness when they aren’t being done 
in person with a whiteboard.  Hence the proposal to make the design sessions 
primarily physical, and somewhat separate from the virtual part of the summit.

It’s still a work in progress; feedback is welcome.  But your response 
regarding the probability that you’ll be able to participate will help us plan.

Thanks,
 -George Dunlap


signature.asc
Description: Message signed with OpenPGP

[PATCH v7 0/7] Boot time cpupools

[Luca Fancellu]

This serie introduces a feature for Xen to create cpu pools at boot time, the
feature is enabled using a configurable that is disabled by default.
The boot time cpupool feature relies on the device tree to describe the cpu
pools.
Another feature is introduced by the serie, the possibility to assign a
dom0less guest to a cpupool at boot time.

Here follows an example, Xen is built with CONFIG_BOOT_TIME_CPUPOOLS=y.

>From the DT:

  [...]

  a72_0: cpu@0 {
compatible = "arm,cortex-a72";
reg = <0x0 0x0>;
device_type = "cpu";
[...]
  };

  a72_1: cpu@1 {
compatible = "arm,cortex-a72";
reg = <0x0 0x1>;
device_type = "cpu";
[...]
  };

  a53_0: cpu@100 {
compatible = "arm,cortex-a53";
reg = <0x0 0x100>;
device_type = "cpu";
[...]
  };

  a53_1: cpu@101 {
compatible = "arm,cortex-a53";
reg = <0x0 0x101>;
device_type = "cpu";
[...]
  };

  a53_2: cpu@102 {
compatible = "arm,cortex-a53";
reg = <0x0 0x102>;
device_type = "cpu";
[...]
  };

  a53_3: cpu@103 {
compatible = "arm,cortex-a53";
reg = <0x0 0x103>;
device_type = "cpu";
[...]
  };

  chosen {
#size-cells = <0x1>;
#address-cells = <0x1>;
xen,dom0-bootargs = "...";
xen,xen-bootargs = "...";

cpupool0 {
  compatible = "xen,cpupool";
  cpupool-cpus = <&a72_0 &a72_1>;
  cpupool-sched = "credit2";
};

cp1: cpupool1 {
  compatible = "xen,cpupool";
  cpupool-cpus = <&a53_0 &a53_1 &a53_2 &a53_3>;
  cpupool-sched = "null";
};

module@0 {
  reg = <0x8008 0x130>;
  compatible = "multiboot,module";
};

domU1 {
  #size-cells = <0x1>;
  #address-cells = <0x1>;
  compatible = "xen,domain";
  cpus = <1>;
  memory = <0 0xC>;
  vpl011;
  domain-cpupool = <&cp1>;

  module@9200 {
compatible = "multiboot,kernel", "multiboot,module";
reg = <0x9200 0x1ff>;
bootargs = "...";
  };
};
  };

  [...]

The example DT is instructing Xen to have two cpu pools, one having two phisical
cpus and the one having 4 phisical cpus, the last mentioned cpu pool uses the
null scheduler and from the /chosen node we can see that a dom0less guest will
be started on that cpu pool.

In this particular case Xen must boot with different type of cpus, so the
boot argument hmp_unsafe must be enabled.

Luca Fancellu (7):
  tools/cpupools: Give a name to unnamed cpupools
  xen/sched: create public function for cpupools creation
  xen/sched: retrieve scheduler id by name
  xen/cpupool: Create different cpupools at boot time
  xen/cpupool: Don't allow removing cpu0 from cpupool0
  arm/dom0less: assign dom0less guests to cpupools
  xen/cpupool: Allow cpupool0 to use different scheduler

 MAINTAINERS|   2 +-
 docs/misc/arm/device-tree/booting.txt  |   5 +
 docs/misc/arm/device-tree/cpupools.txt | 140 +++
 tools/helpers/xen-init-dom0.c  |  37 +++-
 tools/libs/light/libxl_utils.c |   3 +-
 xen/arch/arm/domain_build.c|  19 +-
 xen/arch/arm/include/asm/smp.h |   3 +
 xen/common/Kconfig |   7 +
 xen/common/domain.c|   2 +-
 xen/common/sched/Makefile  |   1 +
 xen/common/sched/boot-cpupool.c| 234 +
 xen/common/sched/core.c|  40 +++--
 xen/common/sched/cpupool.c |  43 -
 xen/include/public/domctl.h|   5 +-
 xen/include/xen/sched.h|  53 ++
 15 files changed, 563 insertions(+), 31 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/cpupools.txt
 create mode 100644 xen/common/sched/boot-cpupool.c

-- 
2.17.1

[PATCH v7 2/7] xen/sched: create public function for cpupools creation

[Luca Fancellu]

Create new public function to create cpupools, can take as parameter
the scheduler id or a negative value that means the default Xen
scheduler will be used.

Signed-off-by: Luca Fancellu 
Reviewed-by: Juergen Gross 
---
Changes in v7:
- no changes
Changes in v6:
- add R-by
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- Fixed comment (Andrew)
Changes in v2:
- cpupool_create_pool doesn't check anymore for pool id uniqueness
  before calling cpupool_create. Modified commit message accordingly
---
 xen/common/sched/cpupool.c | 15 +++
 xen/include/xen/sched.h| 16 
 2 files changed, 31 insertions(+)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index a6da4970506a..89a891af7076 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -1219,6 +1219,21 @@ static void cpupool_hypfs_init(void)
 
 #endif /* CONFIG_HYPFS */
 
+struct cpupool *__init cpupool_create_pool(unsigned int pool_id, int sched_id)
+{
+struct cpupool *pool;
+
+if ( sched_id < 0 )
+sched_id = scheduler_get_default()->sched_id;
+
+pool = cpupool_create(pool_id, sched_id);
+
+BUG_ON(IS_ERR(pool));
+cpupool_put(pool);
+
+return pool;
+}
+
 static int __init cf_check cpupool_init(void)
 {
 unsigned int cpu;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index ed8539f6d297..0164db996b8b 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1153,6 +1153,22 @@ int cpupool_move_domain(struct domain *d, struct cpupool 
*c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 unsigned int cpupool_get_id(const struct domain *d);
 const cpumask_t *cpupool_valid_cpus(const struct cpupool *pool);
+
+/*
+ * cpupool_create_pool - Creates a cpupool
+ * @pool_id: id of the pool to be created
+ * @sched_id: id of the scheduler to be used for the pool
+ *
+ * Creates a cpupool with pool_id id.
+ * The sched_id parameter identifies the scheduler to be used, if it is
+ * negative, the default scheduler of Xen will be used.
+ *
+ * returns:
+ * pointer to the struct cpupool just created, or Xen will panic in case of
+ * error
+ */
+struct cpupool *cpupool_create_pool(unsigned int pool_id, int sched_id);
+
 extern void cf_check dump_runq(unsigned char key);
 
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
-- 
2.17.1

[PATCH v7 5/7] xen/cpupool: Don't allow removing cpu0 from cpupool0

[Luca Fancellu]

Cpu0 must remain in cpupool0, otherwise some operations like moving cpus
between cpupools, cpu hotplug, destroying cpupools, shutdown of the host,
might not work in a sane way.

Signed-off-by: Luca Fancellu 
---
Changes in v7:
- new patch
---
 xen/common/sched/cpupool.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 86a175f99cd5..0a93bcc631bf 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -572,6 +572,7 @@ static long cf_check cpupool_unassign_cpu_helper(void *info)
  * possible failures:
  * - last cpu and still active domains in cpupool
  * - cpu just being unplugged
+ * - Attempt to remove boot cpu from cpupool0
  */
 static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
 {
@@ -582,7 +583,12 @@ static int cpupool_unassign_cpu(struct cpupool *c, 
unsigned int cpu)
 debugtrace_printk("cpupool_unassign_cpu(pool=%u,cpu=%d)\n",
   c->cpupool_id, cpu);
 
-if ( !cpu_online(cpu) )
+/*
+ * Cpu0 must remain in cpupool0, otherwise some operations like moving cpus
+ * between cpupools, cpu hotplug, destroying cpupools, shutdown of the 
host,
+ * might not work in a sane way.
+ */
+if ( (!c->cpupool_id && !cpu) || !cpu_online(cpu) )
 return -EINVAL;
 
 master_cpu = sched_get_resource_cpu(cpu);
-- 
2.17.1

[PATCH v7 6/7] arm/dom0less: assign dom0less guests to cpupools

[Luca Fancellu]

Introduce domain-cpupool property of a xen,domain device tree node,
that specifies the cpupool device tree handle of a xen,cpupool node
that identifies a cpupool created at boot time where the guest will
be assigned on creation.

Add member to the xen_domctl_createdomain public interface so the
XEN_DOMCTL_INTERFACE_VERSION version is bumped.

Add public function to retrieve a pool id from the device tree
cpupool node.

Update documentation about the property.

Signed-off-by: Luca Fancellu 
Reviewed-by: Stefano Stabellini 
---
Changes in v7:
- Add comment for cpupool_id struct member. (Jan)
Changes in v6:
- no changes
Changes in v5:
- no changes
Changes in v4:
- no changes
- add R-by
Changes in v3:
- Use explicitely sized integer for struct xen_domctl_createdomain
  cpupool_id member. (Stefano)
- Changed code due to previous commit code changes
Changes in v2:
- Moved cpupool_id from arch specific to common part (Juergen)
- Implemented functions to retrieve the cpupool id from the
  cpupool dtb node.
---
 docs/misc/arm/device-tree/booting.txt |  5 +
 xen/arch/arm/domain_build.c   | 14 +-
 xen/common/domain.c   |  2 +-
 xen/common/sched/boot-cpupool.c   | 24 
 xen/include/public/domctl.h   |  5 -
 xen/include/xen/sched.h   |  9 +
 6 files changed, 56 insertions(+), 3 deletions(-)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index a94125394e35..7b4a29a2c293 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -188,6 +188,11 @@ with the following properties:
 An empty property to request the memory of the domain to be
 direct-map (guest physical address == physical address).
 
+- domain-cpupool
+
+Optional. Handle to a xen,cpupool device tree node that identifies the
+cpupool where the guest will be started at boot.
+
 Under the "xen,domain" compatible node, one or more sub-nodes are present
 for the DomU kernel and ramdisk.
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9aa6ae27c40f..9787104c3d31 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3175,7 +3175,8 @@ static int __init construct_domU(struct domain *d,
 void __init create_domUs(void)
 {
 struct dt_device_node *node;
-const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+const struct dt_device_node *cpupool_node,
+*chosen = dt_find_node_by_path("/chosen");
 
 BUG_ON(chosen == NULL);
 dt_for_each_child_node(chosen, node)
@@ -3244,6 +3245,17 @@ void __init create_domUs(void)
  vpl011_virq - 32 + 1);
 }
 
+/* Get the optional property domain-cpupool */
+cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
+if ( cpupool_node )
+{
+int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
+if ( pool_id < 0 )
+panic("Error getting cpupool id from domain-cpupool (%d)\n",
+  pool_id);
+d_cfg.cpupool_id = pool_id;
+}
+
 /*
  * The variable max_init_domid is initialized with zero, so here it's
  * very important to use the pre-increment operator to call
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 351029f8b239..0827400f4f49 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -698,7 +698,7 @@ struct domain *domain_create(domid_t domid,
 if ( !d->pbuf )
 goto fail;
 
-if ( (err = sched_init_domain(d, 0)) != 0 )
+if ( (err = sched_init_domain(d, config->cpupool_id)) != 0 )
 goto fail;
 
 if ( (err = late_hwdom_init(d)) != 0 )
diff --git a/xen/common/sched/boot-cpupool.c b/xen/common/sched/boot-cpupool.c
index 9429a5025fc4..240bae4cebb8 100644
--- a/xen/common/sched/boot-cpupool.c
+++ b/xen/common/sched/boot-cpupool.c
@@ -22,6 +22,8 @@ static unsigned int __initdata next_pool_id;
 
 #define BTCPUPOOLS_DT_NODE_NO_REG (-1)
 #define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
+#define BTCPUPOOLS_DT_WRONG_NODE  (-3)
+#define BTCPUPOOLS_DT_CORRUPTED_NODE  (-4)
 
 static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
 {
@@ -56,6 +58,28 @@ get_logical_cpu_from_cpu_node(const struct dt_device_node 
*cpu_node)
 return cpu_num;
 }
 
+int __init btcpupools_get_domain_pool_id(const struct dt_device_node *node)
+{
+const struct dt_device_node *phandle_node;
+int cpu_num;
+
+if ( !dt_device_is_compatible(node, "xen,cpupool") )
+return BTCPUPOOLS_DT_WRONG_NODE;
+/*
+ * Get first cpu listed in the cpupool, from its reg it's possible to
+ * retrieve the cpupool id.
+ */
+phandle_node = dt_parse_phandle(node, "cpupool-cpus", 0);
+if ( !phandle_node )
+return BTCPUPOOLS_DT_CORRUPTED_NODE;
+
+cpu_num = get_logical

[PATCH v7 1/7] tools/cpupools: Give a name to unnamed cpupools

[Luca Fancellu]

With the introduction of boot time cpupools, Xen can create many
different cpupools at boot time other than cpupool with id 0.

Since these newly created cpupools can't have an
entry in Xenstore, create the entry using xen-init-dom0
helper with the usual convention: Pool-.

Given the change, remove the check for poolid == 0 from
libxl_cpupoolid_to_name(...).

Signed-off-by: Luca Fancellu 
Reviewed-by: Anthony PERARD 
---
Changes in v7:
- Add R-by from Anthony
Changes in v6:
- Reworked loop to have only one error path (Anthony)
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- no changes, add R-by
Changes in v2:
 - Remove unused variable, moved xc_cpupool_infofree
   ahead to simplify the code, use asprintf (Juergen)
---
 tools/helpers/xen-init-dom0.c  | 37 +-
 tools/libs/light/libxl_utils.c |  3 +--
 2 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/tools/helpers/xen-init-dom0.c b/tools/helpers/xen-init-dom0.c
index c99224a4b607..37eff8868f25 100644
--- a/tools/helpers/xen-init-dom0.c
+++ b/tools/helpers/xen-init-dom0.c
@@ -43,7 +43,10 @@ int main(int argc, char **argv)
 int rc;
 struct xs_handle *xsh = NULL;
 xc_interface *xch = NULL;
-char *domname_string = NULL, *domid_string = NULL;
+char *domname_string = NULL, *domid_string = NULL,
+ *pool_path = NULL, *pool_name = NULL;
+xc_cpupoolinfo_t *xcinfo;
+unsigned int pool_id = 0;
 libxl_uuid uuid;
 
 /* Accept 0 or 1 argument */
@@ -114,9 +117,41 @@ int main(int argc, char **argv)
 goto out;
 }
 
+/* Create an entry in xenstore for each cpupool on the system */
+do {
+xcinfo = xc_cpupool_getinfo(xch, pool_id);
+if (xcinfo != NULL) {
+if (xcinfo->cpupool_id != pool_id)
+pool_id = xcinfo->cpupool_id;
+xc_cpupool_infofree(xch, xcinfo);
+if (asprintf(&pool_path, "/local/pool/%d/name", pool_id) <= 0) {
+fprintf(stderr, "cannot allocate memory for pool path\n");
+rc = 1;
+goto out;
+}
+if (asprintf(&pool_name, "Pool-%d", pool_id) <= 0) {
+fprintf(stderr, "cannot allocate memory for pool name\n");
+rc = 1;
+goto out;
+}
+pool_id++;
+if (!xs_write(xsh, XBT_NULL, pool_path, pool_name,
+  strlen(pool_name))) {
+fprintf(stderr, "cannot set pool name\n");
+rc = 1;
+goto out;
+}
+free(pool_name);
+free(pool_path);
+pool_path = pool_name = NULL;
+}
+} while(xcinfo != NULL);
+
 printf("Done setting up Dom0\n");
 
 out:
+free(pool_path);
+free(pool_name);
 free(domid_string);
 free(domname_string);
 xs_close(xsh);
diff --git a/tools/libs/light/libxl_utils.c b/tools/libs/light/libxl_utils.c
index b91c2cafa223..81780da3ff40 100644
--- a/tools/libs/light/libxl_utils.c
+++ b/tools/libs/light/libxl_utils.c
@@ -151,8 +151,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t 
poolid)
 
 snprintf(path, sizeof(path), "/local/pool/%d/name", poolid);
 s = xs_read(ctx->xsh, XBT_NULL, path, &len);
-if (!s && (poolid == 0))
-return strdup("Pool-0");
+
 return s;
 }
 
-- 
2.17.1

[PATCH v7 3/7] xen/sched: retrieve scheduler id by name

[Luca Fancellu]

Add a static function to retrieve the scheduler pointer using the
scheduler name.

Add a public function to retrieve the scheduler id by the scheduler
name that makes use of the new static function.

Take the occasion to replace open coded scheduler search with the
new static function in scheduler_init.

Signed-off-by: Luca Fancellu 
Reviewed-by: Juergen Gross 
Reviewed-by: Dario Faggioli 
---
Changes in v7:
- Add R-by (Dario)
Changes in v6:
- no changes
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- add R-by
Changes in v2:
- replace open coded scheduler search in scheduler_init (Juergen)
---
 xen/common/sched/core.c | 40 ++--
 xen/include/xen/sched.h | 11 +++
 2 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 19ab67818106..48ee01420fb8 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2947,10 +2947,30 @@ void scheduler_enable(void)
 scheduler_active = true;
 }
 
+static inline
+const struct scheduler *__init sched_get_by_name(const char *sched_name)
+{
+unsigned int i;
+
+for ( i = 0; i < NUM_SCHEDULERS; i++ )
+if ( schedulers[i] && !strcmp(schedulers[i]->opt_name, sched_name) )
+return schedulers[i];
+
+return NULL;
+}
+
+int __init sched_get_id_by_name(const char *sched_name)
+{
+const struct scheduler *scheduler = sched_get_by_name(sched_name);
+
+return scheduler ? scheduler->sched_id : -1;
+}
+
 /* Initialise the data structures. */
 void __init scheduler_init(void)
 {
 struct domain *idle_domain;
+const struct scheduler *scheduler;
 int i;
 
 scheduler_enable();
@@ -2981,25 +3001,17 @@ void __init scheduler_init(void)
schedulers[i]->opt_name);
 schedulers[i] = NULL;
 }
-
-if ( schedulers[i] && !ops.name &&
- !strcmp(schedulers[i]->opt_name, opt_sched) )
-ops = *schedulers[i];
 }
 
-if ( !ops.name )
+scheduler = sched_get_by_name(opt_sched);
+if ( !scheduler )
 {
 printk("Could not find scheduler: %s\n", opt_sched);
-for ( i = 0; i < NUM_SCHEDULERS; i++ )
-if ( schedulers[i] &&
- !strcmp(schedulers[i]->opt_name, CONFIG_SCHED_DEFAULT) )
-{
-ops = *schedulers[i];
-break;
-}
-BUG_ON(!ops.name);
-printk("Using '%s' (%s)\n", ops.name, ops.opt_name);
+scheduler = sched_get_by_name(CONFIG_SCHED_DEFAULT);
+BUG_ON(!scheduler);
+printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
 }
+ops = *scheduler;
 
 if ( cpu_schedule_up(0) )
 BUG();
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 0164db996b8b..4442a1940c25 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -764,6 +764,17 @@ void sched_destroy_domain(struct domain *d);
 long sched_adjust(struct domain *, struct xen_domctl_scheduler_op *);
 long sched_adjust_global(struct xen_sysctl_scheduler_op *);
 int  sched_id(void);
+
+/*
+ * sched_get_id_by_name - retrieves a scheduler id given a scheduler name
+ * @sched_name: scheduler name as a string
+ *
+ * returns:
+ * positive value being the scheduler id, on success
+ * negative value if the scheduler name is not found.
+ */
+int sched_get_id_by_name(const char *sched_name);
+
 void vcpu_wake(struct vcpu *v);
 long vcpu_yield(void);
 void vcpu_sleep_nosync(struct vcpu *v);
-- 
2.17.1

[PATCH v7 4/7] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

Introduce a way to create different cpupools at boot time, this is
particularly useful on ARM big.LITTLE system where there might be the
need to have different cpupools for each type of core, but also
systems using NUMA can have different cpu pools for each node.

The feature on arm relies on a specification of the cpupools from the
device tree to build pools and assign cpus to them.

ACPI is not supported for this feature.

With this patch, cpupool0 can now have less cpus than the number of
online ones, so update the default case for opt_dom0_max_vcpus.

Documentation is created to explain the feature.

Signed-off-by: Luca Fancellu 
---
Changes in v7:
- rename xen/common/boot_cpupools.c to xen/common/sched/boot-cpupool.c (Jan)
- reverted xen/common/Makefile, add entry in xen/common/sched/Makefile
- changed line in MAINTAINERS under CPU POOLS section (Dario)
- Fix documentation, update opt_dom0_max_vcpus to the number of cpu in
  cpupool0 (Julien)
Changes in v6:
- Changed docs, return if booted with ACPI in btcpupools_dtb_parse,
  panic if /chosen does not exists. Changed commit message (Julien)
- Add Juergen R-by for the xen/common/sched part that didn't change
Changes in v5:
- Fixed wrong variable name, swapped schedulers, add scheduler info
  in the printk (Stefano)
- introduce assert in cpupool_init and btcpupools_get_cpupool_id to
  harden the code
Changes in v4:
- modify Makefile to put in *.init.o, fixed stubs and macro (Jan)
- fixed docs, fix brakets (Stefano)
- keep cpu0 in Pool-0 (Julien)
- moved printk from btcpupools_allocate_pools to
  btcpupools_get_cpupool_id
- Add to docs constraint about cpu0 and Pool-0
Changes in v3:
- Add newline to cpupools.txt and removed "default n" from Kconfig (Jan)
- Fixed comment, moved defines, used global cpu_online_map, use
  HAS_DEVICE_TREE instead of ARM and place arch specific code in header
  (Juergen)
- Fix brakets, x86 code only panic, get rid of scheduler dt node, don't
  save pool pointer and look for it from the pool list (Stefano)
- Changed data structures to allow modification to the code.
Changes in v2:
- Move feature to common code (Juergen)
- Try to decouple dtb parse and cpupool creation to allow
  more way to specify cpupools (for example command line)
- Created standalone dt node for the scheduler so it can
  be used in future work to set scheduler specific
  parameters
- Use only auto generated ids for cpupools
---
 MAINTAINERS|   2 +-
 docs/misc/arm/device-tree/cpupools.txt | 140 +
 xen/arch/arm/domain_build.c|   5 +-
 xen/arch/arm/include/asm/smp.h |   3 +
 xen/common/Kconfig |   7 +
 xen/common/sched/Makefile  |   1 +
 xen/common/sched/boot-cpupool.c| 207 +
 xen/common/sched/cpupool.c |  12 +-
 xen/include/xen/sched.h|  14 ++
 9 files changed, 388 insertions(+), 3 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/cpupools.txt
 create mode 100644 xen/common/sched/boot-cpupool.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 6a097b43eb9a..7963c9232c07 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -274,7 +274,7 @@ CPU POOLS
 M: Juergen Gross 
 M: Dario Faggioli 
 S: Supported
-F: xen/common/sched/cpupool.c
+F: xen/common/sched/*cpupool.c
 
 DEVICE TREE
 M: Stefano Stabellini 
diff --git a/docs/misc/arm/device-tree/cpupools.txt 
b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index ..1f640d680317
--- /dev/null
+++ b/docs/misc/arm/device-tree/cpupools.txt
@@ -0,0 +1,140 @@
+Boot time cpupools
+==
+
+When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible to
+create cpupools during boot phase by specifying them in the device tree.
+ACPI is not supported for this feature.
+
+Cpupools specification nodes shall be direct childs of /chosen node.
+Each cpupool node contains the following properties:
+
+- compatible (mandatory)
+
+Must always include the compatiblity string: "xen,cpupool".
+
+- cpupool-cpus (mandatory)
+
+Must be a list of device tree phandle to nodes describing cpus (e.g. having
+device_type = "cpu"), it can't be empty.
+
+- cpupool-sched (optional)
+
+Must be a string having the name of a Xen scheduler. Check the sched=<...>
+boot argument for allowed values [1]. When this property is omitted, the 
Xen
+default scheduler will be used.
+
+
+Constraints
+===
+
+If no cpupools are specified, all cpus will be assigned to one cpupool
+implicitly created (Pool-0).
+
+If cpupools node are specified, but not every cpu brought up by Xen is 
assigned,
+all the not assigned cpu will be assigned to an additional cpupool.
+
+If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen will
+stop.
+
+The boot cpu must be assigned to Pool-0, so the cpupool containing that core
+will become Pool-0 automatically.
+
+
+Examples
+
+
+A system having two t

[PATCH v7 7/7] xen/cpupool: Allow cpupool0 to use different scheduler

[Luca Fancellu]

Currently cpupool0 can use only the default scheduler, and
cpupool_create has an hardcoded behavior when creating the pool 0
that doesn't allocate new memory for the scheduler, but uses the
default scheduler structure in memory.

With this commit it is possible to allocate a different scheduler for
the cpupool0 when using the boot time cpupool.
To achieve this the hardcoded behavior in cpupool_create is removed
and the cpupool0 creation is moved.

When compiling without boot time cpupools enabled, the current
behavior is maintained (except that cpupool0 scheduler memory will be
allocated).

Signed-off-by: Luca Fancellu 
Reviewed-by: Juergen Gross 
---
Changes in v7:
- no changes
Changes in v6:
- Add R-by
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- fix typo in commit message (Juergen)
- rebase changes
Changes in v2:
- new patch
---
 xen/common/sched/boot-cpupool.c | 5 -
 xen/common/sched/cpupool.c  | 8 +---
 xen/include/xen/sched.h | 5 -
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/sched/boot-cpupool.c b/xen/common/sched/boot-cpupool.c
index 240bae4cebb8..5955e6f9a98b 100644
--- a/xen/common/sched/boot-cpupool.c
+++ b/xen/common/sched/boot-cpupool.c
@@ -205,8 +205,11 @@ void __init btcpupools_allocate_pools(void)
 if ( add_extra_cpupool )
 next_pool_id++;
 
+/* Keep track of cpupool id 0 with the global cpupool0 */
+cpupool0 = cpupool_create_pool(0, pool_sched_map[0]);
+
 /* Create cpupools with selected schedulers */
-for ( i = 0; i < next_pool_id; i++ )
+for ( i = 1; i < next_pool_id; i++ )
 cpupool_create_pool(i, pool_sched_map[i]);
 }
 
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 0a93bcc631bf..f6e3d97e5288 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -312,10 +312,7 @@ static struct cpupool *cpupool_create(unsigned int poolid,
 c->cpupool_id = q->cpupool_id + 1;
 }
 
-if ( poolid == 0 )
-c->sched = scheduler_get_default();
-else
-c->sched = scheduler_alloc(sched_id);
+c->sched = scheduler_alloc(sched_id);
 if ( IS_ERR(c->sched) )
 {
 ret = PTR_ERR(c->sched);
@@ -1248,9 +1245,6 @@ static int __init cf_check cpupool_init(void)
 
 cpupool_hypfs_init();
 
-cpupool0 = cpupool_create(0, 0);
-BUG_ON(IS_ERR(cpupool0));
-cpupool_put(cpupool0);
 register_cpu_notifier(&cpu_nfb);
 
 btcpupools_dtb_parse();
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 32d2a6294b6d..6040fa3b3830 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1191,7 +1191,10 @@ void btcpupools_dtb_parse(void);
 int btcpupools_get_domain_pool_id(const struct dt_device_node *node);
 
 #else /* !CONFIG_BOOT_TIME_CPUPOOLS */
-static inline void btcpupools_allocate_pools(void) {}
+static inline void btcpupools_allocate_pools(void)
+{
+cpupool0 = cpupool_create_pool(0, -1);
+}
 static inline void btcpupools_dtb_parse(void) {}
 static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
 {
-- 
2.17.1

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

[Rahul Singh]

Hi Stefano,

Thanks for reviewing the design.

> On 9 Apr 2022, at 2:00 am, Stefano Stabellini  wrote:
> 
> On Wed, 23 Mar 2022, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less system.
>> 
>> Signed-off-by: Rahul Singh 
>> ---
>> docs/designs/dom0less-evtchn.md | 96 +
>> 1 file changed, 96 insertions(+)
>> create mode 100644 docs/designs/dom0less-evtchn.md
>> 
>> diff --git a/docs/designs/dom0less-evtchn.md 
>> b/docs/designs/dom0less-evtchn.md
>> new file mode 100644
>> index 00..6a1b7e8c22
>> --- /dev/null
>> +++ b/docs/designs/dom0less-evtchn.md
>> @@ -0,0 +1,96 @@
>> +# Signaling support between two domUs on dom0less system
>> +
>> +## Current state: Draft version
>> +
>> +## Proposer(s): Rahul Singh, Bertrand Marquis
>> +
>> +## Problem Statement:
>> +
>> +The goal of this work is to define a simple signaling system between Xen 
>> guests
>> +in dom0less systems.
>> +
>> +In dom0less system, we cannot make use of xenbus and xenstore that are used 
>> in
>> +normal systems with dynamic VMs to communicate between domains by providing 
>> a
>> +bus abstraction for paravirtualized drivers.
>> +
>> +One possible solution to implement the signaling system between domUs is 
>> based
>> +on event channels.
> 
> I suggest to reword this as follows:
> 
> ---
> Dom0less guests would benefit from a statically-defined memory sharing
> and signally system for communication. One that would be immediately
> available at boot without any need for dynamic configurations.
> 
> In embedded a great variety of guest operating system kernels exist,
> many of which don't have support for xenstore, grant table or other
> complex drivers. Some of them are small kernel-space applications (often
> called "baremetal", not to be confused with the term "baremetal" used in
> datacenter which means "without hypervisors") or RTOSes. Additionally,
> for safety reasons, users often need to be able to configure the full
> system statically so that it can be verified statically.
> 
> Event channels are very simple and can be added even to baremetal
> applications. This proposal introduces a way to define them statically
> to make them suitable to dom0less embedded deployments.
> ---
> 

Ok. This is really a good explanation I will add this in next version.
> 
>> +## Proposal:
>> +
>> +Event channels are the basic primitive provided by Xen for event 
>> notifications.
>> +An event channel is a logical connection between 2 domains (more 
>> specifically
>> +between dom1,port1 and dom2,port2). They essentially store one bit of
>> +information, the event of interest is signalled by transitioning this bit 
>> from
>> +0 to 1. An event is an equivalent of a hardware interrupt.
>> +
>> +Notifications are received by a guest via an interrupt from Xen to the 
>> guest,
>> +indicating when an event arrives (setting the bit). Further notifications 
>> are
>> +masked until the bit is cleared again. When a domain wants to wait for data 
>> it
>> +will block until an event arrives, and then send an event to signal that 
>> data
>> +has been consumed. Events are delivered asynchronously to guests and are
>> +enqueued when the guest is not running.
>> +
>> +Event channel communication will be established statically between two domU
>> +guests before unpausing the domains after domain creation. Event channel
>> +connection information between domUs will be passed to XEN via device tree
>> +node.
>> +
>> +Under the /chosen node, there needs to be sub nodes with compatible
>> +"xen,evtchn" that descibes the event channel connection between two domUs.
>> +
>> +The event channel sub-node has the following properties:
>> +
>> +- compatible
>> +
>> + "xen,evtchn"
>> +
>> +- xen,evtchn
>> +
>> + The property is four numbers of tuples of
>> + (local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:
>> +
>> + local-port-domU1 is an integer value that will be used to allocte local
>> + port for domU1 to send an event notification to the remote domain.
>> +
>> + domU1-phandle is a single phandle to an domain to which local-port-domU1
>> + will be allocated.
>> +
>> + local-port-domU2 is an integer value that will be used to allocte local
>> + port for domU2 to send an event notification to the remote domain.
>> +
>> + domU2-phandle is a single phandle to an domain to which local-port-domU2
>> + will be allocated.
>> +
>> +Example:
>> +
>> + chosen {
>> + 
>> +
>> + domU1: domU1 {
>> + ..
>> + };
>> +
>> + domU2: domU2 {
>> + ..
>> + };
>> +
>> + evtchn@1 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xa &domU1 0xb &domU2>;
>> + };
>> +
>> + evtchn@2 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xc &domU1 0xd &domU2>;
>> + };
>> + };
> 
> There is no need to use two evtchn nodes for this given that in device
> tree it is entirely normal to have multiple tuplets in a property. Also,
> it would be good

[ovmf test] 169310: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  327 attempts
Testing same since   169287  2022-04-10 21:10:35 Z0 days   16 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [PATCH v7 4/7] xen/cpupool: Create different cpupools at boot time

[Jan Beulich]

On 11.04.2022 17:20, Luca Fancellu wrote:
> Introduce a way to create different cpupools at boot time, this is
> particularly useful on ARM big.LITTLE system where there might be the
> need to have different cpupools for each type of core, but also
> systems using NUMA can have different cpu pools for each node.
> 
> The feature on arm relies on a specification of the cpupools from the
> device tree to build pools and assign cpus to them.
> 
> ACPI is not supported for this feature.
> 
> With this patch, cpupool0 can now have less cpus than the number of
> online ones, so update the default case for opt_dom0_max_vcpus.
> 
> Documentation is created to explain the feature.
> 
> Signed-off-by: Luca Fancellu 
> ---
> Changes in v7:
> - rename xen/common/boot_cpupools.c to xen/common/sched/boot-cpupool.c (Jan)
> - reverted xen/common/Makefile, add entry in xen/common/sched/Makefile
> - changed line in MAINTAINERS under CPU POOLS section (Dario)
> - Fix documentation, update opt_dom0_max_vcpus to the number of cpu in
>   cpupool0 (Julien)
> Changes in v6:
> - Changed docs, return if booted with ACPI in btcpupools_dtb_parse,
>   panic if /chosen does not exists. Changed commit message (Julien)
> - Add Juergen R-by for the xen/common/sched part that didn't change
> Changes in v5:
> - Fixed wrong variable name, swapped schedulers, add scheduler info
>   in the printk (Stefano)
> - introduce assert in cpupool_init and btcpupools_get_cpupool_id to
>   harden the code
> Changes in v4:
> - modify Makefile to put in *.init.o, fixed stubs and macro (Jan)
> - fixed docs, fix brakets (Stefano)
> - keep cpu0 in Pool-0 (Julien)
> - moved printk from btcpupools_allocate_pools to
>   btcpupools_get_cpupool_id
> - Add to docs constraint about cpu0 and Pool-0
> Changes in v3:
> - Add newline to cpupools.txt and removed "default n" from Kconfig (Jan)
> - Fixed comment, moved defines, used global cpu_online_map, use
>   HAS_DEVICE_TREE instead of ARM and place arch specific code in header
>   (Juergen)
> - Fix brakets, x86 code only panic, get rid of scheduler dt node, don't
>   save pool pointer and look for it from the pool list (Stefano)
> - Changed data structures to allow modification to the code.
> Changes in v2:
> - Move feature to common code (Juergen)
> - Try to decouple dtb parse and cpupool creation to allow
>   more way to specify cpupools (for example command line)
> - Created standalone dt node for the scheduler so it can
>   be used in future work to set scheduler specific
>   parameters
> - Use only auto generated ids for cpupools
> ---
>  MAINTAINERS|   2 +-
>  docs/misc/arm/device-tree/cpupools.txt | 140 +
>  xen/arch/arm/domain_build.c|   5 +-
>  xen/arch/arm/include/asm/smp.h |   3 +
>  xen/common/Kconfig |   7 +

For consistency, should the addition here - with ...

>  xen/common/sched/Makefile  |   1 +
>  xen/common/sched/boot-cpupool.c| 207 +
>  xen/common/sched/cpupool.c |  12 +-

... the new file now under sched/, also be put in sched/Kconfig?

Jan

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

[Rahul Singh]

Hello David,

Thanks for reviewing the design and sorry for the late reply. 

> On 24 Mar 2022, at 12:24 pm, David Vrabel  wrote:
> 
> 
> 
> On 23/03/2022 15:43, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less system.
>> Signed-off-by: Rahul Singh 
>> ---
>> docs/designs/dom0less-evtchn.md | 96 +
>> 1 file changed, 96 insertions(+)
>> create mode 100644 docs/designs/dom0less-evtchn.md
>> diff --git a/docs/designs/dom0less-evtchn.md 
>> b/docs/designs/dom0less-evtchn.md
>> new file mode 100644
>> index 00..6a1b7e8c22
>> --- /dev/null
>> +++ b/docs/designs/dom0less-evtchn.md
>> @@ -0,0 +1,96 @@
>> +# Signaling support between two domUs on dom0less system
>> +
>> +## Current state: Draft version
>> +
>> +## Proposer(s): Rahul Singh, Bertrand Marquis
>> +
>> +## Problem Statement:
>> +
>> +The goal of this work is to define a simple signaling system between Xen 
>> guests
>> +in dom0less systems.
>> +
>> +In dom0less system, we cannot make use of xenbus and xenstore that are used 
>> in
>> +normal systems with dynamic VMs to communicate between domains by providing 
>> a
>> +bus abstraction for paravirtualized drivers.
>> +
>> +One possible solution to implement the signaling system between domUs is 
>> based
>> +on event channels.
> 
> This problem statement could do with some example use cases that are usefully 
> solved by this proposed solution.
> 
> "We don't have xenstore so can't set up shared rings, but here's a 
> replacement comms mechanism that can do a single bit." Doesn't seem very 
> compelling to me.

Ok. Let me add more information in next version.
> 
>> + chosen {
>> + 
>> +
>> + domU1: domU1 {
>> + ..
>> + };
>> +
>> + domU2: domU2 {
>> + ..
>> + };
>> +
>> + evtchn@1 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xa &domU1 0xb &domU2>;
>> + };
>> +
>> + evtchn@2 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xc &domU1 0xd &domU2>;
>> + };
> 
> How is the domain supposed to know what these event channels are for?

As we are statically defining the event channel in XEN, we can document the 
event
channel connection information for the end-user in the end-user documentation 
and
let the user decide how he is going to use it.  

> 
> I'm not that familiar with device tree. Is it possible to give these entries 
> name?

As per the device-tree specification, each node in the device tree is named 
according to the following convention
node-name@unit-address

We can give the name to these entries but in another email, we are discussing 
having singe node, in that
case there is no need to give a name.

evtchn {
compatible = "xen,evtchn-v1”;
xen,evtchn = <0xa &domU1 0xb &domU2 0xc &domU1 0xd &domU2>;
};

Regards.
Rahul
> 
> David

Ping: [XEN PATCH v10 7/7] build: adding out-of-tree support to the xen build

[Anthony PERARD]

Hi Ross,

Could you also ack this livpatch change?

Thanks.

On Tue, Mar 22, 2022 at 11:22:38AM +, Anthony PERARD wrote:
> This implement out-of-tree support, there's two ways to create an
> out-of-tree build tree (after that, `make` in that new directory
> works):
> make O=build
> mkdir build; cd build; make -f ../Makefile
> also works with an absolute path for both.
> 
> This implementation only works if the source tree is clean, as we use
> VPATH.
> 
> This patch copies most new code with handling out-of-tree build from
> Linux v5.12.
> 
> Signed-off-by: Anthony PERARD 
> Acked-by: Jan Beulich 
> Reviewed-by: Daniel P. Smith 
> Acked-by: Julien Grall 
> Tested-by: Julien Grall 
> ---
[...]
> diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
> index ddb07371315e..c258ab0b5940 100644
> --- a/xen/test/livepatch/Makefile
> +++ b/xen/test/livepatch/Makefile
> @@ -11,6 +11,8 @@ endif
>  CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
>  CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
>  
> +CFLAGS-y += -iquote $(obj)
> +
>  extra-y += xen_hello_world.livepatch
>  xen_hello_world-objs := xen_hello_world_func.o xen_hello_world.o note.o 
> xen_note.o modinfo.o
>  $(obj)/xen_hello_world.o: $(obj)/config.h

-- 
Anthony PERARD

Re: [XEN PATCH v10 7/7] build: adding out-of-tree support to the xen build

[Ross Lagerwall]

> From: Anthony PERARD 
> Sent: Tuesday, March 22, 2022 11:22 AM
> To: xen-devel@lists.xenproject.org 
> Cc: Anthony Perard ; Jan Beulich 
> ; Daniel P . Smith ; Julien 
> Grall ; Andrew Cooper ; George 
> Dunlap ; Julien Grall ; Stefano 
> Stabellini ; Wei Liu ; Roger Pau Monne 
> ; Konrad Rzeszutek Wilk ; Ross 
> Lagerwall ; Daniel De Graaf 
> Subject: [XEN PATCH v10 7/7] build: adding out-of-tree support to the xen 
> build 
>  
> This implement out-of-tree support, there's two ways to create an
> out-of-tree build tree (after that, `make` in that new directory
> works):
> make O=build
> mkdir build; cd build; make -f ../Makefile
> also works with an absolute path for both.
> 
> This implementation only works if the source tree is clean, as we use
> VPATH.
> 
> This patch copies most new code with handling out-of-tree build from
> Linux v5.12.
> 
> Signed-off-by: Anthony PERARD 
> Acked-by: Jan Beulich 
> Reviewed-by: Daniel P. Smith 
> Acked-by: Julien Grall 
> Tested-by: Julien Grall 
> 

Acked-by: Ross Lagerwall  (livepatch parts)

[ovmf test] 169311: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 12a50c9ce117b6106c92bb965799e709547d8494
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  328 attempts
Testing same since   169311  2022-04-11 15:43:02 Z0 days1 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [PATCH 08/27] btrfs: use bdev_max_active_zones instead of open coding it

[David Sterba]

On Sat, Apr 09, 2022 at 06:50:24AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Johannes Thumshirn 

Acked-by: David Sterba 

Re: [PATCH 24/27] block: remove QUEUE_FLAG_DISCARD

[David Sterba]

On Sat, Apr 09, 2022 at 06:50:40AM +0200, Christoph Hellwig wrote:
> Just use a non-zero max_discard_sectors as an indicator for discard
> support, similar to what is done for write zeroes.
> 
> The only places where needs special attention is the RAID5 driver,
> which must clear discard support for security reasons by default,
> even if the default stacking rules would allow for it.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Martin K. Petersen 
> Acked-by: Christoph Böhmwalder  [btrfs]
> Acked-by: Coly Li  [bcache]
> ---
>  arch/um/drivers/ubd_kern.c  |  2 --
>  block/blk-core.c|  2 +-
>  block/blk-lib.c |  2 +-
>  block/blk-mq-debugfs.c  |  1 -
>  block/ioctl.c   |  3 +--
>  drivers/block/drbd/drbd_main.c  |  2 +-
>  drivers/block/drbd/drbd_nl.c| 19 ++-
>  drivers/block/drbd/drbd_receiver.c  |  3 +--
>  drivers/block/loop.c| 11 +++
>  drivers/block/nbd.c |  5 +
>  drivers/block/null_blk/main.c   |  1 -
>  drivers/block/rbd.c |  1 -
>  drivers/block/rnbd/rnbd-clt.c   |  2 --
>  drivers/block/rnbd/rnbd-srv-dev.h   |  3 ---
>  drivers/block/virtio_blk.c  |  2 --
>  drivers/block/xen-blkback/xenbus.c  |  2 +-
>  drivers/block/xen-blkfront.c|  2 --
>  drivers/block/zram/zram_drv.c   |  1 -
>  drivers/md/bcache/request.c |  4 ++--
>  drivers/md/bcache/super.c   |  3 +--
>  drivers/md/bcache/sysfs.c   |  2 +-
>  drivers/md/dm-cache-target.c|  9 +
>  drivers/md/dm-clone-target.c|  9 +
>  drivers/md/dm-log-writes.c  |  3 +--
>  drivers/md/dm-raid.c|  9 ++---
>  drivers/md/dm-table.c   |  9 ++---
>  drivers/md/dm-thin.c| 11 +--
>  drivers/md/dm.c |  3 +--
>  drivers/md/md-linear.c  | 11 +--
>  drivers/md/raid0.c  |  7 ---
>  drivers/md/raid1.c  | 16 +---
>  drivers/md/raid10.c | 18 ++
>  drivers/md/raid5-cache.c|  2 +-
>  drivers/md/raid5.c  | 12 
>  drivers/mmc/core/queue.c|  1 -
>  drivers/mtd/mtd_blkdevs.c   |  1 -
>  drivers/nvme/host/core.c|  6 ++
>  drivers/s390/block/dasd_fba.c   |  1 -
>  drivers/scsi/sd.c   |  2 --
>  drivers/target/target_core_device.c |  2 +-

For

>  fs/btrfs/extent-tree.c  |  4 ++--
>  fs/btrfs/ioctl.c|  2 +-

Acked-by: David Sterba 

Re: [PATCH 25/27] block: add a bdev_discard_granularity helper

[David Sterba]

On Sat, Apr 09, 2022 at 06:50:41AM +0200, Christoph Hellwig wrote:
> Abstract away implementation details from file systems by providing a
> block_device based helper to retrieve the discard granularity.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Martin K. Petersen 
> Acked-by: Christoph Böhmwalder  [btrfs]

This  is for drbd

> Acked-by: Ryusuke Konishi 
> Acked-by: David Sterba  [btrfs]

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

[Julien Grall]

Hi Rahul,

Title: s/../.../

On 23/03/2022 15:43, Rahul Singh wrote:

in dom0less system. This patch introduce the new feature to support the


s/introduce/introduces/
s/the new/a/


signaling between two domUs in dom0less system.

Did you intend to add a newline before the second sentence?



Signed-off-by: Rahul Singh 
---
  docs/designs/dom0less-evtchn.md | 96 +
  1 file changed, 96 insertions(+)
  create mode 100644 docs/designs/dom0less-evtchn.md

diff --git a/docs/designs/dom0less-evtchn.md b/docs/designs/dom0less-evtchn.md
new file mode 100644
index 00..6a1b7e8c22
--- /dev/null
+++ b/docs/designs/dom0less-evtchn.md
@@ -0,0 +1,96 @@
+# Signaling support between two domUs on dom0less system
+
+## Current state: Draft version
+
+## Proposer(s): Rahul Singh, Bertrand Marquis
+
+## Problem Statement:
+
+The goal of this work is to define a simple signaling system between Xen guests
+in dom0less systems.
+
+In dom0less system, we cannot make use of xenbus and xenstore that are used in
+normal systems with dynamic VMs to communicate between domains by providing a
+bus abstraction for paravirtualized drivers.
+
+One possible solution to implement the signaling system between domUs is based
+on event channels.
+
+## Proposal:
+
+Event channels are the basic primitive provided by Xen for event notifications.
+An event channel is a logical connection between 2 domains (more specifically
+between dom1,port1 and dom2,port2). They essentially store one bit of
+information, the event of interest is signalled by transitioning this bit from
+0 to 1. An event is an equivalent of a hardware interrupt.
+
+Notifications are received by a guest via an interrupt from Xen to the guest,
+indicating when an event arrives (setting the bit). 


I am a bit confused with the description. Are you trying to explain the 
event channel in layman term? If not, then event channel protocol is 
more complicated than that (in particular for fifo).



Further notifications are
+masked until the bit is cleared again.


I think "masked" is confusing here.

The event channel differentiate "mask" vs "pending". When sending an 
event, the pending bit will be set to 1. If it wasn't already pending 
and the mask bit is clear, then we will notify the guest.


If the pending bit is already set, then we will ignore.

In fact, the event channel is acting similarly to an edge interrupt. I 
wrote similarly, because IIRC they are behaving slightly differently 
(see [1] for more details).



When a domain wants to wait for data it
+will block until an event arrives, and then send an event to signal that data
+has been consumed.
Events are delivered asynchronously to guests and are
+enqueued when the guest is not running.


s/guest/domain/ to stay consistent and also include dom0/hardware domain.


+
+Event channel communication will be established statically between two domU
+guests before unpausing the domains after domain creation. Event channel
+connection information between domUs will be passed to XEN via device tree
+node.


Why are we limiting ourself to domUs?


+
+Under the /chosen node, there needs to be sub nodes with compatible
+"xen,evtchn" that descibes the event channel connection between two domUs.


s/descibes/describes/


+
+The event channel sub-node has the following properties:
+
+- compatible
+
+"xen,evtchn"
+
+- xen,evtchn
+
+The property is four numbers of tuples of
+(local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:


This is quite difficult to read. Can we add some space before/after each 
comma?



+
+local-port-domU1 is an integer value that will be used to allocte local


s/allocte/allocate/


+port for domU1 to send an event notification to the remote domain.


The port will be used for sending but also receiving event notification.

Also, I would suggest to replace "remote domain" with "domU2". So it is 
more explicit.



+
+domU1-phandle is a single phandle to an domain to which local-port-domU1


s/an domain/a domain/ I think.


+will be allocated.
+
+local-port-domU2 is an integer value that will be used to allocte local


s/allocte/allocate/


+port for domU2 to send an event notification to the remote domain.


Same as above for "remote domain".


+
+domU2-phandle is a single phandle to an domain to which local-port-domU2
+will be allocated.
+
+Example:
+
+chosen {
+
+
+domU1: domU1 {
+..
+};
+
+domU2: domU2 {
+..
+};
+
+evtchn@1 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xa &domU1 0xb &domU2>;
+};
+
+evtchn@2 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xc &domU1 0xd &domU2>;
+};
+};
+
+In above example two event channel comunication will be established between
+domU1 and domU2.
+
+domU1 (port 0xa) <-> domU2 (port 0xb)
+domU1

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

[Julien Grall]

Hi,

On 09/04/2022 02:00, Stefano Stabellini wrote:

On Wed, 23 Mar 2022, Rahul Singh wrote:

in dom0less system. This patch introduce the new feature to support the
signaling between two domUs in dom0less system.

Signed-off-by: Rahul Singh 
---
  docs/designs/dom0less-evtchn.md | 96 +
  1 file changed, 96 insertions(+)
  create mode 100644 docs/designs/dom0less-evtchn.md

diff --git a/docs/designs/dom0less-evtchn.md b/docs/designs/dom0less-evtchn.md
new file mode 100644
index 00..6a1b7e8c22
--- /dev/null
+++ b/docs/designs/dom0less-evtchn.md
@@ -0,0 +1,96 @@
+# Signaling support between two domUs on dom0less system
+
+## Current state: Draft version
+
+## Proposer(s): Rahul Singh, Bertrand Marquis
+
+## Problem Statement:
+
+The goal of this work is to define a simple signaling system between Xen guests
+in dom0less systems.
+
+In dom0less system, we cannot make use of xenbus and xenstore that are used in
+normal systems with dynamic VMs to communicate between domains by providing a
+bus abstraction for paravirtualized drivers.
+
+One possible solution to implement the signaling system between domUs is based
+on event channels.


I suggest to reword this as follows:

---
Dom0less guests would benefit from a statically-defined memory sharing
and signally system for communication. One that would be immediately
available at boot without any need for dynamic configurations.

In embedded a great variety of guest operating system kernels exist,
many of which don't have support for xenstore, grant table or other
complex drivers. Some of them are small kernel-space applications (often
called "baremetal", not to be confused with the term "baremetal" used in
datacenter which means "without hypervisors") or RTOSes.  Additionally,
for safety reasons, users often need to be able to configure the full
system statically so that it can be verified statically.

Event channels are very simple and can be added even to baremetal
applications. This proposal introduces a way to define them statically
to make them suitable to dom0less embedded deployments.
---



+## Proposal:
+
+Event channels are the basic primitive provided by Xen for event notifications.
+An event channel is a logical connection between 2 domains (more specifically
+between dom1,port1 and dom2,port2). They essentially store one bit of
+information, the event of interest is signalled by transitioning this bit from
+0 to 1. An event is an equivalent of a hardware interrupt.
+
+Notifications are received by a guest via an interrupt from Xen to the guest,
+indicating when an event arrives (setting the bit). Further notifications are
+masked until the bit is cleared again. When a domain wants to wait for data it
+will block until an event arrives, and then send an event to signal that data
+has been consumed. Events are delivered asynchronously to guests and are
+enqueued when the guest is not running.
+
+Event channel communication will be established statically between two domU
+guests before unpausing the domains after domain creation. Event channel
+connection information between domUs will be passed to XEN via device tree
+node.
+
+Under the /chosen node, there needs to be sub nodes with compatible
+"xen,evtchn" that descibes the event channel connection between two domUs.
+
+The event channel sub-node has the following properties:
+
+- compatible
+
+"xen,evtchn"
+
+- xen,evtchn
+
+The property is four numbers of tuples of
+(local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:
+
+local-port-domU1 is an integer value that will be used to allocte local
+port for domU1 to send an event notification to the remote domain.
+
+domU1-phandle is a single phandle to an domain to which local-port-domU1
+will be allocated.
+
+local-port-domU2 is an integer value that will be used to allocte local
+port for domU2 to send an event notification to the remote domain.
+
+domU2-phandle is a single phandle to an domain to which local-port-domU2
+will be allocated.
+
+Example:
+
+chosen {
+
+
+domU1: domU1 {
+..
+};
+
+domU2: domU2 {
+..
+};
+
+evtchn@1 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xa &domU1 0xb &domU2>;
+};
+
+evtchn@2 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xc &domU1 0xd &domU2>;
+};
+};


There is no need to use two evtchn nodes for this given that in device
tree it is entirely normal to have multiple tuplets in a property. Also,
it would be good to have a version number in the compatible string so
that we can change version in the future.

1)
 chosen {
 

 domU1: domU1 {
 ..
 };

 domU2: domU2 {
 ..
 };

 evtchn {
 compatible = "xen,evtchn-v1";
 xen,evtchn = <0xa &domU1 0xb &dom

[ovmf test] 169312: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 12a50c9ce117b6106c92bb965799e709547d8494
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  329 attempts
Testing same since   169311  2022-04-11 15:43:02 Z0 days2 attempts


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

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



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

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

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

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


Not pushing.

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

[ovmf test] 169313: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 12a50c9ce117b6106c92bb965799e709547d8494
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  330 attempts
Testing same since   169311  2022-04-11 15:43:02 Z0 days3 attempts


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

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



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

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

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

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


Not pushing.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169292

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

version 

[ovmf test] 169314: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 12a50c9ce117b6106c92bb965799e709547d8494
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  331 attempts
Testing same since   169311  2022-04-11 15:43:02 Z0 days4 attempts


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

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



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

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

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

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


Not pushing.

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

[ovmf test] 169315: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 12a50c9ce117b6106c92bb965799e709547d8494
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  332 attempts
Testing same since   169311  2022-04-11 15:43:02 Z0 days5 attempts


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

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



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

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

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

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


Not pushing.

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

[ovmf test] 169316: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 12a50c9ce117b6106c92bb965799e709547d8494
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   41 days  333 attempts
Testing same since   169311  2022-04-11 15:43:02 Z0 days6 attempts


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

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



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

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

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

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


Not pushing.

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

[ovmf test] 169317: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 12a50c9ce117b6106c92bb965799e709547d8494
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   42 days  334 attempts
Testing same since   169311  2022-04-11 15:43:02 Z0 days7 attempts


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

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



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

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

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

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


Not pushing.

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

[ovmf test] 169319: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 12a50c9ce117b6106c92bb965799e709547d8494
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   42 days  335 attempts
Testing same since   169311  2022-04-11 15:43:02 Z0 days8 attempts


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

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



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

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

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

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


Not pushing.

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

[ovmf test] 169321: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 12a50c9ce117b6106c92bb965799e709547d8494
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   42 days
Failing since168258  2022-03-01 01:55:31 Z   42 days  336 attempts
Testing same since   169311  2022-04-11 15:43:02 Z0 days9 attempts


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

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



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

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

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

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


Not pushing.

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

[PATCH v7 02/20] notifier: Add atomic/blocking_notifier_chain_register_unique_prio()

[Dmitry Osipenko]

Add variant of atomic/blocking_notifier_chain_register() functions that
doesn't allow to register notifier using a duplicated priority. The -EBUSY
error code is returned in this case by the new API functions.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/notifier.h |  5 +++
 kernel/notifier.c| 88 +++-
 2 files changed, 74 insertions(+), 19 deletions(-)

diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index d4717bc0ab85..ccce26197dd2 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -150,6 +150,11 @@ extern int raw_notifier_chain_register(struct 
raw_notifier_head *nh,
 extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh,
struct notifier_block *nb);
 
+extern int atomic_notifier_chain_register_unique_prio(
+   struct atomic_notifier_head *nh, struct notifier_block *nb);
+extern int blocking_notifier_chain_register_unique_prio(
+   struct blocking_notifier_head *nh, struct notifier_block *nb);
+
 extern int atomic_notifier_chain_unregister(struct atomic_notifier_head *nh,
struct notifier_block *nb);
 extern int blocking_notifier_chain_unregister(struct blocking_notifier_head 
*nh,
diff --git a/kernel/notifier.c b/kernel/notifier.c
index 4ed6bda8f127..4fc32b1e6cbb 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -20,7 +20,8 @@ BLOCKING_NOTIFIER_HEAD(reboot_notifier_list);
  */
 
 static int notifier_chain_register(struct notifier_block **nl,
-  struct notifier_block *n)
+  struct notifier_block *n,
+  bool unique_priority)
 {
while ((*nl) != NULL) {
if (unlikely((*nl) == n)) {
@@ -30,6 +31,8 @@ static int notifier_chain_register(struct notifier_block **nl,
}
if (n->priority > (*nl)->priority)
break;
+   if (n->priority == (*nl)->priority && unique_priority)
+   return -EBUSY;
nl = &((*nl)->next);
}
n->next = *nl;
@@ -144,12 +147,35 @@ int atomic_notifier_chain_register(struct 
atomic_notifier_head *nh,
int ret;
 
spin_lock_irqsave(&nh->lock, flags);
-   ret = notifier_chain_register(&nh->head, n);
+   ret = notifier_chain_register(&nh->head, n, false);
spin_unlock_irqrestore(&nh->lock, flags);
return ret;
 }
 EXPORT_SYMBOL_GPL(atomic_notifier_chain_register);
 
+/**
+ * atomic_notifier_chain_register_unique_prio - Add notifier to an atomic 
notifier chain
+ * @nh: Pointer to head of the atomic notifier chain
+ * @n: New entry in notifier chain
+ *
+ * Adds a notifier to an atomic notifier chain if there is no other
+ * notifier registered using the same priority.
+ *
+ * Returns 0 on success, %-EEXIST or %-EBUSY on error.
+ */
+int atomic_notifier_chain_register_unique_prio(struct atomic_notifier_head *nh,
+  struct notifier_block *n)
+{
+   unsigned long flags;
+   int ret;
+
+   spin_lock_irqsave(&nh->lock, flags);
+   ret = notifier_chain_register(&nh->head, n, true);
+   spin_unlock_irqrestore(&nh->lock, flags);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(atomic_notifier_chain_register_unique_prio);
+
 /**
  * atomic_notifier_chain_unregister - Remove notifier from an atomic 
notifier chain
  * @nh: Pointer to head of the atomic notifier chain
@@ -209,18 +235,9 @@ NOKPROBE_SYMBOL(atomic_notifier_call_chain);
  * synchronized by an rwsem.
  */
 
-/**
- * blocking_notifier_chain_register - Add notifier to a blocking notifier 
chain
- * @nh: Pointer to head of the blocking notifier chain
- * @n: New entry in notifier chain
- *
- * Adds a notifier to a blocking notifier chain.
- * Must be called in process context.
- *
- * Returns 0 on success, %-EEXIST on error.
- */
-int blocking_notifier_chain_register(struct blocking_notifier_head *nh,
-   struct notifier_block *n)
+static int __blocking_notifier_chain_register(struct blocking_notifier_head 
*nh,
+ struct notifier_block *n,
+ bool unique_priority)
 {
int ret;
 
@@ -230,15 +247,48 @@ int blocking_notifier_chain_register(struct 
blocking_notifier_head *nh,
 * such times we must not call down_write().
 */
if (unlikely(system_state == SYSTEM_BOOTING))
-   return notifier_chain_register(&nh->head, n);
+   return notifier_chain_register(&nh->head, n, unique_priority);
 
down_write(&nh->rwsem);
-   ret = notifier_chain_register(&nh->head, n);
+   ret = notifier_chain_register(&nh->head, n, unique_priority);
up_write(&nh->rwsem);
return ret;
 }
+
+/**
+ * blocking_notifier_chain_register - Add notifier to a bloc

[PATCH v7 01/20] notifier: Add blocking_notifier_call_chain_is_empty()

[Dmitry Osipenko]

Add blocking_notifier_call_chain_is_empty() that returns true if call
chain is empty.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/notifier.h |  2 ++
 kernel/notifier.c| 13 +
 2 files changed, 15 insertions(+)

diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 87069b8459af..d4717bc0ab85 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -173,6 +173,8 @@ extern int blocking_notifier_call_chain_robust(struct 
blocking_notifier_head *nh
 extern int raw_notifier_call_chain_robust(struct raw_notifier_head *nh,
unsigned long val_up, unsigned long val_down, void *v);
 
+extern bool blocking_notifier_call_chain_is_empty(struct 
blocking_notifier_head *nh);
+
 #define NOTIFY_DONE0x  /* Don't care */
 #define NOTIFY_OK  0x0001  /* Suits me */
 #define NOTIFY_STOP_MASK   0x8000  /* Don't call further */
diff --git a/kernel/notifier.c b/kernel/notifier.c
index ba005ebf4730..4ed6bda8f127 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -323,6 +323,19 @@ int blocking_notifier_call_chain(struct 
blocking_notifier_head *nh,
 }
 EXPORT_SYMBOL_GPL(blocking_notifier_call_chain);
 
+/**
+ * blocking_notifier_call_chain_is_empty - Check whether notifier chain is 
empty
+ * @nh: Pointer to head of the blocking notifier chain
+ *
+ * Checks whether notifier chain is empty.
+ *
+ * Returns true is notifier chain is empty, false otherwise.
+ */
+bool blocking_notifier_call_chain_is_empty(struct blocking_notifier_head *nh)
+{
+   return !rcu_access_pointer(nh->head);
+}
+
 /*
  * Raw notifier chain routines.  There is no protection;
  * the caller must provide it.  Use at your own risk!
-- 
2.35.1

[PATCH v7 04/20] kernel: Add combined power-off+restart handler call chain API

[Dmitry Osipenko]

SoC platforms often have multiple ways of how to perform system's
power-off and restart operations. Meanwhile today's kernel is limited to
a single option. Add combined power-off+restart handler call chain API,
which is inspired by the restart API. The new API provides both power-off
and restart functionality.

The old pm_power_off method will be kept around till all users are
converted to the new API.

Current restart API will be replaced by the new unified API since
new API is its superset. The restart functionality of the sys-off handler
API is built upon the existing restart-notifier APIs.

In order to ease conversion to the new API, convenient helpers are added
for the common use-cases. They will reduce amount of boilerplate code and
remove global variables. These helpers preserve old behaviour for cases
where only one power-off handler is expected, this is what all existing
drivers want, and thus, they could be easily converted to the new API.
Users of the new API should explicitly enable power-off chaining by
setting corresponding flag of the power_handler structure.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/reboot.h   | 229 ++-
 kernel/power/hibernate.c |   2 +-
 kernel/reboot.c  | 604 ++-
 3 files changed, 827 insertions(+), 8 deletions(-)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index a2429648d831..ba5e5dddcfcd 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -8,10 +8,35 @@
 
 struct device;
 
-#define SYS_DOWN   0x0001  /* Notify of system down */
-#define SYS_RESTARTSYS_DOWN
-#define SYS_HALT   0x0002  /* Notify of system halt */
-#define SYS_POWER_OFF  0x0003  /* Notify of system power off */
+enum reboot_prepare_mode {
+   SYS_DOWN = 1,   /* Notify of system down */
+   SYS_RESTART = SYS_DOWN,
+   SYS_HALT,   /* Notify of system halt */
+   SYS_POWER_OFF,  /* Notify of system power off */
+};
+
+/*
+ * Standard restart priority levels. Intended to be set in the
+ * sys_off_handler.restart_priority field.
+ *
+ * Use `RESTART_PRIO_ABC +- prio` style for additional levels.
+ *
+ * RESTART_PRIO_RESERVED:  Falls back to RESTART_PRIO_DEFAULT.
+ * Drivers may leave priority initialized
+ * to zero, to auto-set it to the default level.
+ *
+ * RESTART_PRIO_LOW:   Use this for handler of last resort.
+ *
+ * RESTART_PRIO_DEFAULT:   Use this for default/generic handler.
+ *
+ * RESTART_PRIO_HIGH:  Use this if you have multiple handlers and
+ * this handler has higher priority than the
+ * default handler.
+ */
+#define RESTART_PRIO_RESERVED  0
+#define RESTART_PRIO_LOW   8
+#define RESTART_PRIO_DEFAULT   128
+#define RESTART_PRIO_HIGH  192
 
 enum reboot_mode {
REBOOT_UNDEFINED = -1,
@@ -49,6 +74,201 @@ extern int register_restart_handler(struct notifier_block 
*);
 extern int unregister_restart_handler(struct notifier_block *);
 extern void do_kernel_restart(char *cmd);
 
+/*
+ * System power-off and restart API.
+ */
+
+/*
+ * Standard power-off priority levels. Intended to be set in the
+ * sys_off_handler.power_off_priority field.
+ *
+ * Use `POWEROFF_PRIO_ABC +- prio` style for additional levels.
+ *
+ * POWEROFF_PRIO_RESERVED: Falls back to POWEROFF_PRIO_DEFAULT.
+ * Drivers may leave priority initialized
+ * to zero, to auto-set it to the default level.
+ *
+ * POWEROFF_PRIO_PLATFORM: Intended to be used by platform-level handler.
+ * Has lowest priority since device drivers are
+ * expected to take over platform handler which
+ * doesn't allow further callback chaining.
+ *
+ * POWEROFF_PRIO_DEFAULT:  Use this for default/generic handler.
+ *
+ * POWEROFF_PRIO_FIRMWARE: Use this if handler uses firmware call.
+ * Has highest priority since firmware is expected
+ * to know best how to power-off hardware properly.
+ */
+#define POWEROFF_PRIO_RESERVED 0
+#define POWEROFF_PRIO_PLATFORM 1
+#define POWEROFF_PRIO_DEFAULT  128
+#define POWEROFF_PRIO_HIGH 192
+#define POWEROFF_PRIO_FIRMWARE 224
+
+enum poweroff_mode {
+   POWEROFF_NORMAL = 0,
+   POWEROFF_PREPARE,
+};
+
+/**
+ * struct power_off_data - Power-off callback argument
+ *
+ * @cb_data: Callback data.
+ */
+struct power_off_data {
+   void *cb_data;
+};
+
+/**
+ * struct power_off_prep_data - Power-off preparation callback argument
+ *
+ * @cb_data: Callback data.
+ */
+struct power_off_prep_data {
+   void *cb_data;
+};
+
+/**
+ * struct restart_data - Restart callback argument
+ *
+ * @cb_data: Callback data.
+ * @cmd: Restart comma

[PATCH v7 07/20] riscv: Use do_kernel_power_off()

[Dmitry Osipenko]

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Acked-by: Palmer Dabbelt 
Signed-off-by: Dmitry Osipenko 
---
 arch/riscv/kernel/reset.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/kernel/reset.c b/arch/riscv/kernel/reset.c
index 9c842c41684a..912288572226 100644
--- a/arch/riscv/kernel/reset.c
+++ b/arch/riscv/kernel/reset.c
@@ -23,16 +23,12 @@ void machine_restart(char *cmd)
 
 void machine_halt(void)
 {
-   if (pm_power_off != NULL)
-   pm_power_off();
-   else
-   default_power_off();
+   do_kernel_power_off();
+   default_power_off();
 }
 
 void machine_power_off(void)
 {
-   if (pm_power_off != NULL)
-   pm_power_off();
-   else
-   default_power_off();
+   do_kernel_power_off();
+   default_power_off();
 }
-- 
2.35.1

[PATCH v7 05/20] ARM: Use do_kernel_power_off()

[Dmitry Osipenko]

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Reviewed-by: Russell King (Oracle) 
Signed-off-by: Dmitry Osipenko 
---
 arch/arm/kernel/reboot.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
index 3044fcb8d073..2cb943422554 100644
--- a/arch/arm/kernel/reboot.c
+++ b/arch/arm/kernel/reboot.c
@@ -116,9 +116,7 @@ void machine_power_off(void)
 {
local_irq_disable();
smp_send_stop();
-
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();
 }
 
 /*
-- 
2.35.1

[PATCH v7 08/20] arm64: Use do_kernel_power_off()

[Dmitry Osipenko]

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Acked-by: Catalin Marinas 
Signed-off-by: Dmitry Osipenko 
---
 arch/arm64/kernel/process.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 7fa97df55e3a..26d1b0a4329a 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -111,8 +111,7 @@ void machine_power_off(void)
 {
local_irq_disable();
smp_send_stop();
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();
 }
 
 /*
-- 
2.35.1

[PATCH v7 11/20] powerpc: Use do_kernel_power_off()

[Dmitry Osipenko]

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Acked-by: Michael Ellerman 
Signed-off-by: Dmitry Osipenko 
---
 arch/powerpc/kernel/setup-common.c | 4 +---
 arch/powerpc/xmon/xmon.c   | 3 +--
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 518ae5aa9410..1b586577e75b 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -161,9 +161,7 @@ void machine_restart(char *cmd)
 void machine_power_off(void)
 {
machine_shutdown();
-   if (pm_power_off)
-   pm_power_off();
-
+   do_kernel_power_off();
smp_send_stop();
machine_hang();
 }
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index fd72753e8ad5..c916bf250796 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1243,8 +1243,7 @@ static void bootcmds(void)
} else if (cmd == 'h') {
ppc_md.halt();
} else if (cmd == 'p') {
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();
}
 }
 
-- 
2.35.1

[PATCH v7 13/20] sh: Use do_kernel_power_off()

[Dmitry Osipenko]

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Signed-off-by: Dmitry Osipenko 
---
 arch/sh/kernel/reboot.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/sh/kernel/reboot.c b/arch/sh/kernel/reboot.c
index 5c33f036418b..e8eeedc9b182 100644
--- a/arch/sh/kernel/reboot.c
+++ b/arch/sh/kernel/reboot.c
@@ -46,8 +46,7 @@ static void native_machine_shutdown(void)
 
 static void native_machine_power_off(void)
 {
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();
 }
 
 static void native_machine_halt(void)
-- 
2.35.1

[PATCH v7 14/20] x86: Use do_kernel_power_off()

[Dmitry Osipenko]

Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.

Signed-off-by: Dmitry Osipenko 
---
 arch/x86/kernel/reboot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index fa700b46588e..c3636ea4aa71 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -739,10 +739,10 @@ static void native_machine_halt(void)
 
 static void native_machine_power_off(void)
 {
-   if (pm_power_off) {
+   if (kernel_can_power_off()) {
if (!reboot_force)
machine_shutdown();
-   pm_power_off();
+   do_kernel_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
-- 
2.35.1