[ovmf test] 170285: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 0e31124877cc8bc0140a03ad3196f0d58b2fd966
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   70 days  905 attempts
Testing same since   170272  2022-05-09 15:12:57 Z0 days9 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao Li 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6200 lines long.)

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

[osstest service owner]

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

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  0badfb110fa33ca9ffd3bdc3a5200cded03e6106
baseline version:
 xen  95604873ccf56eb81e96ed0dc8b4dec3278f40ca

Last test of basis   170278  2022-05-09 19:01:55 Z0 days
Testing same since   170280  2022-05-09 23:01:42 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Luca Fancellu 

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
   95604873cc..0badfb110f  0badfb110fa33ca9ffd3bdc3a5200cded03e6106 -> smoke

[PATCH v4 6/6] xen: retrieve reserved pages on populate_physmap

[Penny Zheng]

When static domain populates memory through populate_physmap on runtime,
other than allocating from heap, it shall retrieve reserved pages from
resv_page_list to make sure that guest RAM is still restricted in statically
configured memory regions. And this commit introduces a new helper
acquire_reserved_page to make it work.

Signed-off-by: Penny Zheng 
---
v4 changes：
- miss dropping __init in acquire_domstatic_pages
- add the page back to the reserved list in case of error
- remove redundant printk
- refine log message and make it warn level
---
v3 changes:
- move is_domain_using_staticmem to the common header file
- remove #ifdef CONFIG_STATIC_MEMORY-ary
- remove meaningless page_to_mfn(page) in error log
---
v2 changes:
- introduce acquire_reserved_page to retrieve reserved pages from
resv_page_list
- forbid non-zero-order requests in populate_physmap
- let is_domain_static return ((void)(d), false) on x86
---
 xen/common/memory.c  | 23 +++
 xen/common/page_alloc.c  | 35 +--
 xen/include/xen/domain.h |  4 
 xen/include/xen/mm.h |  1 +
 4 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index f2d009843a..cb330ce877 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -245,6 +245,29 @@ static void populate_physmap(struct memop_args *a)
 
 mfn = _mfn(gpfn);
 }
+else if ( is_domain_using_staticmem(d) )
+{
+/*
+ * No easy way to guarantee the retrieved pages are contiguous,
+ * so forbid non-zero-order requests here.
+ */
+if ( a->extent_order != 0 )
+{
+gdprintk(XENLOG_WARNING,
+ "Cannot allocate static order-%u pages for static 
%pd\n",
+ a->extent_order, d);
+goto out;
+}
+
+mfn = acquire_reserved_page(d, a->memflags);
+if ( mfn_eq(mfn, INVALID_MFN) )
+{
+gdprintk(XENLOG_WARNING,
+ "%pd: failed to retrieve a reserved page\n",
+ d);
+goto out;
+}
+}
 else
 {
 page = alloc_domheap_pages(d, a->extent_order, a->memflags);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 290526adaf..06e7037a28 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2740,8 +2740,8 @@ static struct page_info * __init 
acquire_staticmem_pages(mfn_t smfn,
  * Acquire nr_mfns contiguous pages, starting at #smfn, of static memory,
  * then assign them to one specific domain #d.
  */
-int __init acquire_domstatic_pages(struct domain *d, mfn_t smfn,
-   unsigned int nr_mfns, unsigned int memflags)
+int acquire_domstatic_pages(struct domain *d, mfn_t smfn, unsigned int nr_mfns,
+unsigned int memflags)
 {
 struct page_info *pg;
 
@@ -2769,12 +2769,43 @@ int __init acquire_domstatic_pages(struct domain *d, 
mfn_t smfn,
 
 return 0;
 }
+
+/*
+ * Acquire a page from reserved page list(resv_page_list), when populating
+ * memory for static domain on runtime.
+ */
+mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags)
+{
+struct page_info *page;
+mfn_t smfn;
+
+/* Acquire a page from reserved page list(resv_page_list). */
+page = page_list_remove_head(>resv_page_list);
+if ( unlikely(!page) )
+return INVALID_MFN;
+
+smfn = page_to_mfn(page);
+
+if ( acquire_domstatic_pages(d, smfn, 1, memflags) )
+{
+page_list_add_tail(page, >resv_page_list);
+return INVALID_MFN;
+}
+
+return smfn;
+}
 #else
 void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
   bool need_scrub)
 {
 ASSERT_UNREACHABLE();
 }
+
+mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags)
+{
+ASSERT_UNREACHABLE();
+return INVALID_MFN;
+}
 #endif
 
 /*
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 35dc7143a4..c613afa57e 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -38,6 +38,10 @@ void arch_get_domain_info(const struct domain *d,
 #define CDF_staticmem(1U << 2)
 #endif
 
+#ifndef is_domain_using_staticmem
+#define is_domain_using_staticmem(d) ((void)(d), false)
+#endif
+
 /*
  * Arch-specifics.
  */
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 9fd95deaec..74810e1f54 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -92,6 +92,7 @@ void free_staticmem_pages(struct page_info *pg, unsigned long 
nr_mfns,
 int acquire_domstatic_pages(struct domain *d, mfn_t smfn, unsigned int nr_mfns,
 unsigned int memflags);
 #endif
+mfn_t 

[PATCH v4 5/6] xen/arm: unpopulate memory when domain is static

[Penny Zheng]

Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.

Pages as guest RAM for static domain shall be reserved to only this domain
and not be used for any other purposes, so they shall never go back to heap
allocator.

This commit puts reserved pages on the new list resv_page_list only after
having taken them off the "normal" list, when the last ref dropped.

Signed-off-by: Penny Zheng 
---
v4 changes:
- no changes
---
v3 changes:
- have page_list_del() just once out of the if()
- remove resv_pages counter
- make arch_free_heap_page be an expression, not a compound statement.
---
v2 changes:
- put reserved pages on resv_page_list after having taken them off
the "normal" list
---
 xen/arch/arm/include/asm/mm.h | 12 
 xen/common/domain.c   |  4 
 xen/include/xen/sched.h   |  3 +++
 3 files changed, 19 insertions(+)

diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 424aaf2823..c6426c1705 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -358,6 +358,18 @@ void clear_and_clean_page(struct page_info *page);
 
 unsigned int arch_get_dma_bitsize(void);
 
+/*
+ * Put free pages on the resv page list after having taken them
+ * off the "normal" page list, when pages from static memory
+ */
+#ifdef CONFIG_STATIC_MEMORY
+#define arch_free_heap_page(d, pg) ({   \
+page_list_del(pg, page_to_list(d, pg)); \
+if ( (pg)->count_info & PGC_reserved )  \
+page_list_add_tail(pg, &(d)->resv_page_list);   \
+})
+#endif
+
 #endif /*  __ARCH_ARM_MM__ */
 /*
  * Local variables:
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 6373407047..13fe7cecff 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -604,6 +604,10 @@ struct domain *domain_create(domid_t domid,
 INIT_PAGE_LIST_HEAD(>page_list);
 INIT_PAGE_LIST_HEAD(>extra_page_list);
 INIT_PAGE_LIST_HEAD(>xenpage_list);
+#ifdef CONFIG_STATIC_MEMORY
+INIT_PAGE_LIST_HEAD(>resv_page_list);
+#endif
+
 
 spin_lock_init(>node_affinity_lock);
 d->node_affinity = NODE_MASK_ALL;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 49415a113a..368e5c1c53 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -376,6 +376,9 @@ struct domain
 struct page_list_head page_list;  /* linked list */
 struct page_list_head extra_page_list; /* linked list (size extra_pages) */
 struct page_list_head xenpage_list; /* linked list (size xenheap_pages) */
+#ifdef CONFIG_STATIC_MEMORY
+struct page_list_head resv_page_list; /* linked list (size resv_pages) */
+#endif
 
 /*
  * This field should only be directly accessed by domain_adjust_tot_pages()
-- 
2.25.1

[PATCH v4 4/6] xen/arm: introduce CDF_staticmem

[Penny Zheng]

In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_using_staticmem() to tell.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
v4 changes:
- no changes
---
v3 changes:
- change name from "is_domain_static()" to "is_domain_using_staticmem"
---
v2 changes:
- change name from "is_domain_on_static_allocation" to "is_domain_static()"
---
 xen/arch/arm/domain_build.c   | 5 -
 xen/arch/arm/include/asm/domain.h | 2 ++
 xen/include/xen/domain.h  | 2 ++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1472ca4972..6830a282a0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3190,9 +3190,12 @@ void __init create_domUs(void)
 if ( !dt_device_is_compatible(node, "xen,domain") )
 continue;
 
+if ( dt_find_property(node, "xen,static-mem", NULL) )
+flags |= CDF_staticmem;
+
 if ( dt_property_read_bool(node, "direct-map") )
 {
-if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) || !dt_find_property(node, 
"xen,static-mem", NULL) )
+if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) || !(flags & CDF_staticmem) 
)
 panic("direct-map is not valid for domain %s without static 
allocation.\n",
   dt_node_name(node));
 
diff --git a/xen/arch/arm/include/asm/domain.h 
b/xen/arch/arm/include/asm/domain.h
index fe7a029ebf..110c672589 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -31,6 +31,8 @@ enum domain_type {
 
 #define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
 
+#define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
+
 /*
  * Is the domain using the host memory layout?
  *
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 1c3c88a14d..35dc7143a4 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -34,6 +34,8 @@ void arch_get_domain_info(const struct domain *d,
 #ifdef CONFIG_ARM
 /* Should domain memory be directly mapped? */
 #define CDF_directmap(1U << 1)
+/* Is domain memory on static allocation? */
+#define CDF_staticmem(1U << 2)
 #endif
 
 /*
-- 
2.25.1

[PATCH v4 3/6] xen: add field "flags" to cover all internal CDF_XXX

[Penny Zheng]

With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" in struct domain to store CDF_*
internal flags directly.

Another new CDF_xxx will be introduced in the next patch.

Signed-off-by: Penny Zheng 
Acked-by: Julien Grall 
---
v4 changes:
- no change
---
v3 changes:
- change fixed width type uint32_t to unsigned int
- change "flags" to a more descriptive name "cdf"
---
v2 changes:
- let "flags" live in the struct domain. So other arch can take
advantage of it in the future
- fix coding style
---
 xen/arch/arm/domain.c | 2 --
 xen/arch/arm/include/asm/domain.h | 3 +--
 xen/common/domain.c   | 3 +++
 xen/include/xen/sched.h   | 3 +++
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8110c1df86..74189d9878 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -709,8 +709,6 @@ int arch_domain_create(struct domain *d,
 ioreq_domain_init(d);
 #endif
 
-d->arch.directmap = flags & CDF_directmap;
-
 /* p2m_init relies on some value initialized by the IOMMU subsystem */
 if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
 goto fail;
diff --git a/xen/arch/arm/include/asm/domain.h 
b/xen/arch/arm/include/asm/domain.h
index ed63c2b6f9..fe7a029ebf 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -29,7 +29,7 @@ enum domain_type {
 #define is_64bit_domain(d) (0)
 #endif
 
-#define is_domain_direct_mapped(d) (d)->arch.directmap
+#define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
 
 /*
  * Is the domain using the host memory layout?
@@ -103,7 +103,6 @@ struct arch_domain
 void *tee;
 #endif
 
-bool directmap;
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8d2c2a9897..6373407047 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -567,6 +567,9 @@ struct domain *domain_create(domid_t domid,
 /* Sort out our idea of is_system_domain(). */
 d->domain_id = domid;
 
+/* Holding CDF_* internal flags. */
+d->cdf = flags;
+
 /* Debug sanity. */
 ASSERT(is_system_domain(d) ? config == NULL : config != NULL);
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index ed8539f6d2..49415a113a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -591,6 +591,9 @@ struct domain
 struct ioreq_server *server[MAX_NR_IOREQ_SERVERS];
 } ioreq_server;
 #endif
+
+/* Holding CDF_* constant. Internal flags for domain creation. */
+unsigned int cdf;
 };
 
 static inline struct page_list_head *page_to_list(
-- 
2.25.1

[PATCH v4 2/6] xen: do not merge reserved pages in free_heap_pages()

[Penny Zheng]

The code in free_heap_pages() will try to merge pages with the
successor/predecessor if pages are suitably aligned. So if the pages
reserved are right next to the pages given to the heap allocator,
free_heap_pages() will merge them, and give the reserved pages to heap
allocator accidently as a result.

So in order to avoid the above scenario, this commit updates free_heap_pages()
to check whether the predecessor and/or successor has PGC_reserved set,
when trying to merge the about-to-be-freed chunk with the predecessor
and/or successor.

Signed-off-by: Penny Zheng 
Suggested-by: Julien Grall 
Reviewed-by: Jan Beulich 
---
v4 changes:
- commit message refinement
---
v3 changes:
- no changes
---
v2 changes:
- new commit
---
 xen/common/page_alloc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 5e569a48a2..290526adaf 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1483,6 +1483,7 @@ static void free_heap_pages(
 /* Merge with predecessor block? */
 if ( !mfn_valid(page_to_mfn(predecessor)) ||
  !page_state_is(predecessor, free) ||
+ (predecessor->count_info & PGC_reserved) ||
  (PFN_ORDER(predecessor) != order) ||
  (phys_to_nid(page_to_maddr(predecessor)) != node) )
 break;
@@ -1506,6 +1507,7 @@ static void free_heap_pages(
 /* Merge with successor block? */
 if ( !mfn_valid(page_to_mfn(successor)) ||
  !page_state_is(successor, free) ||
+ (successor->count_info & PGC_reserved) ||
  (PFN_ORDER(successor) != order) ||
  (phys_to_nid(page_to_maddr(successor)) != node) )
 break;
-- 
2.25.1

[PATCH v4 1/6] xen: do not free reserved memory into heap

[Penny Zheng]

Pages used as guest RAM for static domain, shall be reserved to this
domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.

free_staticmem_pages will be called by free_heap_pages in runtime
for static domain freeing memory resource, so let's drop the __init
flag.

Signed-off-by: Penny Zheng 
---
v4 changes:
- no changes
---
v3 changes:
- fix possible racy issue in free_staticmem_pages()
- introduce a stub free_staticmem_pages() for the !CONFIG_STATIC_MEMORY case
- move the change to free_heap_pages() to cover other potential call sites
- fix the indentation
---
v2 changes:
- new commit
---
 xen/common/page_alloc.c | 17 ++---
 xen/include/xen/mm.h|  2 +-
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 319029140f..5e569a48a2 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1443,6 +1443,10 @@ static void free_heap_pages(
 
 ASSERT(order <= MAX_ORDER);
 
+if ( pg->count_info & PGC_reserved )
+/* Reserved page shall not go back to the heap. */
+return free_staticmem_pages(pg, 1UL << order, need_scrub);
+
 spin_lock(_lock);
 
 for ( i = 0; i < (1 << order); i++ )
@@ -2636,8 +2640,8 @@ struct domain *get_pg_owner(domid_t domid)
 
 #ifdef CONFIG_STATIC_MEMORY
 /* Equivalent of free_heap_pages to free nr_mfns pages of static memory. */
-void __init free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
- bool need_scrub)
+void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
+  bool need_scrub)
 {
 mfn_t mfn = page_to_mfn(pg);
 unsigned long i;
@@ -2653,7 +2657,8 @@ void __init free_staticmem_pages(struct page_info *pg, 
unsigned long nr_mfns,
 }
 
 /* In case initializing page of static memory, mark it PGC_reserved. */
-pg[i].count_info |= PGC_reserved;
+if ( !(pg[i].count_info & PGC_reserved) )
+pg[i].count_info |= PGC_reserved;
 }
 }
 
@@ -2762,6 +2767,12 @@ int __init acquire_domstatic_pages(struct domain *d, 
mfn_t smfn,
 
 return 0;
 }
+#else
+void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
+  bool need_scrub)
+{
+ASSERT_UNREACHABLE();
+}
 #endif
 
 /*
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 3be754da92..9fd95deaec 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -85,10 +85,10 @@ bool scrub_free_pages(void);
 } while ( false )
 #define FREE_XENHEAP_PAGE(p) FREE_XENHEAP_PAGES(p, 0)
 
-#ifdef CONFIG_STATIC_MEMORY
 /* These functions are for static memory */
 void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
   bool need_scrub);
+#ifdef CONFIG_STATIC_MEMORY
 int acquire_domstatic_pages(struct domain *d, mfn_t smfn, unsigned int nr_mfns,
 unsigned int memflags);
 #endif
-- 
2.25.1

[PATCH V4 0/6] populate/unpopulate memory when domain on static

[Penny Zheng]

Today when a domain unpopulates the memory on runtime, they will always
hand the memory over to the heap allocator. And it will be a problem if it
is a static domain.
Pages used as guest RAM for static domain shall always be reserved to this
domain only, and not be used for any other purposes, so they shall never go
back to heap allocator.

This patch serie intends to fix this issue, by adding pages on the new list
resv_page_list after having taken them off the "normal" list, when unpopulating
memory, and retrieving pages from resv page list(resv_page_list) when
populating memory.

---
v4 changes:
- commit message refinement
- miss dropping __init in acquire_domstatic_pages
- add the page back to the reserved list in case of error
- remove redundant printk
- refine log message and make it warn level
---
v3 changes:
- fix possible racy issue in free_staticmem_pages()
- introduce a stub free_staticmem_pages() for the !CONFIG_STATIC_MEMORY case
- move the change to free_heap_pages() to cover other potential call sites
- change fixed width type uint32_t to unsigned int
- change "flags" to a more descriptive name "cdf"
- change name from "is_domain_static()" to "is_domain_using_staticmem"
- have page_list_del() just once out of the if()
- remove resv_pages counter
- make arch_free_heap_page be an expression, not a compound statement.
- move #ifndef is_domain_using_staticmem to the common header file
- remove #ifdef CONFIG_STATIC_MEMORY-ary
- remove meaningless page_to_mfn(page) in error log
---
v2 changes:
- let "flags" live in the struct domain. So other arch can take
advantage of it in the future
- change name from "is_domain_on_static_allocation" to "is_domain_static()"
- put reserved pages on resv_page_list after having taken them off
the "normal" list
- introduce acquire_reserved_page to retrieve reserved pages from
resv_page_list
- forbid non-zero-order requests in populate_physmap
- let is_domain_static return ((void)(d), false) on x86
- fix coding style

Penny Zheng (6):
  xen: do not free reserved memory into heap
  xen: do not merge reserved pages in free_heap_pages()
  xen: add field "flags" to cover all internal CDF_XXX
  xen/arm: introduce CDF_staticmem
  xen/arm: unpopulate memory when domain is static
  xen: retrieve reserved pages on populate_physmap

 xen/arch/arm/domain.c |  2 --
 xen/arch/arm/domain_build.c   |  5 ++-
 xen/arch/arm/include/asm/domain.h |  5 +--
 xen/arch/arm/include/asm/mm.h | 12 +++
 xen/common/domain.c   |  7 
 xen/common/memory.c   | 23 +
 xen/common/page_alloc.c   | 54 ---
 xen/include/xen/domain.h  |  6 
 xen/include/xen/mm.h  |  3 +-
 xen/include/xen/sched.h   |  6 
 10 files changed, 112 insertions(+), 11 deletions(-)

-- 
2.25.1

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu7e314198157bf38ae7fdd5a000b8795db015d582
baseline version:
 qemuu554623226f800acf48a2ed568900c1c968ec9a8b

