Re: [RFC XEN PATCH v4 2/5] x86/pvh: Allow (un)map_pirq when caller isn't DOMID_SELF

On 2024/1/8 17:25, Jan Beulich wrote: > On 08.01.2024 10:15, Chen, Jiqian wrote: >> On 2024/1/8 16:47, Jan Beulich wrote: >>> On 06.01.2024 01:46, Stefano Stabellini wrote: On Fri, 5 Jan 2024, Jiqian Chen wrote: > @@ -72,8 +73,30 @@ long hvm_physdev_op(int cmd, > XEN_GUEST_HANDLE_PARA

[linux-5.4 test] 184281: regressions - FAIL

flight 184281 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/184281/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail REGR. vs. 184192 test-armhf-armhf-xl-

[linux-linus test] 184283: regressions - FAIL

flight 184283 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184283/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 184270 Tests which did not

[ovmf test] 184288: all pass - PUSHED

flight 184288 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184288/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f2b074398ca0624206355524a1c5f653ff87876a baseline version: ovmf e7152e6186d31bc138fbd

[xen-unstable test] 184278: regressions - FAIL

flight 184278 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184278/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 184271 Tests which did no

Re: [PATCH v5 04/13] xen: extend domctl interface for cache coloring

On Mon, 8 Jan 2024, Carlo Nonato wrote: > Hi Jan, > > On Mon, Jan 8, 2024 at 5:40 PM Jan Beulich wrote: > > > > On 08.01.2024 17:31, Carlo Nonato wrote: > > > On Mon, Jan 8, 2024 at 4:32 PM Julien Grall wrote: > > >> On 08/01/2024 15:18, Carlo Nonato wrote: > > No. I am saying that that we

[PATCH v3 33/46] hw/m68k/q800: use qemu_find_nic_info()

From: David Woodhouse If a corresponding NIC configuration was found, it will have a MAC address already assigned, so use that. Else, generate and assign a default one. Using qemu_find_nic_info() is simpler than the alternative of using qemu_configure_nic_device() and then having to fetch the "m

[PATCH v3 46/46] net: make nb_nics and nd_table[] static in net/net.c

From: David Woodhouse Signed-off-by: David Woodhouse --- include/net/net.h | 4 net/net.c | 3 +++ system/globals.c | 2 -- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/include/net/net.h b/include/net/net.h index 19fb82833c..766201c62c 100644 --- a/include/net/ne

[PATCH v3 31/46] hw/net/etraxfs-eth: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/cris/axis_dev88.c | 9 - hw/net/etraxfs_eth.c | 5 ++--- include/hw/cris/etraxfs.h | 2 +- 3 files changed, 7 insertions(+), 9 deletions(-) diff --git a/hw/cris/axis_dev88.c b/hw/cris/axis_dev88.c index d82050d927..5

[PATCH v3 04/46] hw/pci: add pci_init_nic_devices(), pci_init_nic_in_slot()

From: David Woodhouse The loop over nd_table[] to add PCI NICs is repeated in quite a few places. Add a helper function to do it. Some platforms also try to instantiate a specific model in a specific slot, to match the real hardware. Add pci_init_nic_in_slot() for that purpose. Signed-off-by: D

[PATCH v3 01/46] net: add qemu_{configure,create}_nic_device(), qemu_find_nic_info()

From: David Woodhouse Most code which directly accesses nd_table[] and nb_nics uses them for one of two things. Either "I have created a NIC device and I'd like a configuration for it", or "I will create a NIC device *if* there is a configuration for it". With some variants on the theme around w

[PATCH v3 41/46] hw/sparc/sun4m: use qemu_find_nic_info()

From: David Woodhouse Obtain the MAC address from the NIC configuration if there is one, or generate one explicitly so that it can be placed in the PROM. Signed-off-by: David Woodhouse --- hw/sparc/sun4m.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git

[PATCH v3 36/46] hw/mips/jazz: use qemu_find_nic_info()

From: David Woodhouse Extract the MAC address from the NICInfo, or generate one explicitly if there was no corresponding NIC configuration, to put it in the PROM. Signed-off-by: David Woodhouse --- hw/mips/jazz.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git

[PATCH v3 17/46] hw/ppc: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/ppc/e500.c | 4 +--- hw/ppc/mac_newworld.c | 4 +--- hw/ppc/mac_oldworld.c | 4 +--- hw/ppc/ppc440_bamboo.c | 14 +- 4 files changed, 8 insertions(+), 18 deletions(-) diff --git a/hw/ppc/e500.c b/hw/ppc/e500.

[PATCH v3 19/46] hw/sparc64/sun4u: use pci_init_nic_devices()

From: David Woodhouse The first sunhme NIC gets placed a function 1 on slot 1 of PCI bus A, and the rest are dynamically assigned on PCI bus B. Previously, any PCI NIC would get the special treatment purely by virtue of being first in the list. Signed-off-by: David Woodhouse --- hw/sparc64/su

[PATCH v3 44/46] hw/pci: remove pci_nic_init_nofail()

From: David Woodhouse This function is no longer used. Signed-off-by: David Woodhouse --- hw/pci/pci.c | 72 include/hw/pci/pci.h | 3 -- 2 files changed, 75 deletions(-) diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 5849606f66..449abfb18

[PATCH v3 12/46] hw/mips/fuloong2e: use pci_init_nic_devices()

From: David Woodhouse The previous behaviour was: *if* the first NIC specified on the command line was an RTL8139 (or unspecified model) then it gets assigned to PCI slot 7, which is where the Fuloong board had an RTL8139. All other devices (including the first, if it was specified a anything oth

[PATCH v3 28/46] hw/arm/npcm7xx: use qemu_configure_nic_device, allow emc0/emc1 as aliases

From: David Woodhouse Also update the test to specify which device to attach the test socket to, and remove the comment lamenting the fact that we can't do so. Signed-off-by: David Woodhouse --- hw/arm/npcm7xx.c | 16 +--- tests/qtest/npcm7xx_emc-test.c | 18 -

[PATCH v3 08/46] hw/arm/sbsa-ref: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse Reviewed-by: Leif Lindholm --- hw/arm/sbsa-ref.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c index 477dca0637..f0171176ea 100644 --- a/hw/arm/sbsa-ref.c +++ b/hw/arm/sbsa-ref.c

[PATCH v3 05/46] hw/i386/pc: use qemu_get_nic_info() and pci_init_nic_devices()

From: David Woodhouse Eliminate direct access to nd_table[] and nb_nics by processing the the Xen and ISA NICs first and then calling pci_init_nic_devices() for the rest. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- hw/i386/pc.c| 26 --

[PATCH v3 25/46] hw/net/smc91c111: use qemu_configure_nic_device()

From: David Woodhouse Some callers instantiate the device unconditionally, others will do so only if there is a NICInfo to go with it. This appears to be fairly random, but preserve the existing behaviour for now. Signed-off-by: David Woodhouse --- hw/arm/gumstix.c | 6 ++ hw/ar

[PATCH v3 23/46] hw/arm/exynos4: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/exynos4_boards.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/hw/arm/exynos4_boards.c b/hw/arm/exynos4_boards.c index b0e13eb4f0..003992189b 100644 --- a/hw/arm/exynos4_boards.c +++ b/hw/arm/exynos4_boa

[PATCH v3 32/46] hw/m68k/mcf5208: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/m68k/mcf5208.c | 19 ++- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c index d22d8536db..0cfb806c20 100644 --- a/hw/m68k/mcf5208.c +++ b/hw/m68k/mcf5208.c @@ -206,1

[PATCH v3 15/46] hw/ppc/prep: use pci_init_nic_devices()

From: David Woodhouse Previously, the first PCI NIC would be placed in PCI slot 3 and the rest would be dynamically assigned. Even if the user overrode the default NIC type and made it something other than PCNet. Now, the first PCNet NIC (that is, anything not explicitly specified to be anything

[PATCH v3 03/46] net: add qemu_create_nic_bus_devices()

From: David Woodhouse This will instantiate any NICs which live on a given bus type. Each bus is allowed *one* substitution (for PCI it's virtio → virtio-net-pci, for Xen it's xen → xen-net-device; no point in overengineering it unless we actually want more). Signed-off-by: David Woodhouse Revi

[PATCH v3 02/46] net: report list of available models according to platform

From: David Woodhouse By noting the models for which a configuration was requested, we can give the user an accurate list of which NIC models were actually available on the platform/configuration that was otherwise chosen. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- net/net.c

[PATCH v3 45/46] net: remove qemu_show_nic_models(), qemu_find_nic_model()

From: David Woodhouse These old functions can be removed now too. Let net_param_nic() print the full set of network devices directly, and also make it note that a list more specific to this platform/config will be available by using '-nic model=help' instead. Signed-off-by: David Woodhouse ---

[PATCH v3 37/46] hw/net/lasi_i82596: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/net/lasi_i82596.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/hw/net/lasi_i82596.c b/hw/net/lasi_i82596.c index 6a3147fe2d..2bb4f2c4ca 100644 --- a/hw/net/lasi_i82596.c +++ b/hw/net/lasi_i82596.c @@ -125,11 +1

[PATCH v3 09/46] hw/arm/virt: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/virt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 2793121cb4..8cf9237001 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -1454,9 +1454,7 @@ static void create_pcie(V

[PATCH v3 00/46] Rework matching of network devices to -nic options

Most platforms iterating directly over the nd_table[] are doing one of two things. Either they are creating the NIC for their platform and want to find a matching -nic configuration for it, if such exists. Or they are only going to create that platform NIC if a matching config *does* exist. All

[PATCH v3 26/46] hw/net/lan9118: use qemu_configure_nic_device()

From: David Woodhouse Some callers instantiate the device unconditionally, others will do so only if there is a NICInfo to go with it. This appears to be fairly random, but preseve the existing behaviour for now. Signed-off-by: David Woodhouse --- hw/arm/kzm.c | 4 ++-- hw/arm/mps2

[PATCH v3 40/46] hw/s390x/s390-virtio-ccw: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/s390x/s390-virtio-ccw.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 1169e20b94..202c378131 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/

[PATCH v3 06/46] hw/xen: use qemu_create_nic_bus_devices() to instantiate Xen NICs

From: David Woodhouse When instantiating XenBus itself, for each NIC which is configured with either the model unspecified, or set to to "xen" or "xen-net-device", create a corresponding xen-net-device for it. Now we can revert the previous more hackish version which relied on the platform code

[PATCH v3 22/46] hw/arm/aspeed: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/aspeed.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c index cc59176563..bed5e4f40b 100644 --- a/hw/arm/aspeed.c +++ b/hw/arm/aspeed.c @@ -356,7 +356,6 @@ static void

[PATCH v3 16/46] hw/ppc/spapr: use qemu_get_nic_info() and pci_init_nic_devices()

From: David Woodhouse Avoid directly referencing nd_table[] by first instantiating any spapr-vlan devices using a qemu_get_nic_info() loop, then calling pci_init_nic_devices() to do the rest. No functional change intended. Signed-off-by: David Woodhouse --- hw/ppc/spapr.c | 18 +--

[PATCH v3 38/46] hw/openrisc/openrisc_sim: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/openrisc/openrisc_sim.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c index 35da123aef..bffd6f721f 100644 --- a/hw/openrisc/openrisc_sim.c

[PATCH v3 42/46] hw/xtensa/xtfpga: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/xtensa/xtfpga.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/hw/xtensa/xtfpga.c b/hw/xtensa/xtfpga.c index fbad1c83a3..f49e6591dc 100644 --- a/hw/xtensa/xtfpga.c +++ b/hw/xtensa/xtfpga.c @@ -141,14

[PATCH v3 21/46] hw/arm/allwinner: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/allwinner-a10.c | 6 +- hw/arm/allwinner-h3.c | 6 +- hw/arm/allwinner-r40.c | 27 ++- 3 files changed, 4 insertions(+), 35 deletions(-) diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10

[PATCH v3 07/46] hw/alpha/dp264: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/alpha/dp264.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c index 03495e1e60..52a1fa310b 100644 --- a/hw/alpha/dp264.c +++ b/hw/alpha/dp264.c @@ -124,9 +124,7 @@ static void

[PATCH v3 10/46] hw/hppa: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/hppa/machine.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c index c8da7c18d5..19d477105e 100644 --- a/hw/hppa/machine.c +++ b/hw/hppa/machine.c @@ -338,7 +338,6 @@ sta

[PATCH v3 24/46] hw/arm/fsl: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/fsl-imx25.c | 2 +- hw/arm/fsl-imx6.c | 2 +- hw/arm/fsl-imx6ul.c | 2 +- hw/arm/fsl-imx7.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/hw/arm/fsl-imx25.c b/hw/arm/fsl-imx25.c index 9d2fb75a68..a24fa

[PATCH v3 39/46] hw/riscv: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/riscv/microchip_pfsoc.c | 14 ++ hw/riscv/sifive_u.c| 7 +-- 2 files changed, 3 insertions(+), 18 deletions(-) diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c index b775aa8946..7725dfbde5

[PATCH v3 14/46] hw/mips/loongson3_virt: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/mips/loongson3_virt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c index 33eae01eca..caedde2df0 100644 --- a/hw/mips/loongson3_virt.c +++ b/hw/mips/loongson3

[PATCH v3 34/46] hw/microblaze: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/microblaze/petalogix_ml605_mmu.c | 3 +-- hw/microblaze/petalogix_s3adsp1800_mmu.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/hw/microblaze/petalogix_ml605_mmu.c b/hw/microblaze/petalogix_ml605_mmu.c

[PATCH v3 27/46] hw/arm/highbank: use qemu_create_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/highbank.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c index c21e18d08f..6a0e20e58d 100644 --- a/hw/arm/highbank.c +++ b/hw/arm/highbank.c @@ -296,19 +296,1

[PATCH v3 43/46] net: remove qemu_check_nic_model()

From: David Woodhouse Signed-off-by: David Woodhouse --- include/net/net.h | 1 - net/net.c | 13 - 2 files changed, 14 deletions(-) diff --git a/include/net/net.h b/include/net/net.h index 31e63d1f0d..1be8b40074 100644 --- a/include/net/net.h +++ b/include/net/net.h @@ -2

[PATCH v3 29/46] hw/arm/stellaris: use qemu_find_nic_info()

From: David Woodhouse Rather than just using qemu_configure_nic_device(), populate the MAC address in the system-registers device by peeking at the NICInfo before it's assigned to the device. Generate the MAC address early, if there is no matching -nic option. Otherwise the MAC address wouldn't

[PATCH v3 30/46] hw/arm: use qemu_configure_nic_device()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/arm/mps2-tz.c | 8 ++-- hw/arm/msf2-soc.c| 6 +- hw/arm/musicpal.c| 3 +-- hw/arm/xilinx_zynq.c | 11 --- hw/arm/xlnx-versal.c | 7 +-- hw/arm/xlnx-zynqmp.c | 8 +--- 6 files changed, 10 inserti

[PATCH v3 35/46] hw/mips/mipssim: use qemu_create_nic_device()

From: David Woodhouse The MIPS SIM platform instantiates its NIC only if a corresponding configuration exists for it. Use qemu_create_nic_device() function for that. Signed-off-by: David Woodhouse --- hw/mips/mipssim.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff -

[PATCH v3 11/46] hw/loongarch: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/loongarch/virt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 4b7dc67a2d..c48804ac38 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -504,9 +504,7

[PATCH v3 13/46] hw/mips/malta: use pci_init_nic_devices()

From: David Woodhouse The Malta board setup code would previously place the first NIC into PCI slot 11 if was a PCNet card, and the rest (including the first if it was anything other than a PCNet card) would be dynamically assigned. Now it will place any PCNet NIC into slot 11, and then anything

[PATCH v3 20/46] hw/xtensa/virt: use pci_init_nic_devices()

From: David Woodhouse Signed-off-by: David Woodhouse --- hw/xtensa/virt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c index a6cf646e99..5310a88861 100644 --- a/hw/xtensa/virt.c +++ b/hw/xtensa/virt.c @@ -102,9 +102,7 @@ static void

[PATCH v3 18/46] hw/sh4/r2d: use pci_init_nic_devices()

From: David Woodhouse Previously, the first PCI NIC would be assigned to slot 2 even if the user override the model and made it something other than an rtl8139 which is the default. Everything else would be dynamically assigned. Now, the first rtl8139 gets slot 2 and everything else is dynamic.

[linux-5.4 test] 184275: regressions - FAIL

flight 184275 linux-5.4 real [real] flight 184280 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184275/ http://logs.test-lab.xenproject.org/osstest/logs/184280/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: t

Re: [PATCH v2] NUMA: no need for asm/numa.h when !NUMA

Hi Jan, On 1/8/24 5:30 AM, Jan Beulich wrote: > There's no point in every architecture carrying the same stubs for the > case when NUMA isn't enabled (or even supported). Move all of that to > xen/numa.h; replace explicit uses of asm/numa.h in common code. Make > inclusion of asm/numa.h dependent

Re: Clang-format configuration discussion - pt 2

> I found the way we dealt with MISRA rules quite helpful. We had a weekly meeting to discuss some of the rules and then the outcome was posted on the ML. Maybe we should do the same here? Any other suggestion how to move? >>> >>> I have mixed feelings with meetings like the M

Re: [PATCH v5 08/13] xen/page_alloc: introduce preserved page flags macro

On 02.01.2024 10:51, Carlo Nonato wrote: > PGC_static and PGC_extra are flags that needs to be preserved when assigning > a page. Define a new macro that groups those flags and use it instead of > or'ing every time. > > The new macro is used also in free_heap_pages() allowing future commits to > e

Re: [PATCH v5 01/13] xen/common: add cache coloring common code

On 02.01.2024 10:51, Carlo Nonato wrote: > This commit adds the Last Level Cache (LLC) coloring common header, Kconfig > options and functions. Since this is an arch specific feature, actual > implementation is postponed to later patches and Kconfig options are placed > under xen/arch. As a genera

Re: [PATCH v5 04/13] xen: extend domctl interface for cache coloring

Hi Jan, On Mon, Jan 8, 2024 at 5:40 PM Jan Beulich wrote: > > On 08.01.2024 17:31, Carlo Nonato wrote: > > On Mon, Jan 8, 2024 at 4:32 PM Julien Grall wrote: > >> On 08/01/2024 15:18, Carlo Nonato wrote: > No. I am saying that that we should not be able to allow changing the > colors a

Re: [PATCH v5 04/13] xen: extend domctl interface for cache coloring

Hi Carlo, On 08/01/2024 16:31, Carlo Nonato wrote: On Mon, Jan 8, 2024 at 4:32 PM Julien Grall wrote: Hi, On 08/01/2024 15:18, Carlo Nonato wrote: No. I am saying that that we should not be able to allow changing the colors after the memory has been allocated. To give an example, your curre

[xtf test] 184279: all pass - PUSHED

flight 184279 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184279/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 2eed9f51c67a9e5d29ffd4ffeee50710489aad23 baseline version: xtf a5bd8d9e5d5c7b729d6d61

Re: [PATCH v5 04/13] xen: extend domctl interface for cache coloring

On 08.01.2024 17:31, Carlo Nonato wrote: > On Mon, Jan 8, 2024 at 4:32 PM Julien Grall wrote: >> On 08/01/2024 15:18, Carlo Nonato wrote: No. I am saying that that we should not be able to allow changing the colors after the memory has been allocated. To give an example, your curren

[PULL 5/6] Replace "iothread lock" with "BQL" in comments

The term "iothread lock" is obsolete. The APIs use Big QEMU Lock (BQL) in their names. Update the code comments to use "BQL" instead of "iothread lock". Signed-off-by: Stefan Hajnoczi Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Paul Durrant Reviewed-by: Akihiko Odaki Reviewed-by: Cédric L

[PULL 6/6] Rename "QEMU global mutex" to "BQL" in comments and docs

The term "QEMU global mutex" is identical to the more widely used Big QEMU Lock ("BQL"). Update the code comments and documentation to use "BQL" instead of "QEMU global mutex". Signed-off-by: Stefan Hajnoczi Acked-by: Markus Armbruster Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Paul Durra

[PULL 3/6] qemu/main-loop: rename QEMU_IOTHREAD_LOCK_GUARD to BQL_LOCK_GUARD

The name "iothread" is overloaded. Use the term Big QEMU Lock (BQL) instead, it is already widely used and unambiguous. Signed-off-by: Stefan Hajnoczi Reviewed-by: Paul Durrant Acked-by: David Woodhouse Reviewed-by: Cédric Le Goater Acked-by: Ilya Leoshkevich Reviewed-by: Harsh Prateek Bora

[PULL 4/6] qemu/main-loop: rename qemu_cond_wait_iothread() to qemu_cond_wait_bql()

The name "iothread" is overloaded. Use the term Big QEMU Lock (BQL) instead, it is already widely used and unambiguous. Signed-off-by: Stefan Hajnoczi Reviewed-by: Cédric Le Goater Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Paul Durrant Reviewed-by: Harsh Prateek Bora Reviewed-by: Akihi

[PULL 2/6] system/cpus: rename qemu_mutex_lock_iothread() to bql_lock()

The Big QEMU Lock (BQL) has many names and they are confusing. The actual QemuMutex variable is called qemu_global_mutex but it's commonly referred to as the BQL in discussions and some code comments. The locking APIs, however, are called qemu_mutex_lock_iothread() and qemu_mutex_unlock_iothread().

[PULL 1/6] iothread: Remove unused Error** argument in aio_context_set_aio_params

From: Philippe Mathieu-Daudé aio_context_set_aio_params() doesn't use its undocumented Error** argument. Remove it to simplify. Note this removes a use of "unchecked Error**" in iothread_set_aio_context_params(). Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Markus Armbruster Signed-off-

[PULL 0/6] Block patches

The following changes since commit ffd454c67e38cc6df792733ebc5d967eee28ac0d: Merge tag 'pull-vfio-20240107' of https://github.com/legoater/qemu into staging (2024-01-08 10:28:42 +) are available in the Git repository at: https://gitlab.com/stefanha/qemu.git tags/block-pull-request for

Re: [PATCH v3 0/5] Make Big QEMU Lock naming consistent

On Tue, Jan 02, 2024 at 10:35:24AM -0500, Stefan Hajnoczi wrote: > v3: > - Rebase > - Define bql_lock() macro on a single line [Akihiko Odaki] > v2: > - Rename APIs bql_*() [PeterX] > - Spell out "Big QEMU Lock (BQL)" in doc comments [PeterX] > - Rename "iolock" variables in hw/remote/mpqemu-link.c

Re: [PATCH v5 04/13] xen: extend domctl interface for cache coloring

Hi Julien, On Mon, Jan 8, 2024 at 4:32 PM Julien Grall wrote: > > Hi, > > On 08/01/2024 15:18, Carlo Nonato wrote: > >> No. I am saying that that we should not be able to allow changing the > >> colors after the memory has been allocated. To give an example, your > >> current code would allow: >

Re: [PATCH v5 04/13] xen: extend domctl interface for cache coloring

Hi, On 08/01/2024 15:18, Carlo Nonato wrote: No. I am saying that that we should not be able to allow changing the colors after the memory has been allocated. To give an example, your current code would allow: 1) Setup the P2M pools or allocate RAM 2) Set the color This would render th

Re: [PATCH v2] NUMA: limit first_valid_mfn exposure

Hi Jan, On 08/01/2024 15:03, Jan Beulich wrote: On 08.01.2024 15:57, Julien Grall wrote: Hi Jan, On 08/01/2024 14:47, Jan Beulich wrote: On 08.01.2024 15:13, Julien Grall wrote: Hi Jan, On 08/01/2024 11:43, Jan Beulich wrote: On 08.01.2024 12:37, Julien Grall wrote: On 08/01/2024 11:31, J

Re: [PATCH v5 04/13] xen: extend domctl interface for cache coloring

Hi Julien On Mon, Jan 8, 2024 at 12:36 PM Julien Grall wrote: > > Hi Carlo, > > On 08/01/2024 11:19, Carlo Nonato wrote: > > Hi Julien, > > > > On Mon, Jan 8, 2024 at 12:01 PM Julien Grall wrote: > >> > >> Hi Carlo, > >> > >> On 08/01/2024 10:27, Carlo Nonato wrote: > >>> On Fri, Jan 5, 2024 at

Re: [RFC XEN PATCH v4 4/5] domctl: Use gsi to grant/revoke irq permission

On Mon, Jan 08, 2024 at 09:55:26AM +0100, Jan Beulich wrote: > On 06.01.2024 02:08, Stefano Stabellini wrote: > > On Fri, 5 Jan 2024, Jiqian Chen wrote: > >> --- a/tools/libs/light/libxl_pci.c > >> +++ b/tools/libs/light/libxl_pci.c > >> @@ -1418,6 +1418,7 @@ static void pci_add_dm_done(libxl__egc

Re: [PATCH v2] NUMA: limit first_valid_mfn exposure

On 08.01.2024 15:57, Julien Grall wrote: > Hi Jan, > > On 08/01/2024 14:47, Jan Beulich wrote: >> On 08.01.2024 15:13, Julien Grall wrote: >>> Hi Jan, >>> >>> On 08/01/2024 11:43, Jan Beulich wrote: On 08.01.2024 12:37, Julien Grall wrote: > On 08/01/2024 11:31, Jan Beulich wrote: >>

Re: [PATCH v3 07/34] xen/asm-generic: introdure nospec.h

On Thu, 2024-01-04 at 12:06 +0100, Jan Beulich wrote: > On 22.12.2023 16:12, Oleksii Kurochko wrote: > > The header is similar between Arm, PPC, and RISC-V, > > so it has been moved to asm-generic. > > > > Signed-off-by: Oleksii Kurochko > > Acked-by: Jan Beulich > > A word may want saying th

Re: Xen 4.19 release schedule proposal

On 08.01.2024 15:37, Oleksii wrote: > On Thu, 2024-01-04 at 13:52 +0100, Jan Beulich wrote: >> On 02.01.2024 17:59, Oleksii wrote: >>> I'd like to propose the release schedule for Xen 4.19. >>> >>> Based on the previous release schedules [1] and [2], it seems the >>> next >>> release date should be

Re: [PATCH v2] NUMA: limit first_valid_mfn exposure

Hi Jan, On 08/01/2024 14:47, Jan Beulich wrote: On 08.01.2024 15:13, Julien Grall wrote: Hi Jan, On 08/01/2024 11:43, Jan Beulich wrote: On 08.01.2024 12:37, Julien Grall wrote: On 08/01/2024 11:31, Jan Beulich wrote: Address the TODO regarding first_valid_mfn by making the variable static

Re: [PATCH v3 06/34] xen: avoid generation of empty asm/iommu.h

On Thu, 2024-01-04 at 12:04 +0100, Jan Beulich wrote: > On 22.12.2023 16:12, Oleksii Kurochko wrote: > > Signed-off-by: Oleksii Kurochko > > The change looks okay-ish, but again needs a description: You want to > explain why you use the absolute minimum of the scopes the two (or, > in principle,

Re: [PATCH v2] NUMA: limit first_valid_mfn exposure

On 08.01.2024 15:13, Julien Grall wrote: > Hi Jan, > > On 08/01/2024 11:43, Jan Beulich wrote: >> On 08.01.2024 12:37, Julien Grall wrote: >>> On 08/01/2024 11:31, Jan Beulich wrote: Address the TODO regarding first_valid_mfn by making the variable static when NUMA=y, thus also addressin

Re: [PATCH v3 03/34] xen: add support in public/hvm/save.h for PPC and RISC-V

On Thu, 2024-01-04 at 12:01 +0100, Jan Beulich wrote: > On 22.12.2023 16:12, Oleksii Kurochko wrote: > > Signed-off-by: Oleksii Kurochko > > Since you change how PPC is handled, this can't go without > description (i.e. > justification). I thought adding a comment in the code would be sufficient.

Re: [XEN RFC] x86/uaccess: remove __{put,get}_user_bad()

On 08.01.2024 15:01, Federico Serafini wrote: > Additionally, looking at violations of 16.3 on X86 [1], > I think we should also consider generate_exception(), > ASSERT_UNREACHABLE() and PARSE_ERR_RET() as allowed terminals > for a switch-clause, do you agree? No, and iirc this was discussed befor

Re: Xen 4.19 release schedule proposal

On Thu, 2024-01-04 at 13:52 +0100, Jan Beulich wrote: > On 02.01.2024 17:59, Oleksii wrote: > > I'd like to propose the release schedule for Xen 4.19. > > > > Based on the previous release schedules [1] and [2], it seems the > > next > > release date should be on Wednesday, July 10, 2024: > > > >

[xtf test] 184277: all pass - PUSHED

flight 184277 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184277/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf a5bd8d9e5d5c7b729d6d6122900d28f7a00aa6c0 baseline version: xtf 0a58a1471eb5f692700c0f

Re: [PATCH v2] NUMA: limit first_valid_mfn exposure

Hi Jan, On 08/01/2024 11:43, Jan Beulich wrote: On 08.01.2024 12:37, Julien Grall wrote: On 08/01/2024 11:31, Jan Beulich wrote: Address the TODO regarding first_valid_mfn by making the variable static when NUMA=y, thus also addressing a Misra C:2012 rule 8.4 concern (on x86). Signed-off-by:

Re: [XEN RFC] x86/uaccess: remove __{put,get}_user_bad()

On 08/01/24 12:36, Jan Beulich wrote: On 08.01.2024 12:16, Federico Serafini wrote: On 08/01/24 09:02, Jan Beulich wrote: On 05.01.2024 17:19, Federico Serafini wrote: Hello everyone, On 21/12/23 13:41, Jan Beulich wrote: On 21.12.2023 13:01, Nicola Vetrini wrote: Hi Andrew, On 2023-12-21

[ovmf test] 184276: all pass - PUSHED

flight 184276 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184276/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf e7152e6186d31bc138fbd2592e07886005177aab baseline version: ovmf c3d865a4c21d91f2e338a

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

flight 184274 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184274/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Re: [PATCH] hw/i386/pc_piix: Make piix_intx_routing_notifier_xen() more device independent

On 8/1/24 00:16, Bernhard Beschow wrote: This is a follow-up on commit 89965db43cce "hw/isa/piix3: Avoid Xen-specific variant of piix3_write_config()" which introduced piix_intx_routing_notifier_xen(). This function is implemented in board code but accesses the PCI configuration space of the PIIX

Re: [PATCH v2] xen/gntdev: Fix the abuse of underlying struct page in DMA-buf import

On Sun, 7 Jan 2024 at 11:35, Oleksandr Tyshchenko wrote: > > From: Oleksandr Tyshchenko > > DO NOT access the underlying struct page of an sg table exported > by DMA-buf in dmabuf_imp_to_refs(), this is not allowed. > Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details. > > Fortuna

Re: [PATCH v5 03/13] xen/arm: add Dom0 cache coloring support

On Mon, Jan 8, 2024 at 12:44 PM Julien Grall wrote: > > > > On 08/01/2024 11:04, Carlo Nonato wrote: > > Hi Julien, > > > > On Mon, Jan 8, 2024 at 11:25 AM Julien Grall wrote: > >> > >> Hi Carlo, > >> > >> On 08/01/2024 10:06, Carlo Nonato wrote: > One of the reason is at least in the dom0le

Re: [PATCH v5 03/13] xen/arm: add Dom0 cache coloring support

On 08/01/2024 11:04, Carlo Nonato wrote: Hi Julien, On Mon, Jan 8, 2024 at 11:25 AM Julien Grall wrote: Hi Carlo, On 08/01/2024 10:06, Carlo Nonato wrote: One of the reason is at least in the dom0less case, you will override the value afterwards. In that case I need to allocate the arr

Re: [PATCH v2] NUMA: limit first_valid_mfn exposure

On 08.01.2024 12:37, Julien Grall wrote: > On 08/01/2024 11:31, Jan Beulich wrote: >> Address the TODO regarding first_valid_mfn by making the variable static >> when NUMA=y, thus also addressing a Misra C:2012 rule 8.4 concern (on >> x86). >> >> Signed-off-by: Jan Beulich >> --- >> Julien suggest

Re: [PATCH v2] NUMA: limit first_valid_mfn exposure

Hi Jan, On 08/01/2024 11:31, Jan Beulich wrote: Address the TODO regarding first_valid_mfn by making the variable static when NUMA=y, thus also addressing a Misra C:2012 rule 8.4 concern (on x86). Signed-off-by: Jan Beulich --- Julien suggests something like STATIC_IF(CONFIG_NUMA) unsigned lo

Re: [XEN RFC] x86/uaccess: remove __{put,get}_user_bad()

On 08.01.2024 12:16, Federico Serafini wrote: > On 08/01/24 09:02, Jan Beulich wrote: >> On 05.01.2024 17:19, Federico Serafini wrote: >>> Hello everyone, >>> >>> On 21/12/23 13:41, Jan Beulich wrote: On 21.12.2023 13:01, Nicola Vetrini wrote: > Hi Andrew, > > On 2023-12-21 12:03,

Re: [PATCH v5 04/13] xen: extend domctl interface for cache coloring

Hi Carlo, On 08/01/2024 11:19, Carlo Nonato wrote: Hi Julien, On Mon, Jan 8, 2024 at 12:01 PM Julien Grall wrote: Hi Carlo, On 08/01/2024 10:27, Carlo Nonato wrote: On Fri, Jan 5, 2024 at 6:26 PM Julien Grall wrote: On 02/01/2024 09:51, Carlo Nonato wrote: This commit updates the domctl

[PATCH v2] NUMA: limit first_valid_mfn exposure

Address the TODO regarding first_valid_mfn by making the variable static when NUMA=y, thus also addressing a Misra C:2012 rule 8.4 concern (on x86). Signed-off-by: Jan Beulich --- Julien suggests something like STATIC_IF(CONFIG_NUMA) unsigned long first_valid_mfn; but I view this as non-scalabl

[PATCH v2] NUMA: no need for asm/numa.h when !NUMA

There's no point in every architecture carrying the same stubs for the case when NUMA isn't enabled (or even supported). Move all of that to xen/numa.h; replace explicit uses of asm/numa.h in common code. Make inclusion of asm/numa.h dependent upon NUMA=y. Drop the no longer applicable "implement

Re: [PATCH v5 11/13] Revert "xen/arm: Remove unused BOOT_RELOC_VIRT_START"

Hi Julien, On Fri, Jan 5, 2024 at 7:20 PM Julien Grall wrote: > > Hi Carlo, > > On 02/01/2024 09:51, Carlo Nonato wrote: > > This reverts commit 0c18fb76323bfb13615b6f13c98767face2d8097 (not clean). > > > > This is not a clean revert since the rework of the memory layout, but it is > > sufficient

  1   2   >