[PATCH] automation: upgrade arm32 kernel from bullseye to bookworm

automation: upgrade arm32 kernel from bullseye to bookworm Signed-off-by: Stefano Stabellini diff --git a/automation/scripts/qemu-smoke-dom0less-arm32.sh b/automation/scripts/qemu-smoke-dom0less-arm32.sh index 41f6e5d8e6..0c94e662aa 100755 --- a/automation/scripts/qemu-smoke-dom0less-arm32.sh +

[ANNOUNCE] Save the Date! Xen Summit 2025 Hosted by AMD in San Jose, California

Hi all, I am very happy to announce that AMD will host the upcoming Xen Summit conference in San Jose, California, Sep 15-17. Save the date and join us to explore the latest developments, share insights, and connect with the Xen community! Learn more at the Xen Summit website: https://xenproject.o

Re: [PATCH] xen/arm: Create GIC node using the node name from host dt

On 20/02/2025 03:26, Stefano Stabellini wrote: > > > On Wed, 19 Feb 2025, Michal Orzel wrote: >> At the moment the GIC node we create for hwdom has a name >> "interrupt-controller". Change it so that we use the same name as the >> GIC node from host device tree. This is done for at least 2 pur

Re: [PATCH v3 3/3] x86/dom0: be less restrictive with the Interrupt Address Range

On Thu, Feb 20, 2025 at 09:33:46AM +0100, Jan Beulich wrote: > On 19.02.2025 17:48, Roger Pau Monne wrote: > > Xen currently prevents dom0 from creating CPU or IOMMU page-table mappings > > into the interrupt address range [0xfee0, 0xfeef]. This range has > > two different purposes. For a

[PATCH v2 2/2] x86/hvm: make ACPI PM timer support optional

From: Sergiy Kibrik Introduce config option X86_PMTIMER so that pmtimer driver can be disabled on systems that don't need it. Signed-off-by: Sergiy Kibrik Signed-off-by: Jiqian Chen --- Hi all, this is a rework for https://lore.kernel.org/xen-devel/20240916063757.990070-1-sergiy_kib...@epam.c

[PATCH v2 1/2] x86/hvm: make stdvga support optional

From: Sergiy Kibrik Introduce config option X86_STDVGA so that stdvga driver can be disabled on systems that don't need it. What's more, in function emulation_flags_ok, to check if toolstack pass any emulation flag that disabled in building time. Signed-off-by: Sergiy Kibrik Signed-off-by: Jiq

Re: [PATCH v3 02/25] drm/dumb-buffers: Provide helper to set pitch and size

Hi Am 20.02.25 um 10:18 schrieb Tomi Valkeinen: [...] + * Color modes of 10, 12, 15, 30 and 64 are only supported for use by + * legacy user space. Please don't use them in new code. Other modes + * are not support. + * + * Do not attempt to allocate anything but linear framebuffer memory + * wi

Re: [PATCH v3 23/25] drm/xe: Compute dumb-buffer sizes with drm_mode_size_dumb()

On 18/02/2025 14:23, Thomas Zimmermann wrote: Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. Align the pitch to a multiple of 8. Align the buffer size according to hardware requirements. Xe's internal calculation allowed for 64-bit wide buffer sizes, but the ioc

Re: [PATCH v2 1/2] x86/hvm: make stdvga support optional

Hi all, On 2025/2/20 17:53, Jiqian Chen wrote: > From: Sergiy Kibrik > > Introduce config option X86_STDVGA so that stdvga driver can be > disabled on systems that don't need it. > > What's more, in function emulation_flags_ok, to check if toolstack > pass any emulation flag that disabled in bu

Re: [PATCH v2 1/2] xen/list: avoid UB in list iterators

On 2/20/25 2:38 AM, Stefano Stabellini wrote: On Wed, 19 Feb 2025, Andrew Cooper wrote: On 19/02/2025 2:18 pm, Juergen Gross wrote: The list_for_each_entry*() iterators are testing for having reached the end of the list in a way which relies on undefined behavior: the iterator (being a pointer

Re: [PATCH v3 02/25] drm/dumb-buffers: Provide helper to set pitch and size

Hi, On 20/02/2025 12:05, Thomas Zimmermann wrote: Hi Am 20.02.25 um 10:18 schrieb Tomi Valkeinen: [...] + * Color modes of 10, 12, 15, 30 and 64 are only supported for use by + * legacy user space. Please don't use them in new code. Other modes + * are not support. + * + * Do not attempt to al

Re: [PATCH for 4.21 v6 1/2] xen/riscv: drop CONFIG_RISCV_ISA_RV64G

On 19.02.2025 18:56, Oleksii Kurochko wrote: > > On 2/18/25 6:03 PM, Jan Beulich wrote: >>> --- a/xen/arch/riscv/arch.mk >>> +++ b/xen/arch/riscv/arch.mk >>> @@ -6,8 +6,13 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) >>> riscv-abi-$(CONFIG_RISCV_32) := -mabi=ilp32 >>> riscv-abi

