search for: vdpasim_set_vq_ready

...is need to be serialized with the datapath? >> >> E.g in set_vq_state() we do: >> >> spin_lock(&vdpasim->lock); >> vrh->last_avail_idx = state->split.avail_index; >> spin_unlock(&vdpasim->lock); >> > vdpasim_queue_ready is called from vdpasim_set_vq_ready, which holds > these locks. > > Maybe it's too much indirection and to embed vdpasim_queue_ready in > vdpasim_set_vq_ready would be clearer for the future? Nope, I miss the caller. Acked-by: Jason Wang <jasowang at redhat.com> Thanks > > Thanks! >

...pasim_create(struct vdpasim_dev_attr *dev_attr, if (IS_ERR(vdpasim->worker)) goto err_iommu; - spin_lock_init(&vdpasim->lock); + mutex_init(&vdpasim->mutex); spin_lock_init(&vdpasim->iommu_lock); dev = &vdpasim->vdpa.dev; @@ -275,13 +275,13 @@ static void vdpasim_set_vq_ready(struct vdpa_device *vdpa, u16 idx, bool ready) struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; bool old_ready; - spin_lock(&vdpasim->lock); + mutex_lock(&vdpasim->mutex); old_ready = vq->ready; vq->ready = ready; if (vq->ready && !old_ready) {...

....c:(.text+0x4b0): undefined reference to `vringh_complete_iotlb' m68k-linux-ld: drivers/vdpa/vdpa_sim/vdpa_sim.o: in function `vdpasim_set_status': vdpa_sim.c:(.text+0x764): undefined reference to `vringh_init_iotlb' m68k-linux-ld: drivers/vdpa/vdpa_sim/vdpa_sim.o: in function `vdpasim_set_vq_ready': vdpa_sim.c:(.text+0x844): undefined reference to `vringh_init_iotlb' m68k-linux-ld: drivers/vdpa/vdpa_sim/vdpa_sim.o: in function `vdpasim_dev_init': vdpa_sim.c:(.init.text+0xe4): undefined reference to `vringh_set_iotlb' --- 0-DAY CI Kernel Test Service, Intel Corporati...

...a_sim/vdpa_sim.o: in function `vdpasim_set_status': vdpa_sim.c:(.text+0xad2): undefined reference to `vringh_init_iotlb' >> riscv64-linux-ld: vdpa_sim.c:(.text+0xb4e): undefined reference to `vringh_init_iotlb' riscv64-linux-ld: drivers/vdpa/vdpa_sim/vdpa_sim.o: in function `vdpasim_set_vq_ready': vdpa_sim.c:(.text+0xc6e): undefined reference to `vringh_init_iotlb' riscv64-linux-ld: drivers/vdpa/vdpa_sim/vdpa_sim.o: in function `.L0 ': vdpa_sim.c:(.init.text+0x1a4): undefined reference to `vringh_set_iotlb' >> riscv64-linux-ld: vdpa_sim.c:(.init.text+0x1be):...

...+ +static void vdpasim_set_vq_cb(struct vdpa_device *vdpa, u16 idx, + struct vdpa_callback *cb) +{ + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; + + vq->cb = cb->callback; + vq->private = cb->private; +} + +static void vdpasim_set_vq_ready(struct vdpa_device *vdpa, u16 idx, bool ready) +{ + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; + + spin_lock(&vdpasim->lock); + vq->ready = ready; + if (vq->ready) + vdpasim_queue_ready(vdpasim, idx); + spin_unlock(&vdp...

...+ +static void vdpasim_set_vq_cb(struct vdpa_device *vdpa, u16 idx, + struct vdpa_callback *cb) +{ + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; + + vq->cb = cb->callback; + vq->private = cb->private; +} + +static void vdpasim_set_vq_ready(struct vdpa_device *vdpa, u16 idx, bool ready) +{ + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; + + spin_lock(&vdpasim->lock); + vq->ready = ready; + if (vq->ready) + vdpasim_queue_ready(vdpasim, idx); + spin_unlock(&vdp...

...e *vdpa, u16 idx, > + struct vdpa_callback *cb) > +{ > + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); > + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; > + > + vq->cb = cb->callback; > + vq->private = cb->private; > +} > + > +static void vdpasim_set_vq_ready(struct vdpa_device *vdpa, u16 idx, bool ready) > +{ > + struct vdpasim *vdpasim = vdpa_to_sim(vdpa); > + struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; > + > + spin_lock(&vdpasim->lock); > + vq->ready = ready; > + if (vq->ready) > + vdpasim_queue_rea...

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 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