Re: [PATCH] x86: correct asm() constraints when dealing with immediate selector values

[Jan Beulich]

On 09.09.2021 21:31, Andrew Cooper wrote:
> On 09/09/2021 15:56, Jan Beulich wrote:
>> asm() constraints need to fit both the intended insn(s) which the
>> respective operands are going to be used with as well as the actual kind
>> of value specified. "m" (alone) together with a constant, however, leads
>> to gcc saying
>>
>> error: memory input  is not directly addressable
>>
>> while clang complains
>>
>> error: invalid lvalue in asm input for constraint 'm'
>>
>> And rightly so - in order to access a memory operand, an address needs
>> to be specified to the insn. In some cases it might be possible for a
>> compiler to synthesize a memory operand holding the requested constant,
>> but I think any solution there would have sharp edges.
> 
> It's precisely what happens in the other uses of constants which you
> haven't adjusted below.  Constants are fine if being propagated into a
> static inline which has properly typed parameters.
> 
> Or are you saying automatic spilling when a width isn't necessarily known?

The lack of width information is a secondary aspect, yes. But the primary
aspects with inline functions (as opposed to open-coded uses) is that the
inline function's parameter can be taken the address of, and hence is
both addressable (gcc) and an lvalue (clang).

>> If "m" alone doesn't work with constants, it is at best pointless (and
>> perhaps misleading or even risky - the compiler might decide to actually
>> pick "m" and not try very hard to find a suitable register) to specify
>> it alongside "r".
>>
>> Signed-off-by: Jan Beulich 
> 
> I'm slightly surprised you didn't spot and comment about what Clang does
> with this.
> 
> https://godbolt.org/z/M4nrerrWM
> 
> For "rm" (0), clang really does spill the constant into a global and
> generate a rip-relative mov to fs, which is especially funny considering
> the rejection of "m" as a constraint.

I had no reason to suspect such imo entirely inconsistent behavior, so
I didn't look at the generated code.

> Clang even spills "rm" (local) into a global, while "m" (local) does
> come from the stack.

"rm" (local)? That would be racy (and hence imo a compiler bug). DYM
"rm" (constant)? Or DYM spilling onto the stack (which is what I
observe with clang5, oddly enough independent of optimization level)?

> I think there is a reasonable argument to say "m" (const) doesn't have
> enough type (width) information for a compiler to do anything sensible
> with, and therefore it is fair to be dropped.
> 
> But for "rm" (var), where there is enough width information, I don't
> think it is reasonable to drop the "m" and restrict the flexibility.

Correct, and I don't do this. What I alter are instances of "rm" (const).

> Furthermore, I'm going to argue that we shouldn't work around this
> behaviour by removing "m" elsewhere.  This code generation
> bug/misfeature affects every use of "rm", even when the referenced
> operand is on the stack and can be used without unspilling first.

As long as the generated code is correct, I agree. See above for a case
where it might actually not be.