Re: xl create/save throwing errors

On 19.02.2025 17:04, Petr Beneš wrote: > Hello, > > I have a script that's supposed to start a couple of (Windows 10) VMs > in parallel, wait until they boot and connect to the network, and then > create a live snapshot. > > VMs are created by simple "xl create vm.cfg" and the live snapshot is >

Re: [PATCH v3 1/3] x86/dom0: correctly set the maximum ->iomem_caps bound for PVH

On Thu, Feb 20, 2025 at 09:22:40AM +0100, Jan Beulich wrote: > On 19.02.2025 17:48, Roger Pau Monne wrote: > > The logic in dom0_setup_permissions() sets the maximum bound in > > ->iomem_caps unconditionally using paddr_bits, which is not correct for HVM > > based domains. Instead use domain_max_p

Re: [PATCH v3 2/3] x86/iommu: account for IOMEM caps when populating dom0 IOMMU page-tables

On 19.02.2025 17:48, Roger Pau Monne wrote: > The current code in arch_iommu_hwdom_init() kind of open-codes the same > MMIO permission ranges that are added to the hardware domain ->iomem_caps. > Avoid this duplication and use ->iomem_caps in arch_iommu_hwdom_init() to > filter which memory region

Re: Re: Memory corruption bug with Xen PV Dom0 and BOSS-S1 RAID card

On Wed, Feb 19, 2025 at 07:37:47PM +0100, Paweł Srokosz wrote: > Hello, > > > So the issue doesn't happen on debug=y builds? That's unexpected. I would > > expect the opposite, that some code in Linux assumes that pfn + 1 == mfn + > > 1, and hence breaks when the relation is reversed. > > It was

Re: [PATCH v3 02/25] drm/dumb-buffers: Provide helper to set pitch and size

Hi, On 18/02/2025 16:23, Thomas Zimmermann wrote: Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer scanline pitch and allocation size. Implementations of struct drm_driver.dumb_create can call the new helper for their size computations. There is currently quite a bit of code dup

Re: [PATCH] x86/MCE-telem: adjust cookie definition

On 2/20/25 2:50 AM, Stefano Stabellini wrote: On Wed, 19 Feb 2025, Andrew Cooper wrote: On 19/02/2025 10:00 am, Jan Beulich wrote: struct mctelem_ent is opaque outside of mcetelem.c; the cookie abstraction exists - afaict - just to achieve this opaqueness. Then it is irrelevant though which ki

Re: xen/x86: resolve the last 3 MISRA R16.6 violations

On 2/20/25 2:52 AM, Stefano Stabellini wrote: On Wed, 19 Feb 2025, Jan Beulich wrote: On 18.02.2025 22:42, Stefano Stabellini wrote: On Tue, 18 Feb 2025, Jan Beulich wrote: On 18.02.2025 00:12, Stefano Stabellini wrote: On Mon, 17 Feb 2025, Jan Beulich wrote: On 15.02.2025 03:16, Stefano St

Re: [PATCH] xen/arm: Create GIC node using the node name from host dt

On 2/20/25 9:00 AM, Orzel, Michal wrote: On 20/02/2025 03:26, Stefano Stabellini wrote: On Wed, 19 Feb 2025, Michal Orzel wrote: At the moment the GIC node we create for hwdom has a name "interrupt-controller". Change it so that we use the same name as the GIC node from host device tree. Thi

Re: [PATCH v6] Avoid crash calling PrintErrMesg from efi_multiboot2

On Thu, Feb 20, 2025 at 7:32 AM Jan Beulich wrote: > > On 19.02.2025 17:34, Frediano Ziglio wrote: > > On Mon, Feb 17, 2025 at 4:56 PM Jan Beulich wrote: > >> On 17.02.2025 17:52, Frediano Ziglio wrote: > >>> On Mon, Feb 17, 2025 at 4:41 PM Andrew Cooper > >>> wrote: > On 17/02/2025 4:31 p

Re: Memory corruption bug with Xen PV Dom0 and BOSS-S1 RAID card

