* Re: [PATCH v5 2/5] vhost/vsock: suppress EHOSTUNREACH fast-fail during CPR pause
From: Stefano Garzarella @ 2026-07-22 9:14 UTC (permalink / raw)
To: Andrey Drobyshev
Cc: linux-kernel, kvm, virtualization, netdev, mst, stefanha,
dongli.zhang, maciej.szmigiero, bchaney, mark.kanda, ptikhomirov,
den
In-Reply-To: <20260720102241.371610-3-andrey.drobyshev@virtuozzo.com>
On Mon, Jul 20, 2026 at 01:22:38PM +0300, Andrey Drobyshev wrote:
>Earlier commit bb26ed5f3a8b ("vhost/vsock: Refuse the connection
>immediately when guest isn't ready") added a fast-fail in
>vhost_transport_send_pkt(). It rejects every host send with -EHOSTUNREACH
>until the destination calls SET_RUNNING(1). The fast-fail condition checks
>whether device's backends are dropped, and if they're, the guest is
>considered to be not ready.
>
>However, there might be other reasons for backends to be nulled. In
>particular, when QEMU is performing CPR (checkpoint-restore) migration,
>device ownership is being RESET and SET again, which leads to backends
>drop and reattach. If we end up connecting during this window, an
>AF_VSOCK client gets -EHOSTUNREACH, which is wrong.
>
>Add an 'ever_started' flag which is set once in vhost_vsock_start() and is
>never cleared. The behaviour changes to:
>
> * When device was never started -> flag is unset -> no listener can
> exist yet -> fast-fail;
> * Once the device starts -> flag is set -> we don't fast-fail ->
> we queue and preserve during any later stop / CPR pause.
>
>The VHOST_RESET_OWNER ioctl is implemented in a following patch, and
>without RESET_OWNER the problem we fix here isn't manifesting - thus
>this patch is a preparation to support RESET_OWNER.
>
>Important caveat: after the first start, a connect during any stopped
>window is queued instead of fast-failed. That was the behaviour before
>the patch bb26ed5f3a8b, and we're restoring it now. However we still
>keep the behaviour originally intended by that commit (i.e. fast-fail if
>there's no real listener yet) while fixing the CPR path.
>
>Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
>Signed-off-by: Denis V. Lunev <den@openvz.org>
>Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
>Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
>---
> drivers/vhost/vsock.c | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
^ permalink raw reply
* Re: [PATCH v5 3/5] vhost/vsock: re-scan TX virtqueue on device start
From: Stefano Garzarella @ 2026-07-22 9:14 UTC (permalink / raw)
To: Andrey Drobyshev
Cc: linux-kernel, kvm, virtualization, netdev, mst, stefanha,
dongli.zhang, maciej.szmigiero, bchaney, mark.kanda, ptikhomirov,
den
In-Reply-To: <20260720102241.371610-4-andrey.drobyshev@virtuozzo.com>
On Mon, Jul 20, 2026 at 01:22:39PM +0300, Andrey Drobyshev wrote:
>During QEMU CPR live-update (and VHOST_RESET_OWNER in general) the guest
>keeps running while the host drops and later re-attaches vhost backends.
>If the guest adds a buffer to the TX virtqueue (guest->host) and kicks
>while the backend is temporarily NULL (between vhost_vsock_drop_backends()
>and the next vhost_vsock_start()), then the kick is delivered to the
>vhost worker, handle_tx_kick() sees a NULL backend and returns, and the
>kick signal is consumed. The buffer is then left in the ring.
>
>Then upon device start vhost_vsock_start() only re-kicks the RX send
>worker, never the TX VQ, so the buffer is processed only if the guest
>happens to kick again. But if the guest itself is now waiting for data
>from the host, it will never kick TX VQ again, and we end up in a
>deadlock.
>
>The issue itself is pre-existing, but it only manifests during a device
>pause caused by VHOST_RESET_OWNER. Namely, the deadlock is reproduced
>during active host->guest socat data transfer under multiple consecutive
>CPR live-update's.
>
>To fix this, in vhost_vsock_start(), after kicking the RX send worker, also
>queue the TX vq poll so any buffers the guest enqueued while we were paused
>get scanned.
>
>The VHOST_RESET_OWNER ioctl itself is implemented in the following
>patch, thus this patch is a preparation to support VHOST_RESET_OWNER.
>
>Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
>Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
>---
> drivers/vhost/vsock.c | 7 +++++++
> 1 file changed, 7 insertions(+)
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
^ permalink raw reply
* Re: [PATCH RFC v3 0/6] Add Rust virtio bindings and sample device
From: Eugenio Perez Martin @ 2026-07-22 9:31 UTC (permalink / raw)
To: Manos Pitsidianakis
Cc: Michael S. Tsirkin, Manos Pitsidianakis, Peter Hilber,
Stefano Garzarella, Stefan Hajnoczi, Viresh Kumar, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Daniel Almeida, rust-for-linux, Jason Wang, Xuan Zhuo,
virtualization, linux-kernel
In-Reply-To: <tikjvp.3n7sct2j96lcx@pitsidianak.is>
On Wed, Jul 22, 2026 at 11:04 AM Manos Pitsidianakis
<manos@pitsidianak.is> wrote:
>
> Hi Eugenio,
>
> On Wed, 22 Jul 2026 11:49, Eugenio Perez Martin <eperezma@redhat.com> wrote:
> >On Tue, Jul 21, 2026 at 8:24 AM Manos Pitsidianakis
> ><manos@pitsidianak.is> wrote:
> >>
> >> Ping.
> >>
> >> I have a different version of the series WIP with a virtio-rng instead
> >> of virtio-rtc, based on
> >> https://lore.kernel.org/lkml/20260529-rust-hw_random-virtio-rng-v1-0-b3153dd90311@pitsidianak.is/
> >> (which needs a v2 also)
> >>
> >> But since this series hasn't gotten any feedback on the virtio part, I'd
> >> like to ask if there is any before respinning.
> >>
> >> Thanks!
> >>
> >
> >I also think this will be a great addition, but I have very little
> >knowledge of Rust. Is it easy to implement the simplest virtio-net
> >driver using Rust, without CVQ or extra features, so I can test it and
> >hopefully build features on top? Would it help?
>
> I think so, however it would not be upstreamable right away since (I
> think) there are no netdev Rust bindings and abstractions yet. I will
> take a look when I have the time...
>
How about starting even smaller? Just with the virtio-ring processing
that all virtio drivers share.
> (This is something I am also interested in because I'm working on a
> different kind of network device)
>
> You can definitely play with the sample driver included in this series
> however!
>
> Manos
>
>
> >
> >Thanks!
> >
> >> On Sun, 10 May 2026 16:38, Manos Pitsidianakis <manos@pitsidianak.is> wrote:
> >> >Hi all, this RFC series adds Rust bindings for Virtio drivers
> >> >(frontends in virtio parlance).
> >> >
> >> >As a PoC, it also adds a sample virtio-rtc driver which performs
> >> >capability discovery through the virtqueue without registering any clock.
> >> >
> >> >Before I send a cleaned-up non-RFC I would like some initial feedback
> >> >(i.e. is it something the upstream wants?)
> >> >
> >> >This was tested with the rust-vmm vhost-device-rtc device backend that I
> >> >wrote[^0]:
> >> >
> >> >[^0]: https://github.com/rust-vmm/vhost-device/tree/main/vhost-device-rtc
> >> >
> >> >Instructions:
> >> >
> >> > Run the daemon in a separate terminal:
> >> >
> >> > $ cargo run --bin vhost-device-rtc -- -s /tmp/rtc.sock
> >> >
> >> > Then run the VM:
> >> >
> >> > $ qemu-system-aarch64 \
> >> > -machine type=virt,virtualization=off,acpi=on \
> >> > -cpu host \
> >> > -smp 8 \
> >> > -accel kvm \
> >> > -drive if=virtio,format=qcow2,file=./debian-13-nocloud-arm64-daily.qcow2 \
> >> > -device virtio-net-pci,netdev=unet \
> >> > -device virtio-scsi-pci \
> >> > -serial mon:stdio \
> >> > -m 8192 \
> >> > -object memory-backend-memfd,id=mem,size=8G,share=on \
> >> > -numa node,memdev=mem \
> >> > -display none \
> >> > -vga none \
> >> > -kernel /path/to/linux/build/arch/arm64/boot/Image \
> >> > -device vhost-user-test-device,chardev=rtc,id=rtc,virtio-id=17,num_vqs=2,vq_size=1024 \
> >> > -chardev socket,path=/tmp/rtc.sock,id=rtc \
> >> > ...
> >> >
> >> > Example output:
> >> > [ 1.105238] rust_virtio_rtc: Probe Rust virtio driver sample.
> >> > [ 1.105645] rust_virtio_rtc: Found 1 vqs.
> >> > [ 1.136050] rust_virtio_rtc: process_requestq got buf 16 bytes
> >> > [ 1.136125] rust_virtio_rtc: Got response! Ok(RespCfg { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, num_clocks: Le16(3), reserved: [0, 0, 0, 0, 0, 0] })
> >> > [ 1.136701] rust_virtio_rtc: Got response! Ok(RespClockCap { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_type: 3, leap_second_smearing: 0, flags: 0, reserved: [0, 0, 0, 0, 0] })
> >> > [ 1.136724] rust_virtio_rtc virtio0: cannot expose clock 0 (type 3, variant 0, flags 0) to userspace
> >> > [ 1.137259] rust_virtio_rtc: Got response! Ok(RespRead { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_reading: Le64(1777890485031060388) })
> >> > [ 1.137277] rust_virtio_rtc: #0 clock reading = 1777890485031060388
> >> > [ 1.137749] rust_virtio_rtc: Got response! Ok(RespClockCap { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_type: 1, leap_second_smearing: 0, flags: 0, reserved: [0, 0, 0, 0, 0] })
> >> > [ 1.137769] rust_virtio_rtc virtio0: cannot expose clock 1 (type 1, variant 0, flags 0) to userspace
> >> > [ 1.138247] rust_virtio_rtc: Got response! Ok(RespRead { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_reading: Le64(1777890485032086075) })
> >> > [ 1.138264] rust_virtio_rtc: #1 clock reading = 1777890485032086075
> >> > [ 1.138730] rust_virtio_rtc: Got response! Ok(RespClockCap { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_type: 2, leap_second_smearing: 0, flags: 0, reserved: [0, 0, 0, 0, 0] })
> >> > [ 1.138751] rust_virtio_rtc virtio0: cannot expose clock 2 (type 2, variant 0, flags 0) to userspace
> >> > [ 1.139253] rust_virtio_rtc: Got response! Ok(RespRead { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_reading: Le64(338567896865557) })
> >> > [ 1.139270] rust_virtio_rtc: #2 clock reading = 338567896865557
> >> >
> >> >Concerns - Notes - TODOs
> >> >========================
> >> >
> >> >- Virtqueue lifetimes don't neatly apply to Rust as expected, so a lot
> >> > of times we have to go through unsafe pointer dereferences (though
> >> > which are guaranteed by Virtio subsystem to be valid, for example when
> >> > a callback is called with the vq argument). There's a potential for
> >> > misuse and definitely could use better thinking.
> >> >- `struct virtio_device` is not reference-counted like other implemented
> >> > device types in rust/kernel. Maybe we need to change C API first to
> >> > make them reference counted, assuming this doesn't break anything?
> >> >- The sample driver obviously conflicts with the C implementation, so
> >> > this would either need to move out of samples/ or figure out some way
> >> > to handle this in kbuild.
> >> >- kernel::virtio module and its types need a few rustdoc examples that I
> >> > will add in followup series
> >> >- Note that the registration of RTC clocks etc in the sample driver is
> >> > not done, I'm putting it off until I receive some feedback first. The
> >> > sample driver otherwise does send and receive data from the virtqueue
> >> > as a PoC.
> >> >
> >> >PS: No LLMs used so any mistakes and goofs are solely written by me.
> >> >
> >> >Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
> >> >---
> >> >Changes in v3:
> >> >- Removed unused methods from virtio API
> >> >- Clean up how scattergather lists are added to virtqueues by using
> >> > owned SGTables only, and make the API safe(r)
> >> >- Add RAII cleanup for find_vqs return value that calls del_vqs
> >> >- Reset device after remove callback
> >> >- Significantly clean up sample driver as a result of the other cleanups
> >> >- Link to v2: https://lore.kernel.org/r/20260509-rust-virtio-v2-0-c1e30ec2bd21@pitsidianak.is
> >> >
> >> >Changes in v2:
> >> >- Move helper ifdefs to helper file (thanks Alice)
> >> >- Changed CONFIG checks to IS_ENABLED to allow for CONFIG_VIRTIO=m
> >> >- Split all use imports to one item per line according to style guide
> >> >- Fixed wait_for_completion_interruptible*() rustdocs
> >> >- Use Jiffy type alias in wait_for_completion_interruptible_timeout()
> >> >- Pepper and salt #[inline]s wherever appropriate as per style guide
> >> >- Split probe() into probe() and init() to allow cleaning up if init
> >> > fails
> >> >- Remove unnecessary Send and Sync unsafe impls for
> >> > kernel::virtio::Device
> >> >- Remove unnecessary LeSize and BeSize
> >> >- Accept Option<_> for virtqueue callback when creating a VirtqueueInfo
> >> >- Made all vq buffer adding operations unsafe
> >> >- Use AtomicU16 instead of Cell<u16> for sample virtio driver
> >> >- Fix RespHead field types in sample virtio driver
> >> >- Fix response error checking in sample virtio driver
> >> >- Change some device contexts in method signatures
> >> >- Link to v1: https://lore.kernel.org/r/20260505-rust-virtio-v1-0-9563383909e4@pitsidianak.is
> >> >
> >> >---
> >> >Manos Pitsidianakis (6):
> >> > rust/bindings: generate virtio bindings
> >> > rust/helpers: add virtio.c
> >> > rust/kernel/device: return parent at same context
> >> > rust: add virtio module
> >> > rust: impl interruptible waits for Completion
> >> > samples/rust: Add sample virtio-rtc driver [WIP]
> >> >
> >> > MAINTAINERS | 9 +
> >> > rust/bindings/bindings_helper.h | 5 +
> >> > rust/helpers/helpers.c | 1 +
> >> > rust/helpers/virtio.c | 37 ++++
> >> > rust/kernel/device.rs | 2 +-
> >> > rust/kernel/lib.rs | 2 +
> >> > rust/kernel/sync/completion.rs | 42 +++-
> >> > rust/kernel/virtio.rs | 423 ++++++++++++++++++++++++++++++++++++++++
> >> > rust/kernel/virtio/utils.rs | 57 ++++++
> >> > rust/kernel/virtio/virtqueue.rs | 314 +++++++++++++++++++++++++++++
> >> > samples/rust/Kconfig | 15 ++
> >> > samples/rust/Makefile | 1 +
> >> > samples/rust/rust_virtio_rtc.rs | 403 ++++++++++++++++++++++++++++++++++++++
> >> > 13 files changed, 1309 insertions(+), 2 deletions(-)
> >> >---
> >> >base-commit: 028ef9c96e96197026887c0f092424679298aae8
> >> >change-id: 20260504-rust-virtio-8523b01dfdc2
> >> >
> >> >Best regards,
> >> >--
> >> >Manos Pitsidianakis <manos@pitsidianak.is>
> >> >
>
^ permalink raw reply
* Re: [PATCH v5 4/5] vhost: synchronize with RCU readers when freeing workers
From: Stefano Garzarella @ 2026-07-22 9:43 UTC (permalink / raw)
To: Andrey Drobyshev
Cc: linux-kernel, kvm, virtualization, netdev, mst, stefanha,
dongli.zhang, maciej.szmigiero, bchaney, mark.kanda, ptikhomirov,
den
In-Reply-To: <20260720102241.371610-5-andrey.drobyshev@virtuozzo.com>
On Mon, Jul 20, 2026 at 01:22:40PM +0300, Andrey Drobyshev wrote:
>vhost_vq_work_queue() only holds the RCU read lock while it dereferences
>vq->worker and queues work on it. vhost_workers_free() however clears
>the vq->worker pointers and immediately frees the workers, without
>waiting for a grace period. A caller that fetched the worker right
>before the pointer was cleared can therefore still be queueing work on
>it while it is freed. And even when the queueing itself wins the race,
>the work is never run, so its VHOST_WORK_QUEUED bit stays set and all
>future attempts to queue it are silently skipped.
>
>None of the current callers can actually hit this: net and scsi stop
>their virtqueues before the workers are freed, and vsock unhashes the
>device and does synchronize_rcu() of its own in vhost_vsock_dev_release()
>before the workers go away. But the upcoming VHOST_RESET_OWNER support
>in vhost-vsock keeps the device hashed while its workers are freed, so
>the lockless send/cancel paths become able to race with the teardown.
>
>Fix this by clearing the vq->worker pointers, waiting for a grace
>period, and then flushing the workers so any work the last readers
>queued runs before the workers are freed.
>
>Fixes: 228a27cf78af ("vhost: Allow worker switching while work is queueing")
>Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
>Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
>---
> drivers/vhost/vhost.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Sashiko reported some potential issues here:
https://sashiko.dev/#/patchset/20260720102241.371610-1-andrey.drobyshev@virtuozzo.com?part=4
IMO the first one is pre-existing, but not really sure it is a real
issue since happening when the worker/vmm is going to be killed.
The second one also not sure if it's an issue since the sender is not
lockless IIUC.
But, please can you double check them?
Thanks,
Stefano
>
>diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>index 4c525b3e16ea..d6e235c25254 100644
>--- a/drivers/vhost/vhost.c
>+++ b/drivers/vhost/vhost.c
>@@ -729,6 +729,17 @@ static void vhost_workers_free(struct vhost_dev *dev)
>
> for (i = 0; i < dev->nvqs; i++)
> rcu_assign_pointer(dev->vqs[i]->worker, NULL);
>+
>+ /*
>+ * vhost_vq_work_queue() reads vq->worker under rcu_read_lock(), so a
>+ * reader that fetched a worker before we cleared the pointers above
>+ * may still be queueing work on it. Wait for those readers to
>+ * finish, then flush so any work they queued runs (clearing
>+ * VHOST_WORK_QUEUED) before the workers are freed.
>+ */
>+ synchronize_rcu();
>+ vhost_dev_flush(dev);
>+
> /*
> * Free the default worker we created and cleanup workers userspace
> * created but couldn't clean up (it forgot or crashed).
>--
>2.47.1
>
^ permalink raw reply
* Re: [PATCH v5 5/5] vhost/vsock: add VHOST_RESET_OWNER ioctl
From: Stefano Garzarella @ 2026-07-22 9:43 UTC (permalink / raw)
To: Andrey Drobyshev
Cc: linux-kernel, kvm, virtualization, netdev, mst, stefanha,
dongli.zhang, maciej.szmigiero, bchaney, mark.kanda, ptikhomirov,
den
In-Reply-To: <20260720102241.371610-6-andrey.drobyshev@virtuozzo.com>
On Mon, Jul 20, 2026 at 01:22:41PM +0300, Andrey Drobyshev wrote:
>From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
>
>This ioctl is needed for QEMU's CPR (checkpoint-restore) migration of
>the guest with vhost-vsock device. For this to work, we need to reset
>the device ownership on the source side by calling RESET_OWNER, and then
>claim it on the dest side by calling SET_OWNER. We expect not to lose any
>AF_VSOCK connection while this happens.
>
>To that end, unlike the release path, RESET_OWNER keeps the guest CID
>hashed: established connections survive, and host sends issued while
>the device is between owners simply stay on send_pkt_queue until the
>next device start drains them.
>
>Since the device stays reachable through the CID hash, the lockless
>send/cancel paths can race with the worker teardown in
>vhost_workers_free(). The previous commit ("vhost: synchronize with
>RCU readers when freeing workers") makes that safe.
>
>Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
>Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
>---
> drivers/vhost/vsock.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
^ permalink raw reply
* Re: [PATCH RFC v3 0/6] Add Rust virtio bindings and sample device
From: Manos Pitsidianakis @ 2026-07-22 9:55 UTC (permalink / raw)
To: Eugenio Perez Martin
Cc: Michael S. Tsirkin, Manos Pitsidianakis, Peter Hilber,
Stefano Garzarella, Stefan Hajnoczi, Viresh Kumar, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Daniel Almeida, rust-for-linux, Jason Wang, Xuan Zhuo,
virtualization, linux-kernel
In-Reply-To: <CAJaqyWfq=tAdaAzqBtrkKt0fwiQL=SU6QYVydos1q4GhHy-JDg@mail.gmail.com>
On Wed, 22 Jul 2026 12:31, Eugenio Perez Martin <eperezma@redhat.com> wrote:
>On Wed, Jul 22, 2026 at 11:04 AM Manos Pitsidianakis
><manos@pitsidianak.is> wrote:
>>
>> Hi Eugenio,
>>
>> On Wed, 22 Jul 2026 11:49, Eugenio Perez Martin <eperezma@redhat.com> wrote:
>> >On Tue, Jul 21, 2026 at 8:24 AM Manos Pitsidianakis
>> ><manos@pitsidianak.is> wrote:
>> >>
>> >> Ping.
>> >>
>> >> I have a different version of the series WIP with a virtio-rng instead
>> >> of virtio-rtc, based on
>> >> https://lore.kernel.org/lkml/20260529-rust-hw_random-virtio-rng-v1-0-b3153dd90311@pitsidianak.is/
>> >> (which needs a v2 also)
>> >>
>> >> But since this series hasn't gotten any feedback on the virtio part, I'd
>> >> like to ask if there is any before respinning.
>> >>
>> >> Thanks!
>> >>
>> >
>> >I also think this will be a great addition, but I have very little
>> >knowledge of Rust. Is it easy to implement the simplest virtio-net
>> >driver using Rust, without CVQ or extra features, so I can test it and
>> >hopefully build features on top? Would it help?
>>
>> I think so, however it would not be upstreamable right away since (I
>> think) there are no netdev Rust bindings and abstractions yet. I will
>> take a look when I have the time...
>>
>
>How about starting even smaller? Just with the virtio-ring processing
>that all virtio drivers share.
That's already possible with this series (adding inbufs/outbufs). If you
mean a virtio-net that can react to virtio commands but does not do
anything with packets, yes we can do that. I can try setting up a
minimum driver we can work on together if you like.
Manos
>
>> (This is something I am also interested in because I'm working on a
>> different kind of network device)
>>
>> You can definitely play with the sample driver included in this series
>> however!
>>
>> Manos
>>
>>
>> >
>> >Thanks!
>> >
>> >> On Sun, 10 May 2026 16:38, Manos Pitsidianakis <manos@pitsidianak.is> wrote:
>> >> >Hi all, this RFC series adds Rust bindings for Virtio drivers
>> >> >(frontends in virtio parlance).
>> >> >
>> >> >As a PoC, it also adds a sample virtio-rtc driver which performs
>> >> >capability discovery through the virtqueue without registering any clock.
>> >> >
>> >> >Before I send a cleaned-up non-RFC I would like some initial feedback
>> >> >(i.e. is it something the upstream wants?)
>> >> >
>> >> >This was tested with the rust-vmm vhost-device-rtc device backend that I
>> >> >wrote[^0]:
>> >> >
>> >> >[^0]: https://github.com/rust-vmm/vhost-device/tree/main/vhost-device-rtc
>> >> >
>> >> >Instructions:
>> >> >
>> >> > Run the daemon in a separate terminal:
>> >> >
>> >> > $ cargo run --bin vhost-device-rtc -- -s /tmp/rtc.sock
>> >> >
>> >> > Then run the VM:
>> >> >
>> >> > $ qemu-system-aarch64 \
>> >> > -machine type=virt,virtualization=off,acpi=on \
>> >> > -cpu host \
>> >> > -smp 8 \
>> >> > -accel kvm \
>> >> > -drive if=virtio,format=qcow2,file=./debian-13-nocloud-arm64-daily.qcow2 \
>> >> > -device virtio-net-pci,netdev=unet \
>> >> > -device virtio-scsi-pci \
>> >> > -serial mon:stdio \
>> >> > -m 8192 \
>> >> > -object memory-backend-memfd,id=mem,size=8G,share=on \
>> >> > -numa node,memdev=mem \
>> >> > -display none \
>> >> > -vga none \
>> >> > -kernel /path/to/linux/build/arch/arm64/boot/Image \
>> >> > -device vhost-user-test-device,chardev=rtc,id=rtc,virtio-id=17,num_vqs=2,vq_size=1024 \
>> >> > -chardev socket,path=/tmp/rtc.sock,id=rtc \
>> >> > ...
>> >> >
>> >> > Example output:
>> >> > [ 1.105238] rust_virtio_rtc: Probe Rust virtio driver sample.
>> >> > [ 1.105645] rust_virtio_rtc: Found 1 vqs.
>> >> > [ 1.136050] rust_virtio_rtc: process_requestq got buf 16 bytes
>> >> > [ 1.136125] rust_virtio_rtc: Got response! Ok(RespCfg { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, num_clocks: Le16(3), reserved: [0, 0, 0, 0, 0, 0] })
>> >> > [ 1.136701] rust_virtio_rtc: Got response! Ok(RespClockCap { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_type: 3, leap_second_smearing: 0, flags: 0, reserved: [0, 0, 0, 0, 0] })
>> >> > [ 1.136724] rust_virtio_rtc virtio0: cannot expose clock 0 (type 3, variant 0, flags 0) to userspace
>> >> > [ 1.137259] rust_virtio_rtc: Got response! Ok(RespRead { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_reading: Le64(1777890485031060388) })
>> >> > [ 1.137277] rust_virtio_rtc: #0 clock reading = 1777890485031060388
>> >> > [ 1.137749] rust_virtio_rtc: Got response! Ok(RespClockCap { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_type: 1, leap_second_smearing: 0, flags: 0, reserved: [0, 0, 0, 0, 0] })
>> >> > [ 1.137769] rust_virtio_rtc virtio0: cannot expose clock 1 (type 1, variant 0, flags 0) to userspace
>> >> > [ 1.138247] rust_virtio_rtc: Got response! Ok(RespRead { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_reading: Le64(1777890485032086075) })
>> >> > [ 1.138264] rust_virtio_rtc: #1 clock reading = 1777890485032086075
>> >> > [ 1.138730] rust_virtio_rtc: Got response! Ok(RespClockCap { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_type: 2, leap_second_smearing: 0, flags: 0, reserved: [0, 0, 0, 0, 0] })
>> >> > [ 1.138751] rust_virtio_rtc virtio0: cannot expose clock 2 (type 2, variant 0, flags 0) to userspace
>> >> > [ 1.139253] rust_virtio_rtc: Got response! Ok(RespRead { head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_reading: Le64(338567896865557) })
>> >> > [ 1.139270] rust_virtio_rtc: #2 clock reading = 338567896865557
>> >> >
>> >> >Concerns - Notes - TODOs
>> >> >========================
>> >> >
>> >> >- Virtqueue lifetimes don't neatly apply to Rust as expected, so a lot
>> >> > of times we have to go through unsafe pointer dereferences (though
>> >> > which are guaranteed by Virtio subsystem to be valid, for example when
>> >> > a callback is called with the vq argument). There's a potential for
>> >> > misuse and definitely could use better thinking.
>> >> >- `struct virtio_device` is not reference-counted like other implemented
>> >> > device types in rust/kernel. Maybe we need to change C API first to
>> >> > make them reference counted, assuming this doesn't break anything?
>> >> >- The sample driver obviously conflicts with the C implementation, so
>> >> > this would either need to move out of samples/ or figure out some way
>> >> > to handle this in kbuild.
>> >> >- kernel::virtio module and its types need a few rustdoc examples that I
>> >> > will add in followup series
>> >> >- Note that the registration of RTC clocks etc in the sample driver is
>> >> > not done, I'm putting it off until I receive some feedback first. The
>> >> > sample driver otherwise does send and receive data from the virtqueue
>> >> > as a PoC.
>> >> >
>> >> >PS: No LLMs used so any mistakes and goofs are solely written by me.
>> >> >
>> >> >Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
>> >> >---
>> >> >Changes in v3:
>> >> >- Removed unused methods from virtio API
>> >> >- Clean up how scattergather lists are added to virtqueues by using
>> >> > owned SGTables only, and make the API safe(r)
>> >> >- Add RAII cleanup for find_vqs return value that calls del_vqs
>> >> >- Reset device after remove callback
>> >> >- Significantly clean up sample driver as a result of the other cleanups
>> >> >- Link to v2: https://lore.kernel.org/r/20260509-rust-virtio-v2-0-c1e30ec2bd21@pitsidianak.is
>> >> >
>> >> >Changes in v2:
>> >> >- Move helper ifdefs to helper file (thanks Alice)
>> >> >- Changed CONFIG checks to IS_ENABLED to allow for CONFIG_VIRTIO=m
>> >> >- Split all use imports to one item per line according to style guide
>> >> >- Fixed wait_for_completion_interruptible*() rustdocs
>> >> >- Use Jiffy type alias in wait_for_completion_interruptible_timeout()
>> >> >- Pepper and salt #[inline]s wherever appropriate as per style guide
>> >> >- Split probe() into probe() and init() to allow cleaning up if init
>> >> > fails
>> >> >- Remove unnecessary Send and Sync unsafe impls for
>> >> > kernel::virtio::Device
>> >> >- Remove unnecessary LeSize and BeSize
>> >> >- Accept Option<_> for virtqueue callback when creating a VirtqueueInfo
>> >> >- Made all vq buffer adding operations unsafe
>> >> >- Use AtomicU16 instead of Cell<u16> for sample virtio driver
>> >> >- Fix RespHead field types in sample virtio driver
>> >> >- Fix response error checking in sample virtio driver
>> >> >- Change some device contexts in method signatures
>> >> >- Link to v1: https://lore.kernel.org/r/20260505-rust-virtio-v1-0-9563383909e4@pitsidianak.is
>> >> >
>> >> >---
>> >> >Manos Pitsidianakis (6):
>> >> > rust/bindings: generate virtio bindings
>> >> > rust/helpers: add virtio.c
>> >> > rust/kernel/device: return parent at same context
>> >> > rust: add virtio module
>> >> > rust: impl interruptible waits for Completion
>> >> > samples/rust: Add sample virtio-rtc driver [WIP]
>> >> >
>> >> > MAINTAINERS | 9 +
>> >> > rust/bindings/bindings_helper.h | 5 +
>> >> > rust/helpers/helpers.c | 1 +
>> >> > rust/helpers/virtio.c | 37 ++++
>> >> > rust/kernel/device.rs | 2 +-
>> >> > rust/kernel/lib.rs | 2 +
>> >> > rust/kernel/sync/completion.rs | 42 +++-
>> >> > rust/kernel/virtio.rs | 423 ++++++++++++++++++++++++++++++++++++++++
>> >> > rust/kernel/virtio/utils.rs | 57 ++++++
>> >> > rust/kernel/virtio/virtqueue.rs | 314 +++++++++++++++++++++++++++++
>> >> > samples/rust/Kconfig | 15 ++
>> >> > samples/rust/Makefile | 1 +
>> >> > samples/rust/rust_virtio_rtc.rs | 403 ++++++++++++++++++++++++++++++++++++++
>> >> > 13 files changed, 1309 insertions(+), 2 deletions(-)
>> >> >---
>> >> >base-commit: 028ef9c96e96197026887c0f092424679298aae8
>> >> >change-id: 20260504-rust-virtio-8523b01dfdc2
>> >> >
>> >> >Best regards,
>> >> >--
>> >> >Manos Pitsidianakis <manos@pitsidianak.is>
>> >> >
>>
>
^ permalink raw reply
* Re: [PATCH v8 10/11] virt/steal_governor: Implement steal_governor policy loop
From: Shrikanth Hegde @ 2026-07-22 10:27 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, mingo, peterz, juri.lelli, vincent.guittot,
yury.norov, kprateek.nayak, iii, corbet, tglx, gregkh, pbonzini,
seanjc, vschneid, huschle, rostedt, dietmar.eggemann, maddy,
srikar, hdanton, chleroy, vineeth, frederic, arighi, pauld,
christian.loehle, tj, tommaso.cucinotta, maz, rafael, rdunlap,
kernellwp, linux-doc, jgross, virtualization
In-Reply-To: <amBztSFLg2X72P2N@yury>
On 7/22/26 1:09 PM, Yury Norov wrote:
> On Wed, Jul 22, 2026 at 12:44:03PM +0530, Shrikanth Hegde wrote:
>> Hi Yury.
>
> ...
>
>>>> + schedule_delayed_work(&sg_core_ctx.work,
>>>> + msecs_to_jiffies(sg_core_ctx.interval_ms));
>>>
>>> If you need jiffies, why don't you have them in the structure, instead of
>>> milliseconds?
>>>
>>> schedule_delayed_work(&sg_core_ctx.work, sg_core_ctx.delay);
>>>
>>
>> I would prefer milliseconds as jiffies is very difficult for users to understand.
>> It depends on HZ value and one has to query from configs.
>>
>> HZ can very from 100 to 1000 today. Again I will have to play tricks to schedule
>> the governor at fixed intervals.
>>
>> So i think it is better to use milliseconds here.
>> Correct me if i am not making sense.
>
>
> User provides milliseconds, then in init() you convert them into
> jiffies and save in sg.delay. That's it.
Ah ok. That's simpler. Will add a delay filed to the struct.
^ permalink raw reply
* Re: [RFC PATCH 0/4] virtio: SQ/CQ doorbell polling for vhost-scsi
From: rom.wang @ 2026-07-22 11:00 UTC (permalink / raw)
To: mst, jasowangio, eperezma
Cc: virtualization, linux-kernel, linux-scsi, kvm, Yufeng Wang
In-Reply-To: <CAJaqyWe_nhVOvfA03So_edVO_+1UeHCC6RGnHRQB9dq7CWS4LQ@mail.gmail.com>
From: Yufeng Wang <wangyufeng@kylinos.cn>
Thank you for the detailed feedback. We've completed benchmark
testing comparing the existing notification mechanisms against the
proposed SQ/CQ polling. The results are informative.
Test Modes Explained
--------------------
To answer your second question with data, we tested four modes:
1. **baseline**: Default vhost-scsi with event_idx auto-negotiated.
I/O engine: libaio. Submission uses MMIO kick (VM exit), completion
uses MSI-X interrupt (VM exit). The guest driver dynamically toggles
NO_NOTIFY/NO_INTERRUPT during completion processing, but these are
short windows — most I/O still incurs VM exits on both paths.
2. **poll-queue**: This mode combines the existing notification features
you mentioned:
- VIRTIO_RING_F_EVENT_IDX: auto-negotiated (same as baseline)
- VIRTQ_AVAIL_F_NO_INTERRUPT: effectively permanent — poll queue
VQs have callback=NULL and no MSI-X vector, so the guest never
receives completion interrupts regardless of the flag state
- VIRTQ_USED_F_NO_NOTIFY: vhost dynamically toggles this during
active processing (vhost_disable_notify/enable_notify)
- VIRTIO_F_NOTIFICATION_DATA: negotiated but vhost kernel does not
process notification data, so no practical effect
Implemented via virtio-scsi poll queues (virtscsi_poll_queues=16,
callback=NULL, no MSI-X vector) + io_uring IOPOLL mode (--hipri).
blk-mq polls the used ring for completions via virtscsi_mq_poll().
This eliminates completion-side VM exits. However, submission still
uses MMIO kick (VM exit). Note: libaio cannot use this mode because
aio.c strips IOCB_HIPRI ("no one is going to poll for this I/O").
3. **sqcq-poll**: The proposed SQ/CQ doorbell polling (this RFC) with
libaio. Guest writes sq->idx instead of MMIO kick (no VM exit).
Guest poll thread checks used ring via more_used() (no interrupt).
NEED_WAKEUP protocol enables adaptive sleep when idle. Eliminates
VM exits on BOTH submission and completion paths.
4. **sqcq-uring**: Same SQ/CQ polling but with io_uring + --hipri.
Included to isolate the I/O engine variable from the polling
mechanism.
Results
-------
Test configuration:
x86_64: Intel Xeon E5-2680 v4 @ 2.40GHz, 16 vCPUs
NVMe SAMSUNG MZ1LB960HAJQ-000MV (960GB)
arm64: Kunpeng 920 (2.6GHz), 16 vCPUs
NVMe INTEL SSDPED1K375GA (375GB)
Backend: vhost-scsi with TCM loopback to NVMe
arm64 IOPS (best of 3 runs, fio 4K random I/O):
Test baseline poll-queue sqcq-poll sqcq-uring
───────────── ──────── ────────── ───────── ──────────
randread QD1 23,751 29,892 29,680 26,427
randread QD32 NJ1 93,221 162,849 * 84,967 70,271
randread QD32 NJ4 184,939 186,859 340,780 235,310
randread QD32 NJ8 190,562 188,382 520,946 518,197
randwrite QD1 24,131 — 25,520 25,485
randwrite QD32 NJ1 84,725 — 70,652 68,518
randwrite QD32 NJ4 204,745 — 323,449 312,204
randwrite QD32 NJ8 193,802 — 522,322 516,448
* poll-queue NJ1 read shows high IOPS but hangs at NJ≥4 (see below)
x86_64 IOPS (best of 3 runs):
Test baseline poll-queue sqcq-poll sqcq-uring
───────────── ──────── ────────── ───────── ──────────
randread QD1 8,316 9,022 9,533 9,489
randread QD32 NJ1 124,909 146,744 165,761 165,929
randread QD32 NJ4 305,951 332,139 378,305 379,546
randread QD32 NJ8 344,223 356,328 374,932 374,976
randwrite QD1 20,106 24,464 27,265 27,768
randwrite QD32 NJ1 131,836 153,203 162,145 161,402
randwrite QD32 NJ4 232,908 234,559 232,976 231,336
randwrite QD32 NJ8 231,242 229,858 231,828 231,465
Key Findings
------------
1. **poll-queue excels at NJ=1 (arm64)**: On arm64 4K randread QD32
NJ1, poll-queue achieved 163K IOPS — significantly higher than
baseline (93K, +75%) and SQ/CQ polling (85K). io_uring IOPOLL
mode is very efficient for single-queue workloads because the
submitting task polls for completion directly, avoiding both
interrupt latency and poll thread scheduling overhead.
2. **SQ/CQ dramatically outperforms poll-queue at NJ≥4 (arm64)**:
At 4K randread QD32, poll-queue and SQ/CQ diverge sharply:
- NJ4: poll-queue 187K vs SQ/CQ 341K (+82% over poll-queue)
- NJ8: poll-queue 188K vs SQ/CQ 521K (+177% over poll-queue)
SQ/CQ also outperforms baseline by +84% (NJ4) and +173% (NJ8).
3. **libaio incompatibility**: The existing poll queue mechanism
requires io_uring IOPOLL mode. libaio explicitly strips IOCB_HIPRI
(fs/aio.c: "no one is going to poll for this I/O"), so poll queues
are inaccessible to libaio users. SQ/CQ works with any I/O engine
because the poll thread is independent of the submitting task.
Development Insights
--------------------
Beyond eliminating VM exits, two engineering decisions were critical
to achieving the performance shown above:
1. **TCM completion CPU steering**: Our initial goal was 5-10% IOPS
improvement at 4K random I/O QD1 NJ1. After implementing the basic
polling and NEED_WAKEUP protocol, this target was not met. The
bottleneck was that TCM completions were being scheduled on the same
CPU as the busy poll thread, starving the completion workqueue. We
added vhost_sqcq_pick_completion_cpu() to steer TCM completions to
a free CPU (avoiding busy poll cores), with fallback to next-CPU
when all cores are occupied. This closed the gap and achieved the
QD1 target.
2. **Adaptive idle policy with EMA**: After QD1 targets were met,
we tested higher concurrency (QD32 NJ4/NJ8) and found that
aggressive polling caused performance degradation under
multi-queue workloads — likely due to the poll thread consuming
excessive CPU cycles that competing vCPUs needed. We solved this
by implementing an EMA-based adaptive spin budget: the poll thread
spins within a time window derived from recent I/O latency, then
yields. Combined with the NEED_WAKEUP protocol, this allows the
poll thread to busy-spin when active but sleep when idle, avoiding
CPU contention with other vCPUs.
On the vDPA Question
--------------------
The generic vDPA device approach you suggested is indeed a better
direction. The QEMU-side zero-code advantage (leveraging existing
vdpa-dev.c) is very attractive. Our concern is that vhost-scsi's
TCM integration (SCSI CDB, ALUA, persistent reservations) would
need to be wrapped as a vDPA backend. This feels like a 0-to-1
engineering effort, and we're uncertain about the actual scope of
work involved. If there are additional guidelines or examples
available, we'd be very willing to explore this direction.
One More Thing: SQ/CQ + poll-queue Combined
--------------------------------------------
During arm64 testing, we accidentally ran the poll-queue benchmark
(--hipri, io_uring, virtscsi_poll_queues=16) on a kernel that also
had VIRTIO_F_SQCQ_POLL negotiated. This "poll-sqcq" mode combines
both mechanisms simultaneously:
- Submission: SQ/CQ doorbell (sq->idx write, no VM exit)
- Completion: both SQ/CQ poll thread AND blk-mq poll via io_uring
The results were surprisingly strong (arm64, 4K random I/O):
Test baseline poll-queue poll-sqcq sqcq-poll
───────────── ──────── ────────── ───────── ─────────
randread QD1 23,751 29,892 41,683 29,680
randread QD32 NJ1 93,221 162,849 193,029 84,967
randread QD32 NJ4 184,939 186,859 585,445 340,780
randread QD32 NJ8 190,562 188,382 560,727 520,946
randwrite QD1 24,131 — 38,591 25,520
randwrite QD32 NJ1 84,725 — 187,421 70,652
randwrite QD32 NJ4 204,745 — 598,419 323,449
randwrite QD32 NJ8 193,802 — 569,890 522,322
poll-sqcq outperforms both individual mechanisms across all test
cases. We haven't fully analyzed why, but suspect the combination
benefits from:
- SQ/CQ eliminating submission VM exits
- io_uring IOPOLL providing low-latency completion detection via
blk-mq (directly in submitting task context)
- SQ/CQ poll thread as a secondary completion poller covering VQs
that blk-mq doesn't reach
This is preliminary and accidental data, but we think it's worth
sharing as it suggests the two mechanisms are complementary rather
than mutually exclusive.
Benchmark scripts and raw fio JSON data are available and can be
sent as a follow-up upon request.
Best regards,
Yufeng
Signed-off-by: Yufeng Wang <wangyufeng@kylinos.cn>
^ permalink raw reply
* Re: [PATCH v2 01/13] mm: introduce vma_flags_can_grow() and vma_can_grow()
From: Vlastimil Babka (SUSE) @ 2026-07-22 13:26 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-1-0fa2357d5431@kernel.org>
On 7/11/26 20:44, Lorenzo Stoakes wrote:
> These test whether the VMA has stack semantics, i.e. is able to grow
> upwards or downwards depending on the architecture.
>
> In order to account for arches which do not support upward-growing stacks,
> introduce VMA_GROWSUP whose definition depends on the architecture
> supporting it, and use vma_flags_test_single_mask() in vma_flags_can_grow()
> to account for this.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 02/13] mm/vma: update do_mmap() to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 13:33 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-2-0fa2357d5431@kernel.org>
On 7/11/26 20:44, Lorenzo Stoakes wrote:
> The core do_mmap() function accepts a vm_flags_t parameter which it then
> manipulates before passing to mmap_region() to do the heavy lifting of the
> memory mapping.
>
> Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all
> the logic within do_mmap() to manipulate this instead.
>
> This is as part of the ongoing effort to convert VMA flags from a system
> word size to a bitmap type which allows us to unrestrict the number of VMA
> flags, as well as gain control over how VMA flag manipulation occurs.
>
> We do not cascade these changes to all functions which accept vm_flags_t,
> but rather use vma_flags_to_legacy() where necessary, specifically
> deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and
> __get_unmapped_area() to vma_flags_t.
>
> Also utilise the new vma_flags_can_grow() predicate which correctly handles
> the case of architectures without upward growing stacks.
>
> As part of this change, introduce VMA_SHADOW_STACK so we can correctly
> handle the case of the shadow stack not being defined.
>
> No functional change intended.
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 03/13] mm: convert __get_unmapped_area() to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:17 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-3-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Update __get_unmapped_area() to be parameterised by vma_flags_t rather than
> vm_flags_t as part of the effort to move VMA flags from a system word to a
> bitmap.
>
> We cascade the changes up to arch_get_unmapped_area_topdown() and
> arch_get_unmapped_area(), where, for now, we use vma_flags_to_legacy() in
> order to propagate the VMA flags.
>
> No functional change intended.
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 04/13] mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:19 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-4-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> As part of the changes converting VMA flags from a system word size to a
> bitmap, extend this change to generic_get_unmapped_area() and
> generic_get_unmapped_area_topdown(), which also allows us to convert
> stack_guard_placement() as well.
>
> We retain arch_get_unmapped_area() and arch_get_unmapped_area_topdown()
> as-is for now, using legacy_to_vma_flags() as necessary to do so.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 05/13] mm: prefer mm->def_vma_flags in mm logic
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:31 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-5-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Currently mm->def_flags (of type vm_flags_t) is union'd with
> mm->def_vma_flags (of type vma_flags_t).
>
> As part of the effort to convert vm_flags_t usage to vma_flags_t (in order
> to no longer be arbitrarily limited to a system word size for VMA flags),
> prefer mm->def_vma_flags to mm->def_flags throughout the mm logic.
>
> We update dump_mm() to use the %*pb format which means we make no
> assumption about the number of VMA flag bits on output when outputting
> default VMA flags.
>
> No functional change intended.
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/debug.c | 5 +++--
> mm/mlock.c | 13 +++++++------
> mm/mmap.c | 11 ++++++-----
> mm/vma.c | 2 +-
> 4 files changed, 17 insertions(+), 14 deletions(-)
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 06/13] mm/vma: convert vm_pgprot_modify() to use vma_flags_t and rename
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:34 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-6-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Update vm_pgprot_modify() to use the new VMA flags type vma_flags_t, and
> rename to vma_pgprot_modify() accordingly.
>
> This is part of the ongoing work to convert vm_flags_t to vma_flags_t, in
> order to eliminate the arbitrary limit of the number of bits in a system
> word on available VMA flags.
>
> Update VMA userland tests accordingly, updating vma_set_page_prot() to no
> longer inline vma_pgprot_modify(), rather we can simply define
> vma_pgprot_modify() as a static inline function and the tests will pick it
> up from vma.h.
>
> No functional change intended.
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 07/13] mm/vma: rename vma_get_page_prot to vma_flags_to_page_prot
From: Vlastimil Babka (SUSE) @ 2026-07-22 14:36 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-rockchip, linux-tegra,
virtualization, intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-7-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Having vma_get_page_prot() refer to VMA flags and vma_set_page_prot() refer
> to a VMA is confusing.
>
> Rename vma_get_page_prot() to vma_flags_to_page_prot() to resolve this
> confusion.
>
> No functional change intended.
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH] vhost-scsi: fix T10-PI lifecycle hard BUG after endpoint
From: Stefan Hajnoczi @ 2026-07-22 15:14 UTC (permalink / raw)
To: Jia Jia
Cc: mst, jasowangio, michael.christie, pbonzini, stefanha, eperezma,
virtualization, linux-kernel
In-Reply-To: <20260722063609.1546421-1-physicalmtea@gmail.com>
On Wed, Jul 22, 2026 at 2:40 AM Jia Jia <physicalmtea@gmail.com> wrote:
>
> vhost_scsi_setup_vq_cmds() runs only from VHOST_SCSI_SET_ENDPOINT and
> allocates each command's protection scatterlist array (prot_sgl) only
> when VIRTIO_SCSI_F_T10_PI is already set at that moment. Command pools
> are not rebuilt later. vhost_scsi_set_features() may still flip that
> bit after the endpoint is live: it updates acked_features and returns
> success without reallocating prot_sgl.
>
> That is a feature-versus-resource lifetime mismatch. The broken order
> is:
>
> VHOST_SET_FEATURES(0)
> VHOST_SCSI_SET_ENDPOINT
> setup_vq_cmds() sees no T10-PI -> prot_sgl stays NULL
> VHOST_SET_FEATURES(VIRTIO_SCSI_F_T10_PI)
> only acked_features changes; command resources stay as above
VIRTIO_SCSI_F_T10_PI is defined in the VIRTIO spec. VIRTIO feature
bits do not change once negotiated. The device must be reset in order
to set the feature bits again.
VHOST_F_LOG_ALL is a vhost-specific feature bit that is not covered by
the VIRTIO spec and it can be changed at runtime. It is an exception.
Please generalize this fix to only allow VHOST_F_LOG_ALL to be changed
at runtime. Rather than protecting VIRTIO_SCSI_F_T10_PI specifically,
attempts to change feature bits other than VHOST_F_LOG_ALL once the
device is operational must be rejected.
Perhaps other vhost device implementations have the same issue?
Thanks,
Stefan
> submit a T10-PI WRITE with a 129-page protection payload
>
> The I/O path then follows the new feature bit while using the old
> command objects. vhost_scsi_mapal() (static, inlined into
> vhost_scsi_handle_vq() here) does:
>
> sg_alloc_table_chained(table, 129, first_chunk=NULL,
> nents_first_chunk=inline_sg_cnt)
>
> With first_chunk NULL, __sg_alloc_table() sets curr_max_ents from
> nents_first_chunk and calls sg_pool_alloc(129). sg_pool_index() then
> hits:
>
> BUG_ON(nents > SG_CHUNK_SIZE); /* 129 > 128 */
>
> The kernel reported the following call trace and register state:
>
> Call Trace:
> <TASK>
> ? __sg_alloc_table+0x1d8/0x250
> ? __pfx_vhost_run_work_list+0x10/0x10 [vhost]
> sg_alloc_table_chained+0x59/0xf0
> ? __pfx_sg_pool_alloc+0x10/0x10
> ? vhost_scsi_calc_sgls.constprop.0+0x43/0x60 [vhost_scsi]
> vhost_scsi_handle_vq+0xf02/0x1700 [vhost_scsi]
> ? __pfx_vhost_scsi_handle_vq+0x10/0x10 [vhost_scsi]
> vhost_scsi_handle_kick+0x37/0x50 [vhost_scsi]
> vhost_run_work_list+0x8e/0xd0 [vhost]
> vhost_task_fn+0xe1/0x210
> ret_from_fork+0x348/0x540
> </TASK>
>
> RIP: 0010:0x4
> CR2: 0000000000000004
> RSP: 0018:ffffc90000dbf940 EFLAGS: 00010202
> RAX: ffffffff82396810 RBX: ffff88811dc28b80 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000081
>
> The host worker dies and the machine stops accepting network service
> until reset. The missing object is prot_sgl after a post-endpoint
> T10-PI enable introduced by commit bf2d650391be ("vhost-scsi: Allocate
> T10 PI structs only when enabled").
>
> I also checked the other feature bits handled around endpoint setup.
> Only T10-PI allocates this endpoint-time per-command resource and does
> not rebuild it on a later SET_FEATURES. LOG_ALL uses lazy tvc_log and
> already tears log storage down when cleared; HOTPLUG does not allocate
> prot_sgl. So the chosen fix is to refuse T10-PI enable/disable while
> an endpoint is active, rather than adding a second rebuild path in
> set_features().
>
> Return -EBUSY if vs->vs_tpg is set and the T10-PI bit would change.
> Userspace must CLEAR_ENDPOINT, SET_FEATURES, then SET_ENDPOINT again so
> setup_vq_cmds() can allocate protection SGLs when needed. That matches
> the existing "build command resources at endpoint" model.
>
> Fixes: bf2d650391be ("vhost-scsi: Allocate T10 PI structs only when enabled")
> Signed-off-by: Jia Jia <physicalmtea@gmail.com>
> ---
> drivers/vhost/scsi.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 9a1253b9d8c5..000000000000 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -2219,6 +2219,7 @@ static int vhost_scsi_set_features(struct vhost_scsi *vs, u64 features)
> {
> struct vhost_virtqueue *vq;
> bool is_log, was_log;
> + bool is_t10_pi, was_t10_pi;
> int i;
>
> if (features & ~VHOST_SCSI_FEATURES)
> @@ -2234,6 +2235,13 @@ static int vhost_scsi_set_features(struct vhost_scsi *vs, u64 features)
> if (!vs->dev.nvqs)
> goto out;
>
> + is_t10_pi = features & (1ULL << VIRTIO_SCSI_F_T10_PI);
> + was_t10_pi = vhost_has_feature(&vs->vqs[0].vq, VIRTIO_SCSI_F_T10_PI);
> + if (vs->vs_tpg && is_t10_pi != was_t10_pi) {
> + mutex_unlock(&vs->dev.mutex);
> + return -EBUSY;
> + }
> +
> is_log = features & (1 << VHOST_F_LOG_ALL);
> /*
> * All VQs should have same feature.
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 08/13] mm: introduce vma_get_page_prot() and use it
From: Vlastimil Babka (SUSE) @ 2026-07-22 15:42 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound, Jani Nikula
In-Reply-To: <20260711-b4-vma-flags-mm-v2-8-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> There's a large number of vm_get_page_prot(vma->vm_flags) invocations. Make
> life easier by introducing vma_get_page_prot() parameterised by the VMA.
>
> This also makes converting vm_get_page_prot() to vma_flags_t easier.
>
> Also update the userland VMA tests to reflect the change.
>
> No functional change intended.
>
> Acked-by: Zi Yan <ziy@nvidia.com>
> Acked-by: Jani Nikula <jani.nikula@intel.com> # for i915
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> # for DRM
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH] virtio: rtc: time out alarm requests
From: Peter Hilber @ 2026-07-22 15:48 UTC (permalink / raw)
To: GuoHan Zhao
Cc: Michael S. Tsirkin, virtualization, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Alexandre Belloni, linux-kernel
In-Reply-To: <20260714024352.71307-1-zhaoguohan@kylinos.cn>
On Tue, Jul 14, 2026 at 10:43:52AM +0800, GuoHan Zhao wrote:
> RTC class operations run with rtc_device.ops_lock held. The virtio RTC
> alarm requests currently wait without a timeout for the device to return
> their requestq buffers.
>
> On surprise removal, virtio-pci marks the virtqueues broken before
> unregistering the virtio device. If an alarm request is waiting when the
> device stops responding, viortc_remove() blocks in viortc_class_stop()
> while trying to acquire ops_lock. The request cannot complete and device
> removal hangs until the waiting task is signalled.
>
> Use the same 60-second timeout as clock read requests for alarm reads,
> alarm programming, and alarm interrupt enable requests. The existing
> message reference counting keeps a timed-out request alive until a late
> response or device teardown.
>
> Fixes: 9d4f22fd563e ("virtio_rtc: Add RTC class driver")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Thanks for the fix!
Reviewed-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 09/13] mm/vma: update create_init_stack_vma() to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 15:52 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-9-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values in
> create_init_stack_vma().
>
> As part of this change we add VMA_STACK_EARLY and VMA_STACK_INCOMPLETE
> vma_flags_t defines, and slightly rework create_init_stack_vma() for
> clarity.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 10/13] mm/vma: convert miscellaneous uses of VMA flags in core mm
From: Vlastimil Babka (SUSE) @ 2026-07-22 16:04 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-10-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Update various uses of legacy flags in vma.c and mmap.c to the new
> vma_flags_t type, updating comments alongside them to be consistent.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 11/13] mm/mlock: convert mlock code to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 16:07 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-11-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mlock logic.
>
> Additionally update comments to reflect the changes to be consistent.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 12/13] mm/mprotect: convert mprotect code to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 16:09 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-12-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mprotect logic.
>
> Note that we retain the legacy vm_flags_t bit shifting code in
> do_mprotect_pkey(), deferring a vma_flags_t approach to this for the time
> being.
>
> Additionally update comments to reflect the changes to be consistent.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 13/13] mm/mremap: convert mremap code to use vma_flags_t
From: Vlastimil Babka (SUSE) @ 2026-07-22 16:15 UTC (permalink / raw)
To: Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau
Cc: linux-mm, linux-kernel, linux-mips, linux-aio, linux-fsdevel,
linuxppc-dev, dri-devel, etnaviv, linux-samsung-soc, intel-gfx,
linux-arm-msm, freedreno, nouveau, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-13-0fa2357d5431@kernel.org>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mremap logic.
>
> Note that, in replacing vm_flags_clear() (which takes the VMA write lock)
> with vma_clear_flags() and vma_clear_flags_mask() (which do not)
> respectively in unmap_source_vma() and dontunmap_complete(), we do not add
> a VMA write lock to account for htis.
>
> This is because, in both cases, move_vma() is their calling function and
> this has already acquired the VMA write lock on vrm->vma whose VMA flags
> are being cleared.
>
> In the case of vma_set_flags() in unmap_source_vma() we do need to do this
> - as prev and next were not necessarily write locked at this point.
>
> Additionally update comments to reflect the changes to be consistent.
>
> No functional change intended.
>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH] vhost-scsi: flush backend after device ioctls
From: Mike Christie @ 2026-07-22 17:17 UTC (permalink / raw)
To: Jia Jia, Michael S . Tsirkin, Jason Wang
Cc: Paolo Bonzini, Stefan Hajnoci, Eugenio Pérez, virtualization,
kvm, netdev
In-Reply-To: <20260721073639.1532488-1-physicalmtea@gmail.com>
On 7/21/26 2:36 AM, Jia Jia wrote:
> vhost-scsi translates guest response descriptors into userspace iovecs
> at command submission time and later completes those commands
> asynchronously through target-core. Device-wide control operations such
> as VHOST_SET_MEM_TABLE replace the memory table under the device and
> virtqueue mutexes, but historically returned without waiting for
> outstanding SCSI commands that still hold the pre-update response
> iovecs.
>
> After such a replacement, completion may write virtio_scsi_cmd_resp
> through the old host virtual addresses. If the owner has already
> remapped those addresses, the write lands on the wrong userspace object.
> The kernel tree has carried a TODO for this since the 2012 split of
> vhost_dev_ioctl() and vhost_vring_ioctl():
>
> /* TODO: flush backend after dev ioctl. */
>
> A userspace test kept a READ(10) pending, replaced the memory table so
> the response GPA mapped to a new HVA, remapped the old response address
> as a victim page, and then let the command complete. The completion
> wrote the victim page (victim_changed=yes) and left the replacement
> page unchanged; a later TUR updated the new mapping instead. So the
> pending command retained the pre-update response address across
> VHOST_SET_MEM_TABLE.
>
> That same 2012 change deliberately avoided a second backend flush on the
> vring-ioctl path: vring updates already flush where appropriate, and an
> extra heavy flush would hurt when kick or call fds are reconfigured on
> the data path. This fix does not reintroduce that. The default branch
> still routes unknown commands through vhost_dev_ioctl() first; only a
> non-ENOIOCTLCMD result flushes. Vring ops such as SET_VRING_KICK/CALL,
> num, addr, and base return -ENOIOCTLCMD there and fall through to
> vhost_vring_ioctl() without this backend flush.
>
> What vhost_dev_ioctl() actually handles on this path is small:
> VHOST_SET_OWNER, VHOST_SET_MEM_TABLE, VHOST_SET_LOG_BASE,
> VHOST_SET_LOG_FD, and the optional fork-owner ioctls when enabled.
> Flushing after those is fine: they are rare device-wide control ops,
> and SET_OWNER normally runs before any inflight SCSI work. Call
> vhost_scsi_flush() so pre-update worker work and target-core inflight
> commands finish before the ioctl returns. As with the existing net
> pattern, any non-ENOIOCTLCMD result flushes, including failures that
> may have applied a partial update such as VHOST_SET_LOG_BASE.
>
> I later noticed vhost-net and vhost-vsock already use the same device
> versus vring split.
>
> This is a control-plane barrier only. Ordinary submission, completion,
> kick, and call paths are unchanged. The owner is expected to keep
> pre-update mappings valid until the device ioctl returns. Completion
> copies the response and signals from the vhost worker without needing
> further userspace progress, so waiting in this ioctl does not leave the
> owner process stuck on itself.
It's such a long and verbose description. Was it written by AI? Was the
patch also done with AI?
>
> Signed-off-by: Jia Jia <physicalmtea@gmail.com>
> ---
> drivers/vhost/scsi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 9a1253b9d8c5..c3e8f1a0b2d4 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -2424,10 +2424,11 @@ vhost_scsi_ioctl(struct file *f, unsigned int ioctl, unsigned long arg)
> default:
> mutex_lock(&vs->dev.mutex);
> r = vhost_dev_ioctl(&vs->dev, ioctl, argp);
> - /* TODO: flush backend after dev ioctl. */
> if (r == -ENOIOCTLCMD)
> r = vhost_vring_ioctl(&vs->dev, ioctl, argp);
> + else
Is it still possible for userspace to execute the READ/TUR sequence
describe above at this time before the flush?
From the description it sounded like we needed to stop new cmds, flush
running cmds, swap the new mem pointer, then start new commands?
> + vhost_scsi_flush(vs);
> mutex_unlock(&vs->dev.mutex);
> return r;
^ permalink raw reply
* Re: [PATCH v1 2/2] iommu/virtio: Reject short event buffers
From: Will Deacon @ 2026-07-22 21:41 UTC (permalink / raw)
To: weimin xiong
Cc: Jean-Philippe Brucker, Joerg Roedel, Robin Murphy, virtualization,
iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714025914.193580-3-15927021679@163.com>
On Tue, Jul 14, 2026 at 10:59:14AM +0800, weimin xiong wrote:
> From: Xiong Weimin <xiongweimin@kylinos.cn>
>
> viommu_event_handler() only rejects event buffers that are larger than
> struct viommu_event. A short buffer is also invalid, but the handler
> would still read evt->head and, for fault events, the rest of evt->fault.
>
> Require the used length to match the event buffer size before looking at
> the event contents.
>
> Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
> ---
> drivers/iommu/virtio-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index 4c91a82d2..4b7f0dcfa 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -635,7 +635,7 @@ static void viommu_event_handler(struct virtqueue *vq)
> struct viommu_dev *viommu = vq->vdev->priv;
>
> while ((evt = virtqueue_get_buf(vq, &len)) != NULL) {
> - if (len > sizeof(*evt)) {
> + if (len != sizeof(*evt)) {
> dev_err(viommu->dev,
> "invalid event buffer (len %u != %zu)\n",
> len, sizeof(*evt));
See Jean-Phillipe's previous reply to an identical patch:
https://lore.kernel.org/all/6800BE0812AF0897+20260706083148.788991-1-raoxu@uniontech.com/
Will
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox