[ovmf test] 168672: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 28eeb08d8664df813637e12cb00c60cb30330be8
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   17 days
Failing since168258  2022-03-01 01:55:31 Z   17 days  163 attempts
Testing same since   168670  2022-03-18 03:24:21 Z0 days2 attempts


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

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



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

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

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

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


Not pushing.

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

[ovmf test] 168670: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 28eeb08d8664df813637e12cb00c60cb30330be8
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   17 days
Failing since168258  2022-03-01 01:55:31 Z   17 days  162 attempts
Testing same since   168670  2022-03-18 03:24:21 Z0 days1 attempts


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

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



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

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

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

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


Not pushing.

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

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

[Peng Fan]

> Subject: Re: [PATCH 2/3] xen/arm: Add i.MX lpuart early printk support
> 
> Hi Peng,
> 
> On 28/02/2022 01:07, Peng Fan (OSS) wrote:
> > From: Peng Fan 
> >
> > Signed-off-by: Peng Fan 
> > ---
> >   xen/arch/arm/Kconfig.debug  | 18 ++
> >   xen/arch/arm/arm64/debug-imx-lpuart.inc | 48
> +
> >   2 files changed, 66 insertions(+)
> >   create mode 100644 xen/arch/arm/arm64/debug-imx-lpuart.inc
> >
> > diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
> > index 35ccd13273..9ecb446b3a 100644
> > --- a/xen/arch/arm/Kconfig.debug
> > +++ b/xen/arch/arm/Kconfig.debug
> > @@ -55,6 +55,20 @@ choice
> > selecting one of the platform specific options below if
> > you know the parameters for the port.
> >
> > +   This option is preferred over the platform specific
> > +   options; the platform specific options are deprecated
> > +   and will soon be removed.
> > +   config EARLY_UART_CHOICE_IMX_LPUART
> > +   select EARLY_UART_IMX_LPUART
> > +   depends on ARM_64
> > +   bool "Early printk via i.MX LPUART"
> > +   help
> > +   Say Y here if you wish the early printk to direct their
> > +   output to a i.MX LPUART. You can use this option to
> > +   provide the parameters for the i.MX LPUART rather than
> > +   selecting one of the platform specific options below if
> > +   you know the parameters for the port.
> 
> Plaform specific early printk are deprecated. So I would rather prefer we are
> not introducing new one. Can you adjust the description to remove any
> mention of platform specific options?

Sure, fix in v2.

> 
> > +
> > This option is preferred over the platform specific
> > options; the platform specific options are deprecated
> > and will soon be removed.
> > @@ -186,6 +200,9 @@ config EARLY_UART_CADENCE
> >   config EARLY_UART_EXYNOS4210
> > select EARLY_PRINTK
> > bool
> > +config EARLY_UART_IMX_LPUART
> > +   select EARLY_PRINTK
> > +   bool
> >   config EARLY_UART_MESON
> > select EARLY_PRINTK
> > bool
> > @@ -283,6 +300,7 @@ config EARLY_PRINTK_INC
> > default "debug-8250.inc" if EARLY_UART_8250
> > default "debug-cadence.inc" if EARLY_UART_CADENCE
> > default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
> > +   default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART
> > default "debug-meson.inc" if EARLY_UART_MESON
> > default "debug-mvebu.inc" if EARLY_UART_MVEBU
> > default "debug-pl011.inc" if EARLY_UART_PL011 diff --git
> > a/xen/arch/arm/arm64/debug-imx-lpuart.inc
> > b/xen/arch/arm/arm64/debug-imx-lpuart.inc
> > new file mode 100644
> > index 00..7510210d46
> > --- /dev/null
> > +++ b/xen/arch/arm/arm64/debug-imx-lpuart.inc
> > @@ -0,0 +1,48 @@
> > +/*
> > + * xen/arch/arm/arm64/debug-imx8qm.inc
> > + *
> > + * i.MX8QM specific debug code
> > + *
> > + * Peng Fan 
> > + * Copyright (C) 2016 Freescale Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License as published
> > +by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +
> > +.macro early_uart_init wb wc wd
> > +/* Already initialized in bootloader */ .endm
> 
> NIT: I would add a newline to separate with this macro from next one.

Fix in v2.

> 
> > +/* i.MX8QM wait LPUART to be ready to transmit
> > + * rb: register which contains the UART base address
> > + * rc: scratch register
> > + */
> 
> The coding style for multi-lines comment is:

Fix in v2. Thanks.

> 
> /*
>   * Foo
>   * Bar
>   */
> 
> > +.macro early_uart_ready xb, c
> > +1:
> > +ldr   w\c, [\xb, #UARTSTAT]   /* <- Flag register */
> > +tst   w\c, #UARTSTAT_TDRE /* Check FIFO EMPTY bit */
> > +beq   1b  /* Wait for the UART to be
> ready */
> > +.endm
> > +
> > +/* i.MX8QM LPUART transmit character
> > + * rb: register which contains the UART base address
> > + * rt: register which contains the character to transmit */
> 
> Coding style:

Fix in V2.

Thanks,
Peng.
> 
> /*
>   * Foo
>   * Bar
>   */
> 
> > +.macro early_uart_transmit xb, wt
> > +str   \wt, [\xb, #UARTDATA]  /* -> Data Register */
> > +.endm
> > +
> > +/*
> > + * Local variables:
> > + * mode: ASM
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> 
> Cheers,
> 
> --
> Julien Grall

RE: [PATCH 3/3] xen/arm: Add i.MX8QM platform support

[Peng Fan]

> Subject: Re: [PATCH 3/3] xen/arm: Add i.MX8QM platform support
> 
> Hi Peng,
> 
> On 28/02/2022 01:07, Peng Fan (OSS) wrote:
> > From: Peng Fan 
> >
> > Signed-off-by: Peng Fan 
> > ---
> >   xen/arch/arm/Kconfig.debug  |  3 +++
> >   xen/arch/arm/platforms/Makefile |  1 +
> >   xen/arch/arm/platforms/imx8qm.c | 44
> +
> >   3 files changed, 48 insertions(+)
> >   create mode 100644 xen/arch/arm/platforms/imx8qm.c
> >
> > diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
> > index 9ecb446b3a..43ccd8fe62 100644
> > --- a/xen/arch/arm/Kconfig.debug
> > +++ b/xen/arch/arm/Kconfig.debug
> > @@ -143,6 +143,9 @@ choice
> > config EARLY_PRINTK_HIKEY960
> > bool "Early printk with pl011 with Hikey 960"
> > select EARLY_UART_PL011
> > +   config EARLY_PRINTK_IMX8QM
> > +   bool "Early printk with i.MX LPUART with i.MX8QM"
> > +   select EARLY_UART_IMX_LPUART
> 
> The goal of platform specific early printk is to select to UART address (see
> EARLY_UART_BASE_ADDRESS).
> 
> However, we have deprecated them. So we should avoid adding new ones.
> 
> > config EARLY_PRINTK_JUNO
> > bool "Early printk with pl011 on Juno platform"
> > select EARLY_UART_PL011
> > diff --git a/xen/arch/arm/platforms/Makefile
> > b/xen/arch/arm/platforms/Makefile index 8632f4115f..bec6e55d1f 100644
> > --- a/xen/arch/arm/platforms/Makefile
> > +++ b/xen/arch/arm/platforms/Makefile
> > @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
> >   obj-$(CONFIG_ALL64_PLAT) += thunderx.o
> >   obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
> >   obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
> > +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
> >   obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
> >   obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o diff --git
> > a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c
> > new file mode 100644 index 00..289c18e5f9
> > --- /dev/null
> > +++ b/xen/arch/arm/platforms/imx8qm.c
> > @@ -0,0 +1,44 @@
> > +/*
> > + * xen/arch/arm/platforms/imx8qm.c
> > + *
> > + * i.MX 8QM setup
> > + *
> > + * Copyright 2022 NXP
> > + *
> > + * Peng Fan 
> > + *
> > + * 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 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static const char * const imx8qm_dt_compat[] __initconst = {
> > +"fsl,imx8qm",
> > +NULL
> > +};
> > +
> > +PLATFORM_START(imx8qm, "i.MX 8")
> > +.compatible = imx8qm_dt_compat,
> > +PLATFORM_END
> 
> We are only adding new platform definition when quirks are necessary. Do
> you need specific quirks for the i.MX8QM?
> 
> A somewhat related question, is this series enough to boot Xen upstream on
> the board?

Boot xen upstream, no need specific quirk.

Thanks,
Peng.

> 
> Cheers,
> 
> --
> Julien Grall

RE: [PATCH 1/3] xen/arm: Add i.MX lpuart driver

[Peng Fan]

Hi Julien,

> Subject: Re: [PATCH 1/3] xen/arm: Add i.MX lpuart driver
> 
> Hi Peng,
> 
> On 28/02/2022 01:07, Peng Fan (OSS) wrote:
> > From: Peng Fan 
> >
> > Signed-off-by: Peng Fan 
> > ---
> >   xen/drivers/char/Kconfig  |   8 +
> >   xen/drivers/char/Makefile |   1 +
> >   xen/drivers/char/imx-lpuart.c | 303
> ++
> >   xen/include/xen/imx-lpuart.h  |  64 +++
> >   4 files changed, 376 insertions(+)
> >   create mode 100644 xen/drivers/char/imx-lpuart.c
> >   create mode 100644 xen/include/xen/imx-lpuart.h
> >
> > diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index
> > 2ff5b288e2..0efdb2128f 100644
> > --- a/xen/drivers/char/Kconfig
> > +++ b/xen/drivers/char/Kconfig
> > @@ -13,6 +13,14 @@ config HAS_CADENCE_UART
> >   This selects the Xilinx Zynq Cadence UART. If you have a Xilinx
> Zynq
> >   based board, say Y.
> >
> > +config HAS_IMX_LPUART
> > +   bool "i.MX LPUART driver"
> > +   default y
> > +   depends on ARM_64
> > +   help
> > + This selects the i.MX LPUART. If you have a i.MX8QM based board,
> > + say Y.
> > +
> >   config HAS_MVEBU
> > bool "Marvell MVEBU UART driver"
> > default y
> > diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> > index 7c646d771c..14e67cf072 100644
> > --- a/xen/drivers/char/Makefile
> > +++ b/xen/drivers/char/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
> >   obj-$(CONFIG_HAS_OMAP) += omap-uart.o
> >   obj-$(CONFIG_HAS_SCIF) += scif-uart.o
> >   obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
> > +obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
> >   obj-$(CONFIG_ARM) += arm-uart.o
> >   obj-y += serial.o
> >   obj-$(CONFIG_XEN_GUEST) += xen_pv_console.o diff --git
> > a/xen/drivers/char/imx-lpuart.c b/xen/drivers/char/imx-lpuart.c new
> > file mode 100644 index 00..2a30e3f21a
> > --- /dev/null
> > +++ b/xen/drivers/char/imx-lpuart.c
> > @@ -0,0 +1,303 @@
> > +/*
> > + * xen/drivers/char/imx-lpuart.c
> > + *
> > + * Driver for i.MX LPUART.
> > + *
> > + * Peng Fan 
> > + * Copyright 2022 NXP
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License as published
> > +by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> 
> This should not be necessary.h

Will drop in v2.

> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Please order the  alphabetically.h

Fix in V2.

> 
> > +#include 
> > +#include 
> > +
> > +#define imx_lpuart_read(uart, off)   readl((uart)->regs + off)
> > +#define imx_lpuart_write(uart, off, val) writel((val), (uart)->regs +
> > +off)
> > +
> > +static struct imx_lpuart {
> > +unsigned int baud, clock_hz, data_bits, parity, stop_bits, fifo_size;
> > +unsigned int irq;
> > +char __iomem *regs;
> > +struct irqaction irqaction;
> > +struct vuart_info vuart;
> > +} imx8_com = {0};
> 
> This will be initialized to 0 by default. So I would drop {0}.

Fix in V2.

> 
> > +
> > +static void imx_lpuart_interrupt(int irq, void *data,
> > +  struct cpu_user_regs *regs)
> 
> Coding style: 'struct' should be aligned with 'int'.

Fix in V2.

> 
> > +{
> > +struct serial_port *port = data;
> > +struct imx_lpuart *uart = port->uart;
> > +unsigned int sts, rxcnt;
> > +
> > +sts = imx_lpuart_read(uart, UARTSTAT);
> > +rxcnt = imx_lpuart_read(uart, UARTWATER) >>
> UARTWATER_RXCNT_OFF;
> > +
> > +if ((sts & UARTSTAT_RDRF) || (rxcnt > 0)) {
> 
> Coding style:
> 
> if ( ... )
> {
> 
> But for single line block, we tend to avoid {}.

Fix in V2.

> 
> > +   serial_rx_interrupt(port, regs);
> > +}
> > +
> > +if ((sts & UARTSTAT_TDRE) &&
> > +!(imx_lpuart_read(uart, UARTBAUD) & UARTBAUD_TDMAE))
> 
> Looking at imx_lpuart_init_preirq(), you will always clear UARTBAUD_TDMAE.
> So it is necessary to check the value for every interrupt?

Just for safe, but may not needed check, let me check more, if not needed,
I'll drop in V2.

> 
> > +   serial_tx_interrupt(port, regs);
> > +
> > +imx_lpuart_write(uart, UARTSTAT, sts); }
> > +
> > +static void __init imx_lpuart_init_preirq(struct serial_port *port) {
> > +struct imx_lpuart *uart = port->uart;
> > +u32 sbr, osr;
> > +u32 ctrl, old_ctrl, bd;
> > +u32 baud;
> 
> In Xen we are phasing out the use of u* in favor of uint*_t. Can you convert
> your code to use uint*_t?

Fix in V2.

> 
> > +
> > +ctrl = old_ctrl = imx_lpuart_read(uart, UARTCTRL);
> > +ctrl = (old_ctrl & 

[ovmf test] 168668: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 79a705fbaf8fb817330b513b4cf6e63d3e2e7f21
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   17 days
Failing since168258  2022-03-01 01:55:31 Z   17 days  161 attempts
Testing same since   168668  2022-03-17 22:46:49 Z0 days1 attempts


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

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



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

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

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

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


Not pushing.

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

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

[osstest service owner]

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

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  6974c75180f1aad44e5428eabf2396b2b50fb0e4
baseline version:
 xen  7b41b91fd2ecbf87b91120b468689e10296b656c

Last test of basis   168666  2022-03-17 18:00:27 Z0 days
Testing same since   168669  2022-03-17 23:00:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bjoern Doebel 
  Jiamei Xie 
  Konrad Rzeszutek Wilk 

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
   7b41b91fd2..6974c75180  6974c75180f1aad44e5428eabf2396b2b50fb0e4 -> smoke

Re: [PATCH v1 11/13] xen/arm: store shm-info for deferred foreign memory map

[Stefano Stabellini]

On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng 
> 
> In a few scenarios where owner domain, is defined after borrower domain in
> device tree configuration, then statically shared pages haven't been properly
> allocated if borrower domain tries to do foreign memory map during
> domain construction.
> 
> In order to cover such scenario, we defer all borrower domains' foreign
> memory map after all domain construction finished, then only need to store
> shm-info during domain construction.
> 
> Signed-off-by: Penny Zheng 
> ---
>  xen/arch/arm/domain.c |  3 +++
>  xen/arch/arm/domain_build.c   | 34 ++-
>  xen/arch/arm/include/asm/domain.h | 25 +++
>  3 files changed, 61 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index f0bfd67fe5..73ffbfb918 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -47,6 +47,9 @@ DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
>  
>  #ifdef CONFIG_STATIC_SHM
>  struct domain *__read_mostly dom_shared;
> +
> +shm_info_t shm_list[NR_MEM_BANKS];

Instead of adding shm_list, maybe we can we re-use mem->bank
(bootinfo.reserved_mem)?

It is already storing the physical address and size (added in patch #1
with process_shm_node). We should be able to find the other info from
the mfn: mfn_to_page, page_get_owner, mfn_to_gfn. At most, we need to
mark the memory bank as shared and we could do that with another field
in struct membank. 


> +DECLARE_BITMAP(shm_list_mask, NR_MEM_BANKS);

This is the third bitmask we introduce :-)

Can we narrow it down to a single bitmask? Maybe we don't need it at all
if we switch to using bootinfo.mem.bank.


>  #endif
>  
>  static void do_idle(void)
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 7ee4d33e0b..4b19160674 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -771,7 +771,7 @@ static mfn_t __init acquire_shared_memory_bank(struct 
> domain *d,
>  
>  }
>  
> -static int __init allocate_shared_memory(struct domain *d,
> +static int __init allocate_shared_memory(struct domain *d, u32 shm_id,

No need for it to be u32?


>   u32 addr_cells, u32 size_cells,
>   paddr_t pbase, paddr_t psize,
>   paddr_t gbase)
> @@ -795,6 +795,18 @@ static int __init allocate_shared_memory(struct domain 
> *d,
>  return ret;
>  }
>  
> +/*
> + * If owner domain is not default dom_shared, shm-info of owner domain
> + * shall also be recorded for later deferred foreign memory map.
> + */
> +if ( d != dom_shared )
> +{
> +shm_list[shm_id].owner_dom = d->domain_id;
> +shm_list[shm_id].owner_gbase = gbase;
> +shm_list[shm_id].size = psize;
> +set_bit(shm_id, shm_list_mask);
> +}
>  return ret;
>  }
>  
> @@ -962,6 +974,26 @@ static int __init process_shm(struct domain *d,
>  if ( ret )
>  return ret;
>  }
> +else
> +{
> +if ( strcmp(role_str, "borrower") == 0 )
> +{
> +/*
> + * In a few scenarios where owner domain, is defined after
> + * borrower domain in device tree configuration, statically
> + * shared pages haven't been properly allocated if borrower
> + * domain here tries to do foreign memory map.
> + * In order to cover such scenario, we defer all borrower
> + * domains'foreign memory map after all domain construction
> + * finished, and only store shm-info here for later use.
> + */
> +shm_list[shm_id].borrower_dom[shm_list[shm_id].nr_borrower] =
> +d->domain_id;
> +
> shm_list[shm_id].borrower_gbase[shm_list[shm_id].nr_borrower] =
> +gbase;
> +shm_list[shm_id].nr_borrower++;
> +}
> +}

Maybe we don't need to defer this at all. guest_physmap_add_shm does
only two things:

1) get a page ref using the owner domain
2) add page to borrower p2m


We can do 2) straight away even if the owner is not yet allocated.

For 1), we need to get the right amount of references when the owner is
allocated (which could be after the borrowers).

Keeping in mind that we have already parsed all the info in
xen/arch/arm/bootfdt.c:process_shm_node, I wonder if we can add a field
to mem->bank[mem->nr_banks] to keep a count of the number of borrowers.

Then when we allocate the page to the owner here, we just get as many
additional reference as the number of borrowers.

This would:
- add a field to bootinfo.reserved_mem
- remove the need for shm_list
- remove the need for 

Re: [PATCH v1 07/13] xen/arm: create shared memory nodes in guest device tree

[Stefano Stabellini]