On 20.02.25 10:16, Roger Pau Monné wrote: On Wed, Feb 19, 2025 at 07:37:47PM +0100, Paweł Srokosz wrote: Hello, So the issue doesn't happen on debug=y builds? That's unexpected. I would expect the opposite, that some code in Linux assumes that pfn + 1 == mfn + 1, and hence breaks when the rel

[PATCH for-4.20] CI: Mark MISRA Rule 11.2 as clean

Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Michal Orzel CC: Jan Beulich CC: Julien Grall CC: Roger Pau Monné CC: Stefano Stabellini CC: Oleksii Kurochko CC: Nicola Vetrini For 4.20. I want to include the fix and this patch ahead of RC5 to avoid backporting. --- automation/e

Re: Memory corruption bug with Xen PV Dom0 and BOSS-S1 RAID card

On Thu, Feb 20, 2025 at 01:43:39PM +0100, Jürgen Groß wrote: > On 20.02.25 13:37, Roger Pau Monné wrote: > > On Thu, Feb 20, 2025 at 10:31:02AM +0100, Jürgen Groß wrote: > > > On 20.02.25 10:16, Roger Pau Monné wrote: > > > > On Wed, Feb 19, 2025 at 07:37:47PM +0100, Paweł Srokosz wrote: > > > > >

Re: Memory corruption bug with Xen PV Dom0 and BOSS-S1 RAID card

On Thu, Feb 20, 2025 at 10:31:02AM +0100, Jürgen Groß wrote: > On 20.02.25 10:16, Roger Pau Monné wrote: > > On Wed, Feb 19, 2025 at 07:37:47PM +0100, Paweł Srokosz wrote: > > > Hello, > > > > > > > So the issue doesn't happen on debug=y builds? That's unexpected. I > > > > would > > > > expect

Re: Memory corruption bug with Xen PV Dom0 and BOSS-S1 RAID card

On 20.02.25 13:37, Roger Pau Monné wrote: On Thu, Feb 20, 2025 at 10:31:02AM +0100, Jürgen Groß wrote: On 20.02.25 10:16, Roger Pau Monné wrote: On Wed, Feb 19, 2025 at 07:37:47PM +0100, Paweł Srokosz wrote: Hello, So the issue doesn't happen on debug=y builds? That's unexpected. I would ex

Re: [PATCH v2 1/2] x86/hvm: make stdvga support optional

On 20.02.2025 11:12, Chen, Jiqian wrote: > On 2025/2/20 17:53, Jiqian Chen wrote: >> From: Sergiy Kibrik >> >> Introduce config option X86_STDVGA so that stdvga driver can be >> disabled on systems that don't need it. >> >> What's more, in function emulation_flags_ok, to check if toolstack >> pass

Re: Memory corruption bug with Xen PV Dom0 and BOSS-S1 RAID card

On 20.02.25 14:29, Roger Pau Monné wrote: On Thu, Feb 20, 2025 at 01:43:39PM +0100, Jürgen Groß wrote: On 20.02.25 13:37, Roger Pau Monné wrote: On Thu, Feb 20, 2025 at 10:31:02AM +0100, Jürgen Groß wrote: On 20.02.25 10:16, Roger Pau Monné wrote: On Wed, Feb 19, 2025 at 07:37:47PM +0100, Paw

Re: [PATCH v3 1/3] x86/dom0: correctly set the maximum ->iomem_caps bound for PVH

On 20.02.2025 09:49, Roger Pau Monné wrote: > On Thu, Feb 20, 2025 at 09:22:40AM +0100, Jan Beulich wrote: >> On 19.02.2025 17:48, Roger Pau Monne wrote: >>> The logic in dom0_setup_permissions() sets the maximum bound in >>> ->iomem_caps unconditionally using paddr_bits, which is not correct for H

Re: [PATCH for-4.20] CI: Mark MISRA Rule 11.2 as clean

On 2025-02-20 13:53, Andrew Cooper wrote: Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Michal Orzel CC: Jan Beulich CC: Julien Grall CC: Roger Pau Monné CC: Stefano Stabellini CC: Oleksii Kurochko CC: Nicola Vetrini For 4.20. I want to include the fix and this patch ahead of

Re: [PATCH v3 3/3] x86/dom0: be less restrictive with the Interrupt Address Range

On 20.02.2025 09:55, Roger Pau Monné wrote: > On Thu, Feb 20, 2025 at 09:33:46AM +0100, Jan Beulich wrote: >> On 19.02.2025 17:48, Roger Pau Monne wrote: >>> Note that the restriction to map the local APIC page is enforced >>> separately, and that continues to be present. Additionally make sure th

