Re: [PATCH v2 3/6] virtio: virtqueue_ordered_fill - VIRTIO_F_IN_ORDER support

On Thu, May 23, 2024 at 12:30 PM Jonah Palmer wrote: > > > > On 5/22/24 12:07 PM, Eugenio Perez Martin wrote: > > On Mon, May 20, 2024 at 3:01 PM Jonah Palmer > > wrote: > >> > >> Add VIRTIO_F_IN_ORDER feature support for the vi

Re: [PATCH v2 3/6] virtio: virtqueue_ordered_fill - VIRTIO_F_IN_ORDER support

On Mon, May 20, 2024 at 3:01 PM Jonah Palmer wrote: > > Add VIRTIO_F_IN_ORDER feature support for the virtqueue_fill operation. > > The goal of the virtqueue_ordered_fill operation when the > VIRTIO_F_IN_ORDER feature has been negotiated is to search for this > now-used element, set its length,

Re: [PATCH v2 2/6] virtio: virtqueue_pop - VIRTIO_F_IN_ORDER support

On Mon, May 20, 2024 at 3:01 PM Jonah Palmer wrote: > > Add VIRTIO_F_IN_ORDER feature support in virtqueue_split_pop and > virtqueue_packed_pop. > > VirtQueueElements popped from the available/descritpor ring are added to > the VirtQueue's used_elems array in-order and in the same fashion as >

Re: [PATCH v2 1/6] virtio: Add bool to VirtQueueElement

On Mon, May 20, 2024 at 3:01 PM Jonah Palmer wrote: > > Add the boolean 'in_order_filled' member to the VirtQueueElement structure. > The use of this boolean will signify whether the element has been processed > and is ready to be flushed (so long as the element is in-order). This > boolean is

Re: Intention to work on GSoC project

On Mon, May 13, 2024 at 3:49 PM Sahil wrote: > > Hi, > > On Wednesday, May 8, 2024 8:53:12 AM GMT+5:30 Sahil wrote: > > Hi, > > > > On Tuesday, May 7, 2024 12:44:33 PM IST Eugenio Perez Martin wrote: > > > [...] > > > > > > > Shall I s

Re: [RFC 0/2] Identify aliased maps in vdpa SVQ iova_tree

On Mon, May 13, 2024 at 10:28 AM Jason Wang wrote: > > On Mon, May 13, 2024 at 2:28 PM Eugenio Perez Martin > wrote: > > > > On Sat, May 11, 2024 at 6:07 AM Jason Wang wrote: > > > > > > On Fri, May 10, 2024 at 3:16 PM Eugenio Perez Martin > > >

Re: [RFC 0/2] Identify aliased maps in vdpa SVQ iova_tree

On Sat, May 11, 2024 at 6:07 AM Jason Wang wrote: > > On Fri, May 10, 2024 at 3:16 PM Eugenio Perez Martin > wrote: > > > > On Fri, May 10, 2024 at 6:29 AM Jason Wang wrote: > > > > > > On Thu, May 9, 2024 at 3:10 PM Eugenio Perez Martin > > >

Re: [PATCH 4/6] virtio: virtqueue_ordered_flush - VIRTIO_F_IN_ORDER support

On Mon, May 6, 2024 at 5:06 PM Jonah Palmer wrote: > > Add VIRTIO_F_IN_ORDER feature support for virtqueue_flush operations. > > The goal of the virtqueue_flush operation when the VIRTIO_F_IN_ORDER > feature has been negotiated is to write elements to the used/descriptor > ring in-order and then

Re: [RFC 0/2] Identify aliased maps in vdpa SVQ iova_tree

On Fri, May 10, 2024 at 6:29 AM Jason Wang wrote: > > On Thu, May 9, 2024 at 3:10 PM Eugenio Perez Martin > wrote: > > > > On Thu, May 9, 2024 at 8:27 AM Jason Wang wrote: > > > > > > On Thu, May 9, 2024 at 1:16 AM Eugenio Perez Martin > > > wr

Re: [PATCH 3/6] virtio: virtqueue_ordered_fill - VIRTIO_F_IN_ORDER support

On Mon, May 6, 2024 at 5:05 PM Jonah Palmer wrote: > > Add VIRTIO_F_IN_ORDER feature support for virtqueue_fill operations. > > The goal of the virtqueue_fill operation when the VIRTIO_F_IN_ORDER > feature has been negotiated is to search for this now-used element, > set its length, and mark the

Re: [PATCH 2/6] virtio: virtqueue_pop - VIRTIO_F_IN_ORDER support

On Mon, May 6, 2024 at 5:06 PM Jonah Palmer wrote: > > Add VIRTIO_F_IN_ORDER feature support in virtqueue_split_pop and > virtqueue_packed_pop. > > VirtQueueElements popped from the available/descritpor ring are added to > the VirtQueue's used_elems array in-order and in the same fashion as >

Re: [PATCH 1/6] virtio: Add bool to VirtQueueElement

On Mon, May 6, 2024 at 5:06 PM Jonah Palmer wrote: > > Add the boolean 'filled' member to the VirtQueueElement structure. The > use of this boolean will signify if the element has been written to the > used / descriptor ring or not. This boolean is used to support the > VIRTIO_F_IN_ORDER feature.