On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng 
> 
> We expose the shared memory to the domU using the "xen,shared-memory-v1"
> reserved-memory binding. See
> Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> in Linux for the corresponding device tree binding.
> 
> To save the cost of re-parsing shared memory device tree configuration when
> creating shared memory nodes in guest device tree, this commit adds new field
> "shm_mem" to store shm-info per domain.
> 
> For each shared memory region, a range is exposed under
> the /reserved-memory node as a child node. Each range sub-node is
> named xen-shmem@ and has the following properties:
> - compatible:
> compatible = "xen,shared-memory-v1"
> - reg:
> the base guest physical address and size of the shared memory region
> - xen,id:
> a string that identifies the shared memory region.
> 
> Signed-off-by: Penny Zheng 
> ---
>  xen/arch/arm/domain_build.c   | 144 ++
>  xen/arch/arm/include/asm/domain.h |   1 +
>  xen/arch/arm/include/asm/setup.h  |   3 +
>  3 files changed, 148 insertions(+)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 8cee5ffbd1..997df46ddd 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -840,6 +840,28 @@ static int __init guest_physmap_add_shm(struct domain 
> *od, struct domain *bd,
>  return ret;
>  }
>  
> +static int __init append_shm_bank_to_domain(struct domain *d,
> +paddr_t start, paddr_t size,
> +u32 shm_id)
> +{
> +/* Allocate memory at first insertion. */
> +if ( d->arch.shm_mem == NULL )
> +{
> +d->arch.shm_mem = xmalloc_bytes(sizeof(struct meminfo));
> +if ( d->arch.shm_mem == NULL )
> +return -ENOMEM;
> +
> +memset(d->arch.shm_mem, 0, sizeof(struct meminfo));

_xzalloc ?


> +}
> +
> +d->arch.shm_mem->bank[d->arch.shm_mem->nr_banks].start = start;
> +d->arch.shm_mem->bank[d->arch.shm_mem->nr_banks].size = size;
> +d->arch.shm_mem->bank[d->arch.shm_mem->nr_banks].shm_id = shm_id;
> +d->arch.shm_mem->nr_banks++;
> +
> +return 0;
> +}
> +
>  static int __init process_shm(struct domain *d,
>const struct dt_device_node *node)
>  {
> @@ -907,6 +929,14 @@ static int __init process_shm(struct domain *d,
>  PFN_DOWN(gbase), PFN_DOWN(psize));
>  if ( ret )
>  return ret;
> +
> +/*
> + * Record static shared memory region info for later setting
> + * up shm-node in guest device tree.
> + */
> +ret = append_shm_bank_to_domain(d, gbase, psize, shm_id);
> +if ( ret )
> +return ret;
>  }
>  
>  return 0;
> @@ -1237,6 +1267,115 @@ static int __init make_memory_node(const struct 
> domain *d,
>  return res;
>  }
>  
> +#ifdef CONFIG_STATIC_SHM
> +static int __init make_shm_memory_node(const struct domain *d,
> +   void *fdt,
> +   int addrcells, int sizecells,
> +   struct meminfo *mem)
> +{
> +unsigned long i = 0;
> +int res = 0;
> +int reg_size = addrcells + sizecells;
> +
> +if ( mem->nr_banks == 0 )
> +return -ENOENT;
> +
> +/*
> + * For each shared memory region, a range is exposed under
> + * the /reserved-memory node as a child node. Each range sub-node is
> + * named xen-shmem@.
> + */
> +dt_dprintk("Create xen-shmem node\n");
> +
> +for ( ; i < mem->nr_banks; i++ )
> +{
> +u64 start = mem->bank[i].start;
> +u64 size = mem->bank[i].size;
> +u32 shm_id = mem->bank[i].shm_id;

Wasn't shm_id supposed to be u8?


> +/* Placeholder for xen-shmem@ + a 64-bit number + \0 */
> +char buf[27];
> +const char compat[] = "xen,shared-memory-v1";
> +__be32 *reg, *cells;
> +   unsigned int len;

alignment


> +snprintf(buf, sizeof(buf), "xen-shmem@%"PRIx64, mem->bank[i].start);
> +res = fdt_begin_node(fdt, buf);
> +if ( res )
> +return res;
> +
> +res = fdt_property(fdt, "compatible", compat, sizeof(compat));
> +if ( res )
> +return res;
> +
> +   len = reg_size * sizeof(__be32);

alignment


> +reg = xmalloc_bytes(len);

This is the same size for each bank. I think it is better as a local
variable on the stack.


> +if ( reg == NULL )
> +return -ENOMEM;
> +cells = reg;
> +
> +dt_child_set_range(, addrcells, sizecells, start, size);
> +
> +res = fdt_property(fdt, "reg", reg, len);
> +xfree(reg);
> +if (res)
> +return res;
> +
> +dt_dprintk("Shared memory bank %lu: %#"PRIx64"->%#"PRIx64"\n",
> +   

Re: [PATCH v1 10/13] xen/arm: allocate static shared memory to a specific owner domain

[Stefano Stabellini]

On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng 
> 
> If owner property is defined, then owner domain of a static shared memory
> region is not the default dom_shared anymore, but a specific domain.
> 
> This commit implements allocating static shared memory to a specific domain
> when owner property is defined.
> 
> Signed-off-by: Penny Zheng 
> ---
>  xen/arch/arm/domain_build.c | 63 -
>  1 file changed, 48 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d35f98ff9c..7ee4d33e0b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -872,6 +872,8 @@ static int __init process_shm(struct domain *d,
>  u32 shm_id;
>  u32 addr_cells, size_cells;
>  paddr_t gbase, pbase, psize;
> +const char *role_str;
> +bool owner_dom_shared = true;
>  
>  dt_for_each_child_node(node, shm_node)
>  {
> @@ -899,6 +901,13 @@ static int __init process_shm(struct domain *d,
>  gbase = dt_read_number(cells, addr_cells);
>  
>  /* TODO: Consider owner domain is not the default dom_shared. */

We should remove this comment?


> +/*
> + * "role" property is optional and if it is defined explicitly,
> + * so the owner domain is not the default "dom_shared" domain.
> + */
> +if ( dt_property_read_string(shm_node, "role", _str) == 0 )
> +owner_dom_shared = false;
> +
>  /*
>   * Per shared memory region could be shared between multiple domains.
>   * In case re-allocating the same shared memory region, we use 
> bitmask
> @@ -907,17 +916,38 @@ static int __init process_shm(struct domain *d,
>   */
>  if ( !test_bit(shm_id, shm_mask) )
>  {
> -/*
> - * Allocate statically shared pages to the default dom_shared.
> - * Set up P2M, and dom_shared is a direct-map domain,
> - * so GFN == PFN.
> - */
> -ret = allocate_shared_memory(dom_shared, addr_cells, size_cells,
> - pbase, psize, pbase);
> -if ( ret )
> -return ret;
> -
> -set_bit(shm_id, shm_mask);
> +if ( !owner_dom_shared )
> +{
> +if ( strcmp(role_str, "owner") == 0 )
> +{
> +/*
> + * Allocate statically shared pages to a specific owner
> + * domain.
> + */
> +ret = allocate_shared_memory(d, shm_id, addr_cells,
> + size_cells, pbase, psize,
> + gbase);
> +if ( ret )
> +return ret;
> +
> +set_bit(shm_id, shm_mask);
> +}
> +}
> +else
> +{
> +/*
> + * Allocate statically shared pages to the default 
> dom_shared.
> + * Set up P2M, and dom_shared is a direct-map domain,
> + * so GFN == PFN.
> + */
> +ret = allocate_shared_memory(dom_shared, shm_id,
> + addr_cells, size_cells, pbase,
> + psize, pbase);
> +if ( ret )
> +return ret;
> +
> +set_bit(shm_id, shm_mask);
> +}

These two chunks are identical if not for dom_shared / d. Can we just
do:

if ( owner_dom_shared )
  d = dom_shared;

on top? Then we can implement this only once.

>  }
>  
>  /*
> @@ -925,10 +955,13 @@ static int __init process_shm(struct domain *d,
>   * default dom_shared, so here we could just set up P2M foreign
>   * mapping for borrower domain immediately.
>   */
> -ret = guest_physmap_add_shm(dom_shared, d, PFN_DOWN(pbase),
> -PFN_DOWN(gbase), PFN_DOWN(psize));
> -if ( ret )
> -return ret;
> +if ( owner_dom_shared )
> +{
> +ret = guest_physmap_add_shm(dom_shared, d, PFN_DOWN(pbase),
> +PFN_DOWN(gbase), PFN_DOWN(psize));
> +if ( ret )
> +return ret;
> +}

What happens if the borrower is specified before the owner in device
tree? I see the case is handle by the next patch. Maybe we can have at
least a comment here or in the commit message.


>  
>  /*
>   * Record static shared memory region info for later setting
> -- 
> 2.25.1
> 

Re: [PATCH v1 03/13] xen/arm: allocate static shared memory to dom_shared

[Stefano Stabellini]

On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng 
> 
> This commit introduces process_shm to cope with static shared memory in
> domain construction.
> 
> This commit only considers allocating static shared memory to dom_shared
> when owner domain is not explicitly defined in device tree, the other
> scenario will be covered in the following patches.
> 
> Static shared memory could reuse acquire_static_memory_bank() to acquire
> and allocate static memory.
> 
> Signed-off-by: Penny Zheng 
> ---
>  xen/arch/arm/domain_build.c | 116 +++-
>  1 file changed, 115 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 8be01678de..6e6349caac 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -527,7 +527,8 @@ static mfn_t __init acquire_static_memory_bank(struct 
> domain *d,
>  mfn_t smfn;
>  int res;
>  
> -device_tree_get_reg(cell, addr_cells, size_cells, pbase, psize);
> +if ( cell )
> +device_tree_get_reg(cell, addr_cells, size_cells, pbase, psize);

Why this change?


>  ASSERT(IS_ALIGNED(*pbase, PAGE_SIZE) && IS_ALIGNED(*psize, PAGE_SIZE));
>  if ( PFN_DOWN(*psize) > UINT_MAX )
>  {
> @@ -751,6 +752,113 @@ static void __init assign_static_memory_11(struct 
> domain *d,
>  panic("Failed to assign requested static memory for direct-map domain 
> %pd.",
>d);
>  }
> +
> +#ifdef CONFIG_STATIC_SHM
> +static __initdata DECLARE_BITMAP(shm_mask, NR_MEM_BANKS);
> +
> +static mfn_t __init acquire_shared_memory_bank(struct domain *d,
> +   u32 addr_cells, u32 
> size_cells,
> +   paddr_t *pbase, paddr_t 
> *psize)
> +{
> +/*
> + * Pages of statically shared memory shall be included
> + * in domain_tot_pages().
> + */
> +d->max_pages += PFN_DOWN(*psize);
> +
> +return acquire_static_memory_bank(d, NULL, addr_cells, size_cells,
> +  pbase, psize);
> +
> +}
> +
> +static int __init allocate_shared_memory(struct domain *d,
> + u32 addr_cells, u32 size_cells,
> + paddr_t pbase, paddr_t psize,
> + paddr_t gbase)
> +{
> +mfn_t smfn;
> +int ret = 0;
> +
> +printk(XENLOG_INFO "Allocate static shared memory BANK 
> %#"PRIpaddr"-%#"PRIpaddr"\n",
> +   pbase, pbase + psize);
> +
> +smfn = acquire_shared_memory_bank(d, addr_cells, size_cells, ,
> +  );
> +if ( mfn_eq(smfn, INVALID_MFN) )
> +return -EINVAL;
> +
> +ret = guest_physmap_add_pages(d, gaddr_to_gfn(gbase), smfn, 
> PFN_DOWN(psize));
> +if ( ret )
> +{
> +dprintk(XENLOG_ERR, "Failed to map shared memory to %pd.\n", d);
> +return ret;
> +}
> +
> +return ret;
> +}
> +
> +static int __init process_shm(struct domain *d,
> +  const struct dt_device_node *node)
> +{
> +struct dt_device_node *shm_node;
> +int ret = 0;
> +const struct dt_property *prop;
> +const __be32 *cells;
> +u32 shm_id;
> +u32 addr_cells, size_cells;
> +paddr_t gbase, pbase, psize;
> +
> +dt_for_each_child_node(node, shm_node)
> +{
> +if ( !dt_device_is_compatible(shm_node, 
> "xen,domain-shared-memory-v1") )
> +continue;
> +
> +if ( !dt_property_read_u32(shm_node, "xen,shm-id", _id) )
> +{
> +printk("Shared memory node does not provide \"xen,shm-id\" 
> property.\n");
> +return -ENOENT;
> +}
> +
> +addr_cells = dt_n_addr_cells(shm_node);
> +size_cells = dt_n_size_cells(shm_node);
> +prop = dt_find_property(shm_node, "xen,shared-mem", NULL);
> +if ( !prop )
> +{
> +printk("Shared memory node does not provide \"xen,shared-mem\" 
> property.\n");
> +return -ENOENT;
> +}
> +cells = (const __be32 *)prop->value;
> +/* xen,shared-mem = ; */
> +device_tree_get_reg(, addr_cells, size_cells, , );
> +ASSERT(IS_ALIGNED(pbase, PAGE_SIZE) && IS_ALIGNED(psize, PAGE_SIZE));
> +gbase = dt_read_number(cells, addr_cells);
> +
> +/* TODO: Consider owner domain is not the default dom_shared. */
> +/*
> + * Per shared memory region could be shared between multiple domains.
> + * In case re-allocating the same shared memory region, we use 
> bitmask
> + * shm_mask to record whether this shared memory region has ever been
> + * allocated already.
> + */
> +if ( !test_bit(shm_id, shm_mask) )
> +{
> +/*
> + * Allocate statically shared pages to the default dom_shared.
> + * Set up P2M, and dom_shared is a direct-map domain,
> +  

Re: [PATCH v1 06/13] xen/arm: set up shared memory foreign mapping for borrower domain

[Stefano Stabellini]

On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng 
> 
> This commits introduces a new helper guest_physmap_add_shm to set up shared
> memory foreign mapping for borrower domain.
> 
> Firstly it should get and take reference of statically shared pages from
> owner dom_shared. Then it will setup P2M foreign memory map of these 
> statically
> shared pages for borrower domain.
> 
> This commits only considers owner domain is the default dom_shared, the
> other scenario will be covered in the following patches.
> 
> Signed-off-by: Penny Zheng 
> ---
>  xen/arch/arm/domain_build.c | 52 +
>  1 file changed, 52 insertions(+)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 984e70e5fc..8cee5ffbd1 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -798,6 +798,48 @@ static int __init allocate_shared_memory(struct domain 
> *d,
>  return ret;
>  }
>  
> +static int __init guest_physmap_add_shm(struct domain *od, struct domain *bd,
> +unsigned long o_gfn,
> +unsigned long b_gfn,
> +unsigned long nr_gfns)

They should probably be gfn_t type


> +{
> +struct page_info **pages = NULL;
> +p2m_type_t p2mt, t;
> +int ret = 0;
> +
> +pages = xmalloc_array(struct page_info *, nr_gfns);
> +if ( !pages )
> +return -ENOMEM;
> +
> +/*
> + * Take reference of statically shared pages from owner domain.
> + * Reference will be released when destroying shared memory region.
> + */
> +ret = get_pages_from_gfn(od, o_gfn, nr_gfns, pages, , P2M_ALLOC);
> +if ( ret )
> +{
> +ret = -EINVAL;
> +goto fail_pages;
> +}
> +
> +if ( p2m_is_ram(p2mt) )
> +t = (p2mt == p2m_ram_rw) ? p2m_map_foreign_rw : p2m_map_foreign_ro;
> +else
> +{
> +ret = -EINVAL;
> +goto fail_pages;
> +}

One idea is to initialize p2mt = p2m_ram_rw and pass it to
get_pages_from_gfn. Then get_pages_from_gfn can return error immediately
if any of the pages are of different type.

This way there is no need for checking again here.


> +/* Set up guest foreign map. */
> +ret = guest_physmap_add_pages(bd, _gfn(b_gfn), page_to_mfn(pages[0]),
> +  nr_gfns, t);
> +
> + fail_pages:
> +xfree(pages);
> +
> +return ret;
> +}
> +
>  static int __init process_shm(struct domain *d,
>const struct dt_device_node *node)
>  {
> @@ -855,6 +897,16 @@ static int __init process_shm(struct domain *d,
>  
>  set_bit(shm_id, shm_mask);
>  }
> +
> +/*
> + * All domains are borrower domains when owner domain is the
> + * default dom_shared, so here we could just set up P2M foreign
> + * mapping for borrower domain immediately.
> + */
> +ret = guest_physmap_add_shm(dom_shared, d, PFN_DOWN(pbase),
> +PFN_DOWN(gbase), PFN_DOWN(psize));
> +if ( ret )
> +return ret;
>  }
>  
>  return 0;
> -- 
> 2.25.1
> 

Re: [PATCH v1 02/13] xen/arm: introduce a special domain DOMID_SHARED

[Stefano Stabellini]

On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng 
> 
> In case to own statically shared pages when owner domain is not
> explicitly defined, this commits propose a special domain DOMID_SHARED,
> and we assign it 0x7FF5, as one of the system domains.
> 
> Statically shared memory reuses the same way of initialization with static
> memory, hence this commits proposes a new Kconfig CONFIG_STATIC_SHM to wrap
> related codes, and this option depends on static memory(CONFIG_STATIC_MEMORY).

Why does it depend on CONFIG_STATIC_MEMORY? This is a genuine question,
I am not trying to scope-creep the series. Is there an actual technical
dependency on CONFIG_STATIC_MEMORY? If not, it would be super useful to
be able to share memory statically even between normal dom0less guests
(of course it would be responsibility of the user to provide the right
addresses and avoid mapping clashes.) I know that some of our users have
requested this feature in the past.


> We intends to do shared domain creation after setup_virt_paging so shared
> domain could successfully do p2m initialization.
> 
> Signed-off-by: Penny Zheng 
> ---
>  xen/arch/arm/Kconfig  |  7 +++
>  xen/arch/arm/domain.c | 12 ++--
>  xen/arch/arm/include/asm/domain.h |  6 ++
>  xen/arch/arm/setup.c  | 22 ++
>  xen/common/domain.c   | 11 +++
>  xen/common/page_alloc.c   |  5 +
>  xen/common/vsprintf.c |  9 +
>  xen/include/public/xen.h  |  6 ++
>  xen/include/xen/sched.h   |  2 ++
>  9 files changed, 70 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index ecfa6822e4..c54accefb1 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -106,6 +106,13 @@ config TEE
>  
>  source "arch/arm/tee/Kconfig"
>  
> +config STATIC_SHM
> +   bool "Statically shared memory on a dom0less system" if UNSUPPORTED
> +   depends on STATIC_MEMORY
> +   default n
> +   help
> + This option enables statically shared memory on a dom0less system.
> +
>  endmenu
>  
>  menu "ARM errata workaround via the alternative framework"
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 8110c1df86..1ff1df5d3f 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -44,6 +44,10 @@
>  
>  DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
>  
> +#ifdef CONFIG_STATIC_SHM
> +struct domain *__read_mostly dom_shared;
> +#endif

This one should probably go to xen/common/domain.c to stay close to the
other special domains.


>  static void do_idle(void)
>  {
>  unsigned int cpu = smp_processor_id();
> @@ -703,7 +707,7 @@ int arch_domain_create(struct domain *d,
>  if ( is_idle_domain(d) )
>  return 0;
>  
> -ASSERT(config != NULL);
> +ASSERT(is_shared_domain(d) ? config == NULL : config != NULL);
>  
>  #ifdef CONFIG_IOREQ_SERVER
>  ioreq_domain_init(d);
> @@ -712,12 +716,16 @@ int arch_domain_create(struct domain *d,
>  d->arch.directmap = flags & CDF_directmap;
>  
>  /* p2m_init relies on some value initialized by the IOMMU subsystem */
> -if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
> +if ( (rc = iommu_domain_init(d, is_shared_domain(d) ? 0 : 
> config->iommu_opts)) != 0 )
>  goto fail;
>  
>  if ( (rc = p2m_init(d)) != 0 )
>  goto fail;
>  
> +/* DOMID_shared is sufficiently constructed after p2m initialization. */
> +if ( is_shared_domain(d) )
> +return 0;
> +
>  rc = -ENOMEM;
>  if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
>  goto fail;
> diff --git a/xen/arch/arm/include/asm/domain.h 
> b/xen/arch/arm/include/asm/domain.h
> index c56f6e4398..ea7a7219a3 100644
> --- a/xen/arch/arm/include/asm/domain.h
> +++ b/xen/arch/arm/include/asm/domain.h
> @@ -31,6 +31,12 @@ enum domain_type {
>  
>  #define is_domain_direct_mapped(d) (d)->arch.directmap
>  
> +#ifdef CONFIG_STATIC_SHM
> +extern struct domain *dom_shared;
> +#else
> +#define dom_shared NULL
> +#endif

I think this should probably go to xen/include/xen/mm.h to stay close to
the others (dom_xen, dom_io and dom_cow).


>  /*
>   * Is the domain using the host memory layout?
>   *
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index d5d0792ed4..f6a3b04958 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -855,6 +855,20 @@ static bool __init is_dom0less_mode(void)
>  return ( !dom0found && domUfound );
>  }
>  
> +#ifdef CONFIG_STATIC_SHM
> +static void __init setup_shared_domain(void)
> +{
> +/*
> + * Initialise our DOMID_SHARED domain.
> + * This domain owns statically shared pages when owner domain is not
> + * explicitly defined.
> + */
> +dom_shared = domain_create(DOMID_SHARED, NULL, CDF_directmap);
> +if ( IS_ERR(dom_shared) )
> +panic("Failed to create d[SHARED]: %ld\n", 

Re: [PATCH v1 01/13] xen/arm: introduce static shared memory

[Stefano Stabellini]

On Fri, 11 Mar 2022, Penny Zheng wrote:
> From: Penny Zheng 
> 
> This patch serie introduces a new feature: setting up static
> shared memory on a dom0less system, through device tree configuration.
> 
> This commit parses shared memory node at boot-time, and reserve it in
> bootinfo.reserved_mem to avoid other use.
> 
> Signed-off-by: Penny Zheng 
> ---
>  docs/misc/arm/device-tree/booting.txt | 118 ++
>  xen/arch/arm/bootfdt.c|  52 
>  2 files changed, 170 insertions(+)
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt 
> b/docs/misc/arm/device-tree/booting.txt
> index a94125394e..f702ade817 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -355,3 +355,121 @@ device-tree:
>  
>  This will reserve a 512MB region starting at the host physical address
>  0x3000 to be exclusively used by DomU1.
> +
> +Static Shared Memory
> +=

We ran out of = :-)


> +The static shared memory device tree nodes allow users to statically set up
> +shared memory on dom0less system, enabling domains to do shm-based
> +communication.
> +
> +- compatible
> +
> +"xen,domain-shared-memory-v1"
> +
> +- xen,shm-id
> +
> +An u8 value represents the unique identifier of the shared memory region.
> +The maximum identifier shall be "xen,shm-id = <0xff>".
> +
> +- xen,shared-mem
> +
> +An array takes a physical address, which is the base address of the
> +shared memory region in host physical address space, a size, and a guest
> +physical address, as the target address of the mapping.

This is good. We also need to say how to know how many cells each of the
three elements take: how many cells is the host physical address, how
many cells is the size, how many cells is the guest physical address.

This node is a subnode of a xen,domain compatible node (or chosen) which
comes with an #address-cells and a #size-cells. This is similarly to
multiboot,kernel nodes, so we could do the same. Here we could say that
the number of cells for the host address (and size) is the same as the
guest pseudo-physical address and they are inherited from the parent
node.


> +- role (Optional)
> +
> +A string property specifying the ownership of a shared memory region,
> +the value must be one of the following: "owner", or "borrower"
> +A shared memory region could be explicitly backed by one domain, which is
> +called "owner domain", and all the other domains who are also sharing
> +this region are called "borrower domain".
> +If not specified, the default value is "borrower" and owner is
> +"dom_shared", a system domain.
> +
> +As an example:
> +
> +chosen {
> +#address-cells = <0x1>;
> +#size-cells = <0x1>;
> +xen,xen-bootargs = "console=dtuart dtuart=serial0 bootscrub=0";
> +
> +..
> +
> +/* this is for Dom0 */
> +dom0-shared-mem@1000 {
> +compatible = "xen,domain-shared-memory-v1";
> +role = "owner";
> +xen,shm-id = <0x0>;
> +xen,shared-mem = <0x1000 0x1000 0x1000>;
> +}
> +
> +domU1 {
> +compatible = "xen,domain";
> +#address-cells = <0x1>;
> +#size-cells = <0x1>;
> +memory = <0 131072>;
> +cpus = <2>;
> +vpl011;
> +
> +/*
> + * shared memory region identified as 0x0(xen,shm-id = <0x0>)
> + * is shared between Dom0 and DomU1.
> + */
> +domU1-shared-mem@1000 {
> +compatible = "xen,domain-shared-memory-v1";
> +role = "borrower";
> +xen,shm-id = <0x0>;
> +xen,shared-mem = <0x1000 0x1000 0x5000>;
> +}
> +
> +/*
> + * shared memory region identified as 0x1(xen,shm-id = <0x1>)
> + * is shared between DomU1 and DomU2.
> + */
> +domU1-shared-mem@5000 {
> +compatible = "xen,domain-shared-memory-v1";
> +xen,shm-id = <0x1>;
> +xen,shared-mem = <0x5000 0x2000 0x6000>;
> +}
> +
> +..
> +
> +};
> +
> +domU2 {
> +compatible = "xen,domain";
> +#address-cells = <0x1>;
> +#size-cells = <0x1>;
> +memory = <0 65536>;
> +cpus = <1>;
> +
> +/*
> + * shared memory region identified as 0x1(xen,shm-id = <0x1>)
> + * is shared between domU1 and domU2.
> + */
> +domU2-shared-mem@5000 {
> +compatible = "xen,domain-shared-memory-v1";
> +xen,shm-id = <0x1>;
> +xen,shared-mem = <0x5000 0x2000 0x7000>;
> +}
> +
> +..
> +};
> +};
> +
> +This is an example with two static shared memory regions.
> +
> +For the static shared memory region identified as 0x0, host physical
> +address starting at 0x1000 of 256MB will be reserved to be shared between
> +Dom0 and DomU1.It will get mapped at 0x1000 

Re: [PATCH 1/1] xen/blkfront: fix comment for need_copy

[Chaitanya Kulkarni]

On 3/17/22 3:09 PM, Dongli Zhang wrote:
> The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
> copy the written data to persistent page.
> 
> ".need_copy = rq_data_dir(req) && info->feature_persistent,"
> 
> Signed-off-by: Dongli Zhang 
> ---

Looks good.

Reviewed-by: Chaitanya Kulkarni 

-ck

Re: [PATCH] xen-blkback: remove redundant assignment to variable i

[Chaitanya Kulkarni]

On 3/17/22 4:46 PM, Colin Ian King wrote:
> Variable i is being assigned a value that is never read, it is being
> re-assigned later in a for-loop. The assignment is redundant and can
> be removed.
> 
> Cleans up clang scan build warning:
> drivers/block/xen-blkback/blkback.c:934:14: warning: Although the value
> stored to 'i' is used in the enclosing expression, the value is never
> actually read from 'i' [deadcode.DeadStores]
> 
> Signed-off-by: Colin Ian King 


Looks good.

Reviewed-by: Chaitanya Kulkarni 

-ck

[qemu-upstream-4.16-testing test] 168659: tolerable FAIL - PUSHED

[osstest service owner]

flight 168659 qemu-upstream-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168659/

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu107951211a8d17658e1aaa0c23a8cf29f8806ad8
baseline version:
 qemuu29a2f95d36d2a01bcacc0f3136801b2d9197f4d7

Last test of basis   167686  2022-01-13 11:40:04 Z   63 days
Testing same since   168659  2022-03-17 11:11:40 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jason Andryuk 
  

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

[Stefano Stabellini]

On Thu, 17 Mar 2022, Ayan Kumar Halder wrote:
> When the data abort is caused due to cache maintenance for an address,
> there are three scenarios:-
> 
> 1. Address belonging to a non emulated region - For this, Xen should
> set the corresponding bit in the translation table entry to valid and
> return to the guest to retry the instruction. This can happen sometimes
> as Xen need to set the translation table entry to invalid. (for eg
> 'Break-Before-Make' sequence). Xen returns to the guest to retry the
> instruction.
> 
> 2. Address belongs to an emulated region - Xen should ignore the
> instruction (ie increment the PC) and return to the guest.
> 
> 3. Address is invalid - Xen should forward the data abort to the guest.
> 
> Signed-off-by: Ayan Kumar Halder 

Tested-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 

Re: [PATCH v11 2/3] xen/arm64: io: Handle the abort due to access to stage1 translation table

[Stefano Stabellini]

On Thu, 17 Mar 2022, Ayan Kumar Halder wrote:
> If the abort was caused due to access to stage1 translation table, Xen
> will try to set the p2m entry (assuming that the Stage 1 translation
> table is in a non MMIO region).
> If there is no such entry found, then Xen will try to map the address as
> a MMIO region (assuming that the Stage 1 translation table is in a
> direct MMIO region).
> 
> If that fails as well, then there are the two following scenarios:-
> 1. Stage 1 translation table being in an emulated MMIO region - Xen
> can read the region, but it has no way to return the value read to the
> CPU page table walker (which tries to go through the stage1 tables to
> resolve the translation fault).
> 
> 2. Stage 1 translation table address is invalid.
> 
> In both the above scenarios, Xen will forward the abort to the guest.
> 
> Signed-off-by: Ayan Kumar Halder 

Tested-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 


> ---
> 
> Changelog :-
> 
> v1..v8 - NA
> 
> v9 - 1. Extracted this change from "[XEN v8 2/2] xen/arm64: io: Support
> instructions (for which ISS is not..." into a separate patch of its own.
> The reason being this is an existing bug in the codebase.
> 
> v10 - 1. Enabled checking for stage1 translation table address in the
> MMIO region. The reason being Arm Arm does not have any restrictions.
> 2. Updated the commit message to explain all the possible scenarios.
> 
> v11 - 1. Fixed some wordings in comments and commit message (pointed
> by Julien in v10).
> 
>  xen/arch/arm/io.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> index fd903b7b03..6f458ee7fd 100644
> --- a/xen/arch/arm/io.c
> +++ b/xen/arch/arm/io.c
> @@ -128,6 +128,17 @@ void try_decode_instruction(const struct cpu_user_regs 
> *regs,
>  return;
>  }
>  
> +/*
> + * At this point, we know that the stage1 translation table is either in 
> an
> + * emulated MMIO region or its address is invalid . This is not expected 
> by
> + * Xen and thus it forwards the abort to the guest.
> + */
> +if ( info->dabt.s1ptw )
> +{
> +info->dabt_instr.state = INSTR_ERROR;
> +return;
> +}
> +
>  /*
>   * Armv8 processor does not provide a valid syndrome for decoding some
>   * instructions. So in order to process these instructions, Xen must
> -- 
> 2.17.1
> 
> 

Re: [PATCH v11 1/3] xen/arm64: io: Emulate instructions (with invalid ISS) on MMIO region

[Stefano Stabellini]

On Thu, 17 Mar 2022, Ayan Kumar Halder wrote:
> When an instruction is trapped in Xen due to translation fault, Xen
> checks if the ISS is invalid (for data abort) or it is an instruction
> abort. If so, Xen tries to resolve the translation fault using p2m page
> tables. In case of data abort, Xen will try to map the mmio region to
> the guest (ie tries to emulate the mmio region).
> 
> If the ISS is not valid and it is a data abort, then Xen tries to
> decode the instruction. In case of ioreq, Xen  saves the decoding state,
> rn and imm9 to vcpu_io. Whenever the vcpu handles the ioreq successfully,
> it will read the decoding state to determine if the instruction decoded
> was a ldr/str post indexing (ie INSTR_LDR_STR_POSTINDEXING). If so, it
> uses these details to post increment rn.
> 
> In case of mmio handler, if the mmio operation was successful, then Xen
> retrives the decoding state, rn and imm9. For state ==
> INSTR_LDR_STR_POSTINDEXING, Xen will update rn.
> 
> If there is an error encountered while decoding/executing the instruction,
> Xen will forward the abort to the guest.
> 
> Also, the logic to infer the type of instruction has been moved from
> try_handle_mmio() to try_decode_instruction() which is called before.
> try_handle_mmio() is solely responsible for handling the mmio operation.
> 
> Signed-off-by: Ayan Kumar Halder 

I managed to reproduce (on QEMU emulating a cortex-a15, see recent patch
series for automation) the original crash. And I also tested that this
version of the patch doesn't have the same issue. Now it works, so:

Tested-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 


> ---
> 
> Changelog :-
> 
> v2..v5 - Mentioned in the cover letter.
> 
> v6 - 1. Mantained the decoding state of the instruction. This is used by the
> caller to either abort the guest or retry or ignore or perform read/write on
> the mmio region.
> 
> 2. try_decode() invokes decoding for both aarch64 and thumb state. (Previously
> it used to invoke decoding only for aarch64 state). Thus, it handles all the
> checking of the registers before invoking any decoding of instruction.
> try_decode_instruction_invalid_iss() has thus been removed.
> 
> 3. Introduced a new field('enum instr_decode_state state') inside
> 'struct instr_details'. This holds the decoding state of the instruction.
> This is later read by the post_increment_register() to determine if rn needs 
> to
> be incremented. Also, this is read by the callers of try_decode_instruction()
> to determine if the instruction was valid or ignored or to be retried or
> error or decoded successfully.
> 
> 4. Also stored 'instr_details' inside 'struct ioreq'. This enables
> arch_ioreq_complete_mmio() to invoke post_increment_register() without 
> decoding
> the instruction again.
> 
> 5. Check hsr.dabt.valid in do_trap_stage2_abort_guest(). If it is not valid,
> then decode the instruction. This ensures that try_handle_mmio() is invoked 
> only
> when the instruction is either valid or decoded successfully.
> 
> 6. Inside do_trap_stage2_abort_guest(), if hsr.dabt.valid is not set, then
> resolve the translation fault before trying to decode the instruction. If
> translation fault is resolved, then return to the guest to execute the 
> instruction
> again.
> 
> 
> v7 - 1. Moved the decoding instruction details ie instr_details from 'struct 
> ioreq'
> to 'struct vcpu_io'.
> 
> 2. The instruction is decoded only when we get a data abort.
> 
> 3. Replaced ASSERT_UNREACHABLE() with domain_crash(). The reason being asserts
> can be disabled in some builds. In this scenario when the guest's cpsr is in 
> an
> erroneous state, Xen should crash the guest.
> 
> 4. Introduced check_p2m() which invokes p2m_resolve_translation_fault() and
> try_map_mmio() to resolve translation fault by configuring the page tables. 
> This
> gets invoked first if ISS is invalid and it is an instruction abort. If it is
> a data abort and hsr.dabt.s1ptw is set or try_handle_mmio() returns 
> IO_UNHANDLED,
> then check_p2m() gets invoked again.
> 
> 
> v8 - 1. Removed the handling of data abort when info->dabt.cache is set. This 
> will
> be implemented in a subsequent patch. (Not as part of this series)
> 
> 2. When the data abort is due to access to stage 1 translation tables, Xen 
> will
> try to fix the mapping of the page table for the corresponding address. If 
> this
> returns an error, Xen will abort the guest. Else, it will ask the guest to 
> retry
> the instruction.
> 
> 3. Changed v->io.info.dabt_instr from pointer to variable. The reason being 
> that
> arch_ioreq_complete_mmio() is called from leave_hypervisor_to_guest().
> That is after do_trap_stage2_abort_guest()  has been invoked. So the original
> variable will be no longer valid.
> 
> 4. Some other style issues pointed out in v7.
> 
> 
> v9 - 1. Ensure that "Erratum 766422" is handled only when ISS is valid.
> 
> 2. Whenever Xen receives and instruction abort or data abort (with invalid 
> ISS),
> Xen 

[ovmf test] 168664: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 411b3ff6ddb4042374a6e61285dac9f5a227f652
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   17 days
Failing since168258  2022-03-01 01:55:31 Z   16 days  160 attempts
Testing same since   168663  2022-03-17 13:41:37 Z0 days2 attempts


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

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



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

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

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

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


Not pushing.

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

[PATCH 1/1] xen/blkfront: fix comment for need_copy

[Dongli Zhang]

The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
copy the written data to persistent page.

".need_copy = rq_data_dir(req) && info->feature_persistent,"

Signed-off-by: Dongli Zhang 
---
 drivers/block/xen-blkfront.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 03b5fb341e58..dbc32d0a4b1a 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -576,7 +576,7 @@ struct setup_rw_req {
struct blkif_request *ring_req;
grant_ref_t gref_head;
unsigned int id;
-   /* Only used when persistent grant is used and it's a read request */
+   /* Only used when persistent grant is used and it's a write request */
bool need_copy;
unsigned int bvec_off;
char *bvec_data;
-- 
2.17.1

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

[osstest service owner]

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

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  7b41b91fd2ecbf87b91120b468689e10296b656c
baseline version:
 xen  a3ba3ed0f45d3226320fd051c2066feaf7160d7a

Last test of basis   168662  2022-03-17 13:01:43 Z0 days
Testing same since   168666  2022-03-17 18:00:27 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 

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
   a3ba3ed0f4..7b41b91fd2  7b41b91fd2ecbf87b91120b468689e10296b656c -> smoke

Re: [PATCH early-RFC 2/5] xen/arm64: Rework the memory layout

[Julien Grall]

Hi,

On 09/03/2022 11:20, Julien Grall wrote:

From: Julien Grall 

Xen is currently not fully compliant with the Arm because it will
switch the TTBR with the MMU on.

In order to be compliant, we need to disable the MMU before
switching the TTBR. The implication is the page-tables should
contain an identity mapping of the code switching the TTBR.

If we don't rework the memory layout, we would need to find a
virtual address that matches a physical address and doesn't clash
with the static virtual regions. This can be a bit tricky.

On arm64, the memory layout  has plenty of unused space. In most of
the case we expect Xen to be loaded in low memory.

The memory layout is reshuffled to keep the 0th slot free. Xen will now
be loaded at (512GB + 2MB). This requires a slight tweak of the boot
code as XEN_VIRT_START cannot be used as an immediate.

Signed-off-by: Julien Grall 

---

 TODO:
 - I vaguely recall that one of the early platform we supported add
   the memory starting in high memory (> 1TB). I need to check
   whether the new layout will be fine.
 - Update the documentation to reflect the new layout
---
  xen/arch/arm/arm64/head.S |  3 ++-
  xen/arch/arm/include/asm/config.h | 20 ++--
  xen/arch/arm/mm.c | 14 +++---
  3 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 66d862fc8137..878649280d73 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -594,7 +594,8 @@ create_page_tables:
   * need an additional 1:1 mapping, the virtual mapping will
   * suffice.
   */
-cmp   x19, #XEN_VIRT_START
+ldr   x0, =XEN_VIRT_START
+cmp   x19, x0
  bne   1f
  ret
  1:
diff --git a/xen/arch/arm/include/asm/config.h 
b/xen/arch/arm/include/asm/config.h
index 5db28a8dbd56..b2f31a914103 100644
--- a/xen/arch/arm/include/asm/config.h
+++ b/xen/arch/arm/include/asm/config.h
@@ -107,8 +107,20 @@
   *  Unused
   */
  
+#ifdef CONFIG_ARM_32

+
  #define COMMON_VIRT_START   _AT(vaddr_t, 0)
  
+#else

+
+#define SLOT0_ENTRY_BITS  39
+#define SLOT0(slot) (_AT(vaddr_t,slot) << SLOT0_ENTRY_BITS)
+#define SLOT0_ENTRY_SIZE  SLOT0(1)
+
+#define COMMON_VIRT_START   SLOT(1)


This should have been SLOT0(). I got it right in my tree but merge the 
change to the wrong patch :(.


Cheers,

--
Julien Grall

Re: [PATCH early-RFC 1/5] xen/arm: Clean-up the memory layout

[Julien Grall]

On 17/03/2022 15:23, Bertrand Marquis wrote:

Hi Julien,


Hi Bertrand,


On 9 Mar 2022, at 11:20, Julien Grall  wrote:

From: Julien Grall 

In a follow-up patch, the base address for the common mappings will
vary between arm32 and arm64. To avoid any duplication, define
every mapping in the common region from the previous one.

Take the opportunity to add mising *_SIZE for some mappings.

Signed-off-by: Julien Grall 


Changes looks ok to me so:
Reviewed-by: Bertrand Marquis 

Only one question after.



---

After the next patch, the term "common" will sound strange because
the base address is different. Any better suggestion?


MAPPING_VIRT_START ?


For arm32, I am planning to reshuffle the layout so the runtime address 
is always at the end of the layout.


So I think MAPPING_VIRT_START may be as confusing. How about 
SHARED_ARCH_VIRT_MAPPING?




Or space maybe..


I am not sure I understand this suggestion. Can you clarify?




---
xen/arch/arm/include/asm/config.h | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/include/asm/config.h 
b/xen/arch/arm/include/asm/config.h
index aedb586c8d27..5db28a8dbd56 100644
--- a/xen/arch/arm/include/asm/config.h
+++ b/xen/arch/arm/include/asm/config.h
@@ -107,16 +107,26 @@
  *  Unused
  */

-#define XEN_VIRT_START _AT(vaddr_t,0x0020)
-#define FIXMAP_ADDR(n)(_AT(vaddr_t,0x0040) + (n) * PAGE_SIZE)
+#define COMMON_VIRT_START   _AT(vaddr_t, 0)

-#define BOOT_FDT_VIRT_START_AT(vaddr_t,0x0060)
-#define BOOT_FDT_SLOT_SIZE MB(4)
-#define BOOT_FDT_VIRT_END  (BOOT_FDT_VIRT_START + BOOT_FDT_SLOT_SIZE)
+#define XEN_VIRT_START  (COMMON_VIRT_START + MB(2))
+#define XEN_SLOT_SIZE   MB(2)


I know this is not modified by your patch, but any idea why SLOT is used here ?
XEN_VIRT_SIZE would sound a bit more logic.


No idea. I can add a patch to rename it.

Cheers,

--
Julien Grall

[qemu-upstream-4.14-testing test] 168657: tolerable FAIL - PUSHED

[osstest service owner]

flight 168657 qemu-upstream-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168657/

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu83aebe33dc76760f911162f9e7a4b98a4929776b
baseline version:
 qemuud7d6a60e73ee21e82f0bac2036153f996e6c

Last test of basis   160798  2021-04-07 15:38:46 Z  344 days
Testing same since   168657  2022-03-17 11:11:39 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jason Andryuk 
 

[qemu-upstream-4.15-testing test] 168658: tolerable FAIL - PUSHED

[osstest service owner]

flight 168658 qemu-upstream-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168658/

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu6503bd6a1b5364ffd346a8a475e1eb91b9f756e5
baseline version:
 qemuue2af2d050338c99e8436e251ad67aafb3ebbd501

Last test of basis   160861  2021-04-09 10:38:42 Z  342 days
Testing same since   168658  2022-03-17 11:11:39 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jason Andryuk 
 

Re: Nonsensical XSM Flask denial

[Jason Andryuk]

On Thu, Mar 17, 2022 at 2:14 PM Andrew Cooper  wrote:
>
> On 17/03/2022 17:52, Jason Andryuk wrote:
> > I shut down a domU (HVM dom9 w/ Linux stubdom dom10) with a single PCI
> > device assigned.  Xen logged the following Flask denial for a second
> > PVH dom5 (uivm) without any PCI devices assigned.  This is Xen 4.14.4.
> >
> > (XEN) avc:  denied  { remove_irq } for domid=5 irq=17
> > scontext=system_u:system_r:uivm_t
> > tcontext=system_u:object_r:shared_irq_t tclass=resource
> >
> > Domain 5 as uivm_t and irq 17 as shared_irq_t both look correct.  But
> > it doesn't make sense that uivm would make a hypercall for an irq.
> >
> > Could this be from RCU calling complete_domain_destroy() when current
> > is dom5 (uivm)?  What would current be set to when RCU runs its
> > callbacks?
>
> RCU runs in softirq context, so yes - (almost) any use of current would
> be bogus.
>
> But I can't spot any overlap between the physdevop_unmap_pirq XSM check,
> and complete_domain_destroy().
>
> Any chance you can reproduce this with a WARN() in the AVC denied path,
> so we can see what's going on here?

The path I found reading is:
complete_domain_destroy
  arch_domain_destroy
free_domain_pirqs
  unmap_domain_pirq
xsm_unmap_domain_irq

After a few tries it triggered:
(XEN) Xen WARN at irq.c:2348
(XEN) [ Xen-4.14.4-xc  x86_64  debug=n   Not tainted ]
(XEN) CPU:4
(XEN) RIP:e008:[] unmap_domain_pirq+0x3c4/0x490
...
(XEN) Xen call trace:
(XEN)[] R unmap_domain_pirq+0x3c4/0x490
(XEN)[] S xmem_pool_free+0x22/0x2f0
(XEN)[] S free_domain_pirqs+0x51/0x70
(XEN)[] S arch_domain_destroy+0x45/0xb0
(XEN)[] S domain.c#complete_domain_destroy+0x81/0x150
(XEN)[] S rcupdate.c#rcu_process_callbacks+0x114/0x2b0
(XEN)[] S softirq.c#__do_softirq+0x5a/0xa0
(XEN)[] S vmx_asm_do_vmentry+0x2b/0x30

I found the XSM checks a little confusing.

physdevop_unmap_pirq() calls:
  xsm_unmap_domain_pirq() <- checks generic resource remove
  unmap_domain_pirq()
xsm_unmap_domain_irq() <- checks remove_irq for the specific irq

access_vectors lists physdevop_unmap_pirq as remove_irq, but the xsm
check in the function is xsm_unmap_domain_pirq, which doesn't use
remove_irq.

In an earlier Xen version, these RCU callbacks may have run as xen_t?
Or maybe it's just racy which context is used?  commit
8ad651705cbd0ad192398c1513d12c02b3197fa1 had:

2. When a domain is destroyed with a device passthrough active, the
calls to remove_{irq,ioport,iomem} can be made by the hypervisor itself
(which results in an XSM check with the source xen_t).  It does not make
sense to deny these permissions; no domain should be using xen_t, and
forbidding the hypervisor from performing cleanup is not useful.

+# Domain destruction can result in some access checks for actions performed by
+# the hypervisor.  These should always be allowed.
+allow xen_t resource_type : resource { remove_irq remove_ioport remove_iomem };

Thanks,
Jason

Re: [XEN][RFC PATCH v3 14/14] tools/xl: Add new xl command overlay for device tree overlay support

[Anthony PERARD]

On Tue, Mar 08, 2022 at 11:47:04AM -0800, Vikram Garhwal wrote:
> Signed-off-by: Vikram Garhwal 
> ---
>  tools/xl/xl.h   |  4 
>  tools/xl/xl_cmdtable.c  |  6 ++
>  tools/xl/xl_vmcontrol.c | 45 +
>  3 files changed, 55 insertions(+)
> 
> diff --git a/tools/xl/xl.h b/tools/xl/xl.h
> index c5c4bedbdd..604fd5bb94 100644
> --- a/tools/xl/xl.h
> +++ b/tools/xl/xl.h
> @@ -97,6 +97,9 @@ struct save_file_header {
>  
>  #define SAVEFILE_BYTEORDER_VALUE ((uint32_t)0x01020304UL)
>  
> +#define XL_DT_OVERLAY_ADD   1
> +#define XL_DT_OVERLAY_REMOVE2

These value would need to be part of libxl's API, rather than been
defined here. Could you create a new enum with both operation in
"libxl_types.idl", then have the libxl function convert them to the
hypercall operation? (So to be done in the previous patch.)

>  void save_domain_core_begin(uint32_t domid,
>  int preserve_domid,
>  const char *override_config_file,
> @@ -139,6 +142,7 @@ int main_shutdown(int argc, char **argv);
>  int main_reboot(int argc, char **argv);
>  int main_list(int argc, char **argv);
>  int main_vm_list(int argc, char **argv);
> +int main_dt_overlay(int argc, char **argv);
>  int main_create(int argc, char **argv);
>  int main_config_update(int argc, char **argv);
>  int main_button_press(int argc, char **argv);
> diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
> index 661323d488..5812d19db8 100644
> --- a/tools/xl/xl_cmdtable.c
> +++ b/tools/xl/xl_cmdtable.c
> @@ -20,6 +20,12 @@
>  #include "xl.h"
>  
>  const struct cmd_spec cmd_table[] = {
> +{ "overlay",
> +  _dt_overlay, 1, 1,

I think the first "1" needs to be a "0", because it doesn't seems that
the command can do a "dry-run".

> +  "Add/Remove a device tree overlay",
> +  "add/remove <.dtbo>"
> +  "-h print this help\n"
> +},

I don't think "overlay" is a good name for the command. Maybe
"dt-overlay" ? But we seem to mostly have "*-add" "*-remove" command (or
attach/detach), so maybe two new commands would be better:
"dt-overlay-add" and "dt-overlay-remove" rather than using a subcommand
for add/remove.


Also, could you add this/those commands later in "cmd_table"? I'd rather
keep "create" first when running `xl help`. So maybe at the end, or
some other place that kind of make sens?

>  { "create",
>_create, 1, 1,
>"Create a domain from config file ",
> diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
> index 435155a033..76b969dc33 100644
> --- a/tools/xl/xl_vmcontrol.c
> +++ b/tools/xl/xl_vmcontrol.c
> @@ -1262,6 +1262,51 @@ int main_create(int argc, char **argv)
>  return 0;
>  }
>  
> +int main_dt_overlay(int argc, char **argv)
> +{
> +const char *overlay_ops = argv[1];
> +const char *overlay_config_file = argv[2];
> +void *overlay_dtb = NULL;
> +int rc;
> +uint8_t op;
> +int overlay_dtb_size = 0;
> +
> +if (overlay_ops == NULL) {
> +fprintf(stderr, "No overlay operation mode provided\n");
> +return ERROR_FAIL;
> +}
> +
> +if (strcmp(overlay_ops, "add") == 0)
> +op = XL_DT_OVERLAY_ADD;
> +else if (strcmp(overlay_ops, "remove") == 0)
> +op = XL_DT_OVERLAY_REMOVE;
> +else {
> +fprintf(stderr, "Invalid dt overlay operation\n");
> +return ERROR_FAIL;
> +}
> +
> +if (overlay_config_file) {
> +rc = libxl_read_file_contents(ctx, overlay_config_file,
> +  _dtb, _dtb_size);
> +
> +if (rc) {
> +fprintf(stderr, "failed to read the overlay device tree file 
> %s\n",
> +overlay_config_file);
> +free(overlay_dtb);
> +return ERROR_FAIL;
> +}
> +} else {
> +fprintf(stderr, "overlay dtbo file not provided\n");

Instead of making out of bound access to "argv", you could check that
"argc" have the expected value, and if not, print the help of the
command. If you look at main_save() for example, there is: "if(argc is
wrong value){help("save");} which would print the help for the
command.

> +return ERROR_FAIL;
> +}
> +
> +rc = libxl_dt_overlay(ctx, overlay_dtb, overlay_dtb_size, op);
> +if (rc)
> +fprintf(stderr, "Overlay operation failed\n");

I'm not sure that this error message would be useful, as libxl should
already have printed something.

> +
> +free(overlay_dtb);
> +return rc;
> +}

Thanks,

-- 
Anthony PERARD

Re: Nonsensical XSM Flask denial

[Andrew Cooper]

On 17/03/2022 17:52, Jason Andryuk wrote:
> I shut down a domU (HVM dom9 w/ Linux stubdom dom10) with a single PCI
> device assigned.  Xen logged the following Flask denial for a second
> PVH dom5 (uivm) without any PCI devices assigned.  This is Xen 4.14.4.
>
> (XEN) avc:  denied  { remove_irq } for domid=5 irq=17
> scontext=system_u:system_r:uivm_t
> tcontext=system_u:object_r:shared_irq_t tclass=resource
>
> Domain 5 as uivm_t and irq 17 as shared_irq_t both look correct.  But
> it doesn't make sense that uivm would make a hypercall for an irq.
>
> Could this be from RCU calling complete_domain_destroy() when current
> is dom5 (uivm)?  What would current be set to when RCU runs its
> callbacks?

RCU runs in softirq context, so yes - (almost) any use of current would
be bogus.

But I can't spot any overlap between the physdevop_unmap_pirq XSM check,
and complete_domain_destroy().

Any chance you can reproduce this with a WARN() in the AVC denied path,
so we can see what's going on here?

~Andrew

Nonsensical XSM Flask denial

[Jason Andryuk]

I shut down a domU (HVM dom9 w/ Linux stubdom dom10) with a single PCI
device assigned.  Xen logged the following Flask denial for a second
PVH dom5 (uivm) without any PCI devices assigned.  This is Xen 4.14.4.

(XEN) avc:  denied  { remove_irq } for domid=5 irq=17
scontext=system_u:system_r:uivm_t
tcontext=system_u:object_r:shared_irq_t tclass=resource

Domain 5 as uivm_t and irq 17 as shared_irq_t both look correct.  But
it doesn't make sense that uivm would make a hypercall for an irq.

Could this be from RCU calling complete_domain_destroy() when current
is dom5 (uivm)?  What would current be set to when RCU runs its
callbacks?

Thanks,
Jason

Re: [XEN][RFC PATCH v3 13/14] tools/libs/light: Implement new libxl functions for device tree overlay ops

[Anthony PERARD]

On Tue, Mar 08, 2022 at 11:47:03AM -0800, Vikram Garhwal wrote:
> Signed-off-by: Vikram Garhwal 
> ---
>  tools/include/libxl.h|  3 ++
>  tools/libs/light/Makefile|  1 +
>  tools/libs/light/libxl_overlay.c | 67 
>  3 files changed, 71 insertions(+)
>  create mode 100644 tools/libs/light/libxl_overlay.c
> 
> diff --git a/tools/include/libxl.h b/tools/include/libxl.h
> index 51a9b6cfac..b31e17c2ce 100644
> --- a/tools/include/libxl.h
> +++ b/tools/include/libxl.h
> @@ -2419,6 +2419,9 @@ libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, 
> uint32_t domid,
>  int *num);
>  void libxl_device_pci_list_free(libxl_device_pci* list, int num);
>  
> +int libxl_dt_overlay(libxl_ctx *ctx, void *overlay,
> + int overlay_size, uint8_t overlay_op);
> +

As you are making changes to libxl's API, you are going to need to add a
"#define LIBXL_HAVE_*" in "include/libxl.h" about the availability of
the new function.

>  /*
>   * Turns the current process into a backend device service daemon
>   * for a driver domain.
> diff --git a/tools/libs/light/Makefile b/tools/libs/light/Makefile
> index 453bea0067..405115c13c 100644
> --- a/tools/libs/light/Makefile
> +++ b/tools/libs/light/Makefile
> @@ -116,6 +116,7 @@ SRCS-y += libxl_genid.c
>  SRCS-y += _libxl_types.c
>  SRCS-y += libxl_flask.c
>  SRCS-y += _libxl_types_internal.c
> +SRCS-y += libxl_overlay.o

Building this new file unconditionally is an issue at the moment.
"./configure" doesn't check if libfdt is on the system unless we happen
to build for Arm. And libfdt is mandatory when building for Arm.

Could you build this new source file on Arm only? With a comment why.
"SRCS-$(CONFIG_ARM) +="

Alternatively, you could try to rework configure to always check for
libfdt, but I doubt that device tree overlay are going to be useful on
x86 at the moment.


Then, libxl_dt_overlay() will need a stub that just return an error when
building on system that don't have libfdt.

>  
>  ifeq ($(CONFIG_LIBNL),y)
>  CFLAGS_LIBXL += $(LIBNL3_CFLAGS)
> diff --git a/tools/libs/light/libxl_overlay.c 
> b/tools/libs/light/libxl_overlay.c
> new file mode 100644
> index 00..e370e8cac8
> --- /dev/null
> +++ b/tools/libs/light/libxl_overlay.c

Could you rename this new file "libxl_dt_overlay.c"? There could be
other kind of "overlay".

> @@ -0,0 +1,67 @@
> +/*
> + * Copyright (C) 2021 Xilinx Inc.
> + * Author Vikram Garhwal 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * 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 Lesser General Public License for more details.
> + */
> +
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +#include "libxl_internal.h"
> +#include 
> +#include 
> +#include 
> +
> +static int check_overlay_fdt(libxl__gc *gc, void *fdt, size_t size)
> +{
> +int r;
> +
> +if (fdt_magic(fdt) != FDT_MAGIC) {
> +LOG(ERROR, "Overlay FDT is not a valid Flat Device Tree");
> +return ERROR_FAIL;
> +}
> +
> +r = fdt_check_header(fdt);
> +if (r) {
> +LOG(ERROR, "Failed to check the overlay FDT (%d)", r);
> +return ERROR_FAIL;
> +}
> +
> +if (fdt_totalsize(fdt) > size) {
> +LOG(ERROR, "Overlay FDT totalsize is too big");
> +return ERROR_FAIL;
> +}
> +
> +return 0;
> +}
> +
> +int libxl_dt_overlay(libxl_ctx *ctx, void *overlay_dt, int overlay_dt_size,

I wonder whether the type of "overlay_dt_size" should be something else.
check_overlay_fdt() takes a "size_t", but the hypercall takes
"uint32_t".

> + uint8_t overlay_op)
> +{
> +int rc = 0;

By CODING_STYLE, "rc" shouldn't be set when declared.

> +GC_INIT(ctx);
> +
> +if (check_overlay_fdt(gc, overlay_dt, overlay_dt_size)) {
> +LOG(ERROR, "Overlay DTB check failed\n");

No need for \n, it's already added by LOG().

> +GC_FREE;
> +return ERROR_FAIL;

Instead of writing GC_FREE more than once, could you set "rc" then "goto
out;"?

> +} else
> +LOG(DEBUG, "Overlay DTB check passed\n");

This needs to be in a {} block because the true side of the "if" uses
braces.

> +
> +/* We don't need to do  xc_interface_open here. */

That comment isn't very useful, as it is a fact of using "ctx".

> +rc = xc_dt_overlay(ctx->xch, overlay_dt, overlay_dt_size, overlay_op);

Instead of "rc", could you store the result of xc_dt_overlay() in "r"?
"rc" is reserved for libxl error code. Also, the return value of
libxl_dt_overlay() can't be the return 

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

[osstest service owner]

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

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  a3ba3ed0f45d3226320fd051c2066feaf7160d7a
baseline version:
 xen  c7a80bc50ac768b4eecaad85b77ae45790c93c73

Last test of basis   168613  2022-03-15 12:01:42 Z2 days
Testing same since   168662  2022-03-17 13:01:43 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Henry Wang 
  Julien Grall 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   c7a80bc50a..a3ba3ed0f4  a3ba3ed0f45d3226320fd051c2066feaf7160d7a -> smoke

Re: [PATCH v4 11/11] xen/x86: remove cf_check attribute from hypercall handlers

[Jan Beulich]

On 17.03.2022 17:47, Jan Beulich wrote:
> On 10.03.2022 08:34, Juergen Gross wrote:
>> Now that the hypercall handlers are all being called directly instead
>> through a function vector, the "cf_check" attribute can be removed.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>> V4:
>> - new patch
>> ---
>>  xen/arch/x86/compat.c   |  6 +++---
>>  xen/arch/x86/cpu/mcheck/mce.c   |  2 +-
>>  xen/arch/x86/cpu/vpmu.c |  2 +-
>>  xen/arch/x86/domain.c   |  3 +--
>>  xen/arch/x86/hvm/dm.c   |  2 +-
>>  xen/arch/x86/hvm/hvm.c  |  2 +-
>>  xen/arch/x86/hvm/hypercall.c|  6 +++---
>>  xen/arch/x86/mm.c   | 12 ++--
>>  xen/arch/x86/mm/paging.c|  2 +-
>>  xen/arch/x86/physdev.c  |  2 +-
>>  xen/arch/x86/platform_hypercall.c   |  2 +-
>>  xen/arch/x86/pv/callback.c  | 16 
>>  xen/arch/x86/pv/descriptor-tables.c |  8 
>>  xen/arch/x86/pv/iret.c  |  4 ++--
>>  xen/arch/x86/pv/misc-hypercalls.c   | 10 +-
>>  xen/arch/x86/pv/shim.c  |  4 ++--
>>  xen/arch/x86/x86_64/compat/mm.c |  2 +-
>>  xen/common/argo.c   |  4 ++--
>>  xen/common/compat/grant_table.c |  2 +-
>>  xen/common/compat/kernel.c  |  2 +-
>>  xen/common/compat/memory.c  |  3 +--
>>  xen/common/dm.c |  2 +-
>>  xen/common/domain.c |  2 +-
>>  xen/common/domctl.c |  2 +-
>>  xen/common/event_channel.c  |  2 +-
>>  xen/common/grant_table.c|  3 +--
>>  xen/common/hypfs.c  |  2 +-
>>  xen/common/kernel.c |  2 +-
>>  xen/common/kexec.c  |  4 ++--
>>  xen/common/memory.c |  2 +-
>>  xen/common/multicall.c  |  3 +--
>>  xen/common/sched/compat.c   |  2 +-
>>  xen/common/sched/core.c |  4 ++--
>>  xen/common/sysctl.c |  2 +-
>>  xen/common/xenoprof.c   |  2 +-
>>  xen/drivers/char/console.c  |  2 +-
>>  xen/scripts/gen_hypercall.awk   |  2 +-
>>  xen/xsm/xsm_core.c  |  4 ++--
>>  38 files changed, 67 insertions(+), 71 deletions(-)
> 
> But that's only the definitions; for a reason I forget the annotations
> are present also on the declarations (really the "also" applies the
> other way around; perhaps it was that a future gcc will want to warn
> about declaration and definition having gone out of sync).

Actually wait, this was nonsense - the declarations are gone by this
point, and the awk script adjustment is all that's needed.

Acked-by: Jan Beulich 


Jan

Re: [PATCH v4 11/11] xen/x86: remove cf_check attribute from hypercall handlers

[Juergen Gross]

On 17.03.22 17:47, Jan Beulich wrote:

On 10.03.2022 08:34, Juergen Gross wrote:

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

Signed-off-by: Juergen Gross 
---
V4:
- new patch
---
  xen/arch/x86/compat.c   |  6 +++---
  xen/arch/x86/cpu/mcheck/mce.c   |  2 +-
  xen/arch/x86/cpu/vpmu.c |  2 +-
  xen/arch/x86/domain.c   |  3 +--
  xen/arch/x86/hvm/dm.c   |  2 +-
  xen/arch/x86/hvm/hvm.c  |  2 +-
  xen/arch/x86/hvm/hypercall.c|  6 +++---
  xen/arch/x86/mm.c   | 12 ++--
  xen/arch/x86/mm/paging.c|  2 +-
  xen/arch/x86/physdev.c  |  2 +-
  xen/arch/x86/platform_hypercall.c   |  2 +-
  xen/arch/x86/pv/callback.c  | 16 
  xen/arch/x86/pv/descriptor-tables.c |  8 
  xen/arch/x86/pv/iret.c  |  4 ++--
  xen/arch/x86/pv/misc-hypercalls.c   | 10 +-
  xen/arch/x86/pv/shim.c  |  4 ++--
  xen/arch/x86/x86_64/compat/mm.c |  2 +-
  xen/common/argo.c   |  4 ++--
  xen/common/compat/grant_table.c |  2 +-
  xen/common/compat/kernel.c  |  2 +-
  xen/common/compat/memory.c  |  3 +--
  xen/common/dm.c |  2 +-
  xen/common/domain.c |  2 +-
  xen/common/domctl.c |  2 +-
  xen/common/event_channel.c  |  2 +-
  xen/common/grant_table.c|  3 +--
  xen/common/hypfs.c  |  2 +-
  xen/common/kernel.c |  2 +-
  xen/common/kexec.c  |  4 ++--
  xen/common/memory.c |  2 +-
  xen/common/multicall.c  |  3 +--
  xen/common/sched/compat.c   |  2 +-
  xen/common/sched/core.c |  4 ++--
  xen/common/sysctl.c |  2 +-
  xen/common/xenoprof.c   |  2 +-
  xen/drivers/char/console.c  |  2 +-
  xen/scripts/gen_hypercall.awk   |  2 +-
  xen/xsm/xsm_core.c  |  4 ++--
  38 files changed, 67 insertions(+), 71 deletions(-)


But that's only the definitions; for a reason I forget the annotations
are present also on the declarations (really the "also" applies the
other way around; perhaps it was that a future gcc will want to warn
about declaration and definition having gone out of sync).


See the change of xen/scripts/gen_hypercall.awk which is taking care of that.


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v4 11/11] xen/x86: remove cf_check attribute from hypercall handlers

[Jan Beulich]

On 10.03.2022 08:34, Juergen Gross wrote:
> Now that the hypercall handlers are all being called directly instead
> through a function vector, the "cf_check" attribute can be removed.
> 
> Signed-off-by: Juergen Gross 
> ---
> V4:
> - new patch
> ---
>  xen/arch/x86/compat.c   |  6 +++---
>  xen/arch/x86/cpu/mcheck/mce.c   |  2 +-
>  xen/arch/x86/cpu/vpmu.c |  2 +-
>  xen/arch/x86/domain.c   |  3 +--
>  xen/arch/x86/hvm/dm.c   |  2 +-
>  xen/arch/x86/hvm/hvm.c  |  2 +-
>  xen/arch/x86/hvm/hypercall.c|  6 +++---
>  xen/arch/x86/mm.c   | 12 ++--
>  xen/arch/x86/mm/paging.c|  2 +-
>  xen/arch/x86/physdev.c  |  2 +-
>  xen/arch/x86/platform_hypercall.c   |  2 +-
>  xen/arch/x86/pv/callback.c  | 16 
>  xen/arch/x86/pv/descriptor-tables.c |  8 
>  xen/arch/x86/pv/iret.c  |  4 ++--
>  xen/arch/x86/pv/misc-hypercalls.c   | 10 +-
>  xen/arch/x86/pv/shim.c  |  4 ++--
>  xen/arch/x86/x86_64/compat/mm.c |  2 +-
>  xen/common/argo.c   |  4 ++--
>  xen/common/compat/grant_table.c |  2 +-
>  xen/common/compat/kernel.c  |  2 +-
>  xen/common/compat/memory.c  |  3 +--
>  xen/common/dm.c |  2 +-
>  xen/common/domain.c |  2 +-
>  xen/common/domctl.c |  2 +-
>  xen/common/event_channel.c  |  2 +-
>  xen/common/grant_table.c|  3 +--
>  xen/common/hypfs.c  |  2 +-
>  xen/common/kernel.c |  2 +-
>  xen/common/kexec.c  |  4 ++--
>  xen/common/memory.c |  2 +-
>  xen/common/multicall.c  |  3 +--
>  xen/common/sched/compat.c   |  2 +-
>  xen/common/sched/core.c |  4 ++--
>  xen/common/sysctl.c |  2 +-
>  xen/common/xenoprof.c   |  2 +-
>  xen/drivers/char/console.c  |  2 +-
>  xen/scripts/gen_hypercall.awk   |  2 +-
>  xen/xsm/xsm_core.c  |  4 ++--
>  38 files changed, 67 insertions(+), 71 deletions(-)

But that's only the definitions; for a reason I forget the annotations
are present also on the declarations (really the "also" applies the
other way around; perhaps it was that a future gcc will want to warn
about declaration and definition having gone out of sync).

Jan

Re: [PATCH] Livepatch: fix typos

[Luca Fancellu]

> On 11 Mar 2022, at 19:11, Bjoern Doebel  wrote:
> 
> Fix a couple of typos in livepatch code.

NIT: I would say: [...] in livepatch code comments.

> 
> Signed-off-by: Bjoern Doebel 

With or without it:

Reviewed-by: Luca Fancellu 

Cheers,
Luca

> CC: Konrad Rzeszutek Wilk 
> CC: Ross Lagerwall 

Re: [PATCH] x86/cet: Remove writeable mapping of the BSPs shadow stack

[Andrew Cooper]

On 17/03/2022 16:28, Jan Beulich wrote:
> On 17.03.2022 17:19, Andrew Cooper wrote:
>> On 17/03/2022 09:17, Jan Beulich wrote:
>>> On 16.03.2022 20:23, Andrew Cooper wrote:
 On 16/03/2022 08:33, Jan Beulich wrote:
> On 15.03.2022 17:53, Andrew Cooper wrote:
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -215,8 +215,9 @@ SECTIONS
>>} PHDR(text)
>>DECL_SECTION(.init.data) {
>>  #endif
>> +   . = ALIGN(STACK_SIZE);
>> +   *(.init.bss.stack_aligned)
> No real need for the ALIGN() here - it's the contributions to the
> section which ought to come with proper alignment. Imo ALIGN()
> should only ever be there ahead of a symbol definition, as otherwise
> the symbol might not mark what it is intended to mark due to padding
> which might be inserted. See also 01fe4da6243b ("x86: force suitable
> alignment in sources rather than in linker script").
>
> Really we should consider using
>
> *(SORT_BY_ALIGNMENT(.init.data .init.data.* .init.bss.*))
>
> While I can see your point against forcing sorting by alignment
> globally, this very argument doesn't apply here (at least until
> there appeared a way for the section attribute and -fdata-sections
> to actually interact, such that .init.* could also become per-
> function/object).
>
> Then again - this block of zeroes doesn't need to occupy space in
> the binary.
 It already occupies space, because of mkelf32.
>>> Hmm, yes, and not just because of mkelf32: Since we munge everything
>>> in a single PT_LOAD segment in the linker script, all of .init.*
>>> necessarily has space allocated.
>>>
>  It could very well live in a @nobits .init.bss in the
> final ELF binary. But sadly the section isn't @nobits in the object
> file, and with that there would need to be a way to make the linker
> convert it to @nobits (and I'm unaware of such). What would work is
> naming the section .bss.init.stack_aligned (or e.g.
> .bss..init.stack_aligned to make it easier to separate it from
> .bss.* in the linker script) - that'll make gcc mark it @nobits.
 Living in .bss would prevent it from being reclaimed.  We've got several
 nasty bugs from shooting holes in the Xen image, and too many special
 cases already.
>>> I didn't suggest to put it in .bss; the suggested name was merely so
>>> that gcc would mark the section @nobits and we could exclude the
>>> section from what makes in into .bss in the final image independent
>>> of .init.* vs .bss.* ordering in the linker script. But anyway - with
>>> the above this aspect is now moot anyway.
>> So can I take this as an ack with the .init typo fixed?
> R-b, yes, as long as the ALIGN(STACK_SIZE) is also dropped and the
> other ALIGN() is retained (the latter you did already indicate you
> would do).

Ah yes.  Thanks.

~Andrew

Re: [PATCH] x86/cet: Remove writeable mapping of the BSPs shadow stack

[Jan Beulich]

On 17.03.2022 17:19, Andrew Cooper wrote:
> On 17/03/2022 09:17, Jan Beulich wrote:
>> On 16.03.2022 20:23, Andrew Cooper wrote:
>>> On 16/03/2022 08:33, Jan Beulich wrote:
 On 15.03.2022 17:53, Andrew Cooper wrote:
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -215,8 +215,9 @@ SECTIONS
>} PHDR(text)
>DECL_SECTION(.init.data) {
>  #endif
> +   . = ALIGN(STACK_SIZE);
> +   *(.init.bss.stack_aligned)
 No real need for the ALIGN() here - it's the contributions to the
 section which ought to come with proper alignment. Imo ALIGN()
 should only ever be there ahead of a symbol definition, as otherwise
 the symbol might not mark what it is intended to mark due to padding
 which might be inserted. See also 01fe4da6243b ("x86: force suitable
 alignment in sources rather than in linker script").

 Really we should consider using

 *(SORT_BY_ALIGNMENT(.init.data .init.data.* .init.bss.*))

 While I can see your point against forcing sorting by alignment
 globally, this very argument doesn't apply here (at least until
 there appeared a way for the section attribute and -fdata-sections
 to actually interact, such that .init.* could also become per-
 function/object).

 Then again - this block of zeroes doesn't need to occupy space in
 the binary.
>>> It already occupies space, because of mkelf32.
>> Hmm, yes, and not just because of mkelf32: Since we munge everything
>> in a single PT_LOAD segment in the linker script, all of .init.*
>> necessarily has space allocated.
>>
  It could very well live in a @nobits .init.bss in the
 final ELF binary. But sadly the section isn't @nobits in the object
 file, and with that there would need to be a way to make the linker
 convert it to @nobits (and I'm unaware of such). What would work is
 naming the section .bss.init.stack_aligned (or e.g.
 .bss..init.stack_aligned to make it easier to separate it from
 .bss.* in the linker script) - that'll make gcc mark it @nobits.
>>> Living in .bss would prevent it from being reclaimed.  We've got several
>>> nasty bugs from shooting holes in the Xen image, and too many special
>>> cases already.
>> I didn't suggest to put it in .bss; the suggested name was merely so
>> that gcc would mark the section @nobits and we could exclude the
>> section from what makes in into .bss in the final image independent
>> of .init.* vs .bss.* ordering in the linker script. But anyway - with
>> the above this aspect is now moot anyway.
> 
> So can I take this as an ack with the .init typo fixed?

R-b, yes, as long as the ALIGN(STACK_SIZE) is also dropped and the
other ALIGN() is retained (the latter you did already indicate you
would do).

Jan

Re: [PATCH] x86/cet: Remove writeable mapping of the BSPs shadow stack

[Andrew Cooper]

On 17/03/2022 09:17, Jan Beulich wrote:
> On 16.03.2022 20:23, Andrew Cooper wrote:
>> On 16/03/2022 08:33, Jan Beulich wrote:
>>> On 15.03.2022 17:53, Andrew Cooper wrote:
 --- a/xen/arch/x86/xen.lds.S
 +++ b/xen/arch/x86/xen.lds.S
 @@ -215,8 +215,9 @@ SECTIONS
} PHDR(text)
DECL_SECTION(.init.data) {
  #endif
 +   . = ALIGN(STACK_SIZE);
 +   *(.init.bss.stack_aligned)
>>> No real need for the ALIGN() here - it's the contributions to the
>>> section which ought to come with proper alignment. Imo ALIGN()
>>> should only ever be there ahead of a symbol definition, as otherwise
>>> the symbol might not mark what it is intended to mark due to padding
>>> which might be inserted. See also 01fe4da6243b ("x86: force suitable
>>> alignment in sources rather than in linker script").
>>>
>>> Really we should consider using
>>>
>>> *(SORT_BY_ALIGNMENT(.init.data .init.data.* .init.bss.*))
>>>
>>> While I can see your point against forcing sorting by alignment
>>> globally, this very argument doesn't apply here (at least until
>>> there appeared a way for the section attribute and -fdata-sections
>>> to actually interact, such that .init.* could also become per-
>>> function/object).
>>>
>>> Then again - this block of zeroes doesn't need to occupy space in
>>> the binary.
>> It already occupies space, because of mkelf32.
> Hmm, yes, and not just because of mkelf32: Since we munge everything
> in a single PT_LOAD segment in the linker script, all of .init.*
> necessarily has space allocated.
>
>>>  It could very well live in a @nobits .init.bss in the
>>> final ELF binary. But sadly the section isn't @nobits in the object
>>> file, and with that there would need to be a way to make the linker
>>> convert it to @nobits (and I'm unaware of such). What would work is
>>> naming the section .bss.init.stack_aligned (or e.g.
>>> .bss..init.stack_aligned to make it easier to separate it from
>>> .bss.* in the linker script) - that'll make gcc mark it @nobits.
>> Living in .bss would prevent it from being reclaimed.  We've got several
>> nasty bugs from shooting holes in the Xen image, and too many special
>> cases already.
> I didn't suggest to put it in .bss; the suggested name was merely so
> that gcc would mark the section @nobits and we could exclude the
> section from what makes in into .bss in the final image independent
> of .init.* vs .bss.* ordering in the linker script. But anyway - with
> the above this aspect is now moot anyway.

So can I take this as an ack with the .init typo fixed?

~Andrew

Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu

[Tamas K Lengyel]

On Thu, Mar 17, 2022 at 12:07 PM Jan Beulich  wrote:
>
> On 17.03.2022 16:59, Tamas K Lengyel wrote:
> > On Thu, Mar 17, 2022 at 11:06 AM Jan Beulich  wrote:
> >>
> >> On 17.03.2022 15:43, Tamas K Lengyel wrote:
> >>> On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich  wrote:
>  On 10.03.2022 19:44, Tamas K Lengyel wrote:
> > @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct 
> > domain *d, hvm_domain_context_t *h)
> >  v->arch.dr6   = ctxt.dr6;
> >  v->arch.dr7   = ctxt.dr7;
> >
> > +hvm_set_interrupt_shadow(v, ctxt.interruptibility_info);
> 
>  Setting reserved bits as well as certain combinations of bits will
>  cause VM entry to fail. I think it would be nice to report this as
>  an error here rather than waiting for the VM entry failure.
> >>>
> >>> Not sure if this would be the right spot to do that since that's all
> >>> VMX specific and this is the common hvm code.
> >>
> >> Well, it would be the VMX hook to do the checking, with an error
> >> propagated back here.
> >
> > I'm actually against it because the overhead of that error-checking
> > during vm forking would be significant with really no benefit. We are
> > copying the state from the parent where it was running fine before, so
> > doing that sanity checking thousands of times per second when we
> > already know its fine is bad.
>
> I can see your point, but my concern is not forking but normal migration
> or restoring of guests, where the incoming data is of effectively
> unknown origin.

IMHO for that route the error checking is better performed at the
toolstack level that sends the data to Xen.

Tamas

Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu

[Jan Beulich]

On 17.03.2022 16:59, Tamas K Lengyel wrote:
> On Thu, Mar 17, 2022 at 11:06 AM Jan Beulich  wrote:
>>
>> On 17.03.2022 15:43, Tamas K Lengyel wrote:
>>> On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich  wrote:
 On 10.03.2022 19:44, Tamas K Lengyel wrote:
> @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct domain 
> *d, hvm_domain_context_t *h)
>  v->arch.dr6   = ctxt.dr6;
>  v->arch.dr7   = ctxt.dr7;
>
> +hvm_set_interrupt_shadow(v, ctxt.interruptibility_info);

 Setting reserved bits as well as certain combinations of bits will
 cause VM entry to fail. I think it would be nice to report this as
 an error here rather than waiting for the VM entry failure.
>>>
>>> Not sure if this would be the right spot to do that since that's all
>>> VMX specific and this is the common hvm code.
>>
>> Well, it would be the VMX hook to do the checking, with an error
>> propagated back here.
> 
> I'm actually against it because the overhead of that error-checking
> during vm forking would be significant with really no benefit. We are
> copying the state from the parent where it was running fine before, so
> doing that sanity checking thousands of times per second when we
> already know its fine is bad.

I can see your point, but my concern is not forking but normal migration
or restoring of guests, where the incoming data is of effectively
unknown origin.

Jan

Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu

[Tamas K Lengyel]

On Thu, Mar 17, 2022 at 11:06 AM Jan Beulich  wrote:
>
> On 17.03.2022 15:43, Tamas K Lengyel wrote:
> > On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich  wrote:
> >> On 10.03.2022 19:44, Tamas K Lengyel wrote:
> >>> @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct domain 
> >>> *d, hvm_domain_context_t *h)
> >>>  v->arch.dr6   = ctxt.dr6;
> >>>  v->arch.dr7   = ctxt.dr7;
> >>>
> >>> +hvm_set_interrupt_shadow(v, ctxt.interruptibility_info);
> >>
> >> Setting reserved bits as well as certain combinations of bits will
> >> cause VM entry to fail. I think it would be nice to report this as
> >> an error here rather than waiting for the VM entry failure.
> >
> > Not sure if this would be the right spot to do that since that's all
> > VMX specific and this is the common hvm code.
>
> Well, it would be the VMX hook to do the checking, with an error
> propagated back here.

I'm actually against it because the overhead of that error-checking
during vm forking would be significant with really no benefit. We are
copying the state from the parent where it was running fine before, so
doing that sanity checking thousands of times per second when we
already know its fine is bad.

Tamas

[PATCH v2] x86/vmx: save guest non-register state in hvm_hw_cpu

[Tamas K Lengyel]

During VM forking and resetting a failed vmentry has been observed due
to the guest non-register state going out-of-sync with the guest register
state. For example, a VM fork reset right after a STI instruction can trigger
the failed entry. This is due to the guest non-register state not being saved
from the parent VM, thus the reset operation only copies the register state.

Fix this by including the guest non-register state in hvm_hw_cpu so that when
its copied from the parent VM the vCPU state remains in sync.

SVM is not currently wired-in as VM forking is VMX only and saving non-register
state during normal save/restore/migration operation hasn't been needed.

Signed-off-by: Tamas K Lengyel 
---
v2: Include all CPU non-register state and fold the ops into vmx_vmcs_save &
vmx_vmcs_restore.
Note: no sanity checking is performed on the fields to reduce the cycles during
  fuzzing.
---
 xen/arch/x86/hvm/vmx/vmx.c | 13 -
 xen/include/public/arch-x86/hvm/save.h |  6 ++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index c075370f64..4d4dcc4b70 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -713,7 +713,7 @@ static void vmx_restore_dr(struct vcpu *v)
 
 static void vmx_vmcs_save(struct vcpu *v, struct hvm_hw_cpu *c)
 {
-unsigned long ev;
+unsigned long ev, activity_state, intr_state;
 
 vmx_vmcs_enter(v);
 
@@ -721,6 +721,10 @@ static void vmx_vmcs_save(struct vcpu *v, struct 
hvm_hw_cpu *c)
 __vmread(GUEST_SYSENTER_ESP, >sysenter_esp);
 __vmread(GUEST_SYSENTER_EIP, >sysenter_eip);
 
+__vmread(GUEST_ACTIVITY_STATE, _state);
+__vmread(GUEST_INTERRUPTIBILITY_INFO, _state);
+__vmread(GUEST_PENDING_DBG_EXCEPTIONS, >pending_dbg);
+
 __vmread(VM_ENTRY_INTR_INFO, );
 if ( (ev & INTR_INFO_VALID_MASK) &&
  hvm_event_needs_reinjection(MASK_EXTR(ev, INTR_INFO_INTR_TYPE_MASK),
@@ -732,6 +736,9 @@ static void vmx_vmcs_save(struct vcpu *v, struct hvm_hw_cpu 
*c)
 }
 
 vmx_vmcs_exit(v);
+
+c->activity_state = activity_state;
+c->interruptibility_state = intr_state;
 }
 
 static int vmx_restore_cr0_cr3(
@@ -807,6 +814,10 @@ static int vmx_vmcs_restore(struct vcpu *v, struct 
hvm_hw_cpu *c)
 
 __vmwrite(GUEST_DR7, c->dr7);
 
+__vmwrite(GUEST_ACTIVITY_STATE, c->activity_state);
+__vmwrite(GUEST_INTERRUPTIBILITY_INFO, c->interruptibility_state);
+__vmwrite(GUEST_PENDING_DBG_EXCEPTIONS, c->pending_dbg);
+
 if ( c->pending_valid &&
  hvm_event_needs_reinjection(c->pending_type, c->pending_vector) )
 {
diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index 773a380bc2..eb72e44968 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -52,6 +52,7 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
  * Compat:
  * - Pre-3.4 didn't have msr_tsc_aux
  * - Pre-4.7 didn't have fpu_initialised
+ * - Pre-4.17 didn't have non-register state
  */
 
 struct hvm_hw_cpu {
@@ -166,6 +167,11 @@ struct hvm_hw_cpu {
 #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
 uint32_t flags;
 uint32_t pad0;
+
+/* non-register state */
+uint32_t activity_state;
+uint32_t interruptibility_state;
+uint64_t pending_dbg;
 };
 
 struct hvm_hw_cpu_compat {
-- 
2.25.1

Re: [XEN][RFC PATCH v3 12/14] tools/libs/ctrl: Implement new xc interfaces for dt overlay

[Anthony PERARD]

Hi Vikram,

On Tue, Mar 08, 2022 at 11:47:02AM -0800, Vikram Garhwal wrote:
> diff --git a/tools/libs/ctrl/xc_overlay.c b/tools/libs/ctrl/xc_overlay.c
> new file mode 100644
> index 00..8fe780d75a
> --- /dev/null
> +++ b/tools/libs/ctrl/xc_overlay.c

Could rename this new file? I don't think using "overlay" alone is going
to be helpful to figure out what it is about. Renaming it
"xc_dt_overlay.c" would already be better.

> @@ -0,0 +1,51 @@
> +/*
> + *
> + * Overlay control functions.

Maybe "Device Tree overlay functions" would be better. I'm not sure that
"control" is useful in the file description.

> + * Copyright (C) 2021 Xilinx Inc.
> + * Author Vikram Garhwal 
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library 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
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; If not, see 
> .
> + */
> +
> +#include "xc_bitops.h"
> +#include "xc_private.h"
> +#include 
> +#include 
> +
> +int xc_dt_overlay(xc_interface *xch, void *overlay_fdt, int overlay_fdt_size,
> +  uint8_t overlay_op)

Shouldn't the function prototype match the types from the sysctl
structure? There is "int" vs "uint32_t" for "overlay_fdt_size".

> +{
> +int err;
> +DECLARE_SYSCTL;
> +
> +DECLARE_HYPERCALL_BOUNCE(overlay_fdt, overlay_fdt_size,
> +XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +
> +if ( (err = xc_hypercall_bounce_pre(xch, overlay_fdt)) )
> +goto err;
> +
> +sysctl.cmd = XEN_SYSCTL_dt_overlay;
> +sysctl.u.dt_overlay.overlay_op = overlay_op;
> +sysctl.u.dt_overlay.overlay_fdt_size = overlay_fdt_size;
> +
> +set_xen_guest_handle(sysctl.u.dt_overlay.overlay_fdt, overlay_fdt);
> +
> +if ( (err = do_sysctl(xch, )) != 0 )
> +PERROR("%s failed\n", __func__);

The \n should be remove from the message. perror already adds a newline,
and it also adds information about the error after the message so a
newline in the middle will make it harder to read the error.

> +
> +err:
> +xc_hypercall_bounce_post(xch, overlay_fdt);
> +
> +return err;
> +}

Thanks,

-- 
Anthony PERARD

Re: [XEN PATCH] evtchn/fifo: Don't set PENDING bit if guest misbehaves

[Raphael Ning]

On 17/03/2022 14:26, Luca Fancellu wrote:
> I’ve tested on the ARM side, I’ve started/destroyed few guests from Dom0, 
> connect to the console, run
> some network communications between guest and Dom0, everything works:
>
> Tested-by: Luca Fancellu 


Thanks!  I tested on x86 (in a QEMU VM) by launching and destroying an HVM 
guest; both dom0 and the guest use FIFO event channels.


>
> Cheers,
> Luca
>

Re: [PATCH early-RFC 1/5] xen/arm: Clean-up the memory layout

[Bertrand Marquis]

Hi Julien,

> On 9 Mar 2022, at 11:20, Julien Grall  wrote:
> 
> From: Julien Grall 
> 
> In a follow-up patch, the base address for the common mappings will
> vary between arm32 and arm64. To avoid any duplication, define
> every mapping in the common region from the previous one.
> 
> Take the opportunity to add mising *_SIZE for some mappings.
> 
> Signed-off-by: Julien Grall 

Changes looks ok to me so:
Reviewed-by: Bertrand Marquis 

Only one question after.

> 
> ---
> 
> After the next patch, the term "common" will sound strange because
> the base address is different. Any better suggestion?

MAPPING_VIRT_START ?

Or space maybe..

> ---
> xen/arch/arm/include/asm/config.h | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/config.h 
> b/xen/arch/arm/include/asm/config.h
> index aedb586c8d27..5db28a8dbd56 100644
> --- a/xen/arch/arm/include/asm/config.h
> +++ b/xen/arch/arm/include/asm/config.h
> @@ -107,16 +107,26 @@
>  *  Unused
>  */
> 
> -#define XEN_VIRT_START _AT(vaddr_t,0x0020)
> -#define FIXMAP_ADDR(n)(_AT(vaddr_t,0x0040) + (n) * PAGE_SIZE)
> +#define COMMON_VIRT_START   _AT(vaddr_t, 0)
> 
> -#define BOOT_FDT_VIRT_START_AT(vaddr_t,0x0060)
> -#define BOOT_FDT_SLOT_SIZE MB(4)
> -#define BOOT_FDT_VIRT_END  (BOOT_FDT_VIRT_START + BOOT_FDT_SLOT_SIZE)
> +#define XEN_VIRT_START  (COMMON_VIRT_START + MB(2))
> +#define XEN_SLOT_SIZE   MB(2)

I know this is not modified by your patch, but any idea why SLOT is used here ?
XEN_VIRT_SIZE would sound a bit more logic.

Cheers
Bertrand

Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu

[Jan Beulich]

On 17.03.2022 15:43, Tamas K Lengyel wrote:
> On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich  wrote:
>> On 10.03.2022 19:44, Tamas K Lengyel wrote:
>>> @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct domain 
>>> *d, hvm_domain_context_t *h)
>>>  v->arch.dr6   = ctxt.dr6;
>>>  v->arch.dr7   = ctxt.dr7;
>>>
>>> +hvm_set_interrupt_shadow(v, ctxt.interruptibility_info);
>>
>> Setting reserved bits as well as certain combinations of bits will
>> cause VM entry to fail. I think it would be nice to report this as
>> an error here rather than waiting for the VM entry failure.
> 
> Not sure if this would be the right spot to do that since that's all
> VMX specific and this is the common hvm code.

Well, it would be the VMX hook to do the checking, with an error
propagated back here.

Jan

Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu

[Tamas K Lengyel]

On Thu, Mar 17, 2022 at 9:56 AM Jan Beulich  wrote:
>
> On 10.03.2022 19:44, Tamas K Lengyel wrote:
> > During VM fork resetting a failed vmentry has been observed when the reset
> > is performed immediately after a STI instruction executed. This is due to
> > the guest interruptibility state in the VMCS being modified by STI but the
> > subsequent reset removes the IF bit from FLAGS, causing the failed vmentry.
>
> I first thought this was backwards, but after re-reading a couple of
> times I think the issue is merely with you stating this as if this
> was what always happens, while it really depends on the state that
> the VM is being reset to. I think it would further be helpful if you
> made clear that other interruptibility state could also cause issues
> when not properly restored. One way to express this would be to
> simply insert "e.g." ahead of "a STI instruction".

Correct, there could be other instances where the interruptibility
state could go out of sync with RFLAGS, executing STI and then
resetting only the register state to the pre-STI parent is just one I
stumbled into.

>
> > @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct domain 
> > *d, hvm_domain_context_t *h)
> >  v->arch.dr6   = ctxt.dr6;
> >  v->arch.dr7   = ctxt.dr7;
> >
> > +hvm_set_interrupt_shadow(v, ctxt.interruptibility_info);
>
> Setting reserved bits as well as certain combinations of bits will
> cause VM entry to fail. I think it would be nice to report this as
> an error here rather than waiting for the VM entry failure.

Not sure if this would be the right spot to do that since that's all
VMX specific and this is the common hvm code.

>
> > --- a/xen/arch/x86/include/asm/hvm/hvm.h
> > +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> > @@ -720,6 +720,22 @@ static inline int hvm_vmtrace_reset(struct vcpu *v)
> >  return -EOPNOTSUPP;
> >  }
> >
> > +static inline unsigned long hvm_get_interrupt_shadow(struct vcpu *v)
>
> unsigned long here and ...
>
> > +{
> > +if ( hvm_funcs.get_interrupt_shadow )
> > +return alternative_call(hvm_funcs.get_interrupt_shadow, v);
> > +
> > +return -EOPNOTSUPP;
> > +}
> > +
> > +static inline void
> > +hvm_set_interrupt_shadow(struct vcpu *v, unsigned long val)
>
> ... here are not in line with the hooks' types. Same for the stubs
> further down then.
>
> > +{
> > +if ( hvm_funcs.set_interrupt_shadow )
> > +alternative_vcall(hvm_funcs.set_interrupt_shadow, v, val);
> > +}
> > +
> > +
> >  /*
>
> Please don't insert multiple successive blank lines.

Ack.

Tamas

[ovmf test] 168663: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 411b3ff6ddb4042374a6e61285dac9f5a227f652
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   17 days
Failing since168258  2022-03-01 01:55:31 Z   16 days  159 attempts
Testing same since   168663  2022-03-17 13:41:37 Z0 days1 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [PATCH v3] x86/cet: Use dedicated NOP4 for cf_clobber

[Andrew Cooper]

On 17/03/2022 14:21, Jan Beulich wrote:
> On 17.03.2022 15:06, Andrew Cooper wrote:
>> For livepatching, we need to look at a potentially clobbered function and
>> determine whether it used to have an ENDBR64 instruction.
>>
>> Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
>> check-endbr.sh to look for it.  The same logic can check for the absence of
>> any endbr32 instructions, so include a check for those too.
>>
>> The choice of nop has some complicated consequences.  nopw (%rax) has a ModRM
>> byte of 0, which the Bourne compatible shells unconditionally strip from
>> parameters, meaning that we can't pass it to `grep -aob`.
>>
>> Therefore, use nopw (%rcx) so the ModRM byte becomes 1.
>>
>> This then demonstrates another bug.  Under perl regexes, \1 thru \9 are
>> subpattern matches, and not octal escapes, while the behaviour of \10 and
>> higher depend on the number of capture groups.  Switch the `grep -P` runes to
>> use hex escapes instead, which are unambiguous
>>
>> The build time check then requires that the endbr64 poison have the same
>> treatment as endbr64 to avoid placing the byte pattern in immediate operands.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Thanks.

> with one nit (which likely I should have spotted before):

Unlikely, seeing as that was part that I rewrote between v2 and v3.

Will fix.

~Andrew

Re: [XEN PATCH] evtchn/fifo: Don't set PENDING bit if guest misbehaves

[Luca Fancellu]

> On 16 Mar 2022, at 18:58, Andrew Cooper  wrote:
> 
> On 16/03/2022 18:38, Raphael Ning wrote:
>> From: Raphael Ning 
>> 
>> Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
>> if it fails to lock the FIFO event queue(s), or if the guest has not
>> initialized the FIFO control block for the target vCPU. A well-behaved
>> guest should never trigger either of these cases.
>> 
>> There is no good reason to set the PENDING bit (the guest should not
>> depend on this behaviour anyway) or check for pollers in such corner
>> cases, so skip that. In fact, both the comment above the for loop and
>> the commit message for
>> 
>> 41a822c39263 xen/events: rework fifo queue locking
>> 
>> suggest that the bit should be set after the FIFO queue(s) are locked.
>> 
>> Take the opportunity to rename the was_pending variable (flipping its
>> sense) and switch to the standard bool type.
>> 
>> Suggested-by: David Vrabel 
>> Signed-off-by: Raphael Ning 
>> ---
>> xen/common/event_fifo.c | 8 
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c
>> index ed4d3beb10f3..6c74ccebebb7 100644
>> --- a/xen/common/event_fifo.c
>> +++ b/xen/common/event_fifo.c
>> @@ -165,7 +165,7 @@ static void cf_check evtchn_fifo_set_pending(
>> unsigned int port;
>> event_word_t *word;
>> unsigned long flags;
>> -bool_t was_pending;
>> +bool_t check_pollers = false;
> 
> Considering your commit message, did you intend to change this to bool?
> 
> Can be fixed on commit.  Acked-by: Andrew Cooper 
> 

I’ve tested on the ARM side, I’ve started/destroyed few guests from Dom0, 
connect to the console, run
some network communications between guest and Dom0, everything works:

Tested-by: Luca Fancellu 

Cheers,
Luca

> ~Andrew
> 
> P.S. David - do you want your maintainership back?  None of this code
> has undergone any major changes since you wrote it.
> 

Re: [PATCH 1/2] livepatch: do not ignore sections with 0 size

[Andrew Cooper]

On 17/03/2022 14:16, Roger Pau Monné wrote:
> On Thu, Mar 17, 2022 at 02:00:19PM +, Andrew Cooper wrote:
>> On 17/03/2022 11:08, Roger Pau Monne wrote:
>>> A side effect of ignoring such sections is that symbols belonging to
>>> them won't be resolved, and that could make relocations belonging to
>>> other sections that reference those symbols fail.
>>>
>>> For example it's likely to have an empty .altinstr_replacement with
>>> symbols pointing to it, and marking the section as ignored will
>>> prevent the symbols from being resolved, which in turn will cause any
>>> relocations against them to fail.
>> I agree this is a bug in livepatch handling, but it's also an error in
>> the generated livepatch.  We should not have relocations to an empty
>> altinstr_replacement section in the first place.
> Well, the relocation destination is in the .altinstructions section
> (which is not empty). It happens however to reference a symbol that
> points to the .altinstr_replacement section that's empty.
>
> We could likely avoid generating the altinstr_replacement section in
> the first place, but I think it's more robust to handle those properly
> in the elf loading code.

Actually, it turns out it's distinctly non-trivial to omit these
references.  We need to put the replacement somewhere, so we can
subtract the start from the end, and figure out if it is 0.

~Andrew

Re: [PATCH v3] x86/cet: Use dedicated NOP4 for cf_clobber

[Jan Beulich]

On 17.03.2022 15:06, Andrew Cooper wrote:
> For livepatching, we need to look at a potentially clobbered function and
> determine whether it used to have an ENDBR64 instruction.
> 
> Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
> check-endbr.sh to look for it.  The same logic can check for the absence of
> any endbr32 instructions, so include a check for those too.
> 
> The choice of nop has some complicated consequences.  nopw (%rax) has a ModRM
> byte of 0, which the Bourne compatible shells unconditionally strip from
> parameters, meaning that we can't pass it to `grep -aob`.
> 
> Therefore, use nopw (%rcx) so the ModRM byte becomes 1.
> 
> This then demonstrates another bug.  Under perl regexes, \1 thru \9 are
> subpattern matches, and not octal escapes, while the behaviour of \10 and
> higher depend on the number of capture groups.  Switch the `grep -P` runes to
> use hex escapes instead, which are unambiguous
> 
> The build time check then requires that the endbr64 poison have the same
> treatment as endbr64 to avoid placing the byte pattern in immediate operands.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with one nit (which likely I should have spotted before):

> @@ -45,13 +45,15 @@ echo "X" | grep -aobP "\130" -q 2>/dev/null || 
> perl_re=false
>  ${OBJDUMP} -j .text $1 -d -w | grep 'endbr64 *$' | cut -f 1 -d ':' > 
> $VALID &
>  
>  #
> -# Second, look for any endbr64 byte sequence
> +# Second, look for all endbr64, endbr32 and nop poison byte sequences
>  # This has a couple of complications:
>  #
>  # 1) Grep binary search isn't VMA aware.  Copy .text out as binary, causing
>  #the grep offset to be from the start of .text.
>  #
>  # 2) dash's printf doesn't understand hex escapes, hence the use of octal.
> +#`grep -P` on the other hand can has various ambiguities with octal-like
> +#escapes, so use hex escapes instead which are unambiguous.

There looks to be a stray "can" in here.

Jan

Re: [PATCH 1/2] livepatch: do not ignore sections with 0 size

[Roger Pau Monné]

On Thu, Mar 17, 2022 at 02:00:19PM +, Andrew Cooper wrote:
> On 17/03/2022 11:08, Roger Pau Monne wrote:
> > A side effect of ignoring such sections is that symbols belonging to
> > them won't be resolved, and that could make relocations belonging to
> > other sections that reference those symbols fail.
> >
> > For example it's likely to have an empty .altinstr_replacement with
> > symbols pointing to it, and marking the section as ignored will
> > prevent the symbols from being resolved, which in turn will cause any
> > relocations against them to fail.
> 
> I agree this is a bug in livepatch handling, but it's also an error in
> the generated livepatch.  We should not have relocations to an empty
> altinstr_replacement section in the first place.

Well, the relocation destination is in the .altinstructions section
(which is not empty). It happens however to reference a symbol that
points to the .altinstr_replacement section that's empty.

We could likely avoid generating the altinstr_replacement section in
the first place, but I think it's more robust to handle those properly
in the elf loading code.

> This will probably be from the lfences, where the replacement in a nop
> and takes no space.  I think I know how to fix this case.

Indeed, that's my understanding.

Thanks, Roger.

Re: [PATCH 1/2] livepatch: do not ignore sections with 0 size

[Jan Beulich]

On 17.03.2022 15:00, Andrew Cooper wrote:
> On 17/03/2022 11:08, Roger Pau Monne wrote:
>> A side effect of ignoring such sections is that symbols belonging to
>> them won't be resolved, and that could make relocations belonging to
>> other sections that reference those symbols fail.
>>
>> For example it's likely to have an empty .altinstr_replacement with
>> symbols pointing to it, and marking the section as ignored will
>> prevent the symbols from being resolved, which in turn will cause any
>> relocations against them to fail.
> 
> I agree this is a bug in livepatch handling, but it's also an error in
> the generated livepatch.  We should not have relocations to an empty
> altinstr_replacement section in the first place.

I think having such relocations is quite natural, but ...

> This will probably be from the lfences, where the replacement in a nop
> and takes no space.  I think I know how to fix this case.

... of course it's possible to eliminate them. Whether that's worthwhile
to add logic for I'm not sure.

Jan

[PATCH v3] x86/cet: Use dedicated NOP4 for cf_clobber

[Andrew Cooper]

For livepatching, we need to look at a potentially clobbered function and
determine whether it used to have an ENDBR64 instruction.

Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
check-endbr.sh to look for it.  The same logic can check for the absence of
any endbr32 instructions, so include a check for those too.

The choice of nop has some complicated consequences.  nopw (%rax) has a ModRM
byte of 0, which the Bourne compatible shells unconditionally strip from
parameters, meaning that we can't pass it to `grep -aob`.

Therefore, use nopw (%rcx) so the ModRM byte becomes 1.

This then demonstrates another bug.  Under perl regexes, \1 thru \9 are
subpattern matches, and not octal escapes, while the behaviour of \10 and
higher depend on the number of capture groups.  Switch the `grep -P` runes to
use hex escapes instead, which are unambiguous

The build time check then requires that the endbr64 poison have the same
treatment as endbr64 to avoid placing the byte pattern in immediate operands.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Bjoern Doebel 
CC: Michael Kurth 
CC: Martin Pohlack 

v2:
 * Check for the poison byte pattern in check-endbr.sh
 * Use nopw (%rcx) to work around shell NUL (mis)features
 * Use hex escapes to work around Perl subpattern matches
v3:
 * Tweak wording about perl regex
 * Check for endbr32 as well
---
 xen/arch/x86/alternative.c   |  2 +-
 xen/arch/x86/include/asm/endbr.h | 26 ++
 xen/tools/check-endbr.sh | 18 +-
 3 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index d41eeef1bcaf..0c6fc7b4fb0c 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -362,7 +362,7 @@ static void init_or_livepatch _apply_alternatives(struct 
alt_instr *start,
 if ( !is_kernel_text(ptr) || !is_endbr64(ptr) )
 continue;
 
-add_nops(ptr, ENDBR64_LEN);
+place_endbr64_poison(ptr);
 clobbered++;
 }
 
diff --git a/xen/arch/x86/include/asm/endbr.h b/xen/arch/x86/include/asm/endbr.h
index 6090afeb0bd8..d946fac13130 100644
--- a/xen/arch/x86/include/asm/endbr.h
+++ b/xen/arch/x86/include/asm/endbr.h
@@ -52,4 +52,30 @@ static inline void place_endbr64(void *ptr)
 *(uint32_t *)ptr = gen_endbr64();
 }
 
+/*
+ * After clobbering ENDBR64, we may need to confirm that the site used to
+ * contain an ENDBR64 instruction.  Use an encoding which isn't the default
+ * P6_NOP4.  Specifically, nopw (%rcx)
+ */
+static inline uint32_t __attribute_const__ gen_endbr64_poison(void)
+{
+uint32_t res;
+
+asm ( "mov $~0x011f0f66, %[res]\n\t"
+  "not %[res]\n\t"
+  : [res] "=" (res) );
+
+return res;
+}
+
+static inline bool is_endbr64_poison(const void *ptr)
+{
+return *(const uint32_t *)ptr == gen_endbr64_poison();
+}
+
+static inline void place_endbr64_poison(void *ptr)
+{
+*(uint32_t *)ptr = gen_endbr64_poison();
+}
+
 #endif /* XEN_ASM_ENDBR_H */
diff --git a/xen/tools/check-endbr.sh b/xen/tools/check-endbr.sh
index 9799c451a18d..641a2342199e 100755
--- a/xen/tools/check-endbr.sh
+++ b/xen/tools/check-endbr.sh
@@ -27,7 +27,7 @@ echo "X" | grep -aob "X" -q 2>/dev/null ||
 # Check whether grep supports Perl regexps. Older GNU grep doesn't reliably
 # find binary patterns otherwise.
 perl_re=true
-echo "X" | grep -aobP "\130" -q 2>/dev/null || perl_re=false
+echo "X" | grep -aobP "\x58" -q 2>/dev/null || perl_re=false
 
 #
 # First, look for all the valid endbr64 instructions.
@@ -45,13 +45,15 @@ echo "X" | grep -aobP "\130" -q 2>/dev/null || perl_re=false
 ${OBJDUMP} -j .text $1 -d -w | grep '  endbr64 *$' | cut -f 1 -d ':' > $VALID &
 
 #
-# Second, look for any endbr64 byte sequence
+# Second, look for all endbr64, endbr32 and nop poison byte sequences
 # This has a couple of complications:
 #
 # 1) Grep binary search isn't VMA aware.  Copy .text out as binary, causing
 #the grep offset to be from the start of .text.
 #
 # 2) dash's printf doesn't understand hex escapes, hence the use of octal.
+#`grep -P` on the other hand can has various ambiguities with octal-like
+#escapes, so use hex escapes instead which are unambiguous.
 #
 # 3) AWK can't add 64bit integers, because internally all numbers are doubles.
 #When the upper bits are set, the exponents worth of precision is lost in
@@ -65,11 +67,17 @@ eval $(${OBJDUMP} -j .text $1 -h |
 awk '$2 == ".text" {printf "vma_hi=%s\nvma_lo=%s\n", substr($4, 1, 8), 
substr($4, 9, 16)}')
 
 ${OBJCOPY} -j .text $1 -O binary $TEXT_BIN
+
+# instruction:hex:   oct:
+# endbr64 f3 0f 1e fa363 017 036 372
+# endbr32 f3 0f 1e fb363 017 036 373
+# nopw (%rcx) 66 0f 1f 01146 017 037 001
 if $perl_re
 then
-LC_ALL=C grep -aobP '\363\17\36\372' $TEXT_BIN
+LC_ALL=C grep -aobP 

Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu

[Jan Beulich]

On 17.03.2022 12:06, Tamas K Lengyel wrote:
> Another question I would be interested to hear from the maintainers is in
> regards to the hvm context compat macros. Right now they differentiate
> between hvm hw cpu struct versions based on size. So since this patch
> doesn't change the size how is that supposed to work? Or if there are more
> then two versions of the struct? The compat version never changes?

struct hvm_hw_cpu_compat is indeed not meant to ever change. It needed
introducing because the msr_tsc_aux field was added in the middle of
the struct, instead of at the end. Going forward, as was done with the
"flags" field already, additions should only be at the end. Exceptions
are when padding fields are assigned a purpose (like you do), which is
why they need checking that they're zero when they're introduced.

Jan

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

[Ayan Kumar Halder]

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

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

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

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

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

Changelog:-

v1...v8 - NA

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

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

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

 xen/arch/arm/include/asm/mmio.h |  1 +
 xen/arch/arm/io.c   | 18 ++
 xen/arch/arm/ioreq.c|  9 -
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/mmio.h b/xen/arch/arm/include/asm/mmio.h
index ca259a79c2..79e64d9af8 100644
--- a/xen/arch/arm/include/asm/mmio.h
+++ b/xen/arch/arm/include/asm/mmio.h
@@ -35,6 +35,7 @@ enum instr_decode_state
  * instruction.
  */
 INSTR_LDR_STR_POSTINDEXING,
+INSTR_CACHE,/* Cache Maintenance instr */
 };
 
 typedef struct
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 6f458ee7fd..26c716b4a5 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -139,6 +139,17 @@ void try_decode_instruction(const struct cpu_user_regs 
*regs,
 return;
 }
 
+/*
+ * When the data abort is caused due to cache maintenance, Xen should check
+ * if the address belongs to an emulated MMIO region or not. The behavior
+ * will differ accordingly.
+ */
+if ( info->dabt.cache )
+{
+info->dabt_instr.state = INSTR_CACHE;
+return;
+}
+
 /*
  * Armv8 processor does not provide a valid syndrome for decoding some
  * instructions. So in order to process these instructions, Xen must
@@ -177,6 +188,13 @@ enum io_state try_handle_mmio(struct cpu_user_regs *regs,
 return rc;
 }
 
+/*
+ * When the data abort is caused due to cache maintenance and the address
+ * belongs to an emulated region, Xen should ignore this instruction.
+ */
+if ( info->dabt_instr.state == INSTR_CACHE )
+return IO_HANDLED;
+
 /*
  * At this point, we know that the instruction is either valid or has been
  * decoded successfully. Thus, Xen should be allowed to execute the
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 54167aebcb..cc66713386 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@ -47,7 +47,7 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
  struct vcpu *v, mmio_info_t *info)
 {
 struct vcpu_io *vio = >io;
-struct instr_details instr = info->dabt_instr;
+const struct instr_details instr = info->dabt_instr;
 struct hsr_dabt dabt = info->dabt;
 ioreq_t p = {
 .type = IOREQ_TYPE_COPY,
@@ -78,6 +78,13 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
 if ( !s )
 return IO_UNHANDLED;
 
+/*
+ * When the data abort is caused due to cache maintenance and the address
+ * belongs to an emulated region, Xen should ignore this instruction.
+ */
+if ( instr.state == INSTR_CACHE )
+return IO_HANDLED;
+
 ASSERT(dabt.valid);
 
 vio->req = p;
-- 
2.17.1

[PATCH v11 1/3] xen/arm64: io: Emulate instructions (with invalid ISS) on MMIO region

[Ayan Kumar Halder]

When an instruction is trapped in Xen due to translation fault, Xen
checks if the ISS is invalid (for data abort) or it is an instruction
abort. If so, Xen tries to resolve the translation fault using p2m page
tables. In case of data abort, Xen will try to map the mmio region to
the guest (ie tries to emulate the mmio region).

If the ISS is not valid and it is a data abort, then Xen tries to
decode the instruction. In case of ioreq, Xen  saves the decoding state,
rn and imm9 to vcpu_io. Whenever the vcpu handles the ioreq successfully,
it will read the decoding state to determine if the instruction decoded
was a ldr/str post indexing (ie INSTR_LDR_STR_POSTINDEXING). If so, it
uses these details to post increment rn.

In case of mmio handler, if the mmio operation was successful, then Xen
retrives the decoding state, rn and imm9. For state ==
INSTR_LDR_STR_POSTINDEXING, Xen will update rn.

If there is an error encountered while decoding/executing the instruction,
Xen will forward the abort to the guest.

Also, the logic to infer the type of instruction has been moved from
try_handle_mmio() to try_decode_instruction() which is called before.
try_handle_mmio() is solely responsible for handling the mmio operation.

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

Changelog :-

v2..v5 - Mentioned in the cover letter.

v6 - 1. Mantained the decoding state of the instruction. This is used by the
caller to either abort the guest or retry or ignore or perform read/write on
the mmio region.

2. try_decode() invokes decoding for both aarch64 and thumb state. (Previously
it used to invoke decoding only for aarch64 state). Thus, it handles all the
checking of the registers before invoking any decoding of instruction.
try_decode_instruction_invalid_iss() has thus been removed.

3. Introduced a new field('enum instr_decode_state state') inside
'struct instr_details'. This holds the decoding state of the instruction.
This is later read by the post_increment_register() to determine if rn needs to
be incremented. Also, this is read by the callers of try_decode_instruction()
to determine if the instruction was valid or ignored or to be retried or
error or decoded successfully.

4. Also stored 'instr_details' inside 'struct ioreq'. This enables
arch_ioreq_complete_mmio() to invoke post_increment_register() without decoding
the instruction again.

5. Check hsr.dabt.valid in do_trap_stage2_abort_guest(). If it is not valid,
then decode the instruction. This ensures that try_handle_mmio() is invoked only
when the instruction is either valid or decoded successfully.

6. Inside do_trap_stage2_abort_guest(), if hsr.dabt.valid is not set, then
resolve the translation fault before trying to decode the instruction. If
translation fault is resolved, then return to the guest to execute the 
instruction
again.


v7 - 1. Moved the decoding instruction details ie instr_details from 'struct 
ioreq'
to 'struct vcpu_io'.

2. The instruction is decoded only when we get a data abort.

3. Replaced ASSERT_UNREACHABLE() with domain_crash(). The reason being asserts
can be disabled in some builds. In this scenario when the guest's cpsr is in an
erroneous state, Xen should crash the guest.

4. Introduced check_p2m() which invokes p2m_resolve_translation_fault() and
try_map_mmio() to resolve translation fault by configuring the page tables. This
gets invoked first if ISS is invalid and it is an instruction abort. If it is
a data abort and hsr.dabt.s1ptw is set or try_handle_mmio() returns 
IO_UNHANDLED,
then check_p2m() gets invoked again.


v8 - 1. Removed the handling of data abort when info->dabt.cache is set. This 
will
be implemented in a subsequent patch. (Not as part of this series)

2. When the data abort is due to access to stage 1 translation tables, Xen will
try to fix the mapping of the page table for the corresponding address. If this
returns an error, Xen will abort the guest. Else, it will ask the guest to retry
the instruction.

3. Changed v->io.info.dabt_instr from pointer to variable. The reason being that
arch_ioreq_complete_mmio() is called from leave_hypervisor_to_guest().
That is after do_trap_stage2_abort_guest()  has been invoked. So the original
variable will be no longer valid.

4. Some other style issues pointed out in v7.


v9 - 1. Ensure that "Erratum 766422" is handled only when ISS is valid.

2. Whenever Xen receives and instruction abort or data abort (with invalid ISS),
Xen should first try to resolve the p2m translation fault or see if it it needs
to map a MMIO region. If it succeeds, it should return to the guest to retry the
instruction.

3. Removed handling of "dabt.s1ptw == 1" aborts. This is addressed in patch3 as
it is an existing bug in codebase.

4. Various style issues pointed by Julien in v8.


v10 - 1. Set 'dabt.valid=1' when the instruction is fully decoded. This is
checked in try_handle_mmio() and try_fwd_ioserv().

2. Various other style issues pointed in v9.


v11 - 1. Renamed post_increment_register() to 

[PATCH v11 2/3] xen/arm64: io: Handle the abort due to access to stage1 translation table

[Ayan Kumar Halder]

If the abort was caused due to access to stage1 translation table, Xen
will try to set the p2m entry (assuming that the Stage 1 translation
table is in a non MMIO region).
If there is no such entry found, then Xen will try to map the address as
a MMIO region (assuming that the Stage 1 translation table is in a
direct MMIO region).

If that fails as well, then there are the two following scenarios:-
1. Stage 1 translation table being in an emulated MMIO region - Xen
can read the region, but it has no way to return the value read to the
CPU page table walker (which tries to go through the stage1 tables to
resolve the translation fault).

2. Stage 1 translation table address is invalid.

In both the above scenarios, Xen will forward the abort to the guest.

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

Changelog :-

v1..v8 - NA

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

v10 - 1. Enabled checking for stage1 translation table address in the
MMIO region. The reason being Arm Arm does not have any restrictions.
2. Updated the commit message to explain all the possible scenarios.

v11 - 1. Fixed some wordings in comments and commit message (pointed
by Julien in v10).

 xen/arch/arm/io.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index fd903b7b03..6f458ee7fd 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -128,6 +128,17 @@ void try_decode_instruction(const struct cpu_user_regs 
*regs,
 return;
 }
 
+/*
+ * At this point, we know that the stage1 translation table is either in an
+ * emulated MMIO region or its address is invalid . This is not expected by
+ * Xen and thus it forwards the abort to the guest.
+ */
+if ( info->dabt.s1ptw )
+{
+info->dabt_instr.state = INSTR_ERROR;
+return;
+}
+
 /*
  * Armv8 processor does not provide a valid syndrome for decoding some
  * instructions. So in order to process these instructions, Xen must
-- 
2.17.1

[PATCH v11 0/3] xen/arm64: io: Decode ldr/str post-indexing instruction

[Ayan Kumar Halder]

Hi All,

The patch series continues with the support to decode instructions by Xen when
ISS is invalid. Currently, when the guest executes post indexing ldr/str 
instructions
on emulated MMIO, these instructions are trapped into Xen as a data abort.
Xen reads hsr_dabt.isv == 0, so ISS is invalid. Therefore, it reads the faulting
instruction's opcode from guest's PC. It decodes and executes the instruction on
the emulated region.

This is a continuation of the previous patch series "[XEN v10 0/4] xen/arm64: 
io:
Decode ldr/str post-indexing instruction". In the previous series, patches 2 and
3 had to be reverted as they cause a build break on x86 and boot failure on 
arm32.
Only patch 1 (ie "[XEN v10 1/4] xen/arm64: Decode ldr/str post increment 
operations"
was committed)

While doing the patch, we found two bugs in the codebase. I have addressed them
in patches 2 and 3. This was discussed with Julien on the IRC.

Ayan Kumar Halder (3):
  xen/arm64: io: Emulate instructions (with invalid ISS) on MMIO region
  xen/arm64: io: Handle the abort due to access to stage1 translation
table
  xen/arm64: io: Handle data abort due to cache maintenance instructions

 xen/arch/arm/arm32/traps.c|  12 +++
 xen/arch/arm/arm64/traps.c|  52 +
 xen/arch/arm/decode.c |   2 +
 xen/arch/arm/include/asm/domain.h |   4 +
 xen/arch/arm/include/asm/mmio.h   |  18 -
 xen/arch/arm/include/asm/traps.h  |   2 +
 xen/arch/arm/io.c | 117 +-
 xen/arch/arm/ioreq.c  |  15 +++-
 xen/arch/arm/traps.c  |  77 
 xen/arch/x86/include/asm/domain.h |   3 +
 xen/include/xen/sched.h   |   2 +
 11 files changed, 251 insertions(+), 53 deletions(-)

Changelog :-
v2 - 1. Updated the rn register after reading from it. (Pointed by Julien,
Stefano)
 2. Used a union to represent the instruction opcode (Suggestd by Bertrand)
 3. Fixed coding style issues (Pointed by Julien)
 4. In the previous patch, I was updating dabt->sign based on the signedness
of imm9. This was incorrect. As mentioned in ARMv8 ARM  DDI 0487G.b,
Page 3221, SSE indicates the signedness of the data item loaded. In our
case, the data item loaded is always unsigned.

v3- 1. Handled all the variants of ldr/str (ie 64, 32, 16, 8 bit variants).
   Thus, I have removed the check for "instr->code.opc == 0" (Suggested by
   Andre)
2. Handled the scenario when rn = SP, rt = XZR (Suggested by Jan, Andre)
3. Added restriction for "rt != rn" (Suggested by Andre)
4. Moved union ldr_str_instr_class {} to decode.h. This is the header 
included
   by io.c and decode.c (where the union is referred). (Suggested by Jan)
5. Indentation and typo fixes (Suggested by Jan)

v4- 1. Fixed the patch as per Stefano's comments on v3. They are as follows :-
1.1 Use macros to determine the fixed values in the instruction opcode
1.2 Checked if instr != NULL
1.3 Changed some data types and added #define ARM_64 for AArch64 
specific
code
1.4 Moved post_increment_register() to decode.c so that the decoding
logic is confined to a single file.
1.5 Moved some checks from post_increment_register() to
decode_loadstore_postindexing()
1.6 Removed a duplicate check
2. Updated the commit message as per Andre's comments.
3. Changed the names of a label and some comments. *32bit* was erroneously
   mentioned in a label and comments in decode_loadstore_postindexing()
   although the function handled all variants of ldr/str post indexing.

v5- 1. Renamed decode_loadstore_postindexing() to decode_arm64(). The reason
   being this will be extended in future to support more instructions for
   which hsr_badt.isv = 0
2. Introduce a function try_decode_instruction_invalid_iss() to determine
   if the instruction needs to be decoded before invoking 
decode_instruction().

   It checks :-
   2.1  dabt->s1ptw - Returns IO_UNHANDLED
   2.2  dabt->cache - Returns IO_IGNORED. (new enum instroduced to let the
caller know that the instruction needs to be ignored by Xen. Thus
the caller needs to increment the PC and return to the guest.

3. Invoked try_decode_instruction_invalid_iss() from the following 2 places 
:-
3.a - try_handle_mmio() - When we have determined that there is a valid
  mmio handler.
3.b - try_fwd_ioserv()
When ioserver completes the io request, the acknowledgement is sent via
handle_ioserv(). Here, we need to increment the register. As there is no
common data shared between try_fwd_ioserv() and handle_ioserv(), we need
to decode the instruction again in handle_ioserv() to determine rn, 
imm9.

(NOTE to Reviewers) - This does not feel correct. However, I could not
think of a better approach. 

Re: [PATCH 1/2] livepatch: do not ignore sections with 0 size

[Andrew Cooper]

On 17/03/2022 11:08, Roger Pau Monne wrote:
> A side effect of ignoring such sections is that symbols belonging to
> them won't be resolved, and that could make relocations belonging to
> other sections that reference those symbols fail.
>
> For example it's likely to have an empty .altinstr_replacement with
> symbols pointing to it, and marking the section as ignored will
> prevent the symbols from being resolved, which in turn will cause any
> relocations against them to fail.

I agree this is a bug in livepatch handling, but it's also an error in
the generated livepatch.  We should not have relocations to an empty
altinstr_replacement section in the first place.

This will probably be from the lfences, where the replacement in a nop
and takes no space.  I think I know how to fix this case.

~Andrew

Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu

[Jan Beulich]

On 10.03.2022 19:44, Tamas K Lengyel wrote:
> During VM fork resetting a failed vmentry has been observed when the reset
> is performed immediately after a STI instruction executed. This is due to
> the guest interruptibility state in the VMCS being modified by STI but the
> subsequent reset removes the IF bit from FLAGS, causing the failed vmentry.

I first thought this was backwards, but after re-reading a couple of
times I think the issue is merely with you stating this as if this
was what always happens, while it really depends on the state that
the VM is being reset to. I think it would further be helpful if you
made clear that other interruptibility state could also cause issues
when not properly restored. One way to express this would be to
simply insert "e.g." ahead of "a STI instruction".

> @@ -1155,6 +1154,8 @@ static int cf_check hvm_load_cpu_ctxt(struct domain *d, 
> hvm_domain_context_t *h)
>  v->arch.dr6   = ctxt.dr6;
>  v->arch.dr7   = ctxt.dr7;
>  
> +hvm_set_interrupt_shadow(v, ctxt.interruptibility_info);

Setting reserved bits as well as certain combinations of bits will
cause VM entry to fail. I think it would be nice to report this as
an error here rather than waiting for the VM entry failure.

> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -720,6 +720,22 @@ static inline int hvm_vmtrace_reset(struct vcpu *v)
>  return -EOPNOTSUPP;
>  }
>  
> +static inline unsigned long hvm_get_interrupt_shadow(struct vcpu *v)

unsigned long here and ...

> +{
> +if ( hvm_funcs.get_interrupt_shadow )
> +return alternative_call(hvm_funcs.get_interrupt_shadow, v);
> +
> +return -EOPNOTSUPP;
> +}
> +
> +static inline void
> +hvm_set_interrupt_shadow(struct vcpu *v, unsigned long val)

... here are not in line with the hooks' types. Same for the stubs
further down then.

> +{
> +if ( hvm_funcs.set_interrupt_shadow )
> +alternative_vcall(hvm_funcs.set_interrupt_shadow, v, val);
> +}
> +
> +
>  /*

Please don't insert multiple successive blank lines.

Jan

Re: [PATCH 2/2] livepatch: avoid relocations referencing ignored section symbols

[Roger Pau Monné]

On Thu, Mar 17, 2022 at 02:26:50PM +0100, Jan Beulich wrote:
> On 17.03.2022 12:08, Roger Pau Monne wrote:
> > Track whether symbols belong to ignored sections in order to avoid
> > applying relocations referencing those symbols. The address of such
> > symbols won't be resolved and thus the relocation will likely fail or
> > write garbage to the destination.
> > 
> > Return an error in that case, as leaving unresolved relocations would
> > lead to malfunctioning payload code.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> Reviewed-by: Jan Beulich 
> with one nit (which can likely be addressed while committing):
> 
> > --- a/xen/arch/arm/arm32/livepatch.c
> > +++ b/xen/arch/arm/arm32/livepatch.c
> > @@ -272,6 +272,13 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
> > elf->name, symndx);
> >  return -EINVAL;
> >  }
> > +else if ( elf->sym[symndx].ignored )
> > +{
> > +printk(XENLOG_ERR LIVEPATCH
> > +"%s: Relocation against ignored symbol %s cannot be 
> > resolved\n",
> > +elf->name, elf->sym[symndx].name);
> 
> Indentation here (and in the other two instances mirroring this)
> is off by one.

Oh, thanks, sorry for not noticing.

Roger.

Re: [PATCH 2/2] livepatch: avoid relocations referencing ignored section symbols

[Jan Beulich]

On 17.03.2022 12:08, Roger Pau Monne wrote:
> Track whether symbols belong to ignored sections in order to avoid
> applying relocations referencing those symbols. The address of such
> symbols won't be resolved and thus the relocation will likely fail or
> write garbage to the destination.
> 
> Return an error in that case, as leaving unresolved relocations would
> lead to malfunctioning payload code.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 
with one nit (which can likely be addressed while committing):

> --- a/xen/arch/arm/arm32/livepatch.c
> +++ b/xen/arch/arm/arm32/livepatch.c
> @@ -272,6 +272,13 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
> elf->name, symndx);
>  return -EINVAL;
>  }
> +else if ( elf->sym[symndx].ignored )
> +{
> +printk(XENLOG_ERR LIVEPATCH
> +"%s: Relocation against ignored symbol %s cannot be 
> resolved\n",
> +elf->name, elf->sym[symndx].name);

Indentation here (and in the other two instances mirroring this)
is off by one.

Jan

[ovmf test] 168661: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 5b56c52b5c1cc817a1ddac7f03aa6a02aeab4c04
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   17 days
Failing since168258  2022-03-01 01:55:31 Z   16 days  158 attempts
Testing same since   168637  2022-03-16 13:10:25 Z1 days8 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [PATCH 0/2] livepatch: fix handling of (some) relocations

[Jan Beulich]

On 17.03.2022 12:08, Roger Pau Monne wrote:
> I wonder whether it's possible to have unresolved symbols if we only
> ignore non SHF_ALLOC sections, so we could maybe error out earlier if we
> found a symbols that belongs to a non SHF_ALLOC section in
> livepatch_elf_resolve_symbols.  The current approach is more conservative
> as we would only report an error if we have unresolved symbols that are
> referenced in relocations.

I think it's better to remain that way. Symbols appearing in non-alloc
sections isn't wrong in any way, as long - as you say - there's no
relocation using them.

Jan

Re: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-enhanced functions

[Doebel, Bjoern]

On 17.03.22 11:00, Jiamei Xie wrote:



-Original Message-
From: Xen-devel  On Behalf Of
Jiamei Xie
Sent: 2022年3月17日 17:17
To: Ross Lagerwall ; Bjoern Doebel
; xen-devel@lists.xenproject.org
Cc: Michael Kurth ; Martin Pohlack
; Roger Pau Monne ;
Andrew Cooper ; Konrad Rzeszutek Wilk

Subject: RE: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
enhanced functions

Hi  Bjoern,


-Original Message-
From: Xen-devel  On Behalf Of
Ross Lagerwall
Sent: 2022年3月10日 1:12
To: Bjoern Doebel ; xen-devel@lists.xenproject.org
Cc: Michael Kurth ; Martin Pohlack
; Roger Pau Monne ;
Andrew Cooper ; Konrad Rzeszutek Wilk

Subject: Re: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
enhanced functions


From: Bjoern Doebel 
Sent: Wednesday, March 9, 2022 2:53 PM
To: xen-devel@lists.xenproject.org 
Cc: Michael Kurth ; Martin Pohlack

; Roger Pau Monne ;
Andrew Cooper ; Bjoern Doebel
; Konrad Rzeszutek Wilk ;
Ross Lagerwall 

Subject: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-

enhanced functions


Xen enabled CET for supporting architectures. The control flow aspect of
CET expects functions that can be called indirectly (i.e., via function
pointers) to start with an ENDBR64 instruction. Otherwise a control flow
exception is raised.

This expectation breaks livepatching flows because we patch functions by
overwriting their first 5 bytes with a JMP + , thus breaking the
ENDBR64. We fix this by checking the start of a patched function for
being ENDBR64. In the positive case we move the livepatch JMP to start
behind the ENDBR64 instruction.

To avoid having to guess the ENDBR64 offset again on patch reversal
(which might race with other mechanisms adding/removing ENDBR
dynamically), use the livepatch metadata to store the computed offset
along with the saved bytes of the overwritten function.

Signed-off-by: Bjoern Doebel 
Acked-by: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 


Reviewed-by: Ross Lagerwall 


Tested-by: Jiamei xie 

Cheers,
Jiamei

Sorry I forgot to add the scope I tested in last email. I tested it on armv8a. 
It worked fine and  didn't break arm.
Tested-by: Jiamei xie 


Thanks Jiamei!

As Jan already pointed out there's a v6 patch out already. It is only 
cosmetically different from this one. Unless you insist, I'd not roll a 
v7 only to add this tag?


Bjoern



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: [PATCH 0/2] livepatch: fix handling of (some) relocations

[Doebel, Bjoern]

On 17.03.22, 12:10, "Xen-devel on behalf of Roger Pau Monne" 
 
wrote:


Hello,

Relocations that reference symbols that belong to sections with a size
of 0 are not properly resolved, as the address of those symbols won't be
resolved in the first place.

Fix this by not ignoring sections with a size of 0, while still properly
handling the detection of whether a livepatch can be reapplied after
being reverted (patch 1).

Also detect whether any relocations reference unresolved symbols and
error out in that case, as those relocations cannot be resolved (patch
2).

I wonder whether it's possible to have unresolved symbols if we only
ignore non SHF_ALLOC sections, so we could maybe error out earlier if we
found a symbols that belongs to a non SHF_ALLOC section in
livepatch_elf_resolve_symbols.  The current approach is more conservative
as we would only report an error if we have unresolved symbols that are
referenced in relocations.

Thanks, Roger.

Roger Pau Monne (2):
  livepatch: do not ignore sections with 0 size
  livepatch: avoid relocations referencing ignored section symbols

 xen/arch/arm/arm32/livepatch.c  |  7 +++
 xen/arch/arm/arm64/livepatch.c  |  7 +++
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch.c  | 16 +++-
 xen/common/livepatch_elf.c  |  6 ++
 xen/include/xen/livepatch_elf.h |  3 ++-
 6 files changed, 40 insertions(+), 6 deletions(-)

--
2.34.1

I checked the x86 part and confirmed that my previously non-working livepatch 
loads now.

Tested-by: Bjoern Doebel 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux70f77a2cb5281ad0b08a0bbdeeba885984c399dd
baseline version:
 linux

[ovmf test] 168653: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 5b56c52b5c1cc817a1ddac7f03aa6a02aeab4c04
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   17 days
Failing since168258  2022-03-01 01:55:31 Z   16 days  157 attempts
Testing same since   168637  2022-03-16 13:10:25 Z0 days7 attempts


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

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



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

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

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

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


Not pushing.

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

Re: [PATCH] x86/cet: Use dedicated NOP4 for cf_clobber

[Andrew Cooper]

On 17/03/2022 10:43, Jan Beulich wrote:
> On 17.03.2022 11:02, Andrew Cooper wrote:
>> For livepatching, we need to look at a potentially clobbered function and
>> determine whether it used to have an ENDBR64 instruction.
>>
>> Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
>> check-endbr.sh to look for it.
>>
>> The choice of nop has some complicated consequences.  nopw (%rax) has a ModRM
>> byte of 0, which the Bourne compatible shells unconditionally strip from
>> parameters, meaning that we can't pass it to `grep -aob`.
> Urgh. But as per my earlier comments I'm happier with ...
>
>> Therefore, use nopw (%rcx) so the ModRM byte becomes 1.
> ... a non-zero ModR/M byte anyway.
>
>> This then demonstrates another bug.  Under perl regexes, \1 thru \9 are
>> subpattern matches, and not octal escapes.  Switch the `grep -P` runes to use
>> hex escapes instead.
>>
>> The build time check then requires that the endbr64 poison have the same
>> treatment as endbr64 to avoid placing the byte pattern in immediate operands.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
>
>> Jan: As you had the buggy grep, can you please confirm that hex escapes work.
> (Build-)Tested-by: Jan Beulich 

Thanks.

>
> When working out the workaround, I actually did test with hex, but
> then switched to octal to make easily visible that the two patterns
> actually match. I also did wonder about octal and sub-pattern
> matching conflicting, but the grep I used definitely didn't have
> an issue there. Hence I assume grep behavior changed at some point;
> I wonder how they mean to have octal expressed now.

$ LC_ALL=C grep -aobP '\363\17\36\372|\146\17\37\1' text.bin
grep: reference to non-existent subpattern

> https://perldoc.perl.org/perlre specifically outlines how the
> conflict is dealt with - assuming you have observed grep to misbehave,
> I wonder whether they've accumulated a bug. (The doc also makes clear
> that such references aren't limited to single digit numbers; you may
> want to adjust your description in this regard.)

That part of the doc does say that the dynamic interpretation is only
for \10 and higher, so I don't think this is a bug.  \1 use to
exclusively mean the first capture group, not an octal character, and
this behaviour remains.

> Depending on how exactly your grep behaves, switching to always-three-
> digit octal escapes may be an alternative to retain the property of
> making obvious the similarity between the two pattern representations.

\01 and \001 do both work properly, but the non-ambiguous forms are \o1
or \o001.

Overall, I think it's better to stay with the hex escapes, because
they're also non-ambiguous.  The mix of octal and hex is irritating, but
the comments are very clear about what we're searching for.


And on that note, I realise we can also scan for endbr32 in exactly the
same way for no extra cost.  I'll fold that in too, seeing as the
discussion has come up before, and post a v3.

~Andrew

v2: XTF on arm

[Michal Orzel]

Hello,

Following up a discussion from the v1 of "XTF on arm" patch series(it's been 
almost a year),
I created a new version with the following major changes:
-fixed comments from v1
-no non-MMU environment for arm64
-no PL011 driver
-no test-naming/xtf-runner modifications to make OSSTEST happy

Please review, comment, ask questions.

Link to the v2:
https://github.com/andyhhp/xtf/pull/6

Cheers,
Michal

Re: [PATCH 1/3] tools/xenstore: add documentation for new set/get-feature commands

[Juergen Gross]

On 17.03.22 12:07, Julien Grall wrote:

Hi Juergen,

On 16/03/2022 16:10, Juergen Gross wrote:

Add documentation for two new Xenstore wire commands SET_FEATURE and
GET_FEATURE used to set or query the Xenstore features visible in the
ring page of a given domain.

Signed-off-by: Juergen Gross 
---
  docs/misc/xenstore-ring.txt |  1 +
  docs/misc/xenstore.txt  | 12 
  2 files changed, 13 insertions(+)

diff --git a/docs/misc/xenstore-ring.txt b/docs/misc/xenstore-ring.txt
index f91accb5b0..bd000f694e 100644
--- a/docs/misc/xenstore-ring.txt
+++ b/docs/misc/xenstore-ring.txt
@@ -68,6 +68,7 @@ Mask    Description


I find a bit odd we describe the feature in term of mask rather bit. This will 
get more difficult to read as we add more bits.


Maybe this is in order to avoid big/little endian issues (which bit is
bit 0?)



This is not new, so not change expected in this series.


  -
  1   Ring reconnection (see the ring reconnection feature below)
  2   Connection error indicator (see connection error feature below)
+4   GET_FEATURE and SET_FEATURE Xenstore wire commands are available


Below, you wrote the two commands are dom0 only. Furthermore, I would expect 
such comment return something like ENOSYS if they are not present.


So do we really need to add a feature bit for GET_FEATURE/SET_FEATURE?


Good question. I'd be fine to drop it.




  The "Connection state" field is used to request a ring close and reconnect.
  The "Connection state" field only contains valid data if the server has
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index ea3d8be177..31e3d53c52 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -332,6 +332,18 @@ SET_TARGET    ||
  xenstored prevents the use of SET_TARGET other than by dom0.
+GET_FEATURE    |    |


Did you indented to add many spaces before ?


+SET_FEATURE    ||
+    Returns or sets the contents of the "feature" field located at
+    offset 2064 of the Xenstore ring page of the domain specified by
+    .  is a decimal number being a logical or of the
+    feature bits as defined in docs/misc/xenstore-ring.txt. Trying
+    to set a bit for a feature not being supported by the running
+    Xenstore will be denied.
How will the caller know which feature is supported? Also, what happen if a 
client decided to overwrite 'feature'? Could the result potentially prevent 
migration/liveupdate or else?


The caller could use "GET_FEATURE 0" to see the available features, assuming
that nobody would have changed dom0's features.

I'm not sure whether we should prevent dom0's features to be overwritten.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 1/3] tools/xenstore: add documentation for new set/get-feature commands

[Julien Grall]

On 17/03/2022 11:07, Julien Grall wrote:

Hi Juergen,

On 16/03/2022 16:10, Juergen Gross wrote:

Add documentation for two new Xenstore wire commands SET_FEATURE and
GET_FEATURE used to set or query the Xenstore features visible in the
ring page of a given domain.

Signed-off-by: Juergen Gross 
---
  docs/misc/xenstore-ring.txt |  1 +
  docs/misc/xenstore.txt  | 12 
  2 files changed, 13 insertions(+)

diff --git a/docs/misc/xenstore-ring.txt b/docs/misc/xenstore-ring.txt
index f91accb5b0..bd000f694e 100644
--- a/docs/misc/xenstore-ring.txt
+++ b/docs/misc/xenstore-ring.txt
@@ -68,6 +68,7 @@ Mask    Description


I find a bit odd we describe the feature in term of mask rather bit. 
This will get more difficult to read as we add more bits.


This is not new, so not change expected in this series.


  -
  1   Ring reconnection (see the ring reconnection feature below)
  2   Connection error indicator (see connection error feature below)
+4   GET_FEATURE and SET_FEATURE Xenstore wire commands are available


Below, you wrote the two commands are dom0 only. Furthermore, I would 
expect such comment return something like ENOSYS if they are not present.


So do we really need to add a feature bit for GET_FEATURE/SET_FEATURE?

  The "Connection state" field is used to request a ring close and 
reconnect.

  The "Connection state" field only contains valid data if the server has
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index ea3d8be177..31e3d53c52 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -332,6 +332,18 @@ SET_TARGET    ||
  xenstored prevents the use of SET_TARGET other than by dom0.
+GET_FEATURE    |    |


Did you indented to add many spaces before ?


Please ignore this question.   is part of the response. Sorry for 
the noise.


Cheers,




+SET_FEATURE    ||
+    Returns or sets the contents of the "feature" field located at
+    offset 2064 of the Xenstore ring page of the domain specified by
+    .  is a decimal number being a logical or of the
+    feature bits as defined in docs/misc/xenstore-ring.txt. Trying
+    to set a bit for a feature not being supported by the running
+    Xenstore will be denied.
How will the caller know which feature is supported? Also, what happen 
if a client decided to overwrite 'feature'? Could the result potentially 
prevent migration/liveupdate or else?


Cheers,



--
Julien Grall

[PATCH 1/2] livepatch: do not ignore sections with 0 size

[Roger Pau Monne]

A side effect of ignoring such sections is that symbols belonging to
them won't be resolved, and that could make relocations belonging to
other sections that reference those symbols fail.

For example it's likely to have an empty .altinstr_replacement with
symbols pointing to it, and marking the section as ignored will
prevent the symbols from being resolved, which in turn will cause any
relocations against them to fail.

In order to solve this do not ignore sections with 0 size, only ignore
sections that don't have the SHF_ALLOC flag set.

Special case such empty sections in move_payload so they are not taken
into account in order to decide whether a livepatch can be safely
re-applied after a revert.

Fixes: 98b728a7b2 ('livepatch: Disallow applying after an revert')
Signed-off-by: Roger Pau Monné 
---
 xen/common/livepatch.c  | 16 +++-
 xen/include/xen/livepatch_elf.h |  2 +-
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index be2cf75c2d..abc1cae136 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -300,9 +300,6 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
  * and .shstrtab. For the non-relocate we allocate and copy these
  * via other means - and the .rel we can ignore as we only use it
  * once during loading.
- *
- * Also ignore sections with zero size. Those can be for example:
- * data, or .bss.
  */
 if ( livepatch_elf_ignore_section(elf->sec[i].sec) )
 offset[i] = UINT_MAX;
@@ -361,8 +358,17 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
 else if ( elf->sec[i].sec->sh_flags & SHF_WRITE )
 {
 buf = rw_buf;
-rw_buf_sec = i;
-rw_buf_cnt++;
+if ( elf->sec[i].sec->sh_size )
+{
+/*
+ * Special handling of RW empty regions: do not account for
+ * them in order to decide whether a patch can safely be
+ * re-applied, but assign them a load address so symbol
+ * resolution and relocations work.
+ */
+rw_buf_sec = i;
+rw_buf_cnt++;
+}
 }
 else
 buf = ro_buf;
diff --git a/xen/include/xen/livepatch_elf.h b/xen/include/xen/livepatch_elf.h
index 9ad499ee8b..5b1ec469da 100644
--- a/xen/include/xen/livepatch_elf.h
+++ b/xen/include/xen/livepatch_elf.h
@@ -48,7 +48,7 @@ int livepatch_elf_perform_relocs(struct livepatch_elf *elf);
 
 static inline bool livepatch_elf_ignore_section(const Elf_Shdr *sec)
 {
-return !(sec->sh_flags & SHF_ALLOC) || sec->sh_size == 0;
+return !(sec->sh_flags & SHF_ALLOC);
 }
 #endif /* __XEN_LIVEPATCH_ELF_H__ */
 
-- 
2.34.1

[PATCH 2/2] livepatch: avoid relocations referencing ignored section symbols

[Roger Pau Monne]

Track whether symbols belong to ignored sections in order to avoid
applying relocations referencing those symbols. The address of such
symbols won't be resolved and thus the relocation will likely fail or
write garbage to the destination.

Return an error in that case, as leaving unresolved relocations would
lead to malfunctioning payload code.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/arm/arm32/livepatch.c  | 7 +++
 xen/arch/arm/arm64/livepatch.c  | 7 +++
 xen/arch/x86/livepatch.c| 7 +++
 xen/common/livepatch_elf.c  | 6 ++
 xen/include/xen/livepatch_elf.h | 1 +
 5 files changed, 28 insertions(+)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 5a06467008..6aed227818 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -272,6 +272,13 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
elf->name, symndx);
 return -EINVAL;
 }
+else if ( elf->sym[symndx].ignored )
+{
+printk(XENLOG_ERR LIVEPATCH
+"%s: Relocation against ignored symbol %s cannot be 
resolved\n",
+elf->name, elf->sym[symndx].name);
+return -EINVAL;
+}
 
 val = elf->sym[symndx].sym->st_value; /* S */
 
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 6ec8dc60f0..655ded33d2 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -270,6 +270,13 @@ int arch_livepatch_perform_rela(struct livepatch_elf *elf,
elf->name, symndx);
 return -EINVAL;
 }
+else if ( elf->sym[symndx].ignored )
+{
+printk(XENLOG_ERR LIVEPATCH
+"%s: Relocation against ignored symbol %s cannot be 
resolved\n",
+elf->name, elf->sym[symndx].name);
+return -EINVAL;
+}
 
 val = elf->sym[symndx].sym->st_value +  r->r_addend; /* S+A */
 
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 37c9b8435e..a928e5bfcd 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -262,6 +262,13 @@ int arch_livepatch_perform_rela(struct livepatch_elf *elf,
elf->name, symndx);
 return -EINVAL;
 }
+else if ( elf->sym[symndx].ignored )
+{
+printk(XENLOG_ERR LIVEPATCH
+"%s: Relocation against ignored symbol %s cannot be 
resolved\n",
+elf->name, elf->sym[symndx].name);
+return -EINVAL;
+}
 
 val = r->r_addend + elf->sym[symndx].sym->st_value;
 
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index b089cacb1c..45d73912a3 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -334,7 +334,13 @@ int livepatch_elf_resolve_symbols(struct livepatch_elf 
*elf)
 }
 
 if ( livepatch_elf_ignore_section(elf->sec[idx].sec) )
+{
+dprintk(XENLOG_DEBUG, LIVEPATCH
+"%s: Symbol %s from section %s ignored\n",
+elf->name, elf->sym[i].name, elf->sec[idx].name);
+elf->sym[i].ignored = true;
 break;
+}
 
 st_value += (unsigned long)elf->sec[idx].load_addr;
 if ( elf->sym[i].name )
diff --git a/xen/include/xen/livepatch_elf.h b/xen/include/xen/livepatch_elf.h
index 5b1ec469da..7116deaddc 100644
--- a/xen/include/xen/livepatch_elf.h
+++ b/xen/include/xen/livepatch_elf.h
@@ -22,6 +22,7 @@ struct livepatch_elf_sec {
 struct livepatch_elf_sym {
 const Elf_Sym *sym;
 const char *name;
+bool ignored;
 };
 
 struct livepatch_elf {
-- 
2.34.1

[PATCH 0/2] livepatch: fix handling of (some) relocations

[Roger Pau Monne]

Hello,

Relocations that reference symbols that belong to sections with a size
of 0 are not properly resolved, as the address of those symbols won't be
resolved in the first place.

Fix this by not ignoring sections with a size of 0, while still properly
handling the detection of whether a livepatch can be reapplied after
being reverted (patch 1).

Also detect whether any relocations reference unresolved symbols and
error out in that case, as those relocations cannot be resolved (patch
2).

I wonder whether it's possible to have unresolved symbols if we only
ignore non SHF_ALLOC sections, so we could maybe error out earlier if we
found a symbols that belongs to a non SHF_ALLOC section in
livepatch_elf_resolve_symbols.  The current approach is more conservative
as we would only report an error if we have unresolved symbols that are
referenced in relocations.

Thanks, Roger.

Roger Pau Monne (2):
  livepatch: do not ignore sections with 0 size
  livepatch: avoid relocations referencing ignored section symbols

 xen/arch/arm/arm32/livepatch.c  |  7 +++
 xen/arch/arm/arm64/livepatch.c  |  7 +++
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch.c  | 16 +++-
 xen/common/livepatch_elf.c  |  6 ++
 xen/include/xen/livepatch_elf.h |  3 ++-
 6 files changed, 40 insertions(+), 6 deletions(-)

-- 
2.34.1

Re: [PATCH 1/3] tools/xenstore: add documentation for new set/get-feature commands

[Julien Grall]

Hi Juergen,

On 16/03/2022 16:10, Juergen Gross wrote:

Add documentation for two new Xenstore wire commands SET_FEATURE and
GET_FEATURE used to set or query the Xenstore features visible in the
ring page of a given domain.

Signed-off-by: Juergen Gross 
---
  docs/misc/xenstore-ring.txt |  1 +
  docs/misc/xenstore.txt  | 12 
  2 files changed, 13 insertions(+)

diff --git a/docs/misc/xenstore-ring.txt b/docs/misc/xenstore-ring.txt
index f91accb5b0..bd000f694e 100644
--- a/docs/misc/xenstore-ring.txt
+++ b/docs/misc/xenstore-ring.txt
@@ -68,6 +68,7 @@ MaskDescription


I find a bit odd we describe the feature in term of mask rather bit. 
This will get more difficult to read as we add more bits.


This is not new, so not change expected in this series.


  -
  1   Ring reconnection (see the ring reconnection feature below)
  2   Connection error indicator (see connection error feature below)
+4   GET_FEATURE and SET_FEATURE Xenstore wire commands are available


Below, you wrote the two commands are dom0 only. Furthermore, I would 
expect such comment return something like ENOSYS if they are not present.


So do we really need to add a feature bit for GET_FEATURE/SET_FEATURE?

  
  The "Connection state" field is used to request a ring close and reconnect.

  The "Connection state" field only contains valid data if the server has
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index ea3d8be177..31e3d53c52 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -332,6 +332,18 @@ SET_TARGET ||
  
  	xenstored prevents the use of SET_TARGET other than by dom0.
  
+GET_FEATURE		|		|


Did you indented to add many spaces before ?


+SET_FEATURE||
+   Returns or sets the contents of the "feature" field located at
+   offset 2064 of the Xenstore ring page of the domain specified by
+   .  is a decimal number being a logical or of the
+   feature bits as defined in docs/misc/xenstore-ring.txt. Trying
+   to set a bit for a feature not being supported by the running
+   Xenstore will be denied.
How will the caller know which feature is supported? Also, what happen 
if a client decided to overwrite 'feature'? Could the result potentially 
prevent migration/liveupdate or else?


Cheers,

--
Julien Grall

Re: [PATCH] x86/hvm: Include interruptibility state in hvm_hw_cpu

[Tamas K Lengyel]

On Thu, Mar 17, 2022, 2:09 AM Tian, Kevin  wrote:

> > From: Tamas K Lengyel 
> > Sent: Monday, March 14, 2022 8:14 PM
> >
> > On Mon, Mar 14, 2022 at 3:22 AM Tian, Kevin 
> wrote:
> > >
> > > > From: Lengyel, Tamas 
> > > > Sent: Friday, March 11, 2022 2:45 AM
> > > >
> > > > During VM fork resetting a failed vmentry has been observed when the
> > reset
> > > > is performed immediately after a STI instruction executed. This is
> due to
> > > > the guest interruptibility state in the VMCS being modified by STI
> but the
> > > > subsequent reset removes the IF bit from FLAGS, causing the failed
> > vmentry.
> > >
> > > I didn't get the rationale here. Before this patch the
> interruptibility state is
> > > not saved/restored thus I suppose after reset it will be cleared thus
> aligned
> > > with RFLAGS.IF=0. Can you elaborate a bit how exactly above problem is
> > > caused?
> >
> > The problem is that the interruptibility state is not cleared and thus
> > isn't aligned with RFLAGS.IF=0 after RFLAGS is reset. They go out of
> > sync leading to the failed vmentry. The interruptibility state needs
> > to be included in the hvm hw cpu struct for it to get re-aligned
> > during reset to avoid the failed vmentry.
>
> I'm still confused here. The interruptibility state should have bit 0 as 1
> after a STI instruction is executed (RFLAGS.IF=1). Saving/restoring it
> still doesn't match RFLAGS.IF=0 after vm fork reset. So I didn't understand
> how this patch actually fixes the problem.
>

I think I see where the confusion is. We are saving the context of the
parent vm and restoring it in the fork during a reset. That's what a reset
is. So by including the field in the struct means it will be reset to be in
sync with RFLAGS of the parent vm. Right now only the RFLAGS is copied from
the parent and interruptibility state isn't touched at all.


Also if there is a real problem shouldn't we just reset the interruptbility
> state to match RFLAGS.IF=0?
>

Yes, exactly what this patch achieves. Looking at it more I think the rest
of the non-register cpu state should similarly be included so those would
get reset too (activity & pending dbg).


> >
> > >
> > > >
> > > > Include the interruptibility state information in the public
> hvm_hw_cpu
> > struct
> > > > so that the CPU can be safely saved/restored.
> > > >
> > > > Signed-off-by: Tamas K Lengyel 
> > > > ---
> > > >  xen/arch/x86/hvm/hvm.c |  9 +
> > > >  xen/arch/x86/hvm/vmx/vmx.c |  4 
> > > >  xen/arch/x86/include/asm/hvm/hvm.h | 26
> > >
> > > Why is this change only applied to vmx instead of svm?
> >
> > VM forking is implemented only for vmx, thus this change is only
> > relevant where a VM would be immediately reset after a STI
>
> but the ops is generic and SVM already has the related callbacks.
>
> > instruction. Normal VM save/restore/migration doesn't attempt to
> > capture a VM state immediately after STI thus it's not relevant for
> > SVM.
> >
>
> Can you elaborate why save/restore/migration won't happen
> right after STI while it does for vm fork?
>

This is just based on my observation that noone has encountered this issue
in the long life of Xen. If I'm wrong and this cornercase could be
encountered during normal routes I can wire in SVM too. I ran into this
with vm forks because we are resetting the forks very very often (thousands
of times per second) under various execution paths with the fuzzer and one
happened to hit reset just after STI.

Another question I would be interested to hear from the maintainers is in
regards to the hvm context compat macros. Right now they differentiate
between hvm hw cpu struct versions based on size. So since this patch
doesn't change the size how is that supposed to work? Or if there are more
then two versions of the struct? The compat version never changes?

Tamas

>

Re: [XEN PATCH] evtchn/fifo: Don't set PENDING bit if guest misbehaves

[Raphael Ning]

On 16/03/2022 18:58, Andrew Cooper wrote:
> On 16/03/2022 18:38, Raphael Ning wrote:
>> From: Raphael Ning 
>>
>> Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
>> if it fails to lock the FIFO event queue(s), or if the guest has not
>> initialized the FIFO control block for the target vCPU. A well-behaved
>> guest should never trigger either of these cases.
>>
>> There is no good reason to set the PENDING bit (the guest should not
>> depend on this behaviour anyway) or check for pollers in such corner
>> cases, so skip that. In fact, both the comment above the for loop and
>> the commit message for
>>
>>  41a822c39263 xen/events: rework fifo queue locking
>>
>> suggest that the bit should be set after the FIFO queue(s) are locked.
>>
>> Take the opportunity to rename the was_pending variable (flipping its
>> sense) and switch to the standard bool type.
>>
>> Suggested-by: David Vrabel 
>> Signed-off-by: Raphael Ning 
>> ---
>>  xen/common/event_fifo.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c
>> index ed4d3beb10f3..6c74ccebebb7 100644
>> --- a/xen/common/event_fifo.c
>> +++ b/xen/common/event_fifo.c
>> @@ -165,7 +165,7 @@ static void cf_check evtchn_fifo_set_pending(
>>  unsigned int port;
>>  event_word_t *word;
>>  unsigned long flags;
>> -bool_t was_pending;
>> +bool_t check_pollers = false;
> Considering your commit message, did you intend to change this to bool?
>
> Can be fixed on commit.  Acked-by: Andrew Cooper 


My mistake, I missed that when rebasing the patch.


>
> ~Andrew
>
> P.S. David - do you want your maintainership back?  None of this code
> has undergone any major changes since you wrote it.

Re: [PATCH] x86/cet: Use dedicated NOP4 for cf_clobber

[Jan Beulich]

On 17.03.2022 11:02, Andrew Cooper wrote:
> For livepatching, we need to look at a potentially clobbered function and
> determine whether it used to have an ENDBR64 instruction.
> 
> Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
> check-endbr.sh to look for it.
> 
> The choice of nop has some complicated consequences.  nopw (%rax) has a ModRM
> byte of 0, which the Bourne compatible shells unconditionally strip from
> parameters, meaning that we can't pass it to `grep -aob`.

Urgh. But as per my earlier comments I'm happier with ...

> Therefore, use nopw (%rcx) so the ModRM byte becomes 1.

... a non-zero ModR/M byte anyway.

> This then demonstrates another bug.  Under perl regexes, \1 thru \9 are
> subpattern matches, and not octal escapes.  Switch the `grep -P` runes to use
> hex escapes instead.
> 
> The build time check then requires that the endbr64 poison have the same
> treatment as endbr64 to avoid placing the byte pattern in immediate operands.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

> Jan: As you had the buggy grep, can you please confirm that hex escapes work.

(Build-)Tested-by: Jan Beulich 

When working out the workaround, I actually did test with hex, but
then switched to octal to make easily visible that the two patterns
actually match. I also did wonder about octal and sub-pattern
matching conflicting, but the grep I used definitely didn't have
an issue there. Hence I assume grep behavior changed at some point;
I wonder how they mean to have octal expressed now.
https://perldoc.perl.org/perlre specifically outlines how the
conflict is dealt with - assuming you have observed grep to misbehave,
I wonder whether they've accumulated a bug. (The doc also makes clear
that such references aren't limited to single digit numbers; you may
want to adjust your description in this regard.)

Depending on how exactly your grep behaves, switching to always-three-
digit octal escapes may be an alternative to retain the property of
making obvious the similarity between the two pattern representations.

Jan

Re: [XEN v10 4/4] xen/arm64: io: Handle data abort due to cache maintenance instructions

[Ayan Kumar Halder]

Hi Julien,

On 11/03/2022 18:34, Julien Grall wrote:

Hi,

On 10/03/2022 17:45, Ayan Kumar Halder wrote:

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

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

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

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

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

Changelog:-

v1...v8 - NA

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

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

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

diff --git a/xen/arch/arm/include/asm/mmio.h 
b/xen/arch/arm/include/asm/mmio.h

index ca259a79c2..79e64d9af8 100644
--- a/xen/arch/arm/include/asm/mmio.h
+++ b/xen/arch/arm/include/asm/mmio.h
@@ -35,6 +35,7 @@ enum instr_decode_state
   * instruction.
   */
  INSTR_LDR_STR_POSTINDEXING,
+    INSTR_CACHE,    /* Cache Maintenance instr */
  };
    typedef struct
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index e6c77e16bf..c5b2980a5f 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -139,6 +139,17 @@ void try_decode_instruction(const struct 
cpu_user_regs *regs,

  return;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance, Xen 
should check
+ * if the address belongs to an emulated MMIO region or not. The 
behavior

+ * will differ accordingly.
+ */
+    if ( info->dabt.cache )
+    {
+    info->dabt_instr.state = INSTR_CACHE;
+    return;
+    }
+
  /*
   * Armv8 processor does not provide a valid syndrome for 
decoding some
   * instructions. So in order to process these instructions, Xen 
must
@@ -177,6 +188,15 @@ enum io_state try_handle_mmio(struct 
cpu_user_regs *regs,

  return rc;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance and 
the address
+ * belongs to an emulated region, Xen should ignore this 
instruction.

+ */
+    if ( info->dabt_instr.state == INSTR_CACHE )
+    {
+    return IO_HANDLED;
+    }
+
  /*
   * At this point, we know that the instruction is either valid 
or has been
   * decoded successfully. Thus, Xen should be allowed to execute 
the

diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index cc9bf23213..0dd2d452f7 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@ -29,10 +29,14 @@ enum io_state handle_ioserv(struct cpu_user_regs 
*regs, struct vcpu *v)

  const struct hsr_dabt dabt = hsr.dabt;
  /* Code is similar to handle_read */
  register_t r = v->io.req.data;
+    const struct instr_details instr = v->io.info.dabt_instr;
    /* We are done with the IO */
  v->io.req.state = STATE_IOREQ_NONE;
  +    if ( instr.state == INSTR_CACHE )
+    return IO_HANDLED;


The request will not be forwarded to the IOREQ, so why do we need 
check instr.state here?


I think it is not needed for the following reason.

leave_hypervisor_to_guest() ---> check_for_vcpu_work() --> 
vcpu_ioreq_handle_completion() --> get_pending_vcpu(v, ) will return 
NULL. Is my understanding correct ?


- Ayan




+
  if ( dabt.write )
  return IO_HANDLED;
  @@ -47,7 +51,7 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs 
*regs,

   struct vcpu *v, mmio_info_t *info)
  {
  struct vcpu_io *vio = >io;
-    struct instr_details instr = info->dabt_instr;
+    const struct instr_details instr = info->dabt_instr; >   
struct hsr_dabt dabt = info->dabt;

  ioreq_t p = {
  .type = IOREQ_TYPE_COPY,
@@ -78,6 +82,15 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs 
*regs,

  if ( !s )
  return IO_UNHANDLED;
  +    /*
+ * When the data abort is caused due to cache maintenance and 
the address
+ * belongs to an emulated region, Xen should ignore this 
instruction.

+ */
+    if ( instr.state == INSTR_CACHE )
+    {
+    return IO_HANDLED;
+    

Re: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-enhanced functions

[Jan Beulich]

On 17.03.2022 11:00, Jiamei Xie wrote:
>> -Original Message-
>> From: Xen-devel  On Behalf Of
>> Jiamei Xie
>> Sent: 2022年3月17日 17:17
>>
>>> -Original Message-
>>> From: Xen-devel  On Behalf Of
>>> Ross Lagerwall
>>> Sent: 2022年3月10日 1:12
>>> To: Bjoern Doebel ; xen-devel@lists.xenproject.org
>>> Cc: Michael Kurth ; Martin Pohlack
>>> ; Roger Pau Monne ;
>>> Andrew Cooper ; Konrad Rzeszutek Wilk
>>> 
>>> Subject: Re: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
>>> enhanced functions
>>>
 From: Bjoern Doebel 
 Sent: Wednesday, March 9, 2022 2:53 PM
 To: xen-devel@lists.xenproject.org 
 Cc: Michael Kurth ; Martin Pohlack
>>> ; Roger Pau Monne ;
>>> Andrew Cooper ; Bjoern Doebel
>>> ; Konrad Rzeszutek Wilk ;
>>> Ross Lagerwall 
 Subject: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
>>> enhanced functions

 Xen enabled CET for supporting architectures. The control flow aspect of
 CET expects functions that can be called indirectly (i.e., via function
 pointers) to start with an ENDBR64 instruction. Otherwise a control flow
 exception is raised.

 This expectation breaks livepatching flows because we patch functions by
 overwriting their first 5 bytes with a JMP + , thus breaking the
 ENDBR64. We fix this by checking the start of a patched function for
 being ENDBR64. In the positive case we move the livepatch JMP to start
 behind the ENDBR64 instruction.

 To avoid having to guess the ENDBR64 offset again on patch reversal
 (which might race with other mechanisms adding/removing ENDBR
 dynamically), use the livepatch metadata to store the computed offset
 along with the saved bytes of the overwritten function.

 Signed-off-by: Bjoern Doebel 
 Acked-by: Konrad Rzeszutek Wilk 
 CC: Ross Lagerwall 
>>>
>>> Reviewed-by: Ross Lagerwall 
>>
>> Tested-by: Jiamei xie 
>>
>> Cheers,
>> Jiamei
> Sorry I forgot to add the scope I tested in last email. I tested it on 
> armv8a. It worked fine and  didn't break arm.
> Tested-by: Jiamei xie 

Yet in any event there's meanwhile been a v6, so I'm unsure of taking the
tag over there.

Jan

[xen-unstable test] 168642: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw broken

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  5 host-install(5)  broken pass in 168633
 test-armhf-armhf-examine  5 host-install broken pass in 168633
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail pass in 168633
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 
168633

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

[PATCH] x86/cet: Use dedicated NOP4 for cf_clobber

[Andrew Cooper]

For livepatching, we need to look at a potentially clobbered function and
determine whether it used to have an ENDBR64 instruction.

Use a non-default 4-byte P6 long nop, not emitted by toolchains, and extend
check-endbr.sh to look for it.

The choice of nop has some complicated consequences.  nopw (%rax) has a ModRM
byte of 0, which the Bourne compatible shells unconditionally strip from
parameters, meaning that we can't pass it to `grep -aob`.

Therefore, use nopw (%rcx) so the ModRM byte becomes 1.

This then demonstrates another bug.  Under perl regexes, \1 thru \9 are
subpattern matches, and not octal escapes.  Switch the `grep -P` runes to use
hex escapes instead.

The build time check then requires that the endbr64 poison have the same
treatment as endbr64 to avoid placing the byte pattern in immediate operands.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Bjoern Doebel 
CC: Michael Kurth 
CC: Martin Pohlack 

v2:
 * Check for the poison byte pattern in check-endbr.sh
 * Use nopw (%rcx) to work around shell NUL (mis)features
 * Use hex escapes to work around Perl subpattern matches

Jan: As you had the buggy grep, can you please confirm that hex escapes work.
---
 xen/arch/x86/alternative.c   |  2 +-
 xen/arch/x86/include/asm/endbr.h | 26 ++
 xen/tools/check-endbr.sh | 12 +++-
 3 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index d41eeef1bcaf..0c6fc7b4fb0c 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -362,7 +362,7 @@ static void init_or_livepatch _apply_alternatives(struct 
alt_instr *start,
 if ( !is_kernel_text(ptr) || !is_endbr64(ptr) )
 continue;
 
-add_nops(ptr, ENDBR64_LEN);
+place_endbr64_poison(ptr);
 clobbered++;
 }
 
diff --git a/xen/arch/x86/include/asm/endbr.h b/xen/arch/x86/include/asm/endbr.h
index 6090afeb0bd8..d946fac13130 100644
--- a/xen/arch/x86/include/asm/endbr.h
+++ b/xen/arch/x86/include/asm/endbr.h
@@ -52,4 +52,30 @@ static inline void place_endbr64(void *ptr)
 *(uint32_t *)ptr = gen_endbr64();
 }
 
+/*
+ * After clobbering ENDBR64, we may need to confirm that the site used to
+ * contain an ENDBR64 instruction.  Use an encoding which isn't the default
+ * P6_NOP4.  Specifically, nopw (%rcx)
+ */
+static inline uint32_t __attribute_const__ gen_endbr64_poison(void)
+{
+uint32_t res;
+
+asm ( "mov $~0x011f0f66, %[res]\n\t"
+  "not %[res]\n\t"
+  : [res] "=" (res) );
+
+return res;
+}
+
+static inline bool is_endbr64_poison(const void *ptr)
+{
+return *(const uint32_t *)ptr == gen_endbr64_poison();
+}
+
+static inline void place_endbr64_poison(void *ptr)
+{
+*(uint32_t *)ptr = gen_endbr64_poison();
+}
+
 #endif /* XEN_ASM_ENDBR_H */
diff --git a/xen/tools/check-endbr.sh b/xen/tools/check-endbr.sh
index 9799c451a18d..126a2a14d44e 100755
--- a/xen/tools/check-endbr.sh
+++ b/xen/tools/check-endbr.sh
@@ -27,7 +27,7 @@ echo "X" | grep -aob "X" -q 2>/dev/null ||
 # Check whether grep supports Perl regexps. Older GNU grep doesn't reliably
 # find binary patterns otherwise.
 perl_re=true
-echo "X" | grep -aobP "\130" -q 2>/dev/null || perl_re=false
+echo "X" | grep -aobP "\x58" -q 2>/dev/null || perl_re=false
 
 #
 # First, look for all the valid endbr64 instructions.
@@ -45,13 +45,15 @@ echo "X" | grep -aobP "\130" -q 2>/dev/null || perl_re=false
 ${OBJDUMP} -j .text $1 -d -w | grep '  endbr64 *$' | cut -f 1 -d ':' > $VALID &
 
 #
-# Second, look for any endbr64 byte sequence
+# Second, look for any endbr64 or nop4 poison byte sequences
 # This has a couple of complications:
 #
 # 1) Grep binary search isn't VMA aware.  Copy .text out as binary, causing
 #the grep offset to be from the start of .text.
 #
 # 2) dash's printf doesn't understand hex escapes, hence the use of octal.
+#`grep -P` on the other hand can interpret hex escapes, and must use them
+#to avoid \1 thru \9 being interpreted as subpatterns matches.
 #
 # 3) AWK can't add 64bit integers, because internally all numbers are doubles.
 #When the upper bits are set, the exponents worth of precision is lost in
@@ -67,9 +69,9 @@ eval $(${OBJDUMP} -j .text $1 -h |
 ${OBJCOPY} -j .text $1 -O binary $TEXT_BIN
 if $perl_re
 then
-LC_ALL=C grep -aobP '\363\17\36\372' $TEXT_BIN
+LC_ALL=C grep -aobP '\xf3\x0f\x1e\xfa|\x66\x0f\x1f\x01' $TEXT_BIN
 else
-grep -aob "$(printf '\363\17\36\372')" $TEXT_BIN
+grep -aob -e "$(printf '\363\17\36\372')" -e "$(printf '\146\17\37\1')" 
$TEXT_BIN
 fi | awk -F':' '{printf "%s%x\n", "'$vma_hi'", int(0x'$vma_lo') + $1}' > $ALL
 
 # Wait for $VALID to become complete
@@ -90,6 +92,6 @@ nr_bad=$(wc -l < $BAD)
 [ "$nr_bad" -eq 0 ] && exit 0
 
 # Failure
-echo "$MSG_PFX Fail: Found ${nr_bad} embedded endbr64 instructions" >&2
+echo "$MSG_PFX Fail: Found ${nr_bad} embedded 

RE: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-enhanced functions

[Jiamei Xie]

> -Original Message-
> From: Xen-devel  On Behalf Of
> Jiamei Xie
> Sent: 2022年3月17日 17:17
> To: Ross Lagerwall ; Bjoern Doebel
> ; xen-devel@lists.xenproject.org
> Cc: Michael Kurth ; Martin Pohlack
> ; Roger Pau Monne ;
> Andrew Cooper ; Konrad Rzeszutek Wilk
> 
> Subject: RE: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
> enhanced functions
> 
> Hi  Bjoern,
> 
> > -Original Message-
> > From: Xen-devel  On Behalf Of
> > Ross Lagerwall
> > Sent: 2022年3月10日 1:12
> > To: Bjoern Doebel ; xen-devel@lists.xenproject.org
> > Cc: Michael Kurth ; Martin Pohlack
> > ; Roger Pau Monne ;
> > Andrew Cooper ; Konrad Rzeszutek Wilk
> > 
> > Subject: Re: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
> > enhanced functions
> >
> > > From: Bjoern Doebel 
> > > Sent: Wednesday, March 9, 2022 2:53 PM
> > > To: xen-devel@lists.xenproject.org 
> > > Cc: Michael Kurth ; Martin Pohlack
> > ; Roger Pau Monne ;
> > Andrew Cooper ; Bjoern Doebel
> > ; Konrad Rzeszutek Wilk ;
> > Ross Lagerwall 
> > > Subject: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
> > enhanced functions
> > >
> > > Xen enabled CET for supporting architectures. The control flow aspect of
> > > CET expects functions that can be called indirectly (i.e., via function
> > > pointers) to start with an ENDBR64 instruction. Otherwise a control flow
> > > exception is raised.
> > >
> > > This expectation breaks livepatching flows because we patch functions by
> > > overwriting their first 5 bytes with a JMP + , thus breaking the
> > > ENDBR64. We fix this by checking the start of a patched function for
> > > being ENDBR64. In the positive case we move the livepatch JMP to start
> > > behind the ENDBR64 instruction.
> > >
> > > To avoid having to guess the ENDBR64 offset again on patch reversal
> > > (which might race with other mechanisms adding/removing ENDBR
> > > dynamically), use the livepatch metadata to store the computed offset
> > > along with the saved bytes of the overwritten function.
> > >
> > > Signed-off-by: Bjoern Doebel 
> > > Acked-by: Konrad Rzeszutek Wilk 
> > > CC: Ross Lagerwall 
> >
> > Reviewed-by: Ross Lagerwall 
> 
> Tested-by: Jiamei xie 
> 
> Cheers,
> Jiamei
Sorry I forgot to add the scope I tested in last email. I tested it on armv8a. 
It worked fine and  didn't break arm.
Tested-by: Jiamei xie 
> Cheers,
> Jiamei

Re: [PATCH] x86/spec-ctrl: Knobs for STIBP and PSFD, and follow hardware STIBP hint

[Jan Beulich]

On 16.03.2022 15:00, Andrew Cooper wrote:
> STIBP and PSFD are slightly weird bits, because they're both implied by other
> bits in MSR_SPEC_CTRL.  Add fine grain controls for them, and take the
> implications into account when setting IBRS/SSBD.
> 
> Rearrange the IBPB text/variables/logic to keep all the MSR_SPEC_CTRL bits
> together, for consistency.
> 
> However, AMD have a hardware hint CPUID bit recommending that STIBP be set
> uniaterally.  This is advertised on Zen3, so follow the recommendation.  This
> is the only default change.
> 
> Signed-off-by: Andrew Cooper 

In principle
Reviewed-by: Jan Beulich 
but I have two comments:

> @@ -170,12 +174,18 @@ static int __init cf_check parse_spec_ctrl(const char 
> *s)
>  else
>  rc = -EINVAL;
>  }
> +
>  else if ( (val = parse_boolean("ibrs", s, ss)) >= 0 )
>  opt_ibrs = val;
> -else if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
> -opt_ibpb = val;
> +else if ( (val = parse_boolean("stibp", s, ss)) >= 0 )
> +opt_stibp = val;
>  else if ( (val = parse_boolean("ssbd", s, ss)) >= 0 )
>  opt_ssbd = val;
> +else if ( (val = parse_boolean("psfd", s, ss)) >= 0 )
> +opt_psfd = val;
> +
> +else if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
> +opt_ibpb = val;
>  else if ( (val = parse_boolean("eager-fpu", s, ss)) >= 0 )
>  opt_eager_fpu = val;
>  else if ( (val = parse_boolean("l1d-flush", s, ss)) >= 0 )

Personally I find blank lines ahead of "else if" misleading. Could I
talk you into moving ibrs+stibp and ssbd+psfd close to the end of this
(immediately ahead of "else"), prefixing each pair with a comment about
one feature implying the other (and hence the comments replacing the
blank lines)?

Otoh I notice that we already have blank lines elsewhere in the middle
if this block of code, but at least there they're accompanied by a
comment making more obvious why there is such separation. Which means
as an intermediate approach I'd be okay with no re-ordering, but with
comments added.

> @@ -1070,12 +1083,50 @@ void __init init_speculation_mitigations(void)
>  
>  /* If we have IBRS available, see whether we should use it. */
>  if ( has_spec_ctrl && ibrs )
> +{
> +/* IBRS implies STIBP.  */
> +if ( opt_stibp == -1 )
> +opt_stibp = 1;
> +
>  default_xen_spec_ctrl |= SPEC_CTRL_IBRS;
> +}
> +
> +/* Use STIBP by default if the hardware hint is set. */
> +if ( opt_stibp == -1 && boot_cpu_has(X86_FEATURE_STIBP_ALWAYS) )
> +opt_stibp = 1;
> +
> +/*
> + * Otherwise, don't use STIBP by default.  It has some severe performance
> + * implications on older hardware.
> + */
> +if ( opt_stibp == -1 )
> +opt_stibp = 0;

I'd find this easier to read if written along the lines of

if ( opt_stibp == -1 )
{
/*
 * Use STIBP by default if the hardware hint is set.  Otherwise,
 * don't use STIBP by default.  It has some severe performance
 * implications on older hardware.
 */
opt_stibp = !!boot_cpu_has(X86_FEATURE_STIBP_ALWAYS);
}

FTAOD I'm not going to insist on either adjustment.

Jan

[libvirt test] 168649: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

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

Last test of basis   151777  2020-07-10 04:19:19 Z  615 days
Failing since151818  2020-07-11 04:18:52 Z  614 days  596 attempts
Testing same since   168649  2022-03-17 04:19:07 Z0 days1 attempts


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

Re: [PATCH] x86/cet: Remove writeable mapping of the BSPs shadow stack

[Jan Beulich]

On 16.03.2022 20:23, Andrew Cooper wrote:
> On 16/03/2022 08:33, Jan Beulich wrote:
>> On 15.03.2022 17:53, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -215,8 +215,9 @@ SECTIONS
>>>} PHDR(text)
>>>DECL_SECTION(.init.data) {
>>>  #endif
>>> +   . = ALIGN(STACK_SIZE);
>>> +   *(.init.bss.stack_aligned)
>> No real need for the ALIGN() here - it's the contributions to the
>> section which ought to come with proper alignment. Imo ALIGN()
>> should only ever be there ahead of a symbol definition, as otherwise
>> the symbol might not mark what it is intended to mark due to padding
>> which might be inserted. See also 01fe4da6243b ("x86: force suitable
>> alignment in sources rather than in linker script").
>>
>> Really we should consider using
>>
>> *(SORT_BY_ALIGNMENT(.init.data .init.data.* .init.bss.*))
>>
>> While I can see your point against forcing sorting by alignment
>> globally, this very argument doesn't apply here (at least until
>> there appeared a way for the section attribute and -fdata-sections
>> to actually interact, such that .init.* could also become per-
>> function/object).
>>
>> Then again - this block of zeroes doesn't need to occupy space in
>> the binary.
> 
> It already occupies space, because of mkelf32.

Hmm, yes, and not just because of mkelf32: Since we munge everything
in a single PT_LOAD segment in the linker script, all of .init.*
necessarily has space allocated.

>>  It could very well live in a @nobits .init.bss in the
>> final ELF binary. But sadly the section isn't @nobits in the object
>> file, and with that there would need to be a way to make the linker
>> convert it to @nobits (and I'm unaware of such). What would work is
>> naming the section .bss.init.stack_aligned (or e.g.
>> .bss..init.stack_aligned to make it easier to separate it from
>> .bss.* in the linker script) - that'll make gcc mark it @nobits.
> 
> Living in .bss would prevent it from being reclaimed.  We've got several
> nasty bugs from shooting holes in the Xen image, and too many special
> cases already.

I didn't suggest to put it in .bss; the suggested name was merely so
that gcc would mark the section @nobits and we could exclude the
section from what makes in into .bss in the final image independent
of .init.* vs .bss.* ordering in the linker script. But anyway - with
the above this aspect is now moot anyway.

Jan

RE: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-enhanced functions

[Jiamei Xie]

Hi  Bjoern,

> -Original Message-
> From: Xen-devel  On Behalf Of
> Ross Lagerwall
> Sent: 2022年3月10日 1:12
> To: Bjoern Doebel ; xen-devel@lists.xenproject.org
> Cc: Michael Kurth ; Martin Pohlack
> ; Roger Pau Monne ;
> Andrew Cooper ; Konrad Rzeszutek Wilk
> 
> Subject: Re: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
> enhanced functions
> 
> > From: Bjoern Doebel 
> > Sent: Wednesday, March 9, 2022 2:53 PM
> > To: xen-devel@lists.xenproject.org 
> > Cc: Michael Kurth ; Martin Pohlack
> ; Roger Pau Monne ;
> Andrew Cooper ; Bjoern Doebel
> ; Konrad Rzeszutek Wilk ;
> Ross Lagerwall 
> > Subject: [PATCH v5 2/2] xen/x86: Livepatch: support patching CET-
> enhanced functions
> >
> > Xen enabled CET for supporting architectures. The control flow aspect of
> > CET expects functions that can be called indirectly (i.e., via function
> > pointers) to start with an ENDBR64 instruction. Otherwise a control flow
> > exception is raised.
> >
> > This expectation breaks livepatching flows because we patch functions by
> > overwriting their first 5 bytes with a JMP + , thus breaking the
> > ENDBR64. We fix this by checking the start of a patched function for
> > being ENDBR64. In the positive case we move the livepatch JMP to start
> > behind the ENDBR64 instruction.
> >
> > To avoid having to guess the ENDBR64 offset again on patch reversal
> > (which might race with other mechanisms adding/removing ENDBR
> > dynamically), use the livepatch metadata to store the computed offset
> > along with the saved bytes of the overwritten function.
> >
> > Signed-off-by: Bjoern Doebel 
> > Acked-by: Konrad Rzeszutek Wilk 
> > CC: Ross Lagerwall 
> 
> Reviewed-by: Ross Lagerwall 

Tested-by: Jiamei xie 

Cheers, 
Jiamei

Re: [PATCH v8 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC

[Roger Pau Monné]

On Wed, Mar 16, 2022 at 09:13:15AM +, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
> 
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware assisted virtualization, as well as a global
> configuration option.
> 
> Having all APIC interaction exit to Xen for emulation is slow and can
> induce much overhead. Hardware can speed up x{2}APIC by decoding the
> APIC access and providing a VM exit with a more specific exit reason
> than a regular EPT fault or by altogether avoiding a VM exit.
> 
> On the other hand, being able to disable x{2}APIC hardware assisted
> virtualization can be useful for testing and debugging purposes.
> 
> Note: vmx_install_vlapic_mapping doesn't require modifications
> regardless of whether the guest has "Virtualize APIC accesses" enabled
> or not, i.e., setting the APIC_ACCESS_ADDR VMCS field is fine so long
> as virtualize_apic_accesses is supported by the CPU.

Have you tested migration of guests with this patch applied?

We need to be careful so that a guest that doesn't have
assisted_x{2}apic set in the config file can be migrated between hosts
that have different support for hardware assisted x{2}APIC
virtualization.

Ie: we need to make sure the selection of arch_x86.assisted_x{2}apic
is only present in the migration stream when explicitly set in the
configuration file.

> diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
> index e0a06ecfe3..46d4de22d1 100644
> --- a/tools/libs/light/libxl_x86.c
> +++ b/tools/libs/light/libxl_x86.c
> @@ -23,6 +23,15 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>  if (libxl_defbool_val(d_config->b_info.arch_x86.msr_relaxed))
>  config->arch.misc_flags |= XEN_X86_MSR_RELAXED;
>  
> +if (d_config->c_info.type != LIBXL_DOMAIN_TYPE_PV)
> +{
> +if (libxl_defbool_val(d_config->b_info.arch_x86.assisted_xapic))
> +config->arch.misc_flags |= XEN_X86_ASSISTED_XAPIC;
> +
> +if (libxl_defbool_val(d_config->b_info.arch_x86.assisted_x2apic))
> +config->arch.misc_flags |= XEN_X86_ASSISTED_X2APIC;
> +}
> +
>  return 0;
>  }
>  
> @@ -819,11 +828,26 @@ void 
> libxl__arch_domain_create_info_setdefault(libxl__gc *gc,
>  {
>  }
>  
> -void libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
> -  libxl_domain_build_info 
> *b_info)
> +int libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
> + libxl_domain_build_info *b_info,
> + const libxl_physinfo *physinfo)
>  {
>  libxl_defbool_setdefault(_info->acpi, true);
>  libxl_defbool_setdefault(_info->arch_x86.msr_relaxed, false);
> +
> +if (b_info->type != LIBXL_DOMAIN_TYPE_PV) {
> +libxl_defbool_setdefault(_info->arch_x86.assisted_xapic,
> + physinfo->cap_assisted_xapic);
> +libxl_defbool_setdefault(_info->arch_x86.assisted_x2apic,
> + physinfo->cap_assisted_x2apic);

Nit: the split lines would better be adjusted to match the
indentation of the first parameter.

libxl_defbool_setdefault(_info->arch_x86.assisted_xapic,
 physinfo->cap_assisted_xapic);

> +}
> +else if (!libxl_defbool_is_default(b_info->arch_x86.assisted_xapic) ||
> + !libxl_defbool_is_default(b_info->arch_x86.assisted_x2apic)) {
> +LOG(ERROR, "Interrupt Controller Virtualization not supported for 
> PV");
> +return ERROR_INVAL;
> +}
> +
> +return 0;
>  }
>  
>  int libxl__arch_passthrough_mode_setdefault(libxl__gc *gc,
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> index 712456e098..32f3028828 100644
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -50,6 +50,8 @@ type x86_arch_emulation_flags =
>  
>  type x86_arch_misc_flags =
>   | X86_MSR_RELAXED
> + | X86_ASSISTED_XAPIC
> + | X86_ASSISTED_X2APIC
>  
>  type xen_x86_arch_domainconfig =
>  {
> diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
> index b034434f68..d0fcbc8866 100644
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -44,6 +44,8 @@ type x86_arch_emulation_flags =
>  
>  type x86_arch_misc_flags =
>| X86_MSR_RELAXED
> +  | X86_ASSISTED_XAPIC
> +  | X86_ASSISTED_X2APIC
>  
>  type xen_x86_arch_domainconfig = {
>emulation_flags: x86_arch_emulation_flags list;
> diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
> b/tools/ocaml/libs/xc/xenctrl_stubs.c
> index 7e9c32ad1b..5df8aaa58f 100644
> --- a/tools/ocaml/libs/xc/xenctrl_stubs.c
> +++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
> @@ -239,7 +239,7 @@ CAMLprim value stub_xc_domain_create(value xch, value 
> wanted_domid, value config
>  
>   

Re: [PATCH v3 20/23] VT-d: free all-empty page tables

[Jan Beulich]

On 17.03.2022 06:55, Tian, Kevin wrote:
>> From: Jan Beulich 
>> Sent: Monday, March 14, 2022 3:33 PM
>>
>> On 14.03.2022 05:01, Tian, Kevin wrote:
 From: Jan Beulich 
 Sent: Friday, February 18, 2022 4:31 PM

 On 18.02.2022 06:20, Tian, Kevin wrote:
>> From: Jan Beulich 
>> Sent: Tuesday, January 11, 2022 12:36 AM
>>
>> When a page table ends up with no present entries left, it can be
>> replaced by a non-present entry at the next higher level. The page table
>> itself can then be scheduled for freeing.
>>
>> Note that while its output isn't used there yet,
>> pt_update_contig_markers() right away needs to be called in all places
>> where entries get updated, not just the one where entries get cleared.
>>
>> Note further that while pt_update_contig_markers() updates perhaps
>> several PTEs within the table, since these are changes to "avail" bits
>> only I do not think that cache flushing would be needed afterwards.
>> Such
>> cache flushing (of entire pages, unless adding yet more logic to me
>> more
>> selective) would be quite noticable performance-wise (very prominent
>> during Dom0 boot).
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> v3: Properly bound loop. Re-base over changes earlier in the series.
>> v2: New.
>> ---
>> The hang during boot on my Latitude E6410 (see the respective code
>> comment) was pretty close after iommu_enable_translation(). No
>> errors,
>> no watchdog would kick in, just sometimes the first few pixel lines of
>> the next log message's (XEN) prefix would have made it out to the
>> screen
>> (and there's no serial there). It's been a lot of experimenting until I
>> figured the workaround (which I consider ugly, but halfway acceptable).
>> I've been trying hard to make sure the workaround wouldn't be
>> masking a
>> real issue, yet I'm still wary of it possibly doing so ... My best guess
>> at this point is that on these old IOMMUs the ignored bits 52...61
>> aren't really ignored for present entries, but also aren't "reserved"
>> enough to trigger faults. This guess is from having tried to set other
>
> Is this machine able to capture any VT-d faults before?

 Not sure what you mean here. I don't think I can trigger any I/O at this
 point in time, and hence I also couldn't try to trigger a fault. But if
 the question is whether fault reporting at this time actually works,
 then yes, I think so: This is during Dom0 construction, i.e. late enough
 for fault reporting to be fully set up and enabled.

>>>
>>> My point was that with your guess that the ignored bits are not
>>> ignored some VT-d faults should be triggered. If the reason why
>>> you cannot observe such faults is because they happened too
>>> early so no much can be shown on the screen then trying to
>>> setting those bits at much later point might get more shown to
>>> verify your guess.
>>
>> Pretty clearly there aren't any faults. And in fact my suspicion is
>> that the bits are used for addressing memory, and then the memory
>> access hangs (doesn't complete).
>>
>>> btw any progress since last post? How urgent do you want this
>>> feature in (compared to the issue that it may paper over)?
>>
>> Well, one way or another the issue needs to be dealt with for this
>> series to eventually go in. To be honest I hadn't expected that it
>> would still be pending ...
>>
> 
> Sorry I didn't get your meaning. Do you mean that you didn't
> expect that I haven't given r-b or that you haven't found time
> to root-cause this issue?

Neither - the comment about the series as a whole still being pending
was a general one. After all it's been over half a year since the
original posting of the first parts of it.

As to root-causing this issue: I don't see any reasonable way for me
to do so. Hence it's not a matter of finding time anymore (that was
only the case until I could actually associate the behavior with the
one specific piece of code that causes it), but a matter of simply
not being in the position to sensibly try to dig deeper. I continue
to think that the only reasonable way to gain further insight is for
someone with access to the sources of the (I assume) involved
microcode in the chipset to spell out what the expected behavior
given that microcode would actually be. Without such knowledge I do
not see any alternative to what I'm currently doing to document and
work around the issue. Yet I also understand that given this is
rather old hardware, there's little interest at Intel to actually
put time into such research.

Jan

Re: [XEN PATCH] evtchn/fifo: Don't set PENDING bit if guest misbehaves

[David Vrabel]

On 17/03/2022 06:28, Juergen Gross wrote:

On 16.03.22 19:38, Raphael Ning wrote:

From: Raphael Ning 

Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
if it fails to lock the FIFO event queue(s), or if the guest has not
initialized the FIFO control block for the target vCPU. A well-behaved
guest should never trigger either of these cases.


Is this true even for the resume case e.g. after a migration?

The guests starts on the new host with no FIFO control block for any
vcpu registered, so couldn't an event get lost with your patch in case
it was sent before the target vcpu's control block gets registered?


An event that is PENDING but not LINKED is not reachable by the guest so 
it won't ever see such an event, so the event is lost whether the P bit 
is set or not.


Guests ensure that event channels are not bound to VCPUs that don't 
(yet) have FIFO control blocks.


For example, in Linux xen_irq_resume() reinitializes the control blocks 
(in xen_evtchn_resume()) before restoring any of the event channels.


David

Re: [PATCH] kconfig: detect LD implementation

[Roger Pau Monné]

On Wed, Mar 16, 2022 at 11:28:48AM +0100, Michal Orzel wrote:
> Hi Roger,
> 
> On 14.03.2022 11:55, Roger Pau Monne wrote:
> > Detect GNU and LLVM ld implementations. This is required for further
> > patches that will introduce diverging behaviour depending on the
> > linker implementation in use.
> > 
> > Note that LLVM ld returns "compatible with GNU linkers" as part of the
> > version string, so be on the safe side and use '^' to only match at
> > the start of the line in case LLVM ever decides to change the text to
> > use "compatible with GNU ld" instead.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> >  xen/Kconfig | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/xen/Kconfig b/xen/Kconfig
> > index d134397a0b..e8d5e70d46 100644
> > --- a/xen/Kconfig
> > +++ b/xen/Kconfig
> > @@ -23,6 +23,12 @@ config CLANG_VERSION
> > int
> > default $(shell,$(BASEDIR)/scripts/clang-version.sh $(CC))
> >  
> > +config LD_IS_GNU
> > +   def_bool $(success,$(LD) --version | head -n 1 | grep -q "^GNU ld")
> > +> +config LD_IS_LLVM
> > +   def_bool $(success,$(LD) --version | head -n 1 | grep -q "^LLD")
> > +
> >  # -fvisibility=hidden reduces -fpic cost, if it's available
> >  config CC_HAS_VISIBILITY_ATTRIBUTE
> > def_bool $(cc-option,-fvisibility=hidden)
> 
> NIT: You do not really need to use head especiialy if grep for the beginning 
> of a line.

I'm afraid I don't agree. We use head because we only want to match
against the first line of the output, and then we use '^' to match at
the beginning of such line. Without using head we would end up
matching at the beginning of any line present in the output.

Thanks, Roger.

[ovmf test] 168651: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 5b56c52b5c1cc817a1ddac7f03aa6a02aeab4c04
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   16 days
Failing since168258  2022-03-01 01:55:31 Z   16 days  156 attempts
Testing same since   168637  2022-03-16 13:10:25 Z0 days6 attempts


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

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



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

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

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

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


Not pushing.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  8 xen-bootfail pass in 168647-retest
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 168647-retest

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

version targeted for testing:
 qemuu

Re: [XEN PATCH] evtchn/fifo: Don't set PENDING bit if guest misbehaves

[Juergen Gross]

On 16.03.22 19:38, Raphael Ning wrote:

From: Raphael Ning 

Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
if it fails to lock the FIFO event queue(s), or if the guest has not
initialized the FIFO control block for the target vCPU. A well-behaved
guest should never trigger either of these cases.


Is this true even for the resume case e.g. after a migration?

The guests starts on the new host with no FIFO control block for any
vcpu registered, so couldn't an event get lost with your patch in case
it was sent before the target vcpu's control block gets registered?


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

RE: [PATCH v8 1/2] xen+tools: Report Interrupt Controller Virtualization capabilities on x86

[Tian, Kevin]

> From: Jane Malalane
> Sent: Wednesday, March 16, 2022 5:13 PM
> 
> Add XEN_SYSCTL_PHYSCAP_X86_ASSISTED_XAPIC and
> XEN_SYSCTL_PHYSCAP_X86_ASSISTED_X2APIC to report accelerated xAPIC
> and
> x2APIC, on x86 hardware. This is so that xAPIC and x2APIC virtualization
> can subsequently be enabled on a per-domain basis.
> No such features are currently implemented on AMD hardware.
> 
> HW assisted xAPIC virtualization will be reported if HW, at the
> minimum, supports virtualize_apic_accesses as this feature alone means
> that an access to the APIC page will cause an APIC-access VM exit. An
> APIC-access VM exit provides a VMM with information about the access
> causing the VM exit, unlike a regular EPT fault, thus simplifying some
> internal handling.
> 
> HW assisted x2APIC virtualization will be reported if HW supports
> virtualize_x2apic_mode and, at least, either apic_reg_virt or
> virtual_intr_delivery. This also means that
> sysctl follows the conditionals in vmx_vlapic_msr_changed().
> 
> For that purpose, also add an arch-specific "capabilities" parameter
> to struct xen_sysctl_physinfo.
> 
> Note that this interface is intended to be compatible with AMD so that
> AVIC support can be introduced in a future patch. Unlike Intel that
> has multiple controls for APIC Virtualization, AMD has one global
> 'AVIC Enable' control bit, so fine-graining of APIC virtualization
> control cannot be done on a common interface.
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Jane Malalane 

Reviewed-by: Kevin Tian 

btw the r-b from Roger is lost...

> ---
> CC: Wei Liu 
> CC: Anthony PERARD 
> CC: Juergen Gross 
> CC: Andrew Cooper 
> CC: George Dunlap 
> CC: Jan Beulich 
> CC: Julien Grall 
> CC: Stefano Stabellini 
> CC: Volodymyr Babchuk 
> CC: Bertrand Marquis 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: "Roger Pau Monné" 
> 
> v8:
>  * Improve commit message
> 
> v7:
>  * Make sure assisted_x{2}apic_available evaluates to false, to ensure
>Xen builds, when !CONFIG_HVM
>  * Fix coding style issues
> 
> v6:
>  * Limit abi check to x86
>  * Fix coding style issue
> 
> v5:
>  * Have assisted_xapic_available solely depend on
>cpu_has_vmx_virtualize_apic_accesses and assisted_x2apic_available
>depend on cpu_has_vmx_virtualize_x2apic_mode and
>cpu_has_vmx_apic_reg_virt OR cpu_has_vmx_virtual_intr_delivery
> 
> v4:
>  * Fallback to the original v2/v1 conditions for setting
>assisted_xapic_available and assisted_x2apic_available so that in
>the future APIC virtualization can be exposed on AMD hardware
>since fine-graining of "AVIC" is not supported, i.e., AMD solely
>uses "AVIC Enable". This also means that sysctl mimics what's
>exposed in CPUID
> 
> v3:
>  * Define XEN_SYSCTL_PHYSCAP_ARCH_MAX for ABI checking and actually
>set "arch_capbilities", via a call to c_bitmap_to_ocaml_list()
>  * Have assisted_x2apic_available only depend on
>cpu_has_vmx_virtualize_x2apic_mode
> 
> v2:
>  * Use one macro LIBXL_HAVE_PHYSINFO_ASSISTED_APIC instead of two
>  * Pass xcpyshinfo as a pointer in libxl__arch_get_physinfo
>  * Set assisted_x{2}apic_available to be conditional upon "bsp" and
>annotate it with __ro_after_init
>  * Change XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_X{2}APIC to
>_X86_ASSISTED_X{2}APIC
>  * Keep XEN_SYSCTL_PHYSCAP_X86_ASSISTED_X{2}APIC contained within
>sysctl.h
>  * Fix padding introduced in struct xen_sysctl_physinfo and bump
>XEN_SYSCTL_INTERFACE_VERSION
> ---
>  tools/golang/xenlight/helpers.gen.go |  4 
>  tools/golang/xenlight/types.gen.go   |  2 ++
>  tools/include/libxl.h|  7 +++
>  tools/libs/light/libxl.c |  3 +++
>  tools/libs/light/libxl_arch.h|  4 
>  tools/libs/light/libxl_arm.c |  5 +
>  tools/libs/light/libxl_types.idl |  2 ++
>  tools/libs/light/libxl_x86.c | 11 +++
>  tools/ocaml/libs/xc/xenctrl.ml   |  5 +
>  tools/ocaml/libs/xc/xenctrl.mli  |  5 +
>  tools/ocaml/libs/xc/xenctrl_stubs.c  | 15 +--
>  tools/xl/xl_info.c   |  6 --
>  xen/arch/x86/hvm/hvm.c   |  3 +++
>  xen/arch/x86/hvm/vmx/vmcs.c  |  9 +
>  xen/arch/x86/include/asm/hvm/hvm.h   |  5 +
>  xen/arch/x86/sysctl.c|  4 
>  xen/include/public/sysctl.h  | 11 ++-
>  17 files changed, 96 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/golang/xenlight/helpers.gen.go
> b/tools/golang/xenlight/helpers.gen.go
> index b746ff1081..dd4e6c9f14 100644
> --- a/tools/golang/xenlight/helpers.gen.go
> +++ b/tools/golang/xenlight/helpers.gen.go
> @@ -3373,6 +3373,8 @@ x.CapVmtrace = bool(xc.cap_vmtrace)
>  x.CapVpmu = bool(xc.cap_vpmu)
>  x.CapGnttabV1 = bool(xc.cap_gnttab_v1)
>  x.CapGnttabV2 = bool(xc.cap_gnttab_v2)
> +x.CapAssistedXapic = bool(xc.cap_assisted_xapic)
> +x.CapAssistedX2Apic = bool(xc.cap_assisted_x2apic)
> 
>   return nil}
> 
> @@ -3407,6 +3409,8 @@ xc.cap_vmtrace =