Last test of basis   170256  2022-05-09 01:39:31 Z1 days
Testing same since   170275  2022-05-09 17:08:38 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Brad Smith 
  Gautam Agrawal 
  

[ovmf test] 170284: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 0e31124877cc8bc0140a03ad3196f0d58b2fd966
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   70 days  904 attempts
Testing same since   170272  2022-05-09 15:12:57 Z0 days8 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao Li 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6200 lines long.)

Re: [PATCH 1/3] xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3

[Stefano Stabellini]

On Tue, 3 May 2022, Bertrand Marquis wrote:
> Sync arm64 sysreg bit shift definitions with status of Linux kernel as
> of 5.18-rc3 version (linux commit b2d229d4ddb1).
> Sync ID registers sanitization with the status of Linux 5.18-rc3 and add
> sanitization of ISAR2 registers.
> Complete AA64ISAR2 and AA64MMFR1 with more fields.
> While there add a comment for MMFR bitfields as for other registers in
> the cpuinfo structure definition.
> 
> Signed-off-by: Bertrand Marquis 
> ---
>  xen/arch/arm/arm64/cpufeature.c  | 18 +-
>  xen/arch/arm/include/asm/arm64/sysregs.h | 76 

Linux cpufeature.c has a couple more structures compared to Xen. So I
would add the word "existing" in the commit message:

"Sync existing ID registers sanitization with the status of Linux
5.18-rc3 and add sanitization of ISAR2 registers."

A couple of comments about the cpufeature.h changes below.


>  xen/arch/arm/include/asm/cpufeature.h| 14 -
>  3 files changed, 91 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c
> index 6e5d30dc7b..d9039d37b2 100644
> --- a/xen/arch/arm/arm64/cpufeature.c
> +++ b/xen/arch/arm/arm64/cpufeature.c
> @@ -143,6 +143,16 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
>   ARM64_FTR_END,
>  };
>  
> +static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, 
> ID_AA64ISAR2_CLEARBHB_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
> +FTR_STRICT, FTR_EXACT, ID_AA64ISAR2_APA3_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
> +FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_GPA3_SHIFT, 4, 
> 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, 
> ID_AA64ISAR2_RPRES_SHIFT, 4, 0),
> + ARM64_FTR_END,
> +};
> +
>  static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
>   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
> ID_AA64PFR0_CSV3_SHIFT, 4, 0),
>   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
> ID_AA64PFR0_CSV2_SHIFT, 4, 0),
> @@ -158,8 +168,8 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
>   S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
> ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
>   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
> ID_AA64PFR0_EL3_SHIFT, 4, 0),
>   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
> ID_AA64PFR0_EL2_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
> ID_AA64PFR0_EL1_SHIFT, 4, ID_AA64PFR0_EL1_64BIT_ONLY),
> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
> ID_AA64PFR0_EL0_SHIFT, 4, ID_AA64PFR0_EL0_64BIT_ONLY),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
> ID_AA64PFR0_EL1_SHIFT, 4, ID_AA64PFR0_ELx_64BIT_ONLY),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
> ID_AA64PFR0_EL0_SHIFT, 4, ID_AA64PFR0_ELx_64BIT_ONLY),
>   ARM64_FTR_END,
>  };
>  
> @@ -197,7 +207,7 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
>  };
>  
>  static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
> - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
> ID_AA64MMFR0_ECV_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
> ID_AA64MMFR0_ECV_SHIFT, 4, 0),
>   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
> ID_AA64MMFR0_FGT_SHIFT, 4, 0),
>   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
> ID_AA64MMFR0_EXS_SHIFT, 4, 0),
>   /*
> @@ -243,6 +253,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
>  };
>  
>  static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
> ID_AA64MMFR1_AFP_SHIFT, 4, 0),
>   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
> ID_AA64MMFR1_ETS_SHIFT, 4, 0),
>   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
> ID_AA64MMFR1_TWED_SHIFT, 4, 0),
>   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
> ID_AA64MMFR1_XNX_SHIFT, 4, 0),
> @@ -588,6 +599,7 @@ void update_system_features(const struct cpuinfo_arm *new)
>  
>   SANITIZE_ID_REG(isa64, 0, aa64isar0);
>   SANITIZE_ID_REG(isa64, 1, aa64isar1);
> + SANITIZE_ID_REG(isa64, 2, aa64isar2);
>  
>   SANITIZE_ID_REG(zfr64, 0, aa64zfr0);
>  
> diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h 
> b/xen/arch/arm/include/asm/arm64/sysregs.h
> index eac08ed33f..54670084c3 100644
> --- a/xen/arch/arm/include/asm/arm64/sysregs.h
> +++ b/xen/arch/arm/include/asm/arm64/sysregs.h
> @@ -144,6 +144,30 @@
>  
>  /* id_aa64isar2 */
>  #define ID_AA64ISAR2_CLEARBHB_SHIFT 28
> +#define ID_AA64ISAR2_APA3_SHIFT 12
> +#define ID_AA64ISAR2_GPA3_SHIFT 8
> +#define ID_AA64ISAR2_RPRES_SHIFT4
> +#define ID_AA64ISAR2_WFXT_SHIFT 0
> +

Re: [PATCH 1/3] xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3

[Stefano Stabellini]

On Wed, 4 May 2022, Julien Grall wrote:
> > Do I understand right that it is ok for you if I push one patch mentioning
> > all the commits done in Linux corresponding to the changes (instead of one
> > patch per commit) ?
> 
> For this case yes.

I managed to do a review of the patch by doing a diff of the relevant
portion of Xen cpufeature.c with Linux cpufeature.c (from commit
b2d229d4ddb1), and the relevant portion of Xen sysregs.h with Linux
sysregs.h (diff -E -b -u).

Everything checks out.

In my opinion, this patch should be split in 2 patches: the changes to
cpufeature.c and sysregs.c that come from the Linux sources; and the
updates to cpufeature.h that do not. If you do that you can add my
reviewed-by to the first patch with the changes from Linux.

The list of individual commit IDs would be nice, but thanksfully the two
source files are still "diffable" so in my opinion are not required.

I have a couple of comments on the changes to cpufeature.h (the ones not
from Linux) which I'll reply directly to the patch.

[ovmf test] 170283: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 0e31124877cc8bc0140a03ad3196f0d58b2fd966
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  903 attempts
Testing same since   170272  2022-05-09 15:12:57 Z0 days7 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao Li 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6200 lines long.)

[ovmf test] 170282: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 0e31124877cc8bc0140a03ad3196f0d58b2fd966
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  902 attempts
Testing same since   170272  2022-05-09 15:12:57 Z0 days6 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao Li 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6200 lines long.)

[PATCH v8 23/27] regulator: pfuze100: Use devm_register_sys_off_handler()

[Dmitry Osipenko]

Use devm_register_sys_off_handler() that replaces global
pm_power_off_prepare variable and allows to register multiple
power-off handlers.

Acked-by: Mark Brown 
Signed-off-by: Dmitry Osipenko 
---
 drivers/regulator/pfuze100-regulator.c | 42 +++---
 1 file changed, 17 insertions(+), 25 deletions(-)

diff --git a/drivers/regulator/pfuze100-regulator.c 
b/drivers/regulator/pfuze100-regulator.c
index d60d7d1b7fa2..0322f6b1fb60 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -569,10 +570,10 @@ static inline struct device_node *match_of_node(int index)
return pfuze_matches[index].of_node;
 }
 
-static struct pfuze_chip *syspm_pfuze_chip;
-
-static void pfuze_power_off_prepare(void)
+static int pfuze_power_off_prepare(struct sys_off_data *data)
 {
+   struct pfuze_chip *syspm_pfuze_chip = data->cb_data;
+
dev_info(syspm_pfuze_chip->dev, "Configure standby mode for power off");
 
/* Switch from default mode: APS/APS to APS/Off */
@@ -607,28 +608,30 @@ static void pfuze_power_off_prepare(void)
regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN6VOL,
   PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
   PFUZE100_VGENxSTBY);
