similar to: [PATCH V2 RFC 0/9] virtio: fix hang(loop) after hot-unplug vlan

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

Hi, this patch-set tries to solve various hang situations when virtio devices (network or block) are 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

Hi, this patch-set tries to solve various hang situations when virtio devices (network or block) are 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

Rusty, and here is patch 9 as you suggested. 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 broken after

Rusty, and here is patch 9 as you suggested. 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 broken after

Recent changes to drivers/virtio broke compilation for the tests in tools/virtio. The following patches are build fixes for those changes, as well as a fix for a typo that would have never built. The changes were tested on my amd64 system against 3.14-rc2. Joel Stanley (3): tools/virtio: update internal copies of headers tools/virtio: fix missing kmemleak_ignore symbol tools/virtio: add a

Recent changes to drivers/virtio broke compilation for the tests in tools/virtio. The following patches are build fixes for those changes, as well as a fix for a typo that would have never built. The changes were tested on my amd64 system against 3.14-rc2. Joel Stanley (3): tools/virtio: update internal copies of headers tools/virtio: fix missing kmemleak_ignore symbol tools/virtio: add a

"Michael S. Tsirkin" <mst at redhat.com> writes: > On Tue, Feb 11, 2014 at 04:58:17PM +1030, Joel Stanley wrote: >> Recent changes to drivers/virtio broke compilation for the tests in >> tools/virtio. The following patches are build fixes for those changes, as well >> as a fix for a typo that would have never built. >> >> The changes were tested

"Michael S. Tsirkin" <mst at redhat.com> writes: > On Tue, Feb 11, 2014 at 04:58:17PM +1030, Joel Stanley wrote: >> Recent changes to drivers/virtio broke compilation for the tests in >> tools/virtio. The following patches are build fixes for those changes, as well >> as a fix for a typo that would have never built. >> >> The changes were tested

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use sleep + timeout instead of busy polling. Please review. Thanks Changes since RFC: - switch to use BAD_RING in virtio_break_device() - check virtqueue_is_broken() after being woken up - use

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver, and generic

On 29/01/14 07:31, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> On 23/01/14 05:51, Rusty Russell wrote: >>> Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >>>> Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. >>> >>> Hi Heinz, >>> >>> I didn't

On 29/01/14 07:31, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> On 23/01/14 05:51, Rusty Russell wrote: >>> Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >>>> Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. >>> >>> Hi Heinz, >>> >>> I didn't

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo

The following changes since commit 33807f4f0daec3b00565c2932d95f614f5833adf: Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 (2014-03-11 11:53:42 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/virtio-next-for-linus for you to fetch changes up to fc4324b4597c4eb8907207e82f9a6acec84dd335:

The following changes since commit 33807f4f0daec3b00565c2932d95f614f5833adf: Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 (2014-03-11 11:53:42 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/virtio-next-for-linus for you to fetch changes up to fc4324b4597c4eb8907207e82f9a6acec84dd335:

Current error handling of virtqueue_kick() was wrong in two places: - The skb were freed immediately when virtqueue_kick() fail during xmit. This may lead double free since the skb was not detached from the virtqueue. - try_fill_recv() returns false when virtqueue_kick() fail. This will lead unnecessary rescheduling of refill work. Actually, it's safe to just ignore the kick failure in