Re: [RFC 0/2] Identify aliased maps in vdpa SVQ iova_tree

On Thu, May 9, 2024 at 8:27 AM Jason Wang wrote: > > On Thu, May 9, 2024 at 1:16 AM Eugenio Perez Martin > wrote: > > > > On Wed, May 8, 2024 at 4:29 AM Jason Wang wrote: > > > > > > On Tue, May 7, 2024 at 6:57 PM Eugenio Perez Martin > > > wr

Re: [PATCH] hw/virtio: Fix obtain the buffer id from the last descriptor

On Thu, May 9, 2024 at 4:20 AM Wafer wrote: > > > > On Thu, May, 2024 at 2:21 AM Michael S. Tsirkin wrote: > > > > On Wed, May 08, 2024 at 02:56:11PM +0200, Eugenio Perez Martin wrote: > > > On Mon, Apr 22, 2024 at 3:41 AM Wafer wrote: > > > > > &

Re: [PATCH] hw/virtio: Fix obtain the buffer id from the last descriptor

On Thu, May 9, 2024 at 6:32 AM Wafer wrote: > > > > On Wed, May 08, 2024 at 12:01 PM Jason Wang wrote: > > > > On Mon, Apr 22, 2024 at 9:41 AM Wafer wrote: > > > > > > The virtio-1.3 specification > > > writes: > > > 2.8.6 Next

Re: [RFC 0/2] Identify aliased maps in vdpa SVQ iova_tree

On Wed, May 8, 2024 at 4:29 AM Jason Wang wrote: > > On Tue, May 7, 2024 at 6:57 PM Eugenio Perez Martin > wrote: > > > > On Tue, May 7, 2024 at 9:29 AM Jason Wang wrote: > > > > > > On Fri, Apr 12, 2024 at 3:56 PM Eugenio Perez Martin > > > wro

Re: [RFC 1/2] iova_tree: add an id member to DMAMap

On Wed, May 8, 2024 at 2:52 AM Si-Wei Liu wrote: > > > > On 5/1/2024 11:44 PM, Eugenio Perez Martin wrote: > > On Thu, May 2, 2024 at 1:16 AM Si-Wei Liu wrote: > >> > >> > >> On 4/30/2024 10:19 AM, Eugenio Perez Martin wrote: > >&

Re: [PATCH] hw/virtio: Fix obtain the buffer id from the last descriptor

On Mon, Apr 22, 2024 at 3:41 AM Wafer wrote: > > The virtio-1.3 specification > writes: > 2.8.6 Next Flag: Descriptor Chaining > Buffer ID is included in the last descriptor in the list. > > If the feature (_F_INDIRECT_DESC)

Re: [RFC 0/2] Identify aliased maps in vdpa SVQ iova_tree

On Tue, May 7, 2024 at 9:29 AM Jason Wang wrote: > > On Fri, Apr 12, 2024 at 3:56 PM Eugenio Perez Martin > wrote: > > > > On Fri, Apr 12, 2024 at 8:47 AM Jason Wang wrote: > > > > > > On Wed, Apr 10, 2024 at 6:03 PM Eugenio Pérez wrote: > > >

Re: Intention to work on GSoC project

On Mon, May 6, 2024 at 9:00 PM Sahil wrote: > > Hi, > > It's been a while since I last gave an update. Sorry about that. I am ready > to get my hands dirty and start with the implementation. > No worries! > I have gone through the source of linux's drivers/virtio/virtio_ring.c [1], > and >

Re: [RFC 1/2] iova_tree: add an id member to DMAMap

On Thu, May 2, 2024 at 1:16 AM Si-Wei Liu wrote: > > > > On 4/30/2024 10:19 AM, Eugenio Perez Martin wrote: > > On Tue, Apr 30, 2024 at 7:55 AM Si-Wei Liu wrote: > >> > >> > >> On 4/29/2024 1:14 AM, Eugenio Perez Martin wrote: > >&

Re: [RFC 1/2] iova_tree: add an id member to DMAMap

On Thu, May 2, 2024 at 12:09 AM Si-Wei Liu wrote: > > > > On 4/30/2024 11:11 AM, Eugenio Perez Martin wrote: > > On Mon, Apr 29, 2024 at 1:19 PM Jonah Palmer > > wrote: > >> > >> > >> On 4/29/24 4:14 AM, Eugenio Perez Martin wrote: >

Re: [RFC 1/2] iova_tree: add an id member to DMAMap

On Mon, Apr 29, 2024 at 1:19 PM Jonah Palmer wrote: > > > > On 4/29/24 4:14 AM, Eugenio Perez Martin wrote: > > On Thu, Apr 25, 2024 at 7:44 PM Si-Wei Liu wrote: > >> > >> > >> > >> On 4/24/2024 12:33 AM, Eugenio Perez Martin wrote: &g

Re: [RFC 1/2] iova_tree: add an id member to DMAMap

On Tue, Apr 30, 2024 at 7:55 AM Si-Wei Liu wrote: > > > > On 4/29/2024 1:14 AM, Eugenio Perez Martin wrote: > > On Thu, Apr 25, 2024 at 7:44 PM Si-Wei Liu wrote: > >> > >> > >> On 4/24/2024 12:33 AM, Eugenio Perez Martin wrote: > >&g

Re: [RFC 1/2] iova_tree: add an id member to DMAMap

