similar to: [PATCH 0/2] virtio: virtio_config_ops documentation

On Thu, Jan 03, 2019 at 05:08:04PM +0100, Cornelia Huck wrote: > Some transports (e.g. virtio-ccw) implement virtio operations that > seem to be a simple read/write as something more involved that > cannot be done from an atomic context. > > Give at least a hint about that. > > Signed-off-by: Cornelia Huck <cohuck at redhat.com> > --- >

Hi Michael, hi Jason, This patches applies a few cleanups to the virtio PCI interrupt handling code, and then converts the virtio PCI code to use the automatic MSI-X vectors spreading, as well as using the information in virtio-blk and virtio-scsi to automatically align the blk-mq queues to the MSI-X vectors. Changes since V1: - dropped the patches already merged for 4.10-rc - new patch to

Hi Michael, hi Jason, This patches applies a few cleanups to the virtio PCI interrupt handling code, and then converts the virtio PCI code to use the automatic MSI-X vectors spreading, as well as using the information in virtio-blk and virtio-scsi to automatically align the blk-mq queues to the MSI-X vectors. Changes since V1: - dropped the patches already merged for 4.10-rc - new patch to

Hi Michael, this series contains a couple cleanups for the virtio_pci interrupt handling code, including a switch to the new pci_irq_alloc_vectors helper, and support for automatic affinity by the PCI layer if the consumers ask for it. It then converts over virtio_blk to use this functionality so that it's blk-mq queues are aligned to the MSI-X vector routing. I have a similar patch in the

Hi Michael, this series contains a couple cleanups for the virtio_pci interrupt handling code, including a switch to the new pci_irq_alloc_vectors helper, and support for automatic affinity by the PCI layer if the consumers ask for it. It then converts over virtio_blk to use this functionality so that it's blk-mq queues are aligned to the MSI-X vector routing. I have a similar patch in the

On Thu, 3 Jan 2019 18:28:49 +0100 Halil Pasic <pasic at linux.ibm.com> wrote: > On Thu, 3 Jan 2019 17:08:04 +0100 > Cornelia Huck <cohuck at redhat.com> wrote: > > > Some transports (e.g. virtio-ccw) implement virtio operations that > > seem to be a simple read/write as something more involved that > > cannot be done from an atomic context. > > >

> This will make it easy for transports to validate features and return > failure. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > include/linux/virtio_config.h | 3 ++- > drivers/lguest/lguest_device.c | 4 +++- > drivers/misc/mic/card/mic_virtio.c | 4 +++- > drivers/remoteproc/remoteproc_virtio.c | 4 +++- >

> This will make it easy for transports to validate features and return > failure. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > include/linux/virtio_config.h | 3 ++- > drivers/lguest/lguest_device.c | 4 +++- > drivers/misc/mic/card/mic_virtio.c | 4 +++- > drivers/remoteproc/remoteproc_virtio.c | 4 +++- >

transports need to be able to detect legacy-only devices (ATM balloon only) to use legacy path to drive them. Add a core API to do just that. The implementation just blacklists balloon: not too pretty, but let's not over-engineer. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Acked-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- include/linux/virtio.h | 2 ++

transports need to be able to detect legacy-only devices (ATM balloon only) to use legacy path to drive them. Add a core API to do just that. The implementation just blacklists balloon: not too pretty, but let's not over-engineer. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Acked-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- include/linux/virtio.h | 2 ++

Some transports (e.g. virtio-ccw) implement virtio operations that seem to be a simple read/write as something more involved that cannot be done from an atomic context. Give at least a hint about that. Signed-off-by: Cornelia Huck <cohuck at redhat.com> --- include/linux/virtio_config.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/linux/virtio_config.h

Hi Michael, hi Jason, This patches applies a few cleanups to the virtio PCI interrupt handling code, and then converts the virtio PCI code to use the automatic MSI-X vectors spreading, as well as using the information in virtio-blk and virtio-scsi to automatically align the blk-mq queues to the MSI-X vectors. Changes since V2: - remove a redundant callback check - calculate ->msix_vectors

Hi Michael, hi Jason, This patches applies a few cleanups to the virtio PCI interrupt handling code, and then converts the virtio PCI code to use the automatic MSI-X vectors spreading, as well as using the information in virtio-blk and virtio-scsi to automatically align the blk-mq queues to the MSI-X vectors. Changes since V2: - remove a redundant callback check - calculate ->msix_vectors

I observed that there is one msix vector for config and one shared vector for all queues in below qemu cmdline, when the num-queues for virtio-blk is more than the number of possible cpus: qemu: "-smp 4" while "-device virtio-blk-pci,drive=drive-0,id=virtblk0,num-queues=6" # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 ... ... 24: 0

I observed that there is one msix vector for config and one shared vector for all queues in below qemu cmdline, when the num-queues for virtio-blk is more than the number of possible cpus: qemu: "-smp 4" while "-device virtio-blk-pci,drive=drive-0,id=virtblk0,num-queues=6" # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 ... ... 24: 0

multiple queue virtio-net: flow steering through host/guest cooperation Hello all: This is a rough series adds the guest/host cooperation of flow steering support based on Krish Kumar's multiple queue virtio-net driver patch 3/3 (http://lwn.net/Articles/467283/). This idea is simple, the backend pass the rxhash to the guest and guest would tell the backend the hash to queue mapping when

multiple queue virtio-net: flow steering through host/guest cooperation Hello all: This is a rough series adds the guest/host cooperation of flow steering support based on Krish Kumar's multiple queue virtio-net driver patch 3/3 (http://lwn.net/Articles/467283/). This idea is simple, the backend pass the rxhash to the guest and guest would tell the backend the hash to queue mapping when

Aiming these for coming merge window. Nothing should change, but get ready for a non-guest-endian config transports, and > 32 features bits. Final one is just an overdue consolidation. Cheers, Rusty. Rusty Russell (7): virtio_config: introduce size-based accessors. virtio: use size-based config accessors. virtio_config: helpers for non-converting accessors. virtio_config: make

Aiming these for coming merge window. Nothing should change, but get ready for a non-guest-endian config transports, and > 32 features bits. Final one is just an overdue consolidation. Cheers, Rusty. Rusty Russell (7): virtio_config: introduce size-based accessors. virtio: use size-based config accessors. virtio_config: helpers for non-converting accessors. virtio_config: make

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add wrappers for the host vrings to support loose coupling between the virtio device and driver. The functions find_vrhs() and del_vrhs() are added to struct virtio_config_ops to manage the host vrings. The function vringh_notify() is added so the guest can be kicked when buffers are added to the used-ring. This enables the virtio