>> --- a/xen/arch/x86/x86_64/traps.c
>> +++ b/xen/arch/x86/x86_64/traps.c
>> @@ -248,7 +248,7 @@ void do_double_fault(struct cpu_user_reg
>>  
>>  console_force_unlock();
>>  
>> -asm ( "lsll %1, %0" : "=r" (cpu) : "rm" (PER_CPU_SELECTOR) );
>> +asm ( "lsll %1, %0" : "=r" (cpu) : "r" (PER_CPU_SELECTOR) );
> 
> Any chance we can clean this up to: lsl %[lim], %[sel] seeing as the
> line is being edited?

Sure, no problem at all.

Jan

Re: [PATCH] mini-os: xenbus: support large messages

[Juergen Gross]

On 18.08.21 17:26, Juergen Gross wrote:

Today the implementation of the xenbus protocol in Mini-OS will only
allow to transfer the complete message to or from the ring page buffer.
This is limiting the maximum message size to lower values as the xenbus
protocol normally would allow.

Change that by allowing to transfer the xenbus message in chunks as
soon as they are available.

Avoid crashing Mini-OS in case of illegal data read from the ring
buffer.

Signed-off-by: Juergen Gross 


Ping?


Juergen


---
  xenbus/xenbus.c | 212 
  1 file changed, 124 insertions(+), 88 deletions(-)

diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
index 23de61e..3fbb122 100644
--- a/xenbus/xenbus.c
+++ b/xenbus/xenbus.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define min(x,y) ({   \

  typeof(x) tmpx = (x); \
@@ -46,6 +47,7 @@
  static struct xenstore_domain_interface *xenstore_buf;
  static DECLARE_WAIT_QUEUE_HEAD(xb_waitq);
  DECLARE_WAIT_QUEUE_HEAD(xenbus_watch_queue);
+static __DECLARE_SEMAPHORE_GENERIC(xb_write_sem, 1);
  
  xenbus_event_queue xenbus_events;

  static struct watch {
@@ -231,75 +233,105 @@ char *xenbus_wait_for_state_change(const char* path, 
XenbusState *state, xenbus_
  }
  
  
+static void xenbus_read_data(char *buf, unsigned int len)

+{
+unsigned int off = 0;
+unsigned int prod;
+unsigned int size;
+int notify;
+
+while (off != len)
+{
+if (xenstore_buf->rsp_prod == xenstore_buf->rsp_cons)
+wait_event(xb_waitq,
+   xenstore_buf->rsp_prod != xenstore_buf->rsp_cons);
+
+prod = xenstore_buf->rsp_prod;
+DEBUG("Rsp_cons %d, rsp_prod %d.\n", xenstore_buf->rsp_cons, prod);
+size = min(len - off, prod - xenstore_buf->rsp_cons);
+memcpy_from_ring(xenstore_buf->rsp, buf + off,
+ MASK_XENSTORE_IDX(xenstore_buf->rsp_cons), size);
+off += size;
+notify = (xenstore_buf->rsp_cons + XENSTORE_RING_SIZE ==
+  xenstore_buf->rsp_prod);
+rmb();
+xenstore_buf->rsp_cons += size;
+wmb();
+if (notify)
+notify_remote_via_evtchn(xenbus_evtchn);
+}
+}
+
  static void xenbus_thread_func(void *ign)
  {
  struct xsd_sockmsg msg;
-unsigned prod = xenstore_buf->rsp_prod;
+char *data;
  
  for (;;) {

-wait_event(xb_waitq, prod != xenstore_buf->rsp_prod);
-while (1) {
-prod = xenstore_buf->rsp_prod;
-DEBUG("Rsp_cons %d, rsp_prod %d.\n", xenstore_buf->rsp_cons,
-  xenstore_buf->rsp_prod);
-if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < sizeof(msg))
-break;
-rmb();
-memcpy_from_ring(xenstore_buf->rsp, &msg,
- MASK_XENSTORE_IDX(xenstore_buf->rsp_cons),
- sizeof(msg));
-DEBUG("Msg len %d, %d avail, id %d.\n", msg.len + sizeof(msg),
-  xenstore_buf->rsp_prod - xenstore_buf->rsp_cons, msg.req_id);
-
-if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
-sizeof(msg) + msg.len)
-break;
-
-DEBUG("Message is good.\n");
-
-if (msg.type == XS_WATCH_EVENT) {
-struct xenbus_event *event = malloc(sizeof(*event) + msg.len);
-xenbus_event_queue *events = NULL;
-char *data = (char*)event + sizeof(*event);
-struct watch *watch;
-
-memcpy_from_ring(xenstore_buf->rsp, data,
-MASK_XENSTORE_IDX(xenstore_buf->rsp_cons + sizeof(msg)),
-msg.len);
-
-event->path = data;
-event->token = event->path + strlen(event->path) + 1;
-
-mb();
-xenstore_buf->rsp_cons += msg.len + sizeof(msg);
-
-for (watch = watches; watch; watch = watch->next)
-if (!strcmp(watch->token, event->token)) {
-events = watch->events;
-break;
-}
-
-if (events) {
-event->next = *events;
-*events = event;
-wake_up(&xenbus_watch_queue);
-} else {
-printk("unexpected watch token %s\n", event->token);
-free(event);
+xenbus_read_data((char *)&msg, sizeof(msg));
+DEBUG("Msg len %d, %d avail, id %d.\n", msg.len + sizeof(msg),
+  xenstore_buf->rsp_prod - xenstore_buf->rsp_cons, msg.req_id);
+
+if (msg.len > XENSTORE_PAYLOAD_MAX) {
+printk("Xenstore violates protocol, message longer than 
allowed.\n");
+return;
+}
+
+if (msg.type == XS_WATCH_EVENT) {
+struct xenbus_event *event = malloc(sizeof(*event) + msg.

Re: [PATCH v5 05/10] xsm: apply coding style

[Jan Beulich]

On 10.09.2021 04:12, Daniel P. Smith wrote:
> @@ -70,7 +73,7 @@ void __xsm_action_mismatch_detected(void);
>  #endif /* CONFIG_XSM */
>  
>  static always_inline int xsm_default_action(
> -xsm_default_t action, struct domain *src, struct domain *target)
> + xsm_default_t action, struct domain *src, struct domain *target)

Here and below you're now introducing hard tabs. In Xen style
we don't ever use hard tabs for indentation; this is limited to
files inherited from elsewhere.

It's also not clear why you've touched this instance at all:
The 4 chars indentation was correct already, as previously
pointed out by Andrew (on perhaps a different example).

Jan

Re: [PATCH v5 03/10] xsm: remove remnants of xsm_memtype hook

[Jan Beulich]

On 10.09.2021 04:12, Daniel P. Smith wrote:
> In c/s fcb8baddf00e the xsm_memtype hook was removed but some remnants were
> left behind. This commit cleans up those remnants.
> 
> Signed-off-by: Daniel P. Smith 

Acked-by: Jan Beulich 

Re: [PATCH v5 01/10] xen: Implement xen/alternative-call.h for use in common code

[Jan Beulich]

On 10.09.2021 04:12, Daniel P. Smith wrote:
> From: Andrew Cooper 
> 
> The alternative call infrastructure is x86-only for now, but the common iommu
> code has a variant and more common code wants to use the infrastructure.
> 
> Introduce CONFIG_ALTERNATIVE_CALL and a conditional implemetnation so common
> code can use the optimisation when available, without requiring all
> architectures to implement no-op stubs.
> 
> Write some documentation, which was thus far entirely absent, covering the
> requirements for an architecture to implement this optimsiation, and how to
> use the infrastructure in general code.
> 
> Signed-off-by: Andrew Cooper 
> Signed-off-by: Daniel P. Smith 

I did offer an A-b on v4, dependent upon two small adjustments. Was it
deliberate to neither make these adjustments nor add the ack? (At that
point I did offer making the adjustments while committing, but I think
it goes without saying that upon re-submission the changes should be
made. Unless of course there's disagreement about making them in the
first place. Yet such disagreement would be worth making explicit then,
imo.)

Jan

[PATCH v3 3/3] tools: disable building qemu-trad per default

[Juergen Gross]

Using qemu-traditional as device model is deprecated for some time now.

So change the default for building it to "disable". This will affect
ioemu-stubdom, too, as there is a direct dependency between the two.

Today it is possible to use a PVH/HVM Linux-based stubdom as device
model. Additionally using ioemu-stubdom isn't really helping for
security, as it requires to run a very old and potentially buggy qemu
version in a PV domain. This is adding probably more security problems
than it is removing by using a stubdom.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
Acked-by: Ian Jackson 
---
V2:
- new patch
---
 CHANGELOG.md |  3 +++
 stubdom/configure|  8 
 stubdom/configure.ac |  8 +---
 tools/configure  | 17 ++---
 tools/configure.ac   | 13 +
 5 files changed, 7 insertions(+), 42 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index e7107ac3de..e5ab49e779 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -18,6 +18,9 @@ The format is based on [Keep a 
Changelog](https://keepachangelog.com/en/1.0.0/)
or by passing "iommu=quarantine=scratch-page" on the hypervisor command 
line.
  - pv-grub stubdoms will no longer be built per default. In order to be able 
to use pv-grub
configure needs to be called with "--enable-pv-grub" as parameter.
+ - qemu-traditional based device models (both, qemu-traditional and 
ioemu-stubdom) will
+   no longer be built per default. In order to be able to use those, configure 
needs to
+   be called with "--enable-qemu-traditional" as parameter.
 
 ## [4.15.0 
UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.15.0)
 - TBD
 
diff --git a/stubdom/configure b/stubdom/configure
index df31532abb..07b709f998 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -2286,14 +2286,6 @@ fi
 # Check whether --enable-qemu-traditional was given.
 if test "${enable_qemu_traditional+set}" = set; then :
   enableval=$enable_qemu_traditional;
-else
-
-case "$host_cpu" in
-i[3456]86|x86_64)
-   enable_qemu_traditional="yes";;
-*) enable_qemu_traditional="no";;
-esac
-
 fi
 
 if test "x$enable_qemu_traditional" = "xyes"; then :
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index a07a1edae5..e20d99edac 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -27,13 +27,7 @@ AX_STUBDOM_DEFAULT_ENABLE([xenstorepvh-stubdom], 
[xenstorepvh])
 AX_STUBDOM_CONDITIONAL([vtpm-stubdom], [vtpm])
 AX_STUBDOM_CONDITIONAL([vtpmmgr-stubdom], [vtpmmgr])
 
-AC_ARG_ENABLE([qemu-traditional],,,[
-case "$host_cpu" in
-i[[3456]]86|x86_64)
-   enable_qemu_traditional="yes";;
-*) enable_qemu_traditional="no";;
-esac
-])
+AC_ARG_ENABLE([qemu-traditional])
 AS_IF([test "x$enable_qemu_traditional" = "xyes"], [
 qemu_traditional=y],[
 qemu_traditional=n
diff --git a/tools/configure b/tools/configure
index 33814b24b3..8bf8fe75b8 100755
--- a/tools/configure
+++ b/tools/configure
@@ -1502,8 +1502,8 @@ Optional Features:
   --disable-seabios   Disable SeaBIOS (default is ENABLED)
   --disable-golangDisable Go tools (default is ENABLED)
   --enable-qemu-traditional
-  Enable qemu traditional device model, (DEFAULT is on
-  for Linux or NetBSD x86, otherwise off)
+  Enable qemu traditional device model, (DEFAULT is
+  off)
   --enable-rombiosEnable ROMBIOS, (DEFAULT is on if qemu-traditional
   is enabled, otherwise off)
   --disable-ipxe  Enable in-tree IPXE, (DEFAULT is on if rombios is
@@ -4287,19 +4287,6 @@ LINUX_BACKEND_MODULES="`eval echo 
$LINUX_BACKEND_MODULES`"
 # Check whether --enable-qemu-traditional was given.
 if test "${enable_qemu_traditional+set}" = set; then :
   enableval=$enable_qemu_traditional;
-else
-
-case "$host_cpu" in
-i[3456]86|x86_64)
-   enable_qemu_traditional="yes";;
-*) enable_qemu_traditional="no";;
-esac
-case "$host_os" in
-freebsd*)
-   enable_qemu_traditional="no";;
-esac
-
-
 fi
 
 if test "x$enable_qemu_traditional" = "xyes"; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 6414fcbb44..a713fd34d6 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -120,18 +120,7 @@ AC_SUBST(LINUX_BACKEND_MODULES)
 
 AC_ARG_ENABLE([qemu-traditional],
 AS_HELP_STRING([--enable-qemu-traditional],
-   [Enable qemu traditional device model, (DEFAULT is on for 
Linux or NetBSD x86, otherwise off)]),,[
-case "$host_cpu" in
-i[[3456]]86|x86_64)
-   enable_qemu_traditional="yes";;
-*) enable_qemu_traditional="no";;
-esac
-case "$host_os" in
-freebsd*)
-   enable_qemu_traditional="no";;
-esac
-
-])
+   [Enable qemu traditional device model, (DEFAULT is off)]))
 AS_IF([test "x$enable_qemu_traditional" = "xye

[PATCH v3 2/3] stubdom: disable building pv-grub

[Juergen Gross]

The stubdom based pv-grub is using a very outdated version of grub
(0.97) and should not be used any longer. Mainline grub has support for
PV guests for a long time now, so that should be used as a boot loader
of a PV domain.

So disable building pv-grub per default. In case someone really wants
to continue using it he/she can still use a pv-grub binary from an older
Xen version or manually enable building it via:

  configure --enable-pv-grub

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
Acked-by: Ian Jackson 
---
V2:
- add CHANGELOG.md entry (Jan Beulich)
---
 CHANGELOG.md | 2 ++
 stubdom/configure| 8 ++--
 stubdom/configure.ac | 2 +-
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 22cfdb4298..e7107ac3de 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,8 @@ The format is based on [Keep a 
Changelog](https://keepachangelog.com/en/1.0.0/)
appearing in 4.12.2 and 4.11.4). Prior (4.13...4.15-like) behavior can be 
arranged for
either by enabling the IOMMU_QUARANTINE_SCRATCH_PAGE setting at build 
(configuration) time
or by passing "iommu=quarantine=scratch-page" on the hypervisor command 
line.
+ - pv-grub stubdoms will no longer be built per default. In order to be able 
to use pv-grub
+   configure needs to be called with "--enable-pv-grub" as parameter.
 
 ## [4.15.0 
UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.15.0)
 - TBD
 
diff --git a/stubdom/configure b/stubdom/configure
index aa48df986d..df31532abb 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -1342,7 +1342,7 @@ Optional Features:
   --enable-ioemu-stubdom  Build and install ioemu-stubdom
   --enable-c-stubdom  Build and install c-stubdom (default is DISABLED)
   --enable-caml-stubdom   Build and install caml-stubdom (default is DISABLED)
-  --disable-pv-grub   Build and install pv-grub (default is ENABLED)
+  --enable-pv-grubBuild and install pv-grub (default is DISABLED)
   --disable-xenstore-stubdom
   Build and install xenstore-stubdom (default is
   ENABLED)
@@ -2129,11 +2129,7 @@ fi
 else
 
 
-grub=y
-STUBDOM_TARGETS="$STUBDOM_TARGETS grub"
-STUBDOM_BUILD="$STUBDOM_BUILD pv-grub"
-STUBDOM_INSTALL="$STUBDOM_INSTALL install-grub"
-STUBDOM_UNINSTALL="$STUBDOM_UNINSTALL install-grub"
+grub=n
 
 
 fi
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index bd6f765929..a07a1edae5 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -21,7 +21,7 @@ m4_include([../m4/fetcher.m4])
 AX_STUBDOM_CONDITIONAL([ioemu-stubdom], [ioemu])
 AX_STUBDOM_DEFAULT_DISABLE([c-stubdom], [c])
 AX_STUBDOM_DEFAULT_DISABLE([caml-stubdom], [caml])
-AX_STUBDOM_DEFAULT_ENABLE([pv-grub], [grub])
+AX_STUBDOM_DEFAULT_DISABLE([pv-grub], [grub])
 AX_STUBDOM_DEFAULT_ENABLE([xenstore-stubdom], [xenstore])
 AX_STUBDOM_DEFAULT_ENABLE([xenstorepvh-stubdom], [xenstorepvh])
 AX_STUBDOM_CONDITIONAL([vtpm-stubdom], [vtpm])
-- 
2.26.2

[PATCH v3 0/3] disable building of pv-grub and qemu-trad per default

[Juergen Gross]

This is a first step of deprecating pv-grub and qemu-trad including
ioemu-stubdom. Switch the default to not building it.

Changes in V3:
- rename pv-grub32 make target

Changes in V2:
- new patch 3
- added CHANGELOG.md entry in patch 2

Juergen Gross (3):
  stubdom: fix build with disabled pv-grub
  stubdom: disable building pv-grub
  tools: disable building qemu-trad per default

 CHANGELOG.md |  5 +
 Makefile |  4 ++--
 stubdom/Makefile | 13 +
 stubdom/configure| 16 ++--
 stubdom/configure.ac | 10 ++
 tools/configure  | 17 ++---
 tools/configure.ac   | 13 +
 7 files changed, 27 insertions(+), 51 deletions(-)

-- 
2.26.2

[PATCH v3 1/3] stubdom: fix build with disabled pv-grub

[Juergen Gross]

Today the build will fail if --disable-pv-grub as a parameter of
configure, as the main Makefile will unconditionally try to build a
32-bit pv-grub stubdom.

Fix that by introducing a pv-grub-if-enabled target in
stubdom/Makefile taking care of this situation.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
--
V3:
- rename pv-grub32 target (Ian Jackson)
---
 Makefile |  4 ++--
 stubdom/Makefile | 13 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 96d32cfd50..346d73a0dc 100644
--- a/Makefile
+++ b/Makefile
@@ -72,7 +72,7 @@ build-tools-oxenstored: build-tools-public-headers
 build-stubdom: mini-os-dir build-tools-public-headers
$(MAKE) -C stubdom build
 ifeq (x86_64,$(XEN_TARGET_ARCH))
-   XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub
+   XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub-if-enabled
 endif
 
 .PHONY: build-docs
@@ -143,7 +143,7 @@ install-tools: install-tools-public-headers
 install-stubdom: mini-os-dir install-tools
$(MAKE) -C stubdom install
 ifeq (x86_64,$(XEN_TARGET_ARCH))
-   XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
+   XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub-if-enabled
 endif
 
 .PHONY: tools/firmware/seabios-dir-force-update
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 06aa69d8bc..ccfcf5b75f 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -531,6 +531,13 @@ vtpmmgr-stubdom: mini-os-$(XEN_TARGET_ARCH)-vtpmmgr vtpmmgr
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxenguest grub
DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" 
DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" 
$(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< 
APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: pv-grub-if-enabled
+ifneq ($(filter grub,$(STUBDOM_TARGETS)),)
+pv-grub-if-enabled: pv-grub
+else
+pv-grub-if-enabled:
+endif
+
 .PHONY: xenstore-stubdom
 xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxenguest xenstore
DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" 
DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" 
$(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< 
APP_OBJS=$(CURDIR)/xenstore/xenstored.a
@@ -560,6 +567,12 @@ install-grub: pv-grub
$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz 
"$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+ifneq ($(filter grub,$(STUBDOM_TARGETS)),)
+install-grub-if-enabled: install-grub
+else
+install-grub-if-enabled:
+endif
+
 install-c: c-stubdom
 
 install-caml: caml-stubdom
-- 
2.26.2

Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub

[Juergen Gross]

On 09.09.21 18:08, Ian Jackson wrote:

Juergen Gross writes ("Re: [PATCH v2 1/3] stubdom: fix build with disabled 
pv-grub"):

On 09.09.21 15:23, Ian Jackson wrote:

How about "pv-grub-maybe" ?  Or something.


What about "pv-grub-if-enabled"?


Fine by me.


And could that be done when committing, or should I send another round?


Please do send another round (sorry).


NP.

BTW, you probably want to modify OSStest to use configure with:

--enable-pv-grub --enable-qemu-traditional

in order to not let the tests fail (applies to x86 only, of course).


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[ovmf test] 164913: all pass - PUSHED

[osstest service owner]

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

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

Last test of basis   164869  2021-09-07 04:11:11 Z3 days
Testing same since   164913  2021-09-09 13:11:28 Z0 days1 attempts


People who touched revisions under test:
  Sravanthi 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   a7cf2c5664..d248516b3a  d248516b3a190c5cb5d51164b5721ead9d24469a -> 
xen-tested-master

[xen-4.13-testing test] 164898: tolerable FAIL - PUSHED

[osstest service owner]

flight 164898 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164898/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  065fff7af08f7eaf300c9bef86ae3cec8150d3aa
baseline version:
 xen  32d580902b959000d79d51dff03a3560653c4fcb

Last test of basis   163761  2021-07-17 07:57:22 Z   54 days
Failing since164260  2021-08-19 17:07:29 Z   21 days   10 attempts
Testing same since   164898  2021-09-09 05:02:45 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Jane Malalane 
  Juergen Gross 
  Julien Grall 
  Marek Marczykowski-Górecki 
  Stefano Stabellini 

jobs:
 build-amd64-xsm

[PATCH] xen-blkback: Remove needless request_queue NULL pointer check

[Xu Wang]

The request_queue pointer returned from bdev_get_queue() shall
never be NULL, so the null check is unnecessary, just remove it.

Signed-off-by: Xu Wang 
---
 drivers/block/xen-blkback/xenbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 33eba3df4dd9..f05132b9ddbf 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -516,7 +516,7 @@ static int xen_vbd_create(struct xen_blkif *blkif, 
blkif_vdev_t handle,
vbd->type |= VDISK_REMOVABLE;
 
q = bdev_get_queue(bdev);
-   if (q && test_bit(QUEUE_FLAG_WC, &q->queue_flags))
+   if test_bit(QUEUE_FLAG_WC, &q->queue_flags)
vbd->flush_support = true;
 
if (q && blk_queue_secure_erase(q))
-- 
2.17.1

[PATCH v2] xen-blkback: Remove needless request_queue NULL pointer check

[Xu Wang]

The request_queue pointer returned from bdev_get_queue() shall
never be NULL, so the null check is unnecessary, just remove it.

Signed-off-by: Xu Wang 
---
Changes since v2:
- Add missing parenthesis.
- Remove another null pointer check.
---
 drivers/block/xen-blkback/xenbus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 33eba3df4dd9..aac08b4369ac 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -516,10 +516,10 @@ static int xen_vbd_create(struct xen_blkif *blkif, 
blkif_vdev_t handle,
vbd->type |= VDISK_REMOVABLE;
 
q = bdev_get_queue(bdev);
-   if (q && test_bit(QUEUE_FLAG_WC, &q->queue_flags))
+   if (test_bit(QUEUE_FLAG_WC, &q->queue_flags))
vbd->flush_support = true;
 
-   if (q && blk_queue_secure_erase(q))
+   if (blk_queue_secure_erase(q))
vbd->discard_secure = true;
 
vbd->feature_gnt_persistent = feature_persistent;
-- 
2.17.1

Re: [OSSTEST PATCH 4/4] mfi-common: Drop Linux dom0 i386 tests for newer Linux branches

[Juergen Gross]

On 09.09.21 18:47, Ian Jackson wrote:

This makes radical changes to the test ste for the linux-linus and
linux-next branches.

Mostly, tests are dropped but some 64-bit dom0 tests are added to
replace them.

Requested-by: Juergen Gross 
Signed-off-by: Ian Jackson 


Thanks!

Reviewed-by: Juergen Gross 


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Enabling hypervisor agnosticism for VirtIO backends

[AKASHI Takahiro]

Hi Christopher,

On Tue, Sep 07, 2021 at 11:09:34AM -0700, Christopher Clark wrote:
> On Tue, Sep 7, 2021 at 4:55 AM AKASHI Takahiro 
> wrote:
> 
> > Hi,
> >
> > I have not covered all your comments below yet.
> > So just one comment:
> >
> > On Mon, Sep 06, 2021 at 05:57:43PM -0700, Christopher Clark wrote:
> > > On Thu, Sep 2, 2021 at 12:19 AM AKASHI Takahiro <
> > takahiro.aka...@linaro.org>
> > > wrote:
> >
> > (snip)
> >
> > > >It appears that, on FE side, at least three hypervisor calls (and
> > data
> > > >copying) need to be invoked at every request, right?
> > > >
> > >
> > > For a write, counting FE sendv ops:
> > > 1: the write data payload is sent via the "Argo ring for writes"
> > > 2: the descriptor is sent via a sync of the available/descriptor ring
> > >   -- is there a third one that I am missing?
> >
> > In the picture, I can see
> > a) Data transmitted by Argo sendv
> > b) Descriptor written after data sendv
> > c) VirtIO ring sync'd to back-end via separate sendv
> >
> > Oops, (b) is not a hypervisor call, is it?
> >
> 
> That's correct, it is not - the blue arrows in the diagram are not
> hypercalls, they are intended to show data movement or action in the flow
> of performing the operation, and (b) is a data write within the guest's
> address space into the descriptor ring.
> 
> 
> 
> > (But I guess that you will have to have yet another call for notification
> > since there is no config register of QueueNotify?)
> >
> 
> Reasoning about hypercalls necessary for data movement:
> 
> VirtIO transport drivers are responsible for instantiating virtqueues
> (setup_vq) and are able to populate the notify function pointer in the
> virtqueue that they supply. The virtio-argo transport driver can provide a
> suitable notify function implementation that will issue the Argo hypercall
> sendv hypercall(s) for sending data from the guest frontend to the backend.
> By issuing the sendv at the time of the queuenotify, rather than as each
> buffer is added to the virtqueue, the cost of the sendv hypercall can be
> amortized over multiple buffer additions to the virtqueue.
> 
> I also understand that there has been some recent work in the Linaro
> Project Stratos on "Fat Virtqueues", where the data to be transmitted is
> included within an expanded virtqueue, which could further reduce the
> number of hypercalls required, since the data can be transmitted inline
> with the descriptors.
> Reference here:
> https://linaro.atlassian.net/wiki/spaces/STR/pages/25626313982/2021-01-21+Project+Stratos+Sync+Meeting+notes
> https://linaro.atlassian.net/browse/STR-25

Ah, yes. Obviously, "fatvirtqueue" has pros and cons.
One of cons is that it won't be suitable for bigger payload
with limited space in descriptors.

> As a result of the above, I think that a single hypercall could be
> sufficient for communicating data for multiple requests, and that a
> two-hypercall-per-request (worst case) upper bound could also be
> established.

When it comes to the payload or data plane, "fatvirtqueue" as well as
Argo utilizes copying. You dub it "DMA operations".
A similar approach can be also seen in virtio-over-ivshmem, where
a limited amount of memory are shared and FE will allocate some space
in this buffer and copy the payload into there. Those allocation will
be done via dma_ops of virtio_ivshmem driver. BE, on the other hand,
fetches the data from the shared memory by using the "offset" described
in a descriptor.
Shared memory is divided into a couple of different groups;
one for read/write for all, others for one writer with many readers.
(I hope I'm right here :)

Looks close to Argo? What is different is who is responsible for
copying data, the kernel or the hypervisor.
(Yeah, I know that Argo has more crucial aspects like access controls.)

In this sense, ivshmem can also be a candidate for hypervisor-agnostic
framework. Jailhouse doesn't say so explicitly AFAIK.
Jan may have some more to say.

Thanks,
-Takahiro Akashi


> Christopher
> 
> 
> 
> >
> > Thanks,
> > -Takahiro Akashi
> >
> >
> > > Christopher
> > >
> > >
> > > >
> > > > Thanks,
> > > > -Takahiro Akashi
> > > >
> > > >
> > > > > * Here are the design documents for building VirtIO-over-Argo, to
> > > > support a
> > > > >   hypervisor-agnostic frontend VirtIO transport driver using Argo.
> > > > >
> > > > > The Development Plan to build VirtIO virtual device support over Argo
> > > > > transport:
> > > > >
> > > >
> > https://openxt.atlassian.net/wiki/spaces/DC/pages/1696169985/VirtIO-Argo+Development+Phase+1
> > > > >
> > > > > A design for using VirtIO over Argo, describing how VirtIO data
> > > > structures
> > > > > and communication is handled over the Argo transport:
> > > > >
> > https://openxt.atlassian.net/wiki/spaces/DC/pages/1348763698/VirtIO+Argo
> > > > >
> > > > > Diagram (from the above document) showing how VirtIO rings are
> > > > synchronized
> > > > > between domains without using shared memory:
> > > > >
> > > >
> > https:/

[PATCH v7 7/7] xen/arm: introduce allocate_static_memory

[Penny Zheng]

This commit introduces a new function allocate_static_memory to allocate
static memory as guest RAM for domains on Static Allocation.

It uses acquire_domstatic_pages to acquire pre-configured static memory
for the domain, and uses guest_physmap_add_pages to set up the P2M table.
These pre-defined static memory banks shall be mapped to the usual guest
memory addresses (GUEST_RAM0_BASE, GUEST_RAM1_BASE) defined by
xen/include/public/arch-arm.h.

In order to deal with the trouble of count-to-order conversion when page number
is not in a power-of-two, this commit exports p2m_insert_mapping and introduce
a new function guest_physmap_add_pages to cope with adding guest RAM p2m
mapping with nr_pages.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c | 161 +++-
 xen/arch/arm/p2m.c  |   7 +-
 xen/include/asm-arm/p2m.h   |  11 +++
 3 files changed, 173 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 206038d1c0..62ab7d0ead 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -480,6 +480,162 @@ fail:
   (unsigned long)kinfo->unassigned_mem >> 10);
 }
 
+#ifdef CONFIG_STATIC_MEMORY
+static bool __init append_static_memory_to_bank(struct domain *d,
+struct membank *bank,
+mfn_t smfn,
+paddr_t size)
+{
+int res;
+unsigned int nr_pages = PFN_DOWN(size);
+/* Infer next GFN. */
+gfn_t sgfn = gaddr_to_gfn(bank->start + bank->size);
+
+res = guest_physmap_add_pages(d, sgfn, smfn, nr_pages);
+if ( res )
+{
+dprintk(XENLOG_ERR, "Failed to map pages to DOMU: %d", res);
+return false;
+}
+
+bank->size = bank->size + size;
+
+return true;
+}
+
+/* Allocate memory from static memory as RAM for one specific domain d. */
+static void __init allocate_static_memory(struct domain *d,
+  struct kernel_info *kinfo,
+  const struct dt_device_node *node)
+{
+const struct dt_property *prop;
+u32 addr_cells, size_cells, reg_cells;
+unsigned int nr_banks, gbank, bank = 0;
+const uint64_t rambase[] = GUEST_RAM_BANK_BASES;
+const uint64_t ramsize[] = GUEST_RAM_BANK_SIZES;
+const __be32 *cell;
+u64 tot_size = 0;
+paddr_t pbase, psize, gsize;
+mfn_t smfn;
+int res;
+
+prop = dt_find_property(node, "xen,static-mem", NULL);
+if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
+   &addr_cells) )
+{
+printk(XENLOG_ERR
+   "%pd: failed to read \"#xen,static-mem-address-cells\".\n", d);
+goto fail;
+}
+
+if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
+   &size_cells) )
+{
+printk(XENLOG_ERR
+   "%pd: failed to read \"#xen,static-mem-size-cells\".\n", d);
+goto fail;
+}
+reg_cells = addr_cells + size_cells;
+
+/*
+ * The static memory will be mapped in the guest at the usual guest memory
+ * addresses (GUEST_RAM0_BASE, GUEST_RAM1_BASE) defined by
+ * xen/include/public/arch-arm.h.
+ */
+gbank = 0;
+gsize = ramsize[gbank];
+kinfo->mem.bank[gbank].start = rambase[gbank];
+
+cell = (const __be32 *)prop->value;
+nr_banks = (prop->length) / (reg_cells * sizeof (u32));
+
+for ( ; bank < nr_banks; bank++ )
+{
+device_tree_get_reg(&cell, addr_cells, size_cells, &pbase, &psize);
+ASSERT(IS_ALIGNED(pbase, PAGE_SIZE) && IS_ALIGNED(psize, PAGE_SIZE));
+
+smfn = maddr_to_mfn(pbase);
+res = acquire_domstatic_pages(d, smfn, PFN_DOWN(psize), 0);
+if ( res )
+{
+printk(XENLOG_ERR
+   "%pd: failed to acquire static memory: %d.\n", d, res);
+goto fail;
+}
+
+printk(XENLOG_INFO "%pd: STATIC BANK[%u] %#"PRIpaddr"-%#"PRIpaddr"\n",
+   d, bank, pbase, pbase + psize);
+
+while ( 1 )
+{
+/* Map as much as possible the static range to the guest bank */
+if ( !append_static_memory_to_bank(d, &kinfo->mem.bank[gbank], 
smfn,
+   min(psize, gsize)) )
+goto fail;
+
+/*
+ * The current physical bank is fully mapped.
+ * Handle the next physical bank.
+ */
+if ( gsize >= psize )
+{
+gsize = gsize - psize;
+break;
+}
+/*
+ * When current guest bank is not enough to map, exhaust
+ * the current one and seek to the next.
+ * Before seeking to the next, check if we still have available
+ * guest ban

[PATCH v7 5/7] xen: re-define assign_pages and introduce a new function assign_page

[Penny Zheng]

In order to deal with the trouble of count-to-order conversion when page number
is not in a power-of-two, this commit re-define assign_pages for nr pages and
assign_page for original page with a single order.

Backporting confusion could be helped by altering the order of assign_pages
parameters, such that the compiler would point out that adjustments at call
sites are needed.

Signed-off-by: Penny Zheng 
---
 xen/arch/x86/pv/dom0_build.c |  2 +-
 xen/common/grant_table.c |  2 +-
 xen/common/memory.c  |  6 +++---
 xen/common/page_alloc.c  | 23 ++-
 xen/include/xen/mm.h |  6 ++
 5 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index d7f9e04b28..77efd3918c 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -568,7 +568,7 @@ int __init dom0_construct_pv(struct domain *d,
 else
 {
 while ( count-- )
-if ( assign_pages(d, mfn_to_page(_mfn(mfn++)), 0, 0) )
+if ( assign_pages(mfn_to_page(_mfn(mfn++)), 1, d, 0) )
 BUG();
 }
 initrd->mod_end = 0;
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index e80f8d044d..fe1fc11b22 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2358,7 +2358,7 @@ gnttab_transfer(
  * is respected and speculative execution is blocked accordingly
  */
 if ( unlikely(!evaluate_nospec(okay)) ||
-unlikely(assign_pages(e, page, 0, MEMF_no_refcount)) )
+unlikely(assign_pages(page, 1, e, MEMF_no_refcount)) )
 {
 bool drop_dom_ref;
 
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 74babb0bd7..63642278fd 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -728,8 +728,8 @@ static long 
memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
 /* Assign each output page to the domain. */
 for ( j = 0; (page = page_list_remove_head(&out_chunk_list)); ++j )
 {
-if ( assign_pages(d, page, exch.out.extent_order,
-  MEMF_no_refcount) )
+if ( assign_page(page, exch.out.extent_order, d,
+ MEMF_no_refcount) )
 {
 unsigned long dec_count;
 bool_t drop_dom_ref;
@@ -797,7 +797,7 @@ static long 
memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
  * cleared PGC_allocated.
  */
 while ( (page = page_list_remove_head(&in_chunk_list)) )
-if ( assign_pages(d, page, 0, MEMF_no_refcount) )
+if ( assign_pages(page, 1, d, MEMF_no_refcount) )
 {
 BUG_ON(!d->is_dying);
 free_domheap_page(page);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index ba7adc80db..2aa8edac8c 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2259,9 +2259,9 @@ void init_domheap_pages(paddr_t ps, paddr_t pe)
 
 
 int assign_pages(
-struct domain *d,
 struct page_info *pg,
-unsigned int order,
+unsigned long nr,
+struct domain *d,
 unsigned int memflags)
 {
 int rc = 0;
@@ -2281,7 +2281,7 @@ int assign_pages(
 {
 unsigned int extra_pages = 0;
 
-for ( i = 0; i < (1ul << order); i++ )
+for ( i = 0; i < nr; i++ )
 {
 ASSERT(!(pg[i].count_info & ~PGC_extra));
 if ( pg[i].count_info & PGC_extra )
@@ -2290,18 +2290,18 @@ int assign_pages(
 
 ASSERT(!extra_pages ||
((memflags & MEMF_no_refcount) &&
-extra_pages == 1u << order));
+extra_pages == nr));
 }
 #endif
 
 if ( pg[0].count_info & PGC_extra )
 {
-d->extra_pages += 1u << order;
+d->extra_pages += nr;
 memflags &= ~MEMF_no_refcount;
 }
 else if ( !(memflags & MEMF_no_refcount) )
 {
-unsigned int tot_pages = domain_tot_pages(d) + (1 << order);
+unsigned int tot_pages = domain_tot_pages(d) + nr;
 
 if ( unlikely(tot_pages > d->max_pages) )
 {
@@ -2313,10 +2313,10 @@ int assign_pages(
 }
 
 if ( !(memflags & MEMF_no_refcount) &&
- unlikely(domain_adjust_tot_pages(d, 1 << order) == (1 << order)) )
+ unlikely(domain_adjust_tot_pages(d, nr) == nr) )
 get_knownalive_domain(d);
 
-for ( i = 0; i < (1 << order); i++ )
+for ( i = 0; i < nr; i++ )
 {
 ASSERT(page_get_owner(&pg[i]) == NULL);
 page_set_owner(&pg[i], d);
@@ -2331,6 +2331,11 @@ int assign_pages(
 return rc;
 }
 
+int assign_page(struct page_info *pg, unsigned int order, struct domain *d,
+unsigned int memflags)
+{
+return assign_pages(pg, 1UL << order, d, memflags);
+}
 
 struct page_info *alloc_domheap_pages(
 struct domain *d, unsigned int order, unsigned int memflags)
@@ -2373,7 +2378,7 @@ struct page_

[PATCH v7 6/7] xen/arm: introduce acquire_staticmem_pages and acquire_domstatic_pages

[Penny Zheng]

New function acquire_staticmem_pages aims to acquire nr_mfns contiguous pages
of static memory, starting at #smfn. And it is the equivalent of
alloc_heap_pages for static memory.

For each page, it shall check if the page is reserved(PGC_reserved)
and free. It shall also do a set of necessary initialization, which are
mostly the same ones in alloc_heap_pages, like, following the same
cache-coherency policy and turning page status into PGC_state_inuse, etc.

New function acquire_domstatic_pages is the equivalent of alloc_domheap_pages
for static memory, and it is to acquire nr_mfns contiguous pages of
static memory and assign them to one specific domain.

It uses acquire_staticmem_pages to acquire nr_mfns pages of static memory.
Then on success, it will use assign_pages to assign those pages to one
specific domain.

In order to differentiate pages of static memory from those allocated from
heap, this patch introduces a new page flag PGC_reserved, then mark pages of
static memory PGC_reserved when initializing them.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
 xen/common/page_alloc.c  | 118 ++-
 xen/include/asm-arm/mm.h |   3 +
 xen/include/xen/mm.h |   2 +
 3 files changed, 121 insertions(+), 2 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 2aa8edac8c..5eb87b51c8 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -151,6 +151,10 @@
 #define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
 #endif
 
+#ifndef PGC_reserved
+#define PGC_reserved 0
+#endif
+
 /*
  * Comma-separated list of hexadecimal page numbers containing bad bytes.
  * e.g. 'badpage=0x3f45,0x8a321'.
@@ -2283,7 +2287,7 @@ int assign_pages(
 
 for ( i = 0; i < nr; i++ )
 {
-ASSERT(!(pg[i].count_info & ~PGC_extra));
+ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_reserved)));
 if ( pg[i].count_info & PGC_extra )
 extra_pages++;
 }
@@ -2322,7 +2326,8 @@ int assign_pages(
 page_set_owner(&pg[i], d);
 smp_wmb(); /* Domain pointer must be visible before updating refcnt. */
 pg[i].count_info =
-(pg[i].count_info & PGC_extra) | PGC_allocated | 1;
+(pg[i].count_info & (PGC_extra | PGC_reserved)) | PGC_allocated | 
1;
+
 page_list_add_tail(&pg[i], page_to_list(d, &pg[i]));
 }
 
@@ -2626,8 +2631,117 @@ void __init free_staticmem_pages(struct page_info *pg, 
unsigned long nr_mfns,
 /* TODO: asynchronous scrubbing for pages of static memory. */
 scrub_one_page(pg);
 }
+
+/* In case initializing page of static memory, mark it PGC_reserved. */
+pg[i].count_info |= PGC_reserved;
 }
 }
+
+/*
+ * Acquire nr_mfns contiguous reserved pages, starting at #smfn, of
+ * static memory.
+ * This function needs to be reworked if used outside of boot.
+ */
+static struct page_info * __init acquire_staticmem_pages(mfn_t smfn,
+ unsigned long nr_mfns,
+ unsigned int memflags)
+{
+bool need_tlbflush = false;
+uint32_t tlbflush_timestamp = 0;
+unsigned long i;
+struct page_info *pg;
+
+ASSERT(nr_mfns);
+for ( i = 0; i < nr_mfns; i++ )
+if ( !mfn_valid(mfn_add(smfn, i)) )
+return NULL;
+
+pg = mfn_to_page(smfn);
+
+spin_lock(&heap_lock);
+
+for ( i = 0; i < nr_mfns; i++ )
+{
+/* The page should be reserved and not yet allocated. */
+if ( pg[i].count_info != (PGC_state_free | PGC_reserved) )
+{
+printk(XENLOG_ERR
+   "pg[%lu] Static MFN %"PRI_mfn" c=%#lx t=%#x\n",
+   i, mfn_x(smfn) + i,
+   pg[i].count_info, pg[i].tlbflush_timestamp);
+goto out_err;
+}
+
+if ( !(memflags & MEMF_no_tlbflush) )
+accumulate_tlbflush(&need_tlbflush, &pg[i],
+&tlbflush_timestamp);
+
+/*
+ * Preserve flag PGC_reserved and change page state
+ * to PGC_state_inuse.
+ */
+pg[i].count_info = PGC_reserved | PGC_state_inuse;
+/* Initialise fields which have other uses for free pages. */
+pg[i].u.inuse.type_info = 0;
+page_set_owner(&pg[i], NULL);
+}
+
+spin_unlock(&heap_lock);
+
+if ( need_tlbflush )
+filtered_flush_tlb_mask(tlbflush_timestamp);
+
+/*
+ * Ensure cache and RAM are consistent for platforms where the guest
+ * can control its own visibility of/through the cache.
+ */
+for ( i = 0; i < nr_mfns; i++ )
+flush_page_to_ram(mfn_x(smfn) + i, !(memflags & MEMF_no_icache_flush));
+
+return pg;
+
+ out_err:
+while ( i-- )
+pg[i].count_info = PGC_reserved | PGC_state_free;
+
+spin_unlock(&heap_lock);
+
+return NULL;
+}
+
+/*
+ * Acquire nr_

[PATCH v7 4/7] xen/arm: static memory initialization

[Penny Zheng]

This patch introduces static memory initialization, during system boot-up.

The new function init_staticmem_pages is responsible for static memory
initialization.

Helper free_staticmem_pages is the equivalent of free_heap_pages, to free
nr_mfns pages of static memory.

This commit also introduces a new CONFIG_STATIC_MEMORY option to wrap all
static-allocation-related code.

Put asynchronously scrubbing pages of static memory in TODO list.

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/setup.c| 27 +++
 xen/common/Kconfig  | 13 +
 xen/common/page_alloc.c | 21 +
 xen/include/xen/mm.h|  6 ++
 4 files changed, 67 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 63a908e325..5be7f2b0c2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -609,6 +609,29 @@ static void __init init_pdx(void)
 }
 }
 
+/* Static memory initialization */
+static void __init init_staticmem_pages(void)
+{
+#ifdef CONFIG_STATIC_MEMORY
+unsigned int bank;
+
+for ( bank = 0 ; bank < bootinfo.reserved_mem.nr_banks; bank++ )
+{
+if ( bootinfo.reserved_mem.bank[bank].xen_domain )
+{
+mfn_t bank_start = 
_mfn(PFN_UP(bootinfo.reserved_mem.bank[bank].start));
+unsigned long bank_pages = 
PFN_DOWN(bootinfo.reserved_mem.bank[bank].size);
+mfn_t bank_end = mfn_add(bank_start, bank_pages);
+
+if ( mfn_x(bank_end) <= mfn_x(bank_start) )
+return;
+
+free_staticmem_pages(mfn_to_page(bank_start), bank_pages, false);
+}
+}
+#endif
+}
+
 #ifdef CONFIG_ARM_32
 static void __init setup_mm(void)
 {
@@ -736,6 +759,8 @@ static void __init setup_mm(void)
 /* Add xenheap memory that was not already added to the boot allocator. */
 init_xenheap_pages(mfn_to_maddr(xenheap_mfn_start),
mfn_to_maddr(xenheap_mfn_end));
+
+init_staticmem_pages();
 }
 #else /* CONFIG_ARM_64 */
 static void __init setup_mm(void)
@@ -789,6 +814,8 @@ static void __init setup_mm(void)
 
 setup_frametable_mappings(ram_start, ram_end);
 max_page = PFN_DOWN(ram_end);
+
+init_staticmem_pages();
 }
 #endif
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 0ddd18e11a..3558be0dbc 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -67,6 +67,19 @@ config MEM_ACCESS
 config NEEDS_LIBELF
bool
 
+config STATIC_MEMORY
+   bool "Static Allocation Support (UNSUPPORTED)" if UNSUPPORTED
+   depends on ARM
+   help
+ Static Allocation refers to system or sub-system(domains) for
+ which memory areas are pre-defined by configuration using physical
+ address ranges.
+
+ When enabled, memory can be statically allocated to a domain using
+ the property "xen,static-mem" defined in the domain configuration.
+
+ If unsure, say N.
+
 menu "Speculative hardening"
 
 config SPECULATIVE_HARDEN_ARRAY
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index a3ee5eca9e..ba7adc80db 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2604,6 +2604,27 @@ struct domain *get_pg_owner(domid_t domid)
 return pg_owner;
 }
 
+#ifdef CONFIG_STATIC_MEMORY
+/* Equivalent of free_heap_pages to free nr_mfns pages of static memory. */
+void __init free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
+ bool need_scrub)
+{
+mfn_t mfn = page_to_mfn(pg);
+unsigned long i;
+
+for ( i = 0; i < nr_mfns; i++ )
+{
+mark_page_free(&pg[i], mfn_add(mfn, i));
+
+if ( need_scrub )
+{
+/* TODO: asynchronous scrubbing for pages of static memory. */
+scrub_one_page(pg);
+}
+}
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 667f9dac83..8e8fb5a615 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -85,6 +85,12 @@ bool scrub_free_pages(void);
 } while ( false )
 #define FREE_XENHEAP_PAGE(p) FREE_XENHEAP_PAGES(p, 0)
 
+#ifdef CONFIG_STATIC_MEMORY
+/* These functions are for static memory */
+void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
+  bool need_scrub);
+#endif
+
 /* Map machine page range in Xen virtual address space. */
 int map_pages_to_xen(
 unsigned long virt,
-- 
2.25.1

[PATCH v7 3/7] xen: introduce mark_page_free

[Penny Zheng]

This commit defines a new helper mark_page_free to extract common code,
like following the same cache/TLB coherency policy, between free_heap_pages
and the new function free_staticmem_pages, which will be introduced later.

The PDX compression makes that conversion between the MFN and the page can
be potentially non-trivial. As the function is internal, pass the MFN and
the page. They are both expected to match.

Signed-off-by: Penny Zheng 
Acked-by: Jan Beulich 
Reviewed-by: Julien Grall 
---
 xen/common/page_alloc.c | 89 ++---
 1 file changed, 48 insertions(+), 41 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 958ba0cd92..a3ee5eca9e 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1376,6 +1376,53 @@ bool scrub_free_pages(void)
 return node_to_scrub(false) != NUMA_NO_NODE;
 }
 
+static void mark_page_free(struct page_info *pg, mfn_t mfn)
+{
+ASSERT(mfn_x(mfn) == mfn_x(page_to_mfn(pg)));
+
+/*
+ * Cannot assume that count_info == 0, as there are some corner cases
+ * where it isn't the case and yet it isn't a bug:
+ *  1. page_get_owner() is NULL
+ *  2. page_get_owner() is a domain that was never accessible by
+ * its domid (e.g., failed to fully construct the domain).
+ *  3. page was never addressable by the guest (e.g., it's an
+ * auto-translate-physmap guest and the page was never included
+ * in its pseudophysical address space).
+ * In all the above cases there can be no guest mappings of this page.
+ */
+switch ( pg->count_info & PGC_state )
+{
+case PGC_state_inuse:
+BUG_ON(pg->count_info & PGC_broken);
+pg->count_info = PGC_state_free;
+break;
+
+case PGC_state_offlining:
+pg->count_info = (pg->count_info & PGC_broken) |
+ PGC_state_offlined;
+tainted = 1;
+break;
+
+default:
+printk(XENLOG_ERR
+   "pg MFN %"PRI_mfn" c=%#lx o=%u v=%#lx t=%#x\n",
+   mfn_x(mfn),
+   pg->count_info, pg->v.free.order,
+   pg->u.free.val, pg->tlbflush_timestamp);
+BUG();
+}
+
+/* If a page has no owner it will need no safety TLB flush. */
+pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL);
+if ( pg->u.free.need_tlbflush )
+page_set_tlbflush_timestamp(pg);
+
+/* This page is not a guest frame any more. */
+page_set_owner(pg, NULL); /* set_gpfn_from_mfn snoops pg owner */
+set_gpfn_from_mfn(mfn_x(mfn), INVALID_M2P_ENTRY);
+}
+
 /* Free 2^@order set of pages. */
 static void free_heap_pages(
 struct page_info *pg, unsigned int order, bool need_scrub)
@@ -1392,47 +1439,7 @@ static void free_heap_pages(
 
 for ( i = 0; i < (1 << order); i++ )
 {
-/*
- * Cannot assume that count_info == 0, as there are some corner cases
- * where it isn't the case and yet it isn't a bug:
- *  1. page_get_owner() is NULL
- *  2. page_get_owner() is a domain that was never accessible by
- * its domid (e.g., failed to fully construct the domain).
- *  3. page was never addressable by the guest (e.g., it's an
- * auto-translate-physmap guest and the page was never included
- * in its pseudophysical address space).
- * In all the above cases there can be no guest mappings of this page.
- */
-switch ( pg[i].count_info & PGC_state )
-{
-case PGC_state_inuse:
-BUG_ON(pg[i].count_info & PGC_broken);
-pg[i].count_info = PGC_state_free;
-break;
-
-case PGC_state_offlining:
-pg[i].count_info = (pg[i].count_info & PGC_broken) |
-   PGC_state_offlined;
-tainted = 1;
-break;
-
-default:
-printk(XENLOG_ERR
-   "pg[%u] MFN %"PRI_mfn" c=%#lx o=%u v=%#lx t=%#x\n",
-   i, mfn_x(mfn) + i,
-   pg[i].count_info, pg[i].v.free.order,
-   pg[i].u.free.val, pg[i].tlbflush_timestamp);
-BUG();
-}
-
-/* If a page has no owner it will need no safety TLB flush. */
-pg[i].u.free.need_tlbflush = (page_get_owner(&pg[i]) != NULL);
-if ( pg[i].u.free.need_tlbflush )
-page_set_tlbflush_timestamp(&pg[i]);
-
-/* This page is not a guest frame any more. */
-page_set_owner(&pg[i], NULL); /* set_gpfn_from_mfn snoops pg owner */
-set_gpfn_from_mfn(mfn_x(mfn) + i, INVALID_M2P_ENTRY);
+mark_page_free(&pg[i], mfn_add(mfn, i));
 
 if ( need_scrub )
 {
-- 
2.25.1

[PATCH v7 2/7] xen/arm: introduce domain on Static Allocation

[Penny Zheng]

Static Allocation refers to system or sub-system(domains) for which memory
areas are pre-defined by configuration using physical address ranges.

Those pre-defined memory, -- Static Memory, as parts of RAM reserved in the
beginning, shall never go to heap allocator or boot allocator for any use.

Memory can be statically allocated to a domain using the property "xen,static-
mem" defined in the domain configuration. The number of cells for the address
and the size must be defined using respectively the properties
"#xen,static-mem-address-cells" and "#xen,static-mem-size-cells".

The property 'memory' is still needed and should match the amount of memory
given to the guest. Currently, it either comes from static memory or lets Xen
allocate from heap. *Mixing* is not supported.

The static memory will be mapped in the guest at the usual guest memory
addresses (GUEST_RAM0_BASE, GUEST_RAM1_BASE) defined by
xen/include/public/arch-arm.h.

This patch introduces this new `xen,static-mem` feature, and also documents
and parses this new attribute at boot time.

This patch also introduces a new field "bool xen_domain" in "struct membank"
to tell whether the memory bank is reserved as the whole hardware resource,
or bind to a xen domain node, through "xen,static-mem"

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
 docs/misc/arm/device-tree/booting.txt | 42 +++
 xen/arch/arm/bootfdt.c| 30 +--
 xen/include/asm-arm/setup.h   |  1 +
 3 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index 5243bc7fd3..44cd9e1a9a 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -268,3 +268,45 @@ The DTB fragment is loaded at 0xc00 in the example 
above. It should
 follow the convention explained in docs/misc/arm/passthrough.txt. The
 DTB fragment will be added to the guest device tree, so that the guest
 kernel will be able to discover the device.
+
+
+Static Allocation
+=
+
+Static Allocation refers to system or sub-system(domains) for which memory
+areas are pre-defined by configuration using physical address ranges.
+
+Memory can be statically allocated to a domain using the property "xen,static-
+mem" defined in the domain configuration. The number of cells for the address
+and the size must be defined using respectively the properties
+"#xen,static-mem-address-cells" and "#xen,static-mem-size-cells".
+
+The property 'memory' is still needed and should match the amount of memory
+given to the guest. Currently, it either comes from static memory or lets Xen
+allocate from heap. *Mixing* is not supported.
+
+The static memory will be mapped in the guest at the usual guest memory
+addresses (GUEST_RAM0_BASE, GUEST_RAM1_BASE) defined by
+xen/include/public/arch-arm.h.
+
+Below is an example on how to specify the static memory region in the
+device-tree:
+
+/ {
+chosen {
+domU1 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x2>;
+cpus = <2>;
+memory = <0x0 0x8>;
+#xen,static-mem-address-cells = <0x1>;
+#xen,static-mem-size-cells = <0x1>;
+xen,static-mem = <0x3000 0x2000>;
+...
+};
+};
+};
+
+This will reserve a 512MB region starting at the host physical address
+0x3000 to be exclusively used by DomU1.
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index b01badda3e..afaa0e249b 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -66,7 +66,7 @@ void __init device_tree_get_reg(const __be32 **cell, u32 
address_cells,
 static int __init device_tree_get_meminfo(const void *fdt, int node,
   const char *prop_name,
   u32 address_cells, u32 size_cells,
-  void *data)
+  void *data, bool xen_domain)
 {
 const struct fdt_property *prop;
 unsigned int i, banks;
@@ -97,6 +97,7 @@ static int __init device_tree_get_meminfo(const void *fdt, 
int node,
 continue;
 mem->bank[mem->nr_banks].start = start;
 mem->bank[mem->nr_banks].size = size;
+mem->bank[mem->nr_banks].xen_domain = xen_domain;
 mem->nr_banks++;
 }
 
@@ -185,7 +186,8 @@ static int __init process_memory_node(const void *fdt, int 
node,
   u32 address_cells, u32 size_cells,
   void *data)
 {
-return device_tree_get_meminfo(fdt, node, "reg", address_cells, 
size_cells, data);
+return device_tree_get_meminfo(fdt, node, "reg", address_cells, size_cells,
+   data, false);
 }
 
 stati

[PATCH v7 1/7] xen/arm: introduce new helper device_tree_get_meminfo

[Penny Zheng]

This commit creates a new helper device_tree_get_meminfo to iterate over a
device tree property to get memory info, like "reg".

Signed-off-by: Penny Zheng 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/bootfdt.c | 83 --
 1 file changed, 47 insertions(+), 36 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 476e32e0f5..b01badda3e 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -63,6 +63,52 @@ void __init device_tree_get_reg(const __be32 **cell, u32 
address_cells,
 *size = dt_next_cell(size_cells, cell);
 }
 
+static int __init device_tree_get_meminfo(const void *fdt, int node,
+  const char *prop_name,
+  u32 address_cells, u32 size_cells,
+  void *data)
+{
+const struct fdt_property *prop;
+unsigned int i, banks;
+const __be32 *cell;
+u32 reg_cells = address_cells + size_cells;
+paddr_t start, size;
+struct meminfo *mem = data;
+
+if ( address_cells < 1 || size_cells < 1 )
+{
+printk("fdt: property `%s': invalid #address-cells or #size-cells",
+   prop_name);
+return -EINVAL;
+}
+
+prop = fdt_get_property(fdt, node, prop_name, NULL);
+if ( !prop )
+return -ENOENT;
+
+cell = (const __be32 *)prop->data;
+banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
+
+for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ )
+{
+device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
+/* Some DT may describe empty bank, ignore them */
+if ( !size )
+continue;
+mem->bank[mem->nr_banks].start = start;
+mem->bank[mem->nr_banks].size = size;
+mem->nr_banks++;
+}
+
+if ( i < banks )
+{
+printk("Warning: Max number of supported memory regions reached.\n");
+return -ENOSPC;
+}
+
+return 0;
+}
+
 u32 __init device_tree_get_u32(const void *fdt, int node,
const char *prop_name, u32 dflt)
 {
@@ -139,42 +185,7 @@ static int __init process_memory_node(const void *fdt, int 
node,
   u32 address_cells, u32 size_cells,
   void *data)
 {
-const struct fdt_property *prop;
-int i;
-int banks;
-const __be32 *cell;
-paddr_t start, size;
-u32 reg_cells = address_cells + size_cells;
-struct meminfo *mem = data;
-
-if ( address_cells < 1 || size_cells < 1 )
-{
-printk("fdt: node `%s': invalid #address-cells or #size-cells",
-   name);
-return -EINVAL;
-}
-
-prop = fdt_get_property(fdt, node, "reg", NULL);
-if ( !prop )
-return -ENOENT;
-
-cell = (const __be32 *)prop->data;
-banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
-
-for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ )
-{
-device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
-/* Some DT may describe empty bank, ignore them */
-if ( !size )
-continue;
-mem->bank[mem->nr_banks].start = start;
-mem->bank[mem->nr_banks].size = size;
-mem->nr_banks++;
-}
-
-if ( i < banks )
-return -ENOSPC;
-return 0;
+return device_tree_get_meminfo(fdt, node, "reg", address_cells, 
size_cells, data);
 }
 
 static int __init process_reserved_memory_node(const void *fdt, int node,
-- 
2.25.1

[PATCH v7 0/7] Domain on Static Allocation

[Penny Zheng]

Static Allocation refers to system or sub-system(domains) for which memory
areas are pre-defined by configuration using physical address ranges.

Those pre-defined memory, -- Static Memory, as parts of RAM reserved in the
beginning, shall never go to heap allocator or boot allocator for any use.

Memory can be statically allocated to a domain using the property "xen,static-
mem" defined in the domain configuration. The number of cells for the address
and the size must be defined using respectively the properties
"#xen,static-mem-address-cells" and "#xen,static-mem-size-cells".

The property 'memory' is still needed and should match the amount of memory
given to the guest. Currently, it either comes from static memory or lets Xen
allocate from heap. *Mixing* is not supported.

The static memory will be mapped in the guest at the usual guest memory
addresses (GUEST_RAM0_BASE, GUEST_RAM1_BASE) defined by
xen/include/public/arch-arm.h.

This Patch Serie only talks about Domain on Static Allocation.

Looking into related [design link](
https://lists.xenproject.org/archives/html/xen-devel/2021-05/msg00882.html)
for more details.

The whole design is about Static Allocation and 1:1 direct-map, and this
Patch Serie only covers parts of it, which are Domain on Static Allocation.
Other features will be delievered through different patch series.
---
changes in v2:
 - consider reserved-memory binding and use phandle to refer(still in
discussion)
 - remove unused reserved field in struct page_info, unused helper
page_get_reserved_owner and page_set_reserved_owner
 - introduce CONFIG_STATIC_ALLOCATION to avoid bringing dead codes in
other archs.
 - extract common code from free_heap_pages and free_staticmem_pages
 - introduce new interface assign_pages_nr
 - change pfn-named to mfn-named
 - remove meaningless MEMF_no_owner case
 - leave zone concept out of DMA limitation check
 - take care of concurrency issue on static memory allocation
 - ensure the consistency when `xen,static-mem` and `memory` are both defined
 - fix the scalability issue in allocate_static_memory
 - allocate static memory when parse
---
changes in v3:
- use "xen,static-mem" property to be compatible with System Sevice Tree
in the future
- introduce new helper device_tree_get_meminfo
- extract common codes for dealing with reserved memory stored in
bootinfo
- rename from "free_page" to "mark_page_free"
- remove non-trivial page_to_mfn conversion in "mark_page_free" due to
pdx compression, and let the MFN passed in
- let all switch-cases shared in "mark_page_free"
- change CONFIG_STATIC_ALLOCATION to CONFIG_STATIC_MEMORY
- put init_staticmem_pages in setup_mm
- rename assign_pages_nr to assign_pages
- alter the order of assign_pages parameters to help backporting
- change name from alloc_staticmem_pages/alloc_domstatic_pages to
acquire_staticmem_pages and acquire_domstatic_pages.
- remove hunks' #ifdef-ary by introducing PGC_reserved = 0
- remove DMA restriction
- "memory" property shall be mandatory
- rename allocate_static_bank_memory to append_static_memory_to_bank
- infer the next GFN from the bank information in append_static_memory_to_bank
- simplify the code of double loop in allocate_static_memory
---
changes in v4:
- move the option CONFIG_STATIC_MEMORY to common code, and with Arm
"select"ing it
- replace round_pg{down,up}() with PFN_DOWN()/PFN_UP()
- in all cases where order-0 pages get passed, prefer using new assign_pages
to pass literal 1
- reconstruct the order of assign_pages parameters
- moving tlb/cache flush outside of the locked region, considering XSA-364
and reducing the amount of work happening with the heap_lock held
- remove MEMF_no_refcount case
- make acquire_staticmem_pages/acquire_domstatic_pages being __init
---
changes in v5:
- check the node using the Xen domain binding whether contains the property
"xen,static-mem", not the property itself
- add "rc = ..." to get the error propagated
- introduce new field "bool xen_domain", then static memory shall be also stored
as reserved memory(bootinfo.reserved_mem), but being bind to one
specific Xen domain node.
- make CONFIG_STATIC_MEMORY user selectable and gated by UNSUPPORTED.
- wrap all static-allocation-related codes with CONFIG_STATIC_MEMORY
even in arm-specific file.
- make bank_start/bank_end type of mfn_t, and rename bank_size to
bank_pages.
- Having both functions assign_pages/assign_page with similar parameter
arrangement
- bundle all the functions for static allocation in a single place
- return an error and revert the changes, when the page is not free
and reserved.
- check the MFN is valid for every page and also add a comment to warn
that this function needs to be reworked if used outside of boot.
- use less of mfn_to_page/page_to_mfn
- use ASSERT_UNREACHABLE() to also check that the two flags are clear
- pass the start MFN first and then the number of pages in both
acquire_staticmem_pages and acquire_domstatic_pages
- make acquire_domstatic_pages() to return an

Re: [Stratos-dev] Enabling hypervisor agnosticism for VirtIO backends

[AKASHI Takahiro]

On Mon, Sep 06, 2021 at 07:41:48PM -0700, Christopher Clark wrote:
> On Sun, Sep 5, 2021 at 7:24 PM AKASHI Takahiro via Stratos-dev <
> stratos-...@op-lists.linaro.org> wrote:
> 
> > Alex,
> >
> > On Fri, Sep 03, 2021 at 10:28:06AM +0100, Alex Benn??e wrote:
> > >
> > > AKASHI Takahiro  writes:
> > >
> > > > Alex,
> > > >
> > > > On Wed, Sep 01, 2021 at 01:53:34PM +0100, Alex Benn??e wrote:
> > > >>
> > > >> Stefan Hajnoczi  writes:
> > > >>
> > > >> > [[PGP Signed Part:Undecided]]
> > > >> > On Wed, Aug 04, 2021 at 12:20:01PM -0700, Stefano Stabellini wrote:
> > > >> >> > Could we consider the kernel internally converting IOREQ
> > messages from
> > > >> >> > the Xen hypervisor to eventfd events? Would this scale with
> > other kernel
> > > >> >> > hypercall interfaces?
> > > >> >> >
> > > >> >> > So any thoughts on what directions are worth experimenting with?
> > > >> >>
> > > >> >> One option we should consider is for each backend to connect to
> > Xen via
> > > >> >> the IOREQ interface. We could generalize the IOREQ interface and
> > make it
> > > >> >> hypervisor agnostic. The interface is really trivial and easy to
> > add.
> > > >> >> The only Xen-specific part is the notification mechanism, which is
> > an
> > > >> >> event channel. If we replaced the event channel with something
> > else the
> > > >> >> interface would be generic. See:
> > > >> >>
> > https://gitlab.com/xen-project/xen/-/blob/staging/xen/include/public/hvm/ioreq.h#L52
> > > >> >
> > > >> > There have been experiments with something kind of similar in KVM
> > > >> > recently (see struct ioregionfd_cmd):
> > > >> >
> > https://lore.kernel.org/kvm/dad3d025bcf15ece11d9df0ff685e8ab0a4f2edd.1613828727.git.eafanas...@gmail.com/
> > > >>
> > > >> Reading the cover letter was very useful in showing how this provides
> > a
> > > >> separate channel for signalling IO events to userspace instead of
> > using
> > > >> the normal type-2 vmexit type event. I wonder how deeply tied the
> > > >> userspace facing side of this is to KVM? Could it provide a common FD
> > > >> type interface to IOREQ?
> > > >
> > > > Why do you stick to a "FD" type interface?
> > >
> > > I mean most user space interfaces on POSIX start with a file descriptor
> > > and the usual read/write semantics or a series of ioctls.
> >
> > Who do you assume is responsible for implementing this kind of
> > fd semantics, OSs on BE or hypervisor itself?
> >
> > I think such interfaces can only be easily implemented on type-2
> > hypervisors.
> >
> > # In this sense, I don't think rust-vmm, as it is, cannot be
> > # a general solution.
> >
> > > >> As I understand IOREQ this is currently a direct communication between
> > > >> userspace and the hypervisor using the existing Xen message bus. My
> > > >
> > > > With IOREQ server, IO event occurrences are notified to BE via Xen's
> > event
> > > > channel, while the actual contexts of IO events (see struct ioreq in
> > ioreq.h)
> > > > are put in a queue on a single shared memory page which is to be
> > assigned
> > > > beforehand with xenforeignmemory_map_resource hypervisor call.
> > >
> > > If we abstracted the IOREQ via the kernel interface you would probably
> > > just want to put the ioreq structure on a queue rather than expose the
> > > shared page to userspace.
> >
> > Where is that queue?
> >
> > > >> worry would be that by adding knowledge of what the underlying
> > > >> hypervisor is we'd end up with excess complexity in the kernel. For
> > one
> > > >> thing we certainly wouldn't want an API version dependency on the
> > kernel
> > > >> to understand which version of the Xen hypervisor it was running on.
> > > >
> > > > That's exactly what virtio-proxy in my proposal[1] does; All the
> > hypervisor-
> > > > specific details of IO event handlings are contained in virtio-proxy
> > > > and virtio BE will communicate with virtio-proxy through a virtqueue
> > > > (yes, virtio-proxy is seen as yet another virtio device on BE) and will
> > > > get IO event-related *RPC* callbacks, either MMIO read or write, from
> > > > virtio-proxy.
> > > >
> > > > See page 8 (protocol flow) and 10 (interfaces) in [1].
> > >
> > > There are two areas of concern with the proxy approach at the moment.
> > > The first is how the bootstrap of the virtio-proxy channel happens and
> >
> > As I said, from BE point of view, virtio-proxy would be seen
> > as yet another virtio device by which BE could talk to "virtio
> > proxy" vm or whatever else.
> >
> > This way we guarantee BE's hypervisor-agnosticism instead of having
> > "common" hypervisor interfaces. That is the base of my idea.
> >
> > > the second is how many context switches are involved in a transaction.
> > > Of course with all things there is a trade off. Things involving the
> > > very tightest latency would probably opt for a bare metal backend which
> > > I think would imply hypervisor knowledge in the backend binary.
> >
> > In configuration phase of virtio device, the latency won't b

Re: [PATCH] xen-blkback: Remove needless request_queue NULL pointer check

[Damien Le Moal]

On 2021/09/10 11:32, Xu Wang wrote:
> The request_queue pointer returned from bdev_get_queue() shall
> never be NULL, so the null check is unnecessary, just remove it.
> 
> Signed-off-by: Xu Wang 
> ---
>  drivers/block/xen-blkback/xenbus.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/block/xen-blkback/xenbus.c 
> b/drivers/block/xen-blkback/xenbus.c
> index 33eba3df4dd9..f05132b9ddbf 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -516,7 +516,7 @@ static int xen_vbd_create(struct xen_blkif *blkif, 
> blkif_vdev_t handle,
>   vbd->type |= VDISK_REMOVABLE;
>  
>   q = bdev_get_queue(bdev);
> - if (q && test_bit(QUEUE_FLAG_WC, &q->queue_flags))
> + if test_bit(QUEUE_FLAG_WC, &q->queue_flags)

Missing parenthesis. Did you even compile this ?


>   vbd->flush_support = true;
>  
>   if (q && blk_queue_secure_erase(q))

And why not change this one too ?

> 


-- 
Damien Le Moal
Western Digital Research

[xen-4.12-testing test] 164896: regressions - FAIL

[osstest service owner]

flight 164896 xen-4.12-testing real [real]
flight 164928 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164896/
http://logs.test-lab.xenproject.org/osstest/logs/164928/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow218 guest-saverestore.2  fail REGR. vs. 164489

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

version targeted for testing:
 xen  47193c78887734c2f95a50125684bf81419f1565
baseline version:
 xen  35ba323378d05509f2e0dc049520e140be183003

Last test of basis   164489  2021-08-25 17:57:16 Z   15 days
Testing same since   164886  2021-09-08 13:06:02 Z1 days2 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64

Re: [PATCH v1 14/14] xen/arm: Add linux,pci-domain property for hwdom if not available.

[Stefano Stabellini]

On Thu, 19 Aug 2021, Rahul Singh wrote:
> If the property is not present in the device tree node for host bridge,
> XEN while creating the dtb for hwdom will create this property and
> assigns the already allocated segment to the host bridge
> so that XEN and linux will have the same segment for the host bridges.
> 
> Signed-off-by: Rahul Singh 
> ---
>  xen/arch/arm/domain_build.c| 18 ++
>  xen/arch/arm/pci/pci-host-common.c | 21 +
>  xen/include/asm-arm/pci.h  |  3 +++
>  3 files changed, 42 insertions(+)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 6c86d52781..e0cf2ff19d 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -581,6 +581,24 @@ static int __init write_properties(struct domain *d, 
> struct kernel_info *kinfo,
>  return res;
>  }
>  
> +#ifdef CONFIG_HAS_PCI
> +if ( dt_device_type_is_equal(node, "pci") )
> +{
> +if ( !dt_find_property(node, "linux,pci-domain", NULL) )
> +{
> +uint16_t segment;
> +
> +res = pci_get_host_bridge_segment(node, &segment);
> +if ( res < 0 )
> +return res;
> +
> +res = fdt_property_cell(kinfo->fdt, "linux,pci-domain", segment);
> +if ( res )
> +return res;
> +}
> +}
> +#endif

If param_pci_enable is false it might be possible that Xen didn't
allocate a segment. In that case, we should just let Linux do whatever
it wants in terms of segment allocation. So I think the code here should
not return error if param_pci_enable is false.
returning an error instead.

Re: [PATCH v1 12/14] arm/libxl: Emulated PCI device tree node in libxl

[Stefano Stabellini]

On Thu, 19 Aug 2021, Rahul Singh wrote:
> libxl will create an emulated PCI device tree node in the device tree to
> enable the guest OS to discover the virtual PCI during guest boot.
> Emulated PCI device tree node will only be created when there is any
> device assigned to guest.
> 
> A new area has been reserved in the arm guest physical map at
> which the VPCI bus is declared in the device tree (reg and ranges
> parameters of the node).
> 
> Signed-off-by: Rahul Singh 
> ---
>  tools/libs/light/libxl_arm.c  | 109 ++
>  tools/libs/light/libxl_types.idl  |   1 +
>  tools/xl/xl_parse.c   |   2 +
>  xen/include/public/arch-arm.h |  11 +++
>  xen/include/public/device_tree_defs.h |   1 +
>  5 files changed, 124 insertions(+)
> 
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index e3140a6e00..a091e97e76 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -269,6 +269,58 @@ static int fdt_property_regs(libxl__gc *gc, void *fdt,
>  return fdt_property(fdt, "reg", regs, sizeof(regs));
>  }
>  
> +static int fdt_property_values(libxl__gc *gc, void *fdt,
> +const char *name, unsigned num_cells, ...)
> +{
> +uint32_t prop[num_cells];
> +be32 *cells = &prop[0];
> +int i;
> +va_list ap;
> +uint32_t arg;
> +
> +va_start(ap, num_cells);
> +for (i = 0 ; i < num_cells; i++) {
> +arg = va_arg(ap, uint32_t);
> +set_cell(&cells, 1, arg);
> +}
> +va_end(ap);
> +
> +return fdt_property(fdt, name, prop, sizeof(prop));
> +}
> +
> +static int fdt_property_vpci_ranges(libxl__gc *gc, void *fdt,
> +unsigned addr_cells,
> +unsigned size_cells,
> +unsigned num_regs, ...)
> +{
> +uint32_t regs[num_regs*((addr_cells*2)+size_cells+1)];
> +be32 *cells = ®s[0];
> +int i;
> +va_list ap;
> +uint64_t arg;
> +
> +va_start(ap, num_regs);
> +for (i = 0 ; i < num_regs; i++) {
> +/* Set the memory bit field */
> +arg = va_arg(ap, uint64_t);
> +set_cell(&cells, 1, arg);

Shouldn't this be uint32_t given that it is 1 cell exactly?


> +/* Set the vpci bus address */
> +arg = addr_cells ? va_arg(ap, uint64_t) : 0;
> +set_cell(&cells, addr_cells , arg);
> +
> +/* Set the cpu bus address where vpci address is mapped */
> +set_cell(&cells, addr_cells, arg);
> +
> +/* Set the vpci size requested */
> +arg = size_cells ? va_arg(ap, uint64_t) : 0;
> +set_cell(&cells, size_cells,arg);
   ^ space


> +}
> +va_end(ap);
> +
> +return fdt_property(fdt, "ranges", regs, sizeof(regs));
> +}
> +
>  static int make_root_properties(libxl__gc *gc,
>  const libxl_version_info *vers,
>  void *fdt)
> @@ -668,6 +720,57 @@ static int make_vpl011_uart_node(libxl__gc *gc, void 
> *fdt,
>  return 0;
>  }
>  
> +static int make_vpci_node(libxl__gc *gc, void *fdt,
> +const struct arch_info *ainfo,
> +struct xc_dom_image *dom)
> +{
> +int res;
> +const uint64_t vpci_ecam_base = GUEST_VPCI_ECAM_BASE;
> +const uint64_t vpci_ecam_size = GUEST_VPCI_ECAM_SIZE;
> +const char *name = GCSPRINTF("pcie@%"PRIx64, vpci_ecam_base);
> +
> +res = fdt_begin_node(fdt, name);
> +if (res) return res;
> +
> +res = fdt_property_compat(gc, fdt, 1, "pci-host-ecam-generic");
> +if (res) return res;
> +
> +res = fdt_property_string(fdt, "device_type", "pci");
> +if (res) return res;
> +
> +res = fdt_property_regs(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
> +GUEST_ROOT_SIZE_CELLS, 1, vpci_ecam_base, vpci_ecam_size);
> +if (res) return res;
> +
> +res = fdt_property_values(gc, fdt, "bus-range", 2, 0,17);
^ space


> +if (res) return res;
> +
> +res = fdt_property_cell(fdt, "#address-cells", 3);
> +if (res) return res;
> +
> +res = fdt_property_cell(fdt, "#size-cells", 2);
> +if (res) return res;
> +
> +res = fdt_property_string(fdt, "status", "okay");
> +if (res) return res;
> +
> +res = fdt_property_vpci_ranges(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
> +GUEST_ROOT_SIZE_CELLS, 2,
> +GUEST_VPCI_ADDR_TYPE_MEM, GUEST_VPCI_MEM_ADDR, GUEST_VPCI_MEM_SIZE,
> +GUEST_VPCI_ADDR_TYPE_PREFETCH_MEM, GUEST_VPCI_PREFETCH_MEM_ADDR,
> +GUEST_VPCI_PREFETCH_MEM_SIZE);
> +if (res) return res;
> +
> +res = fdt_property_values(gc, fdt, "msi-map", 4, 0, GUEST_PHANDLE_ITS,
> +  0, 0x1);
> +if (res) return res;

I agree with Julien that we shouldn't add it now if it is not working.

One question: what about legacy interrupts? If they are supported,
shouldn't we have interrupt

Re: [PATCH v1 11/14] xen/arm: Enable the existing x86 virtual PCI support for ARM.

[Stefano Stabellini]

On Thu, 19 Aug 2021, Rahul Singh wrote:
> The existing VPCI support available for X86 is adapted for Arm.
> When the device is added to XEN via the hyper call
> “PHYSDEVOP_pci_device_add”, VPCI handler for the config space
> access is added to the Xen to emulate the PCI devices config space.

This is done just for device discovery, right?

Although it is currently not implemented (and I am not asking to
implement it now, I am only trying to understand the architecture), it
would be possible to discover all PCI devices just by walking down the
PCI hierarchy by ourselves in Xen (no Dom0 interactions) given that we
have an ECAM driver.

I take that would be the way to implement PCI support for Dom0less?

 
> A MMIO trap handler for the PCI ECAM space is registered in XEN
> so that when guest is trying to access the PCI config space,XEN
> will trap the access and emulate read/write using the VPCI and
> not the real PCI hardware.
>
> Signed-off-by: Rahul Singh 
> ---
>  xen/arch/arm/Makefile |  1 +
>  xen/arch/arm/domain.c |  4 ++
>  xen/arch/arm/vpci.c   | 96 +++
>  xen/arch/arm/vpci.h   | 37 ++
>  xen/drivers/passthrough/pci.c |  7 +++
>  xen/drivers/vpci/Makefile |  3 +-
>  xen/drivers/vpci/header.c |  2 +
>  xen/include/asm-arm/domain.h  |  5 +-
>  xen/include/asm-arm/pci.h |  8 +++
>  xen/include/public/arch-arm.h |  4 ++
>  10 files changed, 165 insertions(+), 2 deletions(-)
>  create mode 100644 xen/arch/arm/vpci.c
>  create mode 100644 xen/arch/arm/vpci.h
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 0e14a5e5c8..7cdce684a4 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -7,6 +7,7 @@ obj-y += platforms/
>  endif
>  obj-$(CONFIG_TEE) += tee/
>  obj-$(CONFIG_HAS_PCI) += pci/
> +obj-$(CONFIG_HAS_VPCI) += vpci.o
>  
>  obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
>  obj-y += bootfdt.init.o
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 19c756ac3d..d99c653626 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -40,6 +40,7 @@
>  #include 
>  
>  #include "vuart.h"
> +#include "vpci.h"
>  
>  DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
>  
> @@ -767,6 +768,9 @@ int arch_domain_create(struct domain *d,
>  if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) )
>  goto fail;
>  
> +if ( (rc = domain_vpci_init(d)) != 0 )
> +goto fail;
> +
>  return 0;
>  
>  fail:
> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
> new file mode 100644
> index 00..da8b1ca13c
> --- /dev/null
> +++ b/xen/arch/arm/vpci.c
> @@ -0,0 +1,96 @@
> +/*
> + * xen/arch/arm/vpci.c
> + * Copyright (c) 2021 Arm Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#include 
> +#include 
> +
> +/* Do some sanity checks. */
> +static bool vpci_mmio_access_allowed(unsigned int reg, unsigned int len)
> +{
> +/* Check access size. */
> +if ( len != 1 && len != 2 && len != 4 && len != 8 )
> +return false;
> +
> +/* Check that access is size aligned. */
> +if ( (reg & (len - 1)) )
> +return false;
> +
> +return true;
> +}
> +
> +static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
> +  register_t *r, void *p)
> +{
> +unsigned int reg;
> +pci_sbdf_t sbdf;
> +uint32_t data = 0;
> +unsigned int size = 1U << info->dabt.size;
> +
> +sbdf.sbdf = (((info->gpa) & 0x0000) >> 12);
> +reg = (((info->gpa) & 0x0ffc) | (info->gpa & 3));
> +
> +if ( !vpci_mmio_access_allowed(reg, size) )
> +return 1;
> +
> +data = vpci_read(sbdf, reg, size);
> +
> +memcpy(r, &data, size);
> +
> +return 1;
> +}
> +
> +static int vpci_mmio_write(struct vcpu *v, mmio_info_t *info,
> +   register_t r, void *p)
> +{
> +unsigned int reg;
> +pci_sbdf_t sbdf;
> +uint32_t data = r;
> +unsigned int size = 1U << info->dabt.size;
> +
> +sbdf.sbdf = (((info->gpa) & 0x0000) >> 12);
> +reg = (((info->gpa) & 0x0ffc) | (info->gpa & 3));
> +
> +if ( !vpci_mmio_access_allowed(reg, size) )
> +return 1;
> +
> +vpci_write(sbdf, reg, size, data);
> +
> +return 1;
> +}
> +
> +static const struct mmio_handler_ops vpci_mmio_handler = {
> +.read  = vpci_mmio_read,
> +.write = vpci_mmio_write,
> +};
> +
> +int domain_vpci_init(struct domain *d)
> +{
> +if ( !has_vpci(d) )
> +return 0;
> 

[PATCH AUTOSEL 4.14 16/19] xen: remove stray preempt_disable() from PV AP startup code

[Sasha Levin]

From: Juergen Gross 

[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]

In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:

BUG: scheduling while atomic: swapper/1/0/0x0002

Signed-off-by: Juergen Gross 
Link: https://lore.kernel.org/r/20210825113158.11716-1-jgr...@suse.com
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 arch/x86/xen/smp_pv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index f779d2a5b04c..44468d6fa188 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -59,7 +59,6 @@ static void cpu_bringup(void)
 
cpu_init();
touch_softlockup_watchdog();
-   preempt_disable();
 
/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
-- 
2.30.2

[PATCH AUTOSEL 4.19 22/25] xen: remove stray preempt_disable() from PV AP startup code

[Sasha Levin]

From: Juergen Gross 

[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]

In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:

BUG: scheduling while atomic: swapper/1/0/0x0002

Signed-off-by: Juergen Gross 
Link: https://lore.kernel.org/r/20210825113158.11716-1-jgr...@suse.com
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 arch/x86/xen/smp_pv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 41fd4c123165..7b6e56703bb9 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -59,7 +59,6 @@ static void cpu_bringup(void)
 
cpu_init();
touch_softlockup_watchdog();
-   preempt_disable();
 
/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
-- 
2.30.2

[PATCH AUTOSEL 5.4 34/37] xen: remove stray preempt_disable() from PV AP startup code

[Sasha Levin]

From: Juergen Gross 

[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]

In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:

BUG: scheduling while atomic: swapper/1/0/0x0002

Signed-off-by: Juergen Gross 
Link: https://lore.kernel.org/r/20210825113158.11716-1-jgr...@suse.com
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 arch/x86/xen/smp_pv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 0cebe5db691d..b87c6403b5bd 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -61,7 +61,6 @@ static void cpu_bringup(void)
cr4_init();
cpu_init();
touch_softlockup_watchdog();
-   preempt_disable();
 
/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
-- 
2.30.2

[PATCH AUTOSEL 5.10 49/53] xen: remove stray preempt_disable() from PV AP startup code

[Sasha Levin]

From: Juergen Gross 

[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]

In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:

BUG: scheduling while atomic: swapper/1/0/0x0002

Signed-off-by: Juergen Gross 
Link: https://lore.kernel.org/r/20210825113158.11716-1-jgr...@suse.com
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 arch/x86/xen/smp_pv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index c2ac319f11a4..96afadf9878e 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -64,7 +64,6 @@ static void cpu_bringup(void)
cr4_init();
cpu_init();
touch_softlockup_watchdog();
-   preempt_disable();
 
/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
-- 
2.30.2

[PATCH AUTOSEL 5.13 76/88] xen: remove stray preempt_disable() from PV AP startup code

[Sasha Levin]

From: Juergen Gross 

[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]

In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:

BUG: scheduling while atomic: swapper/1/0/0x0002

Signed-off-by: Juergen Gross 
Link: https://lore.kernel.org/r/20210825113158.11716-1-jgr...@suse.com
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 arch/x86/xen/smp_pv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index c2ac319f11a4..96afadf9878e 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -64,7 +64,6 @@ static void cpu_bringup(void)
cr4_init();
cpu_init();
touch_softlockup_watchdog();
-   preempt_disable();
 
/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
-- 
2.30.2

[PATCH AUTOSEL 5.14 85/99] xen: remove stray preempt_disable() from PV AP startup code

[Sasha Levin]

From: Juergen Gross 

[ Upstream commit 58e636039b512697554b579c2bb23774061877f5 ]

In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:

BUG: scheduling while atomic: swapper/1/0/0x0002

Signed-off-by: Juergen Gross 
Link: https://lore.kernel.org/r/20210825113158.11716-1-jgr...@suse.com
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 arch/x86/xen/smp_pv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index c2ac319f11a4..96afadf9878e 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -64,7 +64,6 @@ static void cpu_bringup(void)
cr4_init();
cpu_init();
touch_softlockup_watchdog();
-   preempt_disable();
 
/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
-- 
2.30.2

Re: [PATCH v1 09/14] xen/arm: Add cmdline boot option "pci=on"

[Stefano Stabellini]

On Thu, 19 Aug 2021, Rahul Singh wrote:
> Add cmdline boot option "pci=on" to enable/disable the PCI init during
> boot.
> 
> Signed-off-by: Rahul Singh 
> ---
>  xen/arch/arm/pci/pci.c | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/xen/arch/arm/pci/pci.c b/xen/arch/arm/pci/pci.c
> index d1c9cf997d..dc63bbc2a2 100644
> --- a/xen/arch/arm/pci/pci.c
> +++ b/xen/arch/arm/pci/pci.c
> @@ -62,8 +62,38 @@ static void __init acpi_pci_init(void)
>  static inline void __init acpi_pci_init(void) { }
>  #endif
>  
> +static bool __initdata param_pci_enable;
> +
> +static int __init parse_pci_param(const char *arg)
> +{
> +if ( !arg )
> +{
> +param_pci_enable = false;
> +return 0;
> +}
> +
> +switch ( parse_bool(arg, NULL) )
> +{
> +case 0:
> +param_pci_enable = false;
> +return 0;
> +case 1:
> +param_pci_enable = true;
> +return 0;
> +}
> +
> +return -EINVAL;
> +}
> +custom_param("pci", parse_pci_param);

Consider using boolean_param instead. It supports "on".


>  static int __init pci_init(void)
>  {
> +/*
> + * Enable PCI when has been enabled explicitly (pci=on)
> + */
> +if ( !param_pci_enable)
> +return 0;
> +
>  if ( acpi_disabled )
>  dt_pci_init();
>  else
> -- 
> 2.17.1
> 

Re: [PATCH v1 09/14] xen/arm: Add cmdline boot option "pci=on"

[Stefano Stabellini]

On Fri, 20 Aug 2021, Jan Beulich wrote:
> On 20.08.2021 16:34, Julien Grall wrote:
> > On 20/08/2021 13:19, Rahul Singh wrote:
> >>> On 19 Aug 2021, at 1:31 pm, Julien Grall  wrote:
> >>> On 19/08/2021 13:02, Rahul Singh wrote:
>  Add cmdline boot option "pci=on" to enable/disable the PCI init during
>  boot.
> >>>
> >>> I read this as "PCI" will be either disabled/enabled for the platform. 
> >>> Whereas, I think it will be used to decide whether Xen discover PCI and 
> >>> PCI passthrough is supported or not.
> >>
> >> Yes. I will modify the option to "pci-passthrough== "
> >>>
> >>> Can you also clarify why a user would want to select "pci=off"?
> >>
> >> As pci-passthrough support emulate the PCI devices for DOM0 also, I 
> >> thought if someone want to
> >> boot the DOM0 without emulating the PCI device in XEN and wants to have 
> >> direct access to device.
> > 
> > Dom0 will always have direct access to the PCI device. The only 
> > difference is whether the access to the hostbridge and config space will 
> > be trapped by Xen. I expect the both to mainly happen during boot and 
> > therefore the overhead will be limited.
> > 
> >>
> >> I am ok to drop this patch if you feel adding the option is not required 
> >> at all.
> > One of the reason I could see this option to be useful is to figure out 
> > if an issue occurs because of the hostbridge emulation. Yet, I am still 
> > not fully convinced adding an option is worth it.
> > 
> > Jan and others, any opinions?
> 
> Well, if there's a proper fallback, then why not allow using it in
> case of problems?

I think it would be good to have the option, if nothing else for
debugging.

Re: [PATCH v1 08/14] xen:arm: Implement pci access functions

[Stefano Stabellini]

On Thu, 19 Aug 2021, Rahul Singh wrote:
> Implement generic pci access functions to read/write the configuration
> space.
> 
> Signed-off-by: Rahul Singh 
> ---
>  xen/arch/arm/pci/pci-access.c  | 31 +-
>  xen/arch/arm/pci/pci-host-common.c | 19 ++
>  xen/include/asm-arm/pci.h  |  2 ++
>  3 files changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/pci/pci-access.c b/xen/arch/arm/pci/pci-access.c
> index f39f6a3a38..b94de3c3ac 100644
> --- a/xen/arch/arm/pci/pci-access.c
> +++ b/xen/arch/arm/pci/pci-access.c
> @@ -72,12 +72,41 @@ int pci_generic_config_write(struct pci_host_bridge 
> *bridge, uint32_t sbdf,
>  static uint32_t pci_config_read(pci_sbdf_t sbdf, unsigned int reg,
>  unsigned int len)
>  {
> -return ~0U;
> +uint32_t val = GENMASK(0, len * 8);

This seems to be another default error value that it would be better to
define with its own macro


> +struct pci_host_bridge *bridge = pci_find_host_bridge(sbdf.seg, 
> sbdf.bus);
> +
> +if ( unlikely(!bridge) )
> +{
> +printk(XENLOG_ERR "Unable to find bridge for "PRI_pci"\n",
> +sbdf.seg, sbdf.bus, sbdf.dev, sbdf.fn);

You are not actually printing sbdf.seg, sbdf.bus, sbdf.dev, sbdf.fn ?


> +return val;
> +}
> +
> +if ( unlikely(!bridge->ops->read) )
> +return val;
> +
> +bridge->ops->read(bridge, (uint32_t) sbdf.sbdf, reg, len, &val);

Would it make sense to make the interface take a pci_sbdf_t directly
instead of casting to uint32_t and back?


> +return val;
>  }
>  
>  static void pci_config_write(pci_sbdf_t sbdf, unsigned int reg,
>   unsigned int len, uint32_t val)
>  {
> +struct pci_host_bridge *bridge = pci_find_host_bridge(sbdf.seg, 
> sbdf.bus);
> +
> +if ( unlikely(!bridge) )
> +{
> +printk(XENLOG_ERR "Unable to find bridge for "PRI_pci"\n",
> +sbdf.seg, sbdf.bus, sbdf.dev, sbdf.fn);

same here


> +return;
> +}
> +
> +if ( unlikely(!bridge->ops->write) )
> +return;
> +
> +bridge->ops->write(bridge, (uint32_t) sbdf.sbdf, reg, len, val);

same here


>  }
>  
>  /*
> diff --git a/xen/arch/arm/pci/pci-host-common.c 
> b/xen/arch/arm/pci/pci-host-common.c
> index c582527e92..62715b4676 100644
> --- a/xen/arch/arm/pci/pci-host-common.c
> +++ b/xen/arch/arm/pci/pci-host-common.c
> @@ -261,6 +261,25 @@ err_exit:
>  return err;
>  }
>  
> +/*
> + * This function will lookup an hostbridge based on the segment and bus
> + * number.
> + */
> +struct pci_host_bridge *pci_find_host_bridge(uint16_t segment, uint8_t bus)
> +{
> +struct pci_host_bridge *bridge;
> +
> +list_for_each_entry( bridge, &pci_host_bridges, node )
> +{
> +if ( bridge->segment != segment )
> +continue;
> +if ( (bus < bridge->bus_start) || (bus > bridge->bus_end) )
> +continue;
> +return bridge;
> +}
> +
> +return NULL;
> +}
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
> index 22866244d2..756f8637ab 100644
> --- a/xen/include/asm-arm/pci.h
> +++ b/xen/include/asm-arm/pci.h
> @@ -20,6 +20,7 @@
>  #ifdef CONFIG_HAS_PCI
>  
>  #define pci_to_dev(pcidev) (&(pcidev)->arch.dev)
> +#define PRI_pci "%04x:%02x:%02x.%u"
>  
>  /* Arch pci dev struct */
>  struct arch_pci_dev {
> @@ -86,6 +87,7 @@ int pci_generic_config_write(struct pci_host_bridge 
> *bridge, uint32_t sbdf,
>  void __iomem *pci_ecam_map_bus(struct pci_host_bridge *bridge,
> uint32_t sbdf, uint32_t where);
>  
> +struct pci_host_bridge *pci_find_host_bridge(uint16_t segment, uint8_t bus);
>  #else   /*!CONFIG_HAS_PCI*/
>  
>  struct arch_pci_dev { };
> -- 
> 2.17.1
> 

Re: [PATCH v1 07/14] xen/arm: Add support for Xilinx ZynqMP PCI host controller

[Stefano Stabellini]

On Thu, 19 Aug 2021, Rahul Singh wrote:
> From: Oleksandr Andrushchenko 
> 
> Add support for Xilinx ZynqMP PCI host controller to map the PCI config
> space to the XEN memory.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  xen/arch/arm/pci/Makefile  |  1 +
>  xen/arch/arm/pci/pci-host-zynqmp.c | 59 ++
>  2 files changed, 60 insertions(+)
>  create mode 100644 xen/arch/arm/pci/pci-host-zynqmp.c
> 
> diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
> index 6f32fbbe67..1d045ade01 100644
> --- a/xen/arch/arm/pci/Makefile
> +++ b/xen/arch/arm/pci/Makefile
> @@ -3,3 +3,4 @@ obj-y += pci-access.o
>  obj-y += pci-host-generic.o
>  obj-y += pci-host-common.o
>  obj-y += ecam.o
> +obj-y += pci-host-zynqmp.o
> diff --git a/xen/arch/arm/pci/pci-host-zynqmp.c 
> b/xen/arch/arm/pci/pci-host-zynqmp.c
> new file mode 100644
> index 00..fe103e3855
> --- /dev/null
> +++ b/xen/arch/arm/pci/pci-host-zynqmp.c
> @@ -0,0 +1,59 @@
> +/*
> + * Copyright (C) 2020-2021 EPAM Systems
> + *
> + * Based on Linux drivers/pci/controller/pci-host-common.c
> + * Based on Linux drivers/pci/controller/pci-host-generic.c
> + * Based on xen/arch/arm/pci/pci-host-generic.c
> + * Copyright (C) 2014 ARM Limited Will Deacon 

Only one Copyright line per file is enough :-)

But actually all the Copyright lines with a name or a company name are
not really required or useful, as the copyright is noted in full details
in the commit messages (author and signed-off-by lines). I would remove
them all from the new files added by this series.


> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +static const struct dt_device_match gen_pci_dt_match[] = {
> +{ .compatible = "xlnx,nwl-pcie-2.11",
> +  .data =   &pci_generic_ecam_ops },
> +{ },
> +};
> +
> +static int gen_pci_dt_init(struct dt_device_node *dev, const void *data)
> +{
> +const struct dt_device_match *of_id;
> +const struct pci_ecam_ops *ops;
> +
> +of_id = dt_match_node(gen_pci_dt_match, dev->dev.of_node);

This should be superfluous


> +ops = (struct pci_ecam_ops *) of_id->data;
> +
> +printk(XENLOG_INFO "Found PCI host bridge %s compatible:%s \n",
> +dt_node_full_name(dev), of_id->compatible);
> +
> +return pci_host_common_probe(dev, ops, 2);
> +}
> +
> +DT_DEVICE_START(pci_gen, "PCI HOST ZYNQMP", DEVICE_PCI)
> +.dt_match = gen_pci_dt_match,
> +.init = gen_pci_dt_init,
> +DT_DEVICE_END
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */

Re: [PATCH v1 06/14] xen/arm: Add support for PCI ecam operations

[Stefano Stabellini]

On Thu, 19 Aug 2021, Rahul Singh wrote:
> Add support for PCI ecam operations to access the PCI
> configuration space.
> 
> Signed-off-by: Rahul Singh 
> ---
>  xen/arch/arm/pci/Makefile   |  1 +
>  xen/arch/arm/pci/ecam.c | 63 +
>  xen/arch/arm/pci/pci-access.c   | 53 
>  xen/arch/arm/pci/pci-host-common.c  | 13 +-
>  xen/arch/arm/pci/pci-host-generic.c |  8 +++-
>  xen/include/asm-arm/pci.h   | 32 +++
>  6 files changed, 167 insertions(+), 3 deletions(-)
>  create mode 100644 xen/arch/arm/pci/ecam.c
> 
> diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
> index f3d97f859e..6f32fbbe67 100644
> --- a/xen/arch/arm/pci/Makefile
> +++ b/xen/arch/arm/pci/Makefile
> @@ -2,3 +2,4 @@ obj-y += pci.o
>  obj-y += pci-access.o
>  obj-y += pci-host-generic.o
>  obj-y += pci-host-common.o
> +obj-y += ecam.o
> diff --git a/xen/arch/arm/pci/ecam.c b/xen/arch/arm/pci/ecam.c
> new file mode 100644
> index 00..91c691b41f
> --- /dev/null
> +++ b/xen/arch/arm/pci/ecam.c
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright (C) 2021 Arm Ltd.
> + *
> + * Based on Linux drivers/pci/ecam.c
> + * Copyright 2016 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +
> +/*
> + * Function to implement the pci_ops ->map_bus method.
> + */
> +void __iomem *pci_ecam_map_bus(struct pci_host_bridge *bridge,
> +  uint32_t sbdf, uint32_t where)

Code style: alignment


> +{
> +const struct pci_config_window *cfg = bridge->sysdata;
> +unsigned int devfn_shift = cfg->ops->bus_shift - 8;

Is it a guarantee that devfn_shift == bus_shift - 8, or is it just so
for ECAM?


> +void __iomem *base;
> +
> +pci_sbdf_t sbdf_t = (pci_sbdf_t) sbdf ;
> +unsigned int busn = sbdf_t.bus;
> +
> +if ( busn < cfg->busn_start || busn > cfg->busn_end )

Genuine question: should it be busn >= cfg->busn_end ?  I don't know if
the range includes busn_end or not.


> +return NULL;
> +
> +busn -= cfg->busn_start;
> +base = cfg->win + (busn << cfg->ops->bus_shift);
> +
> +return base + (PCI_DEVFN(sbdf_t.dev, sbdf_t.fn) << devfn_shift) + where;
> +}

I understand that the arm32 part is not implemented and not part of this
series, that's fine. However if the plan is that arm32 will dynamically
map each bus individually, then I imagine this function will have an
ioremap in the arm32 version. Which means that we also need an
unmap_bus call in struct pci_ops. I understand that pci_ecam_unmap_bus
would be a NOP today for arm64, but I think it makes sense to have it if
we want the API to be generic.


> +/* ECAM ops */
> +const struct pci_ecam_ops pci_generic_ecam_ops = {
> +.bus_shift  = 20,
> +.pci_ops= {
> +.map_bus= pci_ecam_map_bus,
> +.read   = pci_generic_config_read,
> +.write  = pci_generic_config_write,
> +}
> +};
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/arm/pci/pci-access.c b/xen/arch/arm/pci/pci-access.c
> index b938047c03..f39f6a3a38 100644
> --- a/xen/arch/arm/pci/pci-access.c
> +++ b/xen/arch/arm/pci/pci-access.c
> @@ -15,6 +15,59 @@
>   */
>  
>  #include 
> +#include 
> +
> +int pci_generic_config_read(struct pci_host_bridge *bridge, uint32_t sbdf,
> +uint32_t reg, uint32_t len, uint32_t *value)
> +{
> +void __iomem *addr = bridge->ops->map_bus(bridge, sbdf, reg);
> +if (!addr) {
> +*value = ~0;

Is this a standard error? If so, I think we should define it with a
macro (e.g. INVALID_PADDR).


> +return -ENODEV;
> +}
> +
> +switch (len)
> +{
> +case 1:
> +*value = readb(addr);
> +break;
> +case 2:
> +*value = readw(addr);
> +break;
> +case 4:
> +*value = readl(addr);
> +break;
> +default:
> +BUG();

A BUG here is harsh because it could be potentially guest-triggered. An
ASSERT would be better.


> +}
> +
> +return 0;
> +}
> +
> +int pci_generic_config_write(struct pci_host_bridge *bridge, uint32_t sbdf,
> +uint32_t reg, uint32_t len, uint32_t value)
> +{
> +void __iome

Re: [RFC PATCH 0/3] Add handling of extended regions (safe ranges) on Arm (Was "xen/memory: Introduce a hypercall to provide unallocated space")

[Oleksandr]

Hello all

On 07.09.21 20:09, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

You can find an initial discussion at [1].

The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wasting real RAM pages from
the domain memory for establishing these mappings.

The extended regions are chosen at the domain creation time and
advertised to it via "reg" property under hypervisor node in
the guest device-tree.

The extended regions are calculated differently for direct mapped
Dom0 (with and without IOMMU) and non-direct mapped DomUs.

Please note the following limitations:
- The extended region feature is only supported for 64-bit domain.
- The ACPI case is not covered.

Also please note that we haven't figured out yet how to properly
extend the Xen hypervisor device-tree bindings on Arm (either via new
compatible or via new property). I decided to go with new property
for now, but this can be changed. This uncertainty is the main reason
why this series is marked as RFC.


Sorry, I messed up the device tree binding's purpose here.

New DT property "extended-region" (to inform guest about the presence of 
additional regions in "reg" property) is not really needed. Guest can 
simply infer that from the number of regions
in "reg" property (region 0 - reserved for grant table space, regions 
1...n - extended regions).
Instead, new compatible/property will be needed (but only after this 
patch [1] or alternative goes in) to indicate that "region 0 is safe to 
use". Until this patch is merged it is

not safe to use extended regions for the grant table space.

Thanks to Julien for clarifying these bits.

I am going to remove the advertisement of unneeded "extended-region" 
property in the code and send new version soon.


[1] 
https://lore.kernel.org/xen-devel/1631228688-30347-1-git-send-email-olekst...@gmail.com/





Patch series is also available at [2].

The corresponding Linux changes is not in a good shape now (require
some cleanup and refactoring), I will publish them once put them
in order (I hope, it will be in a few days).

[1] 
https://lore.kernel.org/xen-devel/1627489110-25633-1-git-send-email-olekst...@gmail.com/
[2] https://github.com/otyshchenko1/xen/commits/map_opt_ml2

Oleksandr Tyshchenko (3):
   xen: Introduce "gpaddr_bits" field to XEN_SYSCTL_physinfo
   xen/arm: Add handling of extended regions for Dom0
   toolstack/arm: Add handling of extended regions for DomU

  tools/include/libxl.h|   7 ++
  tools/libs/light/libxl.c |   2 +
  tools/libs/light/libxl_arm.c |  92 +++-
  tools/libs/light/libxl_types.idl |   2 +
  xen/arch/arm/domain_build.c  | 233 ++-
  xen/arch/arm/sysctl.c|   2 +
  xen/arch/x86/sysctl.c|   2 +
  xen/include/public/sysctl.h  |   3 +-
  8 files changed, 338 insertions(+), 5 deletions(-)


--
Regards,

Oleksandr Tyshchenko

[RFC PATCH] xen/gnttab: Store frame GFN in struct page_info on Arm

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Rework Arm implementation to store grant table frame GFN
in struct page_info directly instead of keeping it in
standalone status/shared arrays.

To cover 64-bit/40-bit IPA on Arm64/Arm32 we need the new
field to hold 52-bit/28-bit respectively. In order to not
grow the size of struct page_info reduce the type_info field
which current context won't suffer. Add new frame_gfn field
on top of the freed bits and introduce access macros. Update
existing macros to deal with GFN value according to new
location.

Also update P2M code on Arm to clean said GFN when putting
a reference on the grant table page in p2m_put_l3_page().

This patch is intended to fix the potential issue on Arm
which might happen when remapping grant-table frame.
A guest (or the toolstack) will unmap the grant-table frame
using XENMEM_remove_physmap. This is a generic hypercall,
so on x86, we are relying on the fact the M2P entry will
be cleared on removal. For architecture without the M2P,
the GFN would still be present in the grant frame/status
array. So on the next call to map the page, we will end up to
request the P2M to remove whatever mapping was the given GFN.
This could well be another mapping.

Besides that, this patch simplifies arch code on Arm by
removing arrays and corresponding management code and
as the result gnttab_init_arch/gnttab_destroy_arch helpers
and struct grant_table_arch become useless and can be dropped.

Suggested-by: Julien Grall 
Signed-off-by: Oleksandr Tyshchenko 
---
You can find the related discussions at:
https://lore.kernel.org/xen-devel/93d0df14-2c8a-c2e3-8c51-544121901...@xen.org/
https://lore.kernel.org/xen-devel/1628890077-12545-1-git-send-email-olekst...@gmail.com/

! Please note, there is still unresolved locking question here for which
I failed to find a suitable solution !

According to the internal conversation:
Now the GFN field in the struct page_info is accessed from
gnttab_set_frame_gfn() in the grant table code and from page_set_frame_gfn()
in the P2M code (the former uses the latter).

We need to prevent the concurrent access to this field. But, we cannot grab
the grant lock from the P2M code because we will introduce a lock inversion.
The page_set_frame_gfn() will be called from the P2M code with the p2m lock held
and then acquire the grant table lock. The gnttab_map_frame() will do the 
inverse.
---
 xen/arch/arm/p2m.c| 18 ++---
 xen/common/grant_table.c  |  9 ---
 xen/common/page_alloc.c   |  1 +
 xen/include/asm-arm/grant_table.h | 53 +--
 xen/include/asm-arm/mm.h  | 27 
 xen/include/asm-x86/grant_table.h |  5 
 xen/include/asm-x86/mm.h  |  2 ++
 7 files changed, 56 insertions(+), 59 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index eff9a10..7bef210 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -718,8 +718,10 @@ static int p2m_mem_access_radix_set(struct p2m_domain 
*p2m, gfn_t gfn,
  * TODO: Handle superpages, for now we only take special references for leaf
  * pages (specifically foreign ones, which can't be super mapped today).
  */
-static void p2m_put_l3_page(const lpae_t pte)
+static void p2m_put_l3_page(struct p2m_domain *p2m, const lpae_t pte)
 {
+mfn_t mfn = lpae_get_mfn(pte);
+
 ASSERT(p2m_is_valid(pte));
 
 /*
@@ -731,11 +733,19 @@ static void p2m_put_l3_page(const lpae_t pte)
  */
 if ( p2m_is_foreign(pte.p2m.type) )
 {
-mfn_t mfn = lpae_get_mfn(pte);
-
 ASSERT(mfn_valid(mfn));
 put_page(mfn_to_page(mfn));
 }
+
+#ifdef CONFIG_GRANT_TABLE
+/*
+ * Check whether we deal with grant table page. As the grant table page
+ * is xen_heap page and its entry has known p2m type, detect it and mark
+ * the stored GFN as invalid.
+ */
+if ( p2m_is_ram(pte.p2m.type) && is_xen_heap_mfn(mfn) )
+page_set_frame_gfn(mfn_to_page(mfn), INVALID_GFN);
+#endif
 }
 
 /* Free lpae sub-tree behind an entry */
@@ -768,7 +778,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
 p2m->stats.mappings[level]--;
 /* Nothing to do if the entry is a super-page. */
 if ( level == 3 )
-p2m_put_l3_page(entry);
+p2m_put_l3_page(p2m, entry);
 return;
 }
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index b1930e2..9cc3550 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -93,8 +93,6 @@ struct grant_table {
 
 /* Domain to which this struct grant_table belongs. */
 const struct domain *domain;
-
-struct grant_table_arch arch;
 };
 
 unsigned int __read_mostly opt_max_grant_frames = 64;
@@ -1981,14 +1979,9 @@ int grant_table_init(struct domain *d, int 
max_grant_frames,
 
 grant_write_lock(gt);
 
-ret = gnttab_init_arch(gt);
-if ( ret )
-goto unlock;
-
 /* gnttab_grow_table() allocates a min number of frames, so 

Re: [PATCH v2 3/3] tools: disable building qemu-trad per default

[Samuel Thibault]

Juergen Gross, le jeu. 09 sept. 2021 14:49:24 +0200, a ecrit:
> Using qemu-traditional as device model is deprecated for some time now.
> 
> So change the default for building it to "disable". This will affect
> ioemu-stubdom, too, as there is a direct dependency between the two.
> 
> Today it is possible to use a PVH/HVM Linux-based stubdom as device
> model. Additionally using ioemu-stubdom isn't really helping for
> security, as it requires to run a very old and potentially buggy qemu
> version in a PV domain. This is adding probably more security problems
> than it is removing by using a stubdom.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Samuel Thibault 

> ---
> V2:
> - new patch
> ---
>  CHANGELOG.md |  3 +++
>  stubdom/configure|  8 
>  stubdom/configure.ac |  8 +---
>  tools/configure  | 17 ++---
>  tools/configure.ac   | 13 +
>  5 files changed, 7 insertions(+), 42 deletions(-)
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index e7107ac3de..e5ab49e779 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -18,6 +18,9 @@ The format is based on [Keep a 
> Changelog](https://keepachangelog.com/en/1.0.0/)
> or by passing "iommu=quarantine=scratch-page" on the hypervisor command 
> line.
>   - pv-grub stubdoms will no longer be built per default. In order to be able 
> to use pv-grub
> configure needs to be called with "--enable-pv-grub" as parameter.
> + - qemu-traditional based device models (both, qemu-traditional and 
> ioemu-stubdom) will
> +   no longer be built per default. In order to be able to use those, 
> configure needs to
> +   be called with "--enable-qemu-traditional" as parameter.
>  
>  ## [4.15.0 
> UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.15.0)
>  - TBD
>  
> diff --git a/stubdom/configure b/stubdom/configure
> index df31532abb..07b709f998 100755
> --- a/stubdom/configure
> +++ b/stubdom/configure
> @@ -2286,14 +2286,6 @@ fi
>  # Check whether --enable-qemu-traditional was given.
>  if test "${enable_qemu_traditional+set}" = set; then :
>enableval=$enable_qemu_traditional;
> -else
> -
> -case "$host_cpu" in
> -i[3456]86|x86_64)
> -   enable_qemu_traditional="yes";;
> -*) enable_qemu_traditional="no";;
> -esac
> -
>  fi
>  
>  if test "x$enable_qemu_traditional" = "xyes"; then :
> diff --git a/stubdom/configure.ac b/stubdom/configure.ac
> index a07a1edae5..e20d99edac 100644
> --- a/stubdom/configure.ac
> +++ b/stubdom/configure.ac
> @@ -27,13 +27,7 @@ AX_STUBDOM_DEFAULT_ENABLE([xenstorepvh-stubdom], 
> [xenstorepvh])
>  AX_STUBDOM_CONDITIONAL([vtpm-stubdom], [vtpm])
>  AX_STUBDOM_CONDITIONAL([vtpmmgr-stubdom], [vtpmmgr])
>  
> -AC_ARG_ENABLE([qemu-traditional],,,[
> -case "$host_cpu" in
> -i[[3456]]86|x86_64)
> -   enable_qemu_traditional="yes";;
> -*) enable_qemu_traditional="no";;
> -esac
> -])
> +AC_ARG_ENABLE([qemu-traditional])
>  AS_IF([test "x$enable_qemu_traditional" = "xyes"], [
>  qemu_traditional=y],[
>  qemu_traditional=n
> diff --git a/tools/configure b/tools/configure
> index 33814b24b3..8bf8fe75b8 100755
> --- a/tools/configure
> +++ b/tools/configure
> @@ -1502,8 +1502,8 @@ Optional Features:
>--disable-seabios   Disable SeaBIOS (default is ENABLED)
>--disable-golangDisable Go tools (default is ENABLED)
>--enable-qemu-traditional
> -  Enable qemu traditional device model, (DEFAULT is 
> on
> -  for Linux or NetBSD x86, otherwise off)
> +  Enable qemu traditional device model, (DEFAULT is
> +  off)
>--enable-rombiosEnable ROMBIOS, (DEFAULT is on if qemu-traditional
>is enabled, otherwise off)
>--disable-ipxe  Enable in-tree IPXE, (DEFAULT is on if rombios is
> @@ -4287,19 +4287,6 @@ LINUX_BACKEND_MODULES="`eval echo 
> $LINUX_BACKEND_MODULES`"
>  # Check whether --enable-qemu-traditional was given.
>  if test "${enable_qemu_traditional+set}" = set; then :
>enableval=$enable_qemu_traditional;
> -else
> -
> -case "$host_cpu" in
> -i[3456]86|x86_64)
> -   enable_qemu_traditional="yes";;
> -*) enable_qemu_traditional="no";;
> -esac
> -case "$host_os" in
> -freebsd*)
> -   enable_qemu_traditional="no";;
> -esac
> -
> -
>  fi
>  
>  if test "x$enable_qemu_traditional" = "xyes"; then :
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 6414fcbb44..a713fd34d6 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -120,18 +120,7 @@ AC_SUBST(LINUX_BACKEND_MODULES)
>  
>  AC_ARG_ENABLE([qemu-traditional],
>  AS_HELP_STRING([--enable-qemu-traditional],
> -   [Enable qemu traditional device model, (DEFAULT is on for 
> Linux or NetBSD x86, otherwise off)]),,[
> -case "$host_cpu" in
> -i[[3456]]86|x86_64)
> -   enabl

Re: [PATCH v1 05/14] xen/arm: PCI host bridge discovery within XEN on ARM

[Stefano Stabellini]

On Thu, 19 Aug 2021, Rahul Singh wrote:
> XEN during boot will read the PCI device tree node “reg” property
> and will map the PCI config space to the XEN memory.
> 
> As of now "pci-host-ecam-generic" compatible board is supported.
> 
> "linux,pci-domain" device tree property assigns a fixed PCI domain
> number to a host bridge, otherwise an unstable (across boots) unique
> number will be assigned by Linux.This property has to be in sync with
> XEN to access the PCI devices.
> 
> XEN will read the “linux,pci-domain” property from the device tree node
> and configure the host bridge segment number accordingly. If this
> property is not available XEN will allocate the unique segment number
> to the host bridge.
> 
> dt_get_pci_domain_nr(..) and dt_pci_bus_find_domain_nr(..) are directly
> imported from the Linux source tree.
> 
> Signed-off-by: Rahul Singh 
> ---
>  xen/arch/arm/pci/Makefile   |   2 +
>  xen/arch/arm/pci/pci-host-common.c  | 261 
>  xen/arch/arm/pci/pci-host-generic.c |  55 ++
>  xen/include/asm-arm/pci.h   |  28 +++
>  4 files changed, 346 insertions(+)
>  create mode 100644 xen/arch/arm/pci/pci-host-common.c
>  create mode 100644 xen/arch/arm/pci/pci-host-generic.c
> 
> diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
> index a9ee0b9b44..f3d97f859e 100644
> --- a/xen/arch/arm/pci/Makefile
> +++ b/xen/arch/arm/pci/Makefile
> @@ -1,2 +1,4 @@
>  obj-y += pci.o
>  obj-y += pci-access.o
> +obj-y += pci-host-generic.o
> +obj-y += pci-host-common.o
> diff --git a/xen/arch/arm/pci/pci-host-common.c 
> b/xen/arch/arm/pci/pci-host-common.c
> new file mode 100644
> index 00..9dd9b02271
> --- /dev/null
> +++ b/xen/arch/arm/pci/pci-host-common.c
> @@ -0,0 +1,261 @@
> +/*
> + * Copyright (C) 2021 Arm Ltd.
> + *
> + * Based on Linux drivers/pci/ecam.c
> + * Copyright 2016 Broadcom.
> + *
> + * Based on Linux drivers/pci/controller/pci-host-common.c
> + * Based on Linux drivers/pci/controller/pci-host-generic.c
> + * Copyright (C) 2014 ARM Limited Will Deacon 
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * List for all the pci host bridges.
> + */
> +
> +static LIST_HEAD(pci_host_bridges);
> +
> +static atomic_t domain_nr = ATOMIC_INIT(-1);
> +
> +bool dt_pci_parse_bus_range(struct dt_device_node *dev,
> +struct pci_config_window *cfg)
> +{
> +const __be32 *cells;
> +uint32_t len;
> +
> +cells = dt_get_property(dev, "bus-range", &len);
> +/* bus-range should at least be 2 cells */
> +if ( !cells || (len < (sizeof(*cells) * 2)) )
> +return false;
> +
> +cfg->busn_start = dt_next_cell(1, &cells);
> +cfg->busn_end = dt_next_cell(1, &cells);
> +
> +return true;
> +}
> +
> +static inline void __iomem *pci_remap_cfgspace(paddr_t start, size_t len)
> +{
> +return ioremap_nocache(start, len);
> +}
> +
> +static void pci_ecam_free(struct pci_config_window *cfg)
> +{
> +if ( cfg->win )
> +iounmap(cfg->win);
> +
> +xfree(cfg);
> +}
> +
> +static struct pci_config_window *gen_pci_init(struct dt_device_node *dev,
> +  int ecam_reg_idx)

If it is only called at init time, then the function should be __init


> +{
> +int err;
> +struct pci_config_window *cfg;
> +paddr_t addr, size;
> +
> +cfg = xzalloc(struct pci_config_window);
> +if ( !cfg )
> +return NULL;
> +
> +err = dt_pci_parse_bus_range(dev, cfg);
> +if ( !err ) {
> +cfg->busn_start = 0;
> +cfg->busn_end = 0xff;
> +printk(XENLOG_ERR "%s:No bus range found for pci controller\n",
> +   dt_node_full_name(dev));
> +} else {
> +if ( cfg->busn_end > cfg->busn_start + 0xff )
> +cfg->busn_end = cfg->busn_start + 0xff;

Is this a hard limit in the specification? Or is it a limit in the Xen
implementation?


> +}
> +
> +/* Parse our PCI ecam register address*/
^ space

> +err = dt_device_get_address(dev, ecam_reg_idx, &addr, &size);
> +if ( err )
> +goto err_exit;
> +
> +cfg->phys_addr = addr;
> +cfg->size = size;
> +
> +/*
> + * On 64-bit systems, we do a single ioremap for the whole config space
> + * since we have 

[PATCH v5 10/10] xsm: remove alternate xsm hook interface

[Daniel P. Smith]

Hidden behind macro magic is an alternative xsm hook interface dedicated for
use when the dummy/default policy is the only one built. This alternative
interface increases code complexity and code size in the core security
framework of Xen.  This results in code requiring additional maintanence and
additional risk for securit-relevant bugs.

This patch removes this additional interface, making Xen's security framework
have a single, consistent interface that works in a single and consistent
manner regardless of which XSM policy is in use.

Signed-off-by: Daniel P. Smith 
---
 xen/include/xsm/dummy.h| 819 -
 xen/include/xsm/xsm-core.h |  51 ++-
 xen/include/xsm/xsm.h  | 275 -
 xen/xsm/Makefile   |   2 +-
 xen/xsm/dummy.c|   2 +-
 xen/xsm/dummy.h| 659 +
 xen/xsm/silo.c |   2 +-
 xen/xsm/xsm_core.c |   4 -
 8 files changed, 868 insertions(+), 946 deletions(-)
 delete mode 100644 xen/include/xsm/dummy.h
 create mode 100644 xen/xsm/dummy.h

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
deleted file mode 100644
index 002e0bcc4f..00
--- a/xen/include/xsm/dummy.h
+++ /dev/null
@@ -1,819 +0,0 @@
-/*
- *  Default XSM hooks - IS_PRIV and IS_PRIV_FOR checks
- *
- *  Author: Daniel De Graaf 
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2,
- *  as published by the Free Software Foundation.
- *
- *
- *  Each XSM hook implementing an access check should have its first parameter
- *  preceded by XSM_DEFAULT_ARG (or use XSM_DEFAULT_VOID if it has no
- *  arguments). The first non-declaration statement shold be XSM_ASSERT_ACTION
- *  with the expected type of the hook, which will either define or check the
- *  value of action.
- */
-
-#include 
-#include 
-#include 
-
-/*
- * Cannot use BUILD_BUG_ON here because the expressions we check are not
- * considered constant at compile time. Instead, rely on constant propagation 
to
- * inline out the calls to this invalid function, which will cause linker 
errors
- * if references remain at link time.
- */
-#define LINKER_BUG_ON(x) do { if (x) __xsm_action_mismatch_detected(); } while 
(0)
-
-#if defined(CONFIG_COVERAGE) && defined(__clang__)
-/*
- * LLVM coverage support seems to disable some of the optimizations needed in
- * order for XSM to compile. Since coverage should not be used in production
- * provide an implementation of __xsm_action_mismatch_detected to satisfy the
- * linker.
- */
-static inline void __xsm_action_mismatch_detected(void)
-{
-ASSERT_UNREACHABLE();
-}
-#else
-/* DO NOT implement this function; it is supposed to trigger link errors */
-void __xsm_action_mismatch_detected(void);
-#endif
-
-#ifdef CONFIG_XSM_CONFIGURABLE
-
-/*
- * In CONFIG_XSM_CONFIGURABLE builds, this header file is included from
- * xsm/dummy.c, and contains static (not inline) functions compiled to the
- * dummy XSM module.  There is no xsm_default_t argument available, so the
- * value from the assertion is used to initialize the variable.
- */
-#define XSM_INLINE __maybe_unused
-
-#define XSM_DEFAULT_ARG /* */
-#define XSM_DEFAULT_VOID void
-#define XSM_ASSERT_ACTION(def) xsm_default_t action = def; (void)action
-
-#else /* CONFIG_XSM_CONFIGURABLE */
-
-/*
- * In !CONFIG_XSM_CONFIGURABLE builds, this header file is included from
- * xsm/xsm.h, and contains inline functions for each XSM hook. These functions
- * also perform compile-time checks on the xsm_default_t argument to ensure
- * that the behavior of the dummy XSM module is the same as the behavior with
- * XSM disabled.
- */
-#define XSM_INLINE always_inline
-#define XSM_DEFAULT_ARG xsm_default_t action,
-#define XSM_DEFAULT_VOID xsm_default_t action
-#define XSM_ASSERT_ACTION(def) LINKER_BUG_ON(def != action)
-
-#endif /* CONFIG_XSM_CONFIGURABLE */
-
-static always_inline int xsm_default_action(
-   xsm_default_t action, struct domain *src, struct domain *target)
-{
-switch ( action ) {
-case XSM_HOOK:
-return 0;
-case XSM_TARGET:
-if ( evaluate_nospec(src == target) )
-{
-return 0;
-case XSM_XS_PRIV:
-if ( evaluate_nospec(is_xenstore_domain(src)) )
-return 0;
-}
-/* fall through */
-case XSM_DM_PRIV:
-if ( target && evaluate_nospec(src->target == target) )
-return 0;
-/* fall through */
-case XSM_PRIV:
-if ( is_control_domain(src) )
-return 0;
-return -EPERM;
-default:
-LINKER_BUG_ON(1);
-return -EPERM;
-}
-}
-
-static XSM_INLINE void xsm_security_domaininfo(
-   struct domain *d, struct xen_domctl_getdomaininfo *info)
-{
-return;
-}
-
-static XSM_INLINE int xsm_domain_create(
-   XSM_DEFAULT_ARG struct domain *d, uint32_t ssidref)
-{
-XSM_ASSERT_ACTION(XSM_HOOK);

[PATCH v5 09/10] kconfig: update xsm config to reflect reality

[Daniel P. Smith]

It has been a very long time since XSM Flask was the only XSM module, yet the
concenpt of turning XSM on/off continues to be synonymous with enabling and
disabling XSM Flask. Even when XSM Flask was the only module, turning XSM
on/off did not disable or remove the XSM hooks but simply controlled whether
they were implemented as direct inline functions or dispatch calls.

This commit updates XSM kconfig to ensure that it is clear in the code as well
to the user, via the help messages, that the option is about configuring which
XSM policy module(s) are available and which is the default.

Signed-off-by: Daniel P. Smith 
---
 xen/common/Kconfig | 49 ++
 xen/include/xen/sched.h|  2 +-
 xen/include/xsm/dummy.h| 23 +-
 xen/include/xsm/xsm-core.h |  6 ++---
 xen/include/xsm/xsm.h  |  6 ++---
 xen/xsm/Makefile   |  4 ++--
 xen/xsm/xsm_core.c |  4 ++--
 7 files changed, 46 insertions(+), 48 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index ac5491b1cc..2f85538920 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -200,23 +200,20 @@ config XENOPROF
 
  If unsure, say Y.
 
-config XSM
-   bool "Xen Security Modules support"
+config XSM_CONFIGURABLE
+   bool "Configure Xen Security Modules"
default ARM
-   ---help---
- Enables the security framework known as Xen Security Modules which
- allows administrators fine-grained control over a Xen domain and
- its capabilities by defining permissible interactions between domains,
- the hypervisor itself, and related resources such as memory and
- devices.
+   help
+ Allows for configuring the Xen Security Modules (XSM) policy or 
policies
+ modules that will be availble and which will be the default.
 
  If unsure, say N.
 
 config XSM_FLASK
-   def_bool y
-   prompt "FLux Advanced Security Kernel support"
-   depends on XSM
-   ---help---
+   bool "FLux Advanced Security Kernel support"
+   depends on XSM_CONFIGURABLE
+   select XSM_EVTCHN_LABELING
+   help
  Enables FLASK (FLux Advanced Security Kernel) as the access control
  mechanism used by the XSM framework.  This provides a mandatory access
  control framework by which security enforcement, isolation, and
@@ -226,10 +223,10 @@ config XSM_FLASK
  If unsure, say Y.
 
 config XSM_FLASK_AVC_STATS
-   def_bool y
-   prompt "Maintain statistics on the FLASK access vector cache" if EXPERT
+   bool "Maintain statistics on the FLASK access vector cache" if EXPERT
+   default y
depends on XSM_FLASK
-   ---help---
+   help
  Maintain counters on the access vector cache that can be viewed using
  the FLASK_AVC_CACHESTATS sub-op of the xsm_op hypercall.  Disabling
  this will save a tiny amount of memory and time to update the stats.
@@ -240,7 +237,7 @@ config XSM_FLASK_POLICY
bool "Compile Xen with a built-in FLASK security policy"
default y if "$(XEN_HAS_CHECKPOLICY)" = "y"
depends on XSM_FLASK
-   ---help---
+   help
  This includes a default XSM policy in the hypervisor so that the
  bootloader does not need to load a policy to get sane behavior from an
  XSM-enabled hypervisor.  If this is disabled, a policy must be
@@ -253,10 +250,10 @@ config XSM_FLASK_POLICY
  If unsure, say Y.
 
 config XSM_SILO
-   def_bool y
-   prompt "SILO support"
-   depends on XSM
-   ---help---
+   bool "SILO support"
+   default y if ARM
+   depends on XSM_CONFIGURABLE
+   help
  Enables SILO as the access control mechanism used by the XSM 
framework.
  This is not the default module, add boot parameter xsm=silo to choose
  it. This will deny any unmediated communication channels (grant tables
@@ -265,14 +262,14 @@ config XSM_SILO
  If unsure, say Y.
 
 choice
-   prompt "Default XSM implementation"
-   depends on XSM
+   prompt "Default XSM module"
+   depends on XSM_CONFIGURABLE
default XSM_SILO_DEFAULT if XSM_SILO && ARM
default XSM_FLASK_DEFAULT if XSM_FLASK
default XSM_SILO_DEFAULT if XSM_SILO
default XSM_DUMMY_DEFAULT
config XSM_DUMMY_DEFAULT
-   bool "Match non-XSM behavior"
+   bool "Classic Dom0 behavior"
config XSM_FLASK_DEFAULT
bool "FLux Advanced Security Kernel" if XSM_FLASK
config XSM_SILO_DEFAULT
@@ -282,15 +279,15 @@ endchoice
 config LATE_HWDOM
bool "Dedicated hardware domain"
default n
-   depends on XSM && X86
-   ---help---
+   depends on XSM_FLASK && X86
+   help
  Allows the creation of a dedicated hardware domain distinct from
  domain 0 that manages devices without needing access to other
  privileged fu

[PATCH v5 08/10] xsm: decouple xsm header inclusion selection

[Daniel P. Smith]

Multiple preprocessor defines were used as a mechanism to selective include
parts of the xsm.h header file. This makes it difficult to know which portion
is being included at any one time. This commit works to simplify this by
separating the core structures and functions of XSM into xsm-core.h away from
the wrapper functions which remain in xsm.h and dummy.h.

Signed-off-by: Daniel P. Smith 
---
 xen/include/xsm/dummy.h|   2 +-
 xen/include/xsm/xsm-core.h | 267 +
 xen/include/xsm/xsm.h  | 248 +-
 xen/xsm/dummy.c|   1 -
 xen/xsm/silo.c |   2 +-
 xen/xsm/xsm_core.c |   5 +
 6 files changed, 275 insertions(+), 250 deletions(-)
 create mode 100644 xen/include/xsm/xsm-core.h

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index bfcfee1d9e..641b07e8b1 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -16,7 +16,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 
 /*
diff --git a/xen/include/xsm/xsm-core.h b/xen/include/xsm/xsm-core.h
new file mode 100644
index 00..514c198ee6
--- /dev/null
+++ b/xen/include/xsm/xsm-core.h
@@ -0,0 +1,267 @@
+/*
+ *  This file contains the XSM hook definitions for Xen.
+ *
+ *  This work is based on the LSM implementation in Linux 2.6.13.4.
+ *
+ *  Author:  George Coker, 
+ *
+ *  Contributors: Michael LeMay, 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2,
+ *  as published by the Free Software Foundation.
+ */
+
+#ifndef __XSM_CORE_H__
+#define __XSM_CORE_H__
+
+#include 
+#include 
+
+/* policy magic number */
+typedef uint32_t xsm_magic_t;
+
+#ifdef CONFIG_XSM_FLASK
+#define XSM_MAGIC 0xf97cff8c
+#else
+#define XSM_MAGIC 0x0
+#endif
+
+/*
+ * These annotations are used by callers and in dummy.h to document the
+ * default actions of XSM hooks. They should be compiled out otherwise.
+ */
+enum xsm_default {
+XSM_HOOK, /* Guests can normally access the hypercall */
+XSM_DM_PRIV,  /* Device model can perform on its target domain */
+XSM_TARGET,   /* Can perform on self or your target domain */
+XSM_PRIV, /* Privileged - normally restricted to dom0 */
+XSM_XS_PRIV,  /* Xenstore domain - can do some privileged operations */
+XSM_OTHER /* Something more complex */
+};
+typedef enum xsm_default xsm_default_t;
+
+struct xsm_ops {
+void (*security_domaininfo)(struct domain *d,
+struct xen_domctl_getdomaininfo *info);
+int (*domain_create)(struct domain *d, uint32_t ssidref);
+int (*getdomaininfo)(struct domain *d);
+int (*domctl_scheduler_op)(struct domain *d, int op);
+int (*sysctl_scheduler_op)(int op);
+int (*set_target)(struct domain *d, struct domain *e);
+int (*domctl)(struct domain *d, int cmd);
+int (*sysctl)(int cmd);
+int (*readconsole)(uint32_t clear);
+
+int (*evtchn_unbound)(struct domain *d, struct evtchn *chn, domid_t id2);
+int (*evtchn_interdomain)(struct domain *d1, struct evtchn *chn1,
+  struct domain *d2, struct evtchn *chn2);
+void (*evtchn_close_post)(struct evtchn *chn);
+int (*evtchn_send)(struct domain *d, struct evtchn *chn);
+int (*evtchn_status)(struct domain *d, struct evtchn *chn);
+int (*evtchn_reset)(struct domain *d1, struct domain *d2);
+
+int (*grant_mapref)(struct domain *d1, struct domain *d2, uint32_t flags);
+int (*grant_unmapref)(struct domain *d1, struct domain *d2);
+int (*grant_setup)(struct domain *d1, struct domain *d2);
+int (*grant_transfer)(struct domain *d1, struct domain *d2);
+int (*grant_copy)(struct domain *d1, struct domain *d2);
+int (*grant_query_size)(struct domain *d1, struct domain *d2);
+
+int (*alloc_security_domain)(struct domain *d);
+void (*free_security_domain)(struct domain *d);
+int (*alloc_security_evtchns)(struct evtchn chn[], unsigned int nr);
+void (*free_security_evtchns)(struct evtchn chn[], unsigned int nr);
+char *(*show_security_evtchn)(struct domain *d, const struct evtchn *chn);
+int (*init_hardware_domain)(struct domain *d);
+
+int (*get_pod_target)(struct domain *d);
+int (*set_pod_target)(struct domain *d);
+int (*memory_exchange)(struct domain *d);
+int (*memory_adjust_reservation)(struct domain *d1, struct domain *d2);
+int (*memory_stat_reservation)(struct domain *d1, struct domain *d2);
+int (*memory_pin_page)(struct domain *d1, struct domain *d2,
+   struct page_info *page);
+int (*add_to_physmap)(struct domain *d1, struct domain *d2);
+int (*remove_from_physmap)(struct domain *d1, struct domain *d2);
+int (*map_gmfn_foreign)(struct domain *d, struct domain *t);
+int (*claim_pages)(struct domain *d);
+
+int (*console_io)(struct domain *d, int cmd);
+
+int (*profile)(struct domai

[PATCH v5 07/10] xsm: convert xsm_ops hook calls to alternative call

[Daniel P. Smith]

To reduce retpolines convert all the pointer function calls of the
xsm_ops hooks over to the alternative_call infrastructure.

Signed-off-by: Daniel P. Smith 
Acked-by: Andrew Cooper 
---
 xen/include/xsm/xsm.h | 191 +-
 1 file changed, 96 insertions(+), 95 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1d3a1be69d..80dc7f5373 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -15,6 +15,7 @@
 #ifndef __XSM_H__
 #define __XSM_H__
 
+#include 
 #include 
 #include 
 
@@ -202,315 +203,315 @@ extern struct xsm_ops xsm_ops;
 static inline void xsm_security_domaininfo(
 struct domain *d, struct xen_domctl_getdomaininfo *info)
 {
-xsm_ops.security_domaininfo(d, info);
+alternative_vcall(xsm_ops.security_domaininfo, d, info);
 }
 
 static inline int xsm_domain_create(
 xsm_default_t def, struct domain *d, uint32_t ssidref)
 {
-return xsm_ops.domain_create(d, ssidref);
+return alternative_call(xsm_ops.domain_create, d, ssidref);
 }
 
 static inline int xsm_getdomaininfo(xsm_default_t def, struct domain *d)
 {
-return xsm_ops.getdomaininfo(d);
+return alternative_call(xsm_ops.getdomaininfo, d);
 }
 
 static inline int xsm_domctl_scheduler_op(
 xsm_default_t def, struct domain *d, int cmd)
 {
-return xsm_ops.domctl_scheduler_op(d, cmd);
+return alternative_call(xsm_ops.domctl_scheduler_op, d, cmd);
 }
 
 static inline int xsm_sysctl_scheduler_op(xsm_default_t def, int cmd)
 {
-return xsm_ops.sysctl_scheduler_op(cmd);
+return alternative_call(xsm_ops.sysctl_scheduler_op, cmd);
 }
 
 static inline int xsm_set_target(
 xsm_default_t def, struct domain *d, struct domain *e)
 {
-return xsm_ops.set_target(d, e);
+return alternative_call(xsm_ops.set_target, d, e);
 }
 
 static inline int xsm_domctl(xsm_default_t def, struct domain *d, int cmd)
 {
-return xsm_ops.domctl(d, cmd);
+return alternative_call(xsm_ops.domctl, d, cmd);
 }
 
 static inline int xsm_sysctl(xsm_default_t def, int cmd)
 {
-return xsm_ops.sysctl(cmd);
+return alternative_call(xsm_ops.sysctl, cmd);
 }
 
 static inline int xsm_readconsole(xsm_default_t def, uint32_t clear)
 {
-return xsm_ops.readconsole(clear);
+return alternative_call(xsm_ops.readconsole, clear);
 }
 
 static inline int xsm_evtchn_unbound(
 xsm_default_t def, struct domain *d1, struct evtchn *chn, domid_t id2)
 {
-return xsm_ops.evtchn_unbound(d1, chn, id2);
+return alternative_call(xsm_ops.evtchn_unbound, d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain(
 xsm_default_t def, struct domain *d1, struct evtchn *chan1,
 struct domain *d2, struct evtchn *chan2)
 {
-return xsm_ops.evtchn_interdomain(d1, chan1, d2, chan2);
+return alternative_call(xsm_ops.evtchn_interdomain, d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post(struct evtchn *chn)
 {
-xsm_ops.evtchn_close_post(chn);
+alternative_vcall(xsm_ops.evtchn_close_post, chn);
 }
 
 static inline int xsm_evtchn_send(
 xsm_default_t def, struct domain *d, struct evtchn *chn)
 {
-return xsm_ops.evtchn_send(d, chn);
+return alternative_call(xsm_ops.evtchn_send, d, chn);
 }
 
 static inline int xsm_evtchn_status(
 xsm_default_t def, struct domain *d, struct evtchn *chn)
 {
-return xsm_ops.evtchn_status(d, chn);
+return alternative_call(xsm_ops.evtchn_status, d, chn);
 }
 
 static inline int xsm_evtchn_reset(
 xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops.evtchn_reset(d1, d2);
+return alternative_call(xsm_ops.evtchn_reset, d1, d2);
 }
 
 static inline int xsm_grant_mapref(
 xsm_default_t def, struct domain *d1, struct domain *d2, uint32_t flags)
 {
-return xsm_ops.grant_mapref(d1, d2, flags);
+return alternative_call(xsm_ops.grant_mapref, d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref(
 xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops.grant_unmapref(d1, d2);
+return alternative_call(xsm_ops.grant_unmapref, d1, d2);
 }
 
 static inline int xsm_grant_setup(
 xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops.grant_setup(d1, d2);
+return alternative_call(xsm_ops.grant_setup, d1, d2);
 }
 
 static inline int xsm_grant_transfer(
xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops.grant_transfer(d1, d2);
+return alternative_call(xsm_ops.grant_transfer, d1, d2);
 }
 
 static inline int xsm_grant_copy(
xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops.grant_copy(d1, d2);
+return alternative_call(xsm_ops.grant_copy, d1, d2);
 }
 
 static inline int xsm_grant_query_size(
xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops.grant_query_size(d1, d2);
+return alternative_call(xsm_ops.grant_query_size, d1, d2);
 }
 
 static inline int xsm_all

[PATCH v5 06/10] xsm: refactor xsm_ops handling

[Daniel P. Smith]

This renames the `struct xsm_operations` to the shorter `struct xsm_ops` and
converts the global xsm_ops from being a pointer to an explicit instance. As
part of this conversion, it reworks the XSM modules init function to return
their xsm_ops struct which is copied in to the global xsm_ops instance.

Signed-off-by: Daniel P. Smith 
Acked-by: Andrew Cooper 
---
 xen/include/xsm/xsm.h | 220 +-
 xen/xsm/dummy.c   |   4 +-
 xen/xsm/flask/hooks.c |  12 +--
 xen/xsm/silo.c|   7 +-
 xen/xsm/xsm_core.c|  72 +++---
 5 files changed, 161 insertions(+), 154 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 42b0c188a9..1d3a1be69d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -41,7 +41,7 @@ enum xsm_default {
 };
 typedef enum xsm_default xsm_default_t;
 
-struct xsm_operations {
+struct xsm_ops {
 void (*security_domaininfo)(struct domain *d,
 struct xen_domctl_getdomaininfo *info);
 int (*domain_create)(struct domain *d, uint32_t ssidref);
@@ -195,322 +195,322 @@ struct xsm_operations {
 
 #ifdef CONFIG_XSM
 
-extern struct xsm_operations *xsm_ops;
+extern struct xsm_ops xsm_ops;
 
 #ifndef XSM_NO_WRAPPERS
 
 static inline void xsm_security_domaininfo(
 struct domain *d, struct xen_domctl_getdomaininfo *info)
 {
-xsm_ops->security_domaininfo(d, info);
+xsm_ops.security_domaininfo(d, info);
 }
 
 static inline int xsm_domain_create(
 xsm_default_t def, struct domain *d, uint32_t ssidref)
 {
-return xsm_ops->domain_create(d, ssidref);
+return xsm_ops.domain_create(d, ssidref);
 }
 
 static inline int xsm_getdomaininfo(xsm_default_t def, struct domain *d)
 {
-return xsm_ops->getdomaininfo(d);
+return xsm_ops.getdomaininfo(d);
 }
 
 static inline int xsm_domctl_scheduler_op(
 xsm_default_t def, struct domain *d, int cmd)
 {
-return xsm_ops->domctl_scheduler_op(d, cmd);
+return xsm_ops.domctl_scheduler_op(d, cmd);
 }
 
 static inline int xsm_sysctl_scheduler_op(xsm_default_t def, int cmd)
 {
-return xsm_ops->sysctl_scheduler_op(cmd);
+return xsm_ops.sysctl_scheduler_op(cmd);
 }
 
 static inline int xsm_set_target(
 xsm_default_t def, struct domain *d, struct domain *e)
 {
-return xsm_ops->set_target(d, e);
+return xsm_ops.set_target(d, e);
 }
 
 static inline int xsm_domctl(xsm_default_t def, struct domain *d, int cmd)
 {
-return xsm_ops->domctl(d, cmd);
+return xsm_ops.domctl(d, cmd);
 }
 
 static inline int xsm_sysctl(xsm_default_t def, int cmd)
 {
-return xsm_ops->sysctl(cmd);
+return xsm_ops.sysctl(cmd);
 }
 
 static inline int xsm_readconsole(xsm_default_t def, uint32_t clear)
 {
-return xsm_ops->readconsole(clear);
+return xsm_ops.readconsole(clear);
 }
 
 static inline int xsm_evtchn_unbound(
 xsm_default_t def, struct domain *d1, struct evtchn *chn, domid_t id2)
 {
-return xsm_ops->evtchn_unbound(d1, chn, id2);
+return xsm_ops.evtchn_unbound(d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain(
 xsm_default_t def, struct domain *d1, struct evtchn *chan1,
 struct domain *d2, struct evtchn *chan2)
 {
-return xsm_ops->evtchn_interdomain(d1, chan1, d2, chan2);
+return xsm_ops.evtchn_interdomain(d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post(struct evtchn *chn)
 {
-xsm_ops->evtchn_close_post(chn);
+xsm_ops.evtchn_close_post(chn);
 }
 
 static inline int xsm_evtchn_send(
 xsm_default_t def, struct domain *d, struct evtchn *chn)
 {
-return xsm_ops->evtchn_send(d, chn);
+return xsm_ops.evtchn_send(d, chn);
 }
 
 static inline int xsm_evtchn_status(
 xsm_default_t def, struct domain *d, struct evtchn *chn)
 {
-return xsm_ops->evtchn_status(d, chn);
+return xsm_ops.evtchn_status(d, chn);
 }
 
 static inline int xsm_evtchn_reset(
 xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops->evtchn_reset(d1, d2);
+return xsm_ops.evtchn_reset(d1, d2);
 }
 
 static inline int xsm_grant_mapref(
 xsm_default_t def, struct domain *d1, struct domain *d2, uint32_t flags)
 {
-return xsm_ops->grant_mapref(d1, d2, flags);
+return xsm_ops.grant_mapref(d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref(
 xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops->grant_unmapref(d1, d2);
+return xsm_ops.grant_unmapref(d1, d2);
 }
 
 static inline int xsm_grant_setup(
 xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops->grant_setup(d1, d2);
+return xsm_ops.grant_setup(d1, d2);
 }
 
 static inline int xsm_grant_transfer(
xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops->grant_transfer(d1, d2);
+return xsm_ops.grant_transfer(d1, d2);
 }
 
 static inline int xsm_grant_copy(
xsm_default_t def, struct domain *d1, struct domain *d2)
 {
-return xsm_ops-

[PATCH v5 05/10] xsm: apply coding style

[Daniel P. Smith]

Instead of intermixing coding style changes with code changes as they
are come upon in this patch set, moving all coding style changes
into a single commit. The focus of coding style changes here are,

 - move trailing comments to line above
 - ensuring line length does not exceed 80 chars
 - ensuring proper indentation for 80 char wrapping
 - covert u32 type statements to  uint32_t
 - remove space between closing and opening parens
 - drop extern on function declarations

Signed-off-by: Daniel P. Smith 
---
 xen/include/xsm/dummy.h | 196 ++--
 xen/include/xsm/xsm.h   | 499 ++--
 xen/xsm/xsm_core.c  |   8 +-
 xen/xsm/xsm_policy.c|   7 +-
 4 files changed, 401 insertions(+), 309 deletions(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 214b5408b1..bfcfee1d9e 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -19,7 +19,8 @@
 #include 
 #include 
 
-/* Cannot use BUILD_BUG_ON here because the expressions we check are not
+/*
+ * Cannot use BUILD_BUG_ON here because the expressions we check are not
  * considered constant at compile time. Instead, rely on constant propagation 
to
  * inline out the calls to this invalid function, which will cause linker 
errors
  * if references remain at link time.
@@ -44,7 +45,8 @@ void __xsm_action_mismatch_detected(void);
 
 #ifdef CONFIG_XSM
 
-/* In CONFIG_XSM builds, this header file is included from xsm/dummy.c, and
+/*
+ * In CONFIG_XSM builds, this header file is included from xsm/dummy.c, and
  * contains static (not inline) functions compiled to the dummy XSM module.
  * There is no xsm_default_t argument available, so the value from the 
assertion
  * is used to initialize the variable.
@@ -57,7 +59,8 @@ void __xsm_action_mismatch_detected(void);
 
 #else /* CONFIG_XSM */
 
-/* In !CONFIG_XSM builds, this header file is included from xsm/xsm.h, and
+/*
+ * In !CONFIG_XSM builds, this header file is included from xsm/xsm.h, and
  * contains inline functions for each XSM hook. These functions also perform
  * compile-time checks on the xsm_default_t argument to ensure that the 
behavior
  * of the dummy XSM module is the same as the behavior with XSM disabled.
@@ -70,7 +73,7 @@ void __xsm_action_mismatch_detected(void);
 #endif /* CONFIG_XSM */
 
 static always_inline int xsm_default_action(
-xsm_default_t action, struct domain *src, struct domain *target)
+   xsm_default_t action, struct domain *src, struct domain *target)
 {
 switch ( action ) {
 case XSM_HOOK:
@@ -98,13 +101,14 @@ static always_inline int xsm_default_action(
 }
 }
 
-static XSM_INLINE void xsm_security_domaininfo(struct domain *d,
-struct xen_domctl_getdomaininfo *info)
+static XSM_INLINE void xsm_security_domaininfo(
+   struct domain *d, struct xen_domctl_getdomaininfo *info)
 {
 return;
 }
 
-static XSM_INLINE int xsm_domain_create(XSM_DEFAULT_ARG struct domain *d, u32 
ssidref)
+static XSM_INLINE int xsm_domain_create(
+   XSM_DEFAULT_ARG struct domain *d, uint32_t ssidref)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, current->domain, d);
@@ -116,7 +120,8 @@ static XSM_INLINE int xsm_getdomaininfo(XSM_DEFAULT_ARG 
struct domain *d)
 return xsm_default_action(action, current->domain, d);
 }
 
-static XSM_INLINE int xsm_domctl_scheduler_op(XSM_DEFAULT_ARG struct domain 
*d, int cmd)
+static XSM_INLINE int xsm_domctl_scheduler_op(
+   XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, current->domain, d);
@@ -128,7 +133,8 @@ static XSM_INLINE int 
xsm_sysctl_scheduler_op(XSM_DEFAULT_ARG int cmd)
 return xsm_default_action(action, current->domain, NULL);
 }
 
-static XSM_INLINE int xsm_set_target(XSM_DEFAULT_ARG struct domain *d, struct 
domain *e)
+static XSM_INLINE int xsm_set_target(
+   XSM_DEFAULT_ARG struct domain *d, struct domain *e)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, current->domain, NULL);
@@ -173,38 +179,43 @@ static XSM_INLINE void xsm_free_security_domain(struct 
domain *d)
 return;
 }
 
-static XSM_INLINE int xsm_grant_mapref(XSM_DEFAULT_ARG struct domain *d1, 
struct domain *d2,
-uint32_t flags)
+static XSM_INLINE int xsm_grant_mapref(
+   XSM_DEFAULT_ARG struct domain *d1, struct domain *d2, uint32_t flags)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, d1, d2);
 }
 
-static XSM_INLINE int xsm_grant_unmapref(XSM_DEFAULT_ARG struct domain *d1, 
struct domain *d2)
+static XSM_INLINE int xsm_grant_unmapref(
+   XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
 {
 XSM_ASSERT_ACTION(XSM_HOOK);
 return xsm_default_action(action, d1, d2);
 }
 
-static XSM_INLINE int xsm_grant_setup(XSM_DEFAULT_ARG struct domain *d1, 
struct domain *d2)
+static XSM_INLINE

[PATCH v5 04/10] xsm: drop dubious xsm_op_t type

[Daniel P. Smith]

The type xsm_op_t masks the use of void pointers. This commit drops the
xsm_op_t type and replaces it and all its uses with an explicit void.

Signed-off-by: Daniel P. Smith 
Acked-by: Andrew Cooper 
---
 xen/include/xen/hypercall.h |  4 ++--
 xen/include/xsm/dummy.h |  4 ++--
 xen/include/xsm/xsm.h   | 11 ---
 xen/xsm/flask/flask_op.c|  2 +-
 xen/xsm/flask/hooks.c   |  4 ++--
 xen/xsm/xsm_core.c  |  4 ++--
 6 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index 34b7f1fed6..3771487a30 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -127,7 +127,7 @@ do_kexec_op(
 
 extern long
 do_xsm_op(
-XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_xsm_op);
+XEN_GUEST_HANDLE_PARAM(void) u_xsm_op);
 
 #ifdef CONFIG_ARGO
 extern long do_argo_op(
@@ -198,7 +198,7 @@ compat_set_timer_op(
 s32 hi);
 
 extern int compat_xsm_op(
-XEN_GUEST_HANDLE_PARAM(xsm_op_t) op);
+XEN_GUEST_HANDLE_PARAM(void) op);
 
 extern int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) 
uarg);
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 363c6d7798..214b5408b1 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -442,13 +442,13 @@ static XSM_INLINE int xsm_hypfs_op(XSM_DEFAULT_VOID)
 return xsm_default_action(action, current->domain, NULL);
 }
 
-static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
+static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
 {
 return -ENOSYS;
 }
 
 #ifdef CONFIG_COMPAT
-static XSM_INLINE int xsm_do_compat_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
+static XSM_INLINE int xsm_do_compat_op(XEN_GUEST_HANDLE_PARAM(void) op)
 {
 return -ENOSYS;
 }
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 335ba1b022..16b90be2c5 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -18,9 +18,6 @@
 #include 
 #include 
 
-typedef void xsm_op_t;
-DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
-
 /* policy magic number (defined by XSM_MAGIC) */
 typedef u32 xsm_magic_t;
 
@@ -129,9 +126,9 @@ struct xsm_operations {
 int (*page_offline)(uint32_t cmd);
 int (*hypfs_op)(void);
 
-long (*do_xsm_op) (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op);
+long (*do_xsm_op) (XEN_GUEST_HANDLE_PARAM(void) op);
 #ifdef CONFIG_COMPAT
-int (*do_compat_op) (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op);
+int (*do_compat_op) (XEN_GUEST_HANDLE_PARAM(void) op);
 #endif
 
 int (*hvm_param) (struct domain *d, unsigned long op);
@@ -542,13 +539,13 @@ static inline int xsm_hypfs_op(xsm_default_t def)
 return xsm_ops->hypfs_op();
 }
 
-static inline long xsm_do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
+static inline long xsm_do_xsm_op (XEN_GUEST_HANDLE_PARAM(void) op)
 {
 return xsm_ops->do_xsm_op(op);
 }
 
 #ifdef CONFIG_COMPAT
-static inline int xsm_do_compat_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
+static inline int xsm_do_compat_op (XEN_GUEST_HANDLE_PARAM(void) op)
 {
 return xsm_ops->do_compat_op(op);
 }
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index f41c025391..221ff00fd3 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -607,7 +607,7 @@ static int flask_relabel_domain(struct xen_flask_relabel 
*arg)
 
 #endif /* !COMPAT */
 
-ret_t do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op)
+ret_t do_flask_op(XEN_GUEST_HANDLE_PARAM(void) u_flask_op)
 {
 xen_flask_op_t op;
 int rv;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index f1a1217c98..1465db125a 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1742,8 +1742,8 @@ static int flask_argo_send(const struct domain *d, const 
struct domain *t)
 
 #endif
 
-long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
-int compat_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
+long do_flask_op(XEN_GUEST_HANDLE_PARAM(void) u_flask_op);
+int compat_flask_op(XEN_GUEST_HANDLE_PARAM(void) u_flask_op);
 
 static struct xsm_operations flask_ops = {
 .security_domaininfo = flask_security_domaininfo,
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 5eab21e1b1..ac553f9c0d 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -213,13 +213,13 @@ int __init register_xsm(struct xsm_operations *ops)
 
 #endif
 
-long do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
+long do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
 {
 return xsm_do_xsm_op(op);
 }
 
 #ifdef CONFIG_COMPAT
-int compat_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
+int compat_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
 {
 return xsm_do_compat_op(op);
 }
-- 
2.20.1

[PATCH v5 03/10] xsm: remove remnants of xsm_memtype hook

[Daniel P. Smith]

In c/s fcb8baddf00e the xsm_memtype hook was removed but some remnants were
left behind. This commit cleans up those remnants.

Signed-off-by: Daniel P. Smith 
---
 xen/include/xsm/xsm.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ad3cddbf7d..335ba1b022 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -161,7 +161,6 @@ struct xsm_operations {
 int (*shadow_control) (struct domain *d, uint32_t op);
 int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
 int (*apic) (struct domain *d, int cmd);
-int (*memtype) (uint32_t access);
 int (*machine_memory_map) (void);
 int (*domain_memory_map) (struct domain *d);
 #define XSM_MMU_UPDATE_READ  1
@@ -632,11 +631,6 @@ static inline int xsm_apic (xsm_default_t def, struct 
domain *d, int cmd)
 return xsm_ops->apic(d, cmd);
 }
 
-static inline int xsm_memtype (xsm_default_t def, uint32_t access)
-{
-return xsm_ops->memtype(access);
-}
-
 static inline int xsm_machine_memory_map(xsm_default_t def)
 {
 return xsm_ops->machine_memory_map();
-- 
2.20.1

[PATCH v5 02/10] xsm: remove the ability to disable flask

[Daniel P. Smith]

On Linux when SELinux is put into permissive mode the descretionary access
controls are still in place. Whereas for Xen when the enforcing state of flask
is set to permissive, all operations for all domains would succeed, i.e. it
does not fall back to the default access controls. To provide a means to mimic
a similar but not equivalent behavior, a flask op is present to allow a
one-time switch back to the default access controls, aka the "dummy policy".

While this may be desirable for an OS, Xen is a hypervisor and should not allow
the switching of which security policy framework is being enforced after boot.
This patch removes the flask op to enforce the desired XSM usage model
requiring a reboot of Xen to change the XSM policy module in use.

Signed-off-by: Daniel P. Smith 
Acked-by: Andrew Cooper 
---
 xen/include/public/xsm/flask_op.h |  2 +-
 xen/xsm/flask/flask_op.c  | 30 --
 2 files changed, 1 insertion(+), 31 deletions(-)

diff --git a/xen/include/public/xsm/flask_op.h 
b/xen/include/public/xsm/flask_op.h
index 16af7bc22f..b41dd6dac8 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -188,7 +188,7 @@ struct xen_flask_op {
 #define FLASK_SETBOOL   12
 #define FLASK_COMMITBOOLS   13
 #define FLASK_MLS   14
-#define FLASK_DISABLE   15
+#define FLASK_DISABLE   15 /* No longer implemented */
 #define FLASK_GETAVC_THRESHOLD  16
 #define FLASK_SETAVC_THRESHOLD  17
 #define FLASK_AVC_HASHSTATS 18
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 01e52138a1..f41c025391 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -223,32 +223,6 @@ static int flask_security_sid(struct xen_flask_sid_context 
*arg)
 
 #ifndef COMPAT
 
-static int flask_disable(void)
-{
-static int flask_disabled = 0;
-
-if ( ss_initialized )
-{
-/* Not permitted after initial policy load. */
-return -EINVAL;
-}
-
-if ( flask_disabled )
-{
-/* Only do this once. */
-return -EINVAL;
-}
-
-printk("Flask:  Disabled at runtime.\n");
-
-flask_disabled = 1;
-
-/* Reset xsm_ops to the original module. */
-xsm_ops = &dummy_xsm_ops;
-
-return 0;
-}
-
 static int flask_security_setavc_threshold(struct xen_flask_setavc_threshold 
*arg)
 {
 int rv = 0;
@@ -698,10 +672,6 @@ ret_t do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) 
u_flask_op)
 rv = flask_mls_enabled;
 break;
 
-case FLASK_DISABLE:
-rv = flask_disable();
-break;
-
 case FLASK_GETAVC_THRESHOLD:
 rv = avc_cache_threshold;
 break;
-- 
2.20.1

[PATCH v5 01/10] xen: Implement xen/alternative-call.h for use in common code

[Daniel P. Smith]

From: Andrew Cooper 

The alternative call infrastructure is x86-only for now, but the common iommu
code has a variant and more common code wants to use the infrastructure.

Introduce CONFIG_ALTERNATIVE_CALL and a conditional implemetnation so common
code can use the optimisation when available, without requiring all
architectures to implement no-op stubs.

Write some documentation, which was thus far entirely absent, covering the
requirements for an architecture to implement this optimsiation, and how to
use the infrastructure in general code.

Signed-off-by: Andrew Cooper 
Signed-off-by: Daniel P. Smith 

---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bob Eshleman 
CC: Alistair Francis 
CC: Connor Davis 
CC: Daniel P. Smith 

v3:
 * Drop __alt_call_maybe_initconst

This is a pre-requisite to "xsm: refactor xsm_ops handling" to avoid breaking
the ARM build.

Build test for the XSM code:

  diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
  index 5eab21e1b168..592074e8f41c 100644
  --- a/xen/xsm/xsm_core.c
  +++ b/xen/xsm/xsm_core.c
  @@ -195,6 +195,16 @@ bool __init has_xsm_magic(paddr_t start)
   }
#endif

  +#include 
  +struct foo {
  +int (*bar)(void *);
  +} foo __alt_call_maybe_initdata;
  +
  +int test_alternative_call(void)
  +{
  +return alternative_call(foo.bar, NULL);
  +}
  +
   int __init register_xsm(struct xsm_operations *ops)
{
 if ( verify(ops) )
---
 xen/arch/x86/Kconfig   |  1 +
 xen/common/Kconfig |  3 ++
 xen/include/xen/alternative-call.h | 63 ++
 3 files changed, 67 insertions(+)
 create mode 100644 xen/include/xen/alternative-call.h

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 9b164db641..1f83518ee0 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -6,6 +6,7 @@ config X86
def_bool y
select ACPI
select ACPI_LEGACY_TABLES_LOOKUP
+   select ALTERNATIVE_CALL
select ARCH_SUPPORTS_INT128
select CORE_PARKING
select HAS_ALTERNATIVE
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 0ddd18e11a..ac5491b1cc 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -22,6 +22,9 @@ config GRANT_TABLE
 
  If unsure, say Y.
 
+config ALTERNATIVE_CALL
+   bool
+
 config HAS_ALTERNATIVE
bool
 
diff --git a/xen/include/xen/alternative-call.h 
b/xen/include/xen/alternative-call.h
new file mode 100644
index 00..d10af90b1b
--- /dev/null
+++ b/xen/include/xen/alternative-call.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef XEN_ALTERNATIVE_CALL
+#define XEN_ALTERNATIVE_CALL
+
+/*
+ * Some subsystems in Xen may have multiple implementions, which can be
+ * resolved to a single implementation at boot time.  By default, this will
+ * result in the use of function pointers.
+ *
+ * Some architectures may have mechanisms for dynamically modifying .text.
+ * Using this mechnaism, function pointers can be converted to direct calls
+ * which are typically more efficient at runtime.
+ *
+ * For architectures to support:
+ *
+ * - Implement alternative_{,v}call() in asm/alternative.h.  Code generation
+ *   requirements are to emit a function pointer call at build time, and stash
+ *   enough metadata to simplify the call at boot once the implementation has
+ *   been resolved.
+ * - Select ALTERNATIVE_CALL in Kconfig.
+ *
+ * To use:
+ *
+ * Consider the following simplified example.
+ *
+ *  1) struct foo_ops __alt_call_maybe_initdata ops;
+ *
+ *  2) const struct foo_ops __initconst foo_a_ops = { ... };
+ * const struct foo_ops __initconst foo_b_ops = { ... };
+ *
+ * void foo_init(void)
+ * {
+ * ...
+ * if ( use_impl_a )
+ * ops = *foo_a_ops;
+ * else if ( use_impl_b )
+ * ops = *foo_b_ops;
+ * ...
+ * }
+ *
+ *  3) alternative_call(ops.bar, ...);
+ *
+ * There needs to a single ops object (1) which will eventually contain the
+ * function pointers.  This should be populated in foo's init() function (2)
+ * by one of the available implementations.  To call functions, use
+ * alternative_{,v}call() referencing the main ops object (3).
+ */
+
+#ifdef CONFIG_ALTERNATIVE_CALL
+
+#include 
+
+#define __alt_call_maybe_initdata __initdata
+
+#else
+
+#define alternative_call(func, args...)  (func)(args)
+#define alternative_vcall(func, args...) (func)(args)
+
+#define __alt_call_maybe_initdata __read_mostly
+
+#endif /* !CONFIG_ALTERNATIVE_CALL */
+#endif /* XEN_ALTERNATIVE_CALL */
-- 
2.20.1

[PATCH v5 00/10] xsm: refactoring xsm hooks

[Daniel P. Smith]

Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC patch set
is being split into two separate patch sets. This is the first patch set and is
focused purely on the clean up and refactoring of the XSM hooks.

This patch set refactors the xsm_ops wrapper hooks to use the alternative_call
infrastructure. Then proceeds to move and realign the headers to simplify the
unnecessarily complicated header inclusions, remove the facad of being able to
enable/disable XSM, and simplify the XSM hooks down to a single interface and
implementation. The remainder of the changes are clean up and removing no
longer necessary abstractions.

v2:
 - restructured the patches, breaking them up as needed
 - incorporate Andrew Cooper's alternative call common code
 - change XSM module registration, removing register_xsm
 - incoporate KConfig recommendations
 - reworded commit messages
 - incorporate macro expansion recommendations
 - misc clean-up fallout from recommendations

v3:
 - renamed struct xsm_operations to struct xsm_ops
 - flask and silo ops structs made __initconst
 - fixed misplacement of __init on flask/silo_init
 - lots of coding style alignment
 - further clean up from FLASK_DISABLE removal
 - addressed commit message comments
 - removed missed guard around alternative-call include
- reworked approach to XSM hooks, merging the two interfaces instead of
   dropping one

v4:
- make __alt_call_maybe_initdata resolve to __read_mostly when
  CONFIG_ALTERNATIVE_CALL is not set
- removed the masking of void with xsm_op_t
- moved all the coding style conformity to an early commit
- fixed declaration on real and stub declarations in xsm.h
- corrected to __initconstrel
- made the xsm_ops global __read_mostly
- adjusted blank lines in xsm_ops struct to provide consistent grouping
- moved extern references to built in policy to where they are used
- Added back in the #ifdef CONFIG_XSM into struct evtchn
- split the patch removing the duplicate interface up further

v5
- changed 80 col wrapping style to preferred style
- a few additional code style cleanups caught in v4 review
- made xsm_ops_registered __initdata
- pulled duplicate if out of switch cases in xsm_core_init()
- dropped struct evtchn commit
- dropped silo hooks direct calls to xsm_default_action

Andrew Cooper (1):
  xen: Implement xen/alternative-call.h for use in common code

Daniel P. Smith (9):
  xsm: remove the ability to disable flask
  xsm: remove remnants of xsm_memtype hook
  xsm: drop dubious xsm_op_t type
  xsm: apply coding style
  xsm: refactor xsm_ops handling
  xsm: convert xsm_ops hook calls to alternative call
  xsm: decouple xsm header inclusion selection
  kconfig: update xsm config to reflect reality
  xsm: remove alternate xsm hook interface

 xen/arch/x86/Kconfig   |   1 +
 xen/common/Kconfig |  52 +-
 xen/include/public/xsm/flask_op.h  |   2 +-
 xen/include/xen/alternative-call.h |  63 +++
 xen/include/xen/hypercall.h|   4 +-
 xen/include/xen/sched.h|   2 +-
 xen/include/xsm/dummy.h| 774 ---
 xen/include/xsm/xsm-core.h | 266 ++
 xen/include/xsm/xsm.h  | 806 +
 xen/xsm/Makefile   |   4 +-
 xen/xsm/dummy.c|   7 +-
 xen/xsm/dummy.h| 659 +++
 xen/xsm/flask/flask_op.c   |  32 +-
 xen/xsm/flask/hooks.c  |  16 +-
 xen/xsm/silo.c |  11 +-
 xen/xsm/xsm_core.c |  93 ++--
 xen/xsm/xsm_policy.c   |   7 +-
 17 files changed, 1436 insertions(+), 1363 deletions(-)
 create mode 100644 xen/include/xen/alternative-call.h
 delete mode 100644 xen/include/xsm/dummy.h
 create mode 100644 xen/include/xsm/xsm-core.h
 create mode 100644 xen/xsm/dummy.h

-- 
2.20.1

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  56abcf1a58bdaef18579cf2ce8645c8c72a2b749
baseline version:
 xen  e70a9a043a5ce6d4025420f729bc473f711bf5d1

Last test of basis   164883  2021-09-08 10:10:28 Z1 days
Testing same since   164892  2021-09-08 21:09:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Jan Beulich 
  Jane Malalane 
  Julien Grall 

jobs:
 build-amd64-xsm  pa

Re: Disable IOMMU in Dom0

[Stefano Stabellini]

I am fine with adding this functionality only to device tree initially.


It is certainly true that if a DMA-capable device is behind an IOMMU,
then we can skip swiotlb-xen for foreign pages address transactions.
Those addresses will be translated just fine thanks to the IOMMU.
Skipping swiotlb-xen could provide a non-negligible performance
improvement, which is good.

However, you should be aware that your proposal should not be needed for
correctness or to make devices with a 4GB DMA mask work.

Thanks to commit 04085ec1a "xen/arm: fix gnttab_need_iommu_mapping"
foreign pages are added to the Dom0 p2m when mapped to Dom0. swiotlb-xen
translates foreign pages gfn to mfn then uses the mfn to program the
device DMA. The DMA transaction will be accepted by the IOMMU thanks to
the 1:1 GFN<->MFN entry added to Dom0 at the time of mapping.

If the mfn is >4GB and the device requires an address <4GB, then the
dma_capable check at the beginning of xen_swiotlb_map_page fails and the
DMA transaction gets bounced on a swiotlb-xen buffer lower than 4GB.

Am I missing anything?


On Thu, 9 Sep 2021, Roman Skakun wrote:
> Hi Julien,
> Thanks for the clarification!
> 
> I aim towards to prepare implementation for upstream to disable SWIOTLB for 
> IOMMU-protected devices in Dom0.
> To provide this functionality need to add additional binding for each 
> protected device in device-tree.
> After this step, I will also prepare the patch to make ensure that ballooning 
> code prepares all allocations below 4GB.
> 
> We are going to prepare this functionality only for device-tree based system 
> configurations.
> We don't have resources to support ACPI configuration.
> 
> Would you be ok with upstreaming only device-tree configuration?
> 
> Cheers,
> Roman
> 
> ___
> From: Julien Grall 
> Sent: Wednesday, September 1, 2021 1:22 PM
> To: Roman Skakun ; Stefano Stabellini 
> 
> Cc: xen-devel@lists.xenproject.org ; Bertrand 
> Marquis ; Andrii Anisov
> ; Roman Skakun ; Oleksandr 
> Tyshchenko 
> Subject: Re: Disable IOMMU in Dom0  
> Hi Roman
> 
> On 01/09/2021 10:59, Roman Skakun wrote:
> >> If you have a setup  where Dom0 is not 1:1 mapped (which is not currently
> >> possible with upstream  Xen but it is possible with cache coloring) and
> >> uses the IOMMU to make  device DMA work like regular DomUs, then passing
> >> XENFEAT_not_direct_mapped  to Linux would make it work. Without
> >> XENFEAT_not_direct_mapped,  Linux would try to use swiotlb-xen which has
> >> code that relies on  Linux being 1:1 mapped to work properly.
> >
> > I'm using 1:1 Dom0.
> > According to your patch series, xen-swiotlb fops will be applied for all
> > devices
> > because XENFEAT_direct_mapped is active, as shown here:
> >https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14/source/arch/arm64/mm/dma-mapping.c*L56__;Iw!!GF_29dbcQIUBPA!i7I0DxCbP4i
> bLDwzRkeFkgRQbKh-fVD9McLqabG1TzZs9smOVBeowPS_Iv_mvn3O$ 
> [elixir[.]bootlin[.]com]
> > ibLDwzRkeFkgRQbKh-fVD9McLqabG1TzZs9smOVBeowPS_Iv_mvn3O$ 
> [elixir[.]bootlin[.]com]>
> >
> > I agreed, that xen-swiotlb should work correctly, but in my case, I
> > retrieved MFN here:
> >https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14/source/drivers/xen/swiotlb-xen.c*L366__;Iw!!GF_29dbcQIUBPA!i7I0DxCbP4ib
> LDwzRkeFkgRQbKh-fVD9McLqabG1TzZs9smOVBeowPS_IgZgXPjC$ [elixir[.]bootlin[.]com]
> > bLDwzRkeFkgRQbKh-fVD9McLqabG1TzZs9smOVBeowPS_IgZgXPjC$ 
> [elixir[.]bootlin[.]com]>
> > which is greater than 32bit and xen-swiotlb tries to use bounce buffer
> > as expected.
> > It can lead to decrease a performance because I have a long buffer ~4MB.
> >
> > I thought, that we can disable swiotlb fops for devices which are
> > controlled by IOMMU.
> 
> Yes you can disable swiotlb for devices which are controlled by the
> IOMMU. But this will not make your problem disappear, it simply hides
> until it bites you in a more subttle way.
> 
>  From what you wrote, you have a 32-bit DMA capable. So you always need
> to have an address below 4GB. For foreign mapping, there is no guarantee
> the Guest Physical Address will actually be below 4GB.
> 
> Today, the ballooning code only ask Linux to steal *a* RAM page for
> mapping the foreign page. This may or may not be below 4GB depending on
> how you assigned the RAM to dom0 (IIRC you had some RAM above 4GB).
> 
> But that's the current behavior. One of your work colleague is looking
> at avoid to steal RAM page to avoid exhausting the memory. So foreign
> mapping may end up to be a lot higher in memory.
> 
> IOW, you will need to be able to bounce t

Re: [PATCH] x86: correct asm() constraints when dealing with immediate selector values

[Andrew Cooper]

On 09/09/2021 15:56, Jan Beulich wrote:
> asm() constraints need to fit both the intended insn(s) which the
> respective operands are going to be used with as well as the actual kind
> of value specified. "m" (alone) together with a constant, however, leads
> to gcc saying
>
> error: memory input  is not directly addressable
>
> while clang complains
>
> error: invalid lvalue in asm input for constraint 'm'
>
> And rightly so - in order to access a memory operand, an address needs
> to be specified to the insn. In some cases it might be possible for a
> compiler to synthesize a memory operand holding the requested constant,
> but I think any solution there would have sharp edges.

It's precisely what happens in the other uses of constants which you
haven't adjusted below.  Constants are fine if being propagated into a
static inline which has properly typed parameters.

Or are you saying automatic spilling when a width isn't necessarily known?

> If "m" alone doesn't work with constants, it is at best pointless (and
> perhaps misleading or even risky - the compiler might decide to actually
> pick "m" and not try very hard to find a suitable register) to specify
> it alongside "r".
>
> Signed-off-by: Jan Beulich 

I'm slightly surprised you didn't spot and comment about what Clang does
with this.

https://godbolt.org/z/M4nrerrWM

For "rm" (0), clang really does spill the constant into a global and
generate a rip-relative mov to fs, which is especially funny considering
the rejection of "m" as a constraint.

Clang even spills "rm" (local) into a global, while "m" (local) does
come from the stack.


I think there is a reasonable argument to say "m" (const) doesn't have
enough type (width) information for a compiler to do anything sensible
with, and therefore it is fair to be dropped.

But for "rm" (var), where there is enough width information, I don't
think it is reasonable to drop the "m" and restrict the flexibility.

Furthermore, I'm going to argue that we shouldn't work around this
behaviour by removing "m" elsewhere.  This code generation
bug/misfeature affects every use of "rm", even when the referenced
operand is on the stack and can be used without unspilling first.

>
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -736,7 +736,7 @@ void __init detect_zen2_null_seg_behavio
>   uint64_t base;
>  
>   wrmsrl(MSR_FS_BASE, 1);
> - asm volatile ( "mov %0, %%fs" :: "rm" (0) );
> + asm volatile ( "mov %0, %%fs" :: "r" (0) );
>   rdmsrl(MSR_FS_BASE, base);
>  
>   if (base == 0)
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -248,7 +248,7 @@ void do_double_fault(struct cpu_user_reg
>  
>  console_force_unlock();
>  
> -asm ( "lsll %1, %0" : "=r" (cpu) : "rm" (PER_CPU_SELECTOR) );
> +asm ( "lsll %1, %0" : "=r" (cpu) : "r" (PER_CPU_SELECTOR) );

Any chance we can clean this up to: lsl %[lim], %[sel] seeing as the
line is being edited?

~Andrew

Re: [PATCH v4 09/11] silo: remove circular xsm hook call

[Daniel P. Smith]

On 9/9/21 11:45 AM, Jan Beulich wrote:
> On 03.09.2021 21:06, Daniel P. Smith wrote:
>> SILO implements a few XSM hooks to extended the decision logic beyond
>> what is defined in the dummy/default policy. For each of the hooks, it
>> falls back to the dummy/default policy. The fall back is done a slight
>> round-about way. This commit makes the direct call to the default policy's
>> logic, xsm_default_action().
> 
> Again it's not clear to me what you're finding wrong here. The way it's
> done is not as direct as it could be, but going through the extra layer
> allows the functions to document things at the same time. You lose not
> only that documentation, but also ...

It is only for six calls, thus I figured the slight overhead would be
worth cutting out the indirection. If now one is worried about the extra
indirection, than I can adjust to call the default's handlers.

Re: [RFC PATCH 03/10] block: Use qemu_security_policy_taint() API

[Eric Blake]

On Thu, Sep 09, 2021 at 01:20:17AM +0200, Philippe Mathieu-Daudé wrote:
> Add the BlockDriver::bdrv_taints_security_policy() handler.
> Drivers implementing it might taint the global QEMU security
> policy.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/block/block_int.h | 6 +-
>  block.c   | 6 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/include/block/block_int.h b/include/block/block_int.h
> index f1a54db0f8c..0ec0a5c06e9 100644
> --- a/include/block/block_int.h
> +++ b/include/block/block_int.h
> @@ -169,7 +169,11 @@ struct BlockDriver {
>  int (*bdrv_file_open)(BlockDriverState *bs, QDict *options, int flags,
>Error **errp);
>  void (*bdrv_close)(BlockDriverState *bs);
> -
> +/*
> + * Return %true if the driver is withing QEMU security policy boundary,

within

> + * %false otherwise. See: 
> https://www.qemu.org/contribute/security-process/
> + */
> +bool (*bdrv_taints_security_policy)(BlockDriverState *bs);
>  
>  int coroutine_fn (*bdrv_co_create)(BlockdevCreateOptions *opts,
> Error **errp);

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [RFC PATCH 02/10] accel: Use qemu_security_policy_taint(), mark KVM and Xen as safe

[Eric Blake]

On Thu, Sep 09, 2021 at 01:20:16AM +0200, Philippe Mathieu-Daudé wrote:
> Add the AccelClass::secure_policy_supported field to classify
> safe (within security boundary) vs unsafe accelerators.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/qemu/accel.h | 5 +
>  accel/kvm/kvm-all.c  | 1 +
>  accel/xen/xen-all.c  | 1 +
>  softmmu/vl.c | 3 +++
>  4 files changed, 10 insertions(+)
> 
> diff --git a/include/qemu/accel.h b/include/qemu/accel.h
> index 4f4c283f6fc..895e30be0de 100644
> --- a/include/qemu/accel.h
> +++ b/include/qemu/accel.h
> @@ -44,6 +44,11 @@ typedef struct AccelClass {
> hwaddr start_addr, hwaddr size);
>  #endif
>  bool *allowed;
> +/*
> + * Whether the accelerator is withing QEMU security policy boundary.

within

> + * See: https://www.qemu.org/contribute/security-process/
> + */
> +bool secure_policy_supported;
>  /*
>   * Array of global properties that would be applied when specific
>   * accelerator is chosen. It works like MachineClass.compat_props

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [RFC PATCH 01/10] sysemu: Introduce qemu_security_policy_taint() API

[Eric Blake]

On Thu, Sep 09, 2021 at 01:20:15AM +0200, Philippe Mathieu-Daudé wrote:
> Introduce qemu_security_policy_taint() which allows unsafe (read
> "not very maintained") code to 'taint' QEMU security policy.
> 
> The "security policy" is the @SecurityPolicy QAPI enum, composed of:
> - "none"   (no policy, current behavior)
> - "warn"   (display a warning when the policy is tainted, keep going)
> - "strict" (once tainted, exit QEMU before starting the VM)
> 
> The qemu_security_policy_is_strict() helper is also provided, which
> will be proved useful once a VM is started (example we do not want

s/be proved/prove/

> to kill a running VM if an unsafe device is hot-added).
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  qapi/run-state.json   | 16 +++
>  include/qemu-common.h | 19 
>  softmmu/vl.c  | 67 +++
>  qemu-options.hx   | 17 +++
>  4 files changed, 119 insertions(+)
> 
> diff --git a/qapi/run-state.json b/qapi/run-state.json
> index 43d66d700fc..b15a107fa01 100644
> --- a/qapi/run-state.json
> +++ b/qapi/run-state.json
> @@ -638,3 +638,19 @@
>  { 'struct': 'MemoryFailureFlags',
>'data': { 'action-required': 'bool',
>  'recursive': 'bool'} }
> +
> +##
> +# @SecurityPolicy:
> +#
> +# An enumeration of the actions taken when the security policy is tainted.
> +#
> +# @none: do nothing.
> +#
> +# @warn: display a warning.
> +#
> +# @strict: prohibit QEMU to start a VM.

s/to start/from starting/

> +#
> +# Since: 6.2
> +##
> +{ 'enum': 'SecurityPolicy',
> +  'data': [ 'none', 'warn', 'strict' ] }

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [PATCH 10/11] xen/arm: Do not map PCI ECAM space to Domain-0's p2m

[Julien Grall]

Hi Oleksandr,

On 03/09/2021 09:33, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Host bridge controller's ECAM space is mapped into Domain-0's p2m,
thus it is not possible to trap the same for vPCI via MMIO handlers.
For this to work we need to not map those while constructing the domain.

Note, that during Domain-0 creation there is no pci_dev yet allocated for
host bridges, thus we cannot match PCI host and its associated
bridge by SBDF. Use dt_device_node field for checks instead.

Signed-off-by: Oleksandr Andrushchenko 
---
  xen/arch/arm/domain_build.c|  3 +++
  xen/arch/arm/pci/ecam.c| 17 +
  xen/arch/arm/pci/pci-host-common.c | 22 ++
  xen/include/asm-arm/pci.h  | 12 
  4 files changed, 54 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index da427f399711..76f5b513280c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1257,6 +1257,9 @@ static int __init map_range_to_domain(const struct 
dt_device_node *dev,
  }
  }
  
+if ( need_mapping && (device_get_class(dev) == DEVICE_PCI) ) > +need_mapping = pci_host_bridge_need_p2m_mapping(d, dev, 

addr, len);

AFAICT, with device_get_class(dev), you know whether the hostbridge is 
used by Xen. Therefore, I would expect that we don't want to map all the 
regions of the hostbridges in dom0 (including the BARs).


Can you clarify it?


+ >   if ( need_mapping )
  {
  res = map_regions_p2mt(d,
diff --git a/xen/arch/arm/pci/ecam.c b/xen/arch/arm/pci/ecam.c
index 92ecb2e0762b..d32efb7fcbd0 100644
--- a/xen/arch/arm/pci/ecam.c
+++ b/xen/arch/arm/pci/ecam.c
@@ -52,6 +52,22 @@ static int pci_ecam_register_mmio_handler(struct domain *d,
  return 0;
  }
  
+static int pci_ecam_need_p2m_mapping(struct domain *d,

+ struct pci_host_bridge *bridge,
+ uint64_t addr, uint64_t len)
+{
+struct pci_config_window *cfg = bridge->sysdata;
+
+if ( !is_hardware_domain(d) )
+return true;


I am a bit puzzled with this check. If the ECAM has been initialized by 
Xen, then I believe we cannot expose it to any domain at all.



+
+/*
+ * We do not want ECAM address space to be mapped in domain's p2m,
+ * so we can trap access to it.
+ */
+return cfg->phys_addr != addr;
+}
+
  /* ECAM ops */
  const struct pci_ecam_ops pci_generic_ecam_ops = {
  .bus_shift  = 20,
@@ -60,6 +76,7 @@ const struct pci_ecam_ops pci_generic_ecam_ops = {
  .read   = pci_generic_config_read,
  .write  = pci_generic_config_write,
  .register_mmio_handler  = pci_ecam_register_mmio_handler,
+.need_p2m_mapping   = pci_ecam_need_p2m_mapping,
  }
  };
  
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host-common.c

index a89112bfbb7c..c04be636452d 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -334,6 +334,28 @@ int pci_host_iterate_bridges(struct domain *d,
  }
  return 0;
  }
+
+bool pci_host_bridge_need_p2m_mapping(struct domain *d,
+  const struct dt_device_node *node,
+  uint64_t addr, uint64_t len)
+{
+struct pci_host_bridge *bridge;
+
+list_for_each_entry( bridge, &pci_host_bridges, node )
+{
+if ( bridge->dt_node != node )
+continue;
+
+if ( !bridge->ops->need_p2m_mapping )
+return true;
+
+return bridge->ops->need_p2m_mapping(d, bridge, addr, len);
+}
+printk(XENLOG_ERR "Unable to find PCI bridge for %s segment %d, addr 
%lx\n",
+   node->full_name, bridge->segment, addr);
+return true;
+}


If you really need to map the hostbridges, then I would suggest to defer 
the P2M mappings for all of them and then walk all the bridge in one go 
to do the mappings.


This would avoid going through the bridges every time during setup.


+
  /*
   * Local variables:
   * mode: C
diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
index 2c7c7649e00f..9c28a4bdc4b7 100644
--- a/xen/include/asm-arm/pci.h
+++ b/xen/include/asm-arm/pci.h
@@ -82,6 +82,8 @@ struct pci_ops {
  int (*register_mmio_handler)(struct domain *d,
   struct pci_host_bridge *bridge,
   const struct mmio_handler_ops *ops);
+int (*need_p2m_mapping)(struct domain *d, struct pci_host_bridge *bridge,
+uint64_t addr, uint64_t len);
  };
  
  /*

@@ -115,9 +117,19 @@ struct dt_device_node *pci_find_host_bridge_node(struct 
device *dev);
  int pci_host_iterate_bridges(struct domain *d,
   int (*clb)(struct domain *d,
  struct pci_host_bridge *bridge));
+bool pci_host_bridge_n

Re: [PATCH 09/11] xen/arm: Setup MMIO range trap handlers for hardware domain

[Julien Grall]

Hi Oleksandr,

On 03/09/2021 09:33, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

In order vPCI to work it needs all access to PCI configuration space
(ECAM) to be synchronized among all entities, e.g. hardware domain and
guests.


I am not entirely sure what you mean by "synchronized" here. Are you 
refer to the content of the configuration space?



For that implement PCI host bridge specific callbacks to
properly setup those ranges depending on particular host bridge
implementation.

Signed-off-by: Oleksandr Andrushchenko 
---
  xen/arch/arm/pci/ecam.c| 11 +++
  xen/arch/arm/pci/pci-host-common.c | 16 
  xen/arch/arm/vpci.c| 13 +
  xen/include/asm-arm/pci.h  |  8 
  4 files changed, 48 insertions(+)

diff --git a/xen/arch/arm/pci/ecam.c b/xen/arch/arm/pci/ecam.c
index 91c691b41fdf..92ecb2e0762b 100644
--- a/xen/arch/arm/pci/ecam.c
+++ b/xen/arch/arm/pci/ecam.c
@@ -42,6 +42,16 @@ void __iomem *pci_ecam_map_bus(struct pci_host_bridge 
*bridge,
  return base + (PCI_DEVFN(sbdf_t.dev, sbdf_t.fn) << devfn_shift) + where;
  }
  
+static int pci_ecam_register_mmio_handler(struct domain *d,

+  struct pci_host_bridge *bridge,
+  const struct mmio_handler_ops *ops)
+{
+struct pci_config_window *cfg = bridge->sysdata;
+
+register_mmio_handler(d, ops, cfg->phys_addr, cfg->size, NULL);


We have a fixed array for handling the MMIO handlers. So you need to 
make sure we have enough space in it to store one handler per handler.


This is quite similar to the problem we had with the re-distribuor on 
GICv3. Have a look there to see how we dealt with it.



+return 0;
+}
+
  /* ECAM ops */
  const struct pci_ecam_ops pci_generic_ecam_ops = {
  .bus_shift  = 20,
@@ -49,6 +59,7 @@ const struct pci_ecam_ops pci_generic_ecam_ops = {
  .map_bus= pci_ecam_map_bus,
  .read   = pci_generic_config_read,
  .write  = pci_generic_config_write,
+.register_mmio_handler  = pci_ecam_register_mmio_handler,
  }
  };
  
diff --git a/xen/arch/arm/pci/pci-host-common.c b/xen/arch/arm/pci/pci-host-common.c

index d2fef5476b8e..a89112bfbb7c 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -318,6 +318,22 @@ struct dt_device_node *pci_find_host_bridge_node(struct 
device *dev)
  }
  return bridge->dt_node;
  }
+
+int pci_host_iterate_bridges(struct domain *d,
+ int (*clb)(struct domain *d,


NIT: We tend to name callback variable 'cb'.

Cheers,

--
Julien Grall

[libvirt test] 164895: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   151777  2020-07-10 04:19:19 Z  426 days
Failing since151818  2020-07-11 04:18:52 Z  425 days  416 attempts
Testing same since   164895  2021-09-09 04:18:55 Z0 days1 attempts


People who touched revisions under test:
Adolfo Jayme Barrientos 
  Aleksandr Alekseev 
  Aleksei Zakharov 
  Andika Triwidada 
  Andrea Bolognani 
  Balázs Meskó 
  Barrett Schonefeld 
  Bastian Germann 
  Bastien Orivel 
  BiaoXiang Ye 
  Bihong Yu 
  Binfeng Wu 
  Bjoern Walk 
  Boris Fiuczynski 
  Brian Turek 
  Bruno Haible 
  Chris Mayo 
  Christian Ehrhardt 
  Christian Kirbach 
  Christian Schoenebeck 
  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 
  Dmytro Linkin 
  Eiichi Tsukata 
  Eric Farman 
  Erik Skultety 
  Fabian Affolter 
  Fabian Freyer 
  Fabiano Fidêncio 
  Fangge Jin 
  Farhan Ali 
  Fedora Weblate Translation 
  gongwei 
  Guoyi Tu
  Göran Uddeborg 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Hela Basa 
  Helmut Grohne 
  Ian Wienand 
  Jakob Meng 
  Jamie Strandboge 
  Jamie Strandboge 
  Jan Kuparinen 
  jason lee 
  Jean-Baptiste Holcroft 
  Jia Zhou 
  Jianan Gao 
  Jim Fehlig 
  Jin Yan 
  Jinsheng Zhang 
  Jiri Denemark 
  John Ferlan 
  Jonathan Watt 
  Jonathon Jongsma 
  Julio Faracco 
  Justin Gatzen 
  Ján Tomko 
  Kashyap Chamarthy 
  Kevin Locke 
  Kristina Hanicova 
  Laine Stump 
  Laszlo Ersek 
  Lee Yarwood 
  Lei Yang 
  Liao Pingfang 
  Lin Ma 
  Lin Ma 
  Lin Ma 
  Liu Yiding 
  Luke Yue 
  Luyao Zhong 
  Marc Hartmayer 
  Marc-André Lureau 
  Marek Marczykowski-Górecki 
  Markus Schade 
  Martin Kletzander 
  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 Shyrokovskiy 
  Nickys Music Group 
  Nico Pache 
  Nikolay Shirokovskiy 
  Olaf Hering 
  Olesya Gerasimenko 
  Orion Poplawski 
  Pany 
  Patrick Magauran 
  Paulo de Rezende Pinatti 
  Pavel Hrdina 
  Peng Liang 
  Peter Krempa 
  Pino Toscano 
  Pino Toscano 
  Piotr Drąg 
  Prathamesh Chavan 
  Richard W.M. Jones 
  Ricky Tigg 
  Roman Bogorodskiy 
  Roman Bolshakov 
  Ryan Gahagan 
  Ryan Schmidt 
  Sam Hartman 
  Scott Shambarger 
  Sebastian Mitterle 
  SeongHyun Jo 
  Shalini Chellathurai Saroja 
  Shaojun Yang 
  Shi Lei 
  simmon 
  Simon Chopin 
  Simon Gaiser 
  Simon Rowe 
  Stefan Bader 
  Stefan Berger 
  Stefan Berger 
  Stefan Hajnoczi 
  Szymon Scholz 
  Thomas Huth 
  Tim Wiederhake 
  Tomáš Golembiovský 
  Tomáš Janoušek 
  Tuguoyi 
  Ville Skyttä 
  Vinayak Kale 
  Wang Xin 
  WangJian 
  Weblate 
  Wei Liu 
  Wei Liu 
  William Douglas 
  Yalei Li <274268...@qq.com>
  Yalei Li 
  Yang Fei 
  Yang Hang 
  Yanqiu Zhang 
  Yaroslav Kargin 
  Yi Li 
  Yi Wang 
  Yuri Chornoivan 
  Zbigniew Jędrzejewski-Szmek 
  zhangjl02 
  Zheng Chuan 
  zhenwei pi 
  Zhenyu Ye 
  Zhenyu Zheng 
  Zhenzhong Duan 

jobs:
 build-amd64-xsm

Re: [PATCH 01/11] xen/arm: Add new device type for PCI

[Julien Grall]

Hi Oleksandr,

On 03/09/2021 09:33, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Add new device type (DEV_PCI) to distinguish PCI devices from platform
DT devices, so some drivers, like IOMMU, can handle PCI devices
differently.


I think it would be better to fold this change in the next patch as this 
is where you add all the helpers for converting dev to PCI.




While at it fix dev_is_dt macro.


I would keep this change separate. It also needs an explanation of 
what's the problem and mention it is a latent bug because no-one use it 
(so we know this doesn't require a backport).


Cheers,

--
Julien Grall

Re: [PATCH 1/3] tools/libacpi: Use 64-byte alignment for FACS

[Andrew Cooper]

On 09/09/2021 17:34, Kevin Stefanov wrote:
> The spec requires 64-byte alignment, not 16.
>
> Signed-off-by: Kevin Stefanov 
> ---
> CC: Jan Beulich 
> CC: Andrew Cooper 
>
> Note: This does not fix the FACS alignment inside guests yet. See next
> patch.

The history here is complex.

c/s 938cee9d41d3 in 2006 deleted a comment saying

// FACS: should be 64-bit alignment
// so it is put at the start of buffer
// as the buffer is 64 bit alignment

Clearly it means byte rather than bit, but the change also introduced
logic to the effect of buf += ROUNDUP(sizeof(facs), 16).

This (incorrect) alignment survived several morphs of the logic and was
moved from hvmloader into libacpi by c/s 73b72736e6ca.

The current code is clearly wrong, but happens to work correctly in
hvmloader because FACS is the first table written and it starts on a
page boundary.  The logic does not work correctly when libxl passes a
buffer which doesn't start on a page boundary.

As a consequence, I'm not sure what to suggest as a Fixes tag here,
except "the logic has been wrong for 15 years - patch everything".

~Andrew

[OSSTEST PATCH 3/4] fmtarches: Use dom0arches, not hardcoded arch list

[Ian Jackson]

This will make us reallocate fmt tests when the arch list changes.
It's not ideal because it means tests jumping about across arches and
might let regressions go through but it's better than just dropping
them, and doing a better approach is complex.

This changes some jobs and adds others, roughly:

  +   test-amd64-i386-libvirt-fraw
  -   test-amd64-i386-xl-raw
  +   test-amd64-i386-xl-vhd
  +   test-arm64-arm64-libvirt-raw
  +   test-arm64-arm64-xl-vhd
  +   test-armhf-armhf-libvirt-qcow2

(as reported by standalone-generate-dump-flight-runvars)

Signed-off-by: Ian Jackson 
---
 make-flight | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/make-flight b/make-flight
index e0d11c80..ecbb195b 100755
--- a/make-flight
+++ b/make-flight
@@ -652,7 +652,7 @@ do_pv_debian_tests () {
   # Within each fmt we rotate through the list of arches
   # The starting list rotates once per ts, so that we try to
   # exercise each fmt on each arch family.
-  local fmtarches_outer="i386 armhf amd64 arm64"
+  local fmtarches_outer="$dom0arches"
   local endfmt="do_pv_debian_tests-missing-ts-fmt-for-dom0arch="
 
   for ts in xl libvirt ; do
-- 
2.20.1

[OSSTEST PATCH 2/4] mfi-common: Change dom0arch list order (nfc)

[Ian Jackson]

Change the order to match fmtarches_outer in do_pv_debian_tests.

We are going to want to add an indirection here but not change
anything.

No change to output from standalone-generate-dump-flight-runvars.

Signed-off-by: Ian Jackson 
---
 mfi-common | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mfi-common b/mfi-common
index 70e17f7a..02278420 100644
--- a/mfi-common
+++ b/mfi-common
@@ -644,7 +644,7 @@ test_matrix_iterate () {
   esac
 
   dom0arches=''
-  for dom0arch in i386 amd64 armhf arm64; do
+  for dom0arch in i386 armhf amd64 arm64; do
 
 case ${xenarch}_${dom0arch} in
 amd64_amd64) ;;
-- 
2.20.1

[OSSTEST PATCH 4/4] mfi-common: Drop Linux dom0 i386 tests for newer Linux branches

[Ian Jackson]

This makes radical changes to the test ste for the linux-linus and
linux-next branches.

Mostly, tests are dropped but some 64-bit dom0 tests are added to
replace them.

Requested-by: Juergen Gross 
Signed-off-by: Ian Jackson 
---
 mfi-common | 5 +
 1 file changed, 5 insertions(+)

diff --git a/mfi-common b/mfi-common
index 02278420..771843f0 100644
--- a/mfi-common
+++ b/mfi-common
@@ -655,6 +655,11 @@ test_matrix_iterate () {
 *) continue ;;
 esac
 
+case "${branch}_${dom0arch}" in
+  linux-5.4_i386 | linux-[2-4].*_i386) ;; # keep 32-bit for old linux
+  linux-*_i386) continue;;
+esac
+
 dom0arches+=" $dom0arch"
   done
 
-- 
2.20.1

[OSSTEST PATCH 1/4] mfi-common: break out dom0arches variable (nfc)

[Ian Jackson]

This will allow test choices to depend on the actual rather than
entire dom0arches.

No change to output from standalone-generate-dump-flight-runvars.

Signed-off-by: Ian Jackson 
---
 mfi-common | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/mfi-common b/mfi-common
index 2834411f..70e17f7a 100644
--- a/mfi-common
+++ b/mfi-common
@@ -643,6 +643,7 @@ test_matrix_iterate () {
   *)  echo >&2 "kernbuild ?  $kern"; exit 1 ;;
   esac
 
+  dom0arches=''
   for dom0arch in i386 amd64 armhf arm64; do
 
 case ${xenarch}_${dom0arch} in
@@ -654,6 +655,11 @@ test_matrix_iterate () {
 *) continue ;;
 esac
 
+dom0arches+=" $dom0arch"
+  done
+
+  for dom0arch in $dom0arches; do
+
 eval "
 arch_runvars=\"\$ARCH_RUNVARS_$dom0arch\"
 "
-- 
2.20.1

Re: [PATCH v4 08/11] xsm: drop generic event channel labeling exclusion

[Daniel P. Smith]

On 9/9/21 11:35 AM, Jan Beulich wrote:
> On 03.09.2021 21:06, Daniel P. Smith wrote:
>> The internal define flag is not used by any XSM module, removing the #ifdef
>> leaving the generic event channel labeling as always present.
> 
> Already on v2 I did ask
> 
> "I'm not fully convinced of this removal: Does it get in the way of
>  anything?"
> 
> I have no record of getting reply, so I'm still wondering.

I can't find any email record of it but I know I made this change
because of a request to drop XSM_NEED_GENERIC_EVTCHN_SSID since it is
completely unused. Honestly I am not concerned on whether this
completely unused field is kept or not that is behind a flag that is
never set but it clearly is concerning for you, so I will just drop this
for now.

v/r,
dps

[PATCH 3/3] tools/libxl: Only allocate 64 bytes for RSDP

[Kevin Stefanov]

RSDP's size is 64 bytes and later in the function, its buffer is
hardcoded to be 64 bytes long. Don't bother to allocate a whole page.

Signed-off-by: Kevin Stefanov 
---
CC: Andrew Cooper 
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony PERARD 
---
 tools/libs/light/libxl_x86_acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libs/light/libxl_x86_acpi.c 
b/tools/libs/light/libxl_x86_acpi.c
index 0a82e7cacd..2aea1eca31 100644
--- a/tools/libs/light/libxl_x86_acpi.c
+++ b/tools/libs/light/libxl_x86_acpi.c
@@ -183,7 +183,7 @@ int libxl__dom_load_acpi(libxl__gc *gc,
 goto out;
 }
 
-config.rsdp = (unsigned long)libxl__malloc(gc, libxl_ctxt.page_size);
+config.rsdp = (unsigned long)libxl__malloc(gc, 64);
 config.infop = (unsigned long)libxl__malloc(gc, libxl_ctxt.page_size);
 /* Pages to hold ACPI tables */
 acpi_pages =  libxl__malloc(gc, (NUM_ACPI_PAGES + 1) *
-- 
2.25.1

[PATCH 2/3] tools/libxl: Correctly aligned buffer for ACPI tables

[Kevin Stefanov]

The pointer resulting from libxl__malloc() has no explicit alignment.
As an implementation detail, it has 16-byte alignment.

When this buffer is used by libacpi aligning ACPI tables to greater
than 16 does not work correctly.  This causes the FACS to not be
64-byte aligned when the ACPI tables are copied into guest memory.

Align the ACPI tables buffer to a page, to match the alignment
inside guest memory. The buffer is already one page too large,
presumably intended for this purpose originally.

Fixes: 14c0d328da2b ("libxl/acpi: Build ACPI tables for HVMlite guests")
Signed-off-by: Kevin Stefanov 
---
CC: Andrew Cooper 
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony PERARD 
---
 tools/libs/light/libxl_x86_acpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libs/light/libxl_x86_acpi.c 
b/tools/libs/light/libxl_x86_acpi.c
index 3eca1c7a9f..0a82e7cacd 100644
--- a/tools/libs/light/libxl_x86_acpi.c
+++ b/tools/libs/light/libxl_x86_acpi.c
@@ -193,6 +193,7 @@ int libxl__dom_load_acpi(libxl__gc *gc,
  * Set up allocator memory.
  * Start next to acpi_info page to avoid fracturing e820.
  */
+acpi_pages = (void *)ROUNDUP((unsigned long)acpi_pages, 
libxl_ctxt.page_shift);
 libxl_ctxt.alloc_base_paddr = ACPI_INFO_PHYSICAL_ADDRESS +
 libxl_ctxt.page_size;
 libxl_ctxt.alloc_base_vaddr = libxl_ctxt.alloc_currp =
-- 
2.25.1

[PATCH 0/3] Fix alignment of FACS in guests

[Kevin Stefanov]

When booting Xen as a PVH guest, it currently complains:

  (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:b004,1:0], pm1x_evt[1:b000,1:0]
  (XEN) ACPI: FACS is not 64-byte aligned: 0xfc001010
  (XEN) ACPI: wakeup_vec[fc00101c], vec_size[20]
  (XEN) ACPI: Local APIC address 0xfee0

This is caused by several bugs in the toolstack whilst writing ACPI
tables.

Kevin Stefanov (3):
  tools/libacpi: Use 64-byte alignment for FACS
  tools/libxl: Correctly aligned buffer for ACPI tables
  tools/libxl: Only allocate 64 bytes for RSDP

 tools/libacpi/build.c | 2 +-
 tools/libs/light/libxl_x86_acpi.c | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
2.25.1

[PATCH 1/3] tools/libacpi: Use 64-byte alignment for FACS

[Kevin Stefanov]

The spec requires 64-byte alignment, not 16.

Signed-off-by: Kevin Stefanov 
---
CC: Jan Beulich 
CC: Andrew Cooper 

Note: This does not fix the FACS alignment inside guests yet. See next
patch.
---
 tools/libacpi/build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index a61dd5583a..fe2db66a62 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -532,7 +532,7 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
  * Fill in high-memory data structures, starting at @buf.
  */
 
-facs = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_facs), 16);
+facs = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_facs), 64);
 if (!facs) goto oom;
 memcpy(facs, &Facs, sizeof(struct acpi_20_facs));
 
-- 
2.25.1

Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH v2 1/3] stubdom: fix build with disabled 
pv-grub"):
> On 09.09.21 15:23, Ian Jackson wrote:
> > How about "pv-grub-maybe" ?  Or something.
> 
> What about "pv-grub-if-enabled"?

Fine by me.

> And could that be done when committing, or should I send another round?

Please do send another round (sorry).

Thanks,
Ian.

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

[osstest service owner]

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

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  2e2e22c7d50392fa5cced3e0334b217426f48b7a
baseline version:
 xen  56abcf1a58bdaef18579cf2ce8645c8c72a2b749

Last test of basis   164891  2021-09-08 17:01:44 Z0 days
Testing same since   164912  2021-09-09 12:01:41 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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
   56abcf1a58..2e2e22c7d5  2e2e22c7d50392fa5cced3e0334b217426f48b7a -> smoke

Re: [PATCH v4 09/11] silo: remove circular xsm hook call

[Jan Beulich]

On 03.09.2021 21:06, Daniel P. Smith wrote:
> SILO implements a few XSM hooks to extended the decision logic beyond
> what is defined in the dummy/default policy. For each of the hooks, it
> falls back to the dummy/default policy. The fall back is done a slight
> round-about way. This commit makes the direct call to the default policy's
> logic, xsm_default_action().

Again it's not clear to me what you're finding wrong here. The way it's
done is not as direct as it could be, but going through the extra layer
allows the functions to document things at the same time. You lose not
only that documentation, but also ...

> @@ -43,7 +44,7 @@ static int silo_evtchn_unbound(struct domain *d1, struct 
> evtchn *chn,
>  else
>  {
>  if ( silo_mode_dom_check(d1, d2) )
> -rc = xsm_evtchn_unbound(d1, chn, id2);
> +rc = xsm_default_action(XSM_TARGET, current->domain, d1);

... will need to sync changes to the dummy xsm_evtchn_unbound(), no
matter how unlikely such may be, back to here. This would be quite
easy to forget.

But maybe I'm overlooking something where how things are really gets in
the way of something you mean to do in the remaining two patches (or
later)?

>  static int silo_grant_copy(struct domain *d1, struct domain *d2)
>  {
>  if ( silo_mode_dom_check(d1, d2) )
> -return xsm_grant_copy(d1, d2);
> +return xsm_default_action(XSM_HOOK, d1, d2);
>  return -EPERM;
>  }
>  
> @@ -86,14 +87,14 @@ static int silo_argo_register_single_source(const struct 
> domain *d1,
>  const struct domain *d2)
>  {
>  if ( silo_mode_dom_check(d1, d2) )
> -return xsm_argo_register_single_source(d1, d2);
> +return 0;
>  return -EPERM;
>  }
>  
>  static int silo_argo_send(const struct domain *d1, const struct domain *d2)
>  {
>  if ( silo_mode_dom_check(d1, d2) )
> -return xsm_argo_send(d1, d2);
> +return 0;
>  return -EPERM;
>  }

This would then also avoid introducing the anomaly observed by Andrew here.
And in fact the Argo dummy functions may be a good example where a change
might happen down the road - them being all empty doesn't seem quite right
to me.

Jan

Re: [PATCH v4 08/11] xsm: drop generic event channel labeling exclusion

[Jan Beulich]

On 03.09.2021 21:06, Daniel P. Smith wrote:
> The internal define flag is not used by any XSM module, removing the #ifdef
> leaving the generic event channel labeling as always present.

Already on v2 I did ask

"I'm not fully convinced of this removal: Does it get in the way of
 anything?"

I have no record of getting reply, so I'm still wondering.

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -122,13 +122,11 @@ struct evtchn
>  
>  #ifdef CONFIG_XSM
>  union {
> -#ifdef XSM_NEED_GENERIC_EVTCHN_SSID
>  /*
>   * If an XSM module needs more space for its event channel context,
>   * this pointer stores the necessary data for the security server.
>   */
>  void *generic;
> -#endif

I don't consider this any better than what you had originally: Then
you've removed everything inside the #ifdef as well. Now you keep
it and drop just the #ifdef, exposing the field universally (as long
as XSM is set) despite Flask's 32-bit only field being enough for
all practical purposes.

What is there demonstrates what the original intentions were. It's
easy enough to put back if needed in the future, but I think it's
even easier to simply leave as is.

Jan

[PATCH] x86: correct asm() constraints when dealing with immediate selector values

[Jan Beulich]

asm() constraints need to fit both the intended insn(s) which the
respective operands are going to be used with as well as the actual kind
of value specified. "m" (alone) together with a constant, however, leads
to gcc saying

error: memory input  is not directly addressable

while clang complains

error: invalid lvalue in asm input for constraint 'm'

And rightly so - in order to access a memory operand, an address needs
to be specified to the insn. In some cases it might be possible for a
compiler to synthesize a memory operand holding the requested constant,
but I think any solution there would have sharp edges.

If "m" alone doesn't work with constants, it is at best pointless (and
perhaps misleading or even risky - the compiler might decide to actually
pick "m" and not try very hard to find a suitable register) to specify
it alongside "r".

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -736,7 +736,7 @@ void __init detect_zen2_null_seg_behavio
uint64_t base;
 
wrmsrl(MSR_FS_BASE, 1);
-   asm volatile ( "mov %0, %%fs" :: "rm" (0) );
+   asm volatile ( "mov %0, %%fs" :: "r" (0) );
rdmsrl(MSR_FS_BASE, base);
 
if (base == 0)
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -248,7 +248,7 @@ void do_double_fault(struct cpu_user_reg
 
 console_force_unlock();
 
-asm ( "lsll %1, %0" : "=r" (cpu) : "rm" (PER_CPU_SELECTOR) );
+asm ( "lsll %1, %0" : "=r" (cpu) : "r" (PER_CPU_SELECTOR) );
 
 /* Find information saved during fault and dump it to the console. */
 printk("*** DOUBLE FAULT ***\n");

[linux-linus test] 164890: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-examine   6 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332
 test-amd64-i386-libvirt   7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-libvirt-xsm   7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-xl7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332
 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-i386-xl-raw7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-freebsd10-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332
 test-amd64-i386-xl-pvshim 7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-freebsd10-i386  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-xl-shadow 7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332
 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-coresched-i386-xl  7 xen-install  fail REGR. vs. 152332
 test-arm64-arm64-xl-seattle   8 xen-boot fail REGR. vs. 152332
 test-arm64-arm64-xl-credit1  13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-libvirt-xsm 13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-xl  13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-xl-credit2  13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-xl-xsm  13 debian-fixup fail REGR. vs. 152332
 test-arm64-arm64-examine  8 reboot   fail REGR. vs. 152332

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  8 xen-boot fail in 164879 pass in 164890
 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail pass in 164879
 test-amd64-amd64-xl-pvshim   22 guest-start/debian.repeat  fail pass in 164879

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 152332
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 152332
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass

[PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37

[Jan Beulich]

While LLVM's lld is supposed to be a drop-in replacement for GNU ld [1],
it appears to not understand quoted section names as operands to e.g.
ADDR(). Therefore the original workaround broke the build in
environments where ld is actually LLVM's, like on FreeBSD.

Fixes: 58ad654ebce7 ("x86: work around build issue with GNU ld 2.37")
Reported-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

[1] https://lld.llvm.org/
---
I haven't been able to find an environment where I could actually try
with lld (ld.lld); all testing was with GNU ld (ld.bfd).

--- a/.gitignore
+++ b/.gitignore
@@ -306,6 +306,7 @@
 xen/.config.old
 xen/.xen.elf32
 xen/System.map
+xen/arch/x86/.check.*
 xen/arch/x86/asm-macros.i
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/boot/cmdline.S
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -92,10 +92,16 @@ efi-$(CONFIG_PV_SHIM_EXCLUSIVE) :=
 
 ifneq ($(build_id_linker),)
 notes_phdrs = --notes
+# Determine whether to engage a workaround for GNU ld 2.37.
+build-id-ld-good = $(shell echo 'void test(void) {}' \
+   | $(CC) $(XEN_CFLAGS) -o .check.o -c -x c - 
2>.check.err \
+   && $(LD) -T check.lds -o .check.elf .check.o 
2>>.check.err \
+   && echo y)
 else
 ifeq ($(CONFIG_PVH_GUEST),y)
 notes_phdrs = --notes
 endif
+build-id-ld-good := y
 endif
 
 ifdef CONFIG_LIVEPATCH
@@ -291,6 +297,10 @@ $(BASEDIR)/include/asm-x86/asm-macros.h:
$(call move-if-changed,$@.new,$@)
 
 efi.lds: AFLAGS-y += -DEFI
+xen.lds: Makefile
+ifneq ($(build-id-ld-good),y)
+xen.lds: CFLAGS-y += -DQUOTE_SECTION_NAMES
+endif
 xen.lds efi.lds: xen.lds.S
$(CPP) -P $(call cpp_flags,$(a_flags)) -MQ $@ -o $@ $<
 
@@ -302,7 +312,7 @@ hweight.o: CFLAGS-y += $(foreach reg,cx
 
 .PHONY: clean
 clean::
-   rm -f *.lds *.new boot/*.o boot/*~ boot/core boot/mkelf32
+   rm -f ???.lds *.new .check.* boot/*.o boot/*~ boot/core boot/mkelf32
rm -f asm-macros.i $(BASEDIR)/include/asm-x86/asm-macros.*
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d $(BASEDIR)/.xen.elf32
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/mkreloc
--- /dev/null
+++ b/xen/arch/x86/check.lds
@@ -0,0 +1,11 @@
+/*
+ * Minimal linker script used to check whether the linker understands section
+ * names containing a dash (like in .note.gnu.build-id) inside ADDR() and alike
+ * without quoting them.
+ */
+OUTPUT_FORMAT("elf64-x86-64")
+OUTPUT_ARCH("i386:x86-64")
+SECTIONS
+{
+ .text-1 : AT(ADDR(.text-1)) { *(.text) }
+}
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -18,7 +18,12 @@ ENTRY(efi_start)
 #else /* !EFI */
 
 #define FORMAT "elf64-x86-64"
+
+#if defined(QUOTE_SECTION_NAMES) /* GNU ld 2.37 workaround */
 #define DECL_SECTION(x) x : AT(ADDR(#x) - __XEN_VIRT_START)
+#else
+#define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START)
+#endif
 
 ENTRY(start_pa)
 

[XEN PATCH v2] build: add --full to version.sh to guess $(XEN_FULLVERSION)

[Anthony PERARD]

Running $(MAKE) like that in a $(shell ) while parsing the Makefile
doesn't work reliably. In some case, make will complain with
"jobserver unavailable: using -j1.  Add '+' to parent make rule.".
Also, it isn't possible to distinguish between the output produced by
the target "xenversion" and `make`'s own output.

Instead of running make, this patch "improve" `version.sh` to try to
guess the output of `make xenversion`.

In order to have version.sh works in more scenario, it will use
XEN_EXTRAVERSION and XEN_VENDORVERSION from the environment when
present. As for the cases were those two variables are overridden by a
make command line arguments, we export them when invoking version.sh
via a new $(XEN_FULLVERSION) macro.

That should hopefully get us to having ./version.sh returning the same
value that `make xenversion` would.

This fix GitLab CI's build job "debian-unstable-gcc-arm64".

Signed-off-by: Anthony PERARD 
---
v2:
- use $(SHELL) to execute ./version.sh
- get XEN_EXTRAVERSION from the environment if exist
- use XEN_VENDORVERSION when exist in the environment
- introduce a new macro $(XEN_FULLVERSION) whose jobs is to export
  $(XEN_EXTRAVERSION) and $(XEN_VENDORVERSION) in cases where those
  are overridden by command line argument of make.
  (we can't just use make's "export" because it doesn't work when
  parsing the makefile which is when $(shell ) get's executed for
  POLICY_FILENAME, so it wouldn't work when running `make -C
  tools/flask/policy XEN_VENDORVERSION=-os`.)
---
 tools/Rules.mk |  5 +
 tools/flask/policy/Makefile.common |  2 +-
 version.sh | 18 +-
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 2907ed2d3972..b022da3336c4 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -6,6 +6,11 @@ all:
 -include $(XEN_ROOT)/config/Tools.mk
 include $(XEN_ROOT)/Config.mk
 
+XEN_FULLVERSION=$(shell env \
+XEN_EXTRAVERSION=$(XEN_EXTRAVERSION) \
+XEN_VENDORVERSION=$(XEN_VENDORVERSION) \
+$(SHELL) $(XEN_ROOT)/version.sh --full $(XEN_ROOT)/xen/Makefile)
+
 export _INSTALL := $(INSTALL)
 INSTALL = $(XEN_ROOT)/tools/cross-install
 
diff --git a/tools/flask/policy/Makefile.common 
b/tools/flask/policy/Makefile.common
index bea5ba4b6a40..e5ed58200e75 100644
--- a/tools/flask/policy/Makefile.common
+++ b/tools/flask/policy/Makefile.common
@@ -35,7 +35,7 @@ OUTPUT_POLICY ?= $(BEST_POLICY_VER)
 #
 
 
-POLICY_FILENAME = $(FLASK_BUILD_DIR)/xenpolicy-$(shell $(MAKE) -C 
$(XEN_ROOT)/xen xenversion --no-print-directory)
+POLICY_FILENAME = $(FLASK_BUILD_DIR)/xenpolicy-$(XEN_FULLVERSION)
 POLICY_LOADPATH = /boot
 
 # List of policy versions supported by the hypervisor
diff --git a/version.sh b/version.sh
index e894ee7e0469..c6a5692c1982 100755
--- a/version.sh
+++ b/version.sh
@@ -1,5 +1,21 @@
 #!/bin/sh
 
+opt_full=false
+while [ $# -gt 1 ]; do
+case "$1" in
+--full) opt_full=true ;;
+*) break ;;
+esac
+shift
+done
+
 MAJOR=`grep "export XEN_VERSION" $1 | sed 's/.*=//g' | tr -s " "`
 MINOR=`grep "export XEN_SUBVERSION" $1 | sed 's/.*=//g' | tr -s " "`
-printf "%d.%d" $MAJOR $MINOR
+
+if $opt_full; then
+extraversion=$(grep "export XEN_EXTRAVERSION" $1 | sed 's/^.* ?=\s\+//; 
s/\$([^)]*)//g; s/ //g')
+: ${XEN_EXTRAVERSION:=${extraversion}${XEN_VENDORVERSION}}
+else
+unset XEN_EXTRAVERSION
+fi
+printf "%d.%d%s" $MAJOR $MINOR $XEN_EXTRAVERSION
-- 
Anthony PERARD

Re: Disable IOMMU in Dom0

[Roman Skakun]

Hi Julien,

Thanks for the clarification!

I aim towards to prepare implementation for upstream to disable SWIOTLB for 
IOMMU-protected devices in Dom0.
To provide this functionality need to add additional binding for each protected 
device in device-tree.
After this step, I will also prepare the patch to make ensure that ballooning 
code prepares all allocations below 4GB.

We are going to prepare this functionality only for device-tree based system 
configurations.
We don't have resources to support ACPI configuration.

Would you be ok with upstreaming only device-tree configuration?

Cheers,
Roman

From: Julien Grall 
Sent: Wednesday, September 1, 2021 1:22 PM
To: Roman Skakun ; Stefano Stabellini 

Cc: xen-devel@lists.xenproject.org ; Bertrand 
Marquis ; Andrii Anisov ; 
Roman Skakun ; Oleksandr Tyshchenko 

Subject: Re: Disable IOMMU in Dom0

Hi Roman

On 01/09/2021 10:59, Roman Skakun wrote:
>> If you have a setup  where Dom0 is not 1:1 mapped (which is not currently
>> possible with upstream  Xen but it is possible with cache coloring) and
>> uses the IOMMU to make  device DMA work like regular DomUs, then passing
>> XENFEAT_not_direct_mapped  to Linux would make it work. Without
>> XENFEAT_not_direct_mapped,  Linux would try to use swiotlb-xen which has
>> code that relies on  Linux being 1:1 mapped to work properly.
>
> I'm using 1:1 Dom0.
> According to your patch series, xen-swiotlb fops will be applied for all
> devices
> because XENFEAT_direct_mapped is active, as shown here:
> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14/source/arch/arm64/mm/dma-mapping.c*L56__;Iw!!GF_29dbcQIUBPA!i7I0DxCbP4ibLDwzRkeFkgRQbKh-fVD9McLqabG1TzZs9smOVBeowPS_Iv_mvn3O$
>  [elixir[.]bootlin[.]com]
>   [elixir[.]bootlin[.]com]>
>
> I agreed, that xen-swiotlb should work correctly, but in my case, I
> retrieved MFN here:
> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v5.14/source/drivers/xen/swiotlb-xen.c*L366__;Iw!!GF_29dbcQIUBPA!i7I0DxCbP4ibLDwzRkeFkgRQbKh-fVD9McLqabG1TzZs9smOVBeowPS_IgZgXPjC$
>  [elixir[.]bootlin[.]com]
>   [elixir[.]bootlin[.]com]>
> which is greater than 32bit and xen-swiotlb tries to use bounce buffer
> as expected.
> It can lead to decrease a performance because I have a long buffer ~4MB.
>
> I thought, that we can disable swiotlb fops for devices which are
> controlled by IOMMU.

Yes you can disable swiotlb for devices which are controlled by the
IOMMU. But this will not make your problem disappear, it simply hides
until it bites you in a more subttle way.

 From what you wrote, you have a 32-bit DMA capable. So you always need
to have an address below 4GB. For foreign mapping, there is no guarantee
the Guest Physical Address will actually be below 4GB.

Today, the ballooning code only ask Linux to steal *a* RAM page for
mapping the foreign page. This may or may not be below 4GB depending on
how you assigned the RAM to dom0 (IIRC you had some RAM above 4GB).

But that's the current behavior. One of your work colleague is looking
at avoid to steal RAM page to avoid exhausting the memory. So foreign
mapping may end up to be a lot higher in memory.

IOW, you will need to be able to bounce the DMA buffer for your device.
If you want to avoid bouncing, the proper way would be to rework the
ballonning code so pages are allocated below 4GB.

Cheers,

--
Julien Grall

Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub

[Juergen Gross]

On 09.09.21 15:23, Ian Jackson wrote:

Juergen Gross writes ("[PATCH v2 1/3] stubdom: fix build with disabled 
pv-grub"):

Today the build will fail if --disable-pv-grub as a parameter of
configure, as the main Makefile will unconditionally try to build a
32-bit pv-grub stubdom.

Fix that by introducing a pv-grub32 target in stubdom/Makefile taking
care of this situation.


I approve of this whole series, with one resrvation:

I think the name "pv-grub32" for this target is confusing.  It's not
really specifically 32-bit.  The difference between the targets
"pv-grub32" and "pv-grub" is that "pv-grub32" is unconditionally
built but might mean nothing; it has a conditional dependency on
"pv-grub" which is conditionally built but always implies the actual
build.

I don't think the suffix "32" really conveys this :-).

How about "pv-grub-maybe" ?  Or something.


What about "pv-grub-if-enabled"?

And could that be done when committing, or should I send another round?



You can put my ack on patches 2 and 3 right away.


Thanks,


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v1 12/14] arm/libxl: Emulated PCI device tree node in libxl

[Julien Grall]

On 20/08/2021 17:03, Rahul Singh wrote:

Hi Julien,


Hi Rahul,


On 19 Aug 2021, at 2:00 pm, Julien Grall  wrote:

Hi Rahul,

On 19/08/2021 13:02, Rahul Singh wrote:

libxl will create an emulated PCI device tree node in the device tree to
enable the guest OS to discover the virtual PCI during guest boot.
Emulated PCI device tree node will only be created when there is any
device assigned to guest.
A new area has been reserved in the arm guest physical map at
which the VPCI bus is declared in the device tree (reg and ranges
parameters of the node).
Signed-off-by: Rahul Singh 
---
  tools/libs/light/libxl_arm.c  | 109 ++
  tools/libs/light/libxl_types.idl  |   1 +
  tools/xl/xl_parse.c   |   2 +
  xen/include/public/arch-arm.h |  11 +++
  xen/include/public/device_tree_defs.h |   1 +
  5 files changed, 124 insertions(+)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index e3140a6e00..a091e97e76 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -269,6 +269,58 @@ static int fdt_property_regs(libxl__gc *gc, void *fdt,
  return fdt_property(fdt, "reg", regs, sizeof(regs));
  }
  +static int fdt_property_values(libxl__gc *gc, void *fdt,
+const char *name, unsigned num_cells, ...)
+{
+uint32_t prop[num_cells];
+be32 *cells = &prop[0];
+int i;
+va_list ap;
+uint32_t arg;
+
+va_start(ap, num_cells);
+for (i = 0 ; i < num_cells; i++) {
+arg = va_arg(ap, uint32_t);
+set_cell(&cells, 1, arg);
+}
+va_end(ap);
+
+return fdt_property(fdt, name, prop, sizeof(prop));
+}
+
+static int fdt_property_vpci_ranges(libxl__gc *gc, void *fdt,
+unsigned addr_cells,
+unsigned size_cells,
+unsigned num_regs, ...)
+{
+uint32_t regs[num_regs*((addr_cells*2)+size_cells+1)];
+be32 *cells = ®s[0];
+int i;
+va_list ap;
+uint64_t arg;
+
+va_start(ap, num_regs);
+for (i = 0 ; i < num_regs; i++) {
+/* Set the memory bit field */
+arg = va_arg(ap, uint64_t);
+set_cell(&cells, 1, arg);
+
+/* Set the vpci bus address */
+arg = addr_cells ? va_arg(ap, uint64_t) : 0;
+set_cell(&cells, addr_cells , arg);
+
+/* Set the cpu bus address where vpci address is mapped */
+set_cell(&cells, addr_cells, arg);
+
+/* Set the vpci size requested */
+arg = size_cells ? va_arg(ap, uint64_t) : 0;
+set_cell(&cells, size_cells,arg);
+}
+va_end(ap);
+
+return fdt_property(fdt, "ranges", regs, sizeof(regs));
+}
+
  static int make_root_properties(libxl__gc *gc,
  const libxl_version_info *vers,
  void *fdt)
@@ -668,6 +720,57 @@ static int make_vpl011_uart_node(libxl__gc *gc, void *fdt,
  return 0;
  }
  +static int make_vpci_node(libxl__gc *gc, void *fdt,
+const struct arch_info *ainfo,
+struct xc_dom_image *dom)
+{
+int res;
+const uint64_t vpci_ecam_base = GUEST_VPCI_ECAM_BASE;
+const uint64_t vpci_ecam_size = GUEST_VPCI_ECAM_SIZE;
+const char *name = GCSPRINTF("pcie@%"PRIx64, vpci_ecam_base);
+
+res = fdt_begin_node(fdt, name);
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "pci-host-ecam-generic");
+if (res) return res;
+
+res = fdt_property_string(fdt, "device_type", "pci");
+if (res) return res;
+
+res = fdt_property_regs(gc, fdt, GUEST_ROOT_ADDRESS_CELLS,
+GUEST_ROOT_SIZE_CELLS, 1, vpci_ecam_base, vpci_ecam_size);
+if (res) return res;
+
+res = fdt_property_values(gc, fdt, "bus-range", 2, 0,17);


AFAICT, the "bus-range" is optional. Can you explain why we need it?


We need it to implement the function pci_ecam_map_bus().


Ok. Then why next question is what does the 17 mean? Is it tie to how we
implement the vPCI in Xen or the region we reserved?

[...]




+
  if (b_info->type != LIBXL_DOMAIN_TYPE_PV)
  return;
  diff --git a/tools/libs/light/libxl_types.idl 
b/tools/libs/light/libxl_types.idl
index 3f9fff653a..78b1ddf0b8 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -644,6 +644,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
 ("vuart", libxl_vuart_type),
+   ("vpci", libxl_defbool),


Any new addition in the structure should be accompanied with a LIBXL_HAVE_* in 
the libxl.h header.


OK.



])),
  ("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool),
])),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 17dddb4cd5..ffafbeffb4 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1497,6 +1497,8

Re: [PATCH v1 11/14] xen/arm: Enable the existing x86 virtual PCI support for ARM.

[Julien Grall]

Hi Rahul,

On 19/08/2021 13:02, Rahul Singh wrote:

The existing VPCI support available for X86 is adapted for Arm.
When the device is added to XEN via the hyper call
“PHYSDEVOP_pci_device_add”, VPCI handler for the config space
access is added to the Xen to emulate the PCI devices config space.

A MMIO trap handler for the PCI ECAM space is registered in XEN
so that when guest is trying to access the PCI config space,XEN
will trap the access and emulate read/write using the VPCI and
not the real PCI hardware.

Signed-off-by: Rahul Singh 
---
  xen/arch/arm/Makefile |  1 +
  xen/arch/arm/domain.c |  4 ++
  xen/arch/arm/vpci.c   | 96 +++
  xen/arch/arm/vpci.h   | 37 ++
  xen/drivers/passthrough/pci.c |  7 +++
  xen/drivers/vpci/Makefile |  3 +-
  xen/drivers/vpci/header.c |  2 +
  xen/include/asm-arm/domain.h  |  5 +-
  xen/include/asm-arm/pci.h |  8 +++
  xen/include/public/arch-arm.h |  4 ++
  10 files changed, 165 insertions(+), 2 deletions(-)
  create mode 100644 xen/arch/arm/vpci.c
  create mode 100644 xen/arch/arm/vpci.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 0e14a5e5c8..7cdce684a4 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ obj-y += platforms/
  endif
  obj-$(CONFIG_TEE) += tee/
  obj-$(CONFIG_HAS_PCI) += pci/
+obj-$(CONFIG_HAS_VPCI) += vpci.o
  
  obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o

  obj-y += bootfdt.init.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 19c756ac3d..d99c653626 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -40,6 +40,7 @@
  #include 
  
  #include "vuart.h"

+#include "vpci.h"


Please order the includes alphabetically. So this one should go before 
"vuart.h".


  
  DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
  
@@ -767,6 +768,9 @@ int arch_domain_create(struct domain *d,

  if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) )
  goto fail;
  
+if ( (rc = domain_vpci_init(d)) != 0 )

+goto fail;
+
  return 0;
  
  fail:

diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
new file mode 100644
index 00..da8b1ca13c
--- /dev/null
+++ b/xen/arch/arm/vpci.c
@@ -0,0 +1,96 @@
+/*
+ * xen/arch/arm/vpci.c
+ * Copyright (c) 2021 Arm Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 


NIT: Please add a newline between generic and arch specific includes.


+#include 
+
+/* Do some sanity checks. */
+static bool vpci_mmio_access_allowed(unsigned int reg, unsigned int len)
+{
+/* Check access size. */
+if ( len != 1 && len != 2 && len != 4 && len != 8 )
+return false;
You will allow all the possible value of len (this is coming from the 
HW). So I feels this is a bit too much to check for every I/O to the vPCI.


If you really want to keep the check then you can simply check that len 
is < 8 because the two callers compute it with (1 << S). So there is no 
way to set it 3, 5, 6 and 7.



+
+/* Check that access is size aligned. */
+if ( (reg & (len - 1)) )
+return false;
+
+return true;
+}
+
+static int vpci_mmio_read(struct vcpu *v, mmio_info_t *info,
+  register_t *r, void *p)
+{
+unsigned int reg;
+pci_sbdf_t sbdf;
+uint32_t data = 0;
+unsigned int size = 1U << info->dabt.size;
+
+sbdf.sbdf = (((info->gpa) & 0x0000) >> 12);
+reg = (((info->gpa) & 0x0ffc) | (info->gpa & 3));


This logic is the same as below in vpci_mmio_write(). So I think you 
want to provide an helper because this is not trivial to read.


Also, for the first line, I think you can re-use MMCFG_BDF() from the 
x86 code. For the second line, I would define the value so it is clearer 
to understand that they mean (although & 3 is fine to me) .



+
+if ( !vpci_mmio_access_allowed(reg, size) )
+return 1;
So, you will a guest will read 0 if the access is unaligned. This seems 
an odd behavior given this is not an allowed access. AFAIU, the HW would 
likely trow a data abort because you can't do unalign access on 
uncachable memory. So I think we should return 0 here to let the MMIO 
handler inject a data abort.



+
+data = vpci_read(sbdf, reg, size);


So in vpci_mmio_access_allowed(), you will allow a guest to read a 
64-bit value. But... vpci_read() will return a 32-bit value.


Looking at the x86 code, they have a second call to vpci_read() to 
handle the top 32-bit. Any reason why this was not implemented

Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub

[Ian Jackson]

Juergen Gross writes ("[PATCH v2 1/3] stubdom: fix build with disabled 
pv-grub"):
> Today the build will fail if --disable-pv-grub as a parameter of
> configure, as the main Makefile will unconditionally try to build a
> 32-bit pv-grub stubdom.
> 
> Fix that by introducing a pv-grub32 target in stubdom/Makefile taking
> care of this situation.

I approve of this whole series, with one resrvation:

I think the name "pv-grub32" for this target is confusing.  It's not
really specifically 32-bit.  The difference between the targets
"pv-grub32" and "pv-grub" is that "pv-grub32" is unconditionally
built but might mean nothing; it has a conditional dependency on
"pv-grub" which is conditionally built but always implies the actual
build.

I don't think the suffix "32" really conveys this :-).

How about "pv-grub-maybe" ?  Or something.

You can put my ack on patches 2 and 3 right away.

Thanks,
Ian.

Re: [PATCH 8/9] vpci/header: Reset the command register when adding devices

[Oleksandr Andrushchenko]

On 09.09.21 15:47, Jan Beulich wrote:
> On 09.09.2021 14:42, Oleksandr Andrushchenko wrote:
>> On 09.09.21 14:53, Jan Beulich wrote:
>>> On 09.09.2021 13:48, Oleksandr Andrushchenko wrote:
 On 09.09.21 12:21, Jan Beulich wrote:
> For the bit in question, where the goal appears to be to have hardware
> hold the OR of guest and host values, an approach similar to that used
> for some of the MSI / MSI-X bits might be chosen: Maintain guest and
> host bits in software, and update hardware (at least) when the
> effective resulting value changes. A complicating fact here is, though,
> that unlike for the MSI / MSI-X bits here Dom0 (pciback or its PCI
> susbstem) may also have a view on what the setting ought to be.
 The bigger question here is what can we take as the reference for INTx
 bit, e.g. if Dom0 didn't enable/configured the device being passed through
 than its COMMAND register may still be in after reset state and IMO there 
 is
 no guarantee it has the values we can say are "as host wants them"
>>> In the absence of Dom0 controlling the device, I think we ought to take
>>> Xen's view as the "host" one.
>> Agree
>>>Which will want the bit set at least as
>>> long as either MSI or MSI-X is enabled for the device.
>> But what is the INTx relation to MSI/MSI-X here?
> Devices are not supposed to signal interrupts two different ways at a
> time. They may enable only one - pin based, MSI, or MSI-X.

Ok, so I see that we can partially emulate the command register as:

static void guest_cmd_write(const struct pci_dev *pdev, unsigned int reg,
     uint32_t cmd, void *data)
{
     /* TODO: Add proper emulation for all bits of the command register. */

     if ( (cmd & PCI_COMMAND_INTX_DISABLE) == 0 )
     {
     /*
  * Guest wants to enable INTx. It can't be enabled if:
  *  - host has INTx disabled
  *  - MSI/MSI-X enabled
  */
     if ( pdev->vpci->msi->enabled )
     cmd |= PCI_COMMAND_INTX_DISABLE;
     else
     {
     uint16_t current_cmd = pci_conf_read16(pdev->sbdf, reg);

     if ( current_cmd & PCI_COMMAND_INTX_DISABLE )
     cmd |= PCI_COMMAND_INTX_DISABLE;
     }
     }

     cmd_write(pdev, reg, cmd, data);
}

and of course have grand TODO for the rest.

>
> Jan
>
Thank you,

Oleksandr

Re: [PATCH v1 02/14] xen/pci: solve compilation error on ARM with HAS_PCI enabled

[Julien Grall]

Hi,

On 19/08/2021 13:02, Rahul Singh wrote:

Compilation error is observed when HAS_PCI is enabled for ARM
architecture.

Add definition for arch_iommu_use_permitted() and
arch_pci_clean_pirqs().Implement dummy functions for pci_conf_read*() to
fix compilation error.

pci.c: In function ‘deassign_device’:
pci.c:849:49: error: implicit declaration of function ‘pci_to_dev’;
did you mean ‘dt_to_dev’? [-Werror=implicit-function-declaration]
 pci_to_dev(pdev));

pci.c:18: undefined reference to `pci_conf_read16’
pci.c:880: undefined reference to `arch_pci_clean_pirqs’
pci.c:1392: undefined reference to `arch_iommu_use_permitted'

Signed-off-by: Rahul Singh 
---
  xen/arch/arm/Makefile   |  1 +
  xen/arch/arm/pci/Makefile   |  2 +
  xen/arch/arm/pci/pci-access.c   | 61 +
  xen/arch/arm/pci/pci.c  | 32 +++
  xen/drivers/passthrough/arm/iommu.c |  5 +++
  xen/include/asm-arm/pci.h   | 33 ++--
  6 files changed, 131 insertions(+), 3 deletions(-)
  create mode 100644 xen/arch/arm/pci/Makefile
  create mode 100644 xen/arch/arm/pci/pci-access.c
  create mode 100644 xen/arch/arm/pci/pci.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 3d3b97b5b4..0e14a5e5c8 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -6,6 +6,7 @@ ifneq ($(CONFIG_NO_PLAT),y)
  obj-y += platforms/
  endif
  obj-$(CONFIG_TEE) += tee/
+obj-$(CONFIG_HAS_PCI) += pci/


This should go before platforms/ to keep the order alphabetically.


Cheers,

--
Julien Grall

[PATCH v2 3/3] tools: disable building qemu-trad per default

[Juergen Gross]

Using qemu-traditional as device model is deprecated for some time now.

So change the default for building it to "disable". This will affect
ioemu-stubdom, too, as there is a direct dependency between the two.

Today it is possible to use a PVH/HVM Linux-based stubdom as device
model. Additionally using ioemu-stubdom isn't really helping for
security, as it requires to run a very old and potentially buggy qemu
version in a PV domain. This is adding probably more security problems
than it is removing by using a stubdom.

Signed-off-by: Juergen Gross 
---
V2:
- new patch
---
 CHANGELOG.md |  3 +++
 stubdom/configure|  8 
 stubdom/configure.ac |  8 +---
 tools/configure  | 17 ++---
 tools/configure.ac   | 13 +
 5 files changed, 7 insertions(+), 42 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index e7107ac3de..e5ab49e779 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -18,6 +18,9 @@ The format is based on [Keep a 
Changelog](https://keepachangelog.com/en/1.0.0/)
or by passing "iommu=quarantine=scratch-page" on the hypervisor command 
line.
  - pv-grub stubdoms will no longer be built per default. In order to be able 
to use pv-grub
configure needs to be called with "--enable-pv-grub" as parameter.
+ - qemu-traditional based device models (both, qemu-traditional and 
ioemu-stubdom) will
+   no longer be built per default. In order to be able to use those, configure 
needs to
+   be called with "--enable-qemu-traditional" as parameter.
 
 ## [4.15.0 
UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.15.0)
 - TBD
 
diff --git a/stubdom/configure b/stubdom/configure
index df31532abb..07b709f998 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -2286,14 +2286,6 @@ fi
 # Check whether --enable-qemu-traditional was given.
 if test "${enable_qemu_traditional+set}" = set; then :
   enableval=$enable_qemu_traditional;
-else
-
-case "$host_cpu" in
-i[3456]86|x86_64)
-   enable_qemu_traditional="yes";;
-*) enable_qemu_traditional="no";;
-esac
-
 fi
 
 if test "x$enable_qemu_traditional" = "xyes"; then :
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index a07a1edae5..e20d99edac 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -27,13 +27,7 @@ AX_STUBDOM_DEFAULT_ENABLE([xenstorepvh-stubdom], 
[xenstorepvh])
 AX_STUBDOM_CONDITIONAL([vtpm-stubdom], [vtpm])
 AX_STUBDOM_CONDITIONAL([vtpmmgr-stubdom], [vtpmmgr])
 
-AC_ARG_ENABLE([qemu-traditional],,,[
-case "$host_cpu" in
-i[[3456]]86|x86_64)
-   enable_qemu_traditional="yes";;
-*) enable_qemu_traditional="no";;
-esac
-])
+AC_ARG_ENABLE([qemu-traditional])
 AS_IF([test "x$enable_qemu_traditional" = "xyes"], [
 qemu_traditional=y],[
 qemu_traditional=n
diff --git a/tools/configure b/tools/configure
index 33814b24b3..8bf8fe75b8 100755
--- a/tools/configure
+++ b/tools/configure
@@ -1502,8 +1502,8 @@ Optional Features:
   --disable-seabios   Disable SeaBIOS (default is ENABLED)
   --disable-golangDisable Go tools (default is ENABLED)
   --enable-qemu-traditional
-  Enable qemu traditional device model, (DEFAULT is on
-  for Linux or NetBSD x86, otherwise off)
+  Enable qemu traditional device model, (DEFAULT is
+  off)
   --enable-rombiosEnable ROMBIOS, (DEFAULT is on if qemu-traditional
   is enabled, otherwise off)
   --disable-ipxe  Enable in-tree IPXE, (DEFAULT is on if rombios is
@@ -4287,19 +4287,6 @@ LINUX_BACKEND_MODULES="`eval echo 
$LINUX_BACKEND_MODULES`"
 # Check whether --enable-qemu-traditional was given.
 if test "${enable_qemu_traditional+set}" = set; then :
   enableval=$enable_qemu_traditional;
-else
-
-case "$host_cpu" in
-i[3456]86|x86_64)
-   enable_qemu_traditional="yes";;
-*) enable_qemu_traditional="no";;
-esac
-case "$host_os" in
-freebsd*)
-   enable_qemu_traditional="no";;
-esac
-
-
 fi
 
 if test "x$enable_qemu_traditional" = "xyes"; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 6414fcbb44..a713fd34d6 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -120,18 +120,7 @@ AC_SUBST(LINUX_BACKEND_MODULES)
 
 AC_ARG_ENABLE([qemu-traditional],
 AS_HELP_STRING([--enable-qemu-traditional],
-   [Enable qemu traditional device model, (DEFAULT is on for 
Linux or NetBSD x86, otherwise off)]),,[
-case "$host_cpu" in
-i[[3456]]86|x86_64)
-   enable_qemu_traditional="yes";;
-*) enable_qemu_traditional="no";;
-esac
-case "$host_os" in
-freebsd*)
-   enable_qemu_traditional="no";;
-esac
-
-])
+   [Enable qemu traditional device model, (DEFAULT is off)]))
 AS_IF([test "x$enable_qemu_traditional" = "xyes"], [
 AC_DEFINE([HAVE_QEMU_TRADITIONAL], [1], [Qemu

[PATCH v2 0/3] disable building of pv-grub and qemu-trad per default

[Juergen Gross]

This is a first step of deprecating pv-grub and qemu-trad including
ioemu-stubdom. Switch the default to not building it.

Changes in V2:
- new patch 3
- added CHANGELOG.md entry in patch 2

Juergen Gross (3):
  stubdom: fix build with disabled pv-grub
  stubdom: disable building pv-grub
  tools: disable building qemu-trad per default

 CHANGELOG.md |  5 +
 Makefile |  4 ++--
 stubdom/Makefile | 13 +
 stubdom/configure| 16 ++--
 stubdom/configure.ac | 10 ++
 tools/configure  | 17 ++---
 tools/configure.ac   | 13 +
 7 files changed, 27 insertions(+), 51 deletions(-)

-- 
2.26.2

[PATCH v2 2/3] stubdom: disable building pv-grub

[Juergen Gross]

The stubdom based pv-grub is using a very outdated version of grub
(0.97) and should not be used any longer. Mainline grub has support for
PV guests for a long time now, so that should be used as a boot loader
of a PV domain.

So disable building pv-grub per default. In case someone really wants
to continue using it he/she can still use a pv-grub binary from an older
Xen version or manually enable building it via:

  configure --enable-pv-grub

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
V2:
- add CHANGELOG.md entry (Jan Beulich)
---
 CHANGELOG.md | 2 ++
 stubdom/configure| 8 ++--
 stubdom/configure.ac | 2 +-
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 22cfdb4298..e7107ac3de 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,8 @@ The format is based on [Keep a 
Changelog](https://keepachangelog.com/en/1.0.0/)
appearing in 4.12.2 and 4.11.4). Prior (4.13...4.15-like) behavior can be 
arranged for
either by enabling the IOMMU_QUARANTINE_SCRATCH_PAGE setting at build 
(configuration) time
or by passing "iommu=quarantine=scratch-page" on the hypervisor command 
line.
+ - pv-grub stubdoms will no longer be built per default. In order to be able 
to use pv-grub
+   configure needs to be called with "--enable-pv-grub" as parameter.
 
 ## [4.15.0 
UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.15.0)
 - TBD
 
diff --git a/stubdom/configure b/stubdom/configure
index aa48df986d..df31532abb 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -1342,7 +1342,7 @@ Optional Features:
   --enable-ioemu-stubdom  Build and install ioemu-stubdom
   --enable-c-stubdom  Build and install c-stubdom (default is DISABLED)
   --enable-caml-stubdom   Build and install caml-stubdom (default is DISABLED)
-  --disable-pv-grub   Build and install pv-grub (default is ENABLED)
+  --enable-pv-grubBuild and install pv-grub (default is DISABLED)
   --disable-xenstore-stubdom
   Build and install xenstore-stubdom (default is
   ENABLED)
@@ -2129,11 +2129,7 @@ fi
 else
 
 
-grub=y
-STUBDOM_TARGETS="$STUBDOM_TARGETS grub"
-STUBDOM_BUILD="$STUBDOM_BUILD pv-grub"
-STUBDOM_INSTALL="$STUBDOM_INSTALL install-grub"
-STUBDOM_UNINSTALL="$STUBDOM_UNINSTALL install-grub"
+grub=n
 
 
 fi
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index bd6f765929..a07a1edae5 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -21,7 +21,7 @@ m4_include([../m4/fetcher.m4])
 AX_STUBDOM_CONDITIONAL([ioemu-stubdom], [ioemu])
 AX_STUBDOM_DEFAULT_DISABLE([c-stubdom], [c])
 AX_STUBDOM_DEFAULT_DISABLE([caml-stubdom], [caml])
-AX_STUBDOM_DEFAULT_ENABLE([pv-grub], [grub])
+AX_STUBDOM_DEFAULT_DISABLE([pv-grub], [grub])
 AX_STUBDOM_DEFAULT_ENABLE([xenstore-stubdom], [xenstore])
 AX_STUBDOM_DEFAULT_ENABLE([xenstorepvh-stubdom], [xenstorepvh])
 AX_STUBDOM_CONDITIONAL([vtpm-stubdom], [vtpm])
-- 
2.26.2

[PATCH v2 1/3] stubdom: fix build with disabled pv-grub

[Juergen Gross]

Today the build will fail if --disable-pv-grub as a parameter of
configure, as the main Makefile will unconditionally try to build a
32-bit pv-grub stubdom.

Fix that by introducing a pv-grub32 target in stubdom/Makefile taking
care of this situation.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 Makefile |  4 ++--
 stubdom/Makefile | 13 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 96d32cfd50..5b5cef3e49 100644
--- a/Makefile
+++ b/Makefile
@@ -72,7 +72,7 @@ build-tools-oxenstored: build-tools-public-headers
 build-stubdom: mini-os-dir build-tools-public-headers
$(MAKE) -C stubdom build
 ifeq (x86_64,$(XEN_TARGET_ARCH))
-   XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub
+   XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub32
 endif
 
 .PHONY: build-docs
@@ -143,7 +143,7 @@ install-tools: install-tools-public-headers
 install-stubdom: mini-os-dir install-tools
$(MAKE) -C stubdom install
 ifeq (x86_64,$(XEN_TARGET_ARCH))
-   XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
+   XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub32
 endif
 
 .PHONY: tools/firmware/seabios-dir-force-update
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 06aa69d8bc..b339ae701c 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -531,6 +531,13 @@ vtpmmgr-stubdom: mini-os-$(XEN_TARGET_ARCH)-vtpmmgr vtpmmgr
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxenguest grub
DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" 
DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" 
$(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< 
APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: pv-grub32
+ifneq ($(filter grub,$(STUBDOM_TARGETS)),)
+pv-grub32: pv-grub
+else
+pv-grub32:
+endif
+
 .PHONY: xenstore-stubdom
 xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxenguest xenstore
DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" 
DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" 
$(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< 
APP_OBJS=$(CURDIR)/xenstore/xenstored.a
@@ -560,6 +567,12 @@ install-grub: pv-grub
$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz 
"$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+ifneq ($(filter grub,$(STUBDOM_TARGETS)),)
+install-grub32: install-grub
+else
+install-grub32:
+endif
+
 install-c: c-stubdom
 
 install-caml: caml-stubdom
-- 
2.26.2

Re: [PATCH 8/9] vpci/header: Reset the command register when adding devices

[Oleksandr Andrushchenko]

On 09.09.21 15:47, Jan Beulich wrote:
> On 09.09.2021 14:42, Oleksandr Andrushchenko wrote:
>> On 09.09.21 14:53, Jan Beulich wrote:
>>> On 09.09.2021 13:48, Oleksandr Andrushchenko wrote:
 On 09.09.21 12:21, Jan Beulich wrote:
> For the bit in question, where the goal appears to be to have hardware
> hold the OR of guest and host values, an approach similar to that used
> for some of the MSI / MSI-X bits might be chosen: Maintain guest and
> host bits in software, and update hardware (at least) when the
> effective resulting value changes. A complicating fact here is, though,
> that unlike for the MSI / MSI-X bits here Dom0 (pciback or its PCI
> susbstem) may also have a view on what the setting ought to be.
 The bigger question here is what can we take as the reference for INTx
 bit, e.g. if Dom0 didn't enable/configured the device being passed through
 than its COMMAND register may still be in after reset state and IMO there 
 is
 no guarantee it has the values we can say are "as host wants them"
>>> In the absence of Dom0 controlling the device, I think we ought to take
>>> Xen's view as the "host" one.
>> Agree
>>>Which will want the bit set at least as
>>> long as either MSI or MSI-X is enabled for the device.
>> But what is the INTx relation to MSI/MSI-X here?
> Devices are not supposed to signal interrupts two different ways at a
> time. They may enable only one - pin based, MSI, or MSI-X.

Ah, that simple ;) Yes, of course

>
> Jan
>
Thank you,

Oleksandr

Re: [PATCH 8/9] vpci/header: Reset the command register when adding devices

[Jan Beulich]

On 09.09.2021 14:42, Oleksandr Andrushchenko wrote:
> On 09.09.21 14:53, Jan Beulich wrote:
>> On 09.09.2021 13:48, Oleksandr Andrushchenko wrote:
>>> On 09.09.21 12:21, Jan Beulich wrote:
 For the bit in question, where the goal appears to be to have hardware
 hold the OR of guest and host values, an approach similar to that used
 for some of the MSI / MSI-X bits might be chosen: Maintain guest and
 host bits in software, and update hardware (at least) when the
 effective resulting value changes. A complicating fact here is, though,
 that unlike for the MSI / MSI-X bits here Dom0 (pciback or its PCI
 susbstem) may also have a view on what the setting ought to be.
>>> The bigger question here is what can we take as the reference for INTx
>>> bit, e.g. if Dom0 didn't enable/configured the device being passed through
>>> than its COMMAND register may still be in after reset state and IMO there is
>>> no guarantee it has the values we can say are "as host wants them"
>> In the absence of Dom0 controlling the device, I think we ought to take
>> Xen's view as the "host" one.
> Agree
>>   Which will want the bit set at least as
>> long as either MSI or MSI-X is enabled for the device.
> But what is the INTx relation to MSI/MSI-X here?

Devices are not supposed to signal interrupts two different ways at a
time. They may enable only one - pin based, MSI, or MSI-X.

Jan

Re: [PATCH 8/9] vpci/header: Reset the command register when adding devices

[Oleksandr Andrushchenko]

On 09.09.21 14:53, Jan Beulich wrote:
> On 09.09.2021 13:48, Oleksandr Andrushchenko wrote:
>> On 09.09.21 12:21, Jan Beulich wrote:
>>> For the bit in question, where the goal appears to be to have hardware
>>> hold the OR of guest and host values, an approach similar to that used
>>> for some of the MSI / MSI-X bits might be chosen: Maintain guest and
>>> host bits in software, and update hardware (at least) when the
>>> effective resulting value changes. A complicating fact here is, though,
>>> that unlike for the MSI / MSI-X bits here Dom0 (pciback or its PCI
>>> susbstem) may also have a view on what the setting ought to be.
>> The bigger question here is what can we take as the reference for INTx
>> bit, e.g. if Dom0 didn't enable/configured the device being passed through
>> than its COMMAND register may still be in after reset state and IMO there is
>> no guarantee it has the values we can say are "as host wants them"
> In the absence of Dom0 controlling the device, I think we ought to take
> Xen's view as the "host" one.
Agree
>   Which will want the bit set at least as
> long as either MSI or MSI-X is enabled for the device.
But what is the INTx relation to MSI/MSI-X here?
>
> Jan
>
Thank you,

Oleksandr

[xen-4.15-testing test] 164889: tolerable FAIL - PUSHED

[osstest service owner]

flight 164889 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164889/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10   fail REGR. vs. 163759
 test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 163759

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

version targeted for testing:
 xen  6f92f38419d6bd052da9076a7d89534b1f85ded9
baseline version:
 xen  dba774896f7dd74773c14d537643b7d7477fefcd

Last test of basis   163759  2021-07-17 04:12:25 Z   54 days
Failing since164262  2021-08-19 17:07:29 Z   20 days9 attempts
Testing same since   164889  2021-09-08 14:08:45 Z0 days1 attempts


People who touched revisions under t