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

drivers/xen/xenbus: remove quirk for Xen 3.x

2025-08-20T13:47:43+00:00

The kernel is not supported to run as a Xen guest on Xen versions
older than 4.0.

Remove xen_strict_xenbus_quirk() which is testing the Xen version to be
at least 4.0.

Acked-by: Stefano Stabellini 
Reviewed-by: Jason Andryuk 
Signed-off-by: Juergen Gross 
Message-ID: <20250815074052.13792-1-jgross@suse.com>

xen/gntdev: remove struct gntdev_copy_batch from stack

2025-07-14T15:10:09+00:00

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>

xen: fix UAF in dmabuf_exp_from_pages()

2025-07-14T08:12:07+00:00

[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

xen: Remove some deadcode (x)

2025-07-14T07:55:52+00:00

Remove three uncalled functions:

  xenbus_mkdir() was added in 2007 by
commit 4bac07c993d0 ("xen: add the Xenbus sysfs and virtual device hotplug
driver")
but has remained unused.

  xen_get_runstate_snapshot() last use was removed in 2016 by
commit 6ba286ad8457 ("xen: support runqueue steal time on xen")
which replaces the use by the _cpu version.

  xen_resume_notifier_unregister() last use was removed in 2017 by
commit 1914f0cd203c ("xen/acpi: upload PM state from init-domain to Xen")

Remove them.

Signed-off-by: "Dr. David Alan Gilbert" 
Reviewed-by: Juergen Gross 
Signed-off-by: Juergen Gross 
Message-ID: <20250713132625.164728-1-linux@treblig.org>

xen-pciback: Replace scnprintf() with sysfs_emit_at()

2025-07-14T07:35:42+00:00

This is the third revision (v3) of this patch series.
No changes since v2—only adding Reviewed-by lines.

Reviewed-by: Juergen Gross 
Signed-off-by: Ryan Chung 
Signed-off-by: Juergen Gross 
Message-ID: <20250708001444.86155-1-seokwoo.chung130@gmail.com>

xen/xenbus: fix W=1 build warning in xenbus_va_dev_error function

2025-07-14T07:34:54+00:00

This patch fixes a W=1 format-string warning reported by GCC 12.3.0
by annotating xenbus_switch_fatal() and xenbus_va_dev_error()
with the __printf attribute. The attribute enables compile-time
validation of printf-style format strings in these functions.

The original warning trace:
drivers/xen/xenbus/xenbus_client.c:304:9: warning: function 'xenbus_va_dev_error' might be
a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format]

Signed-off-by: Peng Jiang 
Reviewed-by: Juergen Gross 
Message-ID: <20250620084104786r5xoR16_AmYZMJLnno3_Q@zte.com.cn>
Signed-off-by: Juergen Gross

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>