similar to: [PATCH] virtio: Remove virtio device during shutdown

On Wed, 03/11 10:06, Michael S. Tsirkin wrote: > On Wed, Mar 11, 2015 at 04:09:17PM +0800, Fam Zheng wrote: > > Currently shutdown is nop for virtio devices, but the core code could > > remove things behind us such as MSI-X handler etc. For example in the > > case of virtio-scsi-pci, the device may still try to send interupts, > > which will be on IRQ lines seeing MSI-X

On Wed, 03/11 10:06, Michael S. Tsirkin wrote: > On Wed, Mar 11, 2015 at 04:09:17PM +0800, Fam Zheng wrote: > > Currently shutdown is nop for virtio devices, but the core code could > > remove things behind us such as MSI-X handler etc. For example in the > > case of virtio-scsi-pci, the device may still try to send interupts, > > which will be on IRQ lines seeing MSI-X

On Wed, Mar 11, 2015 at 04:09:17PM +0800, Fam Zheng wrote: > Currently shutdown is nop for virtio devices, but the core code could > remove things behind us such as MSI-X handler etc. For example in the > case of virtio-scsi-pci, the device may still try to send interupts, > which will be on IRQ lines seeing MSI-X disabled. Those interrupts will > be unhandled, and may cause flood.

On Wed, Mar 11, 2015 at 04:09:17PM +0800, Fam Zheng wrote: > Currently shutdown is nop for virtio devices, but the core code could > remove things behind us such as MSI-X handler etc. For example in the > case of virtio-scsi-pci, the device may still try to send interupts, > which will be on IRQ lines seeing MSI-X disabled. Those interrupts will > be unhandled, and may cause flood.

On Wed, Mar 11, 2015 at 06:11:35PM +0800, Fam Zheng wrote: > On Wed, 03/11 10:06, Michael S. Tsirkin wrote: > > On Wed, Mar 11, 2015 at 04:09:17PM +0800, Fam Zheng wrote: > > > Currently shutdown is nop for virtio devices, but the core code could > > > remove things behind us such as MSI-X handler etc. For example in the > > > case of virtio-scsi-pci, the device

On Wed, Mar 11, 2015 at 06:11:35PM +0800, Fam Zheng wrote: > On Wed, 03/11 10:06, Michael S. Tsirkin wrote: > > On Wed, Mar 11, 2015 at 04:09:17PM +0800, Fam Zheng wrote: > > > Currently shutdown is nop for virtio devices, but the core code could > > > remove things behind us such as MSI-X handler etc. For example in the > > > case of virtio-scsi-pci, the device

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 @@

Virtio 1.0 doesn't include a modern balloon device. At some point we'll likely define an incompatible interface with a different ID. But for now, it's not a big change to support a transitional balloon device: this has the advantage of supporting existing drivers, transparently. The only issue is with the stats buffer, which has misaligned fields. Seems easy to fix by prepending a 6

Virtio 1.0 doesn't include a modern balloon device. At some point we'll likely define an incompatible interface with a different ID. But for now, it's not a big change to support a transitional balloon device: this has the advantage of supporting existing drivers, transparently. The only issue is with the stats buffer, which has misaligned fields. Seems easy to fix by prepending a 6

I'm not reposting the drivers this time since they haven't changed significantly. See http://lguest.ozlabs.org/patches for the whole thing, from new-io.patch onwards). Changes since last version: - Switch to our own bus implementation, rather than relying on an implementation-specific bus to back this up. - Make virtio_config_ops much higher-level, don't assume layout of

I'm not reposting the drivers this time since they haven't changed significantly. See http://lguest.ozlabs.org/patches for the whole thing, from new-io.patch onwards). Changes since last version: - Switch to our own bus implementation, rather than relying on an implementation-specific bus to back this up. - Make virtio_config_ops much higher-level, don't assume layout of

The dev_attrs field of struct bus_type is going away soon, dev_groups should be used instead. This converts the virtio bus code to use the correct field. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: <virtualization at lists.linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> ---

The dev_attrs field of struct bus_type is going away soon, dev_groups should be used instead. This converts the virtio bus code to use the correct field. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: <virtualization at lists.linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> ---

This is a note to let you know that I've just added the patch titled virtio: convert bus code to use dev_groups to my driver-core git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git in the driver-core-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the

This is a note to let you know that I've just added the patch titled virtio: convert bus code to use dev_groups to my driver-core git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git in the driver-core-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

These are minor robustness enhancements on top of v8 of the patchset [PATCH v8 00/50] linux: towards virtio-1 guest support http://mid.gmane.org/1417449619-24896-1-git-send-email-mst at redhat.com As that one seems stable and actually seems to work well for people, I'm not respinning it anymore. The main motivation is to prevent us accidentally supporting bad configurations, such as legacy

These are minor robustness enhancements on top of v8 of the patchset [PATCH v8 00/50] linux: towards virtio-1 guest support http://mid.gmane.org/1417449619-24896-1-git-send-email-mst at redhat.com As that one seems stable and actually seems to work well for people, I'm not respinning it anymore. The main motivation is to prevent us accidentally supporting bad configurations, such as legacy