search for: virtuqueu

...e Queue Size parameter of a virtqueue corresponds to the maximum number of descriptors in that queue, and it does not have to be a power of 2 for packed virtqueues. However, the virtio_pci_modern driver enforced a power of 2 check for virtqueue sizes, which is unnecessary and restrictive for packed virtuqueue. Split virtqueue still needs to check the virtqueue size is power_of_2 which has been done in vring_alloc_queue_split of the virtio_ring layer. To validate this change, we tested various virtqueue sizes for packed rings, including 128, 256, 512, 100, 200, 500, and 1000, with CONFIG_PAGE_POISONIN...

...; > +#include <linux/kthread.h> Typically the header includes would be alphabetized if possible. > + vq_virt = pci_epc_map_addr(epf->epc, epf->func_no, epf->vfunc_no, > + vq_pci_addr, vq_phys, vq_size); > + if (IS_ERR(vq_virt)) { > + pr_err("Failed to map virtuqueue to local"); s/virtuqueue/virtqueue/ I know you probably don't have any way to use dev_err(), but this message really needs some context, like a driver name and instance or something. > +#define VIRTIO_PCI_LEGACY_CFG_BAR 0 What makes this a "legacy cfg BAR"? Is there some...

...a > virtqueue corresponds to the maximum number of descriptors in that > queue, and it does not have to be a power of 2 for packed virtqueues. > However, the virtio_pci_modern driver enforced a power of 2 check for > virtqueue sizes, which is unnecessary and restrictive for packed > virtuqueue. > > Split virtqueue still needs to check the virtqueue size is power_of_2 > which has been done in vring_alloc_queue_split of the virtio_ring layer. > > To validate this change, we tested various virtqueue sizes for packed > rings, including 128, 256, 512, 100, 200, 500, and 100...

...s means that the device must perform PCI reads to transfer data from the driver to the device. PCI reads are typically slower than PCI writes since reads require a round-trip transfer, whereas writes can be posted. I wonder if any thought has been put into having the device optionally allocate virtuqueue buffers so that the protocol can rely primarily on PCI writes? Perhaps there's some alternative protocol that's more optimized for true PCI-based communication rather than paravirtualized PCI-based communication? Thanks for any thoughts on the best approach, or pointers to pre-existin...

In request submission path it is possible that virtqueue is already gone due to driver->remove(). So do not access it in dev_dbg(). Use pr_debug() instead. If virtuqueue is gone, this will result in NULL pointer deference. Signed-off-by: Vivek Goyal <vgoyal at redhat.com> --- fs/fuse/virtio_fs.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index 40259368a6bd..01bbf2c0e144 100644 --- a...

This patch series performs a clean up of the code in virtio_ring and virtio_pci, modifying it to conform with the Linux kernel coding style guidance [1]. The modifications ensure the code easy to read and understand. This small series does few short cleanups in the code. Patch-1 Allow non power of 2 sizes for packed virtqueues. Patch-2 Avoid using inline for small functions. Patch-3 Use const to

...s by retrying submitting the request with the help of a worker. For regular requests (VQ_REQUESTS), I have never run into virt queue being full so far. That's why never worried about it. So nothing prevents this. But we have not noticed it yet. So its a TODO item. It will be nice to retry if virtuqueue gets full (instead of returning error to caller). [..] > > +static void virtio_fs_wake_pending_and_unlock(struct fuse_iqueue *fiq) > > +__releases(fiq->waitq.lock) > > +{ > > + unsigned int queue_id = VQ_REQUEST; /* TODO multiqueue */ > > + struct virtio_fs *fs; &...

Hi, Michael Tsirkin pointed out issues w.r.t various locking related TODO items and races w.r.t device removal. In this first round of cleanups, I have taken care of most pressing issues. These patches apply on top of following. git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v4 I have tested these patches with mount/umount and device removal using qemu monitor. For

PCIe endpoint framework provides APIs to implement PCIe endpoint function. This framework allows defining various PCIe endpoint function behaviors in software. This patch extend the framework for virtio pci device. The virtio is defined to communicate guest on virtual machine and host side. Advantage of the virtio is the efficiency of data transfer and the conciseness of implementation device

v8: - use per virtqueue lock instead of a whole device lock for data virtuqueue. [Halil & Xin] v7: - fix "BUG: smp_processor_id() in preemptible [00000000] code" reported by Halil, using get_cpu/put_cpu instead of calling smp_processor_id() directly. - fix a possible spinlock recursion in virtcrypto_dataq_callback(), we should release the spinlock befor...

v8: - use per virtqueue lock instead of a whole device lock for data virtuqueue. [Halil & Xin] v7: - fix "BUG: smp_processor_id() in preemptible [00000000] code" reported by Halil, using get_cpu/put_cpu instead of calling smp_processor_id() directly. - fix a possible spinlock recursion in virtcrypto_dataq_callback(), we should release the spinlock befor...

On Tue, Sep 03, 2019 at 01:42:02PM +0200, Miklos Szeredi wrote: > From: Stefan Hajnoczi <stefanha at redhat.com> > > Add a basic file system module for virtio-fs. This does not yet contain > shared data support between host and guest or metadata coherency speedups. > However it is already significantly faster than virtio-9p. > > Design Overview > ===============

On Tue, Sep 03, 2019 at 01:42:02PM +0200, Miklos Szeredi wrote: > From: Stefan Hajnoczi <stefanha at redhat.com> > > Add a basic file system module for virtio-fs. This does not yet contain > shared data support between host and guest or metadata coherency speedups. > However it is already significantly faster than virtio-9p. > > Design Overview > ===============

Hello All: This series is an update version of multiqueue virtio-net driver based on Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the packets reception and transmission. Please review and comments. Test Environment: - Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 8 cores 2 numa nodes - Two directed connected 82599 Test Summary: - Highlights: huge improvements on TCP_RR

Hello All: This series is an update version of multiqueue virtio-net driver based on Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the packets reception and transmission. Please review and comments. Test Environment: - Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 8 cores 2 numa nodes - Two directed connected 82599 Test Summary: - Highlights: huge improvements on TCP_RR