similar to: [PATCH] virtio_blk: allow re-reading config space at runtime

On 6 March 2015 at 03:47, James Bottomley <James.Bottomley at hansenpartnership.com> wrote: > From: James Bottomley <JBottomley at Parallels.com> > > The current string_get_size() overflows when the device size goes over > 2^64 bytes because the string helper routine computes the suffix from > the size in bytes. However, the entirety of Linux thinks in terms of >

On 6 March 2015 at 03:47, James Bottomley <James.Bottomley at hansenpartnership.com> wrote: > From: James Bottomley <JBottomley at Parallels.com> > > The current string_get_size() overflows when the device size goes over > 2^64 bytes because the string helper routine computes the suffix from > the size in bytes. However, the entirety of Linux thinks in terms of >

The message printed on disk resize is incorrect. The following is printed when resizing to 2 GiB: $ truncate -s 1G test.img $ qemu -device virtio-blk-pci,logical_block_size=4096,... (qemu) block_resize drive1 2G virtio_blk virtio0: new size: 4194304 4096-byte logical blocks (17.2 GB/16.0 GiB) The virtio_blk capacity config field is in 512-byte sector units regardless of

The message printed on disk resize is incorrect. The following is printed when resizing to 2 GiB: $ truncate -s 1G test.img $ qemu -device virtio-blk-pci,logical_block_size=4096,... (qemu) block_resize drive1 2G virtio_blk virtio0: new size: 4194304 4096-byte logical blocks (17.2 GB/16.0 GiB) The virtio_blk capacity config field is in 512-byte sector units regardless of

On Wed, Jul 26, 2017 at 03:32:23PM +0100, Stefan Hajnoczi wrote: > The message printed on disk resize is incorrect. The following is > printed when resizing to 2 GiB: > > $ truncate -s 1G test.img > $ qemu -device virtio-blk-pci,logical_block_size=4096,... > (qemu) block_resize drive1 2G > > virtio_blk virtio0: new size: 4194304 4096-byte logical blocks (17.2

Fix a theoretical race related to config work handler: a config interrupt might happen after we flush config work but before we reset the device. It will then cause the config work to run during or after reset. Two problems with this: - if this runs after device is gone we will get use after free - access of config while reset is in progress is racy (as layout is changing). As a solution 1.

Fix a theoretical race related to config work handler: a config interrupt might happen after we flush config work but before we reset the device. It will then cause the config work to run during or after reset. Two problems with this: - if this runs after device is gone we will get use after free - access of config while reset is in progress is racy (as layout is changing). As a solution 1.

Print the capacity of the block device when the driver is probed. Many users expect this since SCSI disks (sd) do it. Moreover, kernel dmesg output is the primary source of troubleshooting information so it's helpful to include the disk size there. The capacity is already printed by virtio_blk when a resize event occurs. Extract the code and reuse it from virtblk_probe(). This patch also

This patch adds support for an optional stats vq that works similary to the stats vq provided by virtio-balloon. The purpose of this change is to allow collection of statistics about working virtio-blk devices to easily analyze performance without having to tap into the guest. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc:

This patch adds support for an optional stats vq that works similary to the stats vq provided by virtio-balloon. The purpose of this change is to allow collection of statistics about working virtio-blk devices to easily analyze performance without having to tap into the guest. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc:

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. To fix, cleanup in reverse order of initialization. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. To fix, cleanup in reverse order of initialization. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1

On Fri, Oct 24, 2014 at 12:12 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > If a device appears while module is being removed, > driver will get a callback after we've given up > on the major number. > > In theory this means this major number can get reused > by something else, resulting in a conflict. Yes, there is a tiny race window. > > To fix, cleanup

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- drivers/block/virtio_blk.c | 2 +- 1 file

If a device appears while module is being removed, driver will get a callback after we've given up on the major number. In theory this means this major number can get reused by something else, resulting in a conflict. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git