search for: vdpasim_set_vq_st

...free_page(vdpasim->notify); > } > > static const struct vdpa_config_ops vdpasim_config_ops = { > @@ -704,6 +765,8 @@ static const struct vdpa_config_ops vdpasim_config_ops = { > .get_vq_ready = vdpasim_get_vq_ready, > .set_vq_state = vdpasim_set_vq_state, > .get_vq_state = vdpasim_get_vq_state, > + .get_vq_notification = vdpasim_get_vq_notification, > + .get_vq_notification_pgprot = vdpasim_get_vq_notification_pgprot, > .get_vq_align = vdpasim_get_vq_align, > .get_vq_group...

...ready; vq->ready = ready; if (vq->ready && !old_ready) { vdpasim_queue_ready(vdpasim, idx); } - spin_unlock(&vdpasim->lock); + mutex_unlock(&vdpasim->mutex); } static bool vdpasim_get_vq_ready(struct vdpa_device *vdpa, u16 idx) @@ -299,9 +299,9 @@ static int vdpasim_set_vq_state(struct vdpa_device *vdpa, u16 idx, struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; struct vringh *vrh = &vq->vring; - spin_lock(&vdpasim->lock); + mutex_lock(&vdpasim->mutex); vrh->last_avail_idx = state->split.avail_index; - spin_unlock(&vdpasim-...

...ang <jasowang at redhat.com> wrote: >> On Thu, Jan 19, 2023 at 12:44 AM Eugenio P?rez <eperezma at redhat.com> wrote: >>> vdpasim_queue_ready calls vringh_init_iotlb, which resets split indexes. >>> But it can be called after setting a ring base with >>> vdpasim_set_vq_state. >>> >>> Fix it by stashing them. They're still resetted in vdpasim_vq_reset. >>> >>> This was discovered and tested live migrating the vdpa_sim_net device. >>> >>> Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator") >>...

...gt; >Since vdpa_sim does not support receive inflight descriptors as a >destination of a migration, let's set both avail_idx and used_idx the >same at vq start. This is how vhost-user works in a >VHOST_SET_VRING_BASE call. > >Although the simple fix is to set last_used_idx at vdpasim_set_vq_state, >it would be reset at vdpasim_queue_ready. The last_avail_idx case is >fixed with commit a09f493c ("vdpa_sim: not reset state in >vdpasim_queue_ready"). Since the only option is to make it equal to >last_avail_idx, adding the only change needed here. > >This was di...

...ate(struct vdpa_device *vdpa_dev, u16 qid, > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c > index 599519039f8d..ddf6086d43c2 100644 > --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c > @@ -427,14 +427,15 @@ static int vdpasim_set_vq_state(struct vdpa_device *vdpa, u16 idx, > return 0; > } > > -static void vdpasim_get_vq_state(struct vdpa_device *vdpa, u16 idx, > - struct vdpa_vq_state *state) > +static int vdpasim_get_vq_state(struct vdpa_device *vdpa, u16 idx, > + struct vdpa_vq_state *state)...

...ate(struct vdpa_device *vdpa_dev, u16 qid, > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c > index f1c351d5959b..c68741363643 100644 > --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c > @@ -464,14 +464,15 @@ static int vdpasim_set_vq_state(struct vdpa_device *vdpa, u16 idx, > return 0; > } > > -static void vdpasim_get_vq_state(struct vdpa_device *vdpa, u16 idx, > - struct vdpa_vq_state *state) > +static int vdpasim_get_vq_state(struct vdpa_device *vdpa, u16 idx, > + struct vdpa_vq_state *state)...

...vdpasim_queue_ready(vdpasim, idx); + spin_unlock(&vdpasim->lock); +} + +static bool vdpasim_get_vq_ready(struct vdpa_device *vdpa, u16 idx) +{ + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; + + return vq->ready; +} + +static int vdpasim_set_vq_state(struct vdpa_device *vdpa, u16 idx, u64 state) +{ + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; + struct vringh *vrh = &vq->vring; + + spin_lock(&vdpasim->lock); + vrh->last_avail_idx = state; + spin_unlock(&vdpasim...

...vdpasim_queue_ready(vdpasim, idx); + spin_unlock(&vdpasim->lock); +} + +static bool vdpasim_get_vq_ready(struct vdpa_device *vdpa, u16 idx) +{ + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; + + return vq->ready; +} + +static int vdpasim_set_vq_state(struct vdpa_device *vdpa, u16 idx, u64 state) +{ + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; + struct vringh *vrh = &vq->vring; + + spin_lock(&vdpasim->lock); + vrh->last_avail_idx = state; + spin_unlock(&vdpasim...

...vdpasim->lock); > +} > + > +static bool vdpasim_get_vq_ready(struct vdpa_device *vdpa, u16 idx) > +{ > + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); > + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; > + > + return vq->ready; > +} > + > +static int vdpasim_set_vq_state(struct vdpa_device *vdpa, u16 idx, u64 state) > +{ > + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); > + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; > + struct vringh *vrh = &vq->vring; > + > + spin_lock(&vdpasim->lock); > + vrh->last_avail_idx...

Hi all: This series tries to support batched IOTLB updating vhost-vdpa. Currently vhost-vdpa accepts userspace mapping via IOTLB API, and it can only forward one mapping to IOMMU or device through IOMMU API or dma_map(). Though set_map() is designed to have the capability to pass an rbtree based mapping to vDPA device, it's still be called at least once for each VHOST_IOTLB_UPDATE or

Hi all: This series tries to support batched IOTLB updating vhost-vdpa. Currently vhost-vdpa accepts userspace mapping via IOTLB API, and it can only forward one mapping to IOMMU or device through IOMMU API or dma_map(). Though set_map() is deisgend to have the capability to pass an rbtree based mapping to vDPA device, it's still be called at least once for each VHOST_IOTLB_UPDATE or

Let's move work management inside the vdpa_sim core. This way we can easily change how we manage the works, without having to change the devices each time. Acked-by: Eugenio P??rez Martin <eperezma at redhat.com> Acked-by: Jason Wang <jasowang at redhat.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drivers/vdpa/vdpa_sim/vdpa_sim.h | 3 ++-

Hi all: This is an updated version of kernel support for vDPA device. Various changes were made based on the feedback since last verion. One major change is to drop the sysfs API and leave the management interface for future development, and introudce the incremental DMA bus operations. Please see changelog for more information. The work on vhost, IFCVF (intel VF driver for vDPA) and qemu is

v2: - rebased on Linus' tree, commit ae3419fbac84 ("vc_screen: don't clobber return value in vcs_read") - removed `struct task_struct *owner` param (unused for now, maybe ?useful to support cgroups) [Jason] - add unbind_mm callback [Jason] - call the new unbind_mm callback during the release [Jason] - avoid to call bind_mm callback after the reset, since the device ?is not

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is

Hi all: This is an update version of vDPA support in kernel. vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single

Hi all: This is an update version of vDPA support in kernel. vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single