+
+   return NOTIFY_DONE;
 }
 
 static int pfuze_power_off_prepare_init(struct pfuze_chip *pfuze_chip)
 {
+   int err;
+
if (pfuze_chip->chip_id != PFUZE100) {
dev_warn(pfuze_chip->dev, "Requested pm_power_off_prepare 
handler for not supported chip\n");
return -ENODEV;
}
 
-   if (pm_power_off_prepare) {
-   dev_warn(pfuze_chip->dev, "pm_power_off_prepare is already 
registered.\n");
-   return -EBUSY;
+   err = devm_register_sys_off_handler(pfuze_chip->dev,
+   SYS_OFF_MODE_POWER_OFF_PREPARE,
+   SYS_OFF_PRIO_DEFAULT,
+   pfuze_power_off_prepare,
+   pfuze_chip);
+   if (err) {
+   dev_err(pfuze_chip->dev, "failed to register sys-off handler: 
%d\n",
+   err);
+   return err;
}
 
-   if (syspm_pfuze_chip) {
-   dev_warn(pfuze_chip->dev, "syspm_pfuze_chip is already set.\n");
-   return -EBUSY;
-   }
-
-   syspm_pfuze_chip = pfuze_chip;
-   pm_power_off_prepare = pfuze_power_off_prepare;
-
return 0;
 }
 
@@ -837,23 +840,12 @@ static int pfuze100_regulator_probe(struct i2c_client 
*client,
return 0;
 }
 
-static int pfuze100_regulator_remove(struct i2c_client *client)
-{
-   if (syspm_pfuze_chip) {
-   syspm_pfuze_chip = NULL;
-   pm_power_off_prepare = NULL;
-   }
-
-   return 0;
-}
-
 static struct i2c_driver pfuze_driver = {
.driver = {
.name = "pfuze100-regulator",
.of_match_table = pfuze_dt_ids,
},
.probe = pfuze100_regulator_probe,
-   .remove = pfuze100_regulator_remove,
 };
 module_i2c_driver(pfuze_driver);
 
-- 
2.35.1

[PATCH v8 12/27] 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 sys-off API.

Acked-by: Catalin Marinas 
Reviewed-by: Michał Mirosław 
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 142a51256669..92bcc1768f0b 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 v8 24/27] reboot: Remove pm_power_off_prepare()

[Dmitry Osipenko]

All pm_power_off_prepare() users were converted to sys-off handler API.
Remove the obsolete global callback variable.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/pm.h |  1 -
 kernel/reboot.c| 19 ---
 2 files changed, 20 deletions(-)

diff --git a/include/linux/pm.h b/include/linux/pm.h
index 70ec69d8bafd..871c9c49ec9d 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -21,7 +21,6 @@
  * Callbacks for platform drivers to implement.
  */
 extern void (*pm_power_off)(void);
-extern void (*pm_power_off_prepare)(void);
 
 struct device; /* we have a circular dep with device.h */
 #ifdef CONFIG_VT_CONSOLE_SLEEP
diff --git a/kernel/reboot.c b/kernel/reboot.c
index e74103f2a801..66033e12e8eb 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -63,13 +63,6 @@ struct sys_off_handler {
  */
 void __weak (*pm_power_off)(void);
 
-/*
- * If set, this is used for preparing the system to power off.
- */
-
-void (*pm_power_off_prepare)(void);
-EXPORT_SYMBOL_GPL(pm_power_off_prepare);
-
 /**
  * emergency_restart - reboot the system
  *
@@ -524,14 +517,6 @@ void unregister_platform_power_off(void (*power_off)(void))
 }
 EXPORT_SYMBOL_GPL(unregister_platform_power_off);
 
-static int legacy_pm_power_off_prepare(struct sys_off_data *data)
-{
-   if (pm_power_off_prepare)
-   pm_power_off_prepare();
-
-   return NOTIFY_DONE;
-}
-
 static int legacy_pm_power_off(struct sys_off_data *data)
 {
if (pm_power_off)
@@ -549,10 +534,6 @@ static int legacy_pm_power_off(struct sys_off_data *data)
  */
 static int __init legacy_pm_init(void)
 {
-   register_sys_off_handler(SYS_OFF_MODE_POWER_OFF_PREPARE,
-SYS_OFF_PRIO_DEFAULT,
-legacy_pm_power_off_prepare, NULL);
-
register_sys_off_handler(SYS_OFF_MODE_POWER_OFF, SYS_OFF_PRIO_DEFAULT,
 legacy_pm_power_off, NULL);
 
-- 
2.35.1

[PATCH v8 17/27] 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 sys-off API.

Reviewed-by: Michał Mirosław 
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 v8 26/27] kernel/reboot: Add devm_register_power_off_handler()

[Dmitry Osipenko]

Add devm_register_power_off_handler() helper that registers sys-off
handler using power-off mode and with a default priority. Most drivers
will want to register power-off handler with a default priority, so this
helper will reduce the boilerplate code and make code easier to read and
follow.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/reboot.h |  4 
 kernel/reboot.c| 22 ++
 2 files changed, 26 insertions(+)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index f185b64faae0..7c6e1f308f7c 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -141,6 +141,10 @@ int devm_register_sys_off_handler(struct device *dev,
  int (*callback)(struct sys_off_data *data),
  void *cb_data);
 
+int devm_register_power_off_handler(struct device *dev,
+   int (*callback)(struct sys_off_data *data),
+   void *cb_data);
+
 int register_platform_power_off(void (*power_off)(void));
 void unregister_platform_power_off(void (*power_off)(void));
 
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 66033e12e8eb..b790025154ac 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -462,6 +462,28 @@ int devm_register_sys_off_handler(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(devm_register_sys_off_handler);
 
+/**
+ * devm_register_power_off_handler - Register power-off handler
+ * @dev: Device that registers callback
+ * @callback: Callback function
+ * @cb_data: Callback's argument
+ *
+ * Registers resource-managed sys-off handler with a default priority
+ * and using power-off mode.
+ *
+ * Returns zero on success, or error code on failure.
+ */
+int devm_register_power_off_handler(struct device *dev,
+   int (*callback)(struct sys_off_data *data),
+   void *cb_data)
+{
+   return devm_register_sys_off_handler(dev,
+SYS_OFF_MODE_POWER_OFF,
+SYS_OFF_PRIO_DEFAULT,
+callback, cb_data);
+}
+EXPORT_SYMBOL_GPL(devm_register_power_off_handler);
+
 static struct sys_off_handler *platform_power_off_handler;
 
 static int platform_power_off_notify(struct sys_off_data *data)
-- 
2.35.1

[PATCH v8 15/27] 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 sys-off API.

Acked-by: Michael Ellerman 
Reviewed-by: Michał Mirosław 
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 b423812e94e0..0300bdfa20d5 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 v8 09/27] 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 sys-off API.

Reviewed-by: Russell King (Oracle) 
Reviewed-by: Michał Mirosław 
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 v8 20/27] mips: 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 sys-off API.

Acked-by: Thomas Bogendoerfer 
Reviewed-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
---
 arch/mips/kernel/reset.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 6288780b779e..e7ce07b3e79b 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -114,8 +114,7 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();
 
 #ifdef CONFIG_SMP
preempt_disable();
-- 
2.35.1

[PATCH v8 25/27] soc/tegra: pmc: Use sys-off handler API to power off Nexus 7 properly

[Dmitry Osipenko]

Nexus 7 Android tablet can be turned off using a special bootloader
command which is conveyed to bootloader by putting magic value into the
special scratch register and then rebooting normally. This power-off
method should be invoked if USB cable is connected. Bootloader then will
display battery status and power off the device. This behaviour is
borrowed from downstream kernel and matches user expectations, otherwise
it looks like device got hung during power-off and it may wake up on
USB disconnect.

Switch PMC driver to sys-off handler API, which provides drivers with
chained power-off callbacks functionality that is required for powering-off
devices properly. It also brings resource-managed API for the restart
handler registration that makes PMC driver code cleaner.

Signed-off-by: Dmitry Osipenko 
---
 drivers/soc/tegra/pmc.c | 87 +
 1 file changed, 62 insertions(+), 25 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index c77ecf61818b..5611d14d3ba2 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -108,6 +109,7 @@
 #define PMC_USB_DEBOUNCE_DEL   0xec
 #define PMC_USB_AO 0xf0
 
+#define PMC_SCRATCH37  0x130
 #define PMC_SCRATCH41  0x140
 
 #define PMC_WAKE2_MASK 0x160
@@ -1101,8 +1103,7 @@ static struct notifier_block tegra_pmc_reboot_notifier = {
.notifier_call = tegra_pmc_reboot_notify,
 };
 
-static int tegra_pmc_restart_notify(struct notifier_block *this,
-   unsigned long action, void *data)
+static void tegra_pmc_restart(void)
 {
u32 value;
 
@@ -1110,14 +,31 @@ static int tegra_pmc_restart_notify(struct 
notifier_block *this,
value = tegra_pmc_readl(pmc, PMC_CNTRL);
value |= PMC_CNTRL_MAIN_RST;
tegra_pmc_writel(pmc, value, PMC_CNTRL);
+}
+
+static int tegra_pmc_restart_handler(struct sys_off_data *data)
+{
+   tegra_pmc_restart();
 
return NOTIFY_DONE;
 }
 
-static struct notifier_block tegra_pmc_restart_handler = {
-   .notifier_call = tegra_pmc_restart_notify,
-   .priority = 128,
-};
+static int tegra_pmc_power_off_handler(struct sys_off_data *data)
+{
+   /*
+* Reboot Nexus 7 into special bootloader mode if USB cable is
+* connected in order to display battery status and power off.
+*/
+   if (of_machine_is_compatible("asus,grouper") &&
+   power_supply_is_system_supplied()) {
+   const u32 go_to_charger_mode = 0xa5a55a5a;
+
+   tegra_pmc_writel(pmc, go_to_charger_mode, PMC_SCRATCH37);
+   tegra_pmc_restart();
+   }
+
+   return NOTIFY_DONE;
+}
 
 static int powergate_show(struct seq_file *s, void *data)
 {
@@ -2879,6 +2897,42 @@ static int tegra_pmc_probe(struct platform_device *pdev)
pmc->clk = NULL;
}
 
+   /*
+* PMC should be last resort for restarting since it soft-resets
+* CPU without resetting everything else.
+*/
+   err = devm_register_reboot_notifier(>dev,
+   _pmc_reboot_notifier);
+   if (err) {
+   dev_err(>dev, "unable to register reboot notifier, %d\n",
+   err);
+   return err;
+   }
+
+   err = devm_register_sys_off_handler(>dev,
+   SYS_OFF_MODE_RESTART,
+   SYS_OFF_PRIO_LOW,
+   tegra_pmc_restart_handler, NULL);
+   if (err) {
+   dev_err(>dev, "failed to register sys-off handler: %d\n",
+   err);
+   return err;
+   }
+
+   /*
+* PMC should be primary power-off method if it soft-resets CPU,
+* asking bootloader to shutdown hardware.
+*/
+   err = devm_register_sys_off_handler(>dev,
+   SYS_OFF_MODE_POWER_OFF,
+   SYS_OFF_PRIO_FIRMWARE,
+   tegra_pmc_power_off_handler, NULL);
+   if (err) {
+   dev_err(>dev, "failed to register sys-off handler: %d\n",
+   err);
+   return err;
+   }
+
/*
 * PCLK clock rate can't be retrieved using CLK API because it
 * causes lockup if CPU enters LP2 idle state from some other
@@ -2910,28 +2964,13 @@ static int tegra_pmc_probe(struct platform_device *pdev)
goto cleanup_sysfs;
}
 
-   err = devm_register_reboot_notifier(>dev,
-   _pmc_reboot_notifier);
-   if (err) {
-   dev_err(>dev, "unable to register reboot notifier, %d\n",
-   err);
-   

[PATCH v8 21/27] memory: emif: Use kernel_can_power_off()

[Dmitry Osipenko]

Replace legacy pm_power_off with kernel_can_power_off() helper that
is aware about chained power-off handlers.

Acked-by: Krzysztof Kozlowski 
Reviewed-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/emif.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 6c2a421b86e3..f305643209f0 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -630,7 +630,7 @@ static irqreturn_t emif_threaded_isr(int irq, void *dev_id)
dev_emerg(emif->dev, "SDRAM temperature exceeds operating 
limit.. Needs shut down!!!\n");
 
/* If we have Power OFF ability, use it, else try restarting */
-   if (pm_power_off) {
+   if (kernel_can_power_off()) {
kernel_power_off();
} else {
WARN(1, "FIXME: NO pm_power_off!!! trying restart\n");
-- 
2.35.1

[PATCH v8 14/27] xen/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 sys-off API.

Acked-by: Juergen Gross 
Reviewed-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
---
 arch/x86/xen/enlighten_pv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 5038edb79ad5..af1f6e886225 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1071,8 +1072,7 @@ static void xen_machine_halt(void)
 
 static void xen_machine_power_off(void)
 {
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();
xen_reboot(SHUTDOWN_poweroff);
 }
 
-- 
2.35.1

[PATCH v8 27/27] kernel/reboot: Add devm_register_restart_handler()

[Dmitry Osipenko]

Add devm_register_restart_handler() helper that registers sys-off
handler using restart mode and with a default priority. Most drivers
will want to register restart handler with a default priority, so this
helper will reduce the boilerplate code and make code easier to read and
follow.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/reboot.h |  4 
 kernel/reboot.c| 22 ++
 2 files changed, 26 insertions(+)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index 7c6e1f308f7c..e5d9ef886179 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -145,6 +145,10 @@ int devm_register_power_off_handler(struct device *dev,
int (*callback)(struct sys_off_data *data),
void *cb_data);
 
+int devm_register_restart_handler(struct device *dev,
+ int (*callback)(struct sys_off_data *data),
+ void *cb_data);
+
 int register_platform_power_off(void (*power_off)(void));
 void unregister_platform_power_off(void (*power_off)(void));
 
diff --git a/kernel/reboot.c b/kernel/reboot.c
index b790025154ac..2e78bd754a75 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -484,6 +484,28 @@ int devm_register_power_off_handler(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(devm_register_power_off_handler);
 
+/**
+ * devm_register_restart_handler - Register restart handler
+ * @dev: Device that registers callback
+ * @callback: Callback function
+ * @cb_data: Callback's argument
+ *
+ * Registers resource-managed sys-off handler with a default priority
+ * and using restart mode.
+ *
+ * Returns zero on success, or error code on failure.
+ */
+int devm_register_restart_handler(struct device *dev,
+ int (*callback)(struct sys_off_data *data),
+ void *cb_data)
+{
+   return devm_register_sys_off_handler(dev,
+SYS_OFF_MODE_RESTART,
+SYS_OFF_PRIO_DEFAULT,
+callback, cb_data);
+}
+EXPORT_SYMBOL_GPL(devm_register_restart_handler);
+
 static struct sys_off_handler *platform_power_off_handler;
 
 static int platform_power_off_notify(struct sys_off_data *data)
-- 
2.35.1

[PATCH v8 22/27] ACPI: power: Switch to sys-off handler API

[Dmitry Osipenko]

Switch to sys-off API that replaces legacy pm_power_off callbacks,
allowing us to remove global pm_* variables and support chaining of
all restart and power-off modes consistently.

Signed-off-by: Dmitry Osipenko 
---
 drivers/acpi/sleep.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index c992e57b2c79..c3e3cee27f01 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -1023,20 +1023,22 @@ static void acpi_sleep_hibernate_setup(void)
 static inline void acpi_sleep_hibernate_setup(void) {}
 #endif /* !CONFIG_HIBERNATION */
 
-static void acpi_power_off_prepare(void)
+static int acpi_power_off_prepare(struct sys_off_data *data)
 {
/* Prepare to power off the system */
acpi_sleep_prepare(ACPI_STATE_S5);
acpi_disable_all_gpes();
acpi_os_wait_events_complete();
+   return NOTIFY_DONE;
 }
 
-static void acpi_power_off(void)
+static int acpi_power_off(struct sys_off_data *data)
 {
/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
pr_debug("%s called\n", __func__);
local_irq_disable();
acpi_enter_sleep_state(ACPI_STATE_S5);
+   return NOTIFY_DONE;
 }
 
 int __init acpi_sleep_init(void)
@@ -1055,8 +1057,14 @@ int __init acpi_sleep_init(void)
 
if (acpi_sleep_state_supported(ACPI_STATE_S5)) {
sleep_states[ACPI_STATE_S5] = 1;
-   pm_power_off_prepare = acpi_power_off_prepare;
-   pm_power_off = acpi_power_off;
+
+   register_sys_off_handler(SYS_OFF_MODE_POWER_OFF_PREPARE,
+SYS_OFF_PRIO_FIRMWARE,
+acpi_power_off_prepare, NULL);
+
+   register_sys_off_handler(SYS_OFF_MODE_POWER_OFF,
+SYS_OFF_PRIO_FIRMWARE,
+acpi_power_off, NULL);
} else {
acpi_no_s5 = true;
}
-- 
2.35.1

[PATCH v8 11/27] 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 sys-off API.

Acked-by: Palmer Dabbelt 
Reviewed-by: Michał Mirosław 
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 v8 13/27] parisc: 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 sys-off API.

Acked-by: Helge Deller  # parisc
Reviewed-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
---
 arch/parisc/kernel/process.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
index a6a2a558fc5b..7c37e09c92da 100644
--- a/arch/parisc/kernel/process.c
+++ b/arch/parisc/kernel/process.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -116,8 +117,7 @@ void machine_power_off(void)
pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
 
/* ipmi_poweroff may have been installed. */
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();

/* It seems we have no way to power the system off via
 * software. The user has to press the button himself. */
-- 
2.35.1

[PATCH v8 19/27] ia64: 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 sys-off API.

Reviewed-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
---
 arch/ia64/kernel/process.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 167b1765bea1..416305e550e2 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -602,8 +603,7 @@ machine_halt (void)
 void
 machine_power_off (void)
 {
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();
machine_halt();
 }
 
-- 
2.35.1

[PATCH v8 16/27] m68k: Switch to new sys-off handler API

[Dmitry Osipenko]

Kernel now supports chained power-off handlers. Use
register_power_off_handler() that registers power-off handlers and
do_kernel_power_off() that invokes chained power-off handlers. Legacy
pm_power_off() will be removed once all drivers will be converted to
the new sys-off API.

Normally arch code should adopt only the do_kernel_power_off() at first,
but m68k is a special case because it uses pm_power_off() "inside out",
i.e. pm_power_off() invokes machine_power_off() [in fact it does nothing],
while it's machine_power_off() that should invoke the pm_power_off(), and
thus, we can't convert platforms to the new API separately. There are only
two platforms changed here, so it's not a big deal.

Acked-by: Geert Uytterhoeven 
Reviewed-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
---
 arch/m68k/emu/natfeat.c | 3 ++-
 arch/m68k/include/asm/machdep.h | 1 -
 arch/m68k/kernel/process.c  | 5 ++---
 arch/m68k/kernel/setup_mm.c | 1 -
 arch/m68k/kernel/setup_no.c | 1 -
 arch/m68k/mac/config.c  | 4 +++-
 6 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/m68k/emu/natfeat.c b/arch/m68k/emu/natfeat.c
index 71b78ecee75c..b19dc00026d9 100644
--- a/arch/m68k/emu/natfeat.c
+++ b/arch/m68k/emu/natfeat.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -90,5 +91,5 @@ void __init nf_init(void)
pr_info("NatFeats found (%s, %lu.%lu)\n", buf, version >> 16,
version & 0x);
 
-   mach_power_off = nf_poweroff;
+   register_platform_power_off(nf_poweroff);
 }
diff --git a/arch/m68k/include/asm/machdep.h b/arch/m68k/include/asm/machdep.h
index 8fd80ef1b77e..8d8c3ee2069f 100644
--- a/arch/m68k/include/asm/machdep.h
+++ b/arch/m68k/include/asm/machdep.h
@@ -24,7 +24,6 @@ extern int (*mach_get_rtc_pll)(struct rtc_pll_info *);
 extern int (*mach_set_rtc_pll)(struct rtc_pll_info *);
 extern void (*mach_reset)( void );
 extern void (*mach_halt)( void );
-extern void (*mach_power_off)( void );
 extern unsigned long (*mach_hd_init) (unsigned long, unsigned long);
 extern void (*mach_hd_setup)(char *, int *);
 extern void (*mach_heartbeat) (int);
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index 221feb0269f1..2cb4a61bcfac 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -67,12 +67,11 @@ void machine_halt(void)
 
 void machine_power_off(void)
 {
-   if (mach_power_off)
-   mach_power_off();
+   do_kernel_power_off();
for (;;);
 }
 
-void (*pm_power_off)(void) = machine_power_off;
+void (*pm_power_off)(void);
 EXPORT_SYMBOL(pm_power_off);
 
 void show_regs(struct pt_regs * regs)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 78ab562beb31..42691abcd908 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -98,7 +98,6 @@ EXPORT_SYMBOL(mach_get_rtc_pll);
 EXPORT_SYMBOL(mach_set_rtc_pll);
 void (*mach_reset)( void );
 void (*mach_halt)( void );
-void (*mach_power_off)( void );
 #ifdef CONFIG_HEARTBEAT
 void (*mach_heartbeat) (int);
 EXPORT_SYMBOL(mach_heartbeat);
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index 5e4104f07a44..00bf82258233 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -55,7 +55,6 @@ int (*mach_hwclk) (int, struct rtc_time*);
 /* machine dependent reboot functions */
 void (*mach_reset)(void);
 void (*mach_halt)(void);
-void (*mach_power_off)(void);
 
 #ifdef CONFIG_M68000
 #if defined(CONFIG_M68328)
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index 65d124ec80bb..382f656c29ea 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -140,7 +141,6 @@ void __init config_mac(void)
mach_hwclk = mac_hwclk;
mach_reset = mac_reset;
mach_halt = mac_poweroff;
-   mach_power_off = mac_poweroff;
 #if IS_ENABLED(CONFIG_INPUT_M68K_BEEP)
mach_beep = mac_mksound;
 #endif
@@ -160,6 +160,8 @@ void __init config_mac(void)
 
if (macintosh_config->ident == MAC_MODEL_IICI)
mach_l2_flush = via_l2_flush;
+
+   register_platform_power_off(mac_poweroff);
 }
 
 
-- 
2.35.1

[PATCH v8 18/27] 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 sys-off API.

Reviewed-by: Michał Mirosław 
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

[PATCH v8 10/27] csky: 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 sys-off API.

Acked-by: Guo Ren 
Reviewed-by: Michał Mirosław 
Signed-off-by: Dmitry Osipenko 
---
 arch/csky/kernel/power.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/csky/kernel/power.c b/arch/csky/kernel/power.c
index 923ee4e381b8..86ee202906f8 100644
--- a/arch/csky/kernel/power.c
+++ b/arch/csky/kernel/power.c
@@ -9,16 +9,14 @@ EXPORT_SYMBOL(pm_power_off);
 void machine_power_off(void)
 {
local_irq_disable();
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();
asm volatile ("bkpt");
 }
 
 void machine_halt(void)
 {
local_irq_disable();
-   if (pm_power_off)
-   pm_power_off();
+   do_kernel_power_off();
asm volatile ("bkpt");
 }
 
-- 
2.35.1

[PATCH v8 08/27] kernel/reboot: Add register_platform_power_off()

[Dmitry Osipenko]

Add platform-level registration helpers that will ease transition of the
arch/platform power-off callbacks to the new sys-off based API, allowing
us to remove the global pm_power_off variable in the future.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/reboot.h |  3 +++
 kernel/reboot.c| 55 ++
 2 files changed, 58 insertions(+)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index c52f77ee4ddd..f185b64faae0 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -141,6 +141,9 @@ int devm_register_sys_off_handler(struct device *dev,
  int (*callback)(struct sys_off_data *data),
  void *cb_data);
 
+int register_platform_power_off(void (*power_off)(void));
+void unregister_platform_power_off(void (*power_off)(void));
+
 /*
  * Architecture independent implemenations of sys_reboot commands.
  */
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 982e58c11ce8..e74103f2a801 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -469,6 +469,61 @@ int devm_register_sys_off_handler(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(devm_register_sys_off_handler);
 
+static struct sys_off_handler *platform_power_off_handler;
+
+static int platform_power_off_notify(struct sys_off_data *data)
+{
+   void (*platform_power_power_off_cb)(void) = data->cb_data;
+
+   platform_power_power_off_cb();
+
+   return NOTIFY_DONE;
+}
+
+/**
+ * register_platform_power_off - Register platform-level power-off callback
+ * @power_off: Power-off callback
+ *
+ * Registers power-off callback that will be called as last step
+ * of the power-off sequence. This callback is expected to be invoked
+ * for the last resort. Only one platform power-off callback is allowed
+ * to be registered at a time.
+ *
+ * Returns zero on success, or error code on failure.
+ */
+int register_platform_power_off(void (*power_off)(void))
+{
+   struct sys_off_handler *handler;
+
+   handler = register_sys_off_handler(SYS_OFF_MODE_POWER_OFF,
+  SYS_OFF_PRIO_PLATFORM,
+  platform_power_off_notify,
+  power_off);
+   if (IS_ERR(handler))
+   return PTR_ERR(handler);
+
+   platform_power_off_handler = handler;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(register_platform_power_off);
+
+/**
+ * unregister_platform_power_off - Unregister platform-level power-off 
callback
+ * @power_off: Power-off callback
+ *
+ * Unregisters previously registered platform power-off callback.
+ */
+void unregister_platform_power_off(void (*power_off)(void))
+{
+   if (platform_power_off_handler &&
+   platform_power_off_handler->cb_data == power_off) {
+   unregister_sys_off_handler(platform_power_off_handler);
+   platform_power_off_handler = NULL;
+   }
+}
+EXPORT_SYMBOL_GPL(unregister_platform_power_off);
+
 static int legacy_pm_power_off_prepare(struct sys_off_data *data)
 {
if (pm_power_off_prepare)
-- 
2.35.1

[PATCH v8 06/27] kernel/reboot: Add stub for pm_power_off

[Dmitry Osipenko]

Add weak stub for the global pm_power_off callback variable. This will
allow us to remove pm_power_off definitions from arch/ code and transition
to the new sys-off based API that will replace the global variable.

Signed-off-by: Dmitry Osipenko 
---
 kernel/reboot.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/reboot.c b/kernel/reboot.c
index 9afa99a32d62..eaede35f45e2 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -57,6 +57,12 @@ struct sys_off_handler {
void *list;
 };
 
+/*
+ * Temporary stub that prevents linkage failure while we're in process
+ * of removing all uses of legacy pm_power_off() around the kernel.
+ */
+void __weak (*pm_power_off)(void);
+
 /*
  * If set, this is used for preparing the system to power off.
  */
-- 
2.35.1

[PATCH v8 05/27] kernel/reboot: Add do_kernel_power_off()

[Dmitry Osipenko]

Add do_kernel_power_off() helper that will remove open-coded pm_power_off
invocations from the architecture code. This is the first step on the way
to remove the global pm_power_off variable, which will allow us to
implement consistent power-off chaining support.

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

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index 05981ef079d8..6b951d68c0c7 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -63,6 +63,8 @@ extern void machine_shutdown(void);
 struct pt_regs;
 extern void machine_crash_shutdown(struct pt_regs *);
 
+void do_kernel_power_off(void);
+
 /*
  * sys-off handler API.
  */
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 2fb0357d9483..9afa99a32d62 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -504,6 +504,19 @@ static void do_kernel_power_off_prepare(void)
blocking_notifier_call_chain(_off_prep_handler_list, 0, NULL);
 }
 
+/**
+ * do_kernel_power_off - Execute kernel power-off handler call chain
+ *
+ * Expected to be called as last step of the power-off sequence.
+ *
+ * Powers off the system immediately if a power-off handler function has
+ * been registered. Otherwise does nothing.
+ */
+void do_kernel_power_off(void)
+{
+   atomic_notifier_call_chain(_off_handler_list, 0, NULL);
+}
+
 /**
  * kernel_power_off - power_off the system
  *
-- 
2.35.1

[PATCH v8 04/27] kernel/reboot: Wrap legacy power-off callbacks into sys-off handlers

[Dmitry Osipenko]

Wrap legacy power-off callbacks into sys-off handlers in order to
support co-existence of both legacy and new callbacks while we're
in process of upgrading legacy callbacks to the new API.

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

diff --git a/kernel/reboot.c b/kernel/reboot.c
index 672a658f21ee..2fb0357d9483 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -463,6 +463,47 @@ int devm_register_sys_off_handler(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(devm_register_sys_off_handler);
 
+static int legacy_pm_power_off_prepare(struct sys_off_data *data)
+{
+   if (pm_power_off_prepare)
+   pm_power_off_prepare();
+
+   return NOTIFY_DONE;
+}
+
+static int legacy_pm_power_off(struct sys_off_data *data)
+{
+   if (pm_power_off)
+   pm_power_off();
+
+   return NOTIFY_DONE;
+}
+
+/*
+ * Register sys-off handlers for legacy PM callbacks. This allows legacy
+ * PM callbacks co-exist with the new sys-off API.
+ *
+ * TODO: Remove legacy handlers once all legacy PM users will be switched
+ *   to the sys-off based APIs.
+ */
+static int __init legacy_pm_init(void)
+{
+   register_sys_off_handler(SYS_OFF_MODE_POWER_OFF_PREPARE,
+SYS_OFF_PRIO_DEFAULT,
+legacy_pm_power_off_prepare, NULL);
+
+   register_sys_off_handler(SYS_OFF_MODE_POWER_OFF, SYS_OFF_PRIO_DEFAULT,
+legacy_pm_power_off, NULL);
+
+   return 0;
+}
+core_initcall(legacy_pm_init);
+
+static void do_kernel_power_off_prepare(void)
+{
+   blocking_notifier_call_chain(_off_prep_handler_list, 0, NULL);
+}
+
 /**
  * kernel_power_off - power_off the system
  *
@@ -471,8 +512,7 @@ EXPORT_SYMBOL_GPL(devm_register_sys_off_handler);
 void kernel_power_off(void)
 {
kernel_shutdown_prepare(SYSTEM_POWER_OFF);
-   if (pm_power_off_prepare)
-   pm_power_off_prepare();
+   do_kernel_power_off_prepare();
migrate_to_reboot_cpu();
syscore_shutdown();
pr_emerg("Power down\n");
-- 
2.35.1

[PATCH v8 03/27] kernel/reboot: Introduce sys-off handler API

[Dmitry Osipenko]

In order to support power-off chaining we need to get rid of the global
pm_* variables, replacing them with the new kernel API functions that
support chaining.

Introduce new generic sys-off handler API that brings the following
features:

1. Power-off and restart handlers are registered using same API function
   that supports chaining, hence all power-off and restart modes will
   support chaining using this unified function.

2. Prevents notifier priority collisions by disallowing registration of
   multiple handlers at the non-default priority level.

3. Supports passing opaque user argument to callback, which allows us to
   remove global variables from drivers.

This patch adds support of the following sys-off modes:

- SYS_OFF_MODE_POWER_OFF_PREPARE that replaces global pm_power_off_prepare
  variable and provides chaining support for power-off-prepare handlers.

- SYS_OFF_MODE_POWER_OFF that replaces global pm_power_off variable and
  provides chaining support for power-off handlers.

- SYS_OFF_MODE_RESTART that provides a better restart API, removing a need
  from drivers to have a global scratch variable by utilizing the opaque
  callback argument.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/reboot.h |  77 +
 kernel/reboot.c| 182 +
 2 files changed, 259 insertions(+)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index a2429648d831..05981ef079d8 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -7,6 +7,7 @@
 #include 
 
 struct device;
+struct sys_off_handler;
 
 #define SYS_DOWN   0x0001  /* Notify of system down */
 #define SYS_RESTARTSYS_DOWN
@@ -62,6 +63,82 @@ extern void machine_shutdown(void);
 struct pt_regs;
 extern void machine_crash_shutdown(struct pt_regs *);
 
+/*
+ * sys-off handler API.
+ */
+
+/*
+ * Standard sys-off priority levels. Users are expected to set priorities
+ * relative to the standard levels.
+ *
+ * SYS_OFF_PRIO_PLATFORM:  Use this for platform-level handlers.
+ *
+ * SYS_OFF_PRIO_LOW:   Use this for handler of last resort.
+ *
+ * SYS_OFF_PRIO_DEFAULT:   Use this for normal handlers.
+ *
+ * SYS_OFF_PRIO_HIGH:  Use this for higher priority handlers.
+ *
+ * SYS_OFF_PRIO_FIRMWARE:  Use this if handler uses firmware call.
+ */
+#define SYS_OFF_PRIO_PLATFORM  -256
+#define SYS_OFF_PRIO_LOW   -128
+#define SYS_OFF_PRIO_DEFAULT   0
+#define SYS_OFF_PRIO_HIGH  192
+#define SYS_OFF_PRIO_FIRMWARE  224
+
+enum sys_off_mode {
+   /**
+* @SYS_OFF_MODE_POWER_OFF_PREPARE:
+*
+* Handlers prepare system to be powered off. Handlers are
+* allowed to sleep.
+*/
+   SYS_OFF_MODE_POWER_OFF_PREPARE,
+
+   /**
+* @SYS_OFF_MODE_POWER_OFF:
+*
+* Handlers power-off system. Handlers are disallowed to sleep.
+*/
+   SYS_OFF_MODE_POWER_OFF,
+
+   /**
+* @SYS_OFF_MODE_RESTART:
+*
+* Handlers restart system. Handlers are disallowed to sleep.
+*/
+   SYS_OFF_MODE_RESTART,
+};
+
+/**
+ * struct sys_off_data - sys-off callback argument
+ *
+ * @mode: Mode ID. Currently used only by the sys-off restart mode,
+ *see enum reboot_mode for the available modes.
+ * @cb_data: User's callback data.
+ * @cmd: Command string. Currently used only by the sys-off restart mode,
+ *   NULL otherwise.
+ */
+struct sys_off_data {
+   int mode;
+   void *cb_data;
+   const char *cmd;
+};
+
+struct sys_off_handler *
+register_sys_off_handler(enum sys_off_mode mode,
+int priority,
+int (*callback)(struct sys_off_data *data),
+void *cb_data);
+void unregister_sys_off_handler(struct sys_off_handler *handler);
+
+int devm_register_sys_off_handler(struct device *dev,
+ enum sys_off_mode mode,
+ int priority,
+ int (*callback)(struct sys_off_data *data),
+ void *cb_data);
+
 /*
  * Architecture independent implemenations of sys_reboot commands.
  */
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 8ce30fa0a104..672a658f21ee 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -48,6 +48,15 @@ int reboot_cpu;
 enum reboot_type reboot_type = BOOT_ACPI;
 int reboot_force;
 
+struct sys_off_handler {
+   struct notifier_block nb;
+   int (*sys_off_cb)(struct sys_off_data *data);
+   void *cb_data;
+   enum sys_off_mode mode;
+   bool blocking;
+   void *list;
+};
+
 /*
  * If set, this is used for preparing the system to power off.
  */
@@ -281,6 +290,179 @@ void kernel_halt(void)
 }
 EXPORT_SYMBOL_GPL(kernel_halt);
 
+/*
+ * Notifier list for kernel code which wants to be called
+ * to prepare system for power off.
+ */
+static 

[PATCH v8 07/27] kernel/reboot: Add kernel_can_power_off()

[Dmitry Osipenko]

Add kernel_can_power_off() helper that replaces open-coded checks of
the global pm_power_off variable. This is a necessary step towards
supporting chained power-off handlers.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/reboot.h |  1 +
 kernel/reboot.c| 14 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index 6b951d68c0c7..c52f77ee4ddd 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -149,6 +149,7 @@ extern void kernel_restart_prepare(char *cmd);
 extern void kernel_restart(char *cmd);
 extern void kernel_halt(void);
 extern void kernel_power_off(void);
+extern bool kernel_can_power_off(void);
 
 void ctrl_alt_del(void);
 
diff --git a/kernel/reboot.c b/kernel/reboot.c
index eaede35f45e2..982e58c11ce8 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -523,6 +523,18 @@ void do_kernel_power_off(void)
atomic_notifier_call_chain(_off_handler_list, 0, NULL);
 }
 
+/**
+ * kernel_can_power_off - check whether system can be powered off
+ *
+ * Returns true if power-off handler is registered and system can be
+ * powered off, false otherwise.
+ */
+bool kernel_can_power_off(void)
+{
+   return !atomic_notifier_call_chain_is_empty(_off_handler_list);
+}
+EXPORT_SYMBOL_GPL(kernel_can_power_off);
+
 /**
  * kernel_power_off - power_off the system
  *
@@ -581,7 +593,7 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned 
int, cmd,
/* Instead of trying to make the power_off code look like
 * halt when pm_power_off is not set do it the easy way.
 */
-   if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !pm_power_off)
+   if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !kernel_can_power_off())
cmd = LINUX_REBOOT_CMD_HALT;
 
mutex_lock(_transition_mutex);
-- 
2.35.1

[PATCH v8 01/27] notifier: Add atomic_notifier_call_chain_is_empty()

[Dmitry Osipenko]

Add atomic_notifier_call_chain_is_empty() that returns true if given
atomic call chain is empty.

Reviewed-by: Michał Mirosław 
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..95e2440037de 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 atomic_notifier_call_chain_is_empty(struct atomic_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..aaf5b56452a6 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -204,6 +204,19 @@ int atomic_notifier_call_chain(struct atomic_notifier_head 
*nh,
 EXPORT_SYMBOL_GPL(atomic_notifier_call_chain);
 NOKPROBE_SYMBOL(atomic_notifier_call_chain);
 
+/**
+ * atomicnotifier_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 atomic_notifier_call_chain_is_empty(struct atomic_notifier_head *nh)
+{
+   return !rcu_access_pointer(nh->head);
+}
+
 /*
  * Blocking notifier chain routines.  All access to the chain is
  * synchronized by an rwsem.
-- 
2.35.1

[PATCH v8 02/27] notifier: Add blocking/atomic_notifier_chain_register_unique_prio()

[Dmitry Osipenko]

Add variant of blocking/atomic_notifier_chain_register() functions that
allow registration of a notifier only if it has unique priority, otherwise
-EBUSY error code is returned by the new functions.

Reviewed-by: Michał Mirosław 
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 95e2440037de..aef88c2d1173 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 aaf5b56452a6..684fe04f5f70 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(>lock, flags);
-   ret = notifier_chain_register(>head, n);
+   ret = notifier_chain_register(>head, n, false);
spin_unlock_irqrestore(>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(>lock, flags);
+   ret = notifier_chain_register(>head, n, true);
+   spin_unlock_irqrestore(>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
@@ -222,18 +248,9 @@ bool atomic_notifier_call_chain_is_empty(struct 
atomic_notifier_head *nh)
  * 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;
 
@@ -243,15 +260,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(>head, n);
+   return notifier_chain_register(>head, n, unique_priority);
 
down_write(>rwsem);
-   ret = notifier_chain_register(>head, n);
+   ret = notifier_chain_register(>head, n, unique_priority);
up_write(>rwsem);
return ret;
 }
+
+/**
+ * blocking_notifier_chain_register - Add notifier to a 

[PATCH v8 00/27] Introduce power-off+restart call chain API

[Dmitry Osipenko]

Problem
---

SoC devices require power-off call chaining functionality from kernel.
We have a widely used restart chaining provided by restart notifier API,
but nothing for power-off.

Solution


Introduce new API that provides call chains support for all restart and
power-off modes. The new API is designed with simplicity and extensibility
in mind.

This is a third attempt to introduce the new API. First was made by
Guenter Roeck back in 2014, second was made by Thierry Reding in 2017.
In fact the work didn't stop and recently arm_pm_restart() was removed
from v5.14 kernel, which was a part of preparatory work started by
Guenter Roeck.

Adoption plan
-

This patchset introduces the new API. It also converts multiple drivers
and arch code to the new API to demonstrate how it all looks in practice,
removing the pm_power_off_prepare global variable.

The plan is:

1. Merge the new API and convert arch code to use do_kernel_power_off().
   For now the new API will co-exist with the older API.

2. Convert all drivers and platform code to the new API.

3. Remove obsoleted pm_power_off and pm_power_off_prepare variables.

Results
---

1. Devices can be powered off properly.

2. Global variables are removed from drivers.

3. Global pm_power_off and pm_power_off_prepare callback variables are
removed once all users are converted to the new API. The latter callback
is removed by patch #24 of this series.

4. Ambiguous call chain ordering is prohibited for non-default priorities.

Changelog:

v8: - Reworked sys-off handler like was suggested by Rafael Wysocki in
  the comments to v7.

- The struct sys-off handler now is private to kernel/reboot.c and
  new API is simplified.

- There is a single sys-off API function for all handler types.
  Users shall pass the required sys-off mode type (restart, power-off
  and etc).

- There is single struct sys_off_data callback argument for all
  handler modes.

- User's callback now must return NOTIFY_DONE or NOTIFY_STOP.

- The default priority level is zero now.

- Multiple handlers now allowed to be registered at the default
  priority level.

- Power-off call chain is atomic now, like the restart chain.

- kernel/reboot.c changes are split up into several logical patches.

- Added r-b from Michał Mirosław to unmodified patches from v7.

- Added acks that were missing in v7 by accident.

v7: - Rebased on a recent linux-next. Dropped the recently removed
  NDS32 architecture. Only SH and x86 arches left un-acked.

- Added acks from Thomas Bogendoerfer and Krzysztof Kozlowski
  to the MIPS and memory/emif patches respectively.

- Made couple minor cosmetic improvements to the new API.

- A month ago I joined Collabora and continuing to work on this series
  on the company's time, so changed my email address to collabora.com

v6: - Rebased on a recent linux-next.

- Made minor couple cosmetic changes.

v5: - Dropped patches which cleaned up notifier/reboot headers, as was
  requested by Rafael Wysocki.

- Dropped WARN_ON() from the code, as was requested by Rafael Wysocki.
  Replaced it with pr_err() appropriately.

- Dropped *_notifier_has_unique_priority() functions and added
  *_notifier_chain_register_unique_prio() instead, as was suggested
  by Michał Mirosław and Rafael Wysocki.

- Dropped export of blocking_notifier_call_chain_is_empty() symbol,
  as was suggested by Rafael Wysocki.

- Michał Mirosław suggested that will be better to split up patch
  that adds the new API to ease reviewing, but Rafael Wysocki asked
  not add more patches, so I kept it as a single patch.

- Added temporary "weak" stub for pm_power_off() which fixes linkage
  failure once symbol is removed from arch/* code. Previously I missed
  this problem because was only compile-testing object files.

v4: - Made a very minor improvement to doc comments, clarifying couple
  default values.

- Corrected list of emails recipient by adding Linus, Sebastian,
  Philipp and more NDS people. Removed bouncing emails.

- Added acks that were given to v3.

v3: - Renamed power_handler to sys_off_handler as was suggested by
  Rafael Wysocki.

- Improved doc-comments as was suggested by Rafael Wysocki. Added more
  doc-comments.

- Implemented full set of 180 patches which convert whole kernel in
  accordance to the plan, see link [1] above. Slightly adjusted API to
  better suit for the remaining converted drivers.

  * Added unregister_sys_off_handler() that is handy for a couple old
platform drivers.

  * Dropped devm_register_trivial_restart_handler(), 'simple' variant
is enough to have.

- Improved "Add atomic/blocking_notifier_has_unique_priority()" patch,
  as was suggested by Andy Shevchenko. Also replaced down_write() with
  down_read() and factored out 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux9be9ed2612b5aedb52a2c240edb1630b6b743cb6
baseline version:
 linuxc5eb0a61238dd6faf37f58c9ce61c9980aaffd7a

Last test of basis   170252  2022-05-08 23:11:10 Z0 days
Testing same since   170273  2022-05-09 16:11:07 Z0 days1 attempts


People who touched revisions under test:
  David Arcari 
  Hans de Goede 
  Linus Torvalds 
  Mario Limonciello 
  Mark Pearson 
  Mark Pearson 
  Maximilian Luz 
  Prarit Bhargava 

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

[ovmf test] 170279: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 0e31124877cc8bc0140a03ad3196f0d58b2fd966
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  901 attempts
Testing same since   170272  2022-05-09 15:12:57 Z0 days5 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao Li 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6200 lines long.)

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

[osstest service owner]

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

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  95604873ccf56eb81e96ed0dc8b4dec3278f40ca
baseline version:
 xen  b7e0d8978810b534725e94a321736496928f00a5

Last test of basis   170186  2022-05-06 17:03:05 Z3 days
Testing same since   170278  2022-05-09 19:01:55 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Julien Grall 
  Rahul Singh 

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
   b7e0d89788..95604873cc  95604873ccf56eb81e96ed0dc8b4dec3278f40ca -> smoke

Re: [PATCH V2 5/7] dt-bindings: Add xen, dev-domid property description for xen-grant DMA ops

[Stefano Stabellini]

On Sat, 7 May 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko 
> 
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
> 
> This binding indicates that Xen grant mappings scheme needs to be
> enabled for the device which DT node contains that property and specifies
> the ID of Xen domain where the corresponding backend resides. The ID
> (domid) is used as an argument to the grant mapping APIs.
> 
> This is needed for the option to restrict memory access using Xen grant
> mappings to work which primary goal is to enable using virtio devices
> in Xen guests.
> 
> Signed-off-by: Oleksandr Tyshchenko 

The binding is OK and the wording is OK too.

Reviewed-by: Stefano Stabellini 

I am not an expert on the details of writing a good schema, I'll defer
to Rob if he has any comments on that.


> ---
> Changes RFC -> V1:
>- update commit subject/description and text in description
>- move to devicetree/bindings/arm/
> 
> Changes V1 -> V2:
>- update text in description
>- change the maintainer of the binding
>- fix validation issue
>- reference xen,dev-domid.yaml schema from virtio/mmio.yaml
> ---
>  .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 
> ++
>  Documentation/devicetree/bindings/virtio/mmio.yaml |  7 
>  2 files changed, 44 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml 
> b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> new file mode 100644
> index ..750e89e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xen specific binding for virtualized devices (e.g. virtio)
> +
> +maintainers:
> +  - Stefano Stabellini 
> +
> +select: true
> +
> +description:
> +  This binding indicates that Xen grant mappings need to be enabled for
> +  the device, and it specifies the ID of the domain where the corresponding
> +  device (backend) resides. The property is required to restrict memory
> +  access using Xen grant mappings.
> +
> +properties:
> +  xen,dev-domid:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description:
> +  The domid (domain ID) of the domain where the device (backend) is 
> running.
> +
> +additionalProperties: true
> +
> +examples:
> +  - |
> +virtio@3000 {
> +compatible = "virtio,mmio";
> +reg = <0x3000 0x100>;
> +interrupts = <41>;
> +
> +/* The device is located in Xen domain with ID 1 */
> +xen,dev-domid = <1>;
> +};
> diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml 
> b/Documentation/devicetree/bindings/virtio/mmio.yaml
> index 10c22b5..29a0932 100644
> --- a/Documentation/devicetree/bindings/virtio/mmio.yaml
> +++ b/Documentation/devicetree/bindings/virtio/mmio.yaml
> @@ -13,6 +13,9 @@ description:
>See https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio for
>more details.
>  
> +allOf:
> +  - $ref: /schemas/arm/xen,dev-domid.yaml#
> +
>  properties:
>compatible:
>  const: virtio,mmio
> @@ -33,6 +36,10 @@ properties:
>  description: Required for devices making accesses thru an IOMMU.
>  maxItems: 1
>  
> +  xen,dev-domid:
> +description: Required when Xen grant mappings need to be enabled for 
> device.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +
>  required:
>- compatible
>- reg
> -- 
> 2.7.4
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [PATCH V2 6/7] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices

[Stefano Stabellini]

On Sat, 7 May 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko 
> 
> Use the presence of recently introduced "xen,dev-domid" property
> in the device node as a clear indicator of enabling Xen grant
> mappings scheme for that device and read the ID of Xen domain where
> the corresponding backend resides. The ID (domid) is used as
> an argument to the Xen grant mapping APIs.
> 
> Also introduce xen_is_grant_dma_device() to check whether xen-grant
> DMA ops need to be set for a passed device.
> 
> Remove the hardcoded domid 0 in xen_grant_setup_dma_ops().
> 
> Signed-off-by: Oleksandr Tyshchenko 

Reviewed-by: Stefano Stabellini 


> ---
> Changes RFC -> V1:
>- new patch, split required changes from commit:
> "[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
>- update checks in xen_virtio_setup_dma_ops() to only support
>  DT devices for now
>- remove the "virtio,mmio" check from xen_is_virtio_device()
>- remane everything according to the new naming scheme:
>  s/virtio/grant_dma
> 
> Changes V1 -> V2:
>- remove dev_is_pci() check in xen_grant_setup_dma_ops()
>- remove EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
> ---
>  drivers/xen/grant-dma-ops.c | 24 +---
>  include/xen/xen-ops.h   |  5 +
>  2 files changed, 22 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
> index 29ad7bf..8924178 100644
> --- a/drivers/xen/grant-dma-ops.c
> +++ b/drivers/xen/grant-dma-ops.c
> @@ -55,11 +55,6 @@ static struct xen_grant_dma_data 
> *find_xen_grant_dma_data(struct device *dev)
>   * Such a DMA address is formed by using the grant reference as a frame
>   * number and setting the highest address bit (this bit is for the backend
>   * to be able to distinguish it from e.g. a mmio address).
> - *
> - * Note that for now we hard wire dom0 to be the backend domain. In order
> - * to support any domain as backend we'd need to add a way to communicate
> - * the domid of this backend, e.g. via Xenstore, via the PCI-device's
> - * config space or DT/ACPI.
>   */
>  static void *xen_grant_dma_alloc(struct device *dev, size_t size,
>dma_addr_t *dma_handle, gfp_t gfp,
> @@ -275,6 +270,15 @@ static const struct dma_map_ops xen_grant_dma_ops = {
>   .dma_supported = xen_grant_dma_supported,
>  };
>  
> +bool xen_is_grant_dma_device(struct device *dev)
> +{
> + /* XXX Handle only DT devices for now */
> + if (!dev->of_node)
> + return false;
> +
> + return of_property_read_bool(dev->of_node, "xen,dev-domid");
> +}
> +
>  void xen_grant_setup_dma_ops(struct device *dev)
>  {
>   struct xen_grant_dma_data *data;
> @@ -286,8 +290,14 @@ void xen_grant_setup_dma_ops(struct device *dev)
>   return;
>   }
>  
> - /* XXX The dom0 is hardcoded as the backend domain for now */
> - dev_domid = 0;
> + /* XXX ACPI device unsupported for now */
> + if (!dev->of_node)
> + goto err;
> +
> + if (of_property_read_u32(dev->of_node, "xen,dev-domid", _domid)) {
> + dev_err(dev, "xen,dev-domid property is not present\n");
> + goto err;
> + }
>  
>   data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>   if (!data)
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 4f9fad5..62be9dc 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -223,10 +223,15 @@ static inline void xen_preemptible_hcall_end(void) { }
>  
>  #ifdef CONFIG_XEN_GRANT_DMA_OPS
>  void xen_grant_setup_dma_ops(struct device *dev);
> +bool xen_is_grant_dma_device(struct device *dev);
>  #else
>  static inline void xen_grant_setup_dma_ops(struct device *dev)
>  {
>  }
> +static inline bool xen_is_grant_dma_device(struct device *dev)
> +{
> + return false;
> +}
>  #endif /* CONFIG_XEN_GRANT_DMA_OPS */
>  
>  #endif /* INCLUDE_XEN_OPS_H */
> -- 
> 2.7.4
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [PATCH V2 3/7] xen/grant-dma-ops: Add option to restrict memory access under Xen

[Stefano Stabellini]

On Sat, 7 May 2022, Oleksandr Tyshchenko wrote:
> From: Juergen Gross 
> 
> Introduce Xen grant DMA-mapping layer which contains special DMA-mapping
> routines for providing grant references as DMA addresses to be used by
> frontends (e.g. virtio) in Xen guests.
> 
> Add the needed functionality by providing a special set of DMA ops
> handling the needed grant operations for the I/O pages.
> 
> The subsequent commit will introduce the use case for xen-grant DMA ops
> layer to enable using virtio devices in Xen guests in a safe manner.
> 
> Signed-off-by: Juergen Gross 
> Signed-off-by: Oleksandr Tyshchenko 

Reviewed-by: Stefano Stabellini 


> ---
> Changes RFC -> V1:
>- squash with almost all changes from commit (except handling 
> "xen,dev-domid"
>  property):
>  "[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
>- update commit subject/description and comments in code
>- leave only single Kconfig option XEN_VIRTIO and remove architectural
>  dependencies
>- introduce common xen_has_restricted_virtio_memory_access() in xen.h
>  and update arch_has_restricted_virtio_memory_access() for both
>  Arm and x86 to call new helper
>- use (1ULL << 63) instead of 0x8000ULL for XEN_GRANT_ADDR_OFF
>- implement xen_virtio_dma_map(unmap)_sg() using example in swiotlb-xen.c
>- optimize padding by moving "broken" field in struct xen_virtio_data
>- remove unneeded per-device spinlock
>- remove the inclusion of virtio_config.h
>- remane everything according to the new naming scheme:
>  s/virtio/grant_dma
>- add new hidden config option XEN_GRANT_DMA_OPS
> 
> Changes V1 -> V2:
>- fix checkpatch.pl warnings
>- remove the inclusion of linux/pci.h
>- rework to use xarray for data context
>- remove EXPORT_SYMBOL_GPL(xen_grant_setup_dma_ops);
>- remove the line of * after SPDX-License-Identifier
>- split changes into grant-dma-ops.c and 
> arch_has_restricted_virtio_memory_access()
>  and update commit subject/description accordingly
>- remove "default n" for config XEN_VIRTIO
>- implement xen_grant_dma_alloc(free)_pages()
> ---
>  drivers/xen/Kconfig |   4 +
>  drivers/xen/Makefile|   1 +
>  drivers/xen/grant-dma-ops.c | 314 
> 
>  include/xen/xen-ops.h   |   8 ++
>  4 files changed, 327 insertions(+)
>  create mode 100644 drivers/xen/grant-dma-ops.c
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 120d32f..313a9127 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -335,4 +335,8 @@ config XEN_UNPOPULATED_ALLOC
> having to balloon out RAM regions in order to obtain physical memory
> space to create such mappings.
>  
> +config XEN_GRANT_DMA_OPS
> + bool
> + select DMA_OPS
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 5aae66e..1a23cb0 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -39,3 +39,4 @@ xen-gntalloc-y  := gntalloc.o
>  xen-privcmd-y:= privcmd.o privcmd-buf.o
>  obj-$(CONFIG_XEN_FRONT_PGDIR_SHBUF)  += xen-front-pgdir-shbuf.o
>  obj-$(CONFIG_XEN_UNPOPULATED_ALLOC)  += unpopulated-alloc.o
> +obj-$(CONFIG_XEN_GRANT_DMA_OPS)  += grant-dma-ops.o
> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
> new file mode 100644
> index ..29ad7bf
> --- /dev/null
> +++ b/drivers/xen/grant-dma-ops.c
> @@ -0,0 +1,314 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Xen grant DMA-mapping layer - contains special DMA-mapping routines
> + * for providing grant references as DMA addresses to be used by frontends
> + * (e.g. virtio) in Xen guests
> + *
> + * Copyright (c) 2021, Juergen Gross 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct xen_grant_dma_data {
> + /* The ID of backend domain */
> + domid_t dev_domid;
> + /* Is device behaving sane? */
> + bool broken;
> +};
> +
> +static DEFINE_XARRAY(xen_grant_dma_devices);
> +
> +#define XEN_GRANT_DMA_ADDR_OFF   (1ULL << 63)
> +
> +static inline dma_addr_t grant_to_dma(grant_ref_t grant)
> +{
> + return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant << PAGE_SHIFT);
> +}
> +
> +static inline grant_ref_t dma_to_grant(dma_addr_t dma)
> +{
> + return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >> PAGE_SHIFT);
> +}
> +
> +static struct xen_grant_dma_data *find_xen_grant_dma_data(struct device *dev)
> +{
> + struct xen_grant_dma_data *data;
> +
> + xa_lock(_grant_dma_devices);
> + data = xa_load(_grant_dma_devices, (unsigned long)dev);
> + xa_unlock(_grant_dma_devices);
> +
> + return data;
> +}
> +
> +/*
> + * DMA ops for Xen frontends (e.g. virtio).
> + *
> + * Used to act as a kind of software IOMMU for Xen guests by using grants as
> + * DMA addresses.
> + * 

Re: [PATCH V2 4/7] xen/virtio: Enable restricted memory access using Xen grant mappings

[Stefano Stabellini]

On Sat, 7 May 2022, Oleksandr Tyshchenko wrote:
> From: Juergen Gross 
> 
> In order to support virtio in Xen guests add a config option XEN_VIRTIO
> enabling the user to specify whether in all Xen guests virtio should
> be able to access memory via Xen grant mappings only on the host side.
> 
> Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest
> initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled.
> 
> Signed-off-by: Juergen Gross 
> Signed-off-by: Oleksandr Tyshchenko 

The patch looks OK to me

Reviewed-by: Stefano Stabellini 


> ---
> Changes V1 -> V2:
>- new patch, split required changes from commit:
> "[PATCH V1 3/6] xen/virtio: Add option to restrict memory access under 
> Xen"
>- rework according to new platform_has() infrastructure
> ---
>  arch/arm/xen/enlighten.c |  2 ++
>  arch/x86/xen/enlighten_hvm.c |  2 ++
>  arch/x86/xen/enlighten_pv.c  |  2 ++
>  drivers/xen/Kconfig  | 11 +++
>  include/xen/xen.h|  8 
>  5 files changed, 25 insertions(+)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 07eb69f..1f9c3ba 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -443,6 +443,8 @@ static int __init xen_guest_init(void)
>   if (!xen_domain())
>   return 0;
>  
> + xen_set_restricted_virtio_memory_access();
> +
>   if (!acpi_disabled)
>   xen_acpi_guest_init();
>   else
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> index 517a9d8..8b71b1d 100644
> --- a/arch/x86/xen/enlighten_hvm.c
> +++ b/arch/x86/xen/enlighten_hvm.c
> @@ -195,6 +195,8 @@ static void __init xen_hvm_guest_init(void)
>   if (xen_pv_domain())
>   return;
>  
> + xen_set_restricted_virtio_memory_access();
> +
>   init_hvm_pv_info();
>  
>   reserve_shared_info();
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 5038edb..fcd5d5d 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -109,6 +109,8 @@ static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
>  
>  static void __init xen_pv_init_platform(void)
>  {
> + xen_set_restricted_virtio_memory_access();
> +
>   populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
>  
>   set_fixmap(FIX_PARAVIRT_BOOTMAP, xen_start_info->shared_info);
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 313a9127..a7bd8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -339,4 +339,15 @@ config XEN_GRANT_DMA_OPS
>   bool
>   select DMA_OPS
>  
> +config XEN_VIRTIO
> + bool "Xen virtio support"
> + depends on VIRTIO
> + select XEN_GRANT_DMA_OPS
> + help
> +   Enable virtio support for running as Xen guest. Depending on the
> +   guest type this will require special support on the backend side
> +   (qemu or kernel, depending on the virtio device types used).
> +
> +   If in doubt, say n.
> +
>  endmenu
> diff --git a/include/xen/xen.h b/include/xen/xen.h
> index a99bab8..0780a81 100644
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -52,6 +52,14 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
>  extern u64 xen_saved_max_mem_size;
>  #endif
>  
> +#include 
> +
> +static inline void xen_set_restricted_virtio_memory_access(void)
> +{
> + if (IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain())
> + platform_set(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS);
> +}
> +
>  #ifdef CONFIG_XEN_UNPOPULATED_ALLOC
>  int xen_alloc_unpopulated_pages(unsigned int nr_pages, struct page **pages);
>  void xen_free_unpopulated_pages(unsigned int nr_pages, struct page **pages);

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

[Stefano Stabellini]

On Wed, 4 May 2022, Rahul Singh wrote:
> This patch introduces a new feature to support the signaling between
> two domains in dom0less system.
> 
> Signed-off-by: Rahul Singh 
> ---
> v2 changes:
> - switch to the one-subnode-per-evtchn under xen,domain" compatible node.
> - Add more detail about event-channel 
> ---
>  docs/designs/dom0less-evtchn.md | 126 
>  1 file changed, 126 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..62ec8a4009
> --- /dev/null
> +++ b/docs/designs/dom0less-evtchn.md
> @@ -0,0 +1,126 @@
> +# Signaling support between two domUs on dom0less system
> +
> +## Current state:???Draft version

Something went wrong with the encoding of this email. Aside from that
the proposal looks good to me. Thanks Rahul!

Reviewed-by: Stefano Stabellini 


> +## Proposer(s): Rahul Singh, Bertrand Marquis
> +
> +## Problem Statement:
> +
> +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 the data center 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
> +for 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). Each event has a pending and a masked 
> bit.
> +The pending bit indicates the event has been raised. The masked bit is used 
> by
> +the domain to prevent the delivery of that specific event. Xen only performs 
> a
> +0 ??? 1 transition on the pending bits and does not touch the mask bit. The
> +domain may toggle masked bits in the masked bit field and should clear the
> +pending bit when an event has been processed
> +
> +Events are received by a domain via an interrupt from Xen to the domain,
> +indicating when an event arrives (setting the bit). Further notifications are
> +blocked until the bit is cleared again. Events are delivered asynchronously 
> to
> +a domain and are enqueued when the domain is not running.
> +More information about FIFO based event channel can be found at:
> +https://xenbits.xen.org/people/dvrabel/event-channels-H.pdf
> +
> +The event channel communication will be established statically between two
> +domains (dom0 and domU also) before unpausing the domains after domain 
> creation.
> +Event channel connection information between domains will be passed to XEN 
> via
> +the device tree node. The event channel will be created and established
> +beforehand in XEN before the domain started. The domain doesn???t need to do 
> any
> +operation to establish a connection. Domain only needs hypercall
> +EVTCHNOP_send(local port) to send notifications to the remote guest.
> +
> +There is no need to describe the static event channel info in the domU device
> +tree. Static event channels are only useful in fully static configurations,
> +and in those configurations the domU device tree dynamically generated by Xen
> +is not needed.
> +
> +Under the "xen,domain" compatible node, there need to be sub-nodes with
> +compatible "xen,evtchn" that describe the event channel connection between 
> two
> +domains(dom0 and domU also).
> +
> +The event channel sub-node has the following properties:
> +
> +- compatible
> +
> +"xen,evtchn"
> +
> +- xen,evtchn
> +
> +The property is tuples of two numbers
> +(local-evtchn link-to-foreign-evtchn) where:
> +
> +local-evtchn is an integer value that will be used to allocate local port
> +for a domain to send and receive event notifications to/from the remote
> +domain.
> +
> +link-to-foreign-evtchn is a single phandle to a remote evtchn to which
> +local-evtchn will be connected.
> +
> +
> +Example:
> +
> +chosen {
> +
> +
> +domU1: domU1 {
> +compatible = "xen,domain";
> +
> +/* one sub-node per local event channel */
> +ec1: evtchn@1 {
> +compatible = "xen,evtchn-v1";
> +/* local-evtchn link-to-foreign-evtchn */
> +xen,evtchn = <0xa >;
> +};
> 

Re: [PATCH v8 0/7] Boot time cpupools

[Stefano Stabellini]

On Fri, 6 May 2022, Luca Fancellu wrote:
> *** Resending the serie adding the maintainers ***
> *** Patches #4 and #6 needs a review from the maintainer of that area ***

Committed, thanks!

Re: Attributing linux related patches on xen-devel

[Andrew Cooper]

On 09/05/2022 20:29, Andrew Cooper wrote:
> On 09/05/2022 20:01, Stefano Stabellini wrote:
>> On Mon, 9 May 2022, Juergen Gross wrote:
>>> On IRC the question came up whether it would be possible to have a
>>> special marker for Linux patches on the xen-devel ML.
>>>
>>> I suggested to use xen-devel+li...@lists.xenprojext.org for those
>>> patches. With a patch for the kernel's MAINTAINERS file this would
>>> be quite easy to achieve.
>>>
>>> Any thoughts?
>> Fine by me, as long as xen-devel+li...@lists.xenprojext.org works :-)
> Well, that one doesn't...
>
> Lets try (take 2).

