linux-stable.git/drivers/xen, branch v6.16.2

xen/gntdev: remove struct gntdev_copy_batch from stack

2025-08-15T14:38:47+00:00

[ Upstream commit 70045cf6593cbf0740956ea9b7b4269142c6ee38 ]

When compiling the kernel with LLVM, the following warning was issued:

  drivers/xen/gntdev.c:991: warning: stack frame size (1160) exceeds
  limit (1024) in function 'gntdev_ioctl'

The main reason is struct gntdev_copy_batch which is located on the
stack and has a size of nearly 1kb.

For performance reasons it shouldn't by just dynamically allocated
instead, so allocate a new instance when needed and instead of freeing
it put it into a list of free structs anchored in struct gntdev_priv.

Fixes: a4cdb556cae0 ("xen/gntdev: add ioctl for grant copy")
Reported-by: Abinash Singh 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250703073259.17356-1-jgross@suse.com>
Signed-off-by: Sasha Levin

xen: fix UAF in dmabuf_exp_from_pages()

2025-08-15T14:38:46+00:00

[ Upstream commit 532c8b51b3a8676cbf533a291f8156774f30ea87 ]

[dma_buf_fd() fixes; no preferences regarding the tree it goes through -
up to xen folks]

As soon as we'd inserted a file reference into descriptor table, another
thread could close it.  That's fine for the case when all we are doing is
returning that descriptor to userland (it's a race, but it's a userland
race and there's nothing the kernel can do about it).  However, if we
follow fd_install() with any kind of access to objects that would be
destroyed on close (be it the struct file itself or anything destroyed
by its ->release()), we have a UAF.

dma_buf_fd() is a combination of reserving a descriptor and fd_install().
gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the
objects destroyed on close - starting with gntdev_dmabuf itself.

Fix that by doing reserving descriptor before anything else and do
fd_install() only when everything had been set up.

Fixes: a240d6e42e28 ("xen/gntdev: Implement dma-buf export functionality")
Signed-off-by: Al Viro 
Acked-by: Juergen Gross 
Message-ID: <20250712050916.GY1880847@ZenIV>
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin

xen/x86: fix initial memory balloon target

2025-05-23T05:09:00+00:00

When adding extra memory regions as ballooned pages also adjust the balloon
target, otherwise when the balloon driver is started it will populate
memory to match the target value and consume all the extra memory regions
added.

This made the usage of the Xen `dom0_mem=,max:` command line parameter for
dom0 not work as expected, as the target won't be adjusted and when the
balloon is started it will populate memory straight to the 'max:' value.
It would equally affect domUs that have memory != maxmem.

Kernels built with CONFIG_XEN_UNPOPULATED_ALLOC are not affected, because
the extra memory regions are consumed by the unpopulated allocation driver,
and then balloon_add_regions() becomes a no-op.

Reported-by: John 
Fixes: 87af633689ce ('x86/xen: fix balloon target initialization for PVH dom0')
Signed-off-by: Roger Pau Monné 
Reviewed-by: Juergen Gross 
Tested-by: Marek Marczykowski-Górecki 
Message-ID: <20250514080427.28129-1-roger.pau@citrix.com>
Signed-off-by: Juergen Gross

xen: swiotlb: Wire up map_resource callback

2025-05-23T05:05:50+00:00

When running Xen on iMX8QXP, an Arm SoC without IOMMU, DMA performed via
its eDMA v3 DMA engine fail with a mapping error.

The eDMA performs DMA between RAM and MMIO space, and it's the MMIO side
that cannot be mapped.

MMIO->RAM DMA access cannot be bounce buffered if it would straddle a page
boundary and on Xen the MMIO space is 1:1 mapped for Arm, and x86 PV Dom0.
Cases where MMIO space is not 1:1 mapped, such as x86 PVH Dom0, requires an
IOMMU present to deal with the mapping.

Considering the above the map_resource callback can just be wired to the
existing dma_direct_map_resource() function.

There is nothing to do for unmap so the unmap callback is not needed.

Signed-off-by: John Ernberg 
Reviewed-by: Stefano Stabellini 

Message-ID: <20250512071440.3726697-1-john.ernberg@actia.se>
Signed-off-by: Juergen Gross

xenbus: Use kref to track req lifetime

2025-05-07T14:21:41+00:00

Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
 
 __wake_up_common_lock+0x82/0xd0
 process_msg+0x18e/0x2f0
 xenbus_thread+0x165/0x1c0

process_msg+0x18e is req->cb(req).  req->cb is set to xs_wake_up(), a
thin wrapper around wake_up(), or xenbus_dev_queue_reply().  It seems
like it was xs_wake_up() in this case.

It seems like req may have woken up the xs_wait_for_reply(), which
kfree()ed the req.  When xenbus_thread resumes, it faults on the zero-ed
data.

Linux Device Drivers 2nd edition states:
"Normally, a wake_up call can cause an immediate reschedule to happen,
meaning that other processes might run before wake_up returns."
... which would match the behaviour observed.

Change to keeping two krefs on each request.  One for the caller, and
one for xenbus_thread.  Each will kref_put() when finished, and the last
will free it.

This use of kref matches the description in
Documentation/core-api/kref.rst

Link: https://lore.kernel.org/xen-devel/ZO0WrR5J0xuwDIxW@mail-itl/
Reported-by: Marek Marczykowski-Górecki 
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Cc: stable@vger.kernel.org
Signed-off-by: Jason Andryuk 
Reviewed-by: Juergen Gross 
Signed-off-by: Juergen Gross 
Message-ID: <20250506210935.5607-1-jason.andryuk@amd.com>

xenbus: Allow PVH dom0 a non-local xenstore

2025-05-07T14:15:27+00:00

Make xenbus_init() allow a non-local xenstore for a PVH dom0 - it is
currently forced to XS_LOCAL.  With Hyperlaunch booting dom0 and a
xenstore stubdom, dom0 can be handled as a regular XS_HVM following the
late init path.

Ideally we'd drop the use of xen_initial_domain() and just check for the
event channel instead.  However, ARM has a xen,enhanced no-xenstore
mode, where the event channel and PFN would both be 0.  Retain the
xen_initial_domain() check, and use that for an additional check when
the event channel is 0.

Check the full 64bit HVM_PARAM_STORE_EVTCHN value to catch the off
chance that high bits are set for the 32bit event channel.

Signed-off-by: Jason Andryuk 
Change-Id: I5506da42e4c6b8e85079fefb2f193c8de17c7437
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250506204456.5220-1-jason.andryuk@amd.com>

xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands it

2025-05-07T13:27:42+00:00

Xen swiotlb support was missed when the patch set starting with
4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from
ARCH_DMA_MINALIGN") was merged.

When running Xen on iMX8QXP, a SoC without IOMMU, the effect was that USB
transfers ended up corrupted when there was more than one URB inflight at
the same time.

Add a call to dma_kmalloc_needs_bounce() to make sure that allocations too
small for DMA get bounced via swiotlb.

Closes: https://lore.kernel.org/linux-usb/ab2776f0-b838-4cf6-a12a-c208eb6aad59@actia.se/
Fixes: 4ab5f8ec7d71 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN")
Cc: stable@kernel.org # v6.5+
Signed-off-by: John Ernberg 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Juergen Gross 
Message-ID: <20250502114043.1968976-2-john.ernberg@actia.se>

x86/xen: fix balloon target initialization for PVH dom0

2025-04-07T09:24:12+00:00

PVH dom0 re-uses logic from PV dom0, in which RAM ranges not assigned to
dom0 are re-used as scratch memory to map foreign and grant pages.  Such
logic relies on reporting those unpopulated ranges as RAM to Linux, and
mark them as reserved.  This way Linux creates the underlying page
structures required for metadata management.

Such approach works fine on PV because the initial balloon target is
calculated using specific Xen data, that doesn't take into account the
memory type changes described above.  However on HVM and PVH the initial
balloon target is calculated using get_num_physpages(), and that function
does take into account the unpopulated RAM regions used as scratch space
for remote domain mappings.

This leads to PVH dom0 having an incorrect initial balloon target, which
causes malfunction (excessive memory freeing) of the balloon driver if the
dom0 memory target is later adjusted from the toolstack.

Fix this by using xen_released_pages to account for any pages that are part
of the memory map, but are already unpopulated when the balloon driver is
initialized.  This accounts for any regions used for scratch remote
mappings.  Note on x86 xen_released_pages definition is moved to
enlighten.c so it's uniformly available for all Xen-enabled builds.

Take the opportunity to unify PV with PVH/HVM guests regarding the usage of
get_num_physpages(), as that avoids having to add different logic for PV vs
PVH in both balloon_add_regions() and arch_xen_unpopulated_init().

Much like a6aa4eb994ee, the code in this changeset should have been part of
38620fc4e893.

Fixes: a6aa4eb994ee ('xen/x86: add extra pages to unpopulated-alloc if available')
Signed-off-by: Roger Pau Monné 
Reviewed-by: Juergen Gross 
Cc: stable@vger.kernel.org
Signed-off-by: Juergen Gross 
Message-ID: <20250407082838.65495-1-roger.pau@citrix.com>

xen: Change xen-acpi-processor dom0 dependency

2025-04-07T09:22:40+00:00

xen-acpi-processor functions under a PVH dom0 with only a
xen_initial_domain() runtime check.  Change the Kconfig dependency from
PV dom0 to generic dom0 to reflect that.

Suggested-by: Jan Beulich 
Signed-off-by: Jason Andryuk 
Reviewed-by: Juergen Gross 
Tested-by: Jan Beulich 
Signed-off-by: Juergen Gross 
Message-ID: <20250331172913.51240-1-jason.andryuk@amd.com>

xenbus: add module description

2025-04-07T06:33:53+00:00

Modules without a description now cause a warning:

WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/xen/xenbus/xenbus_probe_frontend.o

Signed-off-by: Arnd Bergmann 
Reviewed-by: Juergen Gross 
Signed-off-by: Juergen Gross 
Message-ID: <20250328113302.2632353-1-arnd@kernel.org>