On Thu, Apr 25, 2024 at 7:44 PM Si-Wei Liu wrote: > > > > On 4/24/2024 12:33 AM, Eugenio Perez Martin wrote: > > On Wed, Apr 24, 2024 at 12:21 AM Si-Wei Liu wrote: > >> > >> > >> On 4/22/2024 1:49 AM, Eugenio Perez Martin wrote: > >&

Re: [RFC 1/2] iova_tree: add an id member to DMAMap

On Wed, Apr 24, 2024 at 12:21 AM Si-Wei Liu wrote: > > > > On 4/22/2024 1:49 AM, Eugenio Perez Martin wrote: > > On Sat, Apr 20, 2024 at 1:50 AM Si-Wei Liu wrote: > >> > >> > >> On 4/19/2024 1:29 AM, Eugenio Perez Martin wrote: > >&g

Re: [RFC 1/2] iova_tree: add an id member to DMAMap

On Sat, Apr 20, 2024 at 1:50 AM Si-Wei Liu wrote: > > > > On 4/19/2024 1:29 AM, Eugenio Perez Martin wrote: > > On Thu, Apr 18, 2024 at 10:46 PM Si-Wei Liu wrote: > >> > >> > >> On 4/10/2024 3:03 AM, Eugenio Pérez wrote: > >>> IOVA tre

Re: [RFC 1/2] iova_tree: add an id member to DMAMap

On Thu, Apr 18, 2024 at 10:46 PM Si-Wei Liu wrote: > > > > On 4/10/2024 3:03 AM, Eugenio Pérez wrote: > > IOVA tree is also used to track the mappings of virtio-net shadow > > virtqueue. This mappings may not match with the GPA->HVA ones. > > > > This causes a problem when overlapped regions

Re: Intention to work on GSoC project

On Mon, Apr 15, 2024 at 9:42 PM Sahil wrote: > > Hi, > > Thank you for your reply. > > On Monday, April 15, 2024 2:27:36 PM IST Eugenio Perez Martin wrote: > > [...] > > > I have one question though. One of the options (use case 1 in [1]) > >

Re: Discrepancy between mmap call on DPDK/libvduse and rust vm-memory crate

On Sun, Apr 14, 2024 at 11:02 AM Michael S. Tsirkin wrote: > > On Fri, Apr 12, 2024 at 12:15:40PM +0200, Eugenio Perez Martin wrote: > > Hi! > > > > I'm building a bridge to expose vhost-user devices through VDUSE. The > > code is still immature but I'm able to

Re: Intention to work on GSoC project

On Sun, Apr 14, 2024 at 8:52 PM Sahil wrote: > > Hi, > > On Friday, April 5, 2024 12:36:02 AM IST Sahil wrote: > > [...] > > I'll set up this environment as well. > > I would like to post an update here. I spent the last week > trying to set up the environment as described in the blog [1]. > I

Discrepancy between mmap call on DPDK/libvduse and rust vm-memory crate

Hi! I'm building a bridge to expose vhost-user devices through VDUSE. The code is still immature but I'm able to forward packets using dpdk-l2fwd through VDUSE to VM. I'm now developing exposing virtiofsd, but I've hit an error I'd like to discuss. VDUSE devices can get all the memory regions

Re: [RFC 0/2] Identify aliased maps in vdpa SVQ iova_tree