Nope.

The following message to  was
undeliverable.
The reason for the problem:
5.1.0 - Unknown address error 550-'4.7.1 Unrouteable address'

We'll need to do some reconfiguration first.

~Andrew

Re: ECLAIR Xen x86 results and progress

[Stefano Stabellini]

On Mon, 9 May 2022, Bertrand Marquis wrote:
> > On 6 May 2022, at 17:31, Stefano Stabellini  wrote:
> > 
> > Hi all,
> > 
> > Roberto kindly provided the ECLAIR x86 results:
> > 
> > https://eclairit.com:8443/job/XEN/Target=X86_64,agent=public/lastSuccessfulBuild/eclair/
> > 
> > Click on "See ECLAIR in action", then you can select "Show 100 entries"
> > and see all the results in one page. As an example MC3R1.R1.3
> > corresponds to Rule 1.3 in the spreadsheet.
> > 
> > 
> > If you are OK with this, I would like to aim at a follow-up meeting on
> > Tue May 17 at the same time (8AM California / 4PM UK). If the date/time
> > doesn't work, I'll run another Doodle poll.
> 
> Works for me.

Actually, to make sure more people are able to attend, I would like to
suggest May 19 8AM California / 4PM UK / 5PM Europe (which is the same
slot typically used by the Xen Community Call). Please let me know if
that works or if it is a problem.


