search for: kvm_notifi

From: Rusty Russell <rusty at rustcorp.com.au> Add a linked list of all virtqueues for a virtio device: this helps for debugging and is also needed for upcoming interface change. Also, add a "name" field for clearer debug messages. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- including this Rusty's patch here for completeness.

From: Rusty Russell <rusty at rustcorp.com.au> Add a linked list of all virtqueues for a virtio device: this helps for debugging and is also needed for upcoming interface change. Also, add a "name" field for clearer debug messages. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- including this Rusty's patch here for completeness.

Currently a host kick error is silently ignored and not reflected in the virtqueue of a particular virtio device. Changing the notify API for guest->host notification seems to be one prerequisite in order to be able to handle such errors in the context where the kick is triggered. This patch changes the notify API. The notify function must return a negative int return value in case the host

Rusty, here is just patch 1 (using bool as return value in notify API). Thanks. Heinz Graalfs (9): virtio_ring: change host notification API virtio_ring: let virtqueue_{kick()/notify()} return a bool virtio_net: verify if virtqueue_kick() succeeded virtio_test: verify if virtqueue_kick() succeeded virtio_ring: add new function virtqueue_is_broken() virtio_blk: verify if queue is

Rusty, here is just patch 1 (using bool as return value in notify API). Thanks. Heinz Graalfs (9): virtio_ring: change host notification API virtio_ring: let virtqueue_{kick()/notify()} return a bool virtio_net: verify if virtqueue_kick() succeeded virtio_test: verify if virtqueue_kick() succeeded virtio_ring: add new function virtqueue_is_broken() virtio_blk: verify if queue is

From: Christian Borntraeger <borntraeger at de.ibm.com> This patch implements kvm guest kernel support for paravirtualized devices and contains two parts: o a basic virtio stub using virtio_ring and external interrupts and hypercalls o full hypercall implementation in kvm_para.h Currently we dont have PCI on s390. Making virtio_pci usable for s390 seems more complicated that providing an

From: Christian Borntraeger <borntraeger at de.ibm.com> This patch implements kvm guest kernel support for paravirtualized devices and contains two parts: o a basic virtio stub using virtio_ring and external interrupts and hypercalls o full hypercall implementation in kvm_para.h Currently we dont have PCI on s390. Making virtio_pci usable for s390 seems more complicated that providing an

There is no recent user space application available anymore which still supports this old virtio transport. Additionally, commit 3b2fbb3f06ef ("virtio/s390: deprecate old transport") introduced a deprecation message in the driver, and apparently nobody complained so far that it is still required. So let's simply remove it. Signed-off-by: Thomas Huth <thuth at redhat.com> ---

There is no recent user space application available anymore which still supports this old virtio transport. Additionally, commit 3b2fbb3f06ef ("virtio/s390: deprecate old transport") introduced a deprecation message in the driver, and apparently nobody complained so far that it is still required. So let's simply remove it. Signed-off-by: Thomas Huth <thuth at redhat.com> ---

Hi, this patch-set solves a hang situation when a vlan network device is hot-unplugged from a KVM guest. On System z there exists no handshake mechanism between host and guest when a device is hot-unplugged. The device is removed and no further I/O is possible. The guest is notified about the hard removal with a CRW machine check. As per architecture, the host must repond to any I/O operation

Hi, this patch-set solves a hang situation when a vlan network device is hot-unplugged from a KVM guest. On System z there exists no handshake mechanism between host and guest when a device is hot-unplugged. The device is removed and no further I/O is possible. The guest is notified about the hard removal with a CRW machine check. As per architecture, the host must repond to any I/O operation

We were cheating with our barriers; using the smp ones rather than the real device ones. That was fine, until virtio-mmio came along, which could be talking to a real device (a non-SMP CPU). Unfortunately, just putting back the real barriers (reverting d57ed95d) causes a performance regression on virtio-pci. In particular, Amos reports netbench's TCP_RR over virtio_net CPU utilization

We were cheating with our barriers; using the smp ones rather than the real device ones. That was fine, until virtio-mmio came along, which could be talking to a real device (a non-SMP CPU). Unfortunately, just putting back the real barriers (reverting d57ed95d) causes a performance regression on virtio-pci. In particular, Amos reports netbench's TCP_RR over virtio_net CPU utilization

This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 11 +++--- drivers/char/hw_random/virtio-rng.c | 11 +++--- drivers/char/virtio_console.c | 27

This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 11 +++--- drivers/char/hw_random/virtio-rng.c | 11 +++--- drivers/char/virtio_console.c | 27

Allows maintaining extra context per vq. For ease of use, passing in NULL is legal and disables the feature for all vqs. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/misc/mic/vop/vop_main.c | 9 ++++++--- drivers/s390/virtio/kvm_virtio.c | 6 ++++-- drivers/s390/virtio/virtio_ccw.c | 7 ++++--- drivers/virtio/virtio_mmio.c | 8 +++++---

Allows maintaining extra context per vq. For ease of use, passing in NULL is legal and disables the feature for all vqs. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/misc/mic/vop/vop_main.c | 9 ++++++--- drivers/s390/virtio/kvm_virtio.c | 6 ++++-- drivers/s390/virtio/virtio_ccw.c | 7 ++++--- drivers/virtio/virtio_mmio.c | 8 +++++---

The following changes since commit 3c92ec8ae91ecf59d88c798301833d7cf83f2179: Linus Torvalds (1): Merge branch 'next' of git://git.kernel.org/.../paulus/powerpc are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master

The following changes since commit 3c92ec8ae91ecf59d88c798301833d7cf83f2179: Linus Torvalds (1): Merge branch 'next' of git://git.kernel.org/.../paulus/powerpc are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,