On Fri, Apr 12, 2024 at 8:47 AM Jason Wang wrote: > > On Wed, Apr 10, 2024 at 6:03 PM Eugenio Pérez wrote: > > > > The guest may have overlapped memory regions, where different GPA leads > > to the same HVA. This causes a problem when overlapped regions > > (different GPA but same translated

Re: [PULL 4/7] hw/virtio: Fix packed virtqueue flush used_idx

On Tue, Apr 9, 2024 at 7:40 PM Michael Tokarev wrote: > > 09.04.2024 10:32, Michael S. Tsirkin wrote: > > From: Wafer > > > > In the event of writing many chains of descriptors, the device must > > write just the id of the last buffer in the descriptor chain, skip > > forward the number of

Re: [PATCH v4] hw/virtio: Fix packed virtqueue flush used_idx

On Sun, Apr 7, 2024 at 3:56 AM Wafer wrote: > Let me suggest a more generic description for the patch: In the event of writing many chains of descriptors, the device must write just the id of the last buffer in the descriptor chain, skip forward the number of descriptors in the chain, and then

Re: [PATCH v3] hw/virtio: Fix packed virtqueue flush used_idx

On Fri, Apr 5, 2024 at 3:20 PM Wafer wrote: > > If a virtio-net device has the VIRTIO_NET_F_MRG_RXBUF feature > but not the VIRTIO_RING_F_INDIRECT_DESC feature, > 'VirtIONetQueue->rx_vq' will use the merge feature > to store data in multiple 'elems'. > The 'num_buffers' in the virtio header

Re: [RFC v2 1/5] virtio: Initialize sequence variables

On Fri, Apr 5, 2024 at 3:59 PM Jonah Palmer wrote: > > > > On 4/4/24 12:33 PM, Eugenio Perez Martin wrote: > > On Thu, Apr 4, 2024 at 4:42 PM Jonah Palmer wrote: > >> > >> > >> > >> On 4/4/24 7:35 AM, Eugenio Perez Martin wrote: > >

Re: [PATCH v2] hw/virtio: Fix packed virtqueue flush used_idx

On Thu, Apr 4, 2024 at 7:03 PM Wafer wrote: > > If a virtio-net device has the VIRTIO_NET_F_MRG_RXBUF feature > but not the VIRTIO_RING_F_INDIRECT_DESC feature, > 'VirtIONetQueue->rx_vq' will use the merge feature > to store data in multiple 'elems'. > The 'num_buffers' in the virtio header

Re: [RFC v2 1/5] virtio: Initialize sequence variables

On Thu, Apr 4, 2024 at 4:42 PM Jonah Palmer wrote: > > > > On 4/4/24 7:35 AM, Eugenio Perez Martin wrote: > > On Wed, Apr 3, 2024 at 6:51 PM Jonah Palmer wrote: > >> > >> > >> > >> On 4/3/24 6:18 AM, Eugenio Perez Martin wrote: > >&

Re: [RFC v2 1/5] virtio: Initialize sequence variables

On Wed, Apr 3, 2024 at 6:51 PM Jonah Palmer wrote: > > > > On 4/3/24 6:18 AM, Eugenio Perez Martin wrote: > > On Thu, Mar 28, 2024 at 5:22 PM Jonah Palmer > > wrote: > >> > >> Initialize sequence variables for VirtQueue and VirtQueueElement > &g

Re: Intention to work on GSoC project

On Wed, Apr 3, 2024 at 4:36 PM Sahil wrote: > > Hi, > > Thank you for the reply. > > On Tuesday, April 2, 2024 5:08:24 PM IST Eugenio Perez Martin wrote: > > [...] > > > > > Q2. > > > > > In the Red Hat article, just below the first li

Re: [RFC v2 1/5] virtio: Initialize sequence variables

On Thu, Mar 28, 2024 at 5:22 PM Jonah Palmer wrote: > > Initialize sequence variables for VirtQueue and VirtQueueElement > structures. A VirtQueue's sequence variables are initialized when a > VirtQueue is being created or reset. A VirtQueueElement's sequence > variable is initialized when a

Re: [PATCH v2 6/7] vdpa: move iova_tree allocation to net_vhost_vdpa_init

On Wed, Apr 3, 2024 at 8:53 AM Si-Wei Liu wrote: > > > > On 4/2/2024 5:01 AM, Eugenio Perez Martin wrote: > > On Tue, Apr 2, 2024 at 8:19 AM Si-Wei Liu wrote: > >> > >> > >> On 2/14/2024 11:11 AM, Eugenio Perez Martin wrote: > >>> On

Re: [PATCH v2 6/7] vdpa: move iova_tree allocation to net_vhost_vdpa_init

On Tue, Apr 2, 2024 at 8:19 AM Si-Wei Liu wrote: > > > > On 2/14/2024 11:11 AM, Eugenio Perez Martin wrote: > > On Wed, Feb 14, 2024 at 7:29 PM Si-Wei Liu wrote: > >> Hi Michael, > >> > >> On 2/13/2024 2:22 AM, Michael S. Tsirkin wrote: > >>

Re: Intention to work on GSoC project

On Tue, Apr 2, 2024 at 6:58 AM Sahil wrote: > > Hi, > > On Monday, April 1, 2024 11:53:11 PM IST daleyoung4...@gmail.com wrote: > > Hi, > > > > On Monday, March 25, 2024 21:20:32 CST Sahil wrote: > > > Q1. > > > Section 2.7.4 of the virtio spec [3] states that in an available > > > descriptor,

Re: [RFC 0/8] virtio,vhost: Add VIRTIO_F_IN_ORDER support

On Tue, Mar 26, 2024 at 5:49 PM Jonah Palmer wrote: > > > > On 3/25/24 4:33 PM, Eugenio Perez Martin wrote: > > On Mon, Mar 25, 2024 at 5:52 PM Jonah Palmer > > wrote: > >> > >> > >> > >> On 3/22/24 7:18 AM, Eugenio Perez Mart

Re: [RFC 0/8] virtio,vhost: Add VIRTIO_F_IN_ORDER support

On Mon, Mar 25, 2024 at 5:52 PM Jonah Palmer wrote: > > > > On 3/22/24 7:18 AM, Eugenio Perez Martin wrote: > > On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer > > wrote: > >> > >> The goal of these patches is to add support to a variety of virtio and &g

Re: [RFC 4/8] virtio: Implement in-order handling for virtio devices

On Mon, Mar 25, 2024 at 6:35 PM Jonah Palmer wrote: > > > > On 3/22/24 6:46 AM, Eugenio Perez Martin wrote: > > On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer > > wrote: > >> > >> Implements in-order handling for most virtio devices using the > >>

Re: [RFC 1/8] virtio: Define InOrderVQElement

On Mon, Mar 25, 2024 at 6:08 PM Jonah Palmer wrote: > > > > On 3/22/24 5:45 AM, Eugenio Perez Martin wrote: > > On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer > > wrote: > >> > >> Define the InOrderVQElement structure for the VIRTIO_F_IN_O

Re: [RFC 0/8] virtio,vhost: Add VIRTIO_F_IN_ORDER support

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > The goal of these patches is to add support to a variety of virtio and > vhost devices for the VIRTIO_F_IN_ORDER transport feature. This feature > indicates that all buffers are used by the device in the same order in > which they were made

Re: [RFC 8/8] virtio: Add VIRTIO_F_IN_ORDER property definition

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > Extend the virtio device property definitions to include the > VIRTIO_F_IN_ORDER feature. > > The default state of this feature is disabled, allowing it to be > explicitly enabled where it's supported. > Acked-by: Eugenio Pérez Thanks! >

Re: [RFC 7/8] vhost/vhost-user: Add VIRTIO_F_IN_ORDER to vhost feature bits

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > Add support for the VIRTIO_F_IN_ORDER feature across a variety of vhost > devices. > > The inclusion of VIRTIO_F_IN_ORDER in the feature bits arrays for these > devices ensures that the backend is capable of offering and providing > support

Re: [RFC 4/8] virtio: Implement in-order handling for virtio devices

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > Implements in-order handling for most virtio devices using the > VIRTIO_F_IN_ORDER transport feature, specifically those who call > virtqueue_push to push their used elements onto the used ring. > > The logic behind this implementation is as

Re: [RFC 1/8] virtio: Define InOrderVQElement

On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer wrote: > > Define the InOrderVQElement structure for the VIRTIO_F_IN_ORDER > transport feature implementation. > > The InOrderVQElement structure is used to encapsulate out-of-order > VirtQueueElement data that was processed by the host. This data >

Re: Intention to work on GSoC project

On Mon, Mar 18, 2024 at 8:47 PM Sahil wrote: > > Hi, > > I was reading the "Virtqueues and virtio ring: How the data travels" > article [1]. There are a few things that I have not understood in the > "avail rings" section. > > Q1. > Step 2 in the "Process to make a buffer available" diagram

Re: Intention to work on GSoC project

On Sat, Mar 16, 2024 at 9:27 PM Sahil wrote: > > Hi, > > Thank you for your reply. > > On Friday, March 15, 2024 4:57:39 PM IST Eugenio Perez Martin wrote: > > [...] > > > Some sections in the above docs were difficult to grasp. For the time > > > b

Re: [PATCH for-9.0 v3] vdpa-dev: Fix initialisation order to restore VDUSE compatibility

On Tue, Mar 19, 2024 at 11:00 AM Kevin Wolf wrote: > > Am 18.03.2024 um 20:27 hat Eugenio Perez Martin geschrieben: > > On Mon, Mar 18, 2024 at 10:02 AM Michael S. Tsirkin wrote: > > > > > > On Mon, Mar 18, 2024 at 12:31:26PM +0800, Jason Wang wrote: > >

Re: [PATCH for-9.0 v3] vdpa-dev: Fix initialisation order to restore VDUSE compatibility

On Mon, Mar 18, 2024 at 10:02 AM Michael S. Tsirkin wrote: > > On Mon, Mar 18, 2024 at 12:31:26PM +0800, Jason Wang wrote: > > On Fri, Mar 15, 2024 at 11:59 PM Kevin Wolf wrote: > > > > > > VDUSE requires that virtqueues are first enabled before the DRIVER_OK > > > status flag is set; with the

Re: [PATCH] vhost-vdpa: check vhost_vdpa_set_vring_ready() return value

On Mon, Mar 18, 2024 at 5:35 AM Jason Wang wrote: > > On Fri, Mar 15, 2024 at 4:23 PM Stefano Garzarella > wrote: > > > > On Thu, Mar 14, 2024 at 11:17:01AM +0800, Jason Wang wrote: > > >On Wed, Feb 7, 2024 at 5:27 PM Stefano Garzarella > > >wrote: > > >> > > >> vhost_vdpa_set_vring_ready()

Re: [PATCH] vhost-vdpa: check vhost_vdpa_set_vring_ready() return value

On Wed, Feb 7, 2024 at 10:27 AM Stefano Garzarella wrote: > > vhost_vdpa_set_vring_ready() could already fail, but if Linux's > patch [1] will be merged, it may fail with more chance if > userspace does not activate virtqueues before DRIVER_OK when > VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK is not

Re: [PATCH v3 for 9.1 1/6] virtio/virtio-pci: Handle extra notification data

On Fri, Mar 15, 2024 at 5:57 PM Jonah Palmer wrote: > > Add support to virtio-pci devices for handling the extra data sent > from the driver to the device when the VIRTIO_F_NOTIFICATION_DATA > transport feature has been negotiated. > > The extra data that's passed to the virtio-pci device when

Re: Intention to work on GSoC project

On Fri, Mar 15, 2024 at 8:15 AM Sahil wrote: > > Hi, > > Thank you for your email. > > On Thursday, March 14, 2024 8:39:45 PM IST Eugenio Perez Martin wrote: > > Hi Sahil, > > > > It's being hard to find a good self-contained small task related to > > th

Re: [PATCH v2 1/6] virtio/virtio-pci: Handle extra notification data

On Thu, Mar 14, 2024 at 9:24 PM Jonah Palmer wrote: > > > > On 3/14/24 3:05 PM, Eugenio Perez Martin wrote: > > On Thu, Mar 14, 2024 at 5:06 PM Jonah Palmer > > wrote: > >> > >> > >> > >> On 3/14/24 10:55 AM, Eugenio Perez Mart

Re: [PATCH v3 2/2] vhost: Perform memory section dirty scans once per iteration

On Thu, Mar 14, 2024 at 7:35 PM Si-Wei Liu wrote: > > > > On 3/14/2024 8:34 AM, Eugenio Perez Martin wrote: > > On Thu, Mar 14, 2024 at 9:38 AM Si-Wei Liu wrote: > >> On setups with one or more virtio-net devices with vhost on, > >> dirty tracking iteration

Re: [PATCH v2 1/6] virtio/virtio-pci: Handle extra notification data

On Thu, Mar 14, 2024 at 5:06 PM Jonah Palmer wrote: > > > > On 3/14/24 10:55 AM, Eugenio Perez Martin wrote: > > On Thu, Mar 14, 2024 at 1:16 PM Jonah Palmer > > wrote: > >> > >> > >> > >> On 3/13/24 11:01 PM, Jason Wang wrote: >

Re: [PATCH v3 2/2] vhost: Perform memory section dirty scans once per iteration

On Thu, Mar 14, 2024 at 9:38 AM Si-Wei Liu wrote: > > On setups with one or more virtio-net devices with vhost on, > dirty tracking iteration increases cost the bigger the number > amount of queues are set up e.g. on idle guests migration the > following is observed with virtio-net with vhost=on:

Re: [PATCH v3 1/2] vhost: dirty log should be per backend type

On Thu, Mar 14, 2024 at 9:38 AM Si-Wei Liu wrote: > > There could be a mix of both vhost-user and vhost-kernel clients > in the same QEMU process, where separate vhost loggers for the > specific vhost type have to be used. Make the vhost logger per > backend type, and have them properly reference

Re: Intention to work on GSoC project

On Fri, Mar 1, 2024 at 7:29 PM Sahil wrote: > > Hi, > > On Friday, March 1, 2024 1:10:49 PM IST you wrote: > > [...] > > You can add the recently published > > "virtio-live-migration-technical-deep-dive" :) [1]. > > > > [1] > >