Re: [PATCH v3 3/3] x86/dom0: be less restrictive with the Interrupt Address Range

On Thu, Feb 20, 2025 at 02:30:38PM +0100, Jan Beulich wrote: > On 20.02.2025 09:55, Roger Pau Monné wrote: > > On Thu, Feb 20, 2025 at 09:33:46AM +0100, Jan Beulich wrote: > >> On 19.02.2025 17:48, Roger Pau Monne wrote: > >>> Note that the restriction to map the local APIC page is enforced > >>> s

Re: [PATCH for-4.20] CI: Mark MISRA Rule 11.2 as clean

On 2/20/25 2:12 PM, Nicola Vetrini wrote: On 2025-02-20 13:53, Andrew Cooper wrote: Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Michal Orzel CC: Jan Beulich CC: Julien Grall CC: Roger Pau Monné CC: Stefano Stabellini CC: Oleksii Kurochko CC: Nicola Vetrini For 4.20.  I wan

Re: [PATCH v3 3/3] x86/dom0: be less restrictive with the Interrupt Address Range

On 20.02.2025 16:40, Roger Pau Monné wrote: > On Thu, Feb 20, 2025 at 02:30:38PM +0100, Jan Beulich wrote: >> On 20.02.2025 09:55, Roger Pau Monné wrote: >>> On Thu, Feb 20, 2025 at 09:33:46AM +0100, Jan Beulich wrote: On 19.02.2025 17:48, Roger Pau Monne wrote: > Note that the restriction

Re: [PATCH v2 21/25] drm/virtio: Compute dumb-buffer sizes with drm_mode_size_dumb()

On 1/9/25 17:57, Thomas Zimmermann wrote: > Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and > buffer size. Align the pitch to a multiple of 4. > > Signed-off-by: Thomas Zimmermann > Cc: David Airlie > Cc: Gerd Hoffmann > Cc: Gurchetan Singh > Cc: Chia-I Wu > --- > drivers

Re: [PATCH v3 3/3] x86/dom0: be less restrictive with the Interrupt Address Range

On Thu, Feb 20, 2025 at 05:05:44PM +0100, Jan Beulich wrote: > On 20.02.2025 16:40, Roger Pau Monné wrote: > > On Thu, Feb 20, 2025 at 02:30:38PM +0100, Jan Beulich wrote: > >> On 20.02.2025 09:55, Roger Pau Monné wrote: > >>> On Thu, Feb 20, 2025 at 09:33:46AM +0100, Jan Beulich wrote: > On 1

Re: [PATCH v4] xen/dom0less: support for vcpu affinity

Hi Stefano, On 20/02/2025 02:18, Stefano Stabellini wrote: From: Xenia Ragiadakou Add vcpu affinity to the dom0less bindings. Example: dom1 { ... cpus = <4>; vcpu0 { compatible = "xen,vcpu"; id = <0>;

Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs

On 19/02/25 12:25, Dave Hansen wrote: > On 2/19/25 07:13, Valentin Schneider wrote: >>> Maybe I missed part of the discussion though. Is VMEMMAP your only >>> concern? I would have guessed that the more generic vmalloc() >>> functionality would be harder to pin down. >> Urgh, that'll teach me to se

Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs

On 2/20/25 09:10, Valentin Schneider wrote: >> The LDT and maybe the PEBS buffers are the only implicit supervisor >> accesses to vmalloc()'d memory that I can think of. But those are both >> handled specially and shouldn't ever get zapped while in use. The LDT >> replacement has its own IPIs separ

[ANNOUNCEMENT] Xen 4.20.0-rc5 is tagged

Hi all, Xen 4.20 rc5 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.20.0-rc5 For your convenience there is also a tarball and the signature at: https://downloads.xenproject.org/release/xen/4.20.0-rc5/xen-4.20.0-rc5.tar.gz

[PATCH for 4.21 v5 1/3] xen/riscv: implement software page table walking

RISC-V doesn't have hardware feature to ask MMU to translate virtual address to physical address ( like Arm has, for example ), so software page table walking is implemented. Signed-off-by: Oleksii Kurochko Reviewed-by: Jan Beulich --- Changes in v5: - Update the comment above _pt_walk() about

[PATCH for 4.21 v5 3/3] xen/riscv: update mfn calculation in pt_mapping_level()

When pt_update() is called with arguments (..., INVALID_MFN, ..., 0 or 1), it indicates that a mapping is being destroyed/modifyed. In the case when modifying or destroying a mapping, it is necessary to search until a leaf node is found, instead of searching for a page table entry based on the pre

[PATCH for 4.21 v5 0/3] Fixes for vmap_to_mfn() and pt_mapping_level

Introduce pt_walk(), which does software page table walking to resolve the following issues: 1. vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA from either the direct map region or Xen's linkage region (XEN_VIRT_START), thereby an assertion will occur if it is used with

[PATCH for 4.21 v7 2/4] xen/riscv: drop CONFIG_RISCV_ISA_RV64G

'G' stands for "imafd_zicsr_zifencei". Extensions 'f' and 'd' aren't really needed for Xen, and allowing floating point registers to be used can lead to crashes. Extensions 'i', 'm', 'a', 'zicsr', and 'zifencei' are necessary for the operation of Xen, which is why they are used explicitly (uncond

[PATCH for 4.21 v7 0/4] RISC-V runtime detection of extenstions

Based on riscv,isa property of device tree file parse extenstions which are available in CPU. As a part of this feature, drop CONFIG_RISCV_ISA_RV64G and explicitly use extensions 'i', 'm', 'a', 'zicsr', 'zifencei' as they are necessary for a work if Xen and it should be true not only for RISC-V 64

[PATCH for 4.21 v5 2/3] xen/riscv: update defintion of vmap_to_mfn()

vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA from either the direct map region or Xen's linkage region (XEN_VIRT_START). An assertion will occur if it is used with other regions, in particular for the VMAP region. Since RISC-V lacks a hardware feature to request the MMU to

[PATCH for 4.21 v7 3/4] xen/riscv: make zbb as mandatory

According to riscv/booting.txt, it is expected that Zbb should be supported. Signed-off-by: Oleksii Kurochko --- Changes in v7: - new patch. --- xen/arch/riscv/arch.mk | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/arch.mk b/xen/arch/riscv/arch.mk inde

[PATCH for 4.21 v7 4/4] xen/riscv: identify specific ISA supported by cpu

Supported ISA extensions are specified in the device tree within the CPU node, using two properties: `riscv,isa-extensions` and `riscv,isa`. Currently, Xen does not support the `riscv,isa-extensions` property and will be added in the future. The `riscv,isa` property is parsed for each CPU, and th

[PATCH for 4.21 v7 1/4] automation: drop debian:11-riscv64 container

There are two reasons for that: 1. In the README, GCC baseline is chosen to be 12.2, whereas Debian 11 uses GCC 10.2.1. 2. Xen requires mandatory some Z extensions, but GCC 10.2.1 does not support Z extensions in -march, causing the compilation to fail. Signed-off-by: Oleksii Kurochko --- C

[PATCH for-4.20] eclair: mark R16.6 as clean

Signed-off-by: Stefano Stabellini --- This is possible thanks to "resolve the last 3 MISRA R16.6 violations" being committed. Requesting a release ack. Successful pipeline: https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/1681379131 diff --git a/automation/eclair_analysis/ECLAIR

Re: [PATCH v3 14/25] drm/nouveau: Compute dumb-buffer sizes with drm_mode_size_dumb()

Reviewed-by: Lyude Paul On Tue, 2025-02-18 at 15:23 +0100, Thomas Zimmermann wrote: > Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and > buffer size. Align the pitch to a multiple of 256. > > Signed-off-by: Thomas Zimmermann > Cc: Karol Herbst > Cc: Lyude Paul > Cc: Danilo

Re: Inquiry About PCI Passthrough Development and Testing Patches on ARM

Hi Shenghui, I have somewhat taken over the upstreaming effort for now, here is our plan: - 2025 Q1 1. Send "xen/arm: platform: Add support for R-Car Gen4" - Done 2. Revive "SMMU handling for PCIe Passthrough on ARM" - Done 3. Send "Add support for R-Car Gen4 PCIE Host"

Re: [PATCH v3 1/3] x86/dom0: correctly set the maximum ->iomem_caps bound for PVH

On 19.02.2025 17:48, Roger Pau Monne wrote: > The logic in dom0_setup_permissions() sets the maximum bound in > ->iomem_caps unconditionally using paddr_bits, which is not correct for HVM > based domains. Instead use domain_max_paddr_bits() to get the correct > maximum paddr bits for each possible

Re: [PATCH v3 3/3] x86/dom0: be less restrictive with the Interrupt Address Range

On 19.02.2025 17:48, Roger Pau Monne wrote: > Xen currently prevents dom0 from creating CPU or IOMMU page-table mappings > into the interrupt address range [0xfee0, 0xfeef]. This range has > two different purposes. For accesses from the CPU is contains the default > position of local APIC