date:20220324

[PATCH v5 04/10] xen: don't include asm/hypercall.h from C sources

2022-03-24 Thread Juergen Gross

Instead of including asm/hypercall.h always use xen/hypercall.h.
Additionally include xen/hypercall.h from all sources containing a
hypercall handler.

This prepares for generating the handlers' prototypes at build time.

Add a guard in asm/hypercall.h to catch direct inclusion.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Acked-by: Julien Grall  # arm
---
V2:
- remove platform_op hunk (Jan Beulich)
- remove including of xen/hypervisor.h from arch/x86/x86_64/mm.c
  (Jan Beulich)
- fix include order in common/compat/grant_table.c (Jan Beulich)
---
 xen/arch/arm/hvm.c   | 3 +--
 xen/arch/arm/include/asm/hypercall.h | 4 
 xen/arch/arm/platform_hypercall.c| 1 +
 xen/arch/x86/cpu/vpmu.c  | 1 +
 xen/arch/x86/include/asm/hypercall.h | 4 
 xen/arch/x86/mm.c| 1 -
 xen/arch/x86/platform_hypercall.c| 1 +
 xen/arch/x86/pv/iret.c   | 1 +
 xen/arch/x86/traps.c | 2 +-
 xen/arch/x86/x86_64/compat/mm.c  | 1 +
 xen/arch/x86/x86_64/mm.c | 2 --
 xen/arch/x86/x86_64/platform_hypercall.c | 1 -
 xen/common/compat/grant_table.c  | 1 +
 xen/common/event_channel.c   | 1 +
 xen/common/grant_table.c | 1 +
 xen/common/multicall.c   | 1 +
 16 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index 8951b34086..fc1a52767d 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -29,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 static int hvm_allow_set_param(const struct domain *d, unsigned int param)
 {
 switch ( param )
diff --git a/xen/arch/arm/include/asm/hypercall.h 
b/xen/arch/arm/include/asm/hypercall.h
index fac4d60f17..8182895358 100644
--- a/xen/arch/arm/include/asm/hypercall.h
+++ b/xen/arch/arm/include/asm/hypercall.h
@@ -1,3 +1,7 @@
+#ifndef __XEN_HYPERCALL_H__
+#error "asm/hypercall.h should not be included directly - include 
xen/hypercall.h instead"
+#endif
+
 #ifndef __ASM_ARM_HYPERCALL_H__
 #define __ASM_ARM_HYPERCALL_H__
 
diff --git a/xen/arch/arm/platform_hypercall.c 
b/xen/arch/arm/platform_hypercall.c
index 8efac7ee60..403cc84324 100644
--- a/xen/arch/arm/platform_hypercall.c
+++ b/xen/arch/arm/platform_hypercall.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 4fedc7c570..51d171615f 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/include/asm/hypercall.h 
b/xen/arch/x86/include/asm/hypercall.h
index 49973820af..81ca25f7b3 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -2,6 +2,10 @@
  * asm-x86/hypercall.h
  */
 
+#ifndef __XEN_HYPERCALL_H__
+#error "asm/hypercall.h should not be included directly - include 
xen/hypercall.h instead"
+#endif
+
 #ifndef __ASM_X86_HYPERCALL_H__
 #define __ASM_X86_HYPERCALL_H__
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 2befd0c191..6cc73187ac 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -129,7 +129,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index b91ccff589..eeb4f7a20e 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/pv/iret.c b/xen/arch/x86/pv/iret.c
index 55eb6a63bd..58de9f7922 100644
--- a/xen/arch/x86/pv/iret.c
+++ b/xen/arch/x86/pv/iret.c
@@ -18,6 +18,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 8659547970..4c38f6c015 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -70,7 +71,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index b3da8fafbb..70b08a832a 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 4f225da81e..3510a5affe 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -25,14 +25,12 @@ EMIT_FILE;
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/x86_64/platform_hypercall.c 
b/xen/arch/x86/x86_64/platform_h

[PATCH v5 03/10] xen: harmonize return types of hypercall handlers

2022-03-24 Thread Juergen Gross

Today most hypercall handlers have a return type of long, while the
compat ones return an int. There are a few exceptions from that rule,
however.

Get rid of the exceptions by letting compat handlers always return int
and others always return long, with the exception of the Arm specific
physdev_op handler.

For the compat hvm case use eax instead of rax for the stored result as
it should have been from the beginning.

Additionally move some prototypes to include/asm-x86/hypercall.h
as they are x86 specific. Move the compat_platform_op() prototype to
the common header.

Rename paging_domctl_continuation() to do_paging_domctl_cont() and add
a matching define for the associated hypercall.

Make do_callback_op() and compat_callback_op() more similar by adding
the const attribute to compat_callback_op()'s 2nd parameter.

Change the type of the cmd parameter for [do|compat]_kexec_op() to
unsigned int, as this is more appropriate for the compat case.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
---
V2:
- rework platform_op compat handling (Jan Beulich)
V3:
- remove include of types.h (Jan Beulich)
V4:
- don't move do_physdev_op() (Julien Grall)
- carve out non style compliant parameter replacements (Julien Grall)
---
 xen/arch/x86/domctl.c|  4 +--
 xen/arch/x86/hvm/hypercall.c |  8 ++
 xen/arch/x86/hypercall.c |  2 +-
 xen/arch/x86/include/asm/hypercall.h | 31 
 xen/arch/x86/include/asm/paging.h|  3 ---
 xen/arch/x86/mm/paging.c |  3 ++-
 xen/arch/x86/pv/callback.c   | 14 +--
 xen/arch/x86/pv/emul-priv-op.c   |  2 +-
 xen/arch/x86/pv/hypercall.c  |  5 +---
 xen/arch/x86/pv/iret.c   |  4 +--
 xen/arch/x86/pv/misc-hypercalls.c| 14 +++
 xen/arch/x86/x86_64/platform_hypercall.c |  1 +
 xen/common/argo.c|  6 ++---
 xen/common/kexec.c   |  6 ++---
 xen/include/xen/hypercall.h  | 20 +++
 15 files changed, 59 insertions(+), 64 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index e49f9e91b9..ea7d60ffb6 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -221,8 +221,8 @@ long arch_do_domctl(
 case XEN_DOMCTL_shadow_op:
 ret = paging_domctl(d, &domctl->u.shadow_op, u_domctl, 0);
 if ( ret == -ERESTART )
-return hypercall_create_continuation(__HYPERVISOR_arch_1,
- "h", u_domctl);
+return hypercall_create_continuation(
+   __HYPERVISOR_paging_domctl_cont, "h", u_domctl);
 copyback = true;
 break;
 
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 62b5349e7d..3a35543997 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -124,8 +124,6 @@ static long cf_check hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 [ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) do_ ## x,  \
(hypercall_fn_t *) compat_ ## x }
 
-#define do_arch_1 paging_domctl_continuation
-
 static const struct {
 hypercall_fn_t *native, *compat;
 } hvm_hypercall_table[] = {
@@ -158,11 +156,9 @@ static const struct {
 #ifdef CONFIG_HYPFS
 HYPERCALL(hypfs_op),
 #endif
-HYPERCALL(arch_1)
+HYPERCALL(paging_domctl_cont)
 };
 
-#undef do_arch_1
-
 #undef HYPERCALL
 #undef HVM_CALL
 #undef COMPAT_CALL
@@ -300,7 +296,7 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 #endif
 
 curr->hcall_compat = true;
-regs->rax = hvm_hypercall_table[eax].compat(ebx, ecx, edx, esi, edi);
+regs->eax = hvm_hypercall_table[eax].compat(ebx, ecx, edx, esi, edi);
 curr->hcall_compat = false;
 
 #ifndef NDEBUG
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 2370d31d3f..07e1a45ef5 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -75,7 +75,7 @@ const hypercall_args_t hypercall_args_table[NR_hypercalls] =
 ARGS(dm_op, 3),
 ARGS(hypfs_op, 5),
 ARGS(mca, 1),
-ARGS(arch_1, 1),
+ARGS(paging_domctl_cont, 1),
 };
 
 #undef COMP
diff --git a/xen/arch/x86/include/asm/hypercall.h 
b/xen/arch/x86/include/asm/hypercall.h
index d6daa7e4cb..49973820af 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -11,6 +11,8 @@
 #include  /* for do_mca */
 #include 
 
+#define __HYPERVISOR_paging_domctl_cont __HYPERVISOR_arch_1
+
 typedef unsigned long hypercall_fn_t(
 unsigned long, unsigned long, unsigned long,
 unsigned long, unsigned long);
@@ -80,7 +82,7 @@ do_set_debugreg(
 int reg,
 unsigned long value);
 
-extern unsigned long cf_check
+extern long cf_check
 do_get_debugreg(
 int reg);
 
@@ -118,7 +120,7 @@ do_mmuext_op(
 extern long cf_check do_callback_op(
 int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg)

[PATCH v5 02/10] xen: move do_vcpu_op() to arch specific code

2022-03-24 Thread Juergen Gross

The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common handler. This leads to the
weird call hierarchy:

  do_arm_vcpu_op()
do_vcpu_op()
  arch_do_vcpu_op()

Clean this up by renaming do_vcpu_op() to common_vcpu_op() and
arch_do_vcpu_op() in each architecture to do_vcpu_op(). This way one
of above calls can be avoided without restricting any potential
future use of common sub-ops for Arm.

Signed-off-by: Juergen Gross 
---
V4:
- don't remove HYPERCALL_ARM()
V4.1:
- add missing cf_check (Andrew Cooper)
V5:
- use v instead of current (Julien Grall)
---
 xen/arch/arm/domain.c| 15 ---
 xen/arch/arm/include/asm/hypercall.h |  2 --
 xen/arch/arm/traps.c |  2 +-
 xen/arch/x86/domain.c| 12 
 xen/arch/x86/include/asm/hypercall.h |  2 +-
 xen/arch/x86/x86_64/domain.c | 18 +-
 xen/common/compat/domain.c   | 15 ++-
 xen/common/domain.c  | 12 
 xen/include/xen/hypercall.h  |  2 +-
 9 files changed, 42 insertions(+), 38 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8110c1df86..2f8eaab7b5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1079,23 +1079,24 @@ void arch_dump_domain_info(struct domain *d)
 }
 
 
-long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg)
+long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if ( (v = domain_vcpu(d, vcpuid)) == NULL )
+return -ENOENT;
+
 switch ( cmd )
 {
 case VCPUOP_register_vcpu_info:
 case VCPUOP_register_runstate_memory_area:
-return do_vcpu_op(cmd, vcpuid, arg);
+return common_vcpu_op(cmd, v, arg);
 default:
 return -EINVAL;
 }
 }
 
-long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
-{
-return -ENOSYS;
-}
-
 void arch_dump_vcpu_info(struct vcpu *v)
 {
 gic_dump_info(v);
diff --git a/xen/arch/arm/include/asm/hypercall.h 
b/xen/arch/arm/include/asm/hypercall.h
index 39d2e7889d..fac4d60f17 100644
--- a/xen/arch/arm/include/asm/hypercall.h
+++ b/xen/arch/arm/include/asm/hypercall.h
@@ -4,8 +4,6 @@
 #include  /* for arch_do_domctl */
 int do_arm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
-long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg);
-
 long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 43f30747cf..e906bb4a89 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1380,7 +1380,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
 #endif
 HYPERCALL(multicall, 2),
 HYPERCALL(platform_op, 1),
-HYPERCALL_ARM(vcpu_op, 3),
+HYPERCALL(vcpu_op, 3),
 HYPERCALL(vm_assist, 2),
 #ifdef CONFIG_ARGO
 HYPERCALL(argo_op, 5),
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a5048ed654..d566fc82b4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1489,11 +1489,15 @@ int arch_vcpu_reset(struct vcpu *v)
 return 0;
 }
 
-long
-arch_do_vcpu_op(
-int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+long cf_check do_vcpu_op(int cmd, unsigned int vcpuid,
+ XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc = 0;
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if ( (v = domain_vcpu(d, vcpuid)) == NULL )
+return -ENOENT;
 
 switch ( cmd )
 {
@@ -1545,7 +1549,7 @@ arch_do_vcpu_op(
 }
 
 default:
-rc = -ENOSYS;
+rc = common_vcpu_op(cmd, v, arg);
 break;
 }
 
diff --git a/xen/arch/x86/include/asm/hypercall.h 
b/xen/arch/x86/include/asm/hypercall.h
index 61bf897147..d6daa7e4cb 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -145,7 +145,7 @@ compat_physdev_op(
 XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
-arch_compat_vcpu_op(
+compat_common_vcpu_op(
 int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int cf_check compat_mmuext_op(
diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c
index c46dccc25a..9c559aa3ea 100644
--- a/xen/arch/x86/x86_64/domain.c
+++ b/xen/arch/x86/x86_64/domain.c
@@ -12,11 +12,15 @@
 CHECK_vcpu_get_physid;
 #undef xen_vcpu_get_physid
 
-int
-arch_compat_vcpu_op(
-int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+int cf_check
+compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
-int rc = -ENOSYS;
+int rc;
+struct domain *d = cur

[PATCH v5 06/10] xen: generate hypercall interface related code

2022-03-24 Thread Juergen Gross

Instead of repeating similar data multiple times use a single source
file and a generator script for producing prototypes and call sequences
of the hypercalls.

As the script already knows the number of parameters used add generating
a macro for populating an array with the number of parameters per
hypercall.

The priorities for the specific hypercalls are based on two benchamrks
performed in guests (PV and PVH):

- make -j 4 of the Xen hypervisor (resulting in cpu load with lots of
  processes created)
- scp of a large file to the guest (network load)

With a small additional debug patch applied the number of the
different hypercalls in the guest and in dom0 (for looking at backend
activity related hypercalls) were counted while the benchmark in domU
was running:

PV-hypercallPV-guest build   PV-guest scpdom0 build dom0 scp
mmu_update   186175729   2865 2093633725
stack_switch   1273311  62381108589   270764
multicall  2182803 50   302  524
update_va_mapping   571868 1060   80
xen_version  73061850   859 5432
grant_table_op   0  0 35557   139110
iret  75673006 484132268157   757958
vcpu_op 453037  71199138224   334988
set_segment_base   1650249  62387108645   270823
mmuext_op 11225681188  7239 3426
sched_op280153 134645 70729   137943
event_channel_op192327  66204 71409   214191
physdev_op   0  0  7721 4315
(the dom0 values are for the guest running the build or scp test, so
dom0 acting as backend)

HVM-hypercall   PVH-guest buildPVH-guest scp
vcpu_op  277684 2324
event_channel_op 35023357383
(the related dom0 counter values are in the same range as with the test
running in the PV guest)

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Acked-by: Julien Grall 
---
V2:
- split platform_op for doe and compat prefixes (Jan Beulich)
- add "addline:" directive
- add priorities to handlers (Jan Beulich)
V2.1:
- add missing "delete" statement in awk script
- optimize case of 2 hypercalls with same priority
V2.2:
- avoid asort() function (Michal Orzel)
V3:
- drop "addline:" support, as no longer needed
- enclose call sequence macros in "({ ... })" (Jan Beulich)
- small style adjustment (Jan Beulich)
- move generating to xen/include/Makefile (Anthony PERARD)
V4:
- generate cf_check attribute for prototype (will be removed in later patch)
- add Arm-specific variant of physdev_op()
V5:
- user $(srctree) (Anthony Perard)
- specify priority 1 for arm evtchn_op (Julien Grall)
---
 .gitignore|   1 +
 xen/include/Makefile  |  13 ++
 xen/include/hypercall-defs.c  | 285 ++
 xen/scripts/gen_hypercall.awk | 314 ++
 4 files changed, 613 insertions(+)
 create mode 100644 xen/include/hypercall-defs.c
 create mode 100644 xen/scripts/gen_hypercall.awk

diff --git a/.gitignore b/.gitignore
index d425be4bd9..c6e5b31b98 100644
--- a/.gitignore
+++ b/.gitignore
@@ -324,6 +324,7 @@ xen/include/public/public
 xen/include/xen/*.new
 xen/include/xen/acm_policy.h
 xen/include/xen/compile.h
+xen/include/xen/hypercall-defs.h
 xen/include/xen/lib/x86/cpuid-autogen.h
 xen/test/livepatch/config.h
 xen/test/livepatch/expect_config.h
diff --git a/xen/include/Makefile b/xen/include/Makefile
index a3c2511f5f..dfc43f9fba 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -77,6 +77,18 @@ $(obj)/compat/xlat.h: $(addprefix 
$(obj)/compat/.xlat/,$(xlat-y)) $(obj)/config/
cat $(filter %.h,$^) >$@.new
mv -f $@.new $@
 
+quiet_cmd_genhyp = GEN $@
+define cmd_genhyp
+awk -f $(srctree)/scripts/gen_hypercall.awk <$< >$@
+endef
+
+all: $(obj)/xen/hypercall-defs.h
+
+$(obj)/xen/hypercall-defs.h: $(obj)/hypercall-defs.i 
$(srctree)/scripts/gen_hypercall.awk FORCE
+   $(call if_changed,genhyp)
+
+targets += xen/hypercall-defs.h
+
 ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
 
 all: $(obj)/headers.chk $(obj)/headers99.chk $(obj)/headers++.chk
@@ -132,3 +144,4 @@ all: lib-x86-all
 endif
 
 clean-files := compat config generated headers*.chk xen/lib/x86/cpuid-autogen.h
+clean-files += xen/hypercall-defs.h hypercall-defs.i
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
new file mode 100644
index 00..60cbeb18e4
--- /dev/null
+++ b/xen/include/hypercall-defs.c
@@ -0,0 +1,285 @@
+/*
+ * Hypercall interface description:
+ * Used by scripts/gen_hypercall.awk to generate hypercall prototypes and call
+ * sequences.
+ *
+ * Syntax is like a prototype, but without return type and without the ";"

[PATCH v5 08/10] xen/x86: call hypercall handlers via generated macro

2022-03-24 Thread Juergen Gross

Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.

This is beneficial to performance and avoids speculation issues.

With calling the handlers using the correct number of parameters now
it is possible to do the parameter register clobbering in the NDEBUG
case after returning from the handler. With the additional generated
data the hard coded hypercall_args_table[] can be replaced by tables
using the generated number of parameters.

Note that this change modifies behavior of clobbering registers in a
minor way: in case a hypercall is returning -ENOSYS (or the unsigned
equivalent thereof) for any reason the parameter registers will no
longer be clobbered. This should be of no real concern, as those cases
ought to be extremely rare and reuse of the registers in those cases
seems rather far fetched.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
---
V2:
- make hypercall_args_*[] const (Jan Beulich)
- make clobber_regs*() independent from NDEBUG (Jan Beulich)
- drop "L" suffix for 32-bit register clobber value (Jan Beulich)
V3:
- add array_access_nospec() (Jan Beulich)
- remove local variables in hvm_hypercall() (Andrew Cooper)
---
 xen/arch/x86/hvm/hypercall.c | 166 +++-
 xen/arch/x86/hypercall.c |  59 -
 xen/arch/x86/include/asm/hypercall.h |  55 ++--
 xen/arch/x86/pv/hypercall.c  | 184 +++
 4 files changed, 76 insertions(+), 388 deletions(-)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index a9c9ad721f..ae601185fc 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -111,56 +111,10 @@ long cf_check hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 return compat_physdev_op(cmd, arg);
 }
 
-#define HYPERCALL(x) \
-[ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) do_ ## x,  \
-   (hypercall_fn_t *) do_ ## x }
-
-#define HVM_CALL(x)  \
-[ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) hvm_ ## x, \
-   (hypercall_fn_t *) hvm_ ## x }
-
-#define COMPAT_CALL(x)   \
-[ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) do_ ## x,  \
-   (hypercall_fn_t *) compat_ ## x }
-
-static const struct {
-hypercall_fn_t *native, *compat;
-} hvm_hypercall_table[] = {
-HVM_CALL(memory_op),
-COMPAT_CALL(multicall),
-#ifdef CONFIG_GRANT_TABLE
-HVM_CALL(grant_table_op),
-#endif
-HYPERCALL(vm_assist),
-COMPAT_CALL(vcpu_op),
-HVM_CALL(physdev_op),
-COMPAT_CALL(xen_version),
-HYPERCALL(console_io),
-HYPERCALL(event_channel_op),
-COMPAT_CALL(sched_op),
-COMPAT_CALL(set_timer_op),
-COMPAT_CALL(xsm_op),
-HYPERCALL(hvm_op),
-HYPERCALL(sysctl),
-HYPERCALL(domctl),
-#ifdef CONFIG_ARGO
-COMPAT_CALL(argo_op),
-#endif
-COMPAT_CALL(platform_op),
-#ifdef CONFIG_PV
-COMPAT_CALL(mmuext_op),
-#endif
-HYPERCALL(xenpmu_op),
-COMPAT_CALL(dm_op),
-#ifdef CONFIG_HYPFS
-HYPERCALL(hypfs_op),
+#ifndef NDEBUG
+static const unsigned char hypercall_args_64[] = hypercall_args_hvm64;
+static const unsigned char hypercall_args_32[] = hypercall_args_hvm32;
 #endif
-HYPERCALL(paging_domctl_cont)
-};
-
-#undef HYPERCALL
-#undef HVM_CALL
-#undef COMPAT_CALL
 
 int hvm_hypercall(struct cpu_user_regs *regs)
 {
@@ -206,23 +160,6 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 return ret;
 }
 
-BUILD_BUG_ON(ARRAY_SIZE(hvm_hypercall_table) >
- ARRAY_SIZE(hypercall_args_table));
-
-if ( eax >= ARRAY_SIZE(hvm_hypercall_table) )
-{
-regs->rax = -ENOSYS;
-return HVM_HCALL_completed;
-}
-
-eax = array_index_nospec(eax, ARRAY_SIZE(hvm_hypercall_table));
-
-if ( !hvm_hypercall_table[eax].native )
-{
-regs->rax = -ENOSYS;
-return HVM_HCALL_completed;
-}
-
 /*
  * Caching is intended for instruction emulation only. Disable it
  * for any accesses by hypercall argument copy-in / copy-out.
@@ -233,85 +170,27 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 
 if ( mode == 8 )
 {
-unsigned long rdi = regs->rdi;
-unsigned long rsi = regs->rsi;
-unsigned long rdx = regs->rdx;
-unsigned long r10 = regs->r10;
-unsigned long r8 = regs->r8;
-
 HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu(%lx, %lx, %lx, %lx, %lx)",
-eax, rdi, rsi, rdx, r10, r8);
-
-#ifndef NDEBUG
-/* Deliberately corrupt parameter regs not used by this hypercall. */
-switch ( hypercall_args_table[eax].native )
-{
-case 0: rdi = 0xdeadbeefdeadf00dUL; fallthrough;
-case 1: rsi = 0xdeadbeefdeadf00dUL; fallthrough;
-case 2: rdx = 0xdeadbeefdeadf00dUL; fallthrough;
-case 3: r10 = 0xdeadbeefdeadf

[PATCH v5 05/10] xen: include compat/platform.h from hypercall.h

2022-03-24 Thread Juergen Gross

The definition of compat_platform_op_t is in compat/platform.h
already, so include that file from hypercall.h instead of repeating
the typedef.

This allows to remove the related include statement from
arch/x86/x86_64/platform_hypercall.c.

Signed-off-by: Juergen Gross 
Acked-by: Jan Beulich 
---
V3:
- new patch
---
 xen/arch/x86/x86_64/platform_hypercall.c | 1 -
 xen/include/xen/hypercall.h  | 4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/x86_64/platform_hypercall.c 
b/xen/arch/x86/x86_64/platform_hypercall.c
index f84252bac6..7631058cce 100644
--- a/xen/arch/x86/x86_64/platform_hypercall.c
+++ b/xen/arch/x86/x86_64/platform_hypercall.c
@@ -6,7 +6,6 @@ EMIT_FILE;
 
 #include 
 #include 
-#include 
 
 #define xen_platform_op compat_platform_op
 #define xen_platform_op_t   compat_platform_op_t
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index a032ba2b4a..ca8ee22717 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -15,6 +15,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_COMPAT
+#include 
+#endif
 #include 
 #include 
 
@@ -206,7 +209,6 @@ extern int cf_check compat_multicall(
 
 int compat_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
-typedef struct compat_platform_op compat_platform_op_t;
 DEFINE_XEN_GUEST_HANDLE(compat_platform_op_t);
 int compat_platform_op(XEN_GUEST_HANDLE_PARAM(compat_platform_op_t) 
u_xenpf_op);
 
-- 
2.34.1

[PATCH v5 00/10] xen: drop hypercall function tables

2022-03-24 Thread Juergen Gross

In order to avoid indirect function calls on the hypercall path as
much as possible this series is removing the hypercall function tables
and is replacing the hypercall handler calls via the function array
by automatically generated call macros.

Another by-product of generating the call macros is the automatic
generating of the hypercall handler prototypes from the same data base
which is used to generate the macros.

This has the additional advantage of using type safe calls of the
handlers and to ensure related handler (e.g. PV and HVM ones) share
the same prototypes.

A very brief performance test (parallel build of the Xen hypervisor
in a 6 vcpu guest) showed a very slim improvement (less than 1%) of
the performance with the patches applied. The test was performed using
a PV and a PVH guest.

Changes in V2:
- new patches 6, 14, 15
- patch 7: support hypercall priorities for faster code
- comments addressed

Changes in V3:
- patches 1 and 4 removed as already applied
- comments addressed

Changes in V4:
- 5 patches removed al already applied
- new patches 1, 3 and 11
- avoid switching Arm hypercall handlers to return long (no change of
  handlers returning long already)

Changes in V5:
- patch 3 of V4 has been applied already
- comments addressed
- rebase

Juergen Gross (10):
  xen/arm: rename do_phydev_op() to do_arm_physdev_op()
  xen: move do_vcpu_op() to arch specific code
  xen: harmonize return types of hypercall handlers
  xen: don't include asm/hypercall.h from C sources
  xen: include compat/platform.h from hypercall.h
  xen: generate hypercall interface related code
  xen: use generated prototypes for hypercall handlers
  xen/x86: call hypercall handlers via generated macro
  xen/arm: call hypercall handlers via generated macro
  xen/x86: remove cf_check attribute from hypercall handlers

 .gitignore   |   1 +
 xen/arch/arm/domain.c|  15 +-
 xen/arch/arm/hvm.c   |   3 +-
 xen/arch/arm/include/asm/hypercall.h |   7 +-
 xen/arch/arm/physdev.c   |   2 +-
 xen/arch/arm/platform_hypercall.c|   1 +
 xen/arch/arm/traps.c | 117 ++---
 xen/arch/x86/compat.c|   6 +-
 xen/arch/x86/cpu/mcheck/mce.c|   2 +-
 xen/arch/x86/cpu/vpmu.c  |   3 +-
 xen/arch/x86/domain.c|  11 +-
 xen/arch/x86/domctl.c|   4 +-
 xen/arch/x86/hvm/dm.c|   2 +-
 xen/arch/x86/hvm/hvm.c   |   2 +-
 xen/arch/x86/hvm/hypercall.c | 177 ++---
 xen/arch/x86/hypercall.c |  59 -
 xen/arch/x86/include/asm/hypercall.h | 201 ---
 xen/arch/x86/include/asm/paging.h|   3 -
 xen/arch/x86/mm.c|  13 +-
 xen/arch/x86/mm/paging.c |   3 +-
 xen/arch/x86/physdev.c   |   2 +-
 xen/arch/x86/platform_hypercall.c|   3 +-
 xen/arch/x86/pv/callback.c   |  26 +-
 xen/arch/x86/pv/descriptor-tables.c  |   8 +-
 xen/arch/x86/pv/emul-priv-op.c   |   2 +-
 xen/arch/x86/pv/hypercall.c  | 187 ++
 xen/arch/x86/pv/iret.c   |   5 +-
 xen/arch/x86/pv/misc-hypercalls.c|  22 +-
 xen/arch/x86/pv/shim.c   |   4 +-
 xen/arch/x86/traps.c |   2 +-
 xen/arch/x86/x86_64/compat/mm.c  |   3 +-
 xen/arch/x86/x86_64/domain.c |  16 +-
 xen/arch/x86/x86_64/mm.c |   2 -
 xen/arch/x86/x86_64/platform_hypercall.c |   3 +-
 xen/common/argo.c|   8 +-
 xen/common/compat/domain.c   |  15 +-
 xen/common/compat/grant_table.c  |   3 +-
 xen/common/compat/kernel.c   |   2 +-
 xen/common/compat/memory.c   |   3 +-
 xen/common/dm.c  |   2 +-
 xen/common/domain.c  |  14 +-
 xen/common/domctl.c  |   2 +-
 xen/common/event_channel.c   |   3 +-
 xen/common/grant_table.c |   4 +-
 xen/common/hypfs.c   |   2 +-
 xen/common/kernel.c  |   2 +-
 xen/common/kexec.c   |   6 +-
 xen/common/memory.c  |   2 +-
 xen/common/multicall.c   |   4 +-
 xen/common/sched/compat.c|   2 +-
 xen/common/sched/core.c  |   4 +-
 xen/common/sysctl.c  |   2 +-
 xen/common/xenoprof.c|   2 +-
 xen/drivers/char/console.c   |   2 +-
 xen/include/Makefile |  13 +
 xen/include/hypercall-defs.c | 285 
 xen/include/xen/hypercall.h  | 185 +
 xen/scripts/gen_hypercall.awk| 314 +++
 xen/xsm/xsm_core.c   |   4 +-
 59 files changed, 863 insertions(+), 939 deletions(-)
 create mo

[PATCH v5 09/10] xen/arm: call hypercall handlers via generated macro

2022-03-24 Thread Juergen Gross

Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.

This makes the calls of the handlers type safe.

For deprecated hypercalls define stub functions.

Signed-off-by: Juergen Gross 
Reviewed-by: Julien Grall 
Tested-by: Michal Orzel 
---
V2:
- make hypercall_args[] const (Jan Beulich)
V5:
- move out-of-bounds check (Julien Grall)
---
 xen/arch/arm/traps.c | 117 +--
 1 file changed, 24 insertions(+), 93 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index e906bb4a89..e0fca3b4d8 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1331,67 +1331,20 @@ static register_t do_deprecated_hypercall(void)
 return -ENOSYS;
 }
 
-typedef register_t (*arm_hypercall_fn_t)(
-register_t, register_t, register_t, register_t, register_t);
-
-typedef struct {
-arm_hypercall_fn_t fn;
-int nr_args;
-} arm_hypercall_t;
-
-#define HYPERCALL(_name, _nr_args)   \
-[ __HYPERVISOR_ ## _name ] =  {  \
-.fn = (arm_hypercall_fn_t) &do_ ## _name,\
-.nr_args = _nr_args, \
-}
+long dep_sched_op_compat(int cmd, unsigned long arg)
+{
+return do_deprecated_hypercall();
+}
 
-#define HYPERCALL_ARM(_name, _nr_args)\
-[ __HYPERVISOR_ ## _name ] =  {  \
-.fn = (arm_hypercall_fn_t) &do_arm_ ## _name,\
-.nr_args = _nr_args, \
-}
-/*
- * Only use this for hypercalls which were deprecated (i.e. replaced
- * by something else) before Xen on ARM was created, i.e. *not* for
- * hypercalls which are simply not yet used on ARM.
- */
-#define HYPERCALL_DEPRECATED(_name, _nr_args)   \
-[ __HYPERVISOR_##_name ] = {\
-.fn = (arm_hypercall_fn_t) &do_deprecated_hypercall,\
-.nr_args = _nr_args,\
-}
+long dep_event_channel_op_compat(XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop)
+{
+return do_deprecated_hypercall();
+}
 
-static arm_hypercall_t arm_hypercall_table[] = {
-HYPERCALL(memory_op, 2),
-HYPERCALL(domctl, 1),
-HYPERCALL(sched_op, 2),
-HYPERCALL_DEPRECATED(sched_op_compat, 2),
-HYPERCALL(console_io, 3),
-HYPERCALL(xen_version, 2),
-HYPERCALL(xsm_op, 1),
-HYPERCALL(event_channel_op, 2),
-HYPERCALL_DEPRECATED(event_channel_op_compat, 1),
-HYPERCALL_ARM(physdev_op, 2),
-HYPERCALL_DEPRECATED(physdev_op_compat, 1),
-HYPERCALL(sysctl, 2),
-HYPERCALL(hvm_op, 2),
-#ifdef CONFIG_GRANT_TABLE
-HYPERCALL(grant_table_op, 3),
-#endif
-HYPERCALL(multicall, 2),
-HYPERCALL(platform_op, 1),
-HYPERCALL(vcpu_op, 3),
-HYPERCALL(vm_assist, 2),
-#ifdef CONFIG_ARGO
-HYPERCALL(argo_op, 5),
-#endif
-#ifdef CONFIG_HYPFS
-HYPERCALL(hypfs_op, 5),
-#endif
-#ifdef CONFIG_IOREQ_SERVER
-HYPERCALL(dm_op, 3),
-#endif
-};
+long dep_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
+{
+return do_deprecated_hypercall();
+}
 
 #ifndef NDEBUG
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
@@ -1430,7 +1383,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 #define HYPERCALL_ARG3(r) (r)->x2
 #define HYPERCALL_ARG4(r) (r)->x3
 #define HYPERCALL_ARG5(r) (r)->x4
-#define HYPERCALL_ARGS(r) (r)->x0, (r)->x1, (r)->x2, (r)->x3, (r)->x4
 #else
 #define HYPERCALL_RESULT_REG(r) (r)->r0
 #define HYPERCALL_ARG1(r) (r)->r0
@@ -1438,52 +1390,40 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 #define HYPERCALL_ARG3(r) (r)->r2
 #define HYPERCALL_ARG4(r) (r)->r3
 #define HYPERCALL_ARG5(r) (r)->r4
-#define HYPERCALL_ARGS(r) (r)->r0, (r)->r1, (r)->r2, (r)->r3, (r)->r4
 #endif
 
+static const unsigned char hypercall_args[] = hypercall_args_arm;
+
 static void do_trap_hypercall(struct cpu_user_regs *regs, register_t *nr,
   const union hsr hsr)
 {
-arm_hypercall_fn_t call = NULL;
 struct vcpu *curr = current;
 
-BUILD_BUG_ON(NR_hypercalls < ARRAY_SIZE(arm_hypercall_table) );
-
 if ( hsr.iss != XEN_HYPERCALL_TAG )
 {
 gprintk(XENLOG_WARNING, "Invalid HVC imm 0x%x\n", hsr.iss);
 return inject_undef_exception(regs, hsr);
 }
 
-if ( *nr >= ARRAY_SIZE(arm_hypercall_table) )
-{
-perfc_incr(invalid_hypercalls);
-HYPERCALL_RESULT_REG(regs) = -ENOSYS;
-return;
-}
-
 curr->hcall_preempted = false;
 
 perfc_incra(hypercalls, *nr);
-call = arm_hypercall_table[*nr].fn;
-if ( call == NULL )
-{
-HYPERCALL_RESULT_REG(regs) = -ENOSYS;
-return;
-}
 
-HYPERCALL_RESULT_REG(regs) = call(HYPERCALL_ARGS(regs));
+call_handlers_arm(*nr, HYPERCALL_RESULT_REG(regs), HYPERCALL_AR

[PATCH v5 10/10] xen/x86: remove cf_check attribute from hypercall handlers

2022-03-24 Thread Juergen Gross

Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.

Signed-off-by: Juergen Gross 
Reviewed-by: Daniel P. Smith  # xsm parts
Acked-by: Jan Beulich 
Tested-by: Téo Couprie Diaz 
---
V4:
- new patch
---
 xen/arch/x86/compat.c   |  6 +++---
 xen/arch/x86/cpu/mcheck/mce.c   |  2 +-
 xen/arch/x86/cpu/vpmu.c |  2 +-
 xen/arch/x86/domain.c   |  3 +--
 xen/arch/x86/hvm/dm.c   |  2 +-
 xen/arch/x86/hvm/hvm.c  |  2 +-
 xen/arch/x86/hvm/hypercall.c|  6 +++---
 xen/arch/x86/mm.c   | 12 ++--
 xen/arch/x86/mm/paging.c|  2 +-
 xen/arch/x86/physdev.c  |  2 +-
 xen/arch/x86/platform_hypercall.c   |  2 +-
 xen/arch/x86/pv/callback.c  | 16 
 xen/arch/x86/pv/descriptor-tables.c |  8 
 xen/arch/x86/pv/iret.c  |  4 ++--
 xen/arch/x86/pv/misc-hypercalls.c   | 10 +-
 xen/arch/x86/pv/shim.c  |  4 ++--
 xen/arch/x86/x86_64/compat/mm.c |  2 +-
 xen/arch/x86/x86_64/domain.c|  2 +-
 xen/common/argo.c   |  4 ++--
 xen/common/compat/grant_table.c |  2 +-
 xen/common/compat/kernel.c  |  2 +-
 xen/common/compat/memory.c  |  3 +--
 xen/common/dm.c |  2 +-
 xen/common/domain.c |  2 +-
 xen/common/domctl.c |  2 +-
 xen/common/event_channel.c  |  2 +-
 xen/common/grant_table.c|  3 +--
 xen/common/hypfs.c  |  2 +-
 xen/common/kernel.c |  2 +-
 xen/common/kexec.c  |  4 ++--
 xen/common/memory.c |  2 +-
 xen/common/multicall.c  |  3 +--
 xen/common/sched/compat.c   |  2 +-
 xen/common/sched/core.c |  4 ++--
 xen/common/sysctl.c |  2 +-
 xen/common/xenoprof.c   |  2 +-
 xen/drivers/char/console.c  |  2 +-
 xen/scripts/gen_hypercall.awk   |  2 +-
 xen/xsm/xsm_core.c  |  4 ++--
 39 files changed, 68 insertions(+), 72 deletions(-)

diff --git a/xen/arch/x86/compat.c b/xen/arch/x86/compat.c
index 28281a262a..a031062830 100644
--- a/xen/arch/x86/compat.c
+++ b/xen/arch/x86/compat.c
@@ -15,7 +15,7 @@ typedef long ret_t;
 #endif
 
 /* Legacy hypercall (as of 0x00030202). */
-ret_t cf_check do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
+ret_t do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
 {
 struct physdev_op op;
 
@@ -28,7 +28,7 @@ ret_t cf_check 
do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
 #ifndef COMPAT
 
 /* Legacy hypercall (as of 0x00030101). */
-long cf_check do_sched_op_compat(int cmd, unsigned long arg)
+long do_sched_op_compat(int cmd, unsigned long arg)
 {
 switch ( cmd )
 {
@@ -50,7 +50,7 @@ long cf_check do_sched_op_compat(int cmd, unsigned long arg)
 }
 
 /* Legacy hypercall (as of 0x00030202). */
-long cf_check do_event_channel_op_compat(
+long do_event_channel_op_compat(
 XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop)
 {
 struct evtchn_op op;
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 275c54be7c..f68e31b643 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1351,7 +1351,7 @@ CHECK_mcinfo_recovery;
 # endif /* CONFIG_COMPAT */
 
 /* Machine Check Architecture Hypercall */
-long cf_check do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
+long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 {
 long ret = 0;
 struct xen_mc curop, *op = &curop;
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 51d171615f..d2c03a1104 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -672,7 +672,7 @@ void vpmu_dump(struct vcpu *v)
 alternative_vcall(vpmu_ops.arch_vpmu_dump, v);
 }
 
-long cf_check do_xenpmu_op(
+long do_xenpmu_op(
 unsigned int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 {
 int ret;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d566fc82b4..ddf969f76e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1489,8 +1489,7 @@ int arch_vcpu_reset(struct vcpu *v)
 return 0;
 }
 
-long cf_check do_vcpu_op(int cmd, unsigned int vcpuid,
- XEN_GUEST_HANDLE_PARAM(void) arg)
+long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc = 0;
 struct domain *d = current->domain;
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index d80975efcf..f8e6089870 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -654,7 +654,7 @@ CHECK_dm_op_relocate_memory;
 CHECK_dm_op_pin_memory_cacheattr;
 CHECK_dm_op_nr_vcpus;
 
-int cf_check compat_dm_op(
+int compat_dm_op(
 domid_t domid, unsigned int nr_bufs, XEN_GUEST_HANDLE_PARAM(void) bufs)
 {
 struct dmop_args args;
diff --git a/xen/arch/x86/hvm/hvm.c b/x

[PATCH v5 07/10] xen: use generated prototypes for hypercall handlers

2022-03-24 Thread Juergen Gross

Remove the hypercall handler's prototypes in the related header files
and use the generated ones instead.

Some handlers having been static before need to be made globally
visible.

Signed-off-by: Juergen Gross 
Acked-by: Jan Beulich 
Acked-by: Julien Grall 
---
 xen/arch/arm/include/asm/hypercall.h |   1 -
 xen/arch/x86/hvm/hypercall.c |   7 +-
 xen/arch/x86/include/asm/hypercall.h | 141 -
 xen/include/xen/hypercall.h  | 177 +--
 4 files changed, 5 insertions(+), 321 deletions(-)

diff --git a/xen/arch/arm/include/asm/hypercall.h 
b/xen/arch/arm/include/asm/hypercall.h
index 8182895358..ccd26c5184 100644
--- a/xen/arch/arm/include/asm/hypercall.h
+++ b/xen/arch/arm/include/asm/hypercall.h
@@ -6,7 +6,6 @@
 #define __ASM_ARM_HYPERCALL_H__
 
 #include  /* for arch_do_domctl */
-int do_arm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 3a35543997..a9c9ad721f 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -31,8 +31,7 @@
 #include 
 #include 
 
-static long cf_check hvm_memory_op(
-unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
+long cf_check hvm_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 {
 long rc;
 
@@ -52,7 +51,7 @@ static long cf_check hvm_memory_op(
 }
 
 #ifdef CONFIG_GRANT_TABLE
-static long cf_check hvm_grant_table_op(
+long cf_check hvm_grant_table_op(
 unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
 {
 switch ( cmd )
@@ -78,7 +77,7 @@ static long cf_check hvm_grant_table_op(
 }
 #endif
 
-static long cf_check hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
+long cf_check hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 const struct vcpu *curr = current;
 const struct domain *currd = curr->domain;
diff --git a/xen/arch/x86/include/asm/hypercall.h 
b/xen/arch/x86/include/asm/hypercall.h
index 81ca25f7b3..2d243b48bc 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -44,109 +44,6 @@ void pv_ring3_init_hypercall_page(void *ptr);
  */
 #define MMU_UPDATE_PREEMPTED  (~(~0U>>1))
 
-extern long cf_check
-do_event_channel_op_compat(
-XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop);
-
-/* Legacy hypercall (as of 0x00030202). */
-extern long cf_check do_physdev_op_compat(
-XEN_GUEST_HANDLE(physdev_op_t) uop);
-
-/* Legacy hypercall (as of 0x00030101). */
-extern long cf_check do_sched_op_compat(
-int cmd, unsigned long arg);
-
-extern long cf_check
-do_set_trap_table(
-XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps);
-
-extern long cf_check
-do_mmu_update(
-XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs,
-unsigned int count,
-XEN_GUEST_HANDLE_PARAM(uint) pdone,
-unsigned int foreigndom);
-
-extern long cf_check
-do_set_gdt(
-XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
-unsigned int entries);
-
-extern long cf_check
-do_stack_switch(
-unsigned long ss,
-unsigned long esp);
-
-extern long cf_check
-do_fpu_taskswitch(
-int set);
-
-extern long cf_check
-do_set_debugreg(
-int reg,
-unsigned long value);
-
-extern long cf_check
-do_get_debugreg(
-int reg);
-
-extern long cf_check
-do_update_descriptor(
-uint64_t gaddr, seg_desc_t desc);
-
-extern long cf_check
-do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc);
-
-extern long cf_check
-do_update_va_mapping(
-unsigned long va,
-uint64_t val64,
-unsigned long flags);
-
-extern long cf_check
-do_physdev_op(
-int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
-
-extern long cf_check
-do_update_va_mapping_otherdomain(
-unsigned long va,
-uint64_t val64,
-unsigned long flags,
-domid_t domid);
-
-extern long cf_check
-do_mmuext_op(
-XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops,
-unsigned int count,
-XEN_GUEST_HANDLE_PARAM(uint) pdone,
-unsigned int foreigndom);
-
-extern long cf_check do_callback_op(
-int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg);
-
-extern long cf_check
-do_iret(
-void);
-
-extern long cf_check
-do_set_callbacks(
-unsigned long event_address,
-unsigned long failsafe_address,
-unsigned long syscall_address);
-
-extern long cf_check
-do_set_segment_base(
-unsigned int which,
-unsigned long base);
-
-long cf_check do_nmi_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
-
-long cf_check do_xenpmu_op(unsigned int op,
-   XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg);
-
-long cf_check do_paging_domctl_cont(
-XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
-
 #ifdef CONFIG_COMPAT
 
 #include 
@@ -157,44 +54,6 @@ extern int
 compat_common_vcpu_op(
 int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg);
 
-extern int cf_check

[PATCH v5 01/10] xen/arm: rename do_phydev_op() to do_arm_physdev_op()

2022-03-24 Thread Juergen Gross

do_physdev_op() prototypes on Arm and x86 differ in their return type,
so rename the Arm one in order to prepare using a common generated
header file.

Signed-off-by: Juergen Gross 
Acked-by: Julien Grall 
---
V4:
- new patch
---
 xen/arch/arm/include/asm/hypercall.h | 2 +-
 xen/arch/arm/physdev.c   | 2 +-
 xen/arch/arm/traps.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/include/asm/hypercall.h 
b/xen/arch/arm/include/asm/hypercall.h
index a0c5a31a2f..39d2e7889d 100644
--- a/xen/arch/arm/include/asm/hypercall.h
+++ b/xen/arch/arm/include/asm/hypercall.h
@@ -2,7 +2,7 @@
 #define __ASM_ARM_HYPERCALL_H__
 
 #include  /* for arch_do_domctl */
-int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
+int do_arm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg);
 
diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
index f9aa274dda..95a8cdc0ee 100644
--- a/xen/arch/arm/physdev.c
+++ b/xen/arch/arm/physdev.c
@@ -11,7 +11,7 @@
 #include 
 
 
-int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
+int do_arm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 #ifdef CONFIG_HAS_PCI
 return pci_physdev_op(cmd, arg);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 11f970d926..43f30747cf 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1371,7 +1371,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
 HYPERCALL(xsm_op, 1),
 HYPERCALL(event_channel_op, 2),
 HYPERCALL_DEPRECATED(event_channel_op_compat, 1),
-HYPERCALL(physdev_op, 2),
+HYPERCALL_ARM(physdev_op, 2),
 HYPERCALL_DEPRECATED(physdev_op_compat, 1),
 HYPERCALL(sysctl, 2),
 HYPERCALL(hvm_op, 2),
-- 
2.34.1

Re: [PATCH v2] xen/arm: set CPSR Z bit when creating aarch32 guests

2022-03-24 Thread Bertrand Marquis

Hi Stefano,

Thanks a lot for the detailed answers.

> On 24 Mar 2022, at 03:05, Stefano Stabellini  wrote:
> 
> On Wed, 23 Mar 2022, Bertrand Marquis wrote:
>>> On 22 Mar 2022, at 21:28, Stefano Stabellini  wrote:
>>> 
>>> From: Stefano Stabellini 
>>> 
>>> The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
>>> kernel, certain versions of Linux will use an UNPREDICATABLE NOP
>>> encoding, sometimes resulting in an unbootable kernel. Whether the
>>> resulting kernel is bootable or not depends on the processor. See commit
>>> a92882a4d270 in the Linux kernel for all the details.
>>> 
>>> All kernel releases starting from Linux 4.9 without commit a92882a4d270
>>> are affected.
>> 
>> Can you confirm if those kernels are also affected when started natively ?
> 
> Theoretically yes, but in practice only booting on Xen is affected
> because:
> 
> - the issue cannot happen when booting from u-boot because u-boot sets
>  the "Z" bit
> - the issue cannot happen when booting with QEMU -kernel because it also
>  sets "Z"
> - older bootloaders on native skip the first 32 bytes of the start
>  address, which also masks this problem
> 
> Thus, in practice, I have no idea how one could reproduce the problem on
> native.
> 
> This info is in the commit message a92882a4d270 on Linux and in-code
> comments in the kernel.

If uboot is setting we can consider that we have a behaviour equivalent to
a native boot.
Could you add something in the comment in your patch to state that the Z
flag is also set by uboot ?
This will help in the future to remember why it is ok to have that as the
current comment could make one think that this is something only done by
Xen.

> 
> 
>>> Fortunately there is a simple workaround: setting the "Z" bit in CPSR
>>> make it so those invalid NOP instructions are never executed. That is
>>> because the instruction is conditional (not equal). So, on QEMU at
>>> least, the instruction will end up to be ignored and not generate an
>>> exception. Setting the "Z" bit makes those kernel versions bootable
>>> again and it is harmless in the other cases.
>> 
>> I agree with Jan here. This will never be set or should not be expected
>> to be set by anyone when started.
>> It feels to me that we are introducing an ack for a temporary issue in
>> Linux which will makes us derive from the behaviour that could be
>> expected on native hardware.
>> 
>> Could you give more details on how blocking this is ? 
> 
> Without this change, none of the Debian arm32 kernels boot on Xen after
> Jessie (on QEMU).

Ok

> 
> 
>> Is the kernel update with the fix available on any of the affected 
>> distributions ?
> 
> None that I could find. I tried Debian Buster, Debian Bullseye, Debian
> testing and the latest Alpine Linux. Happy to try more if you give me a
> download link or two.

I think the list is long enough to justify the change.

> 
> 
>> Depending on the answers I think we could for example have a config around
>> this to flag it as workaround for a specific guest issue so that this is only
>> activated when needed.
> 
> Also note that this alternative workaround also solves the problem,
> however it has other drawbacks as Julien described:
> [1] https://marc.info/?l=xen-devel&m=164774063802402

Definitely setting the Z bit is better I think.

> 
> 
> My take on this is the following. PSR_GUEST32_INIT is not part of the
> ABI so this cannot be considered an ABI change.
> 
> But in any case, given that without this change (or another change [1])
> most of the kernels out there don't work, is there a point in discussing
> ABI breakages? Basically nothing works right now :-D
> 
> I think it makes sense to think whether this change could cause a kernel
> that used to boot, not to boot anymore. However, I don't think is
> possible because:
> 
> - we only support zImage on arm32 and "Z" works well with it
> - both u-boot and qemu -kernel set "Z" so we would already now if
>  something broke
> 

Agree so please add that both in the comment and in the commit message.

Cheers
Bertrand

> 
> 
>>> Signed-off-by: Stefano Stabellini 
>>> ---
>>> Changes in v2:
>>> - improve commit message
>>> - add in-code comment
>>> - move PSR_Z to the beginning
>>> ---
>>> xen/include/public/arch-arm.h | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>>> index 94b31511dd..81cee95f14 100644
>>> --- a/xen/include/public/arch-arm.h
>>> +++ b/xen/include/public/arch-arm.h
>>> @@ -361,6 +361,7 @@ typedef uint64_t xen_callback_t;
>>> #define PSR_DBG_MASK(1<<9)/* arm64: Debug Exception mask */
>>> #define PSR_IT_MASK (0x0600fc00)  /* Thumb If-Then Mask */
>>> #define PSR_JAZELLE (1<<24)   /* Jazelle Mode */
>>> +#define PSR_Z   (1<<30)   /* Zero condition flag */
>>> 
>>> /* 32 bit modes */
>>> #define PSR_MODE_USR 0x10
>>> @@ -383,7 +384,12 @@ typedef uint64_t xen_callback_t;
>>> #define PSR_M

Re: [PATCH v5 02/10] xen: move do_vcpu_op() to arch specific code

2022-03-24 Thread Julien Grall


Hi Juergen,

On 24/03/2022 08:13, Juergen Gross wrote:

The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common handler. This leads to the
weird call hierarchy:

   do_arm_vcpu_op()
 do_vcpu_op()
   arch_do_vcpu_op()

Clean this up by renaming do_vcpu_op() to common_vcpu_op() and
arch_do_vcpu_op() in each architecture to do_vcpu_op(). This way one
of above calls can be avoided without restricting any potential
future use of common sub-ops for Arm.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v5 03/10] xen: harmonize return types of hypercall handlers

2022-03-24 Thread Jan Beulich

On 24.03.2022 09:13, Juergen Gross wrote:
> Today most hypercall handlers have a return type of long, while the
> --- a/xen/arch/x86/x86_64/platform_hypercall.c
> +++ b/xen/arch/x86/x86_64/platform_hypercall.c
> @@ -4,6 +4,7 @@
>  
>  EMIT_FILE;
>  
> +#include 
>  #include 
>  #include 
>  #include 

So I thought I could apply patches 4 and 5 alongside patch 1, but patch 4
contextually conflicts with the change above. Looking more closely I was
not able to understand (anymore) what the hunk above is good for: It adds
a redundant #include, just for patch 4 to remove the original instance.
In turn patch 5 then also conflicts, no matter what the correct resolution
would be in patch 4 when pulled ahead of patch 3.

Jan

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

2022-03-24 Thread Bertrand Marquis

cppcheck can be used to check Xen code quality.

To create a report do "make cppcheck" on a built tree adding any options
you added during the process you used to build xen (like CROSS_COMPILE
or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml.

To create a html report do "make cppcheck-html" in the same way and a
full report to be seen in a browser will be generated in
cppcheck-htmlreport/index.html.

For better results it is recommended to build your own cppcheck from the
latest sources that you can find at [1].
Development and result analysis has been done with cppcheck 2.7.

The Makefile rule is searching for all C files which have been compiled
(ie which have a generated .o file) and is running cppcheck on all of
them using the current configuration of xen so only the code actually
compiled is checked.

A new tool is introduced to merge all cppcheck reports into one global
report including all findings and removing duplicates.

Some extra variables can be used to customize the report:
- CPPCHECK can be used to give the full path to the cppcheck binary to
use (default is to use the one from the standard path).
- CPPCHECK_HTMLREPORT can be used to give the full path to
cppcheck-htmlreport (default is to use the one from the standard path).

This has been tested on several arm configurations (x86 should work but
has not been tested).

[1] https://cppcheck.sourceforge.io/

Signed-off-by: Bertrand Marquis 
Signed-off-by: Michal Orzel 
---
 .gitignore   |  3 ++
 xen/Makefile | 75 +++-
 xen/arch/arm/include/asm/processor.h |  4 +-
 xen/include/xen/config.h |  4 ++
 xen/include/xen/kconfig.h|  5 ++
 xen/tools/merge_cppcheck_reports.py  | 73 +++
 6 files changed, 161 insertions(+), 3 deletions(-)
 create mode 100755 xen/tools/merge_cppcheck_reports.py

diff --git a/.gitignore b/.gitignore
index d425be4bd9..0d2d60b8f1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,6 +7,7 @@
 *.o
 *.d
 *.d2
+*.c.cppcheck
 *.opic
 *.a
 *.so
@@ -296,6 +297,7 @@ xen/.banner
 xen/.config
 xen/.config.old
 xen/.xen.elf32
+xen/xen-cppcheck.xml
 xen/System.map
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/boot/cmdline.S
@@ -316,6 +318,7 @@ xen/arch/*/efi/runtime.c
 xen/arch/*/include/asm/asm-offsets.h
 xen/common/config_data.S
 xen/common/config.gz
+xen/cppcheck-htmlreport
 xen/include/headers*.chk
 xen/include/compat/*
 xen/include/config/
diff --git a/xen/Makefile b/xen/Makefile
index 18a4f7e101..0280d65051 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -336,7 +336,7 @@ export CFLAGS_UBSAN
 
 endif # need-config
 
-main-targets := build install uninstall clean distclean MAP
+main-targets := build install uninstall clean distclean MAP cppcheck 
cppcheck-html
 .PHONY: $(main-targets)
 ifneq ($(XEN_TARGET_ARCH),x86_32)
 $(main-targets): %: _% ;
@@ -424,15 +424,17 @@ _clean:
$(Q)$(MAKE) $(clean)=tools/kconfig
find . \( -name "*.o" -o -name ".*.d" -o -name ".*.d2" \
-o -name ".*.o.tmp" -o -name "*~" -o -name "core" \
-   -o -name '*.lex.c' -o -name '*.tab.[ch]' \
+   -o -name '*.lex.c' -o -name '*.tab.[ch]' -o -name 
'*.c.cppcheck' \
-o -name "*.gcno" -o -name ".*.cmd" -o -name "lib.a" \) -exec 
rm -f {} \;
rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map
rm -f asm-offsets.s arch/*/include/asm/asm-offsets.h
rm -f .banner .allconfig.tmp include/xen/compile.h
+   rm -f xen-cppcheck.xml
 
 .PHONY: _distclean
 _distclean: clean
rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out 
GTAGS GPATH GRTAGS GSYMS .config
+   rm -rf $(CPPCHECK_HTMLREPORT_OUTDIR)
 
 $(TARGET).gz: $(TARGET)
gzip -n -f -9 < $< > $@.new
@@ -511,6 +513,75 @@ cloc:
done; \
done | cloc --list-file=-
 
+# What cppcheck command to use.
+# To get proper results, it is recommended to build cppcheck manually from the
+# latest source and use CPPCHECK to give the full path to the built version.
+CPPCHECK ?= cppcheck
+
+# What cppcheck-htmlreport to use.
+# If you give the full path to a self compiled cppcheck, this should be set
+# to the full path to cppcheck-html in the htmlreport directory of cppcheck.
+# On recent distribution, this is available in the standard path.
+CPPCHECK_HTMLREPORT ?= cppcheck-htmlreport
+
+# By default we generate the report in cppcheck-htmlreport directory in the
+# build directory. This can be changed by giving a directory in this variable.
+CPPCHECK_HTMLREPORT_OUTDIR ?= cppcheck-htmlreport
+
+# Compile flags to pass to cppcheck:
+# - include directories and defines Xen Makefile is passing (from CFLAGS)
+# - include config.h as this is passed directly to the compiler.
+# - define CPPCHECK as we use to disable or enable some specific part of the
+#   code to solve some cppcheck issues.
+# - explicitely enable

Re: [PATCH v5 03/10] xen: harmonize return types of hypercall handlers

2022-03-24 Thread Juergen Gross


On 24.03.22 11:57, Jan Beulich wrote:

On 24.03.2022 09:13, Juergen Gross wrote:

Today most hypercall handlers have a return type of long, while the
--- a/xen/arch/x86/x86_64/platform_hypercall.c
+++ b/xen/arch/x86/x86_64/platform_hypercall.c
@@ -4,6 +4,7 @@
  
  EMIT_FILE;
  
+#include 

  #include 
  #include 
  #include 


This seems to be an artifact of the rebase done in V4 of the series, which
was necessary as Andrew's large series used two patches of my V3 series.

Do you want me to resend without this hunk?


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[xen-unstable test] 168815: tolerable FAIL

2022-03-24 Thread osstest service owner

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

Failures :-/ but no regressions.

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

[ovmf test] 168820: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   23 days  241 attempts
Testing same since   168774  2022-03-22 08:40:31 Z2 days   22 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

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

2022-03-24 Thread Rahul Singh

Hello Jan,

Thanks for reviewing the design.

> On 23 Mar 2022, at 4:07 pm, Jan Beulich  wrote:
> 
> On 23.03.2022 16:43, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less system.
>> 
>> Signed-off-by: Rahul Singh 
>> ---
>> docs/designs/dom0less-evtchn.md | 96 +
>> 1 file changed, 96 insertions(+)
>> create mode 100644 docs/designs/dom0less-evtchn.md
>> 
>> diff --git a/docs/designs/dom0less-evtchn.md 
>> b/docs/designs/dom0less-evtchn.md
>> new file mode 100644
>> index 00..6a1b7e8c22
>> --- /dev/null
>> +++ b/docs/designs/dom0less-evtchn.md
>> @@ -0,0 +1,96 @@
>> +# Signaling support between two domUs on dom0less system
>> +
>> +## Current state: Draft version
>> +
>> +## Proposer(s): Rahul Singh, Bertrand Marquis
>> +
>> +## Problem Statement:
>> +
>> +The goal of this work is to define a simple signaling system between Xen 
>> guests
>> +in dom0less systems.
>> +
>> +In dom0less system, we cannot make use of xenbus and xenstore that are used 
>> in
>> +normal systems with dynamic VMs to communicate between domains by providing 
>> a
>> +bus abstraction for paravirtualized drivers.
>> +
>> +One possible solution to implement the signaling system between domUs is 
>> based
>> +on event channels.
>> +
>> +## Proposal:
>> +
>> +Event channels are the basic primitive provided by Xen for event 
>> notifications.
>> +An event channel is a logical connection between 2 domains (more 
>> specifically
>> +between dom1,port1 and dom2,port2). They essentially store one bit of
>> +information, the event of interest is signalled by transitioning this bit 
>> from
>> +0 to 1. An event is an equivalent of a hardware interrupt.
> 
> Nit: Since you're talking of channels here, not ports, strictly speaking
> it's two bits - one on each side. Alternatively instead of "They ..."
> you could say "Each port ...".
> 

Ack. I will correct it in next version.

>> +Notifications are received by a guest via an interrupt from Xen to the 
>> guest,
>> +indicating when an event arrives (setting the bit). Further notifications 
>> are
>> +masked until the bit is cleared again. When a domain wants to wait for data 
>> it
>> +will block until an event arrives, and then send an event to signal that 
>> data
>> +has been consumed. Events are delivered asynchronously to guests and are
>> +enqueued when the guest is not running.
>> +
>> +Event channel communication will be established statically between two domU
>> +guests before unpausing the domains after domain creation. Event channel
>> +connection information between domUs will be passed to XEN via device tree
>> +node.
>> +
>> +Under the /chosen node, there needs to be sub nodes with compatible
>> +"xen,evtchn" that descibes the event channel connection between two domUs.
>> +
>> +The event channel sub-node has the following properties:
>> +
>> +- compatible
>> +
>> +"xen,evtchn"
>> +
>> +- xen,evtchn
>> +
>> +The property is four numbers of tuples of
>> +(local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:
> 
> Nit: I think you mean "tuples of four numbers"?

Yes, you are right I will fix this.
> 
>> +local-port-domU1 is an integer value that will be used to allocte local
>> +port for domU1 to send an event notification to the remote domain.
>> +
>> +domU1-phandle is a single phandle to an domain to which local-port-domU1
>> +will be allocated.
>> +
>> +local-port-domU2 is an integer value that will be used to allocte local
>> +port for domU2 to send an event notification to the remote domain.
>> +
>> +domU2-phandle is a single phandle to an domain to which local-port-domU2
>> +will be allocated.
>> +
>> +Example:
>> +
>> +chosen {
>> +
>> +
>> +domU1: domU1 {
>> +..
>> +};
>> +
>> +domU2: domU2 {
>> +..
>> +};
>> +
>> +evtchn@1 {
>> +compatible = "xen,evtchn";
>> +xen,evtchn = <0xa &domU1 0xb &domU2>;
>> +};
>> +
>> +evtchn@2 {
>> +compatible = "xen,evtchn";
>> +xen,evtchn = <0xc &domU1 0xd &domU2>;
>> +};
>> +};
>> +
>> +In above example two event channel comunication will be established between
>> +domU1 and domU2.
>> +
>> +domU1 (port 0xa) <-> domU2 (port 0xb)
>> +domU1 (port 0xc) <-> domU2 (port 0xd)
>> +
>> +domU1 and domU2 can send the signal to remote domain via hypercall
>> +EVTCHNOP_send(.) on local port.
> 
> How do the DomU-s learn of these ports? I guess information is to be
> extracted into their individual DT representation, but this could do
> with spelling out, including how those nodes (or however the data
> items are called in DT) would be named and what data they would
> contain.

There are two options how the guest learn the local ports.

1. Document the event channel connecti

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

2022-03-24 Thread Julien Grall


Hi Bertrand,

On 24/03/2022 11:04, Bertrand Marquis wrote:

cppcheck can be used to check Xen code quality.


Is there anything we should be concerned of in the initial report?



To create a report do "make cppcheck" on a built tree adding any options
you added during the process you used to build xen (like CROSS_COMPILE
or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml.

To create a html report do "make cppcheck-html" in the same way and a
full report to be seen in a browser will be generated in
cppcheck-htmlreport/index.html.

For better results it is recommended to build your own cppcheck from the
latest sources that you can find at [1].
Development and result analysis has been done with cppcheck 2.7.


We want to write down the minimum version of cppcheck we are going to 
support. My suggestion would be to use the version you picked for your 
development.




The Makefile rule is searching for all C files which have been compiled
(ie which have a generated .o file) and is running cppcheck on all of
them using the current configuration of xen so only the code actually
compiled is checked.

A new tool is introduced to merge all cppcheck reports into one global
report including all findings and removing duplicates.

Some extra variables can be used to customize the report:
- CPPCHECK can be used to give the full path to the cppcheck binary to
use (default is to use the one from the standard path).
- CPPCHECK_HTMLREPORT can be used to give the full path to
cppcheck-htmlreport (default is to use the one from the standard path).

This has been tested on several arm configurations (x86 should work but
has not been tested).

[1] https://cppcheck.sourceforge.io/

Signed-off-by: Bertrand Marquis 
Signed-off-by: Michal Orzel 
---
  .gitignore   |  3 ++
  xen/Makefile | 75 +++-
  xen/arch/arm/include/asm/processor.h |  4 +-
  xen/include/xen/config.h |  4 ++
  xen/include/xen/kconfig.h|  5 ++
  xen/tools/merge_cppcheck_reports.py  | 73 +++


In the long term, I think it would be useful if we generate the report 
regularly. We might be able to hook the script that generate 
https://xenbits.xen.org/docs/.



diff --git a/xen/arch/arm/include/asm/processor.h 
b/xen/arch/arm/include/asm/processor.h
index 852b5f3c24..0b4ba73760 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)
  
-#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xUL

+#ifndef CPPCHECK
+#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xULL
  #error "Inconsistent SCTLR_EL2 set/clear bits"
  #endif
+#endif


Why is it necessary?

Cheers,

--
Julien Grall

[ovmf test] 168822: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   23 days  242 attempts
Testing same since   168774  2022-03-22 08:40:31 Z2 days   23 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

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

2022-03-24 Thread David Vrabel





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

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

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

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


This problem statement could do with some example use cases that are 
usefully solved by this proposed solution.


"We don't have xenstore so can't set up shared rings, but here's a 
replacement comms mechanism that can do a single bit." Doesn't seem very 
compelling to me.



+chosen {
+
+
+domU1: domU1 {
+..
+};
+
+domU2: domU2 {
+..
+};
+
+evtchn@1 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xa &domU1 0xb &domU2>;
+};
+
+evtchn@2 {
+compatible = "xen,evtchn";
+xen,evtchn = <0xc &domU1 0xd &domU2>;
+};


How is the domain supposed to know what these event channels are for?

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


David

Re: blocking vs. non-blocking mmu notifiers

2022-03-24 Thread Michal Hocko

On Wed 23-03-22 14:04:04, Jason Gunthorpe wrote:
> On Wed, Mar 23, 2022 at 05:49:43PM +0100, Michal Hocko wrote:
> > > The bug here is that prior to commit a81461b0546c ("xen/gntdev: update
> > > to new mmu_notifier semantic") wired the mn_invl_range_start() which
> > > takes a mutex to invalidate_page, which is defined to run in an atomic
> > > context.
> > 
> > Yeah, we have already identified that but quickly realized that the
> > whole mmu notifier overhaul which this fix depends on would be no no for
> > backporting to our older code base. So we are trying to find our way
> > around that.
> 
> IMHO you don't need everything, just commit 369ea8242c0f ("mm/rmap:
> update to new mmu_notifier semantic v2") which adds the missing
> start/end outside the lock for the page callbacks.
> 
> Then you can take safely a8146 into gntdev.

Thanks Jason!

-- 
Michal Hocko
SUSE Labs

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

2022-03-24 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linuxed4643521e6af8ab8ed1e467630a85884d2696cf
baseline version:
 linux1bc191051dca28fa6d20fd1dc34a1903e7d4fb62

Last test of basis   168807  2022-03-23 19:39:56 Z0 days
Testing same since   168816  2022-03-24 03:18:14 Z0 days1 attempts


550 people touched revisions under test,
not listing them all

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

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

2022-03-24 Thread Bertrand Marquis

Hi Julien,

> On 24 Mar 2022, at 13:00, Julien Grall  wrote:
> 
> Hi Bertrand,
> 
> On 24/03/2022 11:04, Bertrand Marquis wrote:
>> cppcheck can be used to check Xen code quality.
> 
> Is there anything we should be concerned of in the initial report?

Nothing major no.
Michal will soon push a serie with a first set of fixes, mostly related to 
unused variables.

> 
>> To create a report do "make cppcheck" on a built tree adding any options
>> you added during the process you used to build xen (like CROSS_COMPILE
>> or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml.
>> To create a html report do "make cppcheck-html" in the same way and a
>> full report to be seen in a browser will be generated in
>> cppcheck-htmlreport/index.html.
>> For better results it is recommended to build your own cppcheck from the
>> latest sources that you can find at [1].
>> Development and result analysis has been done with cppcheck 2.7.
> 
> We want to write down the minimum version of cppcheck we are going to 
> support. My suggestion would be to use the version you picked for your 
> development.

Agree, 2.7 (current stable) should be the one as we had some unstable 
behaviours with other versions.
Should I put that in the main readme ?

> 
>> The Makefile rule is searching for all C files which have been compiled
>> (ie which have a generated .o file) and is running cppcheck on all of
>> them using the current configuration of xen so only the code actually
>> compiled is checked.
>> A new tool is introduced to merge all cppcheck reports into one global
>> report including all findings and removing duplicates.
>> Some extra variables can be used to customize the report:
>> - CPPCHECK can be used to give the full path to the cppcheck binary to
>> use (default is to use the one from the standard path).
>> - CPPCHECK_HTMLREPORT can be used to give the full path to
>> cppcheck-htmlreport (default is to use the one from the standard path).
>> This has been tested on several arm configurations (x86 should work but
>> has not been tested).
>> [1] https://cppcheck.sourceforge.io/
>> Signed-off-by: Bertrand Marquis 
>> Signed-off-by: Michal Orzel 
>> ---
>>  .gitignore   |  3 ++
>>  xen/Makefile | 75 +++-
>>  xen/arch/arm/include/asm/processor.h |  4 +-
>>  xen/include/xen/config.h |  4 ++
>>  xen/include/xen/kconfig.h|  5 ++
>>  xen/tools/merge_cppcheck_reports.py  | 73 +++
> 
> In the long term, I think it would be useful if we generate the report 
> regularly. We might be able to hook the script that generate 
> https://xenbits.xen.org/docs/.

Agree

> 
>> diff --git a/xen/arch/arm/include/asm/processor.h 
>> b/xen/arch/arm/include/asm/processor.h
>> index 852b5f3c24..0b4ba73760 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)
>>  -#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xUL
>> +#ifndef CPPCHECK
>> +#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xULL
>>  #error "Inconsistent SCTLR_EL2 set/clear bits"
>>  #endif
>> +#endif
> 
> Why is it necessary?

The ULL was an attempt to fix but did not work. I will remove that in the next 
version.
Here cppcheck preprocessor is wrongly generating the error for a reason that I 
could not understand, hence the ifdef.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

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

2022-03-24 Thread Andrew Cooper

On 24/03/2022 11:04, Bertrand Marquis wrote:
> cppcheck can be used to check Xen code quality.
>
> To create a report do "make cppcheck" on a built tree adding any options
> you added during the process you used to build xen (like CROSS_COMPILE
> or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml.
>
> To create a html report do "make cppcheck-html" in the same way and a
> full report to be seen in a browser will be generated in
> cppcheck-htmlreport/index.html.
>
> For better results it is recommended to build your own cppcheck from the
> latest sources that you can find at [1].
> Development and result analysis has been done with cppcheck 2.7.
>
> The Makefile rule is searching for all C files which have been compiled
> (ie which have a generated .o file) and is running cppcheck on all of
> them using the current configuration of xen so only the code actually
> compiled is checked.
>
> A new tool is introduced to merge all cppcheck reports into one global
> report including all findings and removing duplicates.
>
> Some extra variables can be used to customize the report:
> - CPPCHECK can be used to give the full path to the cppcheck binary to
> use (default is to use the one from the standard path).
> - CPPCHECK_HTMLREPORT can be used to give the full path to
> cppcheck-htmlreport (default is to use the one from the standard path).
>
> This has been tested on several arm configurations (x86 should work but
> has not been tested).
>
> [1] https://cppcheck.sourceforge.io/
>
> Signed-off-by: Bertrand Marquis 
> Signed-off-by: Michal Orzel 

Does CPPCheck have configurable errors vs warnings?  Should we wire this
into CI so we can fail builds which introduce errors that we've already
managed to purge from the codebase?

Also, please include Anthony on future patches, given the extent of
makefile changes.

~Andrew

> ---
>  .gitignore   |  3 ++
>  xen/Makefile | 75 +++-
>  xen/arch/arm/include/asm/processor.h |  4 +-
>  xen/include/xen/config.h |  4 ++
>  xen/include/xen/kconfig.h|  5 ++
>  xen/tools/merge_cppcheck_reports.py  | 73 +++
>  6 files changed, 161 insertions(+), 3 deletions(-)
>  create mode 100755 xen/tools/merge_cppcheck_reports.py
>
> diff --git a/.gitignore b/.gitignore
> index d425be4bd9..0d2d60b8f1 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -7,6 +7,7 @@
>  *.o
>  *.d
>  *.d2
> +*.c.cppcheck
>  *.opic
>  *.a
>  *.so
> @@ -296,6 +297,7 @@ xen/.banner
>  xen/.config
>  xen/.config.old
>  xen/.xen.elf32
> +xen/xen-cppcheck.xml
>  xen/System.map
>  xen/arch/x86/boot/mkelf32
>  xen/arch/x86/boot/cmdline.S
> @@ -316,6 +318,7 @@ xen/arch/*/efi/runtime.c
>  xen/arch/*/include/asm/asm-offsets.h
>  xen/common/config_data.S
>  xen/common/config.gz
> +xen/cppcheck-htmlreport
>  xen/include/headers*.chk
>  xen/include/compat/*
>  xen/include/config/
> diff --git a/xen/Makefile b/xen/Makefile
> index 18a4f7e101..0280d65051 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -336,7 +336,7 @@ export CFLAGS_UBSAN
>  
>  endif # need-config
>  
> -main-targets := build install uninstall clean distclean MAP
> +main-targets := build install uninstall clean distclean MAP cppcheck 
> cppcheck-html
>  .PHONY: $(main-targets)
>  ifneq ($(XEN_TARGET_ARCH),x86_32)
>  $(main-targets): %: _% ;
> @@ -424,15 +424,17 @@ _clean:
>   $(Q)$(MAKE) $(clean)=tools/kconfig
>   find . \( -name "*.o" -o -name ".*.d" -o -name ".*.d2" \
>   -o -name ".*.o.tmp" -o -name "*~" -o -name "core" \
> - -o -name '*.lex.c' -o -name '*.tab.[ch]' \
> + -o -name '*.lex.c' -o -name '*.tab.[ch]' -o -name 
> '*.c.cppcheck' \
>   -o -name "*.gcno" -o -name ".*.cmd" -o -name "lib.a" \) -exec 
> rm -f {} \;
>   rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 
> $(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map
>   rm -f asm-offsets.s arch/*/include/asm/asm-offsets.h
>   rm -f .banner .allconfig.tmp include/xen/compile.h
> + rm -f xen-cppcheck.xml
>  
>  .PHONY: _distclean
>  _distclean: clean
>   rm -f tags TAGS cscope.files cscope.in.out cscope.out cscope.po.out 
> GTAGS GPATH GRTAGS GSYMS .config
> + rm -rf $(CPPCHECK_HTMLREPORT_OUTDIR)
>  
>  $(TARGET).gz: $(TARGET)
>   gzip -n -f -9 < $< > $@.new
> @@ -511,6 +513,75 @@ cloc:
>   done; \
>   done | cloc --list-file=-
>  
> +# What cppcheck command to use.
> +# To get proper results, it is recommended to build cppcheck manually from 
> the
> +# latest source and use CPPCHECK to give the full path to the built version.
> +CPPCHECK ?= cppcheck
> +
> +# What cppcheck-htmlreport to use.
> +# If you give the full path to a self compiled cppcheck, this should be set
> +# to the full path to cppcheck-html in the htmlreport directory of cppcheck.
> +# On recent distribution, this is available in the standard path.
> +CPPCHECK_HTMLREPORT ?= cppcheck-htmlrepor

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

2022-03-24 Thread Bertrand Marquis

Hi Andrew,

> On 24 Mar 2022, at 14:06, Andrew Cooper  wrote:
> 
> On 24/03/2022 11:04, Bertrand Marquis wrote:
>> cppcheck can be used to check Xen code quality.
>> 
>> To create a report do "make cppcheck" on a built tree adding any options
>> you added during the process you used to build xen (like CROSS_COMPILE
>> or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml.
>> 
>> To create a html report do "make cppcheck-html" in the same way and a
>> full report to be seen in a browser will be generated in
>> cppcheck-htmlreport/index.html.
>> 
>> For better results it is recommended to build your own cppcheck from the
>> latest sources that you can find at [1].
>> Development and result analysis has been done with cppcheck 2.7.
>> 
>> The Makefile rule is searching for all C files which have been compiled
>> (ie which have a generated .o file) and is running cppcheck on all of
>> them using the current configuration of xen so only the code actually
>> compiled is checked.
>> 
>> A new tool is introduced to merge all cppcheck reports into one global
>> report including all findings and removing duplicates.
>> 
>> Some extra variables can be used to customize the report:
>> - CPPCHECK can be used to give the full path to the cppcheck binary to
>> use (default is to use the one from the standard path).
>> - CPPCHECK_HTMLREPORT can be used to give the full path to
>> cppcheck-htmlreport (default is to use the one from the standard path).
>> 
>> This has been tested on several arm configurations (x86 should work but
>> has not been tested).
>> 
>> [1] https://cppcheck.sourceforge.io/
>> 
>> Signed-off-by: Bertrand Marquis 
>> Signed-off-by: Michal Orzel 
> 
> Does CPPCheck have configurable errors vs warnings?  Should we wire this
> into CI so we can fail builds which introduce errors that we've already
> managed to purge from the codebase?

No we cannot configure which findings are errors or warnings.
What we can (and probably will) do is create a list of cppcheck rules that we
want to check and pass that to cppcheck (can be done using a text file). Once
this is done and all findings are solved we should definitely add cppcheck to 
the
CI and fail builds when errors are introduced.

> 
> Also, please include Anthony on future patches, given the extent of
> makefile changes.

I will for sure.

Cheers
Bertrand

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

2022-03-24 Thread Michal Orzel




On 24.03.2022 14:06, Andrew Cooper wrote:
> On 24/03/2022 11:04, Bertrand Marquis wrote:
>> cppcheck can be used to check Xen code quality.
>>
>> To create a report do "make cppcheck" on a built tree adding any options
>> you added during the process you used to build xen (like CROSS_COMPILE
>> or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml.
>>
>> To create a html report do "make cppcheck-html" in the same way and a
>> full report to be seen in a browser will be generated in
>> cppcheck-htmlreport/index.html.
>>
>> For better results it is recommended to build your own cppcheck from the
>> latest sources that you can find at [1].
>> Development and result analysis has been done with cppcheck 2.7.
>>
>> The Makefile rule is searching for all C files which have been compiled
>> (ie which have a generated .o file) and is running cppcheck on all of
>> them using the current configuration of xen so only the code actually
>> compiled is checked.
>>
>> A new tool is introduced to merge all cppcheck reports into one global
>> report including all findings and removing duplicates.
>>
>> Some extra variables can be used to customize the report:
>> - CPPCHECK can be used to give the full path to the cppcheck binary to
>> use (default is to use the one from the standard path).
>> - CPPCHECK_HTMLREPORT can be used to give the full path to
>> cppcheck-htmlreport (default is to use the one from the standard path).
>>
>> This has been tested on several arm configurations (x86 should work but
>> has not been tested).
>>
>> [1] https://cppcheck.sourceforge.io/
>>
>> Signed-off-by: Bertrand Marquis 
>> Signed-off-by: Michal Orzel 
> 
> Does CPPCheck have configurable errors vs warnings?  Should we wire this
> into CI so we can fail builds which introduce errors that we've already
> managed to purge from the codebase?
> 
For cppcheck, every finding is an error as it is placed within  section 
in XML.
cppcheck differentiates different types of findings by using "severity" element 
which can be e.g. error, style, warning, etc.
cppcheck-html uses this field to group findings into categories and present it 
in a nice format to be seen on a web browser.
However there is currently no way to tell cppcheck to find only errors.

Cheers,
Michal

[ovmf test] 168823: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   23 days  243 attempts
Testing same since   168774  2022-03-22 08:40:31 Z2 days   24 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

[PATCH v12] xen/arm64: io: Handle data abort due to cache maintenance instructions

2022-03-24 Thread Ayan Kumar Halder

When the data abort is caused due to cache maintenance for an address,
there are three scenarios:-

1. Address belonging to a non emulated region - For this, Xen should
set the corresponding bit in the translation table entry to valid and
return to the guest to retry the instruction. This can happen sometimes
as Xen need to set the translation table entry to invalid. (for eg
'Break-Before-Make' sequence). Xen returns to the guest to retry the
instruction.

2. Address belongs to an emulated region - Xen should ignore the
instruction (ie increment the PC) and return to the guest.

3. Address is invalid - Xen should forward the data abort to the guest.

Signed-off-by: Ayan Kumar Halder 
---

Changelog:-

v1...v8 - NA

v9 - Extracted this change from "[XEN v7 2/2] xen/arm64: io: Support
instructions (for which ISS is not ..." into a separate patch of its
own. The reason being this addresses an existing bug in the codebase.

v10 - 1. To check if the address belongs to an emulated region, one
needs to check if it has a mmio handler or an ioreq server. In this
case, Xen should increment the PC
2. If the address is invalid (niether emulated MMIO nor the translation
could be resolved via p2m or mapping the MMIO region), then Xen should
forward the abort to the guest.

v11 - 1. Removed the un-necessary check "( instr.state == INSTR_CACHE )"
in handle_ioserv(). The reason being the ioserv request is not forwarded
by try_fwd_ioserv() when instr.state == INSTR_CACHE.

v12 - 1. try_handle_mmio() should assert for "(info->dabt.valid || 
(info->dabt_instr.state == INSTR_CACHE))"
2. In try_fwd_ioserv(), ioreq size should be set to the cache line size
for INSTR_CACHE. Also ioreq data should be set only when ISS is valid.

 xen/arch/arm/include/asm/mmio.h |  1 +
 xen/arch/arm/io.c   | 20 +++-
 xen/arch/arm/ioreq.c| 14 --
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/include/asm/mmio.h b/xen/arch/arm/include/asm/mmio.h
index ca259a79c2..79e64d9af8 100644
--- a/xen/arch/arm/include/asm/mmio.h
+++ b/xen/arch/arm/include/asm/mmio.h
@@ -35,6 +35,7 @@ enum instr_decode_state
  * instruction.
  */
 INSTR_LDR_STR_POSTINDEXING,
+INSTR_CACHE,/* Cache Maintenance instr */
 };
 
 typedef struct
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 6f458ee7fd..4ce94243aa 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -139,6 +139,17 @@ void try_decode_instruction(const struct cpu_user_regs 
*regs,
 return;
 }
 
+/*
+ * When the data abort is caused due to cache maintenance, Xen should check
+ * if the address belongs to an emulated MMIO region or not. The behavior
+ * will differ accordingly.
+ */
+if ( info->dabt.cache )
+{
+info->dabt_instr.state = INSTR_CACHE;
+return;
+}
+
 /*
  * Armv8 processor does not provide a valid syndrome for decoding some
  * instructions. So in order to process these instructions, Xen must
@@ -161,7 +172,7 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
 
 ASSERT(info->dabt.ec == HSR_EC_DATA_ABORT_LOWER_EL);
 
-if ( !info->dabt.valid )
+if ( !(info->dabt.valid || (info->dabt_instr.state == INSTR_CACHE)) )
 {
 ASSERT_UNREACHABLE();
 return IO_ABORT;
@@ -177,6 +188,13 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
 return rc;
 }
 
+/*
+ * When the data abort is caused due to cache maintenance and the address
+ * belongs to an emulated region, Xen should ignore this instruction.
+ */
+if ( info->dabt_instr.state == INSTR_CACHE )
+return IO_HANDLED;
+
 /*
  * At this point, we know that the instruction is either valid or has been
  * decoded successfully. Thus, Xen should be allowed to execute the
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 54167aebcb..87a6240f2a 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@ -47,7 +47,7 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
  struct vcpu *v, mmio_info_t *info)
 {
 struct vcpu_io *vio = &v->io;
-struct instr_details instr = info->dabt_instr;
+const struct instr_details instr = info->dabt_instr;
 struct hsr_dabt dabt = info->dabt;
 ioreq_t p = {
 .type = IOREQ_TYPE_COPY,
@@ -62,7 +62,6 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
  * memory access. So for now, we can safely always set to 0.
  */
 .df = 0,
-.data = get_user_reg(regs, info->dabt.reg),
 .state = STATE_IOREQ_READY,
 };
 struct ioreq_server *s = NULL;
@@ -74,12 +73,23 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
 return IO_ABORT;
 }
 
+if ( instr.state == INSTR_CACHE )
+p.size = dcache_line_bytes;
+
 s = ioreq_server_select(v->domain, &p);
 if ( !s )
 return IO_UNHANDLED;
 
+

Support status of OpenBSD frontend drivers

2022-03-24 Thread Demi Marie Obenour

As per private discussion with Theo de Raadt, OpenBSD does not consider
bugs in its xnf(4) that allow a backend to cause mischief to be security
issues.  I believe the same applies to its xbf(4).  Should the support
document be updated?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab


signature.asc
Description: PGP signature

Re: [PATCH v5 03/10] xen: harmonize return types of hypercall handlers

2022-03-24 Thread Jan Beulich

On 24.03.2022 12:19, Juergen Gross wrote:
> On 24.03.22 11:57, Jan Beulich wrote:
>> On 24.03.2022 09:13, Juergen Gross wrote:
>>> Today most hypercall handlers have a return type of long, while the
>>> --- a/xen/arch/x86/x86_64/platform_hypercall.c
>>> +++ b/xen/arch/x86/x86_64/platform_hypercall.c
>>> @@ -4,6 +4,7 @@
>>>   
>>>   EMIT_FILE;
>>>   
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include 
> 
> This seems to be an artifact of the rebase done in V4 of the series, which
> was necessary as Andrew's large series used two patches of my V3 series.
> 
> Do you want me to resend without this hunk?

Well, I'd also be fine if you tell me the proper resolution of the
issue in the next patch. I guess the hunk there than also needs
dropping? And patch 5 adjusting accordingly for context? Overall
it may indeed be better if you resent ...

Jan

[PATCH v6 0/9] xen: drop hypercall function tables

2022-03-24 Thread Juergen Gross

In order to avoid indirect function calls on the hypercall path as
much as possible this series is removing the hypercall function tables
and is replacing the hypercall handler calls via the function array
by automatically generated call macros.

Another by-product of generating the call macros is the automatic
generating of the hypercall handler prototypes from the same data base
which is used to generate the macros.

This has the additional advantage of using type safe calls of the
handlers and to ensure related handler (e.g. PV and HVM ones) share
the same prototypes.

A very brief performance test (parallel build of the Xen hypervisor
in a 6 vcpu guest) showed a very slim improvement (less than 1%) of
the performance with the patches applied. The test was performed using
a PV and a PVH guest.

Changes in V2:
- new patches 6, 14, 15
- patch 7: support hypercall priorities for faster code
- comments addressed

Changes in V3:
- patches 1 and 4 removed as already applied
- comments addressed

Changes in V4:
- 5 patches removed al already applied
- new patches 1, 3 and 11
- avoid switching Arm hypercall handlers to return long (no change of
  handlers returning long already)

Changes in V5:
- patch 3 of V4 has been applied already
- comments addressed
- rebase

Changes in V6:
- patch 1 of V5 has been applied already
- fix of a rebase artifact

Juergen Gross (9):
  xen: move do_vcpu_op() to arch specific code
  xen: harmonize return types of hypercall handlers
  xen: don't include asm/hypercall.h from C sources
  xen: include compat/platform.h from hypercall.h
  xen: generate hypercall interface related code
  xen: use generated prototypes for hypercall handlers
  xen/x86: call hypercall handlers via generated macro
  xen/arm: call hypercall handlers via generated macro
  xen/x86: remove cf_check attribute from hypercall handlers

 .gitignore   |   1 +
 xen/arch/arm/domain.c|  15 +-
 xen/arch/arm/hvm.c   |   3 +-
 xen/arch/arm/include/asm/hypercall.h |   7 +-
 xen/arch/arm/platform_hypercall.c|   1 +
 xen/arch/arm/traps.c | 117 ++---
 xen/arch/x86/compat.c|   6 +-
 xen/arch/x86/cpu/mcheck/mce.c|   2 +-
 xen/arch/x86/cpu/vpmu.c  |   3 +-
 xen/arch/x86/domain.c|  11 +-
 xen/arch/x86/domctl.c|   4 +-
 xen/arch/x86/hvm/dm.c|   2 +-
 xen/arch/x86/hvm/hvm.c   |   2 +-
 xen/arch/x86/hvm/hypercall.c | 177 ++---
 xen/arch/x86/hypercall.c |  59 -
 xen/arch/x86/include/asm/hypercall.h | 201 ---
 xen/arch/x86/include/asm/paging.h|   3 -
 xen/arch/x86/mm.c|  13 +-
 xen/arch/x86/mm/paging.c |   3 +-
 xen/arch/x86/physdev.c   |   2 +-
 xen/arch/x86/platform_hypercall.c|   3 +-
 xen/arch/x86/pv/callback.c   |  26 +-
 xen/arch/x86/pv/descriptor-tables.c  |   8 +-
 xen/arch/x86/pv/emul-priv-op.c   |   2 +-
 xen/arch/x86/pv/hypercall.c  | 187 ++
 xen/arch/x86/pv/iret.c   |   5 +-
 xen/arch/x86/pv/misc-hypercalls.c|  22 +-
 xen/arch/x86/pv/shim.c   |   4 +-
 xen/arch/x86/traps.c |   2 +-
 xen/arch/x86/x86_64/compat/mm.c  |   3 +-
 xen/arch/x86/x86_64/domain.c |  16 +-
 xen/arch/x86/x86_64/mm.c |   2 -
 xen/arch/x86/x86_64/platform_hypercall.c |   1 -
 xen/common/argo.c|   8 +-
 xen/common/compat/domain.c   |  15 +-
 xen/common/compat/grant_table.c  |   3 +-
 xen/common/compat/kernel.c   |   2 +-
 xen/common/compat/memory.c   |   3 +-
 xen/common/dm.c  |   2 +-
 xen/common/domain.c  |  14 +-
 xen/common/domctl.c  |   2 +-
 xen/common/event_channel.c   |   3 +-
 xen/common/grant_table.c |   4 +-
 xen/common/hypfs.c   |   2 +-
 xen/common/kernel.c  |   2 +-
 xen/common/kexec.c   |   6 +-
 xen/common/memory.c  |   2 +-
 xen/common/multicall.c   |   4 +-
 xen/common/sched/compat.c|   2 +-
 xen/common/sched/core.c  |   4 +-
 xen/common/sysctl.c  |   2 +-
 xen/common/xenoprof.c|   2 +-
 xen/drivers/char/console.c   |   2 +-
 xen/include/Makefile |  13 +
 xen/include/hypercall-defs.c | 285 
 xen/include/xen/hypercall.h  | 185 +
 xen/scripts/gen_hypercall.awk| 314 +++
 xen/xsm/xsm_core.c   |   4 +-
 58 files changed, 861 insertions(+), 937 deletions(-)
 create mode 100644 xen/include/hyp

[PATCH v6 2/9] xen: harmonize return types of hypercall handlers

2022-03-24 Thread Juergen Gross

Today most hypercall handlers have a return type of long, while the
compat ones return an int. There are a few exceptions from that rule,
however.

Get rid of the exceptions by letting compat handlers always return int
and others always return long, with the exception of the Arm specific
physdev_op handler.

For the compat hvm case use eax instead of rax for the stored result as
it should have been from the beginning.

Additionally move some prototypes to include/asm-x86/hypercall.h
as they are x86 specific. Move the compat_platform_op() prototype to
the common header.

Rename paging_domctl_continuation() to do_paging_domctl_cont() and add
a matching define for the associated hypercall.

Make do_callback_op() and compat_callback_op() more similar by adding
the const attribute to compat_callback_op()'s 2nd parameter.

Change the type of the cmd parameter for [do|compat]_kexec_op() to
unsigned int, as this is more appropriate for the compat case.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
---
V2:
- rework platform_op compat handling (Jan Beulich)
V3:
- remove include of types.h (Jan Beulich)
V4:
- don't move do_physdev_op() (Julien Grall)
- carve out non style compliant parameter replacements (Julien Grall)
V6:
- remove rebase artifact (Jan Beulich)
---
 xen/arch/x86/domctl.c|  4 ++--
 xen/arch/x86/hvm/hypercall.c |  8 ++-
 xen/arch/x86/hypercall.c |  2 +-
 xen/arch/x86/include/asm/hypercall.h | 31 ++--
 xen/arch/x86/include/asm/paging.h|  3 ---
 xen/arch/x86/mm/paging.c |  3 ++-
 xen/arch/x86/pv/callback.c   | 14 ++---
 xen/arch/x86/pv/emul-priv-op.c   |  2 +-
 xen/arch/x86/pv/hypercall.c  |  5 +
 xen/arch/x86/pv/iret.c   |  4 ++--
 xen/arch/x86/pv/misc-hypercalls.c| 14 -
 xen/common/argo.c|  6 +++---
 xen/common/kexec.c   |  6 +++---
 xen/include/xen/hypercall.h  | 20 --
 14 files changed, 58 insertions(+), 64 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index e49f9e91b9..ea7d60ffb6 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -221,8 +221,8 @@ long arch_do_domctl(
 case XEN_DOMCTL_shadow_op:
 ret = paging_domctl(d, &domctl->u.shadow_op, u_domctl, 0);
 if ( ret == -ERESTART )
-return hypercall_create_continuation(__HYPERVISOR_arch_1,
- "h", u_domctl);
+return hypercall_create_continuation(
+   __HYPERVISOR_paging_domctl_cont, "h", u_domctl);
 copyback = true;
 break;
 
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 62b5349e7d..3a35543997 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -124,8 +124,6 @@ static long cf_check hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 [ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) do_ ## x,  \
(hypercall_fn_t *) compat_ ## x }
 
-#define do_arch_1 paging_domctl_continuation
-
 static const struct {
 hypercall_fn_t *native, *compat;
 } hvm_hypercall_table[] = {
@@ -158,11 +156,9 @@ static const struct {
 #ifdef CONFIG_HYPFS
 HYPERCALL(hypfs_op),
 #endif
-HYPERCALL(arch_1)
+HYPERCALL(paging_domctl_cont)
 };
 
-#undef do_arch_1
-
 #undef HYPERCALL
 #undef HVM_CALL
 #undef COMPAT_CALL
@@ -300,7 +296,7 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 #endif
 
 curr->hcall_compat = true;
-regs->rax = hvm_hypercall_table[eax].compat(ebx, ecx, edx, esi, edi);
+regs->eax = hvm_hypercall_table[eax].compat(ebx, ecx, edx, esi, edi);
 curr->hcall_compat = false;
 
 #ifndef NDEBUG
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 2370d31d3f..07e1a45ef5 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -75,7 +75,7 @@ const hypercall_args_t hypercall_args_table[NR_hypercalls] =
 ARGS(dm_op, 3),
 ARGS(hypfs_op, 5),
 ARGS(mca, 1),
-ARGS(arch_1, 1),
+ARGS(paging_domctl_cont, 1),
 };
 
 #undef COMP
diff --git a/xen/arch/x86/include/asm/hypercall.h 
b/xen/arch/x86/include/asm/hypercall.h
index d6daa7e4cb..49973820af 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -11,6 +11,8 @@
 #include  /* for do_mca */
 #include 
 
+#define __HYPERVISOR_paging_domctl_cont __HYPERVISOR_arch_1
+
 typedef unsigned long hypercall_fn_t(
 unsigned long, unsigned long, unsigned long,
 unsigned long, unsigned long);
@@ -80,7 +82,7 @@ do_set_debugreg(
 int reg,
 unsigned long value);
 
-extern unsigned long cf_check
+extern long cf_check
 do_get_debugreg(
 int reg);
 
@@ -118,7 +120,7 @@ do_mmuext_op(
 extern long cf_check do_callback_op(
 int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg);
 
-extern unsigned long cf_check
+extern lo

[PATCH v6 5/9] xen: generate hypercall interface related code

2022-03-24 Thread Juergen Gross

Instead of repeating similar data multiple times use a single source
file and a generator script for producing prototypes and call sequences
of the hypercalls.

As the script already knows the number of parameters used add generating
a macro for populating an array with the number of parameters per
hypercall.

The priorities for the specific hypercalls are based on two benchamrks
performed in guests (PV and PVH):

- make -j 4 of the Xen hypervisor (resulting in cpu load with lots of
  processes created)
- scp of a large file to the guest (network load)

With a small additional debug patch applied the number of the
different hypercalls in the guest and in dom0 (for looking at backend
activity related hypercalls) were counted while the benchmark in domU
was running:

PV-hypercallPV-guest build   PV-guest scpdom0 build dom0 scp
mmu_update   186175729   2865 2093633725
stack_switch   1273311  62381108589   270764
multicall  2182803 50   302  524
update_va_mapping   571868 1060   80
xen_version  73061850   859 5432
grant_table_op   0  0 35557   139110
iret  75673006 484132268157   757958
vcpu_op 453037  71199138224   334988
set_segment_base   1650249  62387108645   270823
mmuext_op 11225681188  7239 3426
sched_op280153 134645 70729   137943
event_channel_op192327  66204 71409   214191
physdev_op   0  0  7721 4315
(the dom0 values are for the guest running the build or scp test, so
dom0 acting as backend)

HVM-hypercall   PVH-guest buildPVH-guest scp
vcpu_op  277684 2324
event_channel_op 35023357383
(the related dom0 counter values are in the same range as with the test
running in the PV guest)

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Acked-by: Julien Grall 
---
V2:
- split platform_op for doe and compat prefixes (Jan Beulich)
- add "addline:" directive
- add priorities to handlers (Jan Beulich)
V2.1:
- add missing "delete" statement in awk script
- optimize case of 2 hypercalls with same priority
V2.2:
- avoid asort() function (Michal Orzel)
V3:
- drop "addline:" support, as no longer needed
- enclose call sequence macros in "({ ... })" (Jan Beulich)
- small style adjustment (Jan Beulich)
- move generating to xen/include/Makefile (Anthony PERARD)
V4:
- generate cf_check attribute for prototype (will be removed in later patch)
- add Arm-specific variant of physdev_op()
V5:
- user $(srctree) (Anthony Perard)
- specify priority 1 for arm evtchn_op (Julien Grall)
---
 .gitignore|   1 +
 xen/include/Makefile  |  13 ++
 xen/include/hypercall-defs.c  | 285 ++
 xen/scripts/gen_hypercall.awk | 314 ++
 4 files changed, 613 insertions(+)
 create mode 100644 xen/include/hypercall-defs.c
 create mode 100644 xen/scripts/gen_hypercall.awk

diff --git a/.gitignore b/.gitignore
index d425be4bd9..c6e5b31b98 100644
--- a/.gitignore
+++ b/.gitignore
@@ -324,6 +324,7 @@ xen/include/public/public
 xen/include/xen/*.new
 xen/include/xen/acm_policy.h
 xen/include/xen/compile.h
+xen/include/xen/hypercall-defs.h
 xen/include/xen/lib/x86/cpuid-autogen.h
 xen/test/livepatch/config.h
 xen/test/livepatch/expect_config.h
diff --git a/xen/include/Makefile b/xen/include/Makefile
index a3c2511f5f..dfc43f9fba 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -77,6 +77,18 @@ $(obj)/compat/xlat.h: $(addprefix 
$(obj)/compat/.xlat/,$(xlat-y)) $(obj)/config/
cat $(filter %.h,$^) >$@.new
mv -f $@.new $@
 
+quiet_cmd_genhyp = GEN $@
+define cmd_genhyp
+awk -f $(srctree)/scripts/gen_hypercall.awk <$< >$@
+endef
+
+all: $(obj)/xen/hypercall-defs.h
+
+$(obj)/xen/hypercall-defs.h: $(obj)/hypercall-defs.i 
$(srctree)/scripts/gen_hypercall.awk FORCE
+   $(call if_changed,genhyp)
+
+targets += xen/hypercall-defs.h
+
 ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
 
 all: $(obj)/headers.chk $(obj)/headers99.chk $(obj)/headers++.chk
@@ -132,3 +144,4 @@ all: lib-x86-all
 endif
 
 clean-files := compat config generated headers*.chk xen/lib/x86/cpuid-autogen.h
+clean-files += xen/hypercall-defs.h hypercall-defs.i
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
new file mode 100644
index 00..60cbeb18e4
--- /dev/null
+++ b/xen/include/hypercall-defs.c
@@ -0,0 +1,285 @@
+/*
+ * Hypercall interface description:
+ * Used by scripts/gen_hypercall.awk to generate hypercall prototypes and call
+ * sequences.
+ *
+ * Syntax is like a prototype, but without return type and without the ";"

[PATCH v6 4/9] xen: include compat/platform.h from hypercall.h

2022-03-24 Thread Juergen Gross

The definition of compat_platform_op_t is in compat/platform.h
already, so include that file from hypercall.h instead of repeating
the typedef.

This allows to remove the related include statement from
arch/x86/x86_64/platform_hypercall.c.

Signed-off-by: Juergen Gross 
Acked-by: Jan Beulich 
---
V3:
- new patch
---
 xen/arch/x86/x86_64/platform_hypercall.c | 1 -
 xen/include/xen/hypercall.h  | 4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/x86_64/platform_hypercall.c 
b/xen/arch/x86/x86_64/platform_hypercall.c
index 966fd27b5f..5bf6b958d2 100644
--- a/xen/arch/x86/x86_64/platform_hypercall.c
+++ b/xen/arch/x86/x86_64/platform_hypercall.c
@@ -5,7 +5,6 @@
 EMIT_FILE;
 
 #include 
-#include 
 #include 
 
 #define xen_platform_op compat_platform_op
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index a032ba2b4a..ca8ee22717 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -15,6 +15,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_COMPAT
+#include 
+#endif
 #include 
 #include 
 
@@ -206,7 +209,6 @@ extern int cf_check compat_multicall(
 
 int compat_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
-typedef struct compat_platform_op compat_platform_op_t;
 DEFINE_XEN_GUEST_HANDLE(compat_platform_op_t);
 int compat_platform_op(XEN_GUEST_HANDLE_PARAM(compat_platform_op_t) 
u_xenpf_op);
 
-- 
2.34.1

[PATCH v6 3/9] xen: don't include asm/hypercall.h from C sources

2022-03-24 Thread Juergen Gross

Instead of including asm/hypercall.h always use xen/hypercall.h.
Additionally include xen/hypercall.h from all sources containing a
hypercall handler.

This prepares for generating the handlers' prototypes at build time.

Add a guard in asm/hypercall.h to catch direct inclusion.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Acked-by: Julien Grall  # arm
---
V2:
- remove platform_op hunk (Jan Beulich)
- remove including of xen/hypervisor.h from arch/x86/x86_64/mm.c
  (Jan Beulich)
- fix include order in common/compat/grant_table.c (Jan Beulich)
---
 xen/arch/arm/hvm.c   | 3 +--
 xen/arch/arm/include/asm/hypercall.h | 4 
 xen/arch/arm/platform_hypercall.c| 1 +
 xen/arch/x86/cpu/vpmu.c  | 1 +
 xen/arch/x86/include/asm/hypercall.h | 4 
 xen/arch/x86/mm.c| 1 -
 xen/arch/x86/platform_hypercall.c| 1 +
 xen/arch/x86/pv/iret.c   | 1 +
 xen/arch/x86/traps.c | 2 +-
 xen/arch/x86/x86_64/compat/mm.c  | 1 +
 xen/arch/x86/x86_64/mm.c | 2 --
 xen/common/compat/grant_table.c  | 1 +
 xen/common/event_channel.c   | 1 +
 xen/common/grant_table.c | 1 +
 xen/common/multicall.c   | 1 +
 15 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index 8951b34086..fc1a52767d 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -29,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 static int hvm_allow_set_param(const struct domain *d, unsigned int param)
 {
 switch ( param )
diff --git a/xen/arch/arm/include/asm/hypercall.h 
b/xen/arch/arm/include/asm/hypercall.h
index fac4d60f17..8182895358 100644
--- a/xen/arch/arm/include/asm/hypercall.h
+++ b/xen/arch/arm/include/asm/hypercall.h
@@ -1,3 +1,7 @@
+#ifndef __XEN_HYPERCALL_H__
+#error "asm/hypercall.h should not be included directly - include 
xen/hypercall.h instead"
+#endif
+
 #ifndef __ASM_ARM_HYPERCALL_H__
 #define __ASM_ARM_HYPERCALL_H__
 
diff --git a/xen/arch/arm/platform_hypercall.c 
b/xen/arch/arm/platform_hypercall.c
index 8efac7ee60..403cc84324 100644
--- a/xen/arch/arm/platform_hypercall.c
+++ b/xen/arch/arm/platform_hypercall.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 4fedc7c570..51d171615f 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/include/asm/hypercall.h 
b/xen/arch/x86/include/asm/hypercall.h
index 49973820af..81ca25f7b3 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -2,6 +2,10 @@
  * asm-x86/hypercall.h
  */
 
+#ifndef __XEN_HYPERCALL_H__
+#error "asm/hypercall.h should not be included directly - include 
xen/hypercall.h instead"
+#endif
+
 #ifndef __ASM_X86_HYPERCALL_H__
 #define __ASM_X86_HYPERCALL_H__
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 2befd0c191..6cc73187ac 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -129,7 +129,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index b91ccff589..eeb4f7a20e 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/pv/iret.c b/xen/arch/x86/pv/iret.c
index 55eb6a63bd..58de9f7922 100644
--- a/xen/arch/x86/pv/iret.c
+++ b/xen/arch/x86/pv/iret.c
@@ -18,6 +18,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 8659547970..4c38f6c015 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -70,7 +71,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index b3da8fafbb..70b08a832a 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 4f225da81e..3510a5affe 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -25,14 +25,12 @@ EMIT_FILE;
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
index c6199e8918..d5787e3719 100644
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -

[PATCH v6 1/9] xen: move do_vcpu_op() to arch specific code

2022-03-24 Thread Juergen Gross

The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common handler. This leads to the
weird call hierarchy:

  do_arm_vcpu_op()
do_vcpu_op()
  arch_do_vcpu_op()

Clean this up by renaming do_vcpu_op() to common_vcpu_op() and
arch_do_vcpu_op() in each architecture to do_vcpu_op(). This way one
of above calls can be avoided without restricting any potential
future use of common sub-ops for Arm.

Signed-off-by: Juergen Gross 
Reviewed-by: Julien Grall 
---
V4:
- don't remove HYPERCALL_ARM()
V4.1:
- add missing cf_check (Andrew Cooper)
V5:
- use v instead of current (Julien Grall)
---
 xen/arch/arm/domain.c| 15 ---
 xen/arch/arm/include/asm/hypercall.h |  2 --
 xen/arch/arm/traps.c |  2 +-
 xen/arch/x86/domain.c| 12 
 xen/arch/x86/include/asm/hypercall.h |  2 +-
 xen/arch/x86/x86_64/domain.c | 18 +-
 xen/common/compat/domain.c   | 15 ++-
 xen/common/domain.c  | 12 
 xen/include/xen/hypercall.h  |  2 +-
 9 files changed, 42 insertions(+), 38 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8110c1df86..2f8eaab7b5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1079,23 +1079,24 @@ void arch_dump_domain_info(struct domain *d)
 }
 
 
-long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg)
+long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if ( (v = domain_vcpu(d, vcpuid)) == NULL )
+return -ENOENT;
+
 switch ( cmd )
 {
 case VCPUOP_register_vcpu_info:
 case VCPUOP_register_runstate_memory_area:
-return do_vcpu_op(cmd, vcpuid, arg);
+return common_vcpu_op(cmd, v, arg);
 default:
 return -EINVAL;
 }
 }
 
-long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
-{
-return -ENOSYS;
-}
-
 void arch_dump_vcpu_info(struct vcpu *v)
 {
 gic_dump_info(v);
diff --git a/xen/arch/arm/include/asm/hypercall.h 
b/xen/arch/arm/include/asm/hypercall.h
index 39d2e7889d..fac4d60f17 100644
--- a/xen/arch/arm/include/asm/hypercall.h
+++ b/xen/arch/arm/include/asm/hypercall.h
@@ -4,8 +4,6 @@
 #include  /* for arch_do_domctl */
 int do_arm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
-long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg);
-
 long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 43f30747cf..e906bb4a89 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1380,7 +1380,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
 #endif
 HYPERCALL(multicall, 2),
 HYPERCALL(platform_op, 1),
-HYPERCALL_ARM(vcpu_op, 3),
+HYPERCALL(vcpu_op, 3),
 HYPERCALL(vm_assist, 2),
 #ifdef CONFIG_ARGO
 HYPERCALL(argo_op, 5),
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a5048ed654..d566fc82b4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1489,11 +1489,15 @@ int arch_vcpu_reset(struct vcpu *v)
 return 0;
 }
 
-long
-arch_do_vcpu_op(
-int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+long cf_check do_vcpu_op(int cmd, unsigned int vcpuid,
+ XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc = 0;
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if ( (v = domain_vcpu(d, vcpuid)) == NULL )
+return -ENOENT;
 
 switch ( cmd )
 {
@@ -1545,7 +1549,7 @@ arch_do_vcpu_op(
 }
 
 default:
-rc = -ENOSYS;
+rc = common_vcpu_op(cmd, v, arg);
 break;
 }
 
diff --git a/xen/arch/x86/include/asm/hypercall.h 
b/xen/arch/x86/include/asm/hypercall.h
index 61bf897147..d6daa7e4cb 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -145,7 +145,7 @@ compat_physdev_op(
 XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
-arch_compat_vcpu_op(
+compat_common_vcpu_op(
 int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int cf_check compat_mmuext_op(
diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c
index c46dccc25a..9c559aa3ea 100644
--- a/xen/arch/x86/x86_64/domain.c
+++ b/xen/arch/x86/x86_64/domain.c
@@ -12,11 +12,15 @@
 CHECK_vcpu_get_physid;
 #undef xen_vcpu_get_physid
 
-int
-arch_compat_vcpu_op(
-int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+int cf_check
+compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
-int rc = -ENOSYS;
+int rc;

[PATCH v6 6/9] xen: use generated prototypes for hypercall handlers

2022-03-24 Thread Juergen Gross

Remove the hypercall handler's prototypes in the related header files
and use the generated ones instead.

Some handlers having been static before need to be made globally
visible.

Signed-off-by: Juergen Gross 
Acked-by: Jan Beulich 
Acked-by: Julien Grall 
---
 xen/arch/arm/include/asm/hypercall.h |   1 -
 xen/arch/x86/hvm/hypercall.c |   7 +-
 xen/arch/x86/include/asm/hypercall.h | 141 -
 xen/include/xen/hypercall.h  | 177 +--
 4 files changed, 5 insertions(+), 321 deletions(-)

diff --git a/xen/arch/arm/include/asm/hypercall.h 
b/xen/arch/arm/include/asm/hypercall.h
index 8182895358..ccd26c5184 100644
--- a/xen/arch/arm/include/asm/hypercall.h
+++ b/xen/arch/arm/include/asm/hypercall.h
@@ -6,7 +6,6 @@
 #define __ASM_ARM_HYPERCALL_H__
 
 #include  /* for arch_do_domctl */
-int do_arm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 3a35543997..a9c9ad721f 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -31,8 +31,7 @@
 #include 
 #include 
 
-static long cf_check hvm_memory_op(
-unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
+long cf_check hvm_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 {
 long rc;
 
@@ -52,7 +51,7 @@ static long cf_check hvm_memory_op(
 }
 
 #ifdef CONFIG_GRANT_TABLE
-static long cf_check hvm_grant_table_op(
+long cf_check hvm_grant_table_op(
 unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
 {
 switch ( cmd )
@@ -78,7 +77,7 @@ static long cf_check hvm_grant_table_op(
 }
 #endif
 
-static long cf_check hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
+long cf_check hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 const struct vcpu *curr = current;
 const struct domain *currd = curr->domain;
diff --git a/xen/arch/x86/include/asm/hypercall.h 
b/xen/arch/x86/include/asm/hypercall.h
index 81ca25f7b3..2d243b48bc 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -44,109 +44,6 @@ void pv_ring3_init_hypercall_page(void *ptr);
  */
 #define MMU_UPDATE_PREEMPTED  (~(~0U>>1))
 
-extern long cf_check
-do_event_channel_op_compat(
-XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop);
-
-/* Legacy hypercall (as of 0x00030202). */
-extern long cf_check do_physdev_op_compat(
-XEN_GUEST_HANDLE(physdev_op_t) uop);
-
-/* Legacy hypercall (as of 0x00030101). */
-extern long cf_check do_sched_op_compat(
-int cmd, unsigned long arg);
-
-extern long cf_check
-do_set_trap_table(
-XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps);
-
-extern long cf_check
-do_mmu_update(
-XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs,
-unsigned int count,
-XEN_GUEST_HANDLE_PARAM(uint) pdone,
-unsigned int foreigndom);
-
-extern long cf_check
-do_set_gdt(
-XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
-unsigned int entries);
-
-extern long cf_check
-do_stack_switch(
-unsigned long ss,
-unsigned long esp);
-
-extern long cf_check
-do_fpu_taskswitch(
-int set);
-
-extern long cf_check
-do_set_debugreg(
-int reg,
-unsigned long value);
-
-extern long cf_check
-do_get_debugreg(
-int reg);
-
-extern long cf_check
-do_update_descriptor(
-uint64_t gaddr, seg_desc_t desc);
-
-extern long cf_check
-do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc);
-
-extern long cf_check
-do_update_va_mapping(
-unsigned long va,
-uint64_t val64,
-unsigned long flags);
-
-extern long cf_check
-do_physdev_op(
-int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
-
-extern long cf_check
-do_update_va_mapping_otherdomain(
-unsigned long va,
-uint64_t val64,
-unsigned long flags,
-domid_t domid);
-
-extern long cf_check
-do_mmuext_op(
-XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops,
-unsigned int count,
-XEN_GUEST_HANDLE_PARAM(uint) pdone,
-unsigned int foreigndom);
-
-extern long cf_check do_callback_op(
-int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg);
-
-extern long cf_check
-do_iret(
-void);
-
-extern long cf_check
-do_set_callbacks(
-unsigned long event_address,
-unsigned long failsafe_address,
-unsigned long syscall_address);
-
-extern long cf_check
-do_set_segment_base(
-unsigned int which,
-unsigned long base);
-
-long cf_check do_nmi_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
-
-long cf_check do_xenpmu_op(unsigned int op,
-   XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg);
-
-long cf_check do_paging_domctl_cont(
-XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
-
 #ifdef CONFIG_COMPAT
 
 #include 
@@ -157,44 +54,6 @@ extern int
 compat_common_vcpu_op(
 int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg);
 
-extern int cf_check

[PATCH v6 9/9] xen/x86: remove cf_check attribute from hypercall handlers

2022-03-24 Thread Juergen Gross

Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.

Signed-off-by: Juergen Gross 
Reviewed-by: Daniel P. Smith  # xsm parts
Acked-by: Jan Beulich 
Tested-by: Téo Couprie Diaz 
---
V4:
- new patch
---
 xen/arch/x86/compat.c   |  6 +++---
 xen/arch/x86/cpu/mcheck/mce.c   |  2 +-
 xen/arch/x86/cpu/vpmu.c |  2 +-
 xen/arch/x86/domain.c   |  3 +--
 xen/arch/x86/hvm/dm.c   |  2 +-
 xen/arch/x86/hvm/hvm.c  |  2 +-
 xen/arch/x86/hvm/hypercall.c|  6 +++---
 xen/arch/x86/mm.c   | 12 ++--
 xen/arch/x86/mm/paging.c|  2 +-
 xen/arch/x86/physdev.c  |  2 +-
 xen/arch/x86/platform_hypercall.c   |  2 +-
 xen/arch/x86/pv/callback.c  | 16 
 xen/arch/x86/pv/descriptor-tables.c |  8 
 xen/arch/x86/pv/iret.c  |  4 ++--
 xen/arch/x86/pv/misc-hypercalls.c   | 10 +-
 xen/arch/x86/pv/shim.c  |  4 ++--
 xen/arch/x86/x86_64/compat/mm.c |  2 +-
 xen/arch/x86/x86_64/domain.c|  2 +-
 xen/common/argo.c   |  4 ++--
 xen/common/compat/grant_table.c |  2 +-
 xen/common/compat/kernel.c  |  2 +-
 xen/common/compat/memory.c  |  3 +--
 xen/common/dm.c |  2 +-
 xen/common/domain.c |  2 +-
 xen/common/domctl.c |  2 +-
 xen/common/event_channel.c  |  2 +-
 xen/common/grant_table.c|  3 +--
 xen/common/hypfs.c  |  2 +-
 xen/common/kernel.c |  2 +-
 xen/common/kexec.c  |  4 ++--
 xen/common/memory.c |  2 +-
 xen/common/multicall.c  |  3 +--
 xen/common/sched/compat.c   |  2 +-
 xen/common/sched/core.c |  4 ++--
 xen/common/sysctl.c |  2 +-
 xen/common/xenoprof.c   |  2 +-
 xen/drivers/char/console.c  |  2 +-
 xen/scripts/gen_hypercall.awk   |  2 +-
 xen/xsm/xsm_core.c  |  4 ++--
 39 files changed, 68 insertions(+), 72 deletions(-)

diff --git a/xen/arch/x86/compat.c b/xen/arch/x86/compat.c
index 28281a262a..a031062830 100644
--- a/xen/arch/x86/compat.c
+++ b/xen/arch/x86/compat.c
@@ -15,7 +15,7 @@ typedef long ret_t;
 #endif
 
 /* Legacy hypercall (as of 0x00030202). */
-ret_t cf_check do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
+ret_t do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
 {
 struct physdev_op op;
 
@@ -28,7 +28,7 @@ ret_t cf_check 
do_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
 #ifndef COMPAT
 
 /* Legacy hypercall (as of 0x00030101). */
-long cf_check do_sched_op_compat(int cmd, unsigned long arg)
+long do_sched_op_compat(int cmd, unsigned long arg)
 {
 switch ( cmd )
 {
@@ -50,7 +50,7 @@ long cf_check do_sched_op_compat(int cmd, unsigned long arg)
 }
 
 /* Legacy hypercall (as of 0x00030202). */
-long cf_check do_event_channel_op_compat(
+long do_event_channel_op_compat(
 XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop)
 {
 struct evtchn_op op;
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 275c54be7c..f68e31b643 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1351,7 +1351,7 @@ CHECK_mcinfo_recovery;
 # endif /* CONFIG_COMPAT */
 
 /* Machine Check Architecture Hypercall */
-long cf_check do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
+long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 {
 long ret = 0;
 struct xen_mc curop, *op = &curop;
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 51d171615f..d2c03a1104 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -672,7 +672,7 @@ void vpmu_dump(struct vcpu *v)
 alternative_vcall(vpmu_ops.arch_vpmu_dump, v);
 }
 
-long cf_check do_xenpmu_op(
+long do_xenpmu_op(
 unsigned int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 {
 int ret;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d566fc82b4..ddf969f76e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1489,8 +1489,7 @@ int arch_vcpu_reset(struct vcpu *v)
 return 0;
 }
 
-long cf_check do_vcpu_op(int cmd, unsigned int vcpuid,
- XEN_GUEST_HANDLE_PARAM(void) arg)
+long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc = 0;
 struct domain *d = current->domain;
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index d80975efcf..f8e6089870 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -654,7 +654,7 @@ CHECK_dm_op_relocate_memory;
 CHECK_dm_op_pin_memory_cacheattr;
 CHECK_dm_op_nr_vcpus;
 
-int cf_check compat_dm_op(
+int compat_dm_op(
 domid_t domid, unsigned int nr_bufs, XEN_GUEST_HANDLE_PARAM(void) bufs)
 {
 struct dmop_args args;
diff --git a/xen/arch/x86/hvm/hvm.c b/x

[PATCH v6 7/9] xen/x86: call hypercall handlers via generated macro

2022-03-24 Thread Juergen Gross

Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.

This is beneficial to performance and avoids speculation issues.

With calling the handlers using the correct number of parameters now
it is possible to do the parameter register clobbering in the NDEBUG
case after returning from the handler. With the additional generated
data the hard coded hypercall_args_table[] can be replaced by tables
using the generated number of parameters.

Note that this change modifies behavior of clobbering registers in a
minor way: in case a hypercall is returning -ENOSYS (or the unsigned
equivalent thereof) for any reason the parameter registers will no
longer be clobbered. This should be of no real concern, as those cases
ought to be extremely rare and reuse of the registers in those cases
seems rather far fetched.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
---
V2:
- make hypercall_args_*[] const (Jan Beulich)
- make clobber_regs*() independent from NDEBUG (Jan Beulich)
- drop "L" suffix for 32-bit register clobber value (Jan Beulich)
V3:
- add array_access_nospec() (Jan Beulich)
- remove local variables in hvm_hypercall() (Andrew Cooper)
---
 xen/arch/x86/hvm/hypercall.c | 166 +++-
 xen/arch/x86/hypercall.c |  59 -
 xen/arch/x86/include/asm/hypercall.h |  55 ++--
 xen/arch/x86/pv/hypercall.c  | 184 +++
 4 files changed, 76 insertions(+), 388 deletions(-)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index a9c9ad721f..ae601185fc 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -111,56 +111,10 @@ long cf_check hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 return compat_physdev_op(cmd, arg);
 }
 
-#define HYPERCALL(x) \
-[ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) do_ ## x,  \
-   (hypercall_fn_t *) do_ ## x }
-
-#define HVM_CALL(x)  \
-[ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) hvm_ ## x, \
-   (hypercall_fn_t *) hvm_ ## x }
-
-#define COMPAT_CALL(x)   \
-[ __HYPERVISOR_ ## x ] = { (hypercall_fn_t *) do_ ## x,  \
-   (hypercall_fn_t *) compat_ ## x }
-
-static const struct {
-hypercall_fn_t *native, *compat;
-} hvm_hypercall_table[] = {
-HVM_CALL(memory_op),
-COMPAT_CALL(multicall),
-#ifdef CONFIG_GRANT_TABLE
-HVM_CALL(grant_table_op),
-#endif
-HYPERCALL(vm_assist),
-COMPAT_CALL(vcpu_op),
-HVM_CALL(physdev_op),
-COMPAT_CALL(xen_version),
-HYPERCALL(console_io),
-HYPERCALL(event_channel_op),
-COMPAT_CALL(sched_op),
-COMPAT_CALL(set_timer_op),
-COMPAT_CALL(xsm_op),
-HYPERCALL(hvm_op),
-HYPERCALL(sysctl),
-HYPERCALL(domctl),
-#ifdef CONFIG_ARGO
-COMPAT_CALL(argo_op),
-#endif
-COMPAT_CALL(platform_op),
-#ifdef CONFIG_PV
-COMPAT_CALL(mmuext_op),
-#endif
-HYPERCALL(xenpmu_op),
-COMPAT_CALL(dm_op),
-#ifdef CONFIG_HYPFS
-HYPERCALL(hypfs_op),
+#ifndef NDEBUG
+static const unsigned char hypercall_args_64[] = hypercall_args_hvm64;
+static const unsigned char hypercall_args_32[] = hypercall_args_hvm32;
 #endif
-HYPERCALL(paging_domctl_cont)
-};
-
-#undef HYPERCALL
-#undef HVM_CALL
-#undef COMPAT_CALL
 
 int hvm_hypercall(struct cpu_user_regs *regs)
 {
@@ -206,23 +160,6 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 return ret;
 }
 
-BUILD_BUG_ON(ARRAY_SIZE(hvm_hypercall_table) >
- ARRAY_SIZE(hypercall_args_table));
-
-if ( eax >= ARRAY_SIZE(hvm_hypercall_table) )
-{
-regs->rax = -ENOSYS;
-return HVM_HCALL_completed;
-}
-
-eax = array_index_nospec(eax, ARRAY_SIZE(hvm_hypercall_table));
-
-if ( !hvm_hypercall_table[eax].native )
-{
-regs->rax = -ENOSYS;
-return HVM_HCALL_completed;
-}
-
 /*
  * Caching is intended for instruction emulation only. Disable it
  * for any accesses by hypercall argument copy-in / copy-out.
@@ -233,85 +170,27 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 
 if ( mode == 8 )
 {
-unsigned long rdi = regs->rdi;
-unsigned long rsi = regs->rsi;
-unsigned long rdx = regs->rdx;
-unsigned long r10 = regs->r10;
-unsigned long r8 = regs->r8;
-
 HVM_DBG_LOG(DBG_LEVEL_HCALL, "hcall%lu(%lx, %lx, %lx, %lx, %lx)",
-eax, rdi, rsi, rdx, r10, r8);
-
-#ifndef NDEBUG
-/* Deliberately corrupt parameter regs not used by this hypercall. */
-switch ( hypercall_args_table[eax].native )
-{
-case 0: rdi = 0xdeadbeefdeadf00dUL; fallthrough;
-case 1: rsi = 0xdeadbeefdeadf00dUL; fallthrough;
-case 2: rdx = 0xdeadbeefdeadf00dUL; fallthrough;
-case 3: r10 = 0xdeadbeefdeadf

[PATCH v6 8/9] xen/arm: call hypercall handlers via generated macro

2022-03-24 Thread Juergen Gross

Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.

This makes the calls of the handlers type safe.

For deprecated hypercalls define stub functions.

Signed-off-by: Juergen Gross 
Reviewed-by: Julien Grall 
Tested-by: Michal Orzel 
---
V2:
- make hypercall_args[] const (Jan Beulich)
V5:
- move out-of-bounds check (Julien Grall)
---
 xen/arch/arm/traps.c | 117 +--
 1 file changed, 24 insertions(+), 93 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index e906bb4a89..e0fca3b4d8 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1331,67 +1331,20 @@ static register_t do_deprecated_hypercall(void)
 return -ENOSYS;
 }
 
-typedef register_t (*arm_hypercall_fn_t)(
-register_t, register_t, register_t, register_t, register_t);
-
-typedef struct {
-arm_hypercall_fn_t fn;
-int nr_args;
-} arm_hypercall_t;
-
-#define HYPERCALL(_name, _nr_args)   \
-[ __HYPERVISOR_ ## _name ] =  {  \
-.fn = (arm_hypercall_fn_t) &do_ ## _name,\
-.nr_args = _nr_args, \
-}
+long dep_sched_op_compat(int cmd, unsigned long arg)
+{
+return do_deprecated_hypercall();
+}
 
-#define HYPERCALL_ARM(_name, _nr_args)\
-[ __HYPERVISOR_ ## _name ] =  {  \
-.fn = (arm_hypercall_fn_t) &do_arm_ ## _name,\
-.nr_args = _nr_args, \
-}
-/*
- * Only use this for hypercalls which were deprecated (i.e. replaced
- * by something else) before Xen on ARM was created, i.e. *not* for
- * hypercalls which are simply not yet used on ARM.
- */
-#define HYPERCALL_DEPRECATED(_name, _nr_args)   \
-[ __HYPERVISOR_##_name ] = {\
-.fn = (arm_hypercall_fn_t) &do_deprecated_hypercall,\
-.nr_args = _nr_args,\
-}
+long dep_event_channel_op_compat(XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop)
+{
+return do_deprecated_hypercall();
+}
 
-static arm_hypercall_t arm_hypercall_table[] = {
-HYPERCALL(memory_op, 2),
-HYPERCALL(domctl, 1),
-HYPERCALL(sched_op, 2),
-HYPERCALL_DEPRECATED(sched_op_compat, 2),
-HYPERCALL(console_io, 3),
-HYPERCALL(xen_version, 2),
-HYPERCALL(xsm_op, 1),
-HYPERCALL(event_channel_op, 2),
-HYPERCALL_DEPRECATED(event_channel_op_compat, 1),
-HYPERCALL_ARM(physdev_op, 2),
-HYPERCALL_DEPRECATED(physdev_op_compat, 1),
-HYPERCALL(sysctl, 2),
-HYPERCALL(hvm_op, 2),
-#ifdef CONFIG_GRANT_TABLE
-HYPERCALL(grant_table_op, 3),
-#endif
-HYPERCALL(multicall, 2),
-HYPERCALL(platform_op, 1),
-HYPERCALL(vcpu_op, 3),
-HYPERCALL(vm_assist, 2),
-#ifdef CONFIG_ARGO
-HYPERCALL(argo_op, 5),
-#endif
-#ifdef CONFIG_HYPFS
-HYPERCALL(hypfs_op, 5),
-#endif
-#ifdef CONFIG_IOREQ_SERVER
-HYPERCALL(dm_op, 3),
-#endif
-};
+long dep_physdev_op_compat(XEN_GUEST_HANDLE_PARAM(physdev_op_t) uop)
+{
+return do_deprecated_hypercall();
+}
 
 #ifndef NDEBUG
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
@@ -1430,7 +1383,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 #define HYPERCALL_ARG3(r) (r)->x2
 #define HYPERCALL_ARG4(r) (r)->x3
 #define HYPERCALL_ARG5(r) (r)->x4
-#define HYPERCALL_ARGS(r) (r)->x0, (r)->x1, (r)->x2, (r)->x3, (r)->x4
 #else
 #define HYPERCALL_RESULT_REG(r) (r)->r0
 #define HYPERCALL_ARG1(r) (r)->r0
@@ -1438,52 +1390,40 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 #define HYPERCALL_ARG3(r) (r)->r2
 #define HYPERCALL_ARG4(r) (r)->r3
 #define HYPERCALL_ARG5(r) (r)->r4
-#define HYPERCALL_ARGS(r) (r)->r0, (r)->r1, (r)->r2, (r)->r3, (r)->r4
 #endif
 
+static const unsigned char hypercall_args[] = hypercall_args_arm;
+
 static void do_trap_hypercall(struct cpu_user_regs *regs, register_t *nr,
   const union hsr hsr)
 {
-arm_hypercall_fn_t call = NULL;
 struct vcpu *curr = current;
 
-BUILD_BUG_ON(NR_hypercalls < ARRAY_SIZE(arm_hypercall_table) );
-
 if ( hsr.iss != XEN_HYPERCALL_TAG )
 {
 gprintk(XENLOG_WARNING, "Invalid HVC imm 0x%x\n", hsr.iss);
 return inject_undef_exception(regs, hsr);
 }
 
-if ( *nr >= ARRAY_SIZE(arm_hypercall_table) )
-{
-perfc_incr(invalid_hypercalls);
-HYPERCALL_RESULT_REG(regs) = -ENOSYS;
-return;
-}
-
 curr->hcall_preempted = false;
 
 perfc_incra(hypercalls, *nr);
-call = arm_hypercall_table[*nr].fn;
-if ( call == NULL )
-{
-HYPERCALL_RESULT_REG(regs) = -ENOSYS;
-return;
-}
 
-HYPERCALL_RESULT_REG(regs) = call(HYPERCALL_ARGS(regs));
+call_handlers_arm(*nr, HYPERCALL_RESULT_REG(regs), HYPERCALL_AR

[libvirt test] 168818: regressions - FAIL

2022-03-24 Thread osstest service owner

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

Regressions :-(

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

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

version targeted for testing:
 libvirt  42d7c3c4dae259ee72d8c834c6477597fccb4775
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  622 days
Failing since151818  2020-07-11 04:18:52 Z  621 days  603 attempts
Testing same since   168796  2022-03-23 04:22:16 Z1 days2 attempts


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

[PATCH v4 0/6] Boot time cpupools

2022-03-24 Thread Luca Fancellu

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

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

>From the DT:

  [...]

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

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

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

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

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

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

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

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

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

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

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

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

  [...]

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

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


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

 docs/misc/arm/device-tree/booting.txt  |   5 +
 docs/misc/arm/device-tree/cpupools.txt | 136 
 tools/helpers/xen-init-dom0.c  |  35 +++-
 tools/libs/light/libxl_utils.c |   3 +-
 xen/arch/arm/domain_build.c|  14 +-
 xen/arch/arm/include/asm/smp.h |   3 +
 xen/common/Kconfig |   7 +
 xen/common/Makefile|   1 +
 xen/common/boot_cpupools.c | 217 +
 xen/common/domain.c|   2 +-
 xen/common/sched/core.c|  40 +++--
 xen/common/sched/cpupool.c |  32 +++-
 xen/include/public/domctl.h|   4 +-
 xen/include/xen/sched.h|  53 ++
 14 files changed, 524 insertions(+), 28 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/cpupools.txt
 create mode 100644 xen/common/boot_cpupools.c

-- 
2.17.1

[PATCH v4 2/6] xen/sched: create public function for cpupools creation

2022-03-24 Thread Luca Fancellu

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

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

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

[PATCH v4 1/6] tools/cpupools: Give a name to unnamed cpupools

2022-03-24 Thread Luca Fancellu

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

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

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

Signed-off-by: Luca Fancellu 
Reviewed-by: Juergen Gross 
---
Changes in v4:
- no changes
Changes in v3:
- no changes, add R-by
Changes in v2:
 - Remove unused variable, moved xc_cpupool_infofree
   ahead to simplify the code, use asprintf (Juergen)
---
 tools/helpers/xen-init-dom0.c  | 35 +-
 tools/libs/light/libxl_utils.c |  3 +--
 2 files changed, 35 insertions(+), 3 deletions(-)

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

[PATCH v4 3/6] xen/sched: retrieve scheduler id by name

2022-03-24 Thread Luca Fancellu

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

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

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

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

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

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

2022-03-24 Thread Luca Fancellu

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

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

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

Update documentation about the property.

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

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

[PATCH v4 6/6] xen/cpupool: Allow cpupool0 to use different scheduler

2022-03-24 Thread Luca Fancellu

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

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

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

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

diff --git a/xen/common/boot_cpupools.c b/xen/common/boot_cpupools.c
index 70003eaf08a4..60ebc6235658 100644
--- a/xen/common/boot_cpupools.c
+++ b/xen/common/boot_cpupools.c
@@ -192,8 +192,11 @@ void __init btcpupools_allocate_pools(void)
 if ( add_extra_cpupool )
 next_pool_id++;
 
+/* Keep track of cpupool id 0 with the global cpupool0 */
+cpupool0 = cpupool_create_pool(0, pool_sched_map[0]);
+
 /* Create cpupools with selected schedulers */
-for ( i = 0; i < next_pool_id; i++ )
+for ( i = 1; i < next_pool_id; i++ )
 cpupool_create_pool(i, pool_sched_map[i]);
 }
 
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index e5189c53a321..f717ee844e91 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -312,10 +312,7 @@ static struct cpupool *cpupool_create(unsigned int poolid,
 c->cpupool_id = q->cpupool_id + 1;
 }
 
-if ( poolid == 0 )
-c->sched = scheduler_get_default();
-else
-c->sched = scheduler_alloc(sched_id);
+c->sched = scheduler_alloc(sched_id);
 if ( IS_ERR(c->sched) )
 {
 ret = PTR_ERR(c->sched);
@@ -1242,9 +1239,6 @@ static int __init cf_check cpupool_init(void)
 
 cpupool_hypfs_init();
 
-cpupool0 = cpupool_create(0, 0);
-BUG_ON(IS_ERR(cpupool0));
-cpupool_put(cpupool0);
 register_cpu_notifier(&cpu_nfb);
 
 btcpupools_dtb_parse();
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index b62315ad5e5d..e8f31758c058 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1185,7 +1185,10 @@ void btcpupools_dtb_parse(void);
 int btcpupools_get_domain_pool_id(const struct dt_device_node *node);
 
 #else /* !CONFIG_BOOT_TIME_CPUPOOLS */
-static inline void btcpupools_allocate_pools(void) {}
+static inline void btcpupools_allocate_pools(void)
+{
+cpupool0 = cpupool_create_pool(0, -1);
+}
 static inline void btcpupools_dtb_parse(void) {}
 static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
 {
-- 
2.17.1

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

2022-03-24 Thread Luca Fancellu

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

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

Documentation is created to explain the feature.

Signed-off-by: Luca Fancellu 
---
Changes in v4:
- modify Makefile to put in *.init.o, fixed stubs and macro (Jan)
- fixed docs, fix brakets (Stefano)
- keep cpu0 in Pool-0 (Julien)
- moved printk from btcpupools_allocate_pools to
  btcpupools_get_cpupool_id
- Add to docs constraint about cpu0 and Pool-0
Changes in v3:
- Add newline to cpupools.txt and removed "default n" from Kconfig (Jan)
- Fixed comment, moved defines, used global cpu_online_map, use
  HAS_DEVICE_TREE instead of ARM and place arch specific code in header
  (Juergen)
- Fix brakets, x86 code only panic, get rid of scheduler dt node, don't
  save pool pointer and look for it from the pool list (Stefano)
- Changed data structures to allow modification to the code.
Changes in v2:
- Move feature to common code (Juergen)
- Try to decouple dtb parse and cpupool creation to allow
  more way to specify cpupools (for example command line)
- Created standalone dt node for the scheduler so it can
  be used in future work to set scheduler specific
  parameters
- Use only auto generated ids for cpupools
---
 docs/misc/arm/device-tree/cpupools.txt | 136 ++
 xen/arch/arm/include/asm/smp.h |   3 +
 xen/common/Kconfig |   7 +
 xen/common/Makefile|   1 +
 xen/common/boot_cpupools.c | 190 +
 xen/common/sched/cpupool.c |   9 +-
 xen/include/xen/sched.h|  14 ++
 7 files changed, 359 insertions(+), 1 deletion(-)
 create mode 100644 docs/misc/arm/device-tree/cpupools.txt
 create mode 100644 xen/common/boot_cpupools.c

diff --git a/docs/misc/arm/device-tree/cpupools.txt 
b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index ..5dac2b1384e0
--- /dev/null
+++ b/docs/misc/arm/device-tree/cpupools.txt
@@ -0,0 +1,136 @@
+Boot time cpupools
+==
+
+When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible to
+create cpupools during boot phase by specifying them in the device tree.
+
+Cpupools specification nodes shall be direct childs of /chosen node.
+Each cpupool node contains the following properties:
+
+- compatible (mandatory)
+
+Must always include the compatiblity string: "xen,cpupool".
+
+- cpupool-cpus (mandatory)
+
+Must be a list of device tree phandle to nodes describing cpus (e.g. having
+device_type = "cpu"), it can't be empty.
+
+- cpupool-sched (optional)
+
+Must be a string having the name of a Xen scheduler. Check the sched=<...>
+boot argument for allowed values.
+
+
+Constraints
+===
+
+If no cpupools are specified, all cpus will be assigned to one cpupool
+implicitly created (Pool-0).
+
+If cpupools node are specified, but not every cpu brought up by Xen is 
assigned,
+all the not assigned cpu will be assigned to an additional cpupool.
+
+If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen will
+stop.
+
+The boot cpu must be assigned to Pool-0, so the cpupool containing that core
+will become Pool-0 automatically.
+
+
+Examples
+
+
+A system having two types of core, the following device tree specification will
+instruct Xen to have two cpupools:
+
+- The cpupool with id 0 will have 4 cpus assigned.
+- The cpupool with id 1 will have 2 cpus assigned.
+
+The following example can work only if hmp-unsafe=1 is passed to Xen boot
+arguments, otherwise not all cores will be brought up by Xen and the cpupool
+creation process will stop Xen.
+
+
+a72_1: cpu@0 {
+compatible = "arm,cortex-a72";
+reg = <0x0 0x0>;
+device_type = "cpu";
+[...]
+};
+
+a72_2: cpu@1 {
+compatible = "arm,cortex-a72";
+reg = <0x0 0x1>;
+device_type = "cpu";
+[...]
+};
+
+a53_1: cpu@100 {
+compatible = "arm,cortex-a53";
+reg = <0x0 0x100>;
+device_type = "cpu";
+[...]
+};
+
+a53_2: cpu@101 {
+compatible = "arm,cortex-a53";
+reg = <0x0 0x101>;
+device_type = "cpu";
+[...]
+};
+
+a53_3: cpu@102 {
+compatible = "arm,cortex-a53";
+reg = <0x0 0x102>;
+device_type = "cpu";
+[...]
+};
+
+a53_4: cpu@103 {
+compatible = "arm,cortex-a53";
+reg = <0x0 0x103>;
+device_type = "cpu";
+[...]
+};
+
+chosen {
+
+cpupool_a {
+compatible = "xen,cpupool";
+cpupool-cpus = <&a53_1 &a53_2 &a53_3 &a53_4>;
+};
+cpupool_b {
+compatible = "xen,cpupool";
+cpupool-cpus = <&a72_1 &a72_2>;
+cpupool-sched

Re: Support status of OpenBSD frontend drivers

2022-03-24 Thread Roger Pau Monné

On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
> As per private discussion with Theo de Raadt, OpenBSD does not consider
> bugs in its xnf(4) that allow a backend to cause mischief to be security
> issues.  I believe the same applies to its xbf(4).  Should the support
> document be updated?

I think that's already reflected in the support document:

'Status, OpenBSD: Supported, Security support external'

Since the security support is external it's my understanding OpenBSD
security team gets to decide what's a security issue and what is not.

That however creates differences in the level of support offered by
the different OSes, but I think that's unavoidable. It's also hard to
track the status here because those are external components in
separate code bases.

Could be added as a mention together with the Windows note about
frontends trusting backends, but then I would fear this is likely to
get out of sync if OpenBSD ever changes their frontends to support
untrusted backends (even if not considered as a security issue).

Thanks, Roger.

[ovmf test] 168824: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   23 days  244 attempts
Testing same since   168774  2022-03-22 08:40:31 Z2 days   25 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

Re: [PATCH 1/3] x86/mem_sharing: option to skip populating special pages during fork

2022-03-24 Thread Roger Pau Monné

On Tue, Mar 22, 2022 at 01:41:37PM -0400, Tamas K Lengyel wrote:
> Add option to the fork memop to skip populating the fork with special pages.
> These special pages are only necessary when setting up forks to be fully
> functional with a toolstack. For short-lived forks where no toolstack is 
> active
> these pages are uneccesary.

I'm not sure those are strictly related to having a toolstack. For
example the vcpu_info has nothing to do with having a toolstack, and
is only used by the guest in order to receive events or fetch time
related data. So while a short-lived fork might not make use of those,
that has nothing to do with having a toolstack or not.

> 
> Signed-off-by: Tamas K Lengyel 
> ---
>  xen/arch/x86/include/asm/hvm/domain.h |  4 +++-
>  xen/arch/x86/mm/mem_sharing.c | 33 +--
>  xen/include/public/memory.h   |  4 ++--
>  3 files changed, 26 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/x86/include/asm/hvm/domain.h 
> b/xen/arch/x86/include/asm/hvm/domain.h
> index 698455444e..446cd06411 100644
> --- a/xen/arch/x86/include/asm/hvm/domain.h
> +++ b/xen/arch/x86/include/asm/hvm/domain.h
> @@ -31,7 +31,9 @@
>  #ifdef CONFIG_MEM_SHARING
>  struct mem_sharing_domain
>  {
> -bool enabled, block_interrupts;
> +bool enabled;
> +bool block_interrupts;
> +bool skip_special_pages;
>  
>  /*
>   * When releasing shared gfn's in a preemptible manner, recall where
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 15e6a7ed81..84c04ddfa3 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1643,7 +1643,8 @@ static int bring_up_vcpus(struct domain *cd, struct 
> domain *d)
>  return 0;
>  }
>  
> -static int copy_vcpu_settings(struct domain *cd, const struct domain *d)
> +static int copy_vcpu_settings(struct domain *cd, const struct domain *d,
> +  bool skip_special_pages)
>  {
>  unsigned int i;
>  struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> @@ -1660,7 +1661,7 @@ static int copy_vcpu_settings(struct domain *cd, const 
> struct domain *d)
>  
>  /* Copy & map in the vcpu_info page if the guest uses one */
>  vcpu_info_mfn = d_vcpu->vcpu_info_mfn;
> -if ( !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
> +if ( !skip_special_pages && !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
>  {
>  mfn_t new_vcpu_info_mfn = cd_vcpu->vcpu_info_mfn;
>  
> @@ -1807,17 +1808,18 @@ static int copy_special_pages(struct domain *cd, 
> struct domain *d)
>  return 0;
>  }
>  
> -static int copy_settings(struct domain *cd, struct domain *d)
> +static int copy_settings(struct domain *cd, struct domain *d,
> + bool skip_special_pages)
>  {
>  int rc;
>  
> -if ( (rc = copy_vcpu_settings(cd, d)) )
> +if ( (rc = copy_vcpu_settings(cd, d, skip_special_pages)) )
>  return rc;
>  
>  if ( (rc = hvm_copy_context_and_params(cd, d)) )
>  return rc;
>  
> -if ( (rc = copy_special_pages(cd, d)) )
> +if ( !skip_special_pages && (rc = copy_special_pages(cd, d)) )
>  return rc;
>  
>  copy_tsc(cd, d);
> @@ -1826,9 +1828,11 @@ static int copy_settings(struct domain *cd, struct 
> domain *d)
>  return rc;
>  }
>  
> -static int fork(struct domain *cd, struct domain *d)
> +static int fork(struct domain *cd, struct domain *d, uint16_t flags)
>  {
>  int rc = -EBUSY;
> +bool block_interrupts = flags & XENMEM_FORK_BLOCK_INTERRUPTS;
> +bool skip_special_pages = flags & XENMEM_FORK_SKIP_SPECIAL_PAGES;
>  
>  if ( !cd->controller_pause_count )
>  return rc;
> @@ -1856,7 +1860,13 @@ static int fork(struct domain *cd, struct domain *d)
>  if ( (rc = bring_up_vcpus(cd, d)) )
>  goto done;
>  
> -rc = copy_settings(cd, d);
> +if ( !(rc = copy_settings(cd, d, skip_special_pages)) )

Can you set
cd->arch.hvm.mem_sharing.{block_interrupts,skip_special_pages} earlier
so that you don't need to pass the options around to copy_settings and
copy_vcpu_settings?

> +{
> +cd->arch.hvm.mem_sharing.block_interrupts = block_interrupts;
> +cd->arch.hvm.mem_sharing.skip_special_pages = skip_special_pages;
> +/* skip mapping the vAPIC page on unpause if skipping special pages 
> */
> +cd->creation_finished = skip_special_pages;

I think this is dangerous. While it might be true at the moment that
the arch_domain_creation_finished only maps the vAPIC page, there's no
guarantee it couldn't do other stuff in the future that could be
required for the VM to be started.

Does it add much overhead to map the vAPIC page?

Thanks, Roger.

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

2022-03-24 Thread osstest service owner

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

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  1c80f13a6efdc832878d7a431e2c216039d063bc
baseline version:
 xen  69e46280937526db9cf78259cd8a0a9ec62dc847

Last test of basis   168778  2022-03-22 13:03:05 Z2 days
Testing same since   168821  2022-03-24 11:03:05 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Juergen Gross 
  Julien Grall 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   69e4628093..1c80f13a6e  1c80f13a6efdc832878d7a431e2c216039d063bc -> smoke

Re: [PATCH 1/3] x86/mem_sharing: option to skip populating special pages during fork

2022-03-24 Thread Tamas K Lengyel

On Thu, Mar 24, 2022 at 10:50 AM Roger Pau Monné  wrote:
>
> On Tue, Mar 22, 2022 at 01:41:37PM -0400, Tamas K Lengyel wrote:
> > Add option to the fork memop to skip populating the fork with special pages.
> > These special pages are only necessary when setting up forks to be fully
> > functional with a toolstack. For short-lived forks where no toolstack is 
> > active
> > these pages are uneccesary.
>
> I'm not sure those are strictly related to having a toolstack. For
> example the vcpu_info has nothing to do with having a toolstack, and
> is only used by the guest in order to receive events or fetch time
> related data. So while a short-lived fork might not make use of those,
> that has nothing to do with having a toolstack or not.

Fair enough, the point is that the short live fork doesn't use these pages.

> >
> > Signed-off-by: Tamas K Lengyel 
> > ---
> >  xen/arch/x86/include/asm/hvm/domain.h |  4 +++-
> >  xen/arch/x86/mm/mem_sharing.c | 33 +--
> >  xen/include/public/memory.h   |  4 ++--
> >  3 files changed, 26 insertions(+), 15 deletions(-)
> >
> > diff --git a/xen/arch/x86/include/asm/hvm/domain.h 
> > b/xen/arch/x86/include/asm/hvm/domain.h
> > index 698455444e..446cd06411 100644
> > --- a/xen/arch/x86/include/asm/hvm/domain.h
> > +++ b/xen/arch/x86/include/asm/hvm/domain.h
> > @@ -31,7 +31,9 @@
> >  #ifdef CONFIG_MEM_SHARING
> >  struct mem_sharing_domain
> >  {
> > -bool enabled, block_interrupts;
> > +bool enabled;
> > +bool block_interrupts;
> > +bool skip_special_pages;
> >
> >  /*
> >   * When releasing shared gfn's in a preemptible manner, recall where
> > diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> > index 15e6a7ed81..84c04ddfa3 100644
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -1643,7 +1643,8 @@ static int bring_up_vcpus(struct domain *cd, struct 
> > domain *d)
> >  return 0;
> >  }
> >
> > -static int copy_vcpu_settings(struct domain *cd, const struct domain *d)
> > +static int copy_vcpu_settings(struct domain *cd, const struct domain *d,
> > +  bool skip_special_pages)
> >  {
> >  unsigned int i;
> >  struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> > @@ -1660,7 +1661,7 @@ static int copy_vcpu_settings(struct domain *cd, 
> > const struct domain *d)
> >
> >  /* Copy & map in the vcpu_info page if the guest uses one */
> >  vcpu_info_mfn = d_vcpu->vcpu_info_mfn;
> > -if ( !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
> > +if ( !skip_special_pages && !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
> >  {
> >  mfn_t new_vcpu_info_mfn = cd_vcpu->vcpu_info_mfn;
> >
> > @@ -1807,17 +1808,18 @@ static int copy_special_pages(struct domain *cd, 
> > struct domain *d)
> >  return 0;
> >  }
> >
> > -static int copy_settings(struct domain *cd, struct domain *d)
> > +static int copy_settings(struct domain *cd, struct domain *d,
> > + bool skip_special_pages)
> >  {
> >  int rc;
> >
> > -if ( (rc = copy_vcpu_settings(cd, d)) )
> > +if ( (rc = copy_vcpu_settings(cd, d, skip_special_pages)) )
> >  return rc;
> >
> >  if ( (rc = hvm_copy_context_and_params(cd, d)) )
> >  return rc;
> >
> > -if ( (rc = copy_special_pages(cd, d)) )
> > +if ( !skip_special_pages && (rc = copy_special_pages(cd, d)) )
> >  return rc;
> >
> >  copy_tsc(cd, d);
> > @@ -1826,9 +1828,11 @@ static int copy_settings(struct domain *cd, struct 
> > domain *d)
> >  return rc;
> >  }
> >
> > -static int fork(struct domain *cd, struct domain *d)
> > +static int fork(struct domain *cd, struct domain *d, uint16_t flags)
> >  {
> >  int rc = -EBUSY;
> > +bool block_interrupts = flags & XENMEM_FORK_BLOCK_INTERRUPTS;
> > +bool skip_special_pages = flags & XENMEM_FORK_SKIP_SPECIAL_PAGES;
> >
> >  if ( !cd->controller_pause_count )
> >  return rc;
> > @@ -1856,7 +1860,13 @@ static int fork(struct domain *cd, struct domain *d)
> >  if ( (rc = bring_up_vcpus(cd, d)) )
> >  goto done;
> >
> > -rc = copy_settings(cd, d);
> > +if ( !(rc = copy_settings(cd, d, skip_special_pages)) )
>
> Can you set
> cd->arch.hvm.mem_sharing.{block_interrupts,skip_special_pages} earlier
> so that you don't need to pass the options around to copy_settings and
> copy_vcpu_settings?

Would be possible yes, but then we would have to clear them in case
the forking failed at any point. Setting them only at the end when the
fork finished ensures that those fields are only ever valid if the VM
is a fork. Both are valid approaches and I prefer this over the other.

>
> > +{
> > +cd->arch.hvm.mem_sharing.block_interrupts = block_interrupts;
> > +cd->arch.hvm.mem_sharing.skip_special_pages = skip_special_pages;
> > +/* skip mapping the vAPIC page on unpause if skipping special 
> > pages */
> > +cd

Re: [PATCH v3 2/5] xen: make evtchn_alloc_unbound public

2022-03-24 Thread Daniel P. Smith

On 3/22/22 20:22, Stefano Stabellini wrote:
> On Tue, 15 Mar 2022, Daniel P. Smith wrote:
>> On 1/28/22 16:33, Stefano Stabellini wrote:
>>> From: Luca Miccio 
>>>
>>> The xenstore event channel will be allocated for dom0less domains. It is
>>> necessary to have access to the evtchn_alloc_unbound function to do
>>> that, so make evtchn_alloc_unbound public.
>>>
>>> Add a skip_xsm parameter to allow disabling the XSM check in
>>> evtchn_alloc_unbound (xsm_evtchn_unbound wouldn't work for a call
>>> originated from Xen before running any domains.)
>>>
>>> Signed-off-by: Luca Miccio 
>>> Signed-off-by: Stefano Stabellini 
>>> CC: Julien Grall 
>>> CC: Volodymyr Babchuk 
>>> CC: Bertrand Marquis 
>>> CC: Andrew Cooper 
>>> CC: George Dunlap 
>>> CC: Jan Beulich 
>>> CC: Wei Liu 
>>> ---
>>> Changes v3:
>>> - expose evtchn_alloc_unbound, assing a skip_xsm parameter
>>> ---
>>>  xen/common/event_channel.c | 13 -
>>>  xen/include/xen/event.h|  3 +++
>>>  2 files changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
>>> index da88ad141a..be57d00a15 100644
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -284,7 +284,7 @@ void evtchn_free(struct domain *d, struct evtchn *chn)
>>>  xsm_evtchn_close_post(chn);
>>>  }
>>>  
>>> -static int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
>>> +int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc, bool skip_xsm)
>>>  {
>>>  struct evtchn *chn;
>>>  struct domain *d;
>>> @@ -301,9 +301,12 @@ static int evtchn_alloc_unbound(evtchn_alloc_unbound_t 
>>> *alloc)
>>>  ERROR_EXIT_DOM(port, d);
>>>  chn = evtchn_from_port(d, port);
>>>  
>>> -rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, alloc->remote_dom);
>>> -if ( rc )
>>> -goto out;
>>> +if ( !skip_xsm )
>>> +{
>>> +rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, alloc->remote_dom);
>>> +if ( rc )
>>> +goto out;
>>> +}
>>
>> Please do not subvert the security framework because it causes an
>> inconvenience. As Jan recommended, work within the XSM check to allow
>> your access so that we may ensure it is done safely. If you need any
>> help making modifications to XSM, please do not hesitate to reach out as
>> I will gladly help.
> 
> Thank you!
> 
> First let me reply to Jan: this series is only introducing 1 more call
> to evtchn_alloc_unbound, which is to allocate the special xenstore event
> channel, the one configured via
> d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN].
> 
> It is not meant to be a generic function, and it is not meant to be
> called more than once. It could (should?) be __init.
> 
> The existing XSM check in evtchn_alloc_unbound cannot work and should
> not work: it is based on the current domain having enough privileges to
> create the event channel. In this case, we have no current domain at
> all. The current domain is Xen itself.

I have already replicated this in hyperlaunch for PV construction where
I have constructed the event channel for both xenstore and the console.
For hyperlaunch the construction is under a single, fairly-tight
function where I have promoted the Idle Domain to is_privileged before
the creation/construction loop starts and then demote the Idle Domain on
the other side of the loop. Honestly this is not my preferred approach
but for the initial implementation I do have a moderate amount of
confidence regarding the risk that results. My current thinking is that
the more appropriate approach would be to introduce a new system domain,
Construct Domain??, to provide a separate context under which all the
hyperlaunch creation and construction logic would be done and then
destroyed as part of init finalization.

> For these reasons, given [1], also not to subvert the security
> framework as Daniel pointed out, I think I should go back to my own
> implementation [2][3] based on get_free_port. That is my preference
> because:
> 
> - the Xen codebase doesn't gain much by reusing evtchn_alloc_unbound
> - adding skip_xsm introduces a component of risk (unless we make it
>   __init maybe?)
> - using get_free_port is trivial and doesn't pose the same issues
> 
> 
> Let's find all an agreement on how to move forward on this.
> 
> 
> [1] https://marc.info/?l=xen-devel&m=164194128922838
> [2] https://marc.info/?l=xen-devel&m=164203543615114
> [3] https://marc.info/?l=xen-devel&m=164203544615129

Re: [PATCH 3/3] x86/mem_sharing: make fork_reset more configurable

2022-03-24 Thread Roger Pau Monné

On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 208d8dcbd9..30ce23c5a7 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -541,12 +541,14 @@ struct xen_mem_sharing_op {
>  uint32_t gref; /* IN: gref to debug */
>  } u;
>  } debug;
> -struct mem_sharing_op_fork {  /* OP_FORK */
> +struct mem_sharing_op_fork {  /* OP_FORK/_RESET */
>  domid_t parent_domain;/* IN: parent's domain id */
>  /* These flags only makes sense for short-lived forks */
>  #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0)
>  #define XENMEM_FORK_BLOCK_INTERRUPTS   (1u << 1)
>  #define XENMEM_FORK_SKIP_SPECIAL_PAGES (1u << 2)
> +#define XENMEM_FORK_RESET_STATE(1u << 3)
> +#define XENMEM_FORK_RESET_MEMORY   (1u << 4)
>  uint16_t flags;   /* IN: optional settings */
>  uint32_t pad; /* Must be set to 0 */
>  } fork;
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index bb003d21d0..81c2ee28cc 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -127,6 +127,14 @@
>   * Reset the vmtrace buffer (if vmtrace is enabled)
>   */
>  #define VM_EVENT_FLAG_RESET_VMTRACE  (1 << 13)
> +/*
> + * Reset the VM state (if VM is fork)
> + */
> +#define VM_EVENT_FLAG_RESET_FORK_STATE   (1 << 14)
> +/*
> + * Remove unshared entried from physmap (if VM is fork)
> + */
> +#define VM_EVENT_FLAG_RESET_FORK_MEMORY  (1 << 15)

I'm confused about why two different interfaces are added to do this
kind of selective resets, one to vm_event and one to xenmem_fork?

I thin k the natural place for the option to live would be
XENMEM_FORK?

Thanks, Roger.

Re: Support status of OpenBSD frontend drivers

2022-03-24 Thread Demi Marie Obenour

On 3/24/22 10:11, Roger Pau Monné wrote:
> On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
>> As per private discussion with Theo de Raadt, OpenBSD does not consider
>> bugs in its xnf(4) that allow a backend to cause mischief to be security
>> issues.  I believe the same applies to its xbf(4).  Should the support
>> document be updated?
> 
> I think that's already reflected in the support document:
> 
> 'Status, OpenBSD: Supported, Security support external'
> 
> Since the security support is external it's my understanding OpenBSD
> security team gets to decide what's a security issue and what is not.
> 
> That however creates differences in the level of support offered by
> the different OSes, but I think that's unavoidable. It's also hard to
> track the status here because those are external components in
> separate code bases.
> 
> Could be added as a mention together with the Windows note about
> frontends trusting backends, but then I would fear this is likely to
> get out of sync if OpenBSD ever changes their frontends to support
> untrusted backends (even if not considered as a security issue).

As a Qubes OS developer, I still think this is useful information and
should be documented.  For instance, if I choose to add proper OpenBSD
guest support to Qubes OS (as opposed to the current “you can run
anything in an HVM” situation), I might decide to have OpenBSD
guests use devices emulated by a Linux-based stubdomain, since the
stubdomain’s netfront and blkfront drivers *are* security-supported
against malicious backends.  I might also choose to have a warning in
the GUI when switching the NetVM of an OpenBSD guest to something other
than the empty string (meaning no network access) or the (normally
fairly trusted) sys-firewall or sys-whonix qubes.

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

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 1/3] x86/mem_sharing: option to skip populating special pages during fork

2022-03-24 Thread Roger Pau Monné

On Thu, Mar 24, 2022 at 11:15:08AM -0400, Tamas K Lengyel wrote:
> On Thu, Mar 24, 2022 at 10:50 AM Roger Pau Monné  wrote:
> >
> > On Tue, Mar 22, 2022 at 01:41:37PM -0400, Tamas K Lengyel wrote:
> > > Add option to the fork memop to skip populating the fork with special 
> > > pages.
> > > These special pages are only necessary when setting up forks to be fully
> > > functional with a toolstack. For short-lived forks where no toolstack is 
> > > active
> > > these pages are uneccesary.
> >
> > I'm not sure those are strictly related to having a toolstack. For
> > example the vcpu_info has nothing to do with having a toolstack, and
> > is only used by the guest in order to receive events or fetch time
> > related data. So while a short-lived fork might not make use of those,
> > that has nothing to do with having a toolstack or not.
> 
> Fair enough, the point is that the short live fork doesn't use these pages.
> 
> > >
> > > Signed-off-by: Tamas K Lengyel 
> > > ---
> > >  xen/arch/x86/include/asm/hvm/domain.h |  4 +++-
> > >  xen/arch/x86/mm/mem_sharing.c | 33 +--
> > >  xen/include/public/memory.h   |  4 ++--
> > >  3 files changed, 26 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/xen/arch/x86/include/asm/hvm/domain.h 
> > > b/xen/arch/x86/include/asm/hvm/domain.h
> > > index 698455444e..446cd06411 100644
> > > --- a/xen/arch/x86/include/asm/hvm/domain.h
> > > +++ b/xen/arch/x86/include/asm/hvm/domain.h
> > > @@ -31,7 +31,9 @@
> > >  #ifdef CONFIG_MEM_SHARING
> > >  struct mem_sharing_domain
> > >  {
> > > -bool enabled, block_interrupts;
> > > +bool enabled;
> > > +bool block_interrupts;
> > > +bool skip_special_pages;
> > >
> > >  /*
> > >   * When releasing shared gfn's in a preemptible manner, recall where
> > > diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> > > index 15e6a7ed81..84c04ddfa3 100644
> > > --- a/xen/arch/x86/mm/mem_sharing.c
> > > +++ b/xen/arch/x86/mm/mem_sharing.c
> > > @@ -1643,7 +1643,8 @@ static int bring_up_vcpus(struct domain *cd, struct 
> > > domain *d)
> > >  return 0;
> > >  }
> > >
> > > -static int copy_vcpu_settings(struct domain *cd, const struct domain *d)
> > > +static int copy_vcpu_settings(struct domain *cd, const struct domain *d,
> > > +  bool skip_special_pages)
> > >  {
> > >  unsigned int i;
> > >  struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> > > @@ -1660,7 +1661,7 @@ static int copy_vcpu_settings(struct domain *cd, 
> > > const struct domain *d)
> > >
> > >  /* Copy & map in the vcpu_info page if the guest uses one */
> > >  vcpu_info_mfn = d_vcpu->vcpu_info_mfn;
> > > -if ( !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
> > > +if ( !skip_special_pages && !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
> > >  {
> > >  mfn_t new_vcpu_info_mfn = cd_vcpu->vcpu_info_mfn;
> > >
> > > @@ -1807,17 +1808,18 @@ static int copy_special_pages(struct domain *cd, 
> > > struct domain *d)
> > >  return 0;
> > >  }
> > >
> > > -static int copy_settings(struct domain *cd, struct domain *d)
> > > +static int copy_settings(struct domain *cd, struct domain *d,
> > > + bool skip_special_pages)
> > >  {
> > >  int rc;
> > >
> > > -if ( (rc = copy_vcpu_settings(cd, d)) )
> > > +if ( (rc = copy_vcpu_settings(cd, d, skip_special_pages)) )
> > >  return rc;
> > >
> > >  if ( (rc = hvm_copy_context_and_params(cd, d)) )
> > >  return rc;
> > >
> > > -if ( (rc = copy_special_pages(cd, d)) )
> > > +if ( !skip_special_pages && (rc = copy_special_pages(cd, d)) )
> > >  return rc;
> > >
> > >  copy_tsc(cd, d);
> > > @@ -1826,9 +1828,11 @@ static int copy_settings(struct domain *cd, struct 
> > > domain *d)
> > >  return rc;
> > >  }
> > >
> > > -static int fork(struct domain *cd, struct domain *d)
> > > +static int fork(struct domain *cd, struct domain *d, uint16_t flags)
> > >  {
> > >  int rc = -EBUSY;
> > > +bool block_interrupts = flags & XENMEM_FORK_BLOCK_INTERRUPTS;
> > > +bool skip_special_pages = flags & XENMEM_FORK_SKIP_SPECIAL_PAGES;
> > >
> > >  if ( !cd->controller_pause_count )
> > >  return rc;
> > > @@ -1856,7 +1860,13 @@ static int fork(struct domain *cd, struct domain 
> > > *d)
> > >  if ( (rc = bring_up_vcpus(cd, d)) )
> > >  goto done;
> > >
> > > -rc = copy_settings(cd, d);
> > > +if ( !(rc = copy_settings(cd, d, skip_special_pages)) )
> >
> > Can you set
> > cd->arch.hvm.mem_sharing.{block_interrupts,skip_special_pages} earlier
> > so that you don't need to pass the options around to copy_settings and
> > copy_vcpu_settings?
> 
> Would be possible yes, but then we would have to clear them in case
> the forking failed at any point. Setting them only at the end when the
> fork finished ensures that those fields are only ever valid if the VM
> is a fork. Both are valid

Re: [PATCH 3/3] x86/mem_sharing: make fork_reset more configurable

2022-03-24 Thread Tamas K Lengyel

On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné  wrote:
>
> On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index 208d8dcbd9..30ce23c5a7 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -541,12 +541,14 @@ struct xen_mem_sharing_op {
> >  uint32_t gref; /* IN: gref to debug */
> >  } u;
> >  } debug;
> > -struct mem_sharing_op_fork {  /* OP_FORK */
> > +struct mem_sharing_op_fork {  /* OP_FORK/_RESET */
> >  domid_t parent_domain;/* IN: parent's domain id */
> >  /* These flags only makes sense for short-lived forks */
> >  #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0)
> >  #define XENMEM_FORK_BLOCK_INTERRUPTS   (1u << 1)
> >  #define XENMEM_FORK_SKIP_SPECIAL_PAGES (1u << 2)
> > +#define XENMEM_FORK_RESET_STATE(1u << 3)
> > +#define XENMEM_FORK_RESET_MEMORY   (1u << 4)
> >  uint16_t flags;   /* IN: optional settings */
> >  uint32_t pad; /* Must be set to 0 */
> >  } fork;
> > diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> > index bb003d21d0..81c2ee28cc 100644
> > --- a/xen/include/public/vm_event.h
> > +++ b/xen/include/public/vm_event.h
> > @@ -127,6 +127,14 @@
> >   * Reset the vmtrace buffer (if vmtrace is enabled)
> >   */
> >  #define VM_EVENT_FLAG_RESET_VMTRACE  (1 << 13)
> > +/*
> > + * Reset the VM state (if VM is fork)
> > + */
> > +#define VM_EVENT_FLAG_RESET_FORK_STATE   (1 << 14)
> > +/*
> > + * Remove unshared entried from physmap (if VM is fork)
> > + */
> > +#define VM_EVENT_FLAG_RESET_FORK_MEMORY  (1 << 15)
>
> I'm confused about why two different interfaces are added to do this
> kind of selective resets, one to vm_event and one to xenmem_fork?
>
> I thin k the natural place for the option to live would be
> XENMEM_FORK?

Yes, that's the natural place for it. But we are adding it to both for
a reason. In our use-case the reset operation will happen after a
vm_event is received to which we already must send a reply. Setting
the flag on the vm_event reply saves us having to issue an extra memop
hypercall afterwards.

Tamas

Re: [PATCH 3/3] x86/mem_sharing: make fork_reset more configurable

2022-03-24 Thread Roger Pau Monné

On Thu, Mar 24, 2022 at 11:52:38AM -0400, Tamas K Lengyel wrote:
> On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné  wrote:
> >
> > On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> > > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > > index 208d8dcbd9..30ce23c5a7 100644
> > > --- a/xen/include/public/memory.h
> > > +++ b/xen/include/public/memory.h
> > > @@ -541,12 +541,14 @@ struct xen_mem_sharing_op {
> > >  uint32_t gref; /* IN: gref to debug */
> > >  } u;
> > >  } debug;
> > > -struct mem_sharing_op_fork {  /* OP_FORK */
> > > +struct mem_sharing_op_fork {  /* OP_FORK/_RESET */
> > >  domid_t parent_domain;/* IN: parent's domain id */
> > >  /* These flags only makes sense for short-lived forks */
> > >  #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0)
> > >  #define XENMEM_FORK_BLOCK_INTERRUPTS   (1u << 1)
> > >  #define XENMEM_FORK_SKIP_SPECIAL_PAGES (1u << 2)
> > > +#define XENMEM_FORK_RESET_STATE(1u << 3)
> > > +#define XENMEM_FORK_RESET_MEMORY   (1u << 4)
> > >  uint16_t flags;   /* IN: optional settings */
> > >  uint32_t pad; /* Must be set to 0 */
> > >  } fork;
> > > diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> > > index bb003d21d0..81c2ee28cc 100644
> > > --- a/xen/include/public/vm_event.h
> > > +++ b/xen/include/public/vm_event.h
> > > @@ -127,6 +127,14 @@
> > >   * Reset the vmtrace buffer (if vmtrace is enabled)
> > >   */
> > >  #define VM_EVENT_FLAG_RESET_VMTRACE  (1 << 13)
> > > +/*
> > > + * Reset the VM state (if VM is fork)
> > > + */
> > > +#define VM_EVENT_FLAG_RESET_FORK_STATE   (1 << 14)
> > > +/*
> > > + * Remove unshared entried from physmap (if VM is fork)
> > > + */
> > > +#define VM_EVENT_FLAG_RESET_FORK_MEMORY  (1 << 15)
> >
> > I'm confused about why two different interfaces are added to do this
> > kind of selective resets, one to vm_event and one to xenmem_fork?
> >
> > I thin k the natural place for the option to live would be
> > XENMEM_FORK?
> 
> Yes, that's the natural place for it. But we are adding it to both for
> a reason. In our use-case the reset operation will happen after a
> vm_event is received to which we already must send a reply. Setting
> the flag on the vm_event reply saves us having to issue an extra memop
> hypercall afterwards.

Can you do a multicall and batch both operations in a single
hypercall?

That would seem more natural than adding duplicated interfaces.

Thanks, Roger.

Re: [PATCH 3/3] x86/mem_sharing: make fork_reset more configurable

2022-03-24 Thread Tamas K Lengyel

On Thu, Mar 24, 2022 at 12:04 PM Roger Pau Monné  wrote:
>
> On Thu, Mar 24, 2022 at 11:52:38AM -0400, Tamas K Lengyel wrote:
> > On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné  
> > wrote:
> > >
> > > On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> > > > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > > > index 208d8dcbd9..30ce23c5a7 100644
> > > > --- a/xen/include/public/memory.h
> > > > +++ b/xen/include/public/memory.h
> > > > @@ -541,12 +541,14 @@ struct xen_mem_sharing_op {
> > > >  uint32_t gref; /* IN: gref to debug */
> > > >  } u;
> > > >  } debug;
> > > > -struct mem_sharing_op_fork {  /* OP_FORK */
> > > > +struct mem_sharing_op_fork {  /* OP_FORK/_RESET */
> > > >  domid_t parent_domain;/* IN: parent's domain id */
> > > >  /* These flags only makes sense for short-lived forks */
> > > >  #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0)
> > > >  #define XENMEM_FORK_BLOCK_INTERRUPTS   (1u << 1)
> > > >  #define XENMEM_FORK_SKIP_SPECIAL_PAGES (1u << 2)
> > > > +#define XENMEM_FORK_RESET_STATE(1u << 3)
> > > > +#define XENMEM_FORK_RESET_MEMORY   (1u << 4)
> > > >  uint16_t flags;   /* IN: optional settings */
> > > >  uint32_t pad; /* Must be set to 0 */
> > > >  } fork;
> > > > diff --git a/xen/include/public/vm_event.h 
> > > > b/xen/include/public/vm_event.h
> > > > index bb003d21d0..81c2ee28cc 100644
> > > > --- a/xen/include/public/vm_event.h
> > > > +++ b/xen/include/public/vm_event.h
> > > > @@ -127,6 +127,14 @@
> > > >   * Reset the vmtrace buffer (if vmtrace is enabled)
> > > >   */
> > > >  #define VM_EVENT_FLAG_RESET_VMTRACE  (1 << 13)
> > > > +/*
> > > > + * Reset the VM state (if VM is fork)
> > > > + */
> > > > +#define VM_EVENT_FLAG_RESET_FORK_STATE   (1 << 14)
> > > > +/*
> > > > + * Remove unshared entried from physmap (if VM is fork)
> > > > + */
> > > > +#define VM_EVENT_FLAG_RESET_FORK_MEMORY  (1 << 15)
> > >
> > > I'm confused about why two different interfaces are added to do this
> > > kind of selective resets, one to vm_event and one to xenmem_fork?
> > >
> > > I thin k the natural place for the option to live would be
> > > XENMEM_FORK?
> >
> > Yes, that's the natural place for it. But we are adding it to both for
> > a reason. In our use-case the reset operation will happen after a
> > vm_event is received to which we already must send a reply. Setting
> > the flag on the vm_event reply saves us having to issue an extra memop
> > hypercall afterwards.
>
> Can you do a multicall and batch both operations in a single
> hypercall?
>
> That would seem more natural than adding duplicated interfaces.

Not in a straight forward way, no. There is no exposed API in libxc to
do a multicall. Even if that was an option it is still easier for me
to just flip a bit in the response field than having to construct a
whole standalone hypercall structure to be sent as part of a
multicall.

Tamas

Re: [PATCH 1/3] x86/mem_sharing: option to skip populating special pages during fork

2022-03-24 Thread Tamas K Lengyel

On Thu, Mar 24, 2022 at 11:51 AM Roger Pau Monné  wrote:
>
> On Thu, Mar 24, 2022 at 11:15:08AM -0400, Tamas K Lengyel wrote:
> > On Thu, Mar 24, 2022 at 10:50 AM Roger Pau Monné  
> > wrote:
> > >
> > > On Tue, Mar 22, 2022 at 01:41:37PM -0400, Tamas K Lengyel wrote:
> > > > Add option to the fork memop to skip populating the fork with special 
> > > > pages.
> > > > These special pages are only necessary when setting up forks to be fully
> > > > functional with a toolstack. For short-lived forks where no toolstack 
> > > > is active
> > > > these pages are uneccesary.
> > >
> > > I'm not sure those are strictly related to having a toolstack. For
> > > example the vcpu_info has nothing to do with having a toolstack, and
> > > is only used by the guest in order to receive events or fetch time
> > > related data. So while a short-lived fork might not make use of those,
> > > that has nothing to do with having a toolstack or not.
> >
> > Fair enough, the point is that the short live fork doesn't use these pages.
> >
> > > >
> > > > Signed-off-by: Tamas K Lengyel 
> > > > ---
> > > >  xen/arch/x86/include/asm/hvm/domain.h |  4 +++-
> > > >  xen/arch/x86/mm/mem_sharing.c | 33 +--
> > > >  xen/include/public/memory.h   |  4 ++--
> > > >  3 files changed, 26 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/xen/arch/x86/include/asm/hvm/domain.h 
> > > > b/xen/arch/x86/include/asm/hvm/domain.h
> > > > index 698455444e..446cd06411 100644
> > > > --- a/xen/arch/x86/include/asm/hvm/domain.h
> > > > +++ b/xen/arch/x86/include/asm/hvm/domain.h
> > > > @@ -31,7 +31,9 @@
> > > >  #ifdef CONFIG_MEM_SHARING
> > > >  struct mem_sharing_domain
> > > >  {
> > > > -bool enabled, block_interrupts;
> > > > +bool enabled;
> > > > +bool block_interrupts;
> > > > +bool skip_special_pages;
> > > >
> > > >  /*
> > > >   * When releasing shared gfn's in a preemptible manner, recall 
> > > > where
> > > > diff --git a/xen/arch/x86/mm/mem_sharing.c 
> > > > b/xen/arch/x86/mm/mem_sharing.c
> > > > index 15e6a7ed81..84c04ddfa3 100644
> > > > --- a/xen/arch/x86/mm/mem_sharing.c
> > > > +++ b/xen/arch/x86/mm/mem_sharing.c
> > > > @@ -1643,7 +1643,8 @@ static int bring_up_vcpus(struct domain *cd, 
> > > > struct domain *d)
> > > >  return 0;
> > > >  }
> > > >
> > > > -static int copy_vcpu_settings(struct domain *cd, const struct domain 
> > > > *d)
> > > > +static int copy_vcpu_settings(struct domain *cd, const struct domain 
> > > > *d,
> > > > +  bool skip_special_pages)
> > > >  {
> > > >  unsigned int i;
> > > >  struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> > > > @@ -1660,7 +1661,7 @@ static int copy_vcpu_settings(struct domain *cd, 
> > > > const struct domain *d)
> > > >
> > > >  /* Copy & map in the vcpu_info page if the guest uses one */
> > > >  vcpu_info_mfn = d_vcpu->vcpu_info_mfn;
> > > > -if ( !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
> > > > +if ( !skip_special_pages && !mfn_eq(vcpu_info_mfn, 
> > > > INVALID_MFN) )
> > > >  {
> > > >  mfn_t new_vcpu_info_mfn = cd_vcpu->vcpu_info_mfn;
> > > >
> > > > @@ -1807,17 +1808,18 @@ static int copy_special_pages(struct domain 
> > > > *cd, struct domain *d)
> > > >  return 0;
> > > >  }
> > > >
> > > > -static int copy_settings(struct domain *cd, struct domain *d)
> > > > +static int copy_settings(struct domain *cd, struct domain *d,
> > > > + bool skip_special_pages)
> > > >  {
> > > >  int rc;
> > > >
> > > > -if ( (rc = copy_vcpu_settings(cd, d)) )
> > > > +if ( (rc = copy_vcpu_settings(cd, d, skip_special_pages)) )
> > > >  return rc;
> > > >
> > > >  if ( (rc = hvm_copy_context_and_params(cd, d)) )
> > > >  return rc;
> > > >
> > > > -if ( (rc = copy_special_pages(cd, d)) )
> > > > +if ( !skip_special_pages && (rc = copy_special_pages(cd, d)) )
> > > >  return rc;
> > > >
> > > >  copy_tsc(cd, d);
> > > > @@ -1826,9 +1828,11 @@ static int copy_settings(struct domain *cd, 
> > > > struct domain *d)
> > > >  return rc;
> > > >  }
> > > >
> > > > -static int fork(struct domain *cd, struct domain *d)
> > > > +static int fork(struct domain *cd, struct domain *d, uint16_t flags)
> > > >  {
> > > >  int rc = -EBUSY;
> > > > +bool block_interrupts = flags & XENMEM_FORK_BLOCK_INTERRUPTS;
> > > > +bool skip_special_pages = flags & XENMEM_FORK_SKIP_SPECIAL_PAGES;
> > > >
> > > >  if ( !cd->controller_pause_count )
> > > >  return rc;
> > > > @@ -1856,7 +1860,13 @@ static int fork(struct domain *cd, struct domain 
> > > > *d)
> > > >  if ( (rc = bring_up_vcpus(cd, d)) )
> > > >  goto done;
> > > >
> > > > -rc = copy_settings(cd, d);
> > > > +if ( !(rc = copy_settings(cd, d, skip_special_pages)) )
> > >
> > > Can you set
> > > cd->arch.hvm.mem_sharing.{block_interrupts,skip_special_pages} earlier
> > > so

[ovmf test] 168826: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   23 days  245 attempts
Testing same since   168774  2022-03-22 08:40:31 Z2 days   26 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

Re: [PATCH 3/3] x86/mem_sharing: make fork_reset more configurable

2022-03-24 Thread Roger Pau Monné

On Thu, Mar 24, 2022 at 12:22:49PM -0400, Tamas K Lengyel wrote:
> On Thu, Mar 24, 2022 at 12:04 PM Roger Pau Monné  wrote:
> >
> > On Thu, Mar 24, 2022 at 11:52:38AM -0400, Tamas K Lengyel wrote:
> > > On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné  
> > > wrote:
> > > >
> > > > On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> > > > > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > > > > index 208d8dcbd9..30ce23c5a7 100644
> > > > > --- a/xen/include/public/memory.h
> > > > > +++ b/xen/include/public/memory.h
> > > > > @@ -541,12 +541,14 @@ struct xen_mem_sharing_op {
> > > > >  uint32_t gref; /* IN: gref to debug */
> > > > >  } u;
> > > > >  } debug;
> > > > > -struct mem_sharing_op_fork {  /* OP_FORK */
> > > > > +struct mem_sharing_op_fork {  /* OP_FORK/_RESET */
> > > > >  domid_t parent_domain;/* IN: parent's domain id 
> > > > > */
> > > > >  /* These flags only makes sense for short-lived forks */
> > > > >  #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0)
> > > > >  #define XENMEM_FORK_BLOCK_INTERRUPTS   (1u << 1)
> > > > >  #define XENMEM_FORK_SKIP_SPECIAL_PAGES (1u << 2)
> > > > > +#define XENMEM_FORK_RESET_STATE(1u << 3)
> > > > > +#define XENMEM_FORK_RESET_MEMORY   (1u << 4)
> > > > >  uint16_t flags;   /* IN: optional settings */
> > > > >  uint32_t pad; /* Must be set to 0 */
> > > > >  } fork;
> > > > > diff --git a/xen/include/public/vm_event.h 
> > > > > b/xen/include/public/vm_event.h
> > > > > index bb003d21d0..81c2ee28cc 100644
> > > > > --- a/xen/include/public/vm_event.h
> > > > > +++ b/xen/include/public/vm_event.h
> > > > > @@ -127,6 +127,14 @@
> > > > >   * Reset the vmtrace buffer (if vmtrace is enabled)
> > > > >   */
> > > > >  #define VM_EVENT_FLAG_RESET_VMTRACE  (1 << 13)
> > > > > +/*
> > > > > + * Reset the VM state (if VM is fork)
> > > > > + */
> > > > > +#define VM_EVENT_FLAG_RESET_FORK_STATE   (1 << 14)
> > > > > +/*
> > > > > + * Remove unshared entried from physmap (if VM is fork)
> > > > > + */
> > > > > +#define VM_EVENT_FLAG_RESET_FORK_MEMORY  (1 << 15)
> > > >
> > > > I'm confused about why two different interfaces are added to do this
> > > > kind of selective resets, one to vm_event and one to xenmem_fork?
> > > >
> > > > I thin k the natural place for the option to live would be
> > > > XENMEM_FORK?
> > >
> > > Yes, that's the natural place for it. But we are adding it to both for
> > > a reason. In our use-case the reset operation will happen after a
> > > vm_event is received to which we already must send a reply. Setting
> > > the flag on the vm_event reply saves us having to issue an extra memop
> > > hypercall afterwards.
> >
> > Can you do a multicall and batch both operations in a single
> > hypercall?
> >
> > That would seem more natural than adding duplicated interfaces.
> 
> Not in a straight forward way, no. There is no exposed API in libxc to
> do a multicall. Even if that was an option it is still easier for me
> to just flip a bit in the response field than having to construct a
> whole standalone hypercall structure to be sent as part of a
> multicall.

Right, I can see it being easier, but it seems like a bad choice from
an interface PoV. You are the maintainer of both subsystems, but it
would seem to me it's in your best interest to try to keep the
interfaces separated and clean.

Would it be possible for the reset XENMEM_FORK op to have the side
effect of performing what you would instead do with the vm_event
hypercall?

Thanks, Roger.

Re: [PATCH 3/3] x86/mem_sharing: make fork_reset more configurable

2022-03-24 Thread Tamas K Lengyel

On Thu, Mar 24, 2022 at 12:44 PM Roger Pau Monné  wrote:
>
> On Thu, Mar 24, 2022 at 12:22:49PM -0400, Tamas K Lengyel wrote:
> > On Thu, Mar 24, 2022 at 12:04 PM Roger Pau Monné  
> > wrote:
> > >
> > > On Thu, Mar 24, 2022 at 11:52:38AM -0400, Tamas K Lengyel wrote:
> > > > On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné  
> > > > wrote:
> > > > >
> > > > > On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> > > > > > diff --git a/xen/include/public/memory.h 
> > > > > > b/xen/include/public/memory.h
> > > > > > index 208d8dcbd9..30ce23c5a7 100644
> > > > > > --- a/xen/include/public/memory.h
> > > > > > +++ b/xen/include/public/memory.h
> > > > > > @@ -541,12 +541,14 @@ struct xen_mem_sharing_op {
> > > > > >  uint32_t gref; /* IN: gref to debug */
> > > > > >  } u;
> > > > > >  } debug;
> > > > > > -struct mem_sharing_op_fork {  /* OP_FORK */
> > > > > > +struct mem_sharing_op_fork {  /* OP_FORK/_RESET */
> > > > > >  domid_t parent_domain;/* IN: parent's domain 
> > > > > > id */
> > > > > >  /* These flags only makes sense for short-lived forks */
> > > > > >  #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0)
> > > > > >  #define XENMEM_FORK_BLOCK_INTERRUPTS   (1u << 1)
> > > > > >  #define XENMEM_FORK_SKIP_SPECIAL_PAGES (1u << 2)
> > > > > > +#define XENMEM_FORK_RESET_STATE(1u << 3)
> > > > > > +#define XENMEM_FORK_RESET_MEMORY   (1u << 4)
> > > > > >  uint16_t flags;   /* IN: optional settings 
> > > > > > */
> > > > > >  uint32_t pad; /* Must be set to 0 */
> > > > > >  } fork;
> > > > > > diff --git a/xen/include/public/vm_event.h 
> > > > > > b/xen/include/public/vm_event.h
> > > > > > index bb003d21d0..81c2ee28cc 100644
> > > > > > --- a/xen/include/public/vm_event.h
> > > > > > +++ b/xen/include/public/vm_event.h
> > > > > > @@ -127,6 +127,14 @@
> > > > > >   * Reset the vmtrace buffer (if vmtrace is enabled)
> > > > > >   */
> > > > > >  #define VM_EVENT_FLAG_RESET_VMTRACE  (1 << 13)
> > > > > > +/*
> > > > > > + * Reset the VM state (if VM is fork)
> > > > > > + */
> > > > > > +#define VM_EVENT_FLAG_RESET_FORK_STATE   (1 << 14)
> > > > > > +/*
> > > > > > + * Remove unshared entried from physmap (if VM is fork)
> > > > > > + */
> > > > > > +#define VM_EVENT_FLAG_RESET_FORK_MEMORY  (1 << 15)
> > > > >
> > > > > I'm confused about why two different interfaces are added to do this
> > > > > kind of selective resets, one to vm_event and one to xenmem_fork?
> > > > >
> > > > > I thin k the natural place for the option to live would be
> > > > > XENMEM_FORK?
> > > >
> > > > Yes, that's the natural place for it. But we are adding it to both for
> > > > a reason. In our use-case the reset operation will happen after a
> > > > vm_event is received to which we already must send a reply. Setting
> > > > the flag on the vm_event reply saves us having to issue an extra memop
> > > > hypercall afterwards.
> > >
> > > Can you do a multicall and batch both operations in a single
> > > hypercall?
> > >
> > > That would seem more natural than adding duplicated interfaces.
> >
> > Not in a straight forward way, no. There is no exposed API in libxc to
> > do a multicall. Even if that was an option it is still easier for me
> > to just flip a bit in the response field than having to construct a
> > whole standalone hypercall structure to be sent as part of a
> > multicall.
>
> Right, I can see it being easier, but it seems like a bad choice from
> an interface PoV. You are the maintainer of both subsystems, but it
> would seem to me it's in your best interest to try to keep the
> interfaces separated and clean.
>
> Would it be possible for the reset XENMEM_FORK op to have the side
> effect of performing what you would instead do with the vm_event
> hypercall?

Yes, the event response is really just an event channel signal to Xen,
so the memop hypercall could similarly encode the "now check the
vm_event response" as an optional field. But why is that any better
than the current event channel route processing the vm_response
encoding the "now do these ops on the fork"?

We already have a bunch of different operations you can encode in the
vm_event response field, so it reduces the complexity on the toolstack
side since I don't have to switch around which hypercall I need to
issue depending on what extra ops I want to put into a single
hypercall.

Tamas

[ovmf test] 168827: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   23 days  246 attempts
Testing same since   168774  2022-03-22 08:40:31 Z2 days   27 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

[ovmf test] 168829: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   23 days  247 attempts
Testing same since   168774  2022-03-22 08:40:31 Z2 days   28 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

Re: Support status of OpenBSD frontend drivers

2022-03-24 Thread Marek Marczykowski-Górecki

On Thu, Mar 24, 2022 at 11:49:14AM -0400, Demi Marie Obenour wrote:
> On 3/24/22 10:11, Roger Pau Monné wrote:
> > On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
> >> As per private discussion with Theo de Raadt, OpenBSD does not consider
> >> bugs in its xnf(4) that allow a backend to cause mischief to be security
> >> issues.  I believe the same applies to its xbf(4).  Should the support
> >> document be updated?
> > 
> > I think that's already reflected in the support document:
> > 
> > 'Status, OpenBSD: Supported, Security support external'
> > 
> > Since the security support is external it's my understanding OpenBSD
> > security team gets to decide what's a security issue and what is not.
> > 
> > That however creates differences in the level of support offered by
> > the different OSes, but I think that's unavoidable. It's also hard to
> > track the status here because those are external components in
> > separate code bases.
> > 
> > Could be added as a mention together with the Windows note about
> > frontends trusting backends, but then I would fear this is likely to
> > get out of sync if OpenBSD ever changes their frontends to support
> > untrusted backends (even if not considered as a security issue).
> 
> As a Qubes OS developer, I still think this is useful information and
> should be documented.  For instance, if I choose to add proper OpenBSD
> guest support to Qubes OS (as opposed to the current “you can run
> anything in an HVM” situation), I might decide to have OpenBSD
> guests use devices emulated by a Linux-based stubdomain, since the
> stubdomain’s netfront and blkfront drivers *are* security-supported
> against malicious backends.  I might also choose to have a warning in
> the GUI when switching the NetVM of an OpenBSD guest to something other
> than the empty string (meaning no network access) or the (normally
> fairly trusted) sys-firewall or sys-whonix qubes.

I'm with Roger on this - when security support is external, such
information in xen.git could easily become stale. If anything, there
could be a link to OpenBSD security status info, maintained by whoever
such support provides.

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


signature.asc
Description: PGP signature

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

2022-03-24 Thread osstest service owner

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

Failures :-/ but no regressions.

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

Re: [PATCH v3 2/5] xen: make evtchn_alloc_unbound public

2022-03-24 Thread Stefano Stabellini

On Wed, 23 Mar 2022, Jan Beulich wrote:
> On 23.03.2022 01:22, Stefano Stabellini wrote:
> > On Tue, 15 Mar 2022, Daniel P. Smith wrote:
> >> On 1/28/22 16:33, Stefano Stabellini wrote:
> >>> From: Luca Miccio 
> >>>
> >>> The xenstore event channel will be allocated for dom0less domains. It is
> >>> necessary to have access to the evtchn_alloc_unbound function to do
> >>> that, so make evtchn_alloc_unbound public.
> >>>
> >>> Add a skip_xsm parameter to allow disabling the XSM check in
> >>> evtchn_alloc_unbound (xsm_evtchn_unbound wouldn't work for a call
> >>> originated from Xen before running any domains.)
> >>>
> >>> Signed-off-by: Luca Miccio 
> >>> Signed-off-by: Stefano Stabellini 
> >>> CC: Julien Grall 
> >>> CC: Volodymyr Babchuk 
> >>> CC: Bertrand Marquis 
> >>> CC: Andrew Cooper 
> >>> CC: George Dunlap 
> >>> CC: Jan Beulich 
> >>> CC: Wei Liu 
> >>> ---
> >>> Changes v3:
> >>> - expose evtchn_alloc_unbound, assing a skip_xsm parameter
> >>> ---
> >>>  xen/common/event_channel.c | 13 -
> >>>  xen/include/xen/event.h|  3 +++
> >>>  2 files changed, 11 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> >>> index da88ad141a..be57d00a15 100644
> >>> --- a/xen/common/event_channel.c
> >>> +++ b/xen/common/event_channel.c
> >>> @@ -284,7 +284,7 @@ void evtchn_free(struct domain *d, struct evtchn *chn)
> >>>  xsm_evtchn_close_post(chn);
> >>>  }
> >>>  
> >>> -static int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
> >>> +int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc, bool skip_xsm)
> >>>  {
> >>>  struct evtchn *chn;
> >>>  struct domain *d;
> >>> @@ -301,9 +301,12 @@ static int 
> >>> evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
> >>>  ERROR_EXIT_DOM(port, d);
> >>>  chn = evtchn_from_port(d, port);
> >>>  
> >>> -rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, alloc->remote_dom);
> >>> -if ( rc )
> >>> -goto out;
> >>> +if ( !skip_xsm )
> >>> +{
> >>> +rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, alloc->remote_dom);
> >>> +if ( rc )
> >>> +goto out;
> >>> +}
> >>
> >> Please do not subvert the security framework because it causes an
> >> inconvenience. As Jan recommended, work within the XSM check to allow
> >> your access so that we may ensure it is done safely. If you need any
> >> help making modifications to XSM, please do not hesitate to reach out as
> >> I will gladly help.
> > 
> > Thank you!
> > 
> > First let me reply to Jan: this series is only introducing 1 more call
> > to evtchn_alloc_unbound, which is to allocate the special xenstore event
> > channel, the one configured via
> > d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN].
> > 
> > It is not meant to be a generic function, and it is not meant to be
> > called more than once. It could (should?) be __init.
> 
> How that? Its pre-existing use doesn't disappear, and requires it to be
> non-__init.

Sorry I meant the new function (calling get_free_port) for the new
use-case could be __init. The new function could be added to
xen/common/event_channel.c or to xen/arch/arm/domain_build.c.


> > The existing XSM check in evtchn_alloc_unbound cannot work and should
> > not work: it is based on the current domain having enough privileges to
> > create the event channel. In this case, we have no current domain at
> > all. The current domain is Xen itself.
> 
> And DOM_XEN cannot be given the appropriate permission, perhaps
> explicitly when using a real policy and by default in dummy and SILO
> modes?

The issue is that the check is based on "current", not one of the
domains passed as an argument to evtchn_alloc_unbound. Otherwise,
passing DOMID_XEN would be straightforward.

We would need to use a hack (like Daniel wrote in the other email) to
set the idle_domain temporarily as a privileged domain only for the sake
of passing an irrelevant (irrelevant as in "not relevant to this case")
XSM check. That cannot be an improvement. Also, setting current to a
"fake" domain is not great either.

In the specific case of dom0less and this patch, this is the only
instance of this issue and could be solved very straightforwardly by
calling get_free_port directly as we discussed [1].

I know Julien had some reservations about that. Let's try to find a
technical solution that makes everyone happy.

Maybe, instead of exporting get_free_port, we could create a new
function in xen/common/event_channel.c and mark it as __init? This way:
- we don't need to expose get_free_port
- the new function would only be __init anyway, so no risk of runtime
  misuse

What do you think?

[1] https://marc.info/?l=xen-devel&m=164197327305903

[PATCH] xen/arm: set CPSR Z bit when creating aarch32 guests

2022-03-24 Thread Stefano Stabellini

From: Stefano Stabellini 

The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
kernel, certain versions of Linux will use an UNPREDICATABLE NOP
encoding, sometimes resulting in an unbootable kernel. Whether the
resulting kernel is bootable or not depends on the processor. See commit
a92882a4d270 in the Linux kernel for all the details.

All kernel releases starting from Linux 4.9 without commit a92882a4d270
are affected.

Fortunately there is a simple workaround: setting the "Z" bit in CPSR
make it so those invalid NOP instructions are never executed. That is
because the instruction is conditional (not equal). So, on QEMU at
least, the instruction will end up to be ignored and not generate an
exception. Setting the "Z" bit makes those kernel versions bootable
again and it is harmless in the other cases.

Note that both U-Boot and QEMU -kernel set the "Z" bit in CPSR when
booting a zImage kernel on aarch32.

Signed-off-by: Stefano Stabellini 
---
Changes in v3:
- improve commit message
- improve in-code comment

Changes in v2:
- improve commit message
- add in-code comment
- move PSR_Z to the beginning
---
 xen/include/public/arch-arm.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 94b31511dd..c0c1149e27 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -361,6 +361,7 @@ typedef uint64_t xen_callback_t;
 #define PSR_DBG_MASK(1<<9)/* arm64: Debug Exception mask */
 #define PSR_IT_MASK (0x0600fc00)  /* Thumb If-Then Mask */
 #define PSR_JAZELLE (1<<24)   /* Jazelle Mode */
+#define PSR_Z   (1<<30)   /* Zero condition flag */
 
 /* 32 bit modes */
 #define PSR_MODE_USR 0x10
@@ -383,7 +384,15 @@ typedef uint64_t xen_callback_t;
 #define PSR_MODE_EL1t 0x04
 #define PSR_MODE_EL0t 0x00
 
-#define PSR_GUEST32_INIT  (PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC)
+/*
+ * We set PSR_Z to be able to boot Linux kernel versions with an invalid
+ * encoding of the first 8 NOP instructions. See commit a92882a4d270 in
+ * Linux.
+ *
+ * Note that PSR_Z is also set by U-Boot and QEMU -kernel when loading
+ * zImage kernels on aarch32.
+ */
+#define PSR_GUEST32_INIT  
(PSR_Z|PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC)
 #define PSR_GUEST64_INIT (PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_EL1h)
 
 #define SCTLR_GUEST_INITxen_mk_ullong(0x00c50078)
-- 
2.25.1

Re: Support status of OpenBSD frontend drivers

2022-03-24 Thread Demi Marie Obenour

On 3/24/22 18:21, Marek Marczykowski-Górecki wrote:
> On Thu, Mar 24, 2022 at 11:49:14AM -0400, Demi Marie Obenour wrote:
>> On 3/24/22 10:11, Roger Pau Monné wrote:
>>> On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
 As per private discussion with Theo de Raadt, OpenBSD does not consider
 bugs in its xnf(4) that allow a backend to cause mischief to be security
 issues.  I believe the same applies to its xbf(4).  Should the support
 document be updated?
>>>
>>> I think that's already reflected in the support document:
>>>
>>> 'Status, OpenBSD: Supported, Security support external'
>>>
>>> Since the security support is external it's my understanding OpenBSD
>>> security team gets to decide what's a security issue and what is not.
>>>
>>> That however creates differences in the level of support offered by
>>> the different OSes, but I think that's unavoidable. It's also hard to
>>> track the status here because those are external components in
>>> separate code bases.
>>>
>>> Could be added as a mention together with the Windows note about
>>> frontends trusting backends, but then I would fear this is likely to
>>> get out of sync if OpenBSD ever changes their frontends to support
>>> untrusted backends (even if not considered as a security issue).
>>
>> As a Qubes OS developer, I still think this is useful information and
>> should be documented.  For instance, if I choose to add proper OpenBSD
>> guest support to Qubes OS (as opposed to the current “you can run
>> anything in an HVM” situation), I might decide to have OpenBSD
>> guests use devices emulated by a Linux-based stubdomain, since the
>> stubdomain’s netfront and blkfront drivers *are* security-supported
>> against malicious backends.  I might also choose to have a warning in
>> the GUI when switching the NetVM of an OpenBSD guest to something other
>> than the empty string (meaning no network access) or the (normally
>> fairly trusted) sys-firewall or sys-whonix qubes.
> 
> I'm with Roger on this - when security support is external, such
> information in xen.git could easily become stale. If anything, there
> could be a link to OpenBSD security status info, maintained by whoever
> such support provides.

This ought to be on https://man.openbsd.org/xnf.4 and
https://man.openbsd.org/xbf.4, but it is not.  Should I send a patch?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Proposal for Porting Xen to Armv8-R64 - DraftB

2022-03-24 Thread Wei Chen

# Proposal for Porting Xen to Armv8-R64

This proposal will introduce the PoC work of porting Xen to Armv8-R64,
which includes:
- The changes of current Xen capability, like Xen build system, memory
  management, domain management, vCPU context switch.
- The expanded Xen capability, like static-allocation and direct-map.

***Notes:***
1. ***This proposal only covers the work of porting Xen to Armv8-R64***
   ***single CPU.Xen SMP support on Armv8-R64 relates to Armv8-R***
   ***Trusted-Frimware (TF-R). This is an external dependency,***
   ***so we think the discussion of Xen SMP support on Armv8-R64***
   ***should be started when single-CPU support is complete.***
2. ***This proposal will not touch xen-tools. In current stange,***
   ***Xen on Armv8-R64 only support dom0less, all guests should***
   ***be booted from device tree.***

## Changelogs
Draft-A -> Draft-B:
1. Update Kconfig options usage.
2. Update the section for XEN_START_ADDRESS.
3. Add description of MPU initialization before parsing device tree.
4. Remove CONFIG_ARM_MPU_EL1_PROTECTION_REGIONS.
5. Update the description of ioremap_nocache/cache.
6. Update about the free_init_memory on Armv8-R.
7. Describe why we need to switch the MPU configuration later.
8. Add alternative proposal in TODO.
9. Add use tool to generate Xen Armv8-R device tree in TODO.
10. Add Xen PIC/PIE discussion in TODO.
11. Add Xen event channel support in TODO.

## Contributors:
Wei Chen 
Penny Zheng 

## 1. Essential Background

### 1.1. Armv8-R64 Profile
The Armv-R architecture profile was designed to support use cases that
have a high sensitivity to deterministic execution. (e.g. Fuel Injection,
Brake control, Drive trains, Motor control etc)

Arm announced Armv8-R in 2013, it is the latest generation Arm architecture
targeted at the Real-time profile. It introduces virtualization at the highest
security level while retaining the Protected Memory System Architecture (PMSA)
based on a Memory Protection Unit (MPU). In 2020, Arm announced Cortex-R82,
which is the first Arm 64-bit Cortex-R processor based on Armv8-R64.

- The latest Armv8-R64 document can be found here:
  [Arm Architecture Reference Manual Supplement - Armv8, for Armv8-R AArch64 
architecture profile](https://developer.arm.com/documentation/ddi0600/latest/).

- Armv-R Architecture progression:
  Armv7-R -> Armv8-R AArch32 -> Armv8 AArch64
  The following figure is a simple comparison of "R" processors based on
  different Armv-R Architectures.
  
![image](https://drive.google.com/uc?export=view&id=1nE5RAXaX8zY2KPZ8imBpbvIr2eqBguEB)

- The Armv8-R architecture evolved additional features on top of Armv7-R:
- An exception model that is compatible with the Armv8-A model
- Virtualization with support for guest operating systems
- PMSA virtualization using MPUs In EL2.
- The new features of Armv8-R64 architecture
- Adds support for the 64-bit A64 instruction set, previously Armv8-R
  only supported A32.
- Supports up to 48-bit physical addressing, previously up to 32-bit
  addressing was supported.
- Optional Arm Neon technology and Advanced SIMD
- Supports three Exception Levels (ELs)
- Secure EL2 - The Highest Privilege, MPU only, for firmware, hypervisor
- Secure EL1 - RichOS (MMU) or RTOS (MPU)
- Secure EL0 - Application Workloads
- Optionally supports Virtual Memory System Architecture at S-EL1/S-EL0.
  This means it's possible to run rich OS kernels - like Linux - either
  bare-metal or as a guest.
- Differences with the Armv8-A AArch64 architecture
- Supports only a single Security state - Secure. There is not Non-Secure
  execution state supported.
- EL3 is not supported, EL2 is mandatory. This means secure EL2 is the
  highest EL.
- Supports the A64 ISA instruction
- With a small set of well-defined differences
- Provides a PMSA (Protected Memory System Architecture) based
  virtualization model.
- As opposed to Armv8-A AArch64's VMSA based Virtualization
- Can support address bits up to 52 if FEAT_LPA is enabled,
  otherwise 48 bits.
- Determines the access permissions and memory attributes of
  the target PA.
- Can implement PMSAv8-64 at EL1 and EL2
- Address translation flat-maps the VA to the PA for EL2 Stage 1.
- Address translation flat-maps the VA to the PA for EL1 Stage 1.
- Address translation flat-maps the IPA to the PA for EL1 Stage 2.
- PMSA in EL1 & EL2 is configurable, VMSA in EL1 is configurable.

### 1.2. Xen Challenges with PMSA Virtualization
Xen is PMSA unaware Type-1 Hypervisor, it will need modifications to run
with an MPU and host multiple guest OSes.

- No MMU at EL2:
- No EL2 Stage 1 address translation
- Xen provides fixed ARM64 virtual memory layout as basis of EL2
  stage 1 address translation, which is not applicable on MPU system,
  where there i

[ovmf test] 168831: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   23 days  248 attempts
Testing same since   168774  2022-03-22 08:40:31 Z2 days   29 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

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

2022-03-24 Thread Stefano Stabellini

On Thu, 24 Mar 2022, Bertrand Marquis wrote:
> cppcheck can be used to check Xen code quality.
> 
> To create a report do "make cppcheck" on a built tree adding any options
> you added during the process you used to build xen (like CROSS_COMPILE
> or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml.
> 
> To create a html report do "make cppcheck-html" in the same way and a
> full report to be seen in a browser will be generated in
> cppcheck-htmlreport/index.html.
> 
> For better results it is recommended to build your own cppcheck from the
> latest sources that you can find at [1].
> Development and result analysis has been done with cppcheck 2.7.
> 
> The Makefile rule is searching for all C files which have been compiled
> (ie which have a generated .o file) and is running cppcheck on all of
> them using the current configuration of xen so only the code actually
> compiled is checked.
> 
> A new tool is introduced to merge all cppcheck reports into one global
> report including all findings and removing duplicates.
> 
> Some extra variables can be used to customize the report:
> - CPPCHECK can be used to give the full path to the cppcheck binary to
> use (default is to use the one from the standard path).
> - CPPCHECK_HTMLREPORT can be used to give the full path to
> cppcheck-htmlreport (default is to use the one from the standard path).
> 
> This has been tested on several arm configurations (x86 should work but
> has not been tested).
> 
> [1] https://cppcheck.sourceforge.io/
> 
> Signed-off-by: Bertrand Marquis 
> Signed-off-by: Michal Orzel 

Very cool, I was looking forward to this :-)


> diff --git a/xen/tools/merge_cppcheck_reports.py 
> b/xen/tools/merge_cppcheck_reports.py
> new file mode 100755
> index 00..ef055f6925
> --- /dev/null
> +++ b/xen/tools/merge_cppcheck_reports.py
> @@ -0,0 +1,73 @@
> +#!/usr/bin/env python
> +
> +"""
> +This script acts as a tool to merge XML files created by cppcheck.
> +Usage:
> +merge_cppcheck_reports.py [FILES] [OUTPUT]
> +
> +FILES  - list of XML files with extension .cppcheck
> +OUTPUT - file to store results (with .xml extension).
> + If not specified, the script will print results to stdout.
> +"""
> +
> +import sys
> +from xml.etree import ElementTree
> +
> +def elements_equal(el1, el2):
> +if type(el1) != type(el2): return False
> +
> +el1_location = str(el1.find('location').attrib)
> +el2_location = str(el2.find('location').attrib)
> +
> +if el1_location != el2_location: return False
> +
> +return True
> +
> +def remove_duplicates(xml_root_element):
> +elems_to_remove = []
> +index = 0
> +elems_list = list(xml_root_element.findall("errors")[0])
> +for elem1 in elems_list:
> +index += 1
> +for elem2 in elems_list[index:]:
> +if elements_equal(elem1, elem2) and elem2 not in elems_to_remove:
> +elems_to_remove.append(elem2)
> +continue
> +
> +for elem in elems_to_remove:
> +xml_root_element.findall("errors")[0].remove(elem)
> +
> +def merge(files):
> +result_xml_root = None
> +for xml_file in files:
> +xml_root = ElementTree.parse(xml_file).getroot()


Traceback (most recent call last):
  File "/local/repos/xen-upstream/xen/tools/merge_cppcheck_reports.py", line 
73, in 
run()
  File "/local/repos/xen-upstream/xen/tools/merge_cppcheck_reports.py", line 
60, in run
result = merge(files)
  File "/local/repos/xen-upstream/xen/tools/merge_cppcheck_reports.py", line 
43, in merge
xml_root = ElementTree.parse(xml_file).getroot()
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1182, in parse
tree.parse(source, parser)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 657, in parse
self._root = parser.close()
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1671, in close
self._raiseerror(v)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1523, in _raiseerror
raise err
xml.etree.ElementTree.ParseError: no element found: line 11, column 0
make: *** [Makefile:576: xen-cppcheck.xml] Error 1

I think we should catch the xml.etree.ElementTree.ParseError exception and 
continue?

RE: [PATCH] xen/arm: set CPSR Z bit when creating aarch32 guests

2022-03-24 Thread Wei Chen

Hi Stefano,

> -Original Message-
> From: Xen-devel  On Behalf Of
> Stefano Stabellini
> Sent: 2022年3月25日 9:01
> To: xen-devel@lists.xenproject.org
> Cc: jul...@xen.org; sstabell...@kernel.org; Bertrand Marquis
> ; volodymyr_babc...@epam.com; Stefano Stabellini
> 
> Subject: [PATCH] xen/arm: set CPSR Z bit when creating aarch32 guests
> 
> From: Stefano Stabellini 
> 
> The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
> kernel, certain versions of Linux will use an UNPREDICATABLE NOP
> encoding, sometimes resulting in an unbootable kernel. Whether the
> resulting kernel is bootable or not depends on the processor. See commit
> a92882a4d270 in the Linux kernel for all the details.
> 
> All kernel releases starting from Linux 4.9 without commit a92882a4d270
> are affected.
> 
> Fortunately there is a simple workaround: setting the "Z" bit in CPSR
> make it so those invalid NOP instructions are never executed. That is
> because the instruction is conditional (not equal). So, on QEMU at
> least, the instruction will end up to be ignored and not generate an
> exception. Setting the "Z" bit makes those kernel versions bootable
> again and it is harmless in the other cases.
> 
> Note that both U-Boot and QEMU -kernel set the "Z" bit in CPSR when
> booting a zImage kernel on aarch32.
> 
> Signed-off-by: Stefano Stabellini 
> ---
> Changes in v3:
> - improve commit message
> - improve in-code comment
> 
> Changes in v2:
> - improve commit message
> - add in-code comment
> - move PSR_Z to the beginning
> ---
>  xen/include/public/arch-arm.h | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 94b31511dd..c0c1149e27 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -361,6 +361,7 @@ typedef uint64_t xen_callback_t;
>  #define PSR_DBG_MASK(1<<9)/* arm64: Debug Exception mask */
>  #define PSR_IT_MASK (0x0600fc00)  /* Thumb If-Then Mask */
>  #define PSR_JAZELLE (1<<24)   /* Jazelle Mode */
> +#define PSR_Z   (1<<30)   /* Zero condition flag */
> 
>  /* 32 bit modes */
>  #define PSR_MODE_USR 0x10
> @@ -383,7 +384,15 @@ typedef uint64_t xen_callback_t;
>  #define PSR_MODE_EL1t 0x04
>  #define PSR_MODE_EL0t 0x00
> 
> -#define PSR_GUEST32_INIT
> (PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC)
> +/*
> + * We set PSR_Z to be able to boot Linux kernel versions with an invalid
> + * encoding of the first 8 NOP instructions. See commit a92882a4d270 in
> + * Linux.
> + *
> + * Note that PSR_Z is also set by U-Boot and QEMU -kernel when loading
> + * zImage kernels on aarch32.
> + */
> +#define PSR_GUEST32_INIT
> (PSR_Z|PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC)
>  #define PSR_GUEST64_INIT
> (PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_EL1h)
> 

Maybe this is a good opportunity to fix the alignment of the two macros : )

Reviewed-by: Wei Chen 

>  #define SCTLR_GUEST_INITxen_mk_ullong(0x00c50078)
> --
> 2.25.1
>

[ovmf test] 168832: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 69218d5d2854acaa7a11c777244de4a297d2fbb9
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   24 days  249 attempts
Testing same since   168832  2022-03-25 01:43:21 Z0 days1 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

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

2022-03-24 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuue309ce90a23bef4f5210a8c49d53441144be293c
baseline version:
 qemuu15ef89d2a1a7b93845a6b09c2ee8e1979f6eb30b

Last test of basis   168791  2022-03-22 23:09:00 Z2 days
Testing same since   168828  2022-03-24 17:07:03 Z0 days1 attempts


People who touched revisions under test:
  Aaron Larson 
  Alex Bennée 
  Christoph Muellner

[ovmf test] 168834: regressions - FAIL

2022-03-24 Thread osstest service owner

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

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 69218d5d2854acaa7a11c777244de4a297d2fbb9
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   24 days
Failing since168258  2022-03-01 01:55:31 Z   24 days  250 attempts
Testing same since   168832  2022-03-25 01:43:21 Z0 days2 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Mara Sophie Grosch 
  Mara Sophie Grosch via groups.io 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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

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

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

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


Not pushing.

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

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

2022-03-24 Thread osstest service owner

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 linux7403e6d8263937dea206dd201fed1ceed190ca18
baseline version:
 linuxed4643521e6af8ab8ed1e467630a85884d2696cf

Last test of basis   168816  2022-03-24 03:18:14 Z1 days
Testing same since   168830  2022-03-24 20:10:22 Z0 days1 attempts


People who touched revisions under test:
  Abhishek Sahu 
  Al Viro 
  Alex Williamson 
  Alexandru Elisei 
  Anssi Hannula 
  Anup Patel 
  Anup Patel 
  Barret Rhoden 
  Bjorn Helgaas 
  Bjorn Helgaas# pci_ids.h
  Catalin Marinas 
  Changcheng Deng 
  Christian Borntraeger 
  Christ

81 matches

Mail list logo