Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion
Good day,
You're looking for this document i was focusing on a week ago, i believe. Anyway, here's the url to this doc below:
https://tutiendafit.com.mx/olea/sndaem
On 3/15/22 7:38 AM, Jan Beulich wrote:
> On 14.03.2022 04:41, Chuck Zmudzinski wrote:
>> Fixes: abfb006f1ff4 (tools/libxl: explicitly grant access to needed I/O-memory ranges)
>> Fixes: 0561e1f01e87 (xen/common: do not implicitly permit access to mapped I/O memory)
>> Backport: 4.12+
> Just fyi: This is fine to have as a tag, but it wouldn't be backported
> farther than to 4.15.
That's entirely reasonable. I understand this is a bug fix, not a
security issue.
>
> Apart from this largely some style issues (see below), but please
> realize that I'm not a libxl maintainer and hence I may not have good
> enough knowledge of, in particular, potential unwritten conventions.
I will take your comments into consideration regarding style before
writing the next version of the patch, and carefully check libxl's
coding style file.
>
>> @@ -610,6 +612,45 @@ out:
>> return ret;
>> }
>>
>> +static uint32_t sysfs_dev_get_igd_opregion(libxl__gc *gc,
>> + libxl_device_pci *pci)
>> +{
>> +char *pci_device_config_path =
>> +GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/config",
>> + pci->domain, pci->bus, pci->dev, pci->func);
>> +size_t read_items;
>> +uint32_t igd_opregion;
>> +uint32_t error = 0x;
> I think this constant wants to gain a #define, to be able to correlate
> the use sites. I'm also not sure of the value - in principle the
> register can hold this value, but of course then it won't be 3 pages.
What we are storing as the return value is the starting address,
not the size, of the opregion, and that is a 32-bit value. If we
cannot read it, we return 0x instead to indicate the error
that we were unable to read the starting address of the opregion
from the config attribute in sysfs. The 32-bit value we are looking for
is read at offset 0xfc from the start of the config attribute of the
Intel IGD in sysfs. The offset 0xfc is defined by PCI_INTEL_OPREGION
both here and in hvmloader (and also in Qemu). The data that is
read at this offset from the start of the config attribute of the Intel
IGD in sysfs is the 32-bit address of the start of the opregion.
> Maybe the error check further down should be to see whether adding 2
> to the value would overflow in 32 bits? (In that case a #define may
> not be needed anymore, as there wouldn't be multiple instances of the
> constant in the code.)
That would work also. Please not that I chose that value for an error
value consistent with the way the current function sysfs_dev_get_vendor
does it. While that function does not assign the variable 'error' to
its return value for an error, which in that case is 0x because
that function returns uint16_t instead of uint32_t,
I chose to explicitly assign the error variable to that value to help make
the code more readable. Your comment that this could be a #define
instead is good. I also think we should use a #define for the error return
value of the sysfs_dev_get_vendor function Something like:
#define ERROR_16 0x
#define ERROR_32 0x
might be appropriate. But that would be touching code unrelated to
this bug fix. I think again the libxl maintainers should weigh in about
what to do here. They might let me take this opportunity to update
and improve the style of the patched file in other functions in the
file not related to this bug fix but I am not inclined to do that without
an explicit request from them to do so. So I am not sure yet what I will
do in the next version of the patch, but I will address your concerns here
and try to explain my reasoning for the changes in the changelog for
version 2 of the patch.
>
>> +
>> +FILE *f = fopen(pci_device_config_path, "r");
>> +if (!f) {
> While libxl has some special style rules, I think it still wants a
> blank line between declaration(s) and statement(s), just like we
> expect elsewhere. Effectively you want to simply move the blank line
> you have one line down.
I think I followed the same style here as the existing sysfs_dev_get_xxx
functions. I will double check that and use the same style the other
functions use unless they clearly violate the rules, and note that I
deviated from the style of the existing functions to conform to current
coding style and suggest a subsequent patch to update the style of
the other functions.
>
>> @@ -2531,6 +2572,37 @@ int libxl__grant_vga_iomem_permission(libxl__gc *gc, const uint32_t domid,
>> domid, vga_iomem_start, (vga_iomem_start + 0x20 - 1));
>> return ret;
>> }
>> +
>> +/* If this is an Intel IGD, allow access to the IGD opregion */
>> +if (!libxl__is_igd_vga_passthru(gc, d_config)) return 0;
> Despite the provision for "return" or alike to go on the same line
> as an error code check,
[ovmf test] 169530: regressions - FAIL
flight 169530 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169530/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 76fda1def3d1baea3b01ae697687ff478d2d1b42 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 49 days 498 attempts Testing same since 169527 2022-04-19 01:40:37 Z0 days3 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5491 lines long.)
Re: [PATCH 10/11] rnbd-srv: use bdev_discard_alignment
On Mon, Apr 18, 2022 at 6:53 AM Christoph Hellwig wrote:
>
> Use bdev_discard_alignment to calculate the correct discard alignment
> offset even for partitions instead of just looking at the queue limit.
>
> Signed-off-by: Christoph Hellwig
Thx!
Acked-by: Jack Wang
> ---
> drivers/block/rnbd/rnbd-srv-dev.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/rnbd/rnbd-srv-dev.h
> b/drivers/block/rnbd/rnbd-srv-dev.h
> index d080a0de59225..4309e52524691 100644
> --- a/drivers/block/rnbd/rnbd-srv-dev.h
> +++ b/drivers/block/rnbd/rnbd-srv-dev.h
> @@ -59,7 +59,7 @@ static inline int rnbd_dev_get_discard_granularity(const
> struct rnbd_dev *dev)
>
> static inline int rnbd_dev_get_discard_alignment(const struct rnbd_dev *dev)
> {
> - return bdev_get_queue(dev->bdev)->limits.discard_alignment;
> + return bdev_discard_alignment(dev->bdev);
> }
>
> #endif /* RNBD_SRV_DEV_H */
> --
> 2.30.2
>
[ovmf test] 169529: regressions - FAIL
flight 169529 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169529/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 76fda1def3d1baea3b01ae697687ff478d2d1b42 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 49 days 497 attempts Testing same since 169527 2022-04-19 01:40:37 Z0 days2 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5491 lines long.)
[PATCH V6 1/2] xen/arm: Add i.MX lpuart driver
From: Peng Fan
The i.MX LPUART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8QMIEC
Chatper 13.6 Low Power Universal Asynchronous Receiver/
Transmitter (LPUART)
Tested-by: Henry Wang
Signed-off-by: Peng Fan
---
xen/arch/arm/include/asm/imx-lpuart.h | 64 ++
xen/drivers/char/Kconfig | 7 +
xen/drivers/char/Makefile | 1 +
xen/drivers/char/imx-lpuart.c | 275 ++
4 files changed, 347 insertions(+)
create mode 100644 xen/arch/arm/include/asm/imx-lpuart.h
create mode 100644 xen/drivers/char/imx-lpuart.c
diff --git a/xen/arch/arm/include/asm/imx-lpuart.h
b/xen/arch/arm/include/asm/imx-lpuart.h
new file mode 100644
index 00..fe859045dc
--- /dev/null
+++ b/xen/arch/arm/include/asm/imx-lpuart.h
@@ -0,0 +1,64 @@
+/*
+ * xen/arch/arm/include/asm/imx-lpuart.h
+ *
+ * Common constant definition between early printk and the LPUART driver
+ *
+ * Peng Fan
+ * Copyright 2022 NXP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARM_IMX_LPUART_H__
+#define __ASM_ARM_IMX_LPUART_H__
+
+/* 32-bit register definition */
+#define UARTBAUD (0x10)
+#define UARTSTAT (0x14)
+#define UARTCTRL (0x18)
+#define UARTDATA (0x1C)
+#define UARTMATCH (0x20)
+#define UARTMODIR (0x24)
+#define UARTFIFO (0x28)
+#define UARTWATER (0x2c)
+
+#define UARTSTAT_TDRE BIT(23, UL)
+#define UARTSTAT_TC BIT(22, UL)
+#define UARTSTAT_RDRF BIT(21, UL)
+#define UARTSTAT_OR BIT(19, UL)
+
+#define UARTBAUD_OSR_SHIFT(24)
+#define UARTBAUD_OSR_MASK (0x1f)
+#define UARTBAUD_SBR_MASK (0x1fff)
+#define UARTBAUD_BOTHEDGE (0x0002)
+#define UARTBAUD_TDMAE(0x0080)
+#define UARTBAUD_RDMAE(0x0020)
+
+#define UARTCTRL_TIE BIT(23, UL)
+#define UARTCTRL_TCIE BIT(22, UL)
+#define UARTCTRL_RIE BIT(21, UL)
+#define UARTCTRL_ILIE BIT(20, UL)
+#define UARTCTRL_TE BIT(19, UL)
+#define UARTCTRL_RE BIT(18, UL)
+#define UARTCTRL_MBIT(4, UL)
+
+#define UARTWATER_RXCNT_OFF 24
+
+#endif /* __ASM_ARM_IMX_LPUART_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 2ff5b288e2..e5f7b1d8eb 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -13,6 +13,13 @@ 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 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..2709136081
--- /dev/null
+++ b/xen/drivers/char/imx-lpuart.c
@@ -0,0 +1,275 @@
+/*
+ * 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
+#include
+#include
+#include
+#include
+#include
+#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 {
+uint32_t baud, clock_hz, data_bits, parity, stop_bits, fifo_size;
+
[PATCH V6 2/2] xen/arm: Add i.MX lpuart early printk support
From: Peng Fan Signed-off-by: Peng Fan --- xen/arch/arm/Kconfig.debug | 14 xen/arch/arm/arm64/debug-imx-lpuart.inc | 48 + 2 files changed, 62 insertions(+) create mode 100644 xen/arch/arm/arm64/debug-imx-lpuart.inc diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug index 35ccd13273..842d768280 100644 --- a/xen/arch/arm/Kconfig.debug +++ b/xen/arch/arm/Kconfig.debug @@ -58,6 +58,16 @@ choice This option is preferred over the platform specific options; the platform specific options are deprecated and will soon be removed. + config EARLY_UART_CHOICE_IMX_LPUART + select EARLY_UART_IMX_LPUART + depends on ARM_64 + bool "Early printk via i.MX LPUART" + help + Say Y here if you wish the early printk to direct their + output to a i.MX LPUART. You can use this option to + provide the parameters for the i.MX LPUART rather than + selecting one of the platform specific options below if + you know the parameters for the port. config EARLY_UART_CHOICE_MESON select EARLY_UART_MESON depends on ARM_64 @@ -186,6 +196,9 @@ config EARLY_UART_CADENCE config EARLY_UART_EXYNOS4210 select EARLY_PRINTK bool +config EARLY_UART_IMX_LPUART + select EARLY_PRINTK + bool config EARLY_UART_MESON select EARLY_PRINTK bool @@ -283,6 +296,7 @@ config EARLY_PRINTK_INC default "debug-8250.inc" if EARLY_UART_8250 default "debug-cadence.inc" if EARLY_UART_CADENCE default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210 + default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART default "debug-meson.inc" if EARLY_UART_MESON default "debug-mvebu.inc" if EARLY_UART_MVEBU default "debug-pl011.inc" if EARLY_UART_PL011 diff --git a/xen/arch/arm/arm64/debug-imx-lpuart.inc b/xen/arch/arm/arm64/debug-imx-lpuart.inc new file mode 100644 index 00..b169332932 --- /dev/null +++ b/xen/arch/arm/arm64/debug-imx-lpuart.inc @@ -0,0 +1,48 @@ +/* + * xen/arch/arm/arm64/debug-imx-lpuart.inc + * + * i.MX8QM specific debug code + * + * Peng Fan + * Copyright 2022 NXP + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include + +/* + * Wait LPUART to be ready to transmit + * rb: register which contains the UART base address + * rc: scratch register + */ +.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 + +/* + * LPUART transmit character + * rb: register which contains the UART base address + * rt: register which contains the character to transmit + */ +.macro early_uart_transmit xb, wt +str \wt, [\xb, #UARTDATA] /* -> Data Register */ +.endm + +/* + * Local variables: + * mode: ASM + * indent-tabs-mode: nil + * End: + */ -- 2.35.1
[PATCH V6 0/2] xen/arm: add i.MX lpuart and i.MX8QM initial support
From: Peng Fan V6: Fix a stale variable check per Stefano's comments. V5: Align code drop early_uart_init V4: Wrong v3 version, some BIT definition are mixed in patch 1,2. V3: Addressed Michal's comments. Add Henry's T-b V2: Per Julien's comments, fix coding style issue, drop unneeded code Add i.MX lpuart driver and i.MX8QM platform support. - lpuart is the uart IP used in i.MX8QM/QXP/93. - Very basic i.MX8QM platform support. Peng Fan (2): xen/arm: Add i.MX lpuart driver xen/arm: Add i.MX lpuart early printk support xen/arch/arm/Kconfig.debug | 14 ++ xen/arch/arm/arm64/debug-imx-lpuart.inc | 48 + xen/arch/arm/include/asm/imx-lpuart.h | 64 ++ xen/drivers/char/Kconfig| 7 + xen/drivers/char/Makefile | 1 + xen/drivers/char/imx-lpuart.c | 275 6 files changed, 409 insertions(+) create mode 100644 xen/arch/arm/arm64/debug-imx-lpuart.inc create mode 100644 xen/arch/arm/include/asm/imx-lpuart.h create mode 100644 xen/drivers/char/imx-lpuart.c -- 2.35.1
[ovmf test] 169527: regressions - FAIL
flight 169527 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169527/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 76fda1def3d1baea3b01ae697687ff478d2d1b42 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 49 days 496 attempts Testing same since 169527 2022-04-19 01:40:37 Z0 days1 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5491 lines long.)
RE: Proposal for Porting Xen to Armv8-R64 - DraftB
Hi Stefano, > -Original Message- > From: Stefano Stabellini > Sent: 2022年4月15日 8:41 > To: Wei Chen > Cc: xen-devel@lists.xenproject.org; jul...@xen.org; Stefano Stabellini > ; Bertrand Marquis ; > Penny Zheng > Subject: Re: Proposal for Porting Xen to Armv8-R64 - DraftB > > On Fri, 25 Mar 2022, Wei Chen wrote: > > # Proposal for Porting Xen to Armv8-R64 > > > > This proposal will introduce the PoC work of porting Xen to Armv8-R64, > > which includes: > > - The changes of current Xen capability, like Xen build system, memory > > management, domain management, vCPU context switch. > > - The expanded Xen capability, like static-allocation and direct-map. > > > > ***Notes:*** > > 1. ***This proposal only covers the work of porting Xen to Armv8-R64*** > >***single CPU.Xen SMP support on Armv8-R64 relates to Armv8-R*** > >***Trusted-Frimware (TF-R). This is an external dependency,*** > >***so we think the discussion of Xen SMP support on Armv8-R64*** > >***should be started when single-CPU support is complete.*** > > 2. ***This proposal will not touch xen-tools. In current stange,*** > >***Xen on Armv8-R64 only support dom0less, all guests should*** > >***be booted from device tree.*** > > > > ## Changelogs > > Draft-A -> Draft-B: > > 1. Update Kconfig options usage. > > 2. Update the section for XEN_START_ADDRESS. > > 3. Add description of MPU initialization before parsing device tree. > > 4. Remove CONFIG_ARM_MPU_EL1_PROTECTION_REGIONS. > > 5. Update the description of ioremap_nocache/cache. > > 6. Update about the free_init_memory on Armv8-R. > > 7. Describe why we need to switch the MPU configuration later. > > 8. Add alternative proposal in TODO. > > 9. Add use tool to generate Xen Armv8-R device tree in TODO. > > 10. Add Xen PIC/PIE discussion in TODO. > > 11. Add Xen event channel support in TODO. > > > > ## Contributors: > > Wei Chen > > Penny Zheng > > > > ## 1. Essential Background > > > > ### 1.1. Armv8-R64 Profile > > The Armv-R architecture profile was designed to support use cases that > > have a high sensitivity to deterministic execution. (e.g. Fuel Injection, > > Brake control, Drive trains, Motor control etc) > > > > Arm announced Armv8-R in 2013, it is the latest generation Arm > architecture > > targeted at the Real-time profile. It introduces virtualization at the > highest > > security level while retaining the Protected Memory System Architecture > (PMSA) > > based on a Memory Protection Unit (MPU). In 2020, Arm announced Cortex- > R82, > > which is the first Arm 64-bit Cortex-R processor based on Armv8-R64. > > > > - The latest Armv8-R64 document can be found here: > > [Arm Architecture Reference Manual Supplement - Armv8, for Armv8-R > AArch64 architecture > profile](https://developer.arm.com/documentation/ddi0600/latest/). > > > > - Armv-R Architecture progression: > > Armv7-R -> Armv8-R AArch32 -> Armv8 AArch64 > > The following figure is a simple comparison of "R" processors based on > > different Armv-R Architectures. > >  > > > > - The Armv8-R architecture evolved additional features on top of Armv7-R: > > - An exception model that is compatible with the Armv8-A model > > - Virtualization with support for guest operating systems > > - PMSA virtualization using MPUs In EL2. > > - The new features of Armv8-R64 architecture > > - Adds support for the 64-bit A64 instruction set, previously Armv8- > R > > only supported A32. > > - Supports up to 48-bit physical addressing, previously up to 32-bit > > addressing was supported. > > - Optional Arm Neon technology and Advanced SIMD > > - Supports three Exception Levels (ELs) > > - Secure EL2 - The Highest Privilege, MPU only, for firmware, > hypervisor > > - Secure EL1 - RichOS (MMU) or RTOS (MPU) > > - Secure EL0 - Application Workloads > > - Optionally supports Virtual Memory System Architecture at S-EL1/S- > EL0. > > This means it's possible to run rich OS kernels - like Linux - > either > > bare-metal or as a guest. > > - Differences with the Armv8-A AArch64 architecture > > - Supports only a single Security state - Secure. There is not Non- > Secure > > execution state supported. > > - EL3 is not supported, EL2 is mandatory. This means secure EL2 is > the > > highest EL. > > - Supports the A64 ISA instruction > > - With a small set of well-defined differences > > - Provides a PMSA (Protected Memory System Architecture) based > > virtualization model. > > - As opposed to Armv8-A AArch64's VMSA based Virtualization > > - Can support address bits up to 52 if FEAT_LPA is enabled, > > otherwise 48 bits. > > - Determines the access permissions and memory attributes of > > the target PA. > > - Can implement PMSAv8-64 at EL1 and EL2 >
[ovmf test] 169526: regressions - FAIL
flight 169526 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169526/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 495 attempts Testing same since 169441 2022-04-16 00:41:39 Z3 days 71 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: Virtio on Xen with Rust
+rust-...@lists.opendev.org On Thu, 14 Apr 2022 at 14:54, Viresh Kumar wrote: > > +xen-devel > > On 14-04-22, 14:45, Viresh Kumar wrote: > > Hello, > > > > We verified our hypervisor-agnostic Rust based vhost-user backends with Qemu > > based setup earlier, and there was growing concern if they were truly > > hypervisor-agnostic. > > > > In order to prove that, we decided to give it a try with Xen, a type-1 > > bare-metal hypervisor. > > > > We are happy to announce that we were able to make progress on that front > > and > > have a working setup where we can test our existing Rust based backends, > > like > > I2C, GPIO, RNG (though only I2C is tested as of now) over Xen. > > > > Key components: > > -- > > > > - Xen: https://github.com/vireshk/xen > > > > Xen requires MMIO and device specific support in order to populate the > > required devices at the guest. This tree contains four patches on the top > > of > > mainline Xen, two from Oleksandr (mmio/disk) and two from me (I2C). > > > > - libxen-sys: https://github.com/vireshk/libxen-sys > > > > We currently depend on the userspace tools/libraries provided by Xen, like > > xendevicemodel, xenevtchn, xenforeignmemory, etc. This crates provides > > Rust > > wrappers over those calls, generated automatically with help of bindgen > > utility in Rust, that allow us to use the installed Xen libraries. Though > > we > > plan to replace this with Rust based "oxerun" (find below) in longer run. > > > > - oxerun (WIP): https://gitlab.com/mathieupoirier/oxerun/-/tree/xen-ioctls > > > > This is Rust based implementations for Ioctl and hypercalls to Xen. This > > is WIP > > and should eventually replace "libxen-sys" crate entirely (which are C > > based > > implementation of the same). > > > > - vhost-device: https://github.com/vireshk/vhost-device > > > > These are Rust based vhost-user backends, maintained inside the rust-vmm > > project. This already contain support for I2C and RNG, while GPIO is under > > review. These are not required to be modified based on hypervisor and are > > truly hypervisor-agnostic. > > > > Ideally the backends are hypervisor agnostic, as explained earlier, but > > because of the way Xen maps the guest memory currently, we need a minor > > update > > for the backends to work. Xen maps the memory via a kernel file > > /dev/xen/privcmd, which needs calls to mmap() followed by an ioctl() to > > make > > it work. For this a hack has been added to one of the rust-vmm crates, > > vm-virtio, which is used by vhost-user. > > > > > > https://github.com/vireshk/vm-memory/commit/54b56c4dd7293428edbd7731c4dbe5739a288abd > > > > The update to vm-memory is responsible to do ioctl() after the already > > present > > mmap(). > > > > - vhost-user-master (WIP): https://github.com/vireshk/vhost-user-master > > > > This implements the master side interface of the vhost protocol, and is > > like > > the vhost-user-backend (https://github.com/rust-vmm/vhost-user-backend) > > crate > > maintained inside the rust-vmm project, which provides similar > > infrastructure > > for the backends to use. This shall be hypervisor independent and provide > > APIs > > for the hypervisor specific implementations. This will eventually be > > maintained inside the rust-vmm project and used by all Rust based > > hypervisors. > > > > - xen-vhost-master (WIP): https://github.com/vireshk/xen-vhost-master > > > > This is the Xen specific implementation and uses the APIs provided by > > "vhost-user-master", "oxerun" and "libxen-sys" crates for its functioning. > > > > This is designed based on the EPAM's "virtio-disk" repository > > (https://github.com/xen-troops/virtio-disk/) and is pretty much similar > > to it. > > > > One can see the analogy as: > > > > Virtio-disk == "Xen-vhost-master" + "vhost-user-master" + "oxerun" + > > "libxen-sys" + "vhost-device". > > > > > > > > Test setup: > > -- > > > > 1. Build Xen: > > > > $ ./configure --libdir=/usr/lib --build=x86_64-unknown-linux-gnu > > --host=aarch64-linux-gnu --disable-docs --disable-golang > > --disable-ocamltools > > --with-system-qemu=/root/qemu/build/i386-softmmu/qemu-system-i386; > > $ make -j9 debball CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64 > > > > 2. Run Xen via Qemu on X86 machine: > > > > $ qemu-system-aarch64 -machine virt,virtualization=on -cpu cortex-a57 > > -serial mon:stdio \ > > -device virtio-net-pci,netdev=net0 -netdev > > user,id=net0,hostfwd=tcp::8022-:22 \ > > -device virtio-scsi-pci -drive > > file=/home/vireshk/virtio/debian-bullseye-arm64.qcow2,index=0,id=hd0,if=none,format=qcow2 > > -device scsi-hd,drive=hd0 \ > > -display none -m 8192 -smp 8 -kernel /home/vireshk/virtio/xen/xen \ > > -append "dom0_mem=5G,max:5G dom0_max_vcpus=7 loglvl=all > > guest_loglvl=all" \ > > -device > >
[ovmf test] 169525: regressions - FAIL
flight 169525 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169525/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 494 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 70 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169524: regressions - FAIL
flight 169524 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169524/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 493 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 69 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [PATCH V7 2/2] libxl: Introduce basic virtio-mmio support on Arm
Hi, Sorry for the formatting issues. On Mon, 18 Apr 2022, 21:41 Stefano Stabellini, wrote: > > +static uint64_t virtio_mmio_base; > > +static uint32_t virtio_mmio_irq; > > No need for these two variables to be global in this file, they could be > local variables in libxl__arch_domain_prepare_config. It is more than "no need". Libxl can be used by a daemon to handle multiple domains. So we can't use static variable to keep track of local information. Cheers,
[ovmf test] 169523: regressions - FAIL
flight 169523 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169523/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 492 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 68 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [RFC PATCH] libxl/arm: Insert "xen,dev-domid" property to virtio-mmio device node
On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is needed for grant table based DMA ops layer (CONFIG_XEN_VIRTIO)
> at the guest side to retrieve the ID of Xen domain where the corresponding
> backend resides (it is used as an argument to the grant table APIs).
>
> This is a part of restricted memory access under Xen feature.
>
> Signed-off-by: Oleksandr Tyshchenko
I think this looks good overall. Instead of mentioning details of the
Linux implementation, we should mention the device tree binding instead,
including a link to it. The device tree binding is the relevant spec in
this case.
> ---
> !!! This patch is based on non upstreamed yet “Virtio support for toolstack
> on Arm” series which is on review now:
> https://lore.kernel.org/xen-devel/1649442065-8332-1-git-send-email-olekst...@gmail.com/
>
> All details are at:
> https://lore.kernel.org/xen-devel/1649963973-22879-1-git-send-email-olekst...@gmail.com/
> ---
> tools/libs/light/libxl_arm.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 8132a47..d9b26fc 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -875,7 +875,8 @@ static int make_vpci_node(libxl__gc *gc, void *fdt,
>
>
> static int make_virtio_mmio_node(libxl__gc *gc, void *fdt,
> - uint64_t base, uint32_t irq)
> + uint64_t base, uint32_t irq,
> + uint32_t backend_domid)
> {
> int res;
> gic_interrupt intr;
> @@ -900,6 +901,14 @@ static int make_virtio_mmio_node(libxl__gc *gc, void
> *fdt,
> res = fdt_property(fdt, "dma-coherent", NULL, 0);
> if (res) return res;
>
> +if (backend_domid != LIBXL_TOOLSTACK_DOMID) {
> +uint32_t domid[1];
> +
> +domid[0] = cpu_to_fdt32(backend_domid);
> +res = fdt_property(fdt, "xen,dev-domid", domid, sizeof(domid));
> +if (res) return res;
> +}
> +
> res = fdt_end_node(fdt);
> if (res) return res;
>
> @@ -1218,7 +1227,8 @@ next_resize:
> libxl_device_disk *disk = _config->disks[i];
>
> if (disk->protocol == LIBXL_DISK_PROTOCOL_VIRTIO_MMIO)
> -FDT( make_virtio_mmio_node(gc, fdt, disk->base, disk->irq) );
> +FDT( make_virtio_mmio_node(gc, fdt, disk->base, disk->irq,
> + disk->backend_domid) );
> }
>
> if (pfdt)
> --
> 2.7.4
>
Re: [PATCH V7 2/2] libxl: Introduce basic virtio-mmio support on Arm
On Fri, 8 Apr 2022, Oleksandr Tyshchenko wrote:
> From: Julien Grall
>
> This patch introduces helpers to allocate Virtio MMIO params
> (IRQ and memory region) and create specific device node in
> the Guest device-tree with allocated params. In order to deal
> with multiple Virtio devices, reserve corresponding ranges.
> For now, we reserve 1MB for memory regions and 10 SPIs.
>
> As these helpers should be used for every Virtio device attached
> to the Guest, call them for Virtio disk(s).
>
> Please note, with statically allocated Virtio IRQs there is
> a risk of a clash with a physical IRQs of passthrough devices.
> For the first version, it's fine, but we should consider allocating
> the Virtio IRQs automatically. Thankfully, we know in advance which
> IRQs will be used for passthrough to be able to choose non-clashed
> ones.
>
> Signed-off-by: Julien Grall
> Signed-off-by: Oleksandr Tyshchenko
> Tested-by: Jiamei Xie
> Reviewed-by: Henry Wang
I realize that we are at v7 and I haven't reviewed this before, so I'll
limit my comments. I'll clarify the ones that I think are more important
from the one that are less important.
> ---
> @Jiamei, @Henry I decided to leave your T-b and R-b tags with the minor
> change I made, are you still happy with that?
>
> s/if (disk->virtio)/if (disk->protocol == LIBXL_DISK_PROTOCOL_VIRTIO_MMIO)
>
> Please note, this is a split/cleanup/hardening of Julien's PoC:
> "Add support for Guest IO forwarding to a device emulator"
>
> Changes RFC -> V1:
>- was squashed with:
> "[RFC PATCH V1 09/12] libxl: Handle virtio-mmio irq in more correct way"
> "[RFC PATCH V1 11/12] libxl: Insert "dma-coherent" property into
> virtio-mmio device node"
> "[RFC PATCH V1 12/12] libxl: Fix duplicate memory node in DT"
>- move VirtIO MMIO #define-s to xen/include/public/arch-arm.h
>
> Changes V1 -> V2:
>- update the author of a patch
>
> Changes V2 -> V3:
>- no changes
>
> Changes V3 -> V4:
>- no changes
>
> Changes V4 -> V5:
>- split the changes, change the order of the patches
>- drop an extra "virtio" configuration option
>- update patch description
>- use CONTAINER_OF instead of own implementation
>- reserve ranges for Virtio MMIO params and put them
> in correct location
>- create helpers to allocate Virtio MMIO params, add
> corresponding sanity-сhecks
>- add comment why MMIO size 0x200 is chosen
>- update debug print
>- drop Wei's T-b
>
> Changes V5 -> V6:
>- rebase on current staging
>
> Changes V6 -> V7:
>- rebase on current staging
>- add T-b and R-b tags
>- update according to the recent changes to
> "libxl: Add support for Virtio disk configuration"
> ---
> tools/libs/light/libxl_arm.c | 131
> +-
> xen/include/public/arch-arm.h | 7 +++
> 2 files changed, 136 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index eef1de0..8132a47 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -8,6 +8,56 @@
> #include
> #include
>
> +/*
> + * There is no clear requirements for the total size of Virtio MMIO region.
> + * The size of control registers is 0x100 and device-specific configuration
> + * registers starts at the offset 0x100, however it's size depends on the
> device
> + * and the driver. Pick the biggest known size at the moment to cover most
> + * of the devices (also consider allowing the user to configure the size via
> + * config file for the one not conforming with the proposed value).
> + */
> +#define VIRTIO_MMIO_DEV_SIZE xen_mk_ullong(0x200)
Actually, I don't think we need to make this generic. We only support
virtio-disk now and I think it is fine if this was called
VIRTIO_DISK_MMIO_DEV_SIZE and the size was exactly the size needed by
virtio-disk. When/if we support another virtio protocol we can add set
the appropriate size of that one as well.
At the moment as you can see below:
*/
for (i = 0; i < d_config->num_disks; i++) {
libxl_device_disk *disk = _config->disks[i];
if (disk->protocol == LIBXL_DISK_PROTOCOL_VIRTIO_MMIO) {
it is all very virtio-disk specific, so we might as well exploit it for
the better :-)
Given that we are at v7 of this series, I don't think this is very
important, so I think it is OK if we keep the code as is.
> +static uint64_t virtio_mmio_base;
> +static uint32_t virtio_mmio_irq;
No need for these two variables to be global in this file, they could be
local variables in libxl__arch_domain_prepare_config.
I think that this is a change we should make if possible before
committing these patches.
> +static void init_virtio_mmio_params(void)
> +{
> +virtio_mmio_base = GUEST_VIRTIO_MMIO_BASE;
> +virtio_mmio_irq = GUEST_VIRTIO_MMIO_SPI_FIRST;
> +}
> +
> +static uint64_t alloc_virtio_mmio_base(libxl__gc *gc)
> +{
> +uint64_t base =
Re: [PATCH V7 1/2] libxl: Add support for Virtio disk configuration
> From: Oleksandr Tyshchenko > > This patch adds basic support for configuring and assisting virtio-mmio > based virtio-disk backend (emualator) which is intended to run out of ^ emulator
Re: [PATCH v2] Grab the EFI System Resource Table and check it
On Wed, Apr 06, 2022 at 12:10:17PM +0200, Jan Beulich wrote:
> On 02.04.2022 01:14, Demi Marie Obenour wrote:
> > The EFI System Resource Table (ESRT) is necessary for fwupd to identify
> > firmware updates to install. According to the UEFI specification §23.4,
> > the table shall be stored in memory of type EfiBootServicesData.
> > Therefore, Xen must avoid reusing that memory for other purposes, so
> > that Linux can access the ESRT. Additionally, Xen must mark the memory
> > as reserved, so that Linux knows accessing it is safe.
> >
> > See https://lore.kernel.org/xen-devel/20200818184018.GN1679@mail-itl/T/
> > for details.
> >
> > Signed-off-by: Demi Marie Obenour
>
> First a note on patch submission: Patches are sent To: the list, with
> Cc: to involved maintainers (and perhaps other interested parties).
Sorry about that — I am used to Linux which does things the other way
around.
> > ---
> > xen/arch/arm/efi/efi-boot.h | 9 +++--
> > xen/arch/x86/efi/efi-boot.h | 5 ++-
> > xen/common/efi/boot.c | 77 +++--
> > xen/common/efi/efi.h| 2 +-
> > xen/common/efi/runtime.c| 5 ++-
> > xen/include/efi/efiapi.h| 3 ++
> > 6 files changed, 89 insertions(+), 12 deletions(-)
>
> This being v2 (oddly enough with another v2 sent on Mar 30), you will
> want to add a brief revision log clarifying to reviewers what has
> changed. Together with the duplicate v2 it's not really clear whether
> this was a plain resend, or whether anything actually changed (it
> looks like you did address the Arm build issue).
Only change was to break the ARM build IIRC.
> > --- a/xen/arch/arm/efi/efi-boot.h
> > +++ b/xen/arch/arm/efi/efi-boot.h
> > @@ -176,7 +176,8 @@ static bool __init meminfo_add_bank(struct meminfo *mem,
> >
> > static EFI_STATUS __init
> > efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *map,
> > UINTN mmap_size,
> > -UINTN desc_size)
> > +UINTN desc_size,
> > +const
> > EFI_MEMORY_DESCRIPTOR *const esrt_desc)
>
> Please omit the 2nd const (here and elsewhere) - no other parameters are
> modified like this.
Will fix in v3.
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -154,7 +154,8 @@ static void __init
> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> > void *map,
> > UINTN map_size,
> > UINTN desc_size,
> > - UINT32 desc_ver)
> > + UINT32 desc_ver,
> > + const EFI_MEMORY_DESCRIPTOR
> > *const esrt_desc)
> > {
> > struct e820entry *e;
> > unsigned int i;
> > @@ -171,7 +172,7 @@ static void __init
> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> > {
> > case EfiBootServicesCode:
> > case EfiBootServicesData:
> > -if ( map_bs )
> > +if ( map_bs || desc == esrt_desc )
> > {
> > default:
> > type = E820_RESERVED;
>
> How certain is it that this descriptor doesn't cover (much) more than
> just ESRT? This could be quite wasteful in terms of memory which
> wouldn't be reclaimed just because of the (perhaps small) ESRT.
I can’t be certain at all, but this has the advantage of a much simpler
and smaller patch. I don’t intend to fix this in v3, but I will send a
follow-up patch that fixes it for x86.
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -93,6 +93,23 @@ typedef struct _EFI_LOAD_OPTION {
> > CHAR16 Description[];
> > } EFI_LOAD_OPTION;
> >
> > +struct esrt_entry {
> > +EFI_GUID fw_class;
> > +UINT32 fw_type;
> > +UINT32 fw_version;
> > +UINT32 fw_lowest_supported_version;
> > +UINT32 fw_capsule_flags;
> > +UINT32 fw_last_attempt_version;
> > +UINT32 fw_last_attempt_status;
> > +};
> > +
> > +struct esrt {
> > +UINT32 esrt_count;
> > +UINT32 esrt_max;
> > +UINT64 esrt_version;
> > +struct esrt_entry esrt_entries[];
> > +};
>
> Please follow the naming and naming convention used by immediately
> preceding structure definitions as well as the specification: All
> names matching the spec and using typedef. That's how such structures
> would eventually be added to the EFI headers we're inheriting from
> the gnu-efi package. At such a point we would want to be able to
> delete the declarations here without needing to touch any other code.
>
> > #define LOAD_OPTION_ACTIVE 0x0001
>
> Also please don't insert in the middle of two related definitions.
>
> > @@ -567,6 +584,38 @@ static int __init
[ovmf test] 169522: regressions - FAIL
flight 169522 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169522/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 491 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 67 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [PATCH 09/11] nvme: remove a spurious clear of discard_alignment
On 4/17/22 21:53, Christoph Hellwig wrote: > The nvme driver never sets a discard_alignment, so it also doens't need > to clear it to zero. > > Signed-off-by: Christoph Hellwig > --- Reviewed-by: Chaitanya Kulkarni -ck
Re: [PATCH 03/11] null_blk: don't set the discard_alignment queue limit
On 4/17/22 21:53, Christoph Hellwig wrote: > The discard_alignment queue limit is named a bit misleading means the > offset into the block device at which the discard granularity starts. > Setting it to the discard granularity as done by null_blk is mostly > harmless but also useless. > > Signed-off-by: Christoph Hellwig > --- Reviewed-by: Chaitanya Kulkarni -ck
Re: [PATCH 08/11] loop: remove a spurious clear of discard_alignment
On 4/17/22 21:53, Christoph Hellwig wrote: > The loop driver never sets a discard_alignment, so it also doens't need s/doens't/doesn't/ > to clear it to zero. > > Signed-off-by: Christoph Hellwig Reviewed-by: Chaitanya Kulkarni -ck
Re: [PATCH v12] xen/arm64: io: Handle data abort due to cache maintenance instructions
On Fri, 1 Apr 2022, Julien Grall wrote:
> On 24/03/2022 13:37, Ayan Kumar Halder wrote:
> > /*
> >* At this point, we know that the instruction is either valid or has
> > been
> >* decoded successfully. Thus, Xen should be allowed to execute the
> > diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
> > index 54167aebcb..87a6240f2a 100644
> > --- a/xen/arch/arm/ioreq.c
> > +++ b/xen/arch/arm/ioreq.c
> > @@ -47,7 +47,7 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
> >struct vcpu *v, mmio_info_t *info)
> > {
> > struct vcpu_io *vio = >io;
> > -struct instr_details instr = info->dabt_instr;
> > +const struct instr_details instr = info->dabt_instr;
> > struct hsr_dabt dabt = info->dabt;
> > ioreq_t p = {
> > .type = IOREQ_TYPE_COPY,
> > @@ -62,7 +62,6 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
> >* memory access. So for now, we can safely always set to 0.
> >*/
> > .df = 0,
> > -.data = get_user_reg(regs, info->dabt.reg),
> > .state = STATE_IOREQ_READY,
> > };
> > struct ioreq_server *s = NULL;
> > @@ -74,12 +73,23 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
> > return IO_ABORT;
> > }
> > +if ( instr.state == INSTR_CACHE )
> > +p.size = dcache_line_bytes;
> I think it would be best to only set the p.size when instr.state !=
> INSTR_CACHE in the else here.
>
> I can do that on commit. I will also give a chance to Stefano to reply.
The patch looks OK to me, please go ahead and make the change on
commit.
[ovmf test] 169521: regressions - FAIL
flight 169521 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169521/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 490 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 66 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: xen-swiotlb issue when NVMe driver is enabled in Dom0 on ARM
On Sun, 17 Apr 2022, Rahul Singh wrote:
> > On 15 Apr 2022, at 6:40 pm, Stefano Stabellini
> > wrote:
> > On Fri, 15 Apr 2022, Christoph Hellwig wrote:
> >> On Thu, Apr 14, 2022 at 01:39:23PM -0700, Stefano Stabellini wrote:
> >>> OK, now we know that the code path with Xen is correct and it is the
> >>> same code path taken (dma_alloc_direct) as when !CONFIG_XEN and !SMMU.
> >>> That is how it should be.
> >>>
> >>> I cannot explain why dma_alloc_direct() would fail when called from
> >>> xen_swiotlb_alloc_coherent(), but it would succeed when called from
> >>> dma_alloc_attrs() without Xen.
> >>>
> >>> I am not aware of any restrictions that xen or swiotlb-xen would
> >>> introduce in that regard. Unless you are just running out of memory
> >>> because dom0_mem too low.
> >>
> >> The crash is deep down in the page allocator. Even if memory was low
> >> it should no crash. So there is some odd interaction between Xen
> >> and the page allocator going on. I think nvme and dma-direct really
> >> are only the messenger here.
> >
> >
> > I cannot think of anything but if that is the case I guess it is more
> > likely related to reserved-memory not properly advertised or ACPI tables
> > not properly populated.
>
> I am not sure if it is true as we are able to boot with the same reserved
> memory or
> the same ACPI table populated if we boot without swiotlb-xen dma ops.
>
> >
> >
> > Rahul,
> >
> > What happens if you boot Linux on Xen with swiotlb-xen disabled?
>
> Linux boots fine without any issue if we disable swiotlb-xen as mentioned
> below.
The plot thinkens.
Without swiotlb-xen, Linux boots fine. With swiotlb-xen it crashes.
However, in both cases, the very same memory allocation function is
used: dma_direct_alloc. In one case it works, in the other case it
crashes. Everything else is the same.
There are a couple of questionable things with dma masks in
xen_swiotlb_alloc_coherent, but they are *after* the call to
xen_alloc_coherent_pages, which is the one that crashes. So they cannot
be the cause of the crash.
Before the call to xen_alloc_coherent_pages, there is only:
1) flags &= ~(__GFP_DMA | __GFP_HIGHMEM);
2) size = 1UL << (order + XEN_PAGE_SHIFT);
1) is already done by dma_alloc_attrs, so it is superfluous. I couldn't
explain how 2) could possibly trigger the crash. XEN_PAGE_SHIFT is
always 12 even on 64K pages kernels. You can try removing 2) from
xen_swiotlb_alloc_coherent, but we are really wandering in the dark
here.
Then there is xen_swiotlb_init() which allocates some memory for
swiotlb-xen at boot. It could lower the total amount of memory
available, but if you disabled swiotlb-xen like I suggested,
xen_swiotlb_init() still should get called and executed anyway at boot
(it is called from arch/arm/xen/mm.c:xen_mm_init). So xen_swiotlb_init()
shouldn't be the one causing problems.
That's it -- there is nothing else in swiotlb-xen that I can think of.
I don't have any good ideas, so I would only suggest to add more printks
and report the results, for instance:
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 2b385c1b4a99..c81f9dc7e5a0 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -284,6 +284,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t
size,
phys_addr_t phys;
dma_addr_t dev_addr;
+ printk("DEBUG %s %d size=%lu flags=%x
attr=%lx\n",__func__,__LINE__,size,flags,attrs);
/*
* Ignore region specifiers - the kernel's ideas of
* pseudo-phys memory layout has nothing to do with the
@@ -295,6 +296,8 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t
size,
/* Convert the size to actually allocated. */
size = 1UL << (order + XEN_PAGE_SHIFT);
+ printk("DEBUG %s %d size=%lu flags=%x
attr=%lx\n",__func__,__LINE__,size,flags,attrs);
+
/* On ARM this function returns an ioremap'ped virtual address for
* which virt_to_phys doesn't return the corresponding physical
* address. In fact on ARM virt_to_phys only works for kernel direct
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 51bb8fa8eb89..549b2c85999c 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -429,9 +429,11 @@ void *dma_alloc_attrs(struct device *dev, size_t size,
dma_addr_t *dma_handle,
if (dma_alloc_from_dev_coherent(dev, size, dma_handle, _addr))
return cpu_addr;
+ printk("DEBUG %s %d size=%lu flags=%x
attr=%lx\n",__func__,__LINE__,size,flags,attrs);
/* let the implementation decide on the zone to allocate from: */
flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
+ printk("DEBUG %s %d size=%lu flags=%x
attr=%lx\n",__func__,__LINE__,size,flags,attrs);
if (dma_alloc_direct(dev, ops))
cpu_addr = dma_direct_alloc(dev, size, dma_handle, flag, attrs);
else if (ops->alloc)
[ovmf test] 169520: regressions - FAIL
flight 169520 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169520/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 489 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 65 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169519: regressions - FAIL
flight 169519 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169519/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 488 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 64 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [RFC PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer
On Sun, 17 Apr 2022, Oleksandr wrote:
> On 16.04.22 01:02, Stefano Stabellini wrote:
> > On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > In the context of current patch do the following:
> > > 1. Update code to support virtio-mmio devices
> > > 2. Introduce struct xen_virtio_data and account passed virtio devices
> > > (using list) as we need to store some per-device data
> > > 3. Add multi-page support for xen_virtio_dma_map(unmap)_page callbacks
> > > 4. Harden code against malicious backend
> > > 5. Change to use alloc_pages_exact() instead of __get_free_pages()
> > > 6. Introduce locking scheme to protect mappings (I am not 100% sure
> > > whether per-device lock is really needed)
> > > 7. Handle virtio device's DMA mask
> > > 8. Retrieve the ID of backend domain from DT for virtio-mmio device
> > > instead of hardcoding it.
> > >
> > > Signed-off-by: Oleksandr Tyshchenko
> > > ---
> > > arch/arm/xen/enlighten.c | 11 +++
> > > drivers/xen/Kconfig | 2 +-
> > > drivers/xen/xen-virtio.c | 200
> > > ++-
> > > include/xen/xen-ops.h| 5 ++
> > > 4 files changed, 196 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > > index ec5b082..870d92f 100644
> > > --- a/arch/arm/xen/enlighten.c
> > > +++ b/arch/arm/xen/enlighten.c
> > > @@ -409,6 +409,17 @@ int __init arch_xen_unpopulated_init(struct resource
> > > **res)
> > > }
> > > #endif
> > > +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> > > +int arch_has_restricted_virtio_memory_access(void)
> > > +{
> > > + if (IS_ENABLED(CONFIG_XEN_HVM_VIRTIO_GRANT) && xen_hvm_domain())
> > > + return 1;
> > Instead of xen_hvm_domain(), you can just use xen_domain(). Also there
> > is no need for the #ifdef
> > CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, given that:
> >
> > CONFIG_XEN_HVM_VIRTIO_GRANT depends on XEN_VIRTIO which selects
> > ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
>
>
> Yes, but please see my comments in commit #2 regarding
> CONFIG_XEN_HVM_VIRTIO_GRANT option and
> arch_has_restricted_virtio_memory_access() on Arm.
>
> I propose to have the following on Arm:
>
> int arch_has_restricted_virtio_memory_access(void)
> {
> return xen_has_restricted_virtio_memory_access();
> }
>
>
> where common xen.h contain a helper to be used by both Arm and x86:
>
> static inline int xen_has_restricted_virtio_memory_access(void)
> {
> if (IS_ENABLED(CONFIG_XEN_VIRTIO) && (xen_pv_domain() ||
> xen_hvm_domain()))
> return 1;
>
> return 0;
> }
>
>
> But I would be happy with what you propose as well.
As I wrote in the previous reply, I also prefer to share the code
between x86 and ARM, and I think it could look like:
int arch_has_restricted_virtio_memory_access(void)
{
return xen_has_restricted_virtio_memory_access();
}
[...]
static inline int xen_has_restricted_virtio_memory_access(void)
{
return (IS_ENABLED(CONFIG_XEN_VIRTIO) && xen_domain());
}
But let's check with Juergen and Boris.
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
> > > +#endif
> > > +
> > > static void __init xen_dt_guest_init(void)
> > > {
> > > struct device_node *xen_node;
> > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > > index fc61f7a..56afe6a 100644
> > > --- a/drivers/xen/Kconfig
> > > +++ b/drivers/xen/Kconfig
> > > @@ -347,7 +347,7 @@ config XEN_VIRTIO
> > > config XEN_HVM_VIRTIO_GRANT
> > > bool "Require virtio for fully virtualized guests to use grant
> > > mappings"
> > > - depends on XEN_VIRTIO && X86_64
> > > + depends on XEN_VIRTIO && (X86_64 || ARM || ARM64)
> > you can remove the architectural dependencies
>
>
> According to the conversation in commit #2 we are considering just a single
> XEN_VIRTIO option, but it is going to has the
> same architectural dependencies: (X86_64 || ARM || ARM64)
>
> By removing the architectural dependencies here, we will leave also X86_32
> covered (neither XEN_HVM_VIRTIO_GRANT nor XEN_PV_VIRTIO covered it). I don't
> know whether it is ok or not.
>
> Shall I remove dependencies anyway?
No, good point. I don't know about X86_32. This is another detail where
Juergen or Boris should comment.
Re: [RFC PATCH 6/6] arm/xen: Assign xen-virtio DMA ops for virtio devices in Xen guests
On Mon, 18 Apr 2022, Oleksandr wrote: > On 16.04.22 09:07, Christoph Hellwig wrote: > > Hello Christoph > > > On Fri, Apr 15, 2022 at 03:02:45PM -0700, Stefano Stabellini wrote: > > > This makes sense overall. Considering that the swiotlb-xen case and the > > > virtio case are mutually exclusive, I would write it like this: > > Curious question: Why can't the same grant scheme also be used for > > non-virtio devices? I really hate having virtio hooks in the arch > > dma code. Why can't Xen just say in DT/ACPI that grants can be used > > for a given device? [...] > This patch series tries to make things work with "virtio" devices in Xen > system without introducing any modifications to code under drivers/virtio. Actually, I think Christoph has a point. There is nothing inherently virtio specific in this patch series or in the "xen,dev-domid" device tree binding. Assuming a given device is emulated by a Xen backend, it could be used with grants as well. For instance, we could provide an emulated e1000 NIC with a "xen,dev-domid" property in device tree. Linux could use grants with it and the backend could map the grants. It would work the same way as virtio-net/block/etc. Passthrough devices wouldn't have the "xen,dev-domid" property, so no problems. So I think we could easily generalize this work and expand it to any device. We just need to hook on the "xen,dev-domid" device tree property. I think it is just a matter of: - remove the "virtio,mmio" check from xen_is_virtio_device - rename xen_is_virtio_device to something more generic, like xen_is_grants_device - rename xen_virtio_setup_dma_ops to something more generic, like xen_grants_setup_dma_ops And that's pretty much it.
Re: [RFC PATCH 2/6] virtio: add option to restrict memory access under Xen
On Sun, 17 Apr 2022, Oleksandr wrote:
> On 16.04.22 01:01, Stefano Stabellini wrote:
> > On Thu, 14 Apr 2022, Oleksandr Tyshchenko wrote:
> > > From: Juergen Gross
> > >
> > > In order to support virtio in Xen guests add a config option enabling
> > > the user to specify whether in all Xen guests virtio should be able to
> > > access memory via Xen grant mappings only on the host side.
> > >
> > > This applies to fully virtualized guests only, as for paravirtualized
> > > guests this is mandatory.
> > >
> > > This requires to switch arch_has_restricted_virtio_memory_access()
> > > from a pure stub to a real function on x86 systems (Arm systems are
> > > not covered by now).
> > >
> > > Add the needed functionality by providing a special set of DMA ops
> > > handling the needed grant operations for the I/O pages.
> > >
> > > Signed-off-by: Juergen Gross
> > > ---
> > > arch/x86/mm/init.c| 15
> > > arch/x86/mm/mem_encrypt.c | 5 --
> > > arch/x86/xen/Kconfig | 9 +++
> > > drivers/xen/Kconfig | 20 ++
> > > drivers/xen/Makefile | 1 +
> > > drivers/xen/xen-virtio.c | 177
> > > ++
> > > include/xen/xen-ops.h | 8 +++
> > > 7 files changed, 230 insertions(+), 5 deletions(-)
> > > create mode 100644 drivers/xen/xen-virtio.c
> > >
> > > diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> > > index d8cfce2..526a3b2 100644
> > > --- a/arch/x86/mm/init.c
> > > +++ b/arch/x86/mm/init.c
> > > @@ -8,6 +8,8 @@
> > > #include
> > > #include
> > > +#include
> > > +
> > > #include
> > > #include
> > > #include
> > > @@ -1065,3 +1067,16 @@ unsigned long max_swapfile_size(void)
> > > return pages;
> > > }
> > > #endif
> > > +
> > > +#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> > > +int arch_has_restricted_virtio_memory_access(void)
> > > +{
> > > + if (IS_ENABLED(CONFIG_XEN_PV_VIRTIO) && xen_pv_domain())
> > > + return 1;
> > > + if (IS_ENABLED(CONFIG_XEN_HVM_VIRTIO_GRANT) && xen_hvm_domain())
> > > + return 1;
> > I think these two checks could be moved to a separate function in a Xen
> > header, e.g. xen_restricted_virtio_memory_access, and here you could
> > just
> >
> > if (xen_restricted_virtio_memory_access())
> > return 1;
>
> Agree, will do
>
>
> >
> >
> >
> > > + return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
> > > +}
> > > +EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
> > > +#endif
> > > diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> > > index 50d2099..dda020f 100644
> > > --- a/arch/x86/mm/mem_encrypt.c
> > > +++ b/arch/x86/mm/mem_encrypt.c
> > > @@ -77,8 +77,3 @@ void __init mem_encrypt_init(void)
> > > print_mem_encrypt_feature_info();
> > > }
> > > -int arch_has_restricted_virtio_memory_access(void)
> > > -{
> > > - return cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT);
> > > -}
> > > -EXPORT_SYMBOL_GPL(arch_has_restricted_virtio_memory_access);
> > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > index 85246dd..dffdffd 100644
> > > --- a/arch/x86/xen/Kconfig
> > > +++ b/arch/x86/xen/Kconfig
> > > @@ -92,3 +92,12 @@ config XEN_DOM0
> > > select X86_X2APIC if XEN_PVH && X86_64
> > > help
> > > Support running as a Xen Dom0 guest.
> > > +
> > > +config XEN_PV_VIRTIO
> > > + bool "Xen virtio support for PV guests"
> > > + depends on XEN_VIRTIO && XEN_PV
> > > + default y
> > > + help
> > > + Support virtio for running as a paravirtualized guest. This will
> > > + need support on the backend side (qemu or kernel, depending on the
> > > + virtio device types used).
> > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > > index 120d32f..fc61f7a 100644
> > > --- a/drivers/xen/Kconfig
> > > +++ b/drivers/xen/Kconfig
> > > @@ -335,4 +335,24 @@ config XEN_UNPOPULATED_ALLOC
> > > having to balloon out RAM regions in order to obtain physical
> > > memory
> > > space to create such mappings.
> > > +config XEN_VIRTIO
> > > + bool "Xen virtio support"
> > > + default n
> > > + depends on VIRTIO && DMA_OPS
> > > + select ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> > > + help
> > > + Enable virtio support for running as Xen guest. Depending on the
> > > + guest type this will require special support on the backend side
> > > + (qemu or kernel, depending on the virtio device types used).
> > > +
> > > +config XEN_HVM_VIRTIO_GRANT
> > > + bool "Require virtio for fully virtualized guests to use grant
> > > mappings"
> > > + depends on XEN_VIRTIO && X86_64
> > > + default y
> > > + help
> > > + Require virtio for fully virtualized guests to use grant mappings.
> > > + This will avoid the need to give the backend the right to map all
> > > + of the guest memory. This will need support on the backend side
> > > + (qemu or kernel, depending on the virtio device types used).
> > I don't think we
Re: [PATCH v5] x86/vmx: add hvm functions to get/set non-register state
On Fri, Mar 25, 2022 at 9:34 AM Tamas K Lengyel wrote: > > 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 adding a new pair of hvm functions to get/set the guest > non-register state so that the overall vCPU state remains in sync. > > Signed-off-by: Tamas K Lengyel > --- > v5: Switch to internal-only hvm funcs instead of adding to hvm_hw_cpu Patch ping.
[ovmf test] 169518: regressions - FAIL
flight 169518 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169518/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 487 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 63 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169517: regressions - FAIL
flight 169517 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169517/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 486 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 62 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169516: regressions - FAIL
flight 169516 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169516/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 485 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 61 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[PATCH v2 06/25] x86/xen: Add ANNOTATE_ENDBR to startup_xen()
The startup_xen() kernel entry point is referenced by the ".note.Xen" section, but is presumably not indirect-branched to. Add ANNOTATE_ENDBR to silence future objtool warnings. Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: xen-devel@lists.xenproject.org Signed-off-by: Josh Poimboeuf --- arch/x86/xen/xen-head.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S index ac17196e2518..3a2cd93bf059 100644 --- a/arch/x86/xen/xen-head.S +++ b/arch/x86/xen/xen-head.S @@ -45,6 +45,7 @@ SYM_CODE_END(hypercall_page) __INIT SYM_CODE_START(startup_xen) UNWIND_HINT_EMPTY + ANNOTATE_NOENDBR cld /* Clear .bss */ -- 2.34.1
[ovmf test] 169515: regressions - FAIL
flight 169515 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169515/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 484 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 60 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169514: regressions - FAIL
flight 169514 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169514/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 483 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 59 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169513: regressions - FAIL
flight 169513 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169513/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 482 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 58 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169512: regressions - FAIL
flight 169512 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169512/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 481 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 57 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169511: regressions - FAIL
flight 169511 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169511/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 480 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 56 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: use block_device based APIs in block layer consumers v3
On Fri, 15 Apr 2022 06:52:31 +0200, Christoph Hellwig wrote:
> this series cleanups up the block layer API so that APIs consumed
> by file systems are (almost) only struct block_devic based, so that
> file systems don't have to poke into block layer internals like the
> request_queue.
>
> I also found a bunch of existing bugs related to partition offsets
> and discard so these are fixed while going along.
>
> [...]
Applied, thanks!
[01/27] target: remove an incorrect unmap zeroes data deduction
commit: 179d8609d8424529e95021df939ed7b0b82b37f1
[02/27] target: pass a block_device to target_configure_unmap_from_queue
commit: 817e8b51eb3d927ce6d56ecf9f48bc3c5b26168b
[03/27] target: fix discard alignment on partitions
commit: 968786b9ef56e75e0109158a4936ea962c1e
[04/27] drbd: remove assign_p_sizes_qlim
commit: 40349d0e16cedd0de561f59752c3249780fb749b
[05/27] drbd: use bdev based limit helpers in drbd_send_sizes
commit: 7a38acce229685968b770d1d9e64e01396b93643
[06/27] drbd: use bdev_alignment_offset instead of queue_alignment_offset
commit: c6f23b1a05441a26f765e59dd95e8ba7354f9388
[07/27] drbd: cleanup decide_on_discard_support
commit: 998e9cbcd615e5e6a7baa69e673ee845f812744e
[08/27] btrfs: use bdev_max_active_zones instead of open coding it
commit: c1e7b24416400ef13ff92a1c60c336c9a2834d7b
[09/27] ntfs3: use bdev_logical_block_size instead of open coding it
commit: f09dac9afb8e3ce4b6485dbc091a9b9c742db023
[10/27] mm: use bdev_is_zoned in claim_swapfile
commit: 9964e674559b02619fee2012a56839624143d02e
[11/27] block: add a bdev_nonrot helper
commit: 10f0d2a517796b8f6dc04fb0cc3e49003ae6b0bc
[12/27] block: add a bdev_write_cache helper
commit: 08e688fdb8f7e862092ae64cee20bc8b463d1046
[13/27] block: add a bdev_fua helper
commit: a557e82e5a01826f902bd94fc925c03f253cb712
[14/27] block: add a bdev_stable_writes helper
commit: 36d254893aa6a6e204075c3cce94bb572ac32c04
[15/27] block: add a bdev_max_zone_append_sectors helper
commit: 2aba0d19f4d8c8929b4b3b94a9cfde2aa20e6ee2
[16/27] block: use bdev_alignment_offset in part_alignment_offset_show
commit: 64dcc7c2717395b7c83ffb10f040d3be795d03c1
[17/27] block: use bdev_alignment_offset in disk_alignment_offset_show
commit: 640f2a23911b8388989547f89d055afbb910b88e
[18/27] block: move bdev_alignment_offset and queue_limit_alignment_offset out
of line
commit: 89098b075cb74a80083bc4ed6b71d0ee18b6898f
[19/27] block: remove queue_discard_alignment
commit: 4e1462ffe8998749884d61f91be251a7a8719677
[20/27] block: use bdev_discard_alignment in part_discard_alignment_show
commit: f0f975a4dde890bfe25ce17bf07a6495453988a4
[21/27] block: move {bdev,queue_limit}_discard_alignment out of line
commit: 5c4b4a5c6f11c869a57c6bd977143430bc9dc43d
[22/27] block: refactor discard bio size limiting
commit: e3cc28ea28b5f8794db2aed24f8a0282ad2e85a2
[23/27] block: add a bdev_max_discard_sectors helper
commit: cf0fbf894bb543f472f682c486be48298eccf199
[24/27] block: remove QUEUE_FLAG_DISCARD
commit: 70200574cc229f6ba038259e8142af2aa09e6976
[25/27] block: add a bdev_discard_granularity helper
commit: 7b47ef52d0a2025fd1408a8a0990933b8e1e510f
[26/27] block: decouple REQ_OP_SECURE_ERASE from REQ_OP_DISCARD
commit: 44abff2c0b970ae3d310b97617525dc01f248d7c
[27/27] direct-io: remove random prefetches
commit: c22198e78d523c8fa079bbb70b2523bb6aa51849
Best regards,
--
Jens Axboe
[ovmf test] 169510: regressions - FAIL
flight 169510 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169510/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 479 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 55 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[PATCH v2 6/6] xen/arm: retrieve reserved pages on populate_physmap
When static domain populates memory through populate_physmap on runtime,
other than allocating from heap, it shall retrieve reserved pages from
resv_page_list to make sure that guest RAM is still restricted in statically
configured memory regions. And this commit introduces a new helper
acquire_reserved_page to make it work.
Signed-off-by: Penny Zheng
---
v2 changes:
- introduce acquire_reserved_page to retrieve reserved pages from
resv_page_list
- forbid non-zero-order requests in populate_physmap
- let is_domain_static return ((void)(d), false) on x86
---
xen/common/memory.c | 29 +
xen/common/page_alloc.c | 28
xen/include/xen/mm.h| 1 +
3 files changed, 58 insertions(+)
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 69b0cd1e50..f7729dfa5c 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -35,6 +35,10 @@
#include
#endif
+#ifndef is_domain_static
+#define is_domain_static(d) ((void)(d), false)
+#endif
+
struct memop_args {
/* INPUT */
struct domain *domain; /* Domain to be affected. */
@@ -245,6 +249,31 @@ static void populate_physmap(struct memop_args *a)
mfn = _mfn(gpfn);
}
+#ifdef CONFIG_STATIC_MEMORY
+else if ( is_domain_static(d) )
+{
+/*
+ * No easy way to guarantee the retreived pages are contiguous,
+ * so forbid non-zero-order requests here.
+ */
+if ( a->extent_order != 0 )
+{
+gdprintk(XENLOG_INFO,
+ "Could not allocate non-zero-order pages for
static %pd.\n.",
+ d);
+goto out;
+}
+
+mfn = acquire_reserved_page(d, a->memflags);
+if ( mfn_eq(mfn, INVALID_MFN) )
+{
+gdprintk(XENLOG_INFO,
+ "%pd: failed to retrieve a reserved page.\n.",
+ d);
+goto out;
+}
+}
+#endif
else
{
page = alloc_domheap_pages(d, a->extent_order, a->memflags);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 8ba38bca9a..759d612eb8 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2770,6 +2770,34 @@ int __init acquire_domstatic_pages(struct domain *d,
mfn_t smfn,
return 0;
}
+
+/*
+ * Acquire a page from reserved page list(resv_page_list), when populating
+ * memory for static domain on runtime.
+ */
+mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags)
+{
+struct page_info *page;
+mfn_t smfn;
+
+/* Acquire a page from reserved page list(resv_page_list). */
+page = page_list_remove_head(>resv_page_list);
+if ( unlikely(!page) )
+{
+printk(XENLOG_ERR
+ "%pd: failed to acquire a reserved page %"PRI_mfn".\n",
+ d, mfn_x(page_to_mfn(page)));
+return INVALID_MFN;
+}
+d->resv_pages--;
+
+smfn = page_to_mfn(page);
+
+if ( acquire_domstatic_pages(d, smfn, 1, memflags) )
+return INVALID_MFN;
+
+return smfn;
+}
#endif
/*
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 3be754da92..6ef5a6adcd 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -91,6 +91,7 @@ void free_staticmem_pages(struct page_info *pg, unsigned long
nr_mfns,
bool need_scrub);
int acquire_domstatic_pages(struct domain *d, mfn_t smfn, unsigned int nr_mfns,
unsigned int memflags);
+mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags);
#endif
/* Map machine page range in Xen virtual address space. */
--
2.25.1
[PATCH v2 4/6] xen/arm: introduce CDF_staticmem
In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_static to tell.
Signed-off-by: Penny Zheng
---
v2 changes:
- change name from "is_domain_on_static_allocation" to "is_domain_static()"
---
xen/arch/arm/domain_build.c | 5 -
xen/arch/arm/include/asm/domain.h | 2 ++
xen/include/xen/domain.h | 2 ++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8be01678de..4e62fd0bf1 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3191,9 +3191,12 @@ void __init create_domUs(void)
if ( !dt_device_is_compatible(node, "xen,domain") )
continue;
+if ( dt_find_property(node, "xen,static-mem", NULL) )
+flags |= CDF_staticmem;
+
if ( dt_property_read_bool(node, "direct-map") )
{
-if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) || !dt_find_property(node,
"xen,static-mem", NULL) )
+if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) || !(flags & CDF_staticmem)
)
panic("direct-map is not valid for domain %s without static
allocation.\n",
dt_node_name(node));
diff --git a/xen/arch/arm/include/asm/domain.h
b/xen/arch/arm/include/asm/domain.h
index 36ec00e62d..b097433f9f 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -31,6 +31,8 @@ enum domain_type {
#define is_domain_direct_mapped(d) ((d)->flags & CDF_directmap)
+#define is_domain_static(d) ((d)->flags & CDF_staticmem)
+
/*
* Is the domain using the host memory layout?
*
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 1c3c88a14d..35dc7143a4 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -34,6 +34,8 @@ void arch_get_domain_info(const struct domain *d,
#ifdef CONFIG_ARM
/* Should domain memory be directly mapped? */
#define CDF_directmap(1U << 1)
+/* Is domain memory on static allocation? */
+#define CDF_staticmem(1U << 2)
#endif
/*
--
2.25.1
[PATCH v2 3/6] xen: add field "flags" to cover all internal CDF_XXX
With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" in struct domain to store CDF_*
internal flags directly.
Another new CDF_xxx will be introduced in the next patch.
Signed-off-by: Penny Zheng
---
v2 changes:
- let "flags" live in the struct domain. So other arch can take
advantage of it in the future
- fix coding style
---
xen/arch/arm/domain.c | 2 --
xen/arch/arm/include/asm/domain.h | 3 +--
xen/common/domain.c | 3 +++
xen/include/xen/sched.h | 3 +++
4 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8110c1df86..74189d9878 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -709,8 +709,6 @@ int arch_domain_create(struct domain *d,
ioreq_domain_init(d);
#endif
-d->arch.directmap = flags & CDF_directmap;
-
/* p2m_init relies on some value initialized by the IOMMU subsystem */
if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
goto fail;
diff --git a/xen/arch/arm/include/asm/domain.h
b/xen/arch/arm/include/asm/domain.h
index ed63c2b6f9..36ec00e62d 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -29,7 +29,7 @@ enum domain_type {
#define is_64bit_domain(d) (0)
#endif
-#define is_domain_direct_mapped(d) (d)->arch.directmap
+#define is_domain_direct_mapped(d) ((d)->flags & CDF_directmap)
/*
* Is the domain using the host memory layout?
@@ -103,7 +103,6 @@ struct arch_domain
void *tee;
#endif
-bool directmap;
} __cacheline_aligned;
struct arch_vcpu
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 351029f8b2..859cc13d3b 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -568,6 +568,9 @@ struct domain *domain_create(domid_t domid,
/* Sort out our idea of is_system_domain(). */
d->domain_id = domid;
+/* Holding CDF_* internal flags. */
+d->flags = flags;
+
/* Debug sanity. */
ASSERT(is_system_domain(d) ? config == NULL : config != NULL);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index ed8539f6d2..68eb08058e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -591,6 +591,9 @@ struct domain
struct ioreq_server *server[MAX_NR_IOREQ_SERVERS];
} ioreq_server;
#endif
+
+/* Holding CDF_* constant. Internal flags for domain creation. */
+uint32_t flags;
};
static inline struct page_list_head *page_to_list(
--
2.25.1
[PATCH v2 5/6] xen/arm: unpopulate memory when domain is static
Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.
Pages as guest RAM for static domain shall be reserved to only this domain
and not be used for any other purposes, so they shall never go back to heap
allocator.
This commit puts reserved pages on the new list resv_page_list only after
having taken them off the "normal" list, when the last ref dropped.
Signed-off-by: Penny Zheng
---
v2 changes:
- put reserved pages on resv_page_list after having taken them off
the "normal" list
---
xen/arch/arm/include/asm/mm.h | 17 +
xen/common/domain.c | 4
xen/include/xen/sched.h | 6 ++
3 files changed, 27 insertions(+)
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 424aaf2823..a2dde01cfa 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -358,6 +358,23 @@ void clear_and_clean_page(struct page_info *page);
unsigned int arch_get_dma_bitsize(void);
+/*
+ * Put free pages on the resv page list after having taken them
+ * off the "normal" page list, when pages from static memory
+ */
+#ifdef CONFIG_STATIC_MEMORY
+#define arch_free_heap_page(d, pg) {\
+if ( (pg)->count_info & PGC_reserved ) \
+{ \
+page_list_del(pg, page_to_list(d, pg)); \
+page_list_add_tail(pg, &(d)->resv_page_list); \
+(d)->resv_pages++; \
+} \
+else\
+page_list_del(pg, page_to_list(d, pg)); \
+}
+#endif
+
#endif /* __ARCH_ARM_MM__ */
/*
* Local variables:
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 859cc13d3b..b499cf8d2c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -605,6 +605,10 @@ struct domain *domain_create(domid_t domid,
INIT_PAGE_LIST_HEAD(>page_list);
INIT_PAGE_LIST_HEAD(>extra_page_list);
INIT_PAGE_LIST_HEAD(>xenpage_list);
+#ifdef CONFIG_STATIC_MEMORY
+INIT_PAGE_LIST_HEAD(>resv_page_list);
+#endif
+
spin_lock_init(>node_affinity_lock);
d->node_affinity = NODE_MASK_ALL;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 68eb08058e..85ef378752 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -376,6 +376,9 @@ struct domain
struct page_list_head page_list; /* linked list */
struct page_list_head extra_page_list; /* linked list (size extra_pages) */
struct page_list_head xenpage_list; /* linked list (size xenheap_pages) */
+#ifdef CONFIG_STATIC_MEMORY
+struct page_list_head resv_page_list; /* linked list (size resv_pages) */
+#endif
/*
* This field should only be directly accessed by domain_adjust_tot_pages()
@@ -395,6 +398,9 @@ struct domain
#ifdef CONFIG_MEM_PAGING
atomic_t paged_pages; /* paged-out pages */
#endif
+#ifdef CONFIG_STATIC_MEMORY
+unsigned int resv_pages;/* reserved pages from static region.
*/
+#endif
/* Scheduling. */
void*sched_priv;/* scheduler-specific data */
--
2.25.1
[PATCH v2 2/6] xen/arm: do not merge reserved pages in free_heap_pages()
There is a slim chance that free_heap_pages() may decide to merge a chunk from the static region(PGC_reserved) with the about-to-be-free chunk. So in order to avoid the above scenario, this commit updates free_heap_pages() to check whether the predecessor and/or successor has PGC_reserved set, when trying to merge the about-to-be-freed chunk with the predecessor and/or successor. Signed-off-by: Penny Zheng --- v2 changes: - new commit --- xen/common/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 9a3e9c1328..8ba38bca9a 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1479,6 +1479,7 @@ static void free_heap_pages( /* Merge with predecessor block? */ if ( !mfn_valid(page_to_mfn(predecessor)) || !page_state_is(predecessor, free) || + (predecessor->count_info & PGC_reserved) || (PFN_ORDER(predecessor) != order) || (phys_to_nid(page_to_maddr(predecessor)) != node) ) break; @@ -1502,6 +1503,7 @@ static void free_heap_pages( /* Merge with successor block? */ if ( !mfn_valid(page_to_mfn(successor)) || !page_state_is(successor, free) || + (successor->count_info & PGC_reserved) || (PFN_ORDER(successor) != order) || (phys_to_nid(page_to_maddr(successor)) != node) ) break; -- 2.25.1
[PATCH V2 0/6] populate/unpopulate memory when domain on static
Today when a domain unpopulates the memory on runtime, they will always hand the memory over to the heap allocator. And it will be a problem if it is a static domain. Pages as guest RAM for static domain shall always be reserved to only this domain and not be used for any other purposes, so they shall never go back to heap allocator. This patch serie intends to fix this issue, by adding pages on the new list resv_page_list after having taken them off the "normal" list, when unpopulating memory, and retrieving pages from resv page list(resv_page_list) when populating memory. --- v2 changes: - let "flags" live in the struct domain. So other arch can take advantage of it in the future - change name from "is_domain_on_static_allocation" to "is_domain_static()" - put reserved pages on resv_page_list after having taken them off the "normal" list - introduce acquire_reserved_page to retrieve reserved pages from resv_page_list - forbid non-zero-order requests in populate_physmap - let is_domain_static return ((void)(d), false) on x86 - fix coding style Penny Zheng (6): xen/arm: do not free reserved memory into heap xen/arm: do not merge reserved pages in free_heap_pages() xen: add field "flags" to cover all internal CDF_XXX xen/arm: introduce CDF_staticmem xen/arm: unpopulate memory when domain is static xen/arm: retrieve reserved pages on populate_physmap xen/arch/arm/domain.c | 2 -- xen/arch/arm/domain_build.c | 5 +++- xen/arch/arm/include/asm/domain.h | 5 ++-- xen/arch/arm/include/asm/mm.h | 17 + xen/common/domain.c | 7 ++ xen/common/memory.c | 29 ++ xen/common/page_alloc.c | 40 +-- xen/include/xen/domain.h | 2 ++ xen/include/xen/mm.h | 1 + xen/include/xen/sched.h | 9 +++ 10 files changed, 110 insertions(+), 7 deletions(-) -- 2.25.1
[PATCH v2 1/6] xen/arm: do not free reserved memory into heap
Pages as guest RAM for static domain, shall be reserved to this domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
free_staticmem_pages will be called by free_domheap_pages in runtime
for static domain freeing memory resource, so let's drop the __init
flag.
Signed-off-by: Penny Zheng
---
v2 changes:
- new commit
---
xen/common/page_alloc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 319029140f..9a3e9c1328 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2488,7 +2488,13 @@ void free_domheap_pages(struct page_info *pg, unsigned
int order)
scrub = 1;
}
-free_heap_pages(pg, order, scrub);
+#ifdef CONFIG_STATIC_MEMORY
+if ( pg->count_info & PGC_reserved )
+/* Reserved page shall not go back to the heap. */
+free_staticmem_pages(pg, 1 << order, scrub);
+else
+#endif
+free_heap_pages(pg, order, scrub);
}
if ( drop_dom_ref )
@@ -2636,7 +2642,7 @@ struct domain *get_pg_owner(domid_t domid)
#ifdef CONFIG_STATIC_MEMORY
/* Equivalent of free_heap_pages to free nr_mfns pages of static memory. */
-void __init free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
+void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
bool need_scrub)
{
mfn_t mfn = page_to_mfn(pg);
--
2.25.1
[ovmf test] 169509: regressions - FAIL
flight 169509 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169509/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 49 days Failing since168258 2022-03-01 01:55:31 Z 48 days 478 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 54 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[linux-linus test] 169495: tolerable FAIL - PUSHED
flight 169495 linux-linus real [real] flight 169507 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/169495/ http://logs.test-lab.xenproject.org/osstest/logs/169507/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-xsm 8 xen-bootfail pass in 169507-retest test-armhf-armhf-libvirt-raw 12 debian-di-install fail pass in 169507-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail in 169507 like 169488 test-arm64-arm64-xl-xsm 15 migrate-support-check fail in 169507 never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail in 169507 never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail in 169507 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169488 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169488 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169488 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169488 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169488 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169488 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169488 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-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-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: linuxb2d229d4ddb17db541098b83524d901257e93845 baseline version: linux3a69a44278a72e15f12e24f5db4d277a497649aa Last test of basis 169488 2022-04-17 17:09:36 Z0 days Testing same since 169495 2022-04-17 23:10:37 Z0 days1 attempts People who touched revisions under test: Boris Ostrovsky Juergen Gross Linus Torvalds jobs:
[PATCH] xen: gntalloc.c: Convert kmap() to kmap_local_page()
The use of kmap() is being deprecated in favor of kmap_local_page()
where it is feasible.
With kmap_local_page(), the mapping is per thread, CPU local and not
globally visible. Therefore __del_gref() is a function
where the use of kmap_local_page() in place of kmap() is correctly
suited.
Signed-off-by: Alaa Mohamed
---
drivers/xen/gntalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 4849f94372a4..55acb32842a3 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -178,9 +178,9 @@ static void __del_gref(struct gntalloc_gref *gref)
unsigned long addr;
if (gref->notify.flags & UNMAP_NOTIFY_CLEAR_BYTE) {
- uint8_t *tmp = kmap(gref->page);
+ uint8_t *tmp = kmap_local_page(gref->page);
tmp[gref->notify.pgoff] = 0;
- kunmap(gref->page);
+ kunmap_local(tmp);
}
if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT) {
notify_remote_via_evtchn(gref->notify.event);
--
2.35.2
[ovmf test] 169508: regressions - FAIL
flight 169508 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169508/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 48 days 477 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 53 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[xen-unstable test] 169499: tolerable FAIL
flight 169499 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/169499/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169472 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169472 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169472 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 169472 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 169472 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169472 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169472 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169472 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169472 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169472 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169472 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169472 test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 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-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-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 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-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-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 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 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-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: xen e509b5f932608e74deac96048b28a5e9b210c647 baseline version: xen
[ovmf test] 169506: regressions - FAIL
flight 169506 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169506/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 48 days 476 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 52 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[PATCH v2 10/10] xen/x86: add detection of memory interleaves for different nodes
One NUMA node may contain several memory blocks. In current Xen
code, Xen will maintain a node memory range for each node to cover
all its memory blocks. But here comes the problem, in the gap of
one node's two memory blocks, if there are some memory blocks don't
belong to this node (remote memory blocks). This node's memory range
will be expanded to cover these remote memory blocks.
One node's memory range contains other nodes' memory, this is
obviously not very reasonable. This means current NUMA code only
can support node has no interleaved memory blocks. However, on a
physical machine, the addresses of multiple nodes can be interleaved.
So in this patch, we add code to detect memory interleaves of
different nodes. NUMA initialization will be failed and error
messages will be printed when Xen detect such hardware configuration.
Signed-off-by: Wei Chen
---
v1 ->v2:
1. Update the description to say we're after is no memory
interleaves of different nodes.
2. Only update node range when it passes the interleave check.
3. Don't use full upper-case for "node".
---
xen/arch/x86/srat.c | 49 +
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index c3e13059e9..53968e4085 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -271,6 +271,35 @@ acpi_numa_processor_affinity_init(const struct
acpi_srat_cpu_affinity *pa)
pxm, pa->apic_id, node);
}
+/*
+ * Check to see if there are other nodes within this node's range.
+ * We just need to check full contains situation. Because overlaps
+ * have been checked before by conflicting_memblks.
+ */
+static bool __init check_node_memory_interleave(nodeid_t nid,
+paddr_t start, paddr_t end)
+{
+ nodeid_t i;
+ const struct node *nd = [nid];
+
+ for_each_node_mask(i, memory_nodes_parsed)
+ {
+ /* Skip itself */
+ if (i == nid)
+ continue;
+
+ nd = [i];
+ if (start < nd->start && nd->end < end) {
+ printk(KERN_ERR
+ "Node %u: (%"PRIpaddr"-%"PRIpaddr") interleaves
with node %u (%"PRIpaddr"-%"PRIpaddr")\n",
+ nid, start, end, i, nd->start, nd->end);
+ return true;
+ }
+ }
+
+ return false;
+}
+
/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
void __init
acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma)
@@ -340,10 +369,22 @@ acpi_numa_memory_affinity_init(const struct
acpi_srat_mem_affinity *ma)
nd->start = start;
nd->end = end;
} else {
- if (start < nd->start)
- nd->start = start;
- if (nd->end < end)
- nd->end = end;
+ paddr_t new_start = nd->start;
+ paddr_t new_end = nd->end;
+
+ if (start < new_start)
+ new_start = start;
+ if (new_end < end)
+ new_end = end;
+
+ /* Check whether new range contains memory for other
nodes */
+ if (check_node_memory_interleave(node, new_start,
new_end)) {
+ bad_srat();
+ return;
+ }
+
+ nd->start = new_start;
+ nd->end = new_end;
}
}
printk(KERN_INFO "SRAT: Node %u PXM %u %"PRIpaddr"-%"PRIpaddr"%s\n",
--
2.25.1
[PATCH v2 05/10] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" undeclared (first use in this function).
This is because in the common header file, "MAX_NUMNODES" is
defined after the common header file includes the ARCH header
file, where phys_to_nid has attempted to use "MAX_NUMNODES".
This error was resolved when we moved the definition of
"MAX_NUMNODES" to x86 ARCH header file. And we reserve the
"MAX_NUMNODES" definition in common header file through a
conditional compilation for some architectures that don't
need to define "MAX_NUMNODES" in their ARCH header files.
2. error: wrong type argument to unary exclamation mark.
This is because, the error-checking code contains !node_data[nid].
But node_data is a data structure variable, it's not a pointer.
So, in this patch, we use ASSERT instead of VIRTUAL_BUG_ON to
enable the two lines of error-checking code. And fix the left
compilation errors by replacing !node_data[nid] to
!node_data[nid].node_spanned_pages.
Because when node_spanned_pages is 0, this node has no memory,
numa_scan_node will print warning message for such kind of nodes:
"Firmware Bug or mis-configured hardware?".
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Use ASSERT to replace VIRTUAL_BUG_ON in phys_to_nid.
2. Adjust the conditional express for ASSERT.
3. Move MAX_NUMNODES from xen/numa.h to asm/numa.h for x86.
4. Use conditional macro to gate MAX_NUMNODES for other architectures.
---
xen/arch/x86/include/asm/numa.h | 6 +++---
xen/include/xen/numa.h | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/include/asm/numa.h b/xen/arch/x86/include/asm/numa.h
index bada2c0bb9..1f268ce77d 100644
--- a/xen/arch/x86/include/asm/numa.h
+++ b/xen/arch/x86/include/asm/numa.h
@@ -4,6 +4,7 @@
#include
#define NODES_SHIFT 6
+#define MAX_NUMNODES(1 << NODES_SHIFT)
typedef u8 nodeid_t;
@@ -26,7 +27,6 @@ extern int compute_hash_shift(struct node *nodes, int
numnodes,
extern nodeid_t pxm_to_node(unsigned int pxm);
#define ZONE_ALIGN (1UL << (MAX_ORDER+PAGE_SHIFT))
-#define VIRTUAL_BUG_ON(x)
extern void numa_add_cpu(int cpu);
extern void numa_init_array(void);
@@ -62,9 +62,9 @@ extern struct node_data node_data[];
static inline __attribute__((pure)) nodeid_t phys_to_nid(paddr_t addr)
{
nodeid_t nid;
- VIRTUAL_BUG_ON((paddr_to_pdx(addr) >> memnode_shift) >= memnodemapsize);
+ ASSERT((paddr_to_pdx(addr) >> memnode_shift) < memnodemapsize);
nid = memnodemap[paddr_to_pdx(addr) >> memnode_shift];
- VIRTUAL_BUG_ON(nid >= MAX_NUMNODES || !node_data[nid]);
+ ASSERT(nid < MAX_NUMNODES && node_data[nid].node_spanned_pages);
return nid;
}
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index 7aef1a88dc..91b25c5617 100644
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -10,7 +10,9 @@
#define NUMA_NO_NODE 0xFF
#define NUMA_NO_DISTANCE 0xFF
+#ifndef MAX_NUMNODES
#define MAX_NUMNODES(1 << NODES_SHIFT)
+#endif
#define vcpu_to_node(v) (cpu_to_node((v)->processor))
--
2.25.1
[PATCH v2 08/10] xen/arm: use !CONFIG_NUMA to keep fake NUMA API
We have introduced CONFIG_NUMA in a previous patch. And this option is enabled only on x86 at the current stage. In a follow up patch, we will enable this option for Arm. But we still want users to be able to disable the CONFIG_NUMA via Kconfig. In this case, keep the fake NUMA API, will make Arm code still able to work with NUMA aware memory allocation and scheduler. Signed-off-by: Wei Chen Reviewed-by: Stefano Stabellini --- xen/arch/arm/include/asm/numa.h | 5 + 1 file changed, 5 insertions(+) diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h index 268ba93a92..59cdf8e39e 100644 --- a/xen/arch/arm/include/asm/numa.h +++ b/xen/arch/arm/include/asm/numa.h @@ -5,6 +5,8 @@ typedef u8 nodeid_t; +#ifndef CONFIG_NUMA + /* Fake one node for now. See also node_online_map. */ #define cpu_to_node(cpu) 0 #define node_to_cpumask(node) (cpu_online_map) @@ -24,6 +26,9 @@ extern mfn_t first_valid_mfn; #define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn)) #define node_start_pfn(nid) (mfn_x(first_valid_mfn)) #define __node_distance(a, b) (20) + +#endif + #define arch_have_default_dmazone() (false) #endif /* __ARCH_ARM_NUMA_H */ -- 2.25.1
[PATCH v2 07/10] xen: decouple NUMA from ACPI in Kconfig
In current Xen code only implements x86 ACPI-based NUMA support. So in Xen Kconfig system, NUMA equals to ACPI_NUMA. x86 selects NUMA by default, and CONFIG_ACPI_NUMA is hardcode in config.h. In a follow-up patch, we will introduce support for NUMA using the device tree. That means we will have two NUMA implementations, so in this patch we decouple NUMA from ACPI based NUMA in Kconfig. Make NUMA as a common feature, that device tree based NUMA also can select it. Signed-off-by: Wei Chen Reviewed-by: Jan Beulich --- xen/arch/x86/Kconfig | 2 +- xen/arch/x86/include/asm/config.h | 1 - xen/common/Kconfig| 3 +++ xen/drivers/acpi/Kconfig | 3 ++- xen/drivers/acpi/Makefile | 2 +- 5 files changed, 7 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 06d6fbc864..1e31edc99f 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -6,6 +6,7 @@ config X86 def_bool y select ACPI select ACPI_LEGACY_TABLES_LOOKUP + select ACPI_NUMA select ALTERNATIVE_CALL select ARCH_SUPPORTS_INT128 select CORE_PARKING @@ -26,7 +27,6 @@ config X86 select HAS_UBSAN select HAS_VPCI if HVM select NEEDS_LIBELF - select NUMA config ARCH_DEFCONFIG string diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm/config.h index de20642524..07bcd15831 100644 --- a/xen/arch/x86/include/asm/config.h +++ b/xen/arch/x86/include/asm/config.h @@ -31,7 +31,6 @@ /* Intel P4 currently has largest cache line (L2 line size is 128 bytes). */ #define CONFIG_X86_L1_CACHE_SHIFT 7 -#define CONFIG_ACPI_NUMA 1 #define CONFIG_ACPI_SRAT 1 #define CONFIG_ACPI_CSTATE 1 diff --git a/xen/common/Kconfig b/xen/common/Kconfig index d921c74d61..d65add3fc6 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -70,6 +70,9 @@ config MEM_ACCESS config NEEDS_LIBELF bool +config NUMA + bool + config STATIC_MEMORY bool "Static Allocation Support (UNSUPPORTED)" if UNSUPPORTED depends on ARM diff --git a/xen/drivers/acpi/Kconfig b/xen/drivers/acpi/Kconfig index b64d3731fb..e3f3d8f4b1 100644 --- a/xen/drivers/acpi/Kconfig +++ b/xen/drivers/acpi/Kconfig @@ -5,5 +5,6 @@ config ACPI config ACPI_LEGACY_TABLES_LOOKUP bool -config NUMA +config ACPI_NUMA bool + select NUMA diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile index 4f8e97228e..2fc5230253 100644 --- a/xen/drivers/acpi/Makefile +++ b/xen/drivers/acpi/Makefile @@ -3,7 +3,7 @@ obj-y += utilities/ obj-$(CONFIG_X86) += apei/ obj-bin-y += tables.init.o -obj-$(CONFIG_NUMA) += numa.o +obj-$(CONFIG_ACPI_NUMA) += numa.o obj-y += osl.o obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o -- 2.25.1
[PATCH v2 04/10] xen/arm: Keep memory nodes in device tree when Xen boots from EFI
In current code, when Xen is booting from EFI, it will delete
all memory nodes in device tree. This would work well in current
stage, because Xen can get memory map from EFI system table.
However, EFI system table cannot completely replace memory nodes
of device tree. EFI system table doesn't contain memory NUMA
information. Xen depends on ACPI SRAT or device tree memory nodes
to parse memory blocks' NUMA mapping. So in EFI + DTB boot, Xen
doesn't have any method to get numa-node-id for memory blocks any
more. This makes device tree based NUMA support become impossible
for Xen in EFI + DTB boot.
So in this patch, we will keep memory nodes in device tree for
NUMA code to parse memory numa-node-id later.
As a side effect, if we still parse boot memory information in
early_scan_node, bootmem.info will calculate memory ranges in
memory nodes twice. So we have to prevent early_scan_node to
parse memory nodes in EFI boot.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Move this patch from later to early of this series.
2. Refine commit message.
---
xen/arch/arm/bootfdt.c | 8 +++-
xen/arch/arm/efi/efi-boot.h | 25 -
2 files changed, 7 insertions(+), 26 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index e318ef9603..78e10c6ebc 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -370,7 +371,12 @@ static int __init early_scan_node(const void *fdt,
{
int rc = 0;
-if ( device_tree_node_matches(fdt, node, "memory") )
+/*
+ * If Xen has been booted via UEFI, the memory banks are
+ * populated. So we should skip the parsing.
+ */
+if ( !efi_enabled(EFI_BOOT) &&
+ device_tree_node_matches(fdt, node, "memory") )
rc = process_memory_node(fdt, node, name, depth,
address_cells, size_cells, );
else if ( depth == 1 && !dt_node_cmp(name, "reserved-memory") )
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index e452b687d8..59d93c24a1 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -231,33 +231,8 @@ EFI_STATUS __init fdt_add_uefi_nodes(EFI_SYSTEM_TABLE
*sys_table,
int status;
u32 fdt_val32;
u64 fdt_val64;
-int prev;
int num_rsv;
-/*
- * Delete any memory nodes present. The EFI memory map is the only
- * memory description provided to Xen.
- */
-prev = 0;
-for (;;)
-{
-const char *type;
-int len;
-
-node = fdt_next_node(fdt, prev, NULL);
-if ( node < 0 )
-break;
-
-type = fdt_getprop(fdt, node, "device_type", );
-if ( type && strncmp(type, "memory", len) == 0 )
-{
-fdt_del_node(fdt, node);
-continue;
-}
-
-prev = node;
-}
-
/*
* Delete all memory reserve map entries. When booting via UEFI,
* kernel will use the UEFI memory map to find reserved regions.
--
2.25.1
[PATCH v2 06/10] xen: introduce an arch helper for default dma zone status
In current code, when Xen is running in a multiple nodes
NUMA system, it will set dma_bitsize in end_boot_allocator
to reserve some low address memory as DMA zone.
There are some x86 implications in the implementation.
Because on x86, memory starts from 0. On a multiple-nodes
NUMA system, if a single node contains the majority or all
of the DMA memory, x86 prefers to give out memory from
non-local allocations rather than exhausting the DMA memory
ranges. Hence x86 uses dma_bitsize to set aside some largely
arbitrary amount of memory for DMA zone. The allocations
from DMA zone would happen only after exhausting all other
nodes' memory.
But the implications are not shared across all architectures.
For example, Arm cannot guarantee the availability of memory
below a certain boundary for DMA limited-capability devices
either. But currently, Arm doesn't need a reserved DMA zone
in Xen. Because there is no DMA device in Xen. And for guests,
Xen Arm only allows Dom0 to have DMA operations without IOMMU.
Xen will try to allocate memory under 4GB or memory range that
is limited by dma_bitsize for Dom0 in boot time. For DomU, even
Xen can passthrough devices to DomU without IOMMU, but Xen Arm
doesn't guarantee their DMA operations. So, Xen Arm doesn't
need a reserved DMA zone to provide DMA memory for guests.
In this patch, we introduce an arch_have_default_dmazone helper
for different architectures to determine whether they need to
set dma_bitsize for DMA zone reservation or not.
At the same time, when x86 Xen is built with CONFIG_PV=n could
probably leverage this new helper to actually not trigger DMA
zone reservation.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Extend the description of Arm's workaround for reserve DMA
allocations to avoid the same discussion every time.
2. Use a macro to define arch_have_default_dmazone, because
it's little hard to make x86 version to static inline.
Use a macro will also avoid add __init for this function.
3. Change arch_have_default_dmazone return value from
unsigned int to bool.
4. Un-addressed comment: make arch_have_default_dmazone
of x86 to be static inline. Because, if we move
arch_have_default_dmazone to x86/asm/numa.h, it depends
on nodemask.h to provide num_online_nodes. But nodemask.h
needs numa.h to provide MAX_NUMANODES. This will cause a
loop dependency. And this function can only be used in
end_boot_allocator, in Xen initialization. So I think,
compared to the changes introduced by inline, it doesn't
mean much.
---
xen/arch/arm/include/asm/numa.h | 1 +
xen/arch/x86/include/asm/numa.h | 1 +
xen/common/page_alloc.c | 2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/include/asm/numa.h b/xen/arch/arm/include/asm/numa.h
index 31a6de4e23..268ba93a92 100644
--- a/xen/arch/arm/include/asm/numa.h
+++ b/xen/arch/arm/include/asm/numa.h
@@ -24,6 +24,7 @@ extern mfn_t first_valid_mfn;
#define node_spanned_pages(nid) (max_page - mfn_x(first_valid_mfn))
#define node_start_pfn(nid) (mfn_x(first_valid_mfn))
#define __node_distance(a, b) (20)
+#define arch_have_default_dmazone() (false)
#endif /* __ARCH_ARM_NUMA_H */
/*
diff --git a/xen/arch/x86/include/asm/numa.h b/xen/arch/x86/include/asm/numa.h
index 1f268ce77d..6eeae02060 100644
--- a/xen/arch/x86/include/asm/numa.h
+++ b/xen/arch/x86/include/asm/numa.h
@@ -74,6 +74,7 @@ static inline __attribute__((pure)) nodeid_t
phys_to_nid(paddr_t addr)
#define node_spanned_pages(nid)(NODE_DATA(nid)->node_spanned_pages)
#define node_end_pfn(nid) (NODE_DATA(nid)->node_start_pfn + \
NODE_DATA(nid)->node_spanned_pages)
+#define arch_have_default_dmazone() (num_online_nodes() > 1)
extern int valid_numa_range(u64 start, u64 end, nodeid_t node);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 319029140f..4c0dc3cb3c 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1889,7 +1889,7 @@ void __init end_boot_allocator(void)
}
nr_bootmem_regions = 0;
-if ( !dma_bitsize && (num_online_nodes() > 1) )
+if ( !dma_bitsize && arch_have_default_dmazone() )
dma_bitsize = arch_get_dma_bitsize();
printk("Domain heap initialised");
--
2.25.1
[PATCH v2 03/10] xen/arm: add CONFIG_ARM_EFI to stub EFI API
x86 is using compiler feature testing to decide EFI build enable or not. When EFI build is disabled, x86 will use a efi/stub.c file to replace efi/runtime.c for build objects. Following this idea, we introduce a stub file for Arm, but use CONFIG_ARM_EFI to decide EFI build enable or not. Signed-off-by: Wei Chen --- v1 -> v2: 1. Use CONFIG_ARM_EFI to replace CONFIG_EFI 2. Remove help text and make CONFIG_ARM_EFI invisible. 3. Merge one following patch: xen/arm: introduce a stub file for non-EFI architectures 4. Use the common stub.c instead of creating new one. --- xen/arch/arm/Kconfig | 5 + xen/arch/arm/Makefile | 2 +- xen/arch/arm/efi/Makefile | 5 + 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index ecfa6822e4..5f1b0121b0 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -6,6 +6,7 @@ config ARM_64 def_bool y depends on !ARM_32 select 64BIT + select ARM_EFI select HAS_FAST_MULTIPLY config ARM @@ -33,6 +34,10 @@ config ACPI Advanced Configuration and Power Interface (ACPI) support for Xen is an alternative to device tree on ARM64. +config ARM_EFI + bool + depends on ARM_64 + config GICV3 bool "GICv3 driver" depends on ARM_64 && !NEW_VGIC diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index 1d862351d1..bb7a6151c1 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -1,6 +1,5 @@ obj-$(CONFIG_ARM_32) += arm32/ obj-$(CONFIG_ARM_64) += arm64/ -obj-$(CONFIG_ARM_64) += efi/ obj-$(CONFIG_ACPI) += acpi/ obj-$(CONFIG_HAS_PCI) += pci/ ifneq ($(CONFIG_NO_PLAT),y) @@ -20,6 +19,7 @@ obj-y += domain.o obj-y += domain_build.init.o obj-y += domctl.o obj-$(CONFIG_EARLY_PRINTK) += early_printk.o +obj-y += efi/ obj-y += gic.o obj-y += gic-v2.o obj-$(CONFIG_GICV3) += gic-v3.o diff --git a/xen/arch/arm/efi/Makefile b/xen/arch/arm/efi/Makefile index 4313c39066..75ef180233 100644 --- a/xen/arch/arm/efi/Makefile +++ b/xen/arch/arm/efi/Makefile @@ -1,4 +1,9 @@ include $(srctree)/common/efi/efi-common.mk +ifeq ($(CONFIG_ARM_EFI),y) obj-y += $(EFIOBJ-y) obj-$(CONFIG_ACPI) += efi-dom0.init.o +else +EFIOBJ-y += stub.o +obj-y += stub.o +endif -- 2.25.1
[PATCH v2 01/10] xen/arm: Print a 64-bit number in hex from early uart
Current putn function that is using for early print only can print low 32-bit of AArch64 register. This will lose some important messages while debugging with early console. For example: (XEN) Bringing up CPU5 - CPU 00010100 booting - Will be truncated to (XEN) Bringing up CPU5 - CPU 0100 booting - In this patch, we increased the print loops and shift bits to make putn print 64-bit number. Signed-off-by: Wei Chen Acked-by: Julien Grall --- xen/arch/arm/arm64/head.S | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S index e62c48ec1c..2bb7906f69 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -866,17 +866,19 @@ puts: ret ENDPROC(puts) -/* Print a 32-bit number in hex. Specific to the PL011 UART. +/* + * Print a 64-bit number in hex. * x0: Number to print. * x23: Early UART base address - * Clobbers x0-x3 */ + * Clobbers x0-x3 + */ putn: adr x1, hex -mov x3, #8 +mov x3, #16 1: early_uart_ready x23, 2 -and x2, x0, #0xf000/* Mask off the top nybble */ -lsr x2, x2, #28 +and x2, x0, #(0xf<<60) /* Mask off the top nybble */ +lsr x2, x2, #60 ldrb w2, [x1, x2] /* Convert to a char */ early_uart_transmit x23, w2 lsl x0, x0, #4 /* Roll it through one nybble at a time */ -- 2.25.1
[PATCH v2 02/10] xen/x86: move reusable EFI stub functions from x86 to common
Most of the functions in x86 EFI stub.c can be reused for other
architectures. So we move them to common and keep the x86 specific
function in stub-x86.c.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Drop the copy of stub.c from Arm EFI.
2. Share common codes of x86 EFI stub for other architectures.
---
xen/arch/x86/efi/Makefile | 4 +--
xen/arch/x86/efi/{stub.c => stub-x86.c} | 37
xen/common/efi/stub.c | 38 +
3 files changed, 40 insertions(+), 39 deletions(-)
rename xen/arch/x86/efi/{stub.c => stub-x86.c} (71%)
create mode 100644 xen/common/efi/stub.c
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 034ec87895..5ca3a0b4a4 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -11,8 +11,8 @@ $(obj)/boot.init.o: $(obj)/buildid.o
$(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4)
$(addprefix $(obj)/,$(EFIOBJ-y)): CFLAGS_stack_boundary :=
$(cflags-stack-boundary)
-obj-y := stub.o
+obj-y := stub.o stub-x86.o
obj-$(XEN_BUILD_EFI) := $(filter-out %.init.o,$(EFIOBJ-y))
obj-bin-$(XEN_BUILD_EFI) := $(filter %.init.o,$(EFIOBJ-y))
extra-$(XEN_BUILD_EFI) += buildid.o relocs-dummy.o
-nocov-$(XEN_BUILD_EFI) += stub.o
+nocov-$(XEN_BUILD_EFI) += stub.o stub-x86.o
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c
similarity index 71%
rename from xen/arch/x86/efi/stub.c
rename to xen/arch/x86/efi/stub-x86.c
index 9984932626..2cd5c8d4dc 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub-x86.c
@@ -1,7 +1,5 @@
#include
-#include
#include
-#include
#include
#include
#include
@@ -45,11 +43,6 @@ void __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle,
unreachable();
}
-bool efi_enabled(unsigned int feature)
-{
-return false;
-}
-
void __init efi_init_memory(void) { }
bool efi_boot_mem_unused(unsigned long *start, unsigned long *end)
@@ -61,33 +54,3 @@ bool efi_boot_mem_unused(unsigned long *start, unsigned long
*end)
}
void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e) { }
-
-bool efi_rs_using_pgtables(void)
-{
-return false;
-}
-
-unsigned long efi_get_time(void)
-{
-BUG();
-return 0;
-}
-
-void efi_halt_system(void) { }
-void efi_reset_system(bool warm) { }
-
-int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
-{
-return -ENOSYS;
-}
-
-int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *)
-__attribute__((__alias__("efi_get_info")));
-
-int efi_runtime_call(struct xenpf_efi_runtime_call *op)
-{
-return -ENOSYS;
-}
-
-int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *)
-__attribute__((__alias__("efi_runtime_call")));
diff --git a/xen/common/efi/stub.c b/xen/common/efi/stub.c
new file mode 100644
index 00..6e4f4de9af
--- /dev/null
+++ b/xen/common/efi/stub.c
@@ -0,0 +1,38 @@
+#include
+#include
+#include
+
+bool efi_enabled(unsigned int feature)
+{
+return false;
+}
+
+bool efi_rs_using_pgtables(void)
+{
+return false;
+}
+
+unsigned long efi_get_time(void)
+{
+BUG();
+return 0;
+}
+
+void efi_halt_system(void) { }
+void efi_reset_system(bool warm) { }
+
+int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
+{
+return -ENOSYS;
+}
+
+int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *)
+__attribute__((__alias__("efi_get_info")));
+
+int efi_runtime_call(struct xenpf_efi_runtime_call *op)
+{
+return -ENOSYS;
+}
+
+int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *)
+__attribute__((__alias__("efi_runtime_call")));
--
2.25.1
[PATCH v2 00/10] Device tree based NUMA support for Arm - Part#1
(The Arm device tree based NUMA support patch set contains 35 patches. In order to make stuff easier for reviewers, I split them into 3 parts: 1. Preparation. I have re-sorted the patch series. And moved independent patches to the head of the series. 2. Move generically usable code from x86 to common. 3. Add new code to support Arm. This series only contains the first part patches. The full patch list can be found in this cover letter.) Xen memory allocation and scheduler modules are NUMA aware. But actually, on x86 has implemented the architecture APIs to support NUMA. Arm was providing a set of fake architecture APIs to make it compatible with NUMA awared memory allocation and scheduler. Arm system was working well as a single node NUMA system with these fake APIs, because we didn't have multiple nodes NUMA system on Arm. But in recent years, more and more Arm devices support multiple nodes NUMA system. So now we have a new problem. When Xen is running on these Arm devices, Xen still treat them as single node SMP systems. The NUMA affinity capability of Xen memory allocation and scheduler becomes meaningless. Because they rely on input data that does not reflect real NUMA layout. Xen still think the access time for all of the memory is the same for all CPUs. However, Xen may allocate memory to a VM from different NUMA nodes with different access speeds. This difference can be amplified in workloads inside VM, causing performance instability and timeouts. So in this patch series, we implement a set of NUMA API to use device tree to describe the NUMA layout. We reuse most of the code of x86 NUMA to create and maintain the mapping between memory and CPU, create the matrix between any two NUMA nodes. Except ACPI and some x86 specified code, we have moved other code to common. In next stage, when we implement ACPI based NUMA for Arm64, we may move the ACPI NUMA code to common too, but in current stage, we keep it as x86 only. This patch serires has been tested and booted well on one Arm64 NUMA machine and one HPE x86 NUMA machine. --- Part1 v1->v2: 1. Move independent patches from later to early of this series. 2. Drop the copy of EFI stub.c from Arm. Share common codes of x86 EFI stub for Arm. 3. Use CONFIG_ARM_EFI to replace CONFIG_EFI and remove help text and make CONFIG_ARM_EFI invisible. 4. Use ASSERT to replace VIRTUAL_BUG_ON in phys_to_nid. 5. Move MAX_NUMNODES from xen/numa.h to asm/numa.h for x86. 6. Extend the description of Arm's workaround for reserve DMA allocations to avoid the same discussion every time for arch_have_default_dmazone. 7. Update commit messages. Wei Chen (10): xen/arm: Print a 64-bit number in hex from early uart xen/x86: move reusable EFI stub functions from x86 to common xen/arm: add CONFIG_ARM_EFI to stub EFI API xen/arm: Keep memory nodes in device tree when Xen boots from EFI xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid xen: introduce an arch helper for default dma zone status xen: decouple NUMA from ACPI in Kconfig xen/arm: use !CONFIG_NUMA to keep fake NUMA API xen/x86: use paddr_t for addresses in NUMA node structure xen/x86: add detection of memory interleaves for different nodes PART2: xen/x86: introduce a helper to update memory hotplug end xen/x86: Use enumerations to indicate NUMA status xen/x86: move generically usable NUMA code from x86 to common xen/x86: use arch_get_memory_map to get information from E820 map xen/x86: move NUMA scan nodes codes from x86 to common xen/x86: rename bad_srat to numa_bad PART3: xen: rename acpi_scan_nodes to numa_scan_nodes xen: introduce a Kconfig option to configure NUMA nodes number xen/arm: use NR_MEM_BANKS to override default NR_NODE_MEMBLKS xen/arm: implement helpers to get and update NUMA status xen/arm: implement node distance helpers for Arm xen/arm: use arch_get_memory_map to memory bank from bootinfo xen/arm: build NUMA cpu_to_node map in dt_smp_init_cpus xen/arm: Add boot and secondary CPU to NUMA system xen/arm: stub mem_hotplug_update_boundary for Arm xen/arm: introduce a helper to parse device tree processor node xen/arm: introduce a helper to parse device tree memory node xen/arm: introduce a helper to parse device tree NUMA distance map xen/arm: unified entry to parse all NUMA data from device tree xen/arm: keep guest still be NUMA unware xen/arm: enable device tree based NUMA in system init xen/arm: implement a dummy 1:1 node to pxm mapping xen/arm: use CONFIG_NUMA to gate node_online_map in smpboot xen/arm: Provide Kconfig options for Arm to enable NUMA docs: update numa command line to support Arm xen/arch/arm/Kconfig| 5 ++ xen/arch/arm/Makefile | 2 +- xen/arch/arm/arm64/head.S | 12 ++-- xen/arch/arm/bootfdt.c | 8 ++- xen/arch/arm/efi/Makefile | 5 ++ xen/arch/arm/efi/efi-boot.h | 25 -
[ovmf test] 169505: regressions - FAIL
flight 169505 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169505/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 48 days 475 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 51 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
[ovmf test] 169504: regressions - FAIL
flight 169504 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169504/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 48 days 474 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 50 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [dm-devel] [PATCH 08/11] loop: remove a spurious clear of discard_alignment
On 4/18/22 13:53, Christoph Hellwig wrote:
> The loop driver never sets a discard_alignment, so it also doens't need
> to clear it to zero.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/loop.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 976cf987b3920..61b642b966a08 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -789,7 +789,6 @@ static void loop_config_discard(struct loop_device *lo)
> blk_queue_max_discard_sectors(q, 0);
> blk_queue_max_write_zeroes_sectors(q, 0);
> }
> - q->limits.discard_alignment = 0;
> }
>
> struct loop_worker {
Reviewed-by: Damien Le Moal
--
Damien Le Moal
Western Digital Research
Re: [dm-devel] [PATCH 11/11] xen-blkback: use bdev_discard_alignment
On 4/18/22 13:53, Christoph Hellwig wrote:
> Use bdev_discard_alignment to calculate the correct discard alignment
> offset even for partitions instead of just looking at the queue limit.
>
> Also switch to use bdev_discard_granularity to get rid of the last direct
> queue reference in xen_blkbk_discard.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/xen-blkback/xenbus.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/xen-blkback/xenbus.c
> b/drivers/block/xen-blkback/xenbus.c
> index b21bffc9c50bc..04c90cb8955f6 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -583,14 +583,14 @@ static void xen_blkbk_discard(struct xenbus_transaction
> xbt, struct backend_info
> if (bdev_max_discard_sectors(bdev)) {
> err = xenbus_printf(xbt, dev->nodename,
> "discard-granularity", "%u",
> - q->limits.discard_granularity);
> + bdev_discard_granularity(bdev));
> if (err) {
> dev_warn(>dev, "writing discard-granularity (%d)",
> err);
> return;
> }
> err = xenbus_printf(xbt, dev->nodename,
> "discard-alignment", "%u",
> - q->limits.discard_alignment);
> + bdev_discard_alignment(bdev));
> if (err) {
> dev_warn(>dev, "writing discard-alignment (%d)",
> err);
> return;
Reviewed-by: Damien Le Moal
--
Damien Le Moal
Western Digital Research
Re: [dm-devel] [PATCH 10/11] rnbd-srv: use bdev_discard_alignment
On 4/18/22 13:53, Christoph Hellwig wrote:
> Use bdev_discard_alignment to calculate the correct discard alignment
> offset even for partitions instead of just looking at the queue limit.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/rnbd/rnbd-srv-dev.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/rnbd/rnbd-srv-dev.h
> b/drivers/block/rnbd/rnbd-srv-dev.h
> index d080a0de59225..4309e52524691 100644
> --- a/drivers/block/rnbd/rnbd-srv-dev.h
> +++ b/drivers/block/rnbd/rnbd-srv-dev.h
> @@ -59,7 +59,7 @@ static inline int rnbd_dev_get_discard_granularity(const
> struct rnbd_dev *dev)
>
> static inline int rnbd_dev_get_discard_alignment(const struct rnbd_dev *dev)
> {
> - return bdev_get_queue(dev->bdev)->limits.discard_alignment;
> + return bdev_discard_alignment(dev->bdev);
> }
>
> #endif /* RNBD_SRV_DEV_H */
Reviewed-by: Damien Le Moal
--
Damien Le Moal
Western Digital Research
Re: [dm-devel] [PATCH 09/11] nvme: remove a spurious clear of discard_alignment
On 4/18/22 13:53, Christoph Hellwig wrote: > The nvme driver never sets a discard_alignment, so it also doens't need > to clear it to zero. > > Signed-off-by: Christoph Hellwig > --- > drivers/nvme/host/core.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c > index b9b0fbde97c80..76a9ccd5d064a 100644 > --- a/drivers/nvme/host/core.c > +++ b/drivers/nvme/host/core.c > @@ -1628,7 +1628,6 @@ static void nvme_config_discard(struct gendisk *disk, > struct nvme_ns *ns) > BUILD_BUG_ON(PAGE_SIZE / sizeof(struct nvme_dsm_range) < > NVME_DSM_MAX_RANGES); > > - queue->limits.discard_alignment = 0; > queue->limits.discard_granularity = size; > > /* If discard is already enabled, don't reset queue limits */ Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Research
Re: [dm-devel] [PATCH 03/11] null_blk: don't set the discard_alignment queue limit
On 4/18/22 13:53, Christoph Hellwig wrote: > The discard_alignment queue limit is named a bit misleading means the > offset into the block device at which the discard granularity starts. > Setting it to the discard granularity as done by null_blk is mostly > harmless but also useless. > > Signed-off-by: Christoph Hellwig > --- > drivers/block/null_blk/main.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c > index 5cb4c92cdffea..a521e914a9843 100644 > --- a/drivers/block/null_blk/main.c > +++ b/drivers/block/null_blk/main.c > @@ -1765,7 +1765,6 @@ static void null_config_discard(struct nullb *nullb) > } > > nullb->q->limits.discard_granularity = nullb->dev->blocksize; > - nullb->q->limits.discard_alignment = nullb->dev->blocksize; > blk_queue_max_discard_sectors(nullb->q, UINT_MAX >> 9); > } > Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Research
Re: [dm-devel] [PATCH 05/11] dm-zoned: don't set the discard_alignment queue limit
On 4/18/22 13:53, Christoph Hellwig wrote: > The discard_alignment queue limit is named a bit misleading means the > offset into the block device at which the discard granularity starts. > Setting it to the discard granularity as done by dm-zoned is mostly > harmless but also useless. > > Signed-off-by: Christoph Hellwig > --- > drivers/md/dm-zoned-target.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/md/dm-zoned-target.c b/drivers/md/dm-zoned-target.c > index cac295cc8840e..0ec5d8b9b1a4e 100644 > --- a/drivers/md/dm-zoned-target.c > +++ b/drivers/md/dm-zoned-target.c > @@ -1001,7 +1001,7 @@ static void dmz_io_hints(struct dm_target *ti, struct > queue_limits *limits) > blk_limits_io_min(limits, DMZ_BLOCK_SIZE); > blk_limits_io_opt(limits, DMZ_BLOCK_SIZE); > > - limits->discard_alignment = DMZ_BLOCK_SIZE; > + limits->discard_alignment = 0; > limits->discard_granularity = DMZ_BLOCK_SIZE; > limits->max_discard_sectors = chunk_sectors; > limits->max_hw_discard_sectors = chunk_sectors Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Research
[ovmf test] 169503: regressions - FAIL
flight 169503 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/169503/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 91a03f78ba0b75bc4ed2c4b756cbe57c685d9c72 baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 48 days Failing since168258 2022-03-01 01:55:31 Z 48 days 473 attempts Testing same since 169441 2022-04-16 00:41:39 Z2 days 49 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bo Chang Ke Bob Feng Chen Lin Z Chen, Lin Z Dandan Bi Dun Tan Feng, Bob C Gerd Hoffmann Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jason Jason Lou Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min Xu Oliver Steffen Patrick Rudolph Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Ted Kuo Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yuanhao Xie Zhihao Li jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5290 lines long.)
Re: [PATCH] xen: gntalloc.c: Convert kmap() to kmap_local_page()
On Mon, 18 Apr 2022, Alaa Mohamed wrote:
> The use of kmap() is being deprecated in favor of kmap_local_page()
> where it is feasible.
>
> With kmap_local_page(), the mapping is per thread, CPU local and not
> globally visible. Therefore __del_gref() is a function
> where the use of kmap_local_page() in place of kmap() is correctly
> suited.
What is it about __del_gref() that makes this change the right choice?
julia
>
> Signed-off-by: Alaa Mohamed
> ---
> drivers/xen/gntalloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
> index 4849f94372a4..55acb32842a3 100644
> --- a/drivers/xen/gntalloc.c
> +++ b/drivers/xen/gntalloc.c
> @@ -178,9 +178,9 @@ static void __del_gref(struct gntalloc_gref *gref)
> unsigned long addr;
>
> if (gref->notify.flags & UNMAP_NOTIFY_CLEAR_BYTE) {
> - uint8_t *tmp = kmap(gref->page);
> + uint8_t *tmp = kmap_local_page(gref->page);
> tmp[gref->notify.pgoff] = 0;
> - kunmap(gref->page);
> + kunmap_local(tmp);
> }
> if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT) {
> notify_remote_via_evtchn(gref->notify.event);
> --
> 2.35.2
>
>
>
[libvirt test] 169502: regressions - FAIL
flight 169502 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/169502/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a version targeted for testing: libvirt 6be7beb3bdb9ad611a5598dad7edfbd2a836fd2e baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 647 days Failing since151818 2020-07-11 04:18:52 Z 646 days 628 attempts Testing same since 169415 2022-04-15 04:18:55 Z3 days4 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Amneesh Singh Andika Triwidada Andrea Bolognani Andrew Melnychenko Ani Sinha Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brad Laue Brian Turek Bruno Haible Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck Christophe Fergeau Claudio Fontana Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Didik Supriadi dinglimin Divya Garg Dmitrii Shcherbakov Dmytro Linkin Eiichi Tsukata Emilio Herrera Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation Franck Ridel Gavi Teitz gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Haonan Wang Hela Basa Helmut Grohne Hiroki Narukawa Hyman Huang(黄勇) Ian Wienand Ioanna Alifieraki Ivan Teterevkov Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen jason lee Jean-Baptiste Holcroft Jia Zhou Jianan Gao Jim Fehlig Jin Yan Jing Qi Jinsheng Zhang Jiri Denemark Joachim Falk John Ferlan John Levon John Levon Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Kim InSoo Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Martin Pitt Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Moteen Shah Moteen Shah Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Paolo Bonzini Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Praveen K Paladugu Richard W.M. Jones Ricky Tigg Robin Lee