> > By then, I am hoping that the group has already gone through the first
> > 20 rules in the list, up until Rule 8.10. Is that reasonable for all of
> > you?
> 
> I completed that part of the table this morning (up to 8.14), it took me 30 
> minutes.

Thank you! I did so as well in about the same amount of time.

I think I should provide a clarification on a couple of rules that are
not clear from the examples.


# Rule 5.4 "Macro identifiers shall be distinct"

This one is about the length of the Macro itself. C90 requires the first
31 characters to be different, while C99 requires the first 63
characteres to be different.

So the problem is the following:

#define this_macro_is_way_way_way_too_long
#define this_macro_is_way_way_way_too_lng

I don't think we have any violations.


# Rule 8.6 " An identifier with external linkage shall have exactly one 
external definition"

This one is meant to catch cases where there are 2 definitions for 1
declaration:

header.h:
extern int hello;

file1.c:
int hello;

file2:
int hello;

There was a question on whether having 1 declaration with no definitions
would be OK, so only the following:

header.h:
extern int hello;

for instance because file1.c has been removed from the build due to a
kconfig. Reading MISRA, I don't think it is a violation of Rule 8.6.
Roberto please correct me if I am wrong.


Cheers,

Stefano

[ovmf test] 170277: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 0e31124877cc8bc0140a03ad3196f0d58b2fd966
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  900 attempts
Testing same since   170272  2022-05-09 15:12:57 Z0 days4 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao Li 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6200 lines long.)

Re: Attributing linux related patches on xen-devel

[Boris Ostrovsky]

On 5/9/22 3:01 PM, Stefano Stabellini wrote:

On Mon, 9 May 2022, Juergen Gross wrote:

On IRC the question came up whether it would be possible to have a
special marker for Linux patches on the xen-devel ML.

I suggested to use xen-devel+li...@lists.xenprojext.org for those
patches. With a patch for the kernel's MAINTAINERS file this would
be quite easy to achieve.

Any thoughts?

Fine by me, as long as xen-devel+li...@lists.xenprojext.org works :-)

The alternative would be to come up with a different subject tag (e.g.
"PATCH LINUX") but that doesn't work as it is not supported by today's
Linux MAINTAINERS file.

So I think xen-devel+linux is fine.




I'd prefer '-' instead of '+' but either way is fine.


-boris

RE: [PATCH v2 4/9] xen/arm: introduce put_page_nr and get_page_nr

[Stefano Stabellini]

On Sat, 7 May 2022, Penny Zheng wrote:
> > On Fri, 6 May 2022, Penny Zheng wrote:
> > > Later, we need to add the right amount of references, which should be
> > > the number of borrower domains, to the owner domain. Since we only
> > > have
> > > get_page() to increment the page reference by 1, a loop is needed per
> > > page, which is inefficient and time-consuming.
> > >
> > > To save the loop time, this commit introduces a set of new helpers
> > > put_page_nr() and get_page_nr() to increment/drop the page reference by
> > nr.
> > >
> > > Signed-off-by: Penny Zheng 
> > > ---
> > > v2 change:
> > > - new commit
> > > ---
> > >  xen/arch/arm/include/asm/mm.h |  4 
> > >  xen/arch/arm/mm.c | 36 +--
> > >  2 files changed, 30 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/include/asm/mm.h
> > > b/xen/arch/arm/include/asm/mm.h index 424aaf2823..c737d51e4d 100644
> > > --- a/xen/arch/arm/include/asm/mm.h
> > > +++ b/xen/arch/arm/include/asm/mm.h
> > > @@ -347,6 +347,10 @@ void free_init_memory(void);  int
> > > guest_physmap_mark_populate_on_demand(struct domain *d, unsigned
> > long gfn,
> > >unsigned int order);
> > >
> > > +extern bool get_page_nr(struct page_info *page, const struct domain
> > *domain,
> > > +unsigned long nr); extern void
> > > +put_page_nr(struct page_info *page, unsigned long nr);
> > > +
> > >  extern void put_page_type(struct page_info *page);  static inline
> > > void put_page_and_type(struct page_info *page)  { diff --git
> > > a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 7b1f2f4906..e565979f3c
> > > 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -1537,7 +1537,8 @@ long arch_memory_op(int op,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> > >  return 0;
> > >  }
> > >
> > > -struct domain *page_get_owner_and_reference(struct page_info *page)
> > > +static struct domain *page_get_owner_and_nr_reference(struct page_info
> > *page,
> > > +  unsigned long
> > > +nr)
> > >  {
> > >  unsigned long x, y = page->count_info;
> > >  struct domain *owner;
> > > @@ -1545,13 +1546,14 @@ struct domain
> > *page_get_owner_and_reference(struct page_info *page)
> > >  do {
> > >  x = y;
> > >  /*
> > > + * Consider the minimum case(nr = 1):
> > >   * Count ==  0: Page is not allocated, so we cannot take a 
> > > reference.
> > >   * Count == -1: Reference count would wrap, which is invalid.
> > >   */
> > >  if ( unlikely(((x + 1) & PGC_count_mask) <= 1) )
> > >  return NULL;
> > >  }
> > > -while ( (y = cmpxchg(>count_info, x, x + 1)) != x );
> > > +while ( (y = cmpxchg(>count_info, x, x + nr)) != x );
> > >
> > >  owner = page_get_owner(page);
> > >  ASSERT(owner);
> > > @@ -1559,36 +1561,50 @@ struct domain
> > *page_get_owner_and_reference(struct page_info *page)
> > >  return owner;
> > >  }
> > >
> > > -void put_page(struct page_info *page)
> > > +struct domain *page_get_owner_and_reference(struct page_info *page) {
> > > +return page_get_owner_and_nr_reference(page, 1); }
> > > +
> > > +void put_page_nr(struct page_info *page, unsigned long nr)
> > >  {
> > >  unsigned long nx, x, y = page->count_info;
> > >
> > >  do {
> > > -ASSERT((y & PGC_count_mask) != 0);
> > > +ASSERT(((y - nr) & PGC_count_mask) >= 0);
> > 
> > Why this change? The original ASSERT is to check that we enter the loop only
> > when count_info is greater than 0. It should still apply even for 
> > put_page_nr
> > without modifications?
> > 
> > 
> 
> Oh, I understand wrongly about the ASSERT. I thought it was to
> check the result count_info after the loop will be not smaller than 0.
> 
> Do you think we still need to ensure that? Maybe ASSERT( ((y & 
> PGC_count_mask) != 0) && (((y - nr) & PGC_count_mask) >= 0)); ?

I think it should be:

ASSERT((y & PGC_count_mask) >= nr);

Re: Attributing linux related patches on xen-devel

[Stefano Stabellini]

On Mon, 9 May 2022, Juergen Gross wrote:
> On IRC the question came up whether it would be possible to have a
> special marker for Linux patches on the xen-devel ML.
> 
> I suggested to use xen-devel+li...@lists.xenprojext.org for those
> patches. With a patch for the kernel's MAINTAINERS file this would
> be quite easy to achieve.
> 
> Any thoughts?

Fine by me, as long as xen-devel+li...@lists.xenprojext.org works :-)

The alternative would be to come up with a different subject tag (e.g.
"PATCH LINUX") but that doesn't work as it is not supported by today's
Linux MAINTAINERS file.

So I think xen-devel+linux is fine.

Re: [PATCH v6 1/2] xsm: create idle domain privileged and demote after setup

[Julien Grall]

Hi Daniel,

On 03/05/2022 12:17, Daniel P. Smith wrote:

There are new capabilities, dom0less and hyperlaunch, that introduce internal
hypervisor logic which needs to make resource allocation calls that are
protected by XSM access checks. This creates an issue as a subset of the
hypervisor code is executed under a system domain, the idle domain, that is
represented by a per-CPU non-privileged struct domain. To enable these new
capabilities to function correctly but in a controlled manner, this commit
changes the idle system domain to be created as a privileged domain under the
default policy and demoted before transitioning to running. A new XSM hook,
xsm_set_system_active(), is introduced to allow each XSM policy type to demote
the idle domain appropriately for that policy type. In the case of SILO, it
inherits the default policy's hook for xsm_set_system_active().

For flask a stub is added to ensure that flask policy system will function
correctly with this patch until flask is extended with support for starting the
idle domain privileged and properly demoting it on the call to
xsm_set_system_active().

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
  xen/arch/arm/setup.c|  4 
  xen/arch/x86/setup.c|  5 +
  xen/common/sched/core.c |  7 ++-
  xen/include/xsm/dummy.h | 17 +
  xen/include/xsm/xsm.h   |  6 ++
  xen/xsm/dummy.c |  1 +
  xen/xsm/flask/hooks.c   | 23 +++
  7 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d5d0792ed4..39a654926d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -1048,6 +1048,10 @@ void __init start_xen(unsigned long boot_phys_offset,
  /* Hide UART from DOM0 if we're using it */
  serial_endboot();
  
+if ( (rc = xsm_set_system_active()) != 0 )

+panic("xsm(err=%d): "
+  "unable to set hypervisor to SYSTEM_ACTIVE privilege\n", rc);


We usually don't split error message over multiple lines (even if they 
are over 80 characters).



+
  system_state = SYS_STATE_active;
  
  for_each_domain( d )

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 6f20e17892..36a60ce884 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -620,6 +620,11 @@ static void noreturn init_done(void)
  {
  void *va;
  unsigned long start, end;
+int err;
+
+if ( (err = xsm_set_system_active()) != 0 )
+panic("xsm(err=%d): "
+  "unable to set hypervisor to SYSTEM_ACTIVE privilege\n", err);


Same here.

Other than the two remarks above and Luca's one:

Acked-by: Julien Grall  # arm

Cheers,

--
Julien Grall

Re: [PATCH v6 1/2] xsm: create idle domain privileged and demote after setup

[Julien Grall]

On 03/05/2022 14:17, Luca Fancellu wrote:

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0bf63ffa84..b93101191e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -186,6 +186,28 @@ static int cf_check flask_domain_alloc_security(struct 
domain *d)
 return 0;
}

+static int cf_check flask_set_system_active(void)
+{
+struct domain *d = current->domain;
+
+ASSERT(d->is_privileged);
+
+if ( d->domain_id != DOMID_IDLE )
+{
+printk("xsm_set_system_active should only be called by idle domain\n");


Sorry I spotted that now, here in the printk probably you mean 
“flask_set_system_active”
instead of “xsm_set_system_active”, you can keep my R-by after this change.


I tend to use "%s: ...", __func__ so the name always name the function.

Cheers,

--
Julien Grall

[ovmf test] 170276: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 0e31124877cc8bc0140a03ad3196f0d58b2fd966
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  899 attempts
Testing same since   170272  2022-05-09 15:12:57 Z0 days3 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao Li 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6200 lines long.)

Re: [PATCH v2] xen/arm: p2m don't fall over on FEAT_LPA enabled hw

[Julien Grall]

Hi Alex,

On 28/04/2022 11:34, Alex Bennée wrote:

When we introduced FEAT_LPA to QEMU's -cpu max we discovered older
kernels had a bug where the physical address was copied directly from
ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits
the same error by blindly copying across the max supported range.

Unsurprisingly when the page tables aren't set up for these greater
ranges hilarity ensues and the hypervisor crashes fairly early on in
the boot-up sequence. This happens when we write to the control
register in enable_mmu().

Attempt to fix this the same way as the Linux kernel does by gating
PARange to the maximum the hypervisor can handle. I also had to fix up
code in p2m which panics when it sees an "invalid" entry in PARange.

Signed-off-by: Alex Bennée 
Cc: Richard Henderson 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Volodymyr Babchuk 
Cc: Bertrand Marquis 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v3] xen/build: Add cppcheck and cppcheck-html make rules

[Julien Grall]

Hi,

On 26/04/2022 13:38, Bertrand Marquis wrote:

diff --git a/xen/arch/arm/include/asm/processor.h 
b/xen/arch/arm/include/asm/processor.h
index 852b5f3c24..ef37cfa16f 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -219,9 +219,11 @@
   SCTLR_Axx_ELx_A| SCTLR_Axx_ELx_C   |\
   SCTLR_Axx_ELx_WXN  | SCTLR_Axx_ELx_EE)
  
+#ifndef CPPCHECK


Can you add a comment explaining why you need this check?

With that:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v2] arm/its: enable LPIs before mapping the collection table

[Julien Grall]

On 06/05/2022 12:28, Bertrand Marquis wrote:

On 4 May 2022, at 18:15, Rahul Singh  wrote:

When Xen boots on the platform that implements the GIC 600, ITS
MAPC_LPI_OFF uncorrectable command error issue is observed.

As per the GIC-600 TRM (Revision: r1p6) MAPC_LPI_OFF command error can
be reported if the MAPC command has tried to map a collection to a core
that does not have LPIs enabled. The definition of GICR.EnableLPIs
also suggests enabling the LPIs before sending any ITS command that
involves LPIs

0b0 LPI support is disabled. Any doorbell interrupt generated as a
result of a write to a virtual LPI register must be discarded,
and any ITS translation requests or commands involving LPIs in
this Redistributor are ignored.

0b1 LPI support is enabled.

To fix the MAPC command error issue, enable the LPIs using
GICR_CTLR.EnableLPIs before mapping the collection table.

gicv3_enable_lpis() is using writel_relaxed(), write to the GICR_CTLR
register may not be visible before gicv3_its_setup_collection() send the
MAPC command. Use wmb() after writel_relaxed() to make sure register
write to enable LPIs is visible.

Signed-off-by: Rahul Singh 

Reviewed-by: Bertrand Marquis 


Committed. Thanks!

Cheers,

--
Julien Grall

Re: [PATCH] docs: Fix SUPPORT matrix generation after a5968a553f6a

[Julien Grall]

Hi,

On 09/05/2022 09:42, George Dunlap wrote:




On May 9, 2022, at 9:07 AM, Julien Grall  wrote:

From: Julien Grall 

Commit a5968a553f6a "SUPPORT.MD: Correct the amount of physical memory
supported for Arm" added a support statement split over two lines.

Unfortunately, docs/support-matrix-generate throw an error for it:

Generating support matrix (origin/stable-NN )
+ docs/support-matrix-generate HEAD 
https://xenbits.xen.org/docs/unstable/SUPPORT.html origin/stable-NN 
https://xenbits.xen.org/docs/NN-testing/SUPPORT.html
Status, x86: Supported up to 8 TiB. Hosts with more memory are
 supported, but not security supported.
Status, Arm32: Supported up to 12 GiB
Status, Arm64: Supported up to 2 TiB
^ cannot parse status codeblock line:
 supported, but not security supported.
 ? at docs/parse-support-md line 172,  chunk 1.

It would be good to allow split support statement (to keep lines below
80 characters) but my knowledge of the script is very limited.

Therefore, workaround the error by describing the support statement
in one long line.

Fixes: a5968a553f6a "SUPPORT.MD: Correct the amount of physical memory supported for 
Arm"
Signed-off-by: Julien Grall 


Acked-by: George Dunlap 


Thanks! I have committed it.

Cheers,

--
Julien Grall

[ovmf test] 170274: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 0e31124877cc8bc0140a03ad3196f0d58b2fd966
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  898 attempts
Testing same since   170272  2022-05-09 15:12:57 Z0 days2 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao Li 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6200 lines long.)

Re: [PATCH 24/30] panic: Refactor the panic path

[Guilherme G. Piccoli]

Hey Hatayma, thanks for your great analysis and no need for apologies!

I'll comment/respond properly inline below, just noticing here that I've
CCed Mark and Marc (from the ARM64 perspective), Michael (Hyper-V
perspective) and Hari (PowerPC perspective), besides the usual suspects
as Petr, Baoquan, etc.

On 09/05/2022 12:16, d.hatay...@fujitsu.com wrote:
> Sorry for the delayed response. Unfortunately, I had 10 days holidays
> until yesterday...
> [...] 
>> +   We currently have 4 lists of panic notifiers; based
>> +   on the functionality and risk (for panic success) the
>> +   callbacks are added in a given list. The lists are:
>> +   - hypervisor/FW notification list (low risk);
>> +   - informational list (low/medium risk);
>> +   - pre_reboot list (higher risk);
>> +   - post_reboot list (only run late in panic and after
>> +   kdump, not configurable for now).
>> +   This parameter defines the ordering of the first 3
>> +   lists with regards to kdump; the levels determine
>> +   which set of notifiers execute before kdump. The
>> +   accepted levels are:
>> +   0: kdump is the first thing to run, NO list is
>> +   executed before kdump.
>> +   1: only the hypervisor list is executed before kdump.
>> +   2 (default level): the hypervisor list and (*if*
> 
> Hmmm, why are you trying to change default setting?
> 
> Based on the current design of kdump, it's natural to put what the
> handlers for these level 1 and level 2 handlers do in
> machine_crash_shutdown(), as these are necessary by default, right?
> 
> Or have you already tried that and figured out it's difficult in some
> reason and reached the current design? If so, why is that difficult?
> Could you point to if there is already such discussion online?
> 
> kdump is designed to perform as little things as possible before
> transferring the execution to the 2nd kernel in order to increase
> reliability. Just detour to panic() increases risks of kdump failure
> in the sense of increasing the executed codes in the abnormal
> situation, which is very the note in the explanation of
> crash_kexec_post_notifiers.
> 
> Also, the current implementation of crash_kexec_post_notifiers uses
> the panic notifier, but this is not from the technical
> reason. Ideally, it should have been implemented in the context of
> crash_kexec() independently of panic().
> 
> That is, it looks to me that, in addition to changing design of panic
> notifier, you are trying to integrate shutdown code of the crash kexec
> and the panic paths. If so, this is a big design change for kdump.
> I'm concerned about increase of reliability. I'd like you to discuss
> them carefully.

>From my understanding (specially based on both these threads [0] and
[1]), 3 facts are clear and quite complex in nature:

(a) Currently, the panic notifier list is a "no man's land" - it's a
mess, all sort of callbacks are added there, some of them are extremely
risk for breaking kdump, others are quite safe (like setting a
variable). Petr's details in thread [0] are really clear and express in
great way how confusing and conflicting the panic notifiers goals are.

(b) In order to "address" problems in the antagonistic goals of
notifiers (see point (a) above and thread [0]), we have this
quirk/workaround called "crash_kexec_post_notifiers". This is useful,
but (almost as for attesting how this is working as band-aid over
complex and fundamental issues) see the following commits:

a11589563e96 ("x86/Hyper-V: Report crash register data or kmsg before
running crash kernel")

06e629c25daa ("powerpc/fadump: Fix inaccurate CPU state info in vmcore
generated with panic")

They hardcode such workaround, because they *need* some notifiers'
callbacks. But notice they *don't need all of them*, only some important
ones (that usually are good considering the risk, it's a good
cost/benefit). Since we currently have an all-or-nothing behavior for
the panic notifiers, both PowerPC and Hyper-V end-up bringing all of
them to run before kdump due to the lack of flexibility, increasing a
lot the risk of failure for kdump.

(c) To add on top of all such complexity, we don't have a custom
machine_crash_shutdown() handler for some architectures like ARM64, and
the feeling is that's not right to add a bunch of callbacks / complexity
in such architecture code, specially since we have the notifiers
infrastructure in the kernel. I've recently started a discussion about
that with ARM64 community, please take a look in [1].

With that said, we can use (a) + (b) + (c) to justify our argument here:
the panic notifiers should be refactored! We need to try to encompass
the antagonistic goals of kdump (wants to be the 

Re: [PATCH 09/30] coresight: cpu-debug: Replace mutex with mutex_trylock on panic notifier

[Guilherme G. Piccoli]

On 09/05/2022 13:14, Suzuki K Poulose wrote:
> [...]> 
> I have queued this to coresight/next.
> 
> Thanks
> Suzuki


Thanks a lot Suzuki!

Re: [PATCH 09/30] coresight: cpu-debug: Replace mutex with mutex_trylock on panic notifier

[Suzuki K Poulose]

Hi

On 09/05/2022 14:09, Guilherme G. Piccoli wrote:

On 28/04/2022 05:11, Suzuki K Poulose wrote:

Hi Guilherme,

On 27/04/2022 23:49, Guilherme G. Piccoli wrote:

The panic notifier infrastructure executes registered callbacks when
a panic event happens - such callbacks are executed in atomic context,
with interrupts and preemption disabled in the running CPU and all other
CPUs disabled. That said, mutexes in such context are not a good idea.

This patch replaces a regular mutex with a mutex_trylock safer approach;
given the nature of the mutex used in the driver, it should be pretty
uncommon being unable to acquire such mutex in the panic path, hence
no functional change should be observed (and if it is, that would be
likely a deadlock with the regular mutex).

Fixes: 2227b7c74634 ("coresight: add support for CPU debug module")
Cc: Leo Yan 
Cc: Mathieu Poirier 
Cc: Mike Leach 
Cc: Suzuki K Poulose 
Signed-off-by: Guilherme G. Piccoli 


How would you like to proceed with queuing this ? I am happy
either way. In case you plan to push this as part of this
series (I don't see any potential conflicts) :

Reviewed-by: Suzuki K Poulose 


Hi Suzuki, some other maintainers are taking the patches to their next
branches for example. I'm working on V2, and I guess in the end would be
nice to reduce the size of the series a bit.

So, do you think you could pick this one for your coresight/next branch
(or even for rc cycle, your call - this is really a fix)?
This way, I won't re-submit this one in V2, since it's gonna be merged
already in your branch.


I have queued this to coresight/next.

Thanks
Suzuki

[ovmf test] 170272: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 0e31124877cc8bc0140a03ad3196f0d58b2fd966
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  897 attempts
Testing same since   170272  2022-05-09 15:12:57 Z0 days1 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao Li 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6200 lines long.)

Attributing linux related patches on xen-devel

[Juergen Gross]

On IRC the question came up whether it would be possible to have a
special marker for Linux patches on the xen-devel ML.

I suggested to use xen-devel+li...@lists.xenprojext.org for those
patches. With a patch for the kernel's MAINTAINERS file this would
be quite easy to achieve.

Any thoughts?


Juergen

P.S.: similar tagging could be performed for qemu and Mini-OS
  related mails


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 01/30] x86/crash,reboot: Avoid re-disabling VMX in all CPUs on crash/restart

[Sean Christopherson]

I find the shortlog to be very confusing, the bug has nothing to do with 
disabling
VMX and I distinctly remember wrapping VMXOFF with exception fixup to prevent 
doom
if VMX is already disabled :-).  The issue is really that nmi_shootdown_cpus() 
doesn't
play nice with being called twice.

On Wed, Apr 27, 2022, Guilherme G. Piccoli wrote:
> In the panic path we have a list of functions to be called, the panic
> notifiers - such callbacks perform various actions in the machine's
> last breath, and sometimes users want them to run before kdump. We
> have the parameter "crash_kexec_post_notifiers" for that. When such
> parameter is used, the function "crash_smp_send_stop()" is executed
> to poweroff all secondary CPUs through the NMI-shootdown mechanism;
> part of this process involves disabling virtualization features in
> all CPUs (except the main one).
> 
> Now, in the emergency restart procedure we have also a way of
> disabling VMX in all CPUs, using the same NMI-shootdown mechanism;
> what happens though is that in case we already NMI-disabled all CPUs,
> the emergency restart fails due to a second addition of the same items
> in the NMI list, as per the following log output:
> 
> sysrq: Trigger a crash
> Kernel panic - not syncing: sysrq triggered crash
> [...]
> Rebooting in 2 seconds..
> list_add double add: new=, prev=, next=.
> [ cut here ]
> kernel BUG at lib/list_debug.c:29!
> invalid opcode:  [#1] PREEMPT SMP PTI

Call stacks for the two callers would be very, very helpful.

> In order to reproduce the problem, users just need to set the kernel
> parameter "crash_kexec_post_notifiers" *without* kdump set in any
> system with the VMX feature present.
> 
> Since there is no benefit in re-disabling VMX in all CPUs in case
> it was already done, this patch prevents that by guarding the restart
> routine against doubly issuing NMIs unnecessarily. Notice we still
> need to disable VMX locally in the emergency restart.
> 
> Fixes: ed72736183c4 ("x86/reboot: Force all cpus to exit VMX root if VMX is 
> supported)
> Fixes: 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump friendly 
> version in panic path")
> Cc: David P. Reed 
> Cc: Hidehiro Kawai 
> Cc: Paolo Bonzini 
> Cc: Sean Christopherson 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>  arch/x86/include/asm/cpu.h |  1 +
>  arch/x86/kernel/crash.c|  8 
>  arch/x86/kernel/reboot.c   | 14 --
>  3 files changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
> index 86e5e4e26fcb..b6a9062d387f 100644
> --- a/arch/x86/include/asm/cpu.h
> +++ b/arch/x86/include/asm/cpu.h
> @@ -36,6 +36,7 @@ extern int _debug_hotplug_cpu(int cpu, int action);
>  #endif
>  #endif
>  
> +extern bool crash_cpus_stopped;
>  int mwait_usable(const struct cpuinfo_x86 *);
>  
>  unsigned int x86_family(unsigned int sig);
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index e8326a8d1c5d..71dd1a990e8d 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -42,6 +42,8 @@
>  #include 
>  #include 
>  
> +bool crash_cpus_stopped;
> +
>  /* Used while preparing memory map entries for second kernel */
>  struct crash_memmap_data {
>   struct boot_params *params;
> @@ -108,9 +110,7 @@ void kdump_nmi_shootdown_cpus(void)
>  /* Override the weak function in kernel/panic.c */
>  void crash_smp_send_stop(void)
>  {
> - static int cpus_stopped;
> -
> - if (cpus_stopped)
> + if (crash_cpus_stopped)
>   return;
>  
>   if (smp_ops.crash_stop_other_cpus)
> @@ -118,7 +118,7 @@ void crash_smp_send_stop(void)
>   else
>   smp_send_stop();
>  
> - cpus_stopped = 1;
> + crash_cpus_stopped = true;

This feels like were just adding more duct tape to the mess.  nmi_shootdown() is
still unsafe for more than one caller, and it takes a _lot_ of staring and 
searching
to understand that crash_smp_send_stop() is invoked iff CONFIG_KEXEC_CORE=y, 
i.e.
that it will call smp_ops.crash_stop_other_cpus() and not just smp_send_stop().

Rather than shared a flag between two relatively unrelated functions, what if we
instead disabling virtualization in crash_nmi_callback() and then turn the 
reboot
call into a nop if an NMI shootdown has already occurred?  That will also add a
bit of documentation about multiple shootdowns not working.

And I believe there's also a lurking bug in native_machine_emergency_restart() 
that
can be fixed with cleanup.  SVM can also block INIT and so should be disabled 
during
an emergency reboot.

The attached patches are compile tested only.  If they seem sane, I'll post an
official mini series.

>  }
>  
>  #else
> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> index fa700b46588e..2fc42b8402ac 100644
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -589,8 +589,18 @@ static void native_machine_emergency_restart(void)
>   

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

[George Dunlap]

> On May 6, 2022, at 1:00 PM, 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 
> Reviewed-by: Stefano Stabellini 

Changes to sched.h:

Acked-by: George Dunlap 



signature.asc
Description: Message signed with OpenPGP

Re: [PATCH 24/30] panic: Refactor the panic path

[d.hatay...@fujitsu.com]

Sorry for the delayed response. Unfortunately, I had 10 days holidays
until yesterday...

>  .../admin-guide/kernel-parameters.txt |  42 ++-
>  include/linux/panic_notifier.h|   1 +
>  kernel/kexec_core.c   |   8 +-
>  kernel/panic.c| 292 +-
>  .../selftests/pstore/pstore_crash_test|   5 +-
>  5 files changed, 252 insertions(+), 96 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 3f1cc5e317ed..8d3524060ce3 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
...snip...
> @@ -3784,6 +3791,33 @@
> timeout < 0: reboot immediately
> Format: 
> 
> +   panic_notifiers_level=
> +   [KNL] Set the panic notifiers execution order.
> +   Format: 
> +   We currently have 4 lists of panic notifiers; based
> +   on the functionality and risk (for panic success) the
> +   callbacks are added in a given list. The lists are:
> +   - hypervisor/FW notification list (low risk);
> +   - informational list (low/medium risk);
> +   - pre_reboot list (higher risk);
> +   - post_reboot list (only run late in panic and after
> +   kdump, not configurable for now).
> +   This parameter defines the ordering of the first 3
> +   lists with regards to kdump; the levels determine
> +   which set of notifiers execute before kdump. The
> +   accepted levels are:
> +   0: kdump is the first thing to run, NO list is
> +   executed before kdump.
> +   1: only the hypervisor list is executed before kdump.
> +   2 (default level): the hypervisor list and (*if*

Hmmm, why are you trying to change default setting?

Based on the current design of kdump, it's natural to put what the
handlers for these level 1 and level 2 handlers do in
machine_crash_shutdown(), as these are necessary by default, right?

Or have you already tried that and figured out it's difficult in some
reason and reached the current design? If so, why is that difficult?
Could you point to if there is already such discussion online?

kdump is designed to perform as little things as possible before
transferring the execution to the 2nd kernel in order to increase
reliability. Just detour to panic() increases risks of kdump failure
in the sense of increasing the executed codes in the abnormal
situation, which is very the note in the explanation of
crash_kexec_post_notifiers.

Also, the current implementation of crash_kexec_post_notifiers uses
the panic notifier, but this is not from the technical
reason. Ideally, it should have been implemented in the context of
crash_kexec() independently of panic().

That is, it looks to me that, in addition to changing design of panic
notifier, you are trying to integrate shutdown code of the crash kexec
and the panic paths. If so, this is a big design change for kdump.
I'm concerned about increase of reliability. I'd like you to discuss
them carefully.

Thanks.
HATAYAMA, Daisuke

[ovmf test] 170271: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 a658ed30e51f2b2024d7bf8d2aa8be2dfa0b02a2
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  896 attempts
Testing same since   170267  2022-05-09 11:41:59 Z0 days5 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6180 lines long.)

[linux-5.4 test] 170264: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux1d72b776f6dc973211f5d153453cf8955fb3d70a
baseline version:
 linux

Re: [PATCH 24/30] panic: Refactor the panic path

[Guilherme G. Piccoli]

On 29/04/2022 13:04, Guilherme G. Piccoli wrote:
> On 27/04/2022 21:28, Randy Dunlap wrote:
>>
>>
>> On 4/27/22 15:49, Guilherme G. Piccoli wrote:
>>> +   crash_kexec_post_notifiers
>>> +   This was DEPRECATED - users should always prefer the
>>
>>  This is DEPRECATED - users should always prefer the
>>
>>> +   parameter "panic_notifiers_level" - check its entry
>>> +   in this documentation for details on how it works.
>>> +   Setting this parameter is exactly the same as setting
>>> +   "panic_notifiers_level=4".
>>
> 
> Thanks Randy, for your suggestion - but I confess I couldn't understand
> it properly. It's related to spaces/tabs, right? What you suggest me to
> change in this formatting? Just by looking the email I can't parse.
> 
> Cheers,
> 
> 
> Guilherme

Complete lack of attention from me, apologies!
The suggestions was s/was/is - already fixed for V2, thanks Randy.

Re: [PATCH 22/30] panic: Introduce the panic post-reboot notifier list

[Guilherme G. Piccoli]

On 27/04/2022 19:49, Guilherme G. Piccoli wrote:
> Currently we have 3 notifier lists in the panic path, which will
> be wired in a way to allow the notifier callbacks to run in
> different moments at panic time, in a subsequent patch.
> 
> But there is also an odd set of architecture calls hardcoded in
> the end of panic path, after the restart machinery. They're
> responsible for late time tunings / events, like enabling a stop
> button (Sparc) or effectively stopping the machine (s390).
> 
> This patch introduces yet another notifier list to offer the
> architectures a way to add callbacks in such late moment on
> panic path without the need of ifdefs / hardcoded approaches.
> 
> Cc: Alexander Gordeev 
> Cc: Christian Borntraeger 
> Cc: "David S. Miller" 
> Cc: Heiko Carstens 
> Cc: Sven Schnelle 
> Cc: Vasily Gorbik 
> Signed-off-by: Guilherme G. Piccoli 

Hey S390/SPARC folks, sorry for the ping!

Any reviews on this V1 would be greatly appreciated, I'm working on V2
and seeking feedback in the non-reviewed patches.

Thanks in advance,


Guilherme

Re: [PATCH 10/30] alpha: Clean-up the panic notifier code

[Guilherme G. Piccoli]

On 27/04/2022 19:49, Guilherme G. Piccoli wrote:
> The alpha panic notifier has some code issues, not following
> the conventions of other notifiers. Also, it might halt the
> machine but still it is set to run as early as possible, which
> doesn't seem to be a good idea.
> 
> This patch cleans the code, and set the notifier to run as the
> latest, following the same approach other architectures are doing.
> Also, we remove the unnecessary include of a header already
> included indirectly.
> 
> Cc: Ivan Kokshaysky 
> Cc: Matt Turner 
> Cc: Richard Henderson 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>  arch/alpha/kernel/setup.c | 36 +++-
>  1 file changed, 15 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
> index b4fbbba30aa2..d88bdf852753 100644
> --- a/arch/alpha/kernel/setup.c
> +++ b/arch/alpha/kernel/setup.c
> @@ -41,19 +41,11 @@
>  #include 
>  #include 
>  #endif
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  
> -static int alpha_panic_event(struct notifier_block *, unsigned long, void *);
> -static struct notifier_block alpha_panic_block = {
> - alpha_panic_event,
> -NULL,
> -INT_MAX /* try to do it first */
> -};
> -
>  #include 
>  #include 
>  #include 
> @@ -435,6 +427,21 @@ static const struct sysrq_key_op srm_sysrq_reboot_op = {
>  };
>  #endif
>  
> +static int alpha_panic_event(struct notifier_block *this,
> +  unsigned long event, void *ptr)
> +{
> + /* If we are using SRM and serial console, just hard halt here. */
> + if (alpha_using_srm && srmcons_output)
> + __halt();
> +
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block alpha_panic_block = {
> + .notifier_call = alpha_panic_event,
> + .priority = INT_MIN, /* may not return, do it last */
> +};
> +
>  void __init
>  setup_arch(char **cmdline_p)
>  {
> @@ -1427,19 +1434,6 @@ const struct seq_operations cpuinfo_op = {
>   .show   = show_cpuinfo,
>  };
>  
> -
> -static int
> -alpha_panic_event(struct notifier_block *this, unsigned long event, void 
> *ptr)
> -{
> -#if 1
> - /* FIXME FIXME FIXME */
> - /* If we are using SRM and serial console, just hard halt here. */
> - if (alpha_using_srm && srmcons_output)
> - __halt();
> -#endif
> -return NOTIFY_DONE;
> -}
> -
>  static __init int add_pcspkr(void)
>  {
>   struct platform_device *pd;


Hi folks, I'm updating Richard's email and re-sending the V1, any
reviews are greatly appreciated!

Cheers,


Guilherme

[ovmf test] 170270: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 a658ed30e51f2b2024d7bf8d2aa8be2dfa0b02a2
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  895 attempts
Testing same since   170267  2022-05-09 11:41:59 Z0 days4 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6180 lines long.)

Re: [PATCH 3/3] common/spinlock: Drop inline from _spin_lock_cb()

[Roger Pau Monné]

On Mon, May 09, 2022 at 01:24:09PM +0100, Andrew Cooper wrote:
> This is undefined behaviour, because there is no _spin_lock_cb() in a separate
> translation unit (C11 6.7.4.11).
> 
> Moreover, MISRA prohibits this construct because, in the case where it is well
> defined, the compiler is free to use either implementation and nothing
> prevents the two from being different.

>From my reading of the spec, using inline defined function with an
extern declaration could allow the function to be (re)defined in the
scope of a different compilation unit, kind of similar to the usage of
the weak attribute?

> This function has external users, so drop the inline.
> 
> Spotted by Eclair MISRA scanner.

Like wants a:

Fixes: 462090402a ('spinlock: Introduce spin_lock_cb()')

Thanks, Roger.

[PATCH] drm/xen: Add missing VM_DONTEXPAND flag in mmap callback

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

With Xen PV Display driver in use the "expected" VM_DONTEXPAND flag
is not set (neither explicitly nor implicitly), so the driver hits
the code path in drm_gem_mmap_obj() which triggers the WARNING.

Signed-off-by: Oleksandr Tyshchenko 
---
This patch eliminates a WARNING which occurs during running any user space
application over drm (weston, modetest, etc) using PV Display frontend
in Xen guest (it worth mentioning the frontend still works despite the WARNING):

root@salvator-x-h3-4x2g-xt-domu:~# modetest -M xendrm-du -s 31:1920x1080
(XEN) common/grant_table.c:1882:d2v0 Expanding d2 grant table from 5 to 9 frames
[   31.566759] [ cut here ]
[   31.566811] WARNING: CPU: 0 PID: 235 at drivers/gpu/drm/drm_gem.c:1055 
drm_gem_mmap_obj+0x16c/0x180
[   31.566864] Modules linked in:
[   31.566886] CPU: 0 PID: 235 Comm: modetest Not tainted 
5.18.0-rc4-yocto-standard-9-gabe87d78bbc9 #1
[   31.566922] Hardware name: XENVM-4.17 (DT)
[   31.566940] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   31.566973] pc : drm_gem_mmap_obj+0x16c/0x180
[   31.567001] lr : drm_gem_mmap_obj+0x78/0x180
[   31.567026] sp : 89d03bb0
[   31.567044] x29: 89d03bb0 x28: 0008 x27: 0001c42d43c0
[   31.567080] x26: 0001c42d4cc0 x25: 07e9 x24: 0001c0136000
[   31.567116] x23: 0001c031 x22: 0001c4002b80 x21: 
[   31.567150] x20: 0001c42d43c0 x19: 0001c0137600 x18: 0001
[   31.567186] x17:  x16:  x15: 00035c81
[   31.567220] x14:  x13:  x12: 
[   31.567258] x11: 0010 x10: 95d69000 x9 : 0001c435ac30
[   31.567294] x8 : 8001f65ce000 x7 : 0001 x6 : 0001c24de000
[   31.567329] x5 : 89d03a10 x4 : 0090 x3 : 10046400
[   31.567365] x2 : 07e9 x1 : 9dd8cb7c02b1bd00 x0 : 10fb
[   31.567401] Call trace:
[   31.567415]  drm_gem_mmap_obj+0x16c/0x180
[   31.567439]  drm_gem_mmap+0x128/0x228
[   31.567460]  mmap_region+0x384/0x5a0
[   31.567484]  do_mmap+0x354/0x4f0
[   31.567505]  vm_mmap_pgoff+0xdc/0x108
[   31.567529]  ksys_mmap_pgoff+0x1b8/0x208
[   31.567550]  __arm64_sys_mmap+0x30/0x48
[   31.567576]  invoke_syscall+0x44/0x108
[   31.567599]  el0_svc_common.constprop.0+0xcc/0xf0
[   31.567629]  do_el0_svc+0x24/0x88
[   31.567649]  el0_svc+0x2c/0x88
[   31.567686]  el0t_64_sync_handler+0xb0/0xb8
[   31.567708]  el0t_64_sync+0x18c/0x190
[   31.567731] ---[ end trace  ]---
setting mode 1920x1080-60.00Hz@XR24 on connectors 31, crtc 34
---
 drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 5a5bf4e..e31554d 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -71,7 +71,7 @@ static int xen_drm_front_gem_object_mmap(struct 
drm_gem_object *gem_obj,
 * the whole buffer.
 */
vma->vm_flags &= ~VM_PFNMAP;
-   vma->vm_flags |= VM_MIXEDMAP;
+   vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
vma->vm_pgoff = 0;
 
/*
-- 
2.7.4

Re: [PATCH] arm/acpi: don't expose the ACPI IORT SMMUv3 entry to dom0

[Robin Murphy]

On 2022-04-27 17:12, Rahul Singh wrote:

Xen should control the SMMUv3 devices therefore, don't expose the
SMMUv3 devices to dom0. Deny iomem access to SMMUv3 address space for
dom0 and also make ACPI IORT SMMUv3 node type to 0xff.


...making the resulting IORT technically useless to consumers. ID 
mappings for all the Root Complex, Named Component and RMR nodes which 
were supposed to be translated through that SMMU node are now invalid, 
because ID mappings can only target an SMMU or ITS node. I can't guess 
at how other consumers may react, but Linux's IORT code is going to 
experience undefined behaviour when tries to translate any MSI DeviceID 
mappings through this invalid node, since it uses a bitmap of (1 << 
node->type) internally; beyond that we're not as strict as we could be 
and make some pretty loose assumptions about what we're parsing, so it 
might even appear to work, but that could easily change at any time in 
future and is absolutely not something Xen or any other software should 
try to rely on.


Thanks,
Robin.


Signed-off-by: Rahul Singh 
---
  xen/arch/arm/acpi/domain_build.c | 40 
  1 file changed, 40 insertions(+)

diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
index bbdc90f92c..ec0b5b261f 100644
--- a/xen/arch/arm/acpi/domain_build.c
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -30,6 +31,7 @@ static int __init acpi_iomem_deny_access(struct domain *d)
  {
  acpi_status status;
  struct acpi_table_spcr *spcr = NULL;
+struct acpi_table_iort *iort;
  unsigned long mfn;
  int rc;
  
@@ -55,6 +57,44 @@ static int __init acpi_iomem_deny_access(struct domain *d)

  printk("Failed to get SPCR table, Xen console may be unavailable\n");
  }
  
+status = acpi_get_table(ACPI_SIG_IORT, 0,

+(struct acpi_table_header **));
+
+if ( ACPI_SUCCESS(status) )
+{
+int i;
+struct acpi_iort_node *node, *end;
+node = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->node_offset);
+end = ACPI_ADD_PTR(struct acpi_iort_node, iort, iort->header.length);
+
+for ( i = 0; i < iort->node_count; i++ )
+{
+if ( node >= end )
+break;
+
+switch ( node->type )
+{
+case ACPI_IORT_NODE_SMMU_V3:
+{
+struct acpi_iort_smmu_v3 *smmu;
+smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
+mfn = paddr_to_pfn(smmu->base_address);
+rc = iomem_deny_access(d, mfn, mfn + PFN_UP(SZ_128K));
+if ( rc )
+printk("iomem_deny_access failed for SMMUv3\n");
+node->type = 0xff;
+break;
+}
+}
+node = ACPI_ADD_PTR(struct acpi_iort_node, node, node->length);
+}
+}
+else
+{
+printk("Failed to get IORT table\n");
+return -EINVAL;
+}
+
  /* Deny MMIO access for GIC regions */
  return gic_iomem_deny_access(d);
  }

[ovmf test] 170269: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 a658ed30e51f2b2024d7bf8d2aa8be2dfa0b02a2
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  894 attempts
Testing same since   170267  2022-05-09 11:41:59 Z0 days3 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6180 lines long.)

Re: [PATCH 1/3] x86/p2m.h: Add include guards

[Andrew Cooper]

On 09/05/2022 14:18, Roger Pau Monné wrote:
> On Mon, May 09, 2022 at 01:24:07PM +0100, Andrew Cooper wrote:
>> Spotted by Eclair MISRA scanner.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Roger Pau Monné 
>
>> ---
>> CC: Jan Beulich 
>> CC: Roger Pau Monné 
>> CC: Wei Liu 
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> CC: Volodymyr Babchuk 
>> CC: Bertrand Marquis 
>> ---
>>  xen/arch/x86/mm/p2m.h | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/xen/arch/x86/mm/p2m.h b/xen/arch/x86/mm/p2m.h
>> index cc0f6766e4df..dc706b8e4799 100644
>> --- a/xen/arch/x86/mm/p2m.h
>> +++ b/xen/arch/x86/mm/p2m.h
>> @@ -15,6 +15,9 @@
>>   * along with this program; If not, see .
>>   */
>>  
>> +#ifndef __ARCH_MM_P2M_H__
>> +#define __ARCH_MM_P2M_H__
> Do we have any guidelines regarding guard naming? Some files seem to
> use __ASM_X86_, others just __ASM and some just _X86.

Not really.  This one is especially complicated because x86 has two of them.

$ git ls-files | grep /p2m\.h
arch/arm/include/asm/p2m.h
arch/x86/include/asm/p2m.h
arch/x86/mm/p2m.h

~Andrew

Re: [PATCH v3 00/21] xen: simplify frontend side ring setup

[Oleksandr]

On 05.05.22 11:16, Juergen Gross wrote:

Hello Juergen.




Many Xen PV frontends share similar code for setting up a ring page
(allocating and granting access for the backend) and for tearing it
down.

Create new service functions doing all needed steps in one go.

This requires all frontends to use a common value for an invalid
grant reference in order to make the functions idempotent.

Changes in V3:
- new patches 1 and 2, comments addressed

Changes in V2:
- new patch 9 and related changes in patches 10-18

Juergen Gross (21):
   xen: update grant_table.h
   xen/grant-table: never put a reserved grant on the free list
   xen/blkfront: switch blkfront to use INVALID_GRANT_REF
   xen/netfront: switch netfront to use INVALID_GRANT_REF
   xen/scsifront: remove unused GRANT_INVALID_REF definition
   xen/usb: switch xen-hcd to use INVALID_GRANT_REF
   xen/drm: switch xen_drm_front to use INVALID_GRANT_REF
   xen/sound: switch xen_snd_front to use INVALID_GRANT_REF
   xen/dmabuf: switch gntdev-dmabuf to use INVALID_GRANT_REF
   xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF
   xen: update ring.h
   xen/xenbus: add xenbus_setup_ring() service function
   xen/blkfront: use xenbus_setup_ring() and xenbus_teardown_ring()
   xen/netfront: use xenbus_setup_ring() and xenbus_teardown_ring()
   xen/tpmfront: use xenbus_setup_ring() and xenbus_teardown_ring()
   xen/drmfront: use xenbus_setup_ring() and xenbus_teardown_ring()
   xen/pcifront: use xenbus_setup_ring() and xenbus_teardown_ring()
   xen/scsifront: use xenbus_setup_ring() and xenbus_teardown_ring()
   xen/usbfront: use xenbus_setup_ring() and xenbus_teardown_ring()
   xen/sndfront: use xenbus_setup_ring() and xenbus_teardown_ring()
   xen/xenbus: eliminate xenbus_grant_ring()



For the patches that touch PV display (#07, #16), PV sound (#08, #20) 
and shared buffer framework used by both frontends (#10):


Reviewed-by: Oleksandr Tyshchenko 


Also I didn't see any issues with these frontends while testing on Arm64 
based board.

So, you can also add:

[Arm64 only]
Tested-by: Oleksandr Tyshchenko 


Thanks!




  drivers/block/xen-blkfront.c|  57 +++
  drivers/char/tpm/xen-tpmfront.c |  18 +--
  drivers/gpu/drm/xen/xen_drm_front.h |   9 --
  drivers/gpu/drm/xen/xen_drm_front_evtchnl.c |  43 ++
  drivers/net/xen-netfront.c  |  85 ---
  drivers/pci/xen-pcifront.c  |  19 +--
  drivers/scsi/xen-scsifront.c|  31 +---
  drivers/usb/host/xen-hcd.c  |  65 ++--
  drivers/xen/gntdev-dmabuf.c |  13 +-
  drivers/xen/grant-table.c   |  12 +-
  drivers/xen/xen-front-pgdir-shbuf.c |  18 +--
  drivers/xen/xenbus/xenbus_client.c  |  82 +++---
  include/xen/grant_table.h   |   2 -
  include/xen/interface/grant_table.h | 161 
  include/xen/interface/io/ring.h |  19 ++-
  include/xen/xenbus.h|   4 +-
  sound/xen/xen_snd_front_evtchnl.c   |  44 ++
  sound/xen/xen_snd_front_evtchnl.h   |   9 --
  18 files changed, 287 insertions(+), 404 deletions(-)


--
Regards,

Oleksandr Tyshchenko

Re: [PATCH 2/3] x86/shadow: Don't use signed bitfield in sh_emulate_ctxt

[Roger Pau Monné]

On Mon, May 09, 2022 at 01:24:08PM +0100, Andrew Cooper wrote:
> 'int' bitfields in particular have implementation defined behaviour under gcc
> and can change signed-ness with -funsigned-bitfields.
> 
> There is no need for low_bit_was_clear to be a bitfield in the first place; it
> is only used as a boolean.  Doing so even improves the code generation in
> sh_emulate_map_dest() to avoid emitting a merge with structure padding.
> 
> Spotted by Eclair MISRA scanner.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Thanks.

Re: [PATCH 1/3] x86/p2m.h: Add include guards

[Roger Pau Monné]

On Mon, May 09, 2022 at 01:24:07PM +0100, Andrew Cooper wrote:
> Spotted by Eclair MISRA scanner.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> CC: Wei Liu 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Volodymyr Babchuk 
> CC: Bertrand Marquis 
> ---
>  xen/arch/x86/mm/p2m.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/xen/arch/x86/mm/p2m.h b/xen/arch/x86/mm/p2m.h
> index cc0f6766e4df..dc706b8e4799 100644
> --- a/xen/arch/x86/mm/p2m.h
> +++ b/xen/arch/x86/mm/p2m.h
> @@ -15,6 +15,9 @@
>   * along with this program; If not, see .
>   */
>  
> +#ifndef __ARCH_MM_P2M_H__
> +#define __ARCH_MM_P2M_H__

Do we have any guidelines regarding guard naming? Some files seem to
use __ASM_X86_, others just __ASM and some just _X86.

Thanks, Roger.

Re: [PATCH 09/30] coresight: cpu-debug: Replace mutex with mutex_trylock on panic notifier

[Guilherme G. Piccoli]

On 28/04/2022 05:11, Suzuki K Poulose wrote:
> Hi Guilherme,
> 
> On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
>> The panic notifier infrastructure executes registered callbacks when
>> a panic event happens - such callbacks are executed in atomic context,
>> with interrupts and preemption disabled in the running CPU and all other
>> CPUs disabled. That said, mutexes in such context are not a good idea.
>>
>> This patch replaces a regular mutex with a mutex_trylock safer approach;
>> given the nature of the mutex used in the driver, it should be pretty
>> uncommon being unable to acquire such mutex in the panic path, hence
>> no functional change should be observed (and if it is, that would be
>> likely a deadlock with the regular mutex).
>>
>> Fixes: 2227b7c74634 ("coresight: add support for CPU debug module")
>> Cc: Leo Yan 
>> Cc: Mathieu Poirier 
>> Cc: Mike Leach 
>> Cc: Suzuki K Poulose 
>> Signed-off-by: Guilherme G. Piccoli 
> 
> How would you like to proceed with queuing this ? I am happy
> either way. In case you plan to push this as part of this
> series (I don't see any potential conflicts) :
> 
> Reviewed-by: Suzuki K Poulose 

Hi Suzuki, some other maintainers are taking the patches to their next
branches for example. I'm working on V2, and I guess in the end would be
nice to reduce the size of the series a bit.

So, do you think you could pick this one for your coresight/next branch
(or even for rc cycle, your call - this is really a fix)?
This way, I won't re-submit this one in V2, since it's gonna be merged
already in your branch.

Thanks in advance,


Guilherme

Re: [PATCH 08/30] powerpc/setup: Refactor/untangle panic notifiers

[Guilherme G. Piccoli]

On 05/05/2022 15:55, Hari Bathini wrote:
> [...] 
> The change looks good. I have tested it on an LPAR (ppc64).
> 
> Reviewed-by: Hari Bathini 
> 

Hi Michael. do you think it's possible to add this one to powerpc/next
(or something like that), or do you prefer a V2 with his tag?
Thanks,


Guilherme

Re: [PATCH 2/3] x86/shadow: Don't use signed bitfield in sh_emulate_ctxt

[Bertrand Marquis]

Hi Andrew,

> On 9 May 2022, at 13:24, Andrew Cooper  wrote:
> 
> 'int' bitfields in particular have implementation defined behaviour under gcc
> and can change signed-ness with -funsigned-bitfields.
> 
> There is no need for low_bit_was_clear to be a bitfield in the first place; it
> is only used as a boolean.  Doing so even improves the code generation in
> sh_emulate_map_dest() to avoid emitting a merge with structure padding.
> 
> Spotted by Eclair MISRA scanner.
> 
> Signed-off-by: Andrew Cooper 
Reviewed-by: Bertrand Marquis 

Is in fact only used as boolean in hvm.c so does make sense.

Cheers
Bertrand

Re: [PATCH 3/3] common/spinlock: Drop inline from _spin_lock_cb()

[Bertrand Marquis]

Hi Andrew,

> On 9 May 2022, at 13:24, Andrew Cooper  wrote:
> 
> This is undefined behaviour, because there is no _spin_lock_cb() in a separate
> translation unit (C11 6.7.4.11).
> 
> Moreover, MISRA prohibits this construct because, in the case where it is well
> defined, the compiler is free to use either implementation and nothing
> prevents the two from being different.
> 
> This function has external users, so drop the inline.
> 
> Spotted by Eclair MISRA scanner.
> 
> Signed-off-by: Andrew Cooper 
Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

Re: [PATCH 01/30] x86/crash,reboot: Avoid re-disabling VMX in all CPUs on crash/restart

[Guilherme G. Piccoli]

On 27/04/2022 19:48, Guilherme G. Piccoli wrote:
> In the panic path we have a list of functions to be called, the panic
> notifiers - such callbacks perform various actions in the machine's
> last breath, and sometimes users want them to run before kdump. We
> have the parameter "crash_kexec_post_notifiers" for that. When such
> parameter is used, the function "crash_smp_send_stop()" is executed
> to poweroff all secondary CPUs through the NMI-shootdown mechanism;
> part of this process involves disabling virtualization features in
> all CPUs (except the main one).
> 
> Now, in the emergency restart procedure we have also a way of
> disabling VMX in all CPUs, using the same NMI-shootdown mechanism;
> what happens though is that in case we already NMI-disabled all CPUs,
> the emergency restart fails due to a second addition of the same items
> in the NMI list, as per the following log output:
> 
> sysrq: Trigger a crash
> Kernel panic - not syncing: sysrq triggered crash
> [...]
> Rebooting in 2 seconds..
> list_add double add: new=, prev=, next=.
> [ cut here ]
> kernel BUG at lib/list_debug.c:29!
> invalid opcode:  [#1] PREEMPT SMP PTI
> 
> In order to reproduce the problem, users just need to set the kernel
> parameter "crash_kexec_post_notifiers" *without* kdump set in any
> system with the VMX feature present.
> 
> Since there is no benefit in re-disabling VMX in all CPUs in case
> it was already done, this patch prevents that by guarding the restart
> routine against doubly issuing NMIs unnecessarily. Notice we still
> need to disable VMX locally in the emergency restart.
> 
> Fixes: ed72736183c4 ("x86/reboot: Force all cpus to exit VMX root if VMX is 
> supported)
> Fixes: 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump friendly 
> version in panic path")
> Cc: David P. Reed 
> Cc: Hidehiro Kawai 
> Cc: Paolo Bonzini 
> Cc: Sean Christopherson 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>  arch/x86/include/asm/cpu.h |  1 +
>  arch/x86/kernel/crash.c|  8 
>  arch/x86/kernel/reboot.c   | 14 --
>  3 files changed, 17 insertions(+), 6 deletions(-)
> 

Hi Paolo / Sean / Vitaly, sorry for the ping.
But do you think this fix is OK from the VMX point-of-view?

I'd like to send a V2 of this set soon, so any review here is highly
appreciated!

Cheers,


Guilherme

Re: [PATCH 1/3] x86/p2m.h: Add include guards

[Bertrand Marquis]

Hi Andrew,

> On 9 May 2022, at 13:24, Andrew Cooper  wrote:
> 
> Spotted by Eclair MISRA scanner.
> 
> Signed-off-by: Andrew Cooper 
Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

[ovmf test] 170268: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 a658ed30e51f2b2024d7bf8d2aa8be2dfa0b02a2
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  893 attempts
Testing same since   170267  2022-05-09 11:41:59 Z0 days2 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6180 lines long.)

[PATCH 2/3] x86/shadow: Don't use signed bitfield in sh_emulate_ctxt

[Andrew Cooper]

'int' bitfields in particular have implementation defined behaviour under gcc
and can change signed-ness with -funsigned-bitfields.

There is no need for low_bit_was_clear to be a bitfield in the first place; it
is only used as a boolean.  Doing so even improves the code generation in
sh_emulate_map_dest() to avoid emitting a merge with structure padding.

Spotted by Eclair MISRA scanner.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
---
 xen/arch/x86/mm/shadow/private.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm/shadow/private.h b/xen/arch/x86/mm/shadow/private.h
index 3dc024e30f20..772521b55dd3 100644
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -827,7 +827,7 @@ struct sh_emulate_ctxt {
 #if (SHADOW_OPTIMIZATIONS & SHOPT_SKIP_VERIFY)
 /* Special case for avoiding having to verify writes: remember
  * whether the old value had its low bit (_PAGE_PRESENT) clear. */
-int low_bit_was_clear:1;
+bool low_bit_was_clear;
 #endif
 };
 
-- 
2.11.0

[PATCH 1/3] x86/p2m.h: Add include guards

[Andrew Cooper]

Spotted by Eclair MISRA scanner.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
---
 xen/arch/x86/mm/p2m.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/x86/mm/p2m.h b/xen/arch/x86/mm/p2m.h
index cc0f6766e4df..dc706b8e4799 100644
--- a/xen/arch/x86/mm/p2m.h
+++ b/xen/arch/x86/mm/p2m.h
@@ -15,6 +15,9 @@
  * along with this program; If not, see .
  */
 
+#ifndef __ARCH_MM_P2M_H__
+#define __ARCH_MM_P2M_H__
+
 struct p2m_domain *p2m_init_one(struct domain *d);
 void p2m_free_one(struct p2m_domain *p2m);
 
@@ -39,6 +42,8 @@ int ept_p2m_init(struct p2m_domain *p2m);
 void ept_p2m_uninit(struct p2m_domain *p2m);
 void p2m_init_altp2m_ept(struct domain *d, unsigned int i);
 
+#endif /* __ARCH_MM_P2M_H__ */
+
 /*
  * Local variables:
  * mode: C
-- 
2.11.0

[PATCH 3/3] common/spinlock: Drop inline from _spin_lock_cb()

[Andrew Cooper]

This is undefined behaviour, because there is no _spin_lock_cb() in a separate
translation unit (C11 6.7.4.11).

Moreover, MISRA prohibits this construct because, in the case where it is well
defined, the compiler is free to use either implementation and nothing
prevents the two from being different.

This function has external users, so drop the inline.

Spotted by Eclair MISRA scanner.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
---
 xen/common/spinlock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 62c83aaa6a73..8cb3b316c5b1 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -159,7 +159,7 @@ static always_inline u16 observe_head(spinlock_tickets_t *t)
 return read_atomic(>head);
 }
 
-void inline _spin_lock_cb(spinlock_t *lock, void (*cb)(void *), void *data)
+void _spin_lock_cb(spinlock_t *lock, void (*cb)(void *), void *data)
 {
 spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
 LOCK_PROFILE_VAR;
-- 
2.11.0

[PATCH 0/3] xen: Trivial MISRA fixes

[Andrew Cooper]

Trivial fixes for MISRA issues while idly looking through the x86 report.

Andrew Cooper (3):
  x86/p2m.h: Add include guards
  x86/shadow: Don't use signed bitfield in sh_emulate_ctxt
  common/spinlock: Drop inline from _spin_lock_cb()

 xen/arch/x86/mm/p2m.h| 5 +
 xen/arch/x86/mm/shadow/private.h | 2 +-
 xen/common/spinlock.c| 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

-- 
2.11.0

[ovmf test] 170267: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 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 a658ed30e51f2b2024d7bf8d2aa8be2dfa0b02a2
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   70 days
Failing since168258  2022-03-01 01:55:31 Z   69 days  892 attempts
Testing same since   170267  2022-05-09 11:41:59 Z0 days1 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Akihiko Odaki 
  Anthony PERARD 
  Bo Chang Ke 
  Bob Feng 
  Chao, Zhuoran 
  Chen Lin Z 
  Chen, Christine 
  Chen, Lin Z 
  Corvin Köhne 
  Dandan Bi 
  Dun Tan 
  duntan 
  Feng, Bob C 
  Gerd Hoffmann 
  Gua Guo 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Heng Luo 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jake Garver 
  Jake Garver via groups.io 
  Jason 
  Jason Lou 
  Jiewen Yao 
  Ke, Bo-ChangX 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Laszlo Ersek 
  Lean Sheng Tan 
  Leif Lindholm 
  Li, Yi1 
  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 
  Peter Grehan 
  Purna Chandra Rao Bandaru 
  Ray Ni 
  Rebecca Cran 
  Rebecca Cran 
  Sami Mujawar 
  Sean Rhodes 
  Sean Rhodes sean@starlabs.systems
  Sebastien Boeuf 
  Sunny Wang 
  Tan, Dun 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Xie, Yuanhao 
  Yi Li 
  yi1 li 
  Yu Pu 
  Yuanhao Xie 
  Yuwei Chen 
  Zhihao Li 
  Zhuoran Chao 

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 6180 lines long.)