Re: [PATCH v2 1/6] virtio/virtio-pci: Handle extra notification data

On Thu, Mar 14, 2024 at 1:16 PM Jonah Palmer wrote: > > > > On 3/13/24 11:01 PM, Jason Wang wrote: > > On Wed, Mar 13, 2024 at 7:55 PM Jonah Palmer > > wrote: > >> > >> Add support to virtio-pci devices for handling the extra data sent > >> from the driver to the device when the

Re: [PATCH v2 2/6] virtio: Prevent creation of device using notification-data with ioeventfd

On Wed, Mar 13, 2024 at 12:55 PM Jonah Palmer wrote: > > Prevent the realization of a virtio device that attempts to use the > VIRTIO_F_NOTIFICATION_DATA transport feature without disabling > ioeventfd. > > Due to ioeventfd not being able to carry the extra data associated with > this feature,

Re: [EXT] Re: [PATCH] vhost_net: add NOTIFICATION_DATA and IN_ORDER feature bits to vdpa_feature_bits

On Fri, Mar 8, 2024 at 2:39 PM Srujana Challa wrote: > > Hi Michael, > > VIRTIO_F_NOTIFICATION_DATA needs to be exposed to make Marvell's device works > with Qemu. Any other better ways to expose VIRTIO_F_NOTIFICATION_DATA feature > bit for vhost vdpa use case? > Hi! Jonah Palmer is working on

Re: [PATCH v1 2/8] virtio-pci: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA

On Fri, Mar 8, 2024 at 6:01 PM Michael S. Tsirkin wrote: > > On Mon, Mar 04, 2024 at 02:46:06PM -0500, Jonah Palmer wrote: > > Prevent ioeventfd from being enabled/disabled when a virtio-pci > > device has negotiated the VIRTIO_F_NOTIFICATION_DATA transport > > feature. > > > > Due to ioeventfd

Re: [PATCH v1 0/8] virtio, vhost: Add VIRTIO_F_NOTIFICATION_DATA support

On Wed, Mar 6, 2024 at 8:34 AM Michael S. Tsirkin wrote: > > On Wed, Mar 06, 2024 at 08:07:31AM +0100, Eugenio Perez Martin wrote: > > On Wed, Mar 6, 2024 at 6:34 AM Jason Wang wrote: > > > > > > On Tue, Mar 5, 2024 at 3:46 AM Jonah Palmer > > > wrote: &g

Re: [PATCH v2 2/2] vhost: Perform memory section dirty scans once per iteration

On Wed, Feb 14, 2024 at 2:02 PM Si-Wei Liu wrote: > > On setups with one or more virtio-net devices with vhost on, > dirty tracking iteration increases cost the bigger the number > amount of queues are set up e.g. on idle guests migration the > following is observed with virtio-net with vhost=on:

Re: [PATCH v2 1/2] vhost: dirty log should be per backend type

On Wed, Feb 14, 2024 at 2:01 PM Si-Wei Liu wrote: > > There could be a mix of both vhost-user and vhost-kernel clients > in the same QEMU process, where separate vhost loggers for the > specific vhost type have to be used. Make the vhost logger per > backend type, and have them properly reference

Re: [PATCH v1 0/8] virtio, vhost: Add VIRTIO_F_NOTIFICATION_DATA support

On Wed, Mar 6, 2024 at 6:34 AM Jason Wang wrote: > > On Tue, Mar 5, 2024 at 3:46 AM Jonah Palmer wrote: > > > > The goal of these patches are to add support to a variety of virtio and > > vhost devices for the VIRTIO_F_NOTIFICATION_DATA transport feature. This > > feature indicates that a driver

Re: [RFC 0/8] virtio,vhost: Add VIRTIO_F_NOTIFICATION_DATA support

40301134330.4191007-1-jonah.pal...@oracle.com>" (untested). https://pypi.org/project/b4/ Thanks! > Thanks, > Xinying > > > [1] https://lists.nongnu.org/archive/html/qemu-devel/2024-03/msg00090.html > > > From: Eugenio Perez

Re: [PATCH v1 3/8] virtio-mmio: Handle extra notification data

On Mon, Mar 4, 2024 at 8:46 PM Jonah Palmer wrote: > > Add support to virtio-mmio devices for handling the extra data sent from > the driver to the device when the VIRTIO_F_NOTIFICATION_DATA transport > feature has been negotiated. > > The extra data that's passed to the virtio-mmio device when

Re: [PATCH v1 4/8] virtio-mmio: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA

On Mon, Mar 4, 2024 at 8:46 PM Jonah Palmer wrote: > > Prevent ioeventfd from being enabled/disabled when a virtio-mmio device > has negotiated the VIRTIO_F_NOTIFICATION_DATA transport feature. > > Due to ioeventfd not being able to carry the extra data associated with > this feature, the

Re: [PATCH v1 1/8] virtio/virtio-pci: Handle extra notification data

On Mon, Mar 4, 2024 at 8:46 PM Jonah Palmer wrote: > > Add support to virtio-pci devices for handling the extra data sent > from the driver to the device when the VIRTIO_F_NOTIFICATION_DATA > transport feature has been negotiated. > > The extra data that's passed to the virtio-pci device when

Re: [RFC 1/8] virtio/virtio-pci: Handle extra notification data

On Mon, Mar 4, 2024 at 6:09 PM Jonah Palmer wrote: > > > > On 3/1/24 2:31 PM, Eugenio Perez Martin wrote: > > On Fri, Mar 1, 2024 at 2:44 PM Jonah Palmer wrote: > >> > >> Add support to virtio-pci devices for handling the extra data sent >

Re: [RFC 0/8] virtio,vhost: Add VIRTIO_F_NOTIFICATION_DATA support

Hi Wentao / Rick / Xinying Yu, Would it work for you to test this series on your use cases, so we make sure everything works as expected? Thanks! On Fri, Mar 1, 2024 at 2:44 PM Jonah Palmer wrote: > > The goal of these patches are to add support to a variety of virtio and > vhost devices for

Re: [RFC 8/8] virtio: Add VIRTIO_F_NOTIFICATION_DATA property definition

On Fri, Mar 1, 2024 at 2:44 PM Jonah Palmer wrote: > > Extend the virtio device property definitions to include the > VIRTIO_F_NOTIFICATION_DATA feature. > > The default state of this feature is disabled, allowing it to be > explicitly enabled where it's supported. > Reviewed-by: Eugenio Pérez

Re: [RFC 7/8] vhost/vhost-user: Add VIRTIO_F_NOTIFICATION_DATA to vhost feature bits

On Fri, Mar 1, 2024 at 2:44 PM Jonah Palmer wrote: > > Add support for the VIRTIO_F_NOTIFICATION_DATA feature across a variety > of vhost devices. > > The inclusion of VIRTIO_F_NOTIFICATION_DATA in the feature bits arrays > for these devices ensures that the backend is capable of offering and >

Re: [RFC 1/8] virtio/virtio-pci: Handle extra notification data

On Fri, Mar 1, 2024 at 2:44 PM Jonah Palmer wrote: > > Add support to virtio-pci devices for handling the extra data sent > from the driver to the device when the VIRTIO_F_NOTIFICATION_DATA > transport feature has been negotiated. > > The extra data that's passed to the virtio-pci device when

Re: [RFC 2/8] virtio-pci: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA

On Fri, Mar 1, 2024 at 2:44 PM Jonah Palmer wrote: > > Prevent ioeventfd from being enabled/disabled when a virtio-pci > device has negotiated the VIRTIO_F_NOTIFICATION_DATA transport > feature. > > Due to ioeventfd not being able to carry the extra data associated with > this feature, the

Re: [RFC 1/8] virtio/virtio-pci: Handle extra notification data

On Fri, Mar 1, 2024 at 2:44 PM Jonah Palmer wrote: > > Add support to virtio-pci devices for handling the extra data sent > from the driver to the device when the VIRTIO_F_NOTIFICATION_DATA > transport feature has been negotiated. > > The extra data that's passed to the virtio-pci device when

Re: Intention to work on GSoC project

On Thu, Feb 29, 2024 at 9:32 AM Stefano Garzarella wrote: > > Hi Sahil, > > On Sun, Feb 25, 2024 at 10:38 PM Sahil wrote: > > > > Hi, > > > > My name is Sahil and I go by the pseudonym 'valdaarhun' on Github. I have > > never contributed to QEMU before but I have used it a few times as an end >

Re: [PATCH 12/12] vdpa: fix network breakage after cancelling migration

On Thu, Feb 15, 2024 at 5:15 PM Eugenio Perez Martin wrote: > > On Wed, Feb 14, 2024 at 1:39 PM Si-Wei Liu wrote: > > > > Fix an issue where cancellation of ongoing migration ends up > > with no network connectivity. > > > > When canceling

Re: [PATCH 12/12] vdpa: fix network breakage after cancelling migration

On Wed, Feb 14, 2024 at 1:39 PM Si-Wei Liu wrote: > > Fix an issue where cancellation of ongoing migration ends up > with no network connectivity. > > When canceling migration, SVQ will be switched back to the > passthrough mode, but the right call fd is not programed to > the device and the

Re: [PATCH 04/12] vdpa: factor out vhost_vdpa_net_get_nc_vdpa

On Wed, Feb 14, 2024 at 9:59 PM Si-Wei Liu wrote: > > > > On 2/14/2024 10:54 AM, Eugenio Perez Martin wrote: > > On Wed, Feb 14, 2024 at 1:39 PM Si-Wei Liu wrote: > >> Introduce new API. No functional change on existing API. > >> > >> Acked-by: Jason

Re: [PATCH v2 6/7] vdpa: move iova_tree allocation to net_vhost_vdpa_init

On Wed, Feb 14, 2024 at 7:29 PM Si-Wei Liu wrote: > > Hi Michael, > > On 2/13/2024 2:22 AM, Michael S. Tsirkin wrote: > > On Mon, Feb 05, 2024 at 05:10:36PM -0800, Si-Wei Liu wrote: > >> Hi Eugenio, > >> > >> I thought this new code looks good to me and the original issue I saw with > >> x-svq=on

Re: [PATCH 04/12] vdpa: factor out vhost_vdpa_net_get_nc_vdpa

On Wed, Feb 14, 2024 at 1:39 PM Si-Wei Liu wrote: > > Introduce new API. No functional change on existing API. > > Acked-by: Jason Wang > Signed-off-by: Si-Wei Liu I'm ok with the new function, but doesn't the compiler complain because adding a static function is not used? > --- >

Re: [PATCH v2 6/7] vdpa: move iova_tree allocation to net_vhost_vdpa_init

On Tue, Feb 13, 2024 at 11:22 AM Michael S. Tsirkin wrote: > > On Mon, Feb 05, 2024 at 05:10:36PM -0800, Si-Wei Liu wrote: > > Hi Eugenio, > > > > I thought this new code looks good to me and the original issue I saw with > > x-svq=on should be gone. However, after rebase my tree on top of this,

Re: [PATCH] vdpa-dev: Fix initialisation order to restore VDUSE compatibility

On Wed, Feb 7, 2024 at 11:18 AM Kevin Wolf wrote: > > Am 06.02.2024 um 17:44 hat Eugenio Perez Martin geschrieben: > > On Mon, Feb 5, 2024 at 2:49 PM Kevin Wolf wrote: > > > > > > Am 05.02.2024 um 13:22 hat Eugenio Perez Martin geschrieben: > > > >

Re: [PATCH] vdpa-dev: Fix initialisation order to restore VDUSE compatibility

On Mon, Feb 5, 2024 at 2:49 PM Kevin Wolf wrote: > > Am 05.02.2024 um 13:22 hat Eugenio Perez Martin geschrieben: > > On Fri, Feb 2, 2024 at 2:25 PM Kevin Wolf wrote: > > > > > > VDUSE requires that virtqueues are first enabled before the DRIVER_OK > > > s

Re: [PATCH] vdpa-dev: Fix initialisation order to restore VDUSE compatibility

On Fri, Feb 2, 2024 at 2:25 PM Kevin Wolf wrote: > > VDUSE requires that virtqueues are first enabled before the DRIVER_OK > status flag is set; with the current API of the kernel module, it is > impossible to enable the opposite order in our block export code because > userspace is not notified

Re: FW: [PATCH] vhost-user: add VIRTIO_F_IN_ORDER and VIRTIO_F_NOTIFICATION_DATA feature

); > return features; > } > > Best Regards > Wentao Jia > > -Original Message- > From: Eugenio Perez Martin > Sent: Saturday, January 27, 2024 2:04 AM > To: Wentao Jia > Cc: Rick Zhong ; qemu-devel@nongnu.org; > m...@redhat.com; Jason W

Re: [PATCH 1/6] vdpa: check for iova tree initialized at net_client_start

On Wed, Jan 31, 2024 at 11:07 AM Si-Wei Liu wrote: > > Hi Eugenio, > > Maybe there's some patch missing, but I saw this core dump when x-svq=on > is specified while waiting for the incoming migration on destination host: > > (gdb) bt > #0 0x5643b24cc13c in vhost_iova_tree_map_alloc

Re: Call for GSoC/Outreachy internship project ideas

On Tue, Jan 30, 2024 at 8:34 PM Stefan Hajnoczi wrote: > > Hi Eugenio, > Stefano Garzarella and I had a SVQ-related project idea that I have added: > https://wiki.qemu.org/Google_Summer_of_Code_2024#vhost-user_memory_isolation > > We want to support vhost-user devices without exposing guest RAM.

  1   2   3   4   5   6   7   8   9   >