Patchew URL:
https://patchew.org/QEMU/20200527203733.16129-1-vsement...@virtuozzo.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
On 5/27/20 3:37 PM, Vladimir Sementsov-Ogievskiy wrote:
This is the only coroutine wrapper from block.c and block/io.c which
doesn't return value, so let's convert it to the common behavior, to
s/value/a value/
simplify moving to generated coroutine wrappers in further commit.
s/in/in a/
On 5/27/20 4:46 PM, no-re...@patchew.org wrote:
Patchew URL:
https://patchew.org/QEMU/20200527203733.16129-1-vsement...@virtuozzo.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can
Patchew URL:
https://patchew.org/QEMU/20200527203733.16129-1-vsement...@virtuozzo.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178
On 5/27/20 3:53 PM, Roman Kagan wrote:
---
v5 -> v6:
- add prop_size32 instead of going with 64bit
Would it be worth adding prop_size32 as its own patch, before using it here?
I've no strong opinion on this. Should I better split it out when
respinning?
Patch splitting is an art-form.
On Wed, May 27, 2020 at 09:50:39AM -0500, Eric Blake wrote:
> On 5/27/20 7:45 AM, Roman Kagan wrote:
> > Several BlockConf properties represent respective sizes in bytes so it
> > makes sense to accept size suffixes for them.
> >
> > Turn them all into uint32_t and use size-suffix-capable
Use code generation implemented in previous commit to generated
coroutine wrappers in block.c and block/io.c
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/coroutines.h| 7 +-
include/block/block.h | 17 ++-
block.c | 73
block/io.c| 260
Like for read/write in a previous commit, drop extra indirection layer,
generate directly bdrv_readv_vmstate() and bdrv_writev_vmstate().
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
---
block/coroutines.h| 10 +++
include/block/block.h | 6 ++--
block/io.c
We are going to keep coroutine-wrappers code (structure-packing
parameters, BDRV_POLL wrapper functions) in separate auto-generated
files. So, we'll need a header with declaration of original _co_
functions, for those which are static now. As well, we'll need
declarations for wrapper functions. Do
Now that we are not maintaining boilerplate code for coroutine
wrappers, there is no more sense in keeping the extra indirection layer
of bdrv_prwv(). Let's drop it and instead generate pure bdrv_preadv()
and bdrv_pwritev().
Currently, bdrv_pwritev() and bdrv_preadv() are returning bytes on
Most of our coroutine wrappers already follow this convention:
We have 'coroutine_fn bdrv_co_()' as
the core function, and a wrapper 'bdrv_()' which does a polling loop.
The only outsiders are the bdrv_prwv_co and
bdrv_common_block_status_above wrappers. Let's refactor them to behave
as the
We have a very frequent pattern of creating coroutine from function
with several arguments:
- create structure to pack parameters
- create _entry function to call original function taking parameters
from struct
- do different magic to handle completion: set ret to NOT_DONE or
This is the only coroutine wrapper from block.c and block/io.c which
doesn't return value, so let's convert it to the common behavior, to
simplify moving to generated coroutine wrappers in further commit.
Also, bdrv_invalidate_cache is a void function, returning error only
through **errp
Hi all!
The aim of the series is to reduce code-duplication and writing
parameters structure-packing by hand around coroutine function wrappers.
It's an alternative to "[PATCH v3] block: Factor out bdrv_run_co()"
patch.
Benefits:
- no code duplication
- less indirection
v5: mostly by Eric's
21.05.2020 21:32, John Snow wrote:
On 5/19/20 7:41 AM, Kevin Wolf wrote:
Am 19.05.2020 um 13:32 hat Vladimir Sementsov-Ogievskiy geschrieben:
19.05.2020 12:07, Kevin Wolf wrote:
Am 18.05.2020 um 18:12 hat Thomas Huth geschrieben:
On 15/05/2020 23.15, Vladimir Sementsov-Ogievskiy wrote:
On 5/25/20 1:08 PM, Alberto Garcia wrote:
Signed-off-by: Alberto Garcia
---
tests/qemu-iotests/271 | 705 +
tests/qemu-iotests/271.out | 603 +++
tests/qemu-iotests/group | 1 +
3 files changed, 1309 insertions(+)
On 5/25/20 1:08 PM, Alberto Garcia wrote:
Now that the implementation of subclusters is complete we can finally
add the necessary options to create and read images with this feature,
which we call "extended L2 entries".
Signed-off-by: Alberto Garcia
---
Reviewed-by: Eric Blake
--
Eric
On 5/25/20 1:08 PM, Alberto Garcia wrote:
This works now at the subcluster level and pwrite_zeroes_alignment is
updated accordingly.
qcow2_cluster_zeroize() is turned into qcow2_subcluster_zeroize() with
the following changes:
- The request can now be subcluster-aligned.
- The
On 5/25/20 1:08 PM, Alberto Garcia wrote:
The L2 bitmap needs to be updated after each write to indicate what
new subclusters are now allocated. This needs to happen even if the
cluster was already allocated and the L2 entry was otherwise valid.
In some cases however a write operation doesn't
On 5/25/20 1:08 PM, Alberto Garcia wrote:
Two things need to be taken into account here:
1) With full_discard == true the L2 entry must be cleared completely.
This also includes the L2 bitmap if the image has extended L2
entries.
2) With full_discard == false we have to make the
On 5/25/20 1:08 PM, Alberto Garcia wrote:
The QCOW_OFLAG_ZERO bit that indicates that a cluster reads as
zeroes is only used in standard L2 entries. Extended L2 entries use
individual 'all zeroes' bits for each subcluster.
This must be taken into account when updating the L2 entry and also
when
On 5/25/20 1:08 PM, Alberto Garcia wrote:
The logic of this function remains pretty much the same, except that
it uses count_contiguous_subclusters(), which combines the logic of
count_contiguous_clusters() / count_contiguous_clusters_unallocated()
and checks individual subclusters.
On 5/25/20 1:08 PM, Alberto Garcia wrote:
If an image has subclusters then there are more copy-on-write
scenarios that we need to consider. Let's say we have a write request
from the middle of subcluster #3 until the end of the cluster:
1) If we are writing to a newly allocated cluster then we
On 5/27/20 7:45 AM, Roman Kagan wrote:
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessary tight, and we've seen bigger block sizes handy
unnecessarily
at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches
On 5/27/20 7:45 AM, Roman Kagan wrote:
Several BlockConf properties represent respective sizes in bytes so it
makes sense to accept size suffixes for them.
Turn them all into uint32_t and use size-suffix-capable setters/getters
on them; introduce DEFINE_PROP_SIZE32 and adjust
On 5/27/20 7:45 AM, Roman Kagan wrote:
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
---
Reviewed-by: Eric Blake
--
Eric Blake,
On 5/27/20 7:45 AM, Roman Kagan wrote:
Several block device properties related to blocksize configuration must
be in certain relationship WRT each other: physical block must be no
smaller than logical block; min_io_size, opt_io_size, and
discard_granularity must be a multiple of a logical block.
On Wed, May 27, 2020 at 10:28:44AM -0400, John Snow wrote:
>
>
> On 5/26/20 11:25 AM, Daniel P. Berrangé wrote:
> > On Tue, May 26, 2020 at 05:23:42PM +0200, Philippe Mathieu-Daudé wrote:
> >> On 5/26/20 5:22 PM, Daniel P. Berrangé wrote:
> >>> On Mon, May 18, 2020 at 08:27:54PM -0400, John Snow
Hi Stefan
On Fri, May 22, 2020 at 7:18 PM Stefan Hajnoczi wrote:
>
> Many vhost devices in QEMU currently do not involve the device backend
> in feature negotiation. This seems fine at first glance for device types
> without their own feature bits (virtio-net has many but other device
> types
On 5/26/20 11:25 AM, Daniel P. Berrangé wrote:
> On Tue, May 26, 2020 at 05:23:42PM +0200, Philippe Mathieu-Daudé wrote:
>> On 5/26/20 5:22 PM, Daniel P. Berrangé wrote:
>>> On Mon, May 18, 2020 at 08:27:54PM -0400, John Snow wrote:
On 5/18/20 3:33 PM, Vladimir
On 5/27/20 4:51 AM, Alberto Garcia wrote:
On Tue 26 May 2020 10:32:08 PM CEST, Eric Blake wrote:
+/* The subcluster X [0..31] is allocated */
+#define QCOW_OFLAG_SUB_ALLOC(X) (1ULL << (X))
+/* The subcluster X [0..31] reads as zeroes */
+#define QCOW_OFLAG_SUB_ZERO(X)
On Fri, May 08, 2020 at 08:24:52AM +0200, Philippe Mathieu-Daudé wrote:
> Let the NVMe emulated device be target-agnostic.
>
> It is not clear if dccvap_writefn() really needs
> memory_region_writeback() or could use memory_region_msync().
>
> Philippe Mathieu-Daudé (4):
> memory: Rename
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessary tight, and we've seen bigger block sizes handy
at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches the qcow2 cluster size limit.
Signed-off-by: Roman Kagan
Several BlockConf properties represent respective sizes in bytes so it
makes sense to accept size suffixes for them.
Turn them all into uint32_t and use size-suffix-capable setters/getters
on them; introduce DEFINE_PROP_SIZE32 and adjust DEFINE_PROP_BLOCKSIZE
for that. (Making them uint64_t and
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
---
v4 -> v5:
- split out into separate patch [Philippe]
hw/core/qdev-properties.c | 21
Several block device properties related to blocksize configuration must
be in certain relationship WRT each other: physical block must be no
smaller than logical block; min_io_size, opt_io_size, and
discard_granularity must be a multiple of a logical block.
To ensure these requirements are met,
The width of opt_io_size in virtio_blk_config is 32bit. However, it's
written with virtio_stw_p; this may result in value truncation, and on
big-endian systems with legacy virtio in completely bogus readings in
the guest.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
BlockConf includes several properties counted in bytes.
Enhance their handling in a some aspects, specifically
- accept common size suffixes (k, m)
- perform consistency checks on the values
- lift the upper limit on physical_block_size and logical_block_size
Also fix the accessor for
26.05.2020 23:26, Andrey Shinkevich wrote:
Add dirty bitmap information to QCOW2 metadata dump in qcow2.py script.
The sample output:
Header extension: Bitmaps
magic 0x23852875
length24
nb_bitmaps2
reserved320
27.05.2020 00:34, Eric Blake wrote:
On 5/25/20 5:08 AM, Vladimir Sementsov-Ogievskiy wrote:
Now, when we are not more paying extra code for coroutine wrappers,
there no more sence in extra indirection layer: bdrv_prwv(). Let's drop
it and instead genereate pure bdrv_preadv() and bdrv_pwritev().
27.05.2020 00:30, Eric Blake wrote:
On 5/25/20 5:07 AM, Vladimir Sementsov-Ogievskiy wrote:
We have a very frequent pattern of creating coroutine from function
with several arguments:
- create structure to pack parameters
- create _entry function to call original function taking
On Wed, May 27, 2020 at 11:29:23AM +0100, Stefan Hajnoczi wrote:
> Automatically size the number of virtio-scsi-pci, vhost-scsi-pci, and
> vhost-user-scsi-pci request virtqueues to match the number of vCPUs.
> Other transports continue to default to 1 request virtqueue.
IIRC this was raised on
Automatically size the number of virtio-blk-pci request virtqueues to
match the number of vCPUs. Other transports continue to default to 1
request virtqueue.
A 1:1 virtqueue:vCPU mapping ensures that completion interrupts are
handled on the same vCPU that submitted the request. No IPI is
Automatically size the number of request virtqueues to match the number
of vCPUs. This ensures that completion interrupts are handled on the
same vCPU that submitted the request. No IPI is necessary to complete
an I/O request and performance is improved.
Signed-off-by: Stefan Hajnoczi
The event and control virtqueues are always present, regardless of the
multi-queue configuration. Define a constant so that virtqueue number
calculations are easier to read.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Cornelia Huck
---
include/hw/virtio/virtio-scsi.h | 3 +++
Automatically size the number of virtio-scsi-pci, vhost-scsi-pci, and
vhost-user-scsi-pci request virtqueues to match the number of vCPUs.
Other transports continue to default to 1 request virtqueue.
A 1:1 virtqueue:vCPU mapping ensures that completion interrupts are
handled on the same vCPU that
Multi-queue devices achieve the best performance when each vCPU has a
dedicated queue. This ensures that virtqueue used notifications are
handled on the same vCPU that submitted virtqueue buffers. When another
vCPU handles the the notification an IPI will be necessary to wake the
submission vCPU
v3:
* Introduce virtio_pci_optimal_num_queues() helper to enforce VIRTIO_QUEUE_MAX
in one place
* Use VIRTIO_SCSI_VQ_NUM_FIXED constant in all cases [Cornelia]
* Update hw/core/machine.c compat properties for QEMU 5.0 [Michael]
v3:
* Add new performance results that demonstrate the
On Tue 26 May 2020 10:32:08 PM CEST, Eric Blake wrote:
>> +/* The subcluster X [0..31] is allocated */
>> +#define QCOW_OFLAG_SUB_ALLOC(X) (1ULL << (X))
>> +/* The subcluster X [0..31] reads as zeroes */
>> +#define QCOW_OFLAG_SUB_ZERO(X)(QCOW_OFLAG_SUB_ALLOC(X) << 32)
>> +/* Subclusters [X,
On 5/26/20 6:42 PM, Kevin Wolf wrote:
Am 25.05.2020 um 18:41 hat Kevin Wolf geschrieben:
Am 25.05.2020 um 16:18 hat Stefan Reiter geschrieben:
On 5/12/20 4:43 PM, Kevin Wolf wrote:
Coroutine functions that are entered through bdrv_run_co() are already
safe to call from synchronous code in a
On 5/27/20 6:49 AM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> On 5/26/20 11:31 AM, Philippe Mathieu-Daudé wrote:
>>> +Laurent
>>>
>>> On 5/26/20 11:04 AM, Markus Armbruster wrote:
Philippe Mathieu-Daudé writes:
> On 5/26/20 9:38 AM, Markus Armbruster wrote:
52 matches
Mail list logo
