search for: virtio_drivers

to_vp_device is worth changing to inlined definition. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- drivers/virtio/virtio_pci.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index e3ecc94..7681fe3 100644 --- a/drivers/virtio/virtio_pci.c +++ b/drivers/virtio/virtio_pci.c @@ -98,11 +98,7 @@

to_vp_device is worth changing to inlined definition. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- drivers/virtio/virtio_pci.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index e3ecc94..7681fe3 100644 --- a/drivers/virtio/virtio_pci.c +++ b/drivers/virtio/virtio_pci.c @@ -98,11 +98,7 @@

Hi, when an active virtio block device is hot-unplugged from a KVM guest, running affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. On System z there exists no handshake mechanism between host and guest when a device

Hi, when an active virtio block device is hot-unplugged from a KVM guest, running affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. On System z there exists no handshake mechanism between host and guest when a device

Replace duplicated code in all transports with a single wrapper in virtio.c. The only functional change is in virtio_mmio.c: if a buggy device sends us an interrupt before driver is set, we previously returned IRQ_NONE, now we return IRQ_HANDLED. As this must not happen in practice, this does not look like a big deal. See also commit 3fff0179e33cd7d0a688dab65700c46ad089e934 virtio-pci: do not

Replace duplicated code in all transports with a single wrapper in virtio.c. The only functional change is in virtio_mmio.c: if a buggy device sends us an interrupt before driver is set, we previously returned IRQ_NONE, now we return IRQ_HANDLED. As this must not happen in practice, this does not look like a big deal. See also commit 3fff0179e33cd7d0a688dab65700c46ad089e934 virtio-pci: do not

Hi, here is an updated patch-set with changes as suggested by Michael Tsirkin. When an active virtio block device is hot-unplugged from a KVM guest, running affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. On System z

Hi, here is an updated patch-set with changes as suggested by Michael Tsirkin. When an active virtio block device is hot-unplugged from a KVM guest, running affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. On System z

On 21/11/13 07:47, Michael S. Tsirkin wrote: > On Wed, Nov 20, 2013 at 04:22:00PM +0100, Heinz Graalfs wrote: >> Hi, >> >> when an active virtio block device is hot-unplugged from a KVM guest, running >> affected guest user applications are not aware of any errors that occur due >> to the lost device. This patch-set adds code to avoid further request queueing

On 21/11/13 07:47, Michael S. Tsirkin wrote: > On Wed, Nov 20, 2013 at 04:22:00PM +0100, Heinz Graalfs wrote: >> Hi, >> >> when an active virtio block device is hot-unplugged from a KVM guest, running >> affected guest user applications are not aware of any errors that occur due >> to the lost device. This patch-set adds code to avoid further request queueing

Add an optional notify() callback to virtio_driver. A backend driver can provide this callback to perform actions for a lost device. notify() event values are inherited from virtio_ccw's notify() callback. We might want to support even more of them lateron. notify() return values are defined in include/linux/notifier.h. Signed-off-by: Heinz Graalfs <graalfs at linux.vnet.ibm.com> ---

On Wed, Nov 20, 2013 at 04:22:00PM +0100, Heinz Graalfs wrote: > Hi, > > when an active virtio block device is hot-unplugged from a KVM guest, running > affected guest user applications are not aware of any errors that occur due > to the lost device. This patch-set adds code to avoid further request queueing > when a lost block device is detected, resulting in appropriate error

Add an optional notify() callback to virtio_driver. A backend driver can provide this callback to perform actions for a lost device. notify() event values are inherited from virtio_ccw's notify() callback. We might want to support even more of them lateron. notify() return values are defined in include/linux/notifier.h. Signed-off-by: Heinz Graalfs <graalfs at linux.vnet.ibm.com> ---

Replace duplicated code in all transports with a single wrapper in virtio.c. The only functional change is in virtio_mmio.c: if a buggy device sends us an interrupt before driver is set, we previously returned IRQ_NONE, now we return IRQ_HANDLED. As this must not happen in practice, this does not look like a big deal. See also commit 3fff0179e33cd7d0a688dab65700c46ad089e934 virtio-pci: do not

On Thu, Nov 21, 2013 at 03:43:51PM +0100, Heinz Graalfs wrote: > On 21/11/13 07:47, Michael S. Tsirkin wrote: > >On Wed, Nov 20, 2013 at 04:22:00PM +0100, Heinz Graalfs wrote: > >>Hi, > >> > >>when an active virtio block device is hot-unplugged from a KVM guest, running > >>affected guest user applications are not aware of any errors that occur due >

Hi all, This patch series attempts to come closer to unifying kvm and lguest's usage of virtio. As these two are the first implementations we've seen, I hope making them closer will make future ones closer too. Drivers now unpack their own configuration: their probe() methods are uniform. The configuration mechanism is extensible and can be backed by PCI, a string of bytes, or

Hi all, This patch series attempts to come closer to unifying kvm and lguest's usage of virtio. As these two are the first implementations we've seen, I hope making them closer will make future ones closer too. Drivers now unpack their own configuration: their probe() methods are uniform. The configuration mechanism is extensible and can be backed by PCI, a string of bytes, or

Replace duplicated code in all transports with a single wrapper in virtio.c. The only functional change is in virtio_mmio.c: if a buggy device sends us an interrupt before driver is set, we previously returned IRQ_NONE, now we return IRQ_HANDLED. As this must not happen in practice, this does not look like a big deal. See also commit 3fff0179e33cd7d0a688dab65700c46ad089e934 virtio-pci: do not

Add virtblk_notify() as virtio_driver's notify() callback. When a transport driver is notified that a device disappeared it should invoke this callback to prevent further request queueing. Subsequent block layer calls of virtio_blk's request function will fail, resulting in appropriate I/O errors. Signed-off-by: Heinz Graalfs <graalfs at linux.vnet.ibm.com> ---

Add virtblk_notify() as virtio_driver's notify() callback. When a transport driver is notified that a device disappeared it should invoke this callback to prevent further request queueing. Subsequent block layer calls of virtio_blk's request function will fail, resulting in appropriate I/O errors. Signed-off-by: Heinz Graalfs <graalfs at linux.vnet.ibm.com> ---