When a server advertises an unaligned size but no block sizes, the
code was rounding up to a sector-aligned size (a known limitation of
bdrv_getlength(); maybe 4.1 will fix it to be byte-accurate), then
assuming a request_alignment of 512 (the recommendation of the NBD
spec for maximum
On 3/27/19 7:31 PM, Hannes Reinecke wrote:
> On 3/26/19 5:47 PM, Dongli Zhang wrote:
>> I am reporting an error that the scsi lun cannot initialize successfully
>> when I
>> am emulating megasas scsi controller with qemu.
>>
>> I am not sure if this is issue in qemu or linux kernel.
>>
>> When
The next patch needs access to a device's minimum permitted
alignment, since NBD wants to advertise this to clients. Add
an accessor function, borrowing from blk_get_max_transfer()
for accessing a backend's block limits.
Signed-off-by: Eric Blake
Message-Id:
Add a test for the NBD client workaround in the previous patch. It's
not really feasible for an iotest to assume a specific tracing engine,
so we can't really probe for the new
trace_nbd_parse_blockstatus_compliance to see if the server was fixed
vs. whether the client just worked around the
v1 was here (yes, blast from the past):
https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg00305.html
Since then:
- retitle the iotest (228 is now 241)
- rebase on top of other alignment fixes/workarounds that have
landed in meantime
- hoist test earlier, to demonstrate (according to which
Both NBD_CMD_BLOCK_STATUS and structured NBD_CMD_READ will split their
reply according to bdrv_block_status() boundaries. If the block device
has a request_alignment smaller than 512, but we advertise a block
alignment of 512 to the client, then this can result in the server
reply violating client
On 3/27/19 3:33 PM, John Snow wrote:
>
>
> On 3/27/19 8:49 AM, Vladimir Sementsov-Ogievskiy wrote:
>> bdrv_replace_child() calls bdrv_check_perm() with error_abort on
>> loosening permissions. However file-locking operations may fail even
>> in this case, for example on NFS. And this leads to
On 3/27/19 11:56 AM, Vladimir Sementsov-Ogievskiy wrote:
> 26.03.2019 20:13, Eric Blake wrote:
>> The NBD spec is clear that a server that advertises a minimum block
>> size should reply to NBD_CMD_BLOCK_STATUS with extents aligned
>> accordingly. However, we know that the qemu NBD server
On 3/26/19 2:40 PM, Eric Blake wrote:
> Trying 'qemu-img map -f raw nbd://localhost:10809' causes the
> NBD server to output a scary message:
>
> qemu-nbd: Disconnect client, due to: Failed to read request: Unexpected
> end-of-file before all bytes were read
>
> This is because the NBD
On 3/27/19 8:49 AM, Vladimir Sementsov-Ogievskiy wrote:
> bdrv_replace_child() calls bdrv_check_perm() with error_abort on
> loosening permissions. However file-locking operations may fail even
> in this case, for example on NFS. And this leads to Qemu crash.
>
> Let's ignore such errors, as
> -Original Message-
> From: Andrew Cooper
> Sent: 27 March 2019 18:20
> To: Paul Durrant ; xen-de...@lists.xenproject.org;
> qemu-block@nongnu.org;
> qemu-de...@nongnu.org
> Cc: Kevin Wolf ; Stefano Stabellini
> ; Max Reitz
> ; Stefan Hajnoczi ; Anthony Perard
>
> Subject: Re:
Le mer. 27 mars 2019 18:18, John Snow a écrit :
>
>
> On 3/27/19 5:56 AM, Stefano Garzarella wrote:
> > IEC binary prefixes are already defined in "qemu/units.h",
> > so we can remove redundant definitions in "block/vhdx.h".
> >
> > Signed-off-by: Stefano Garzarella
> > ---
> > block/vhdx.c |
On 27/03/2019 17:32, Paul Durrant wrote:
> The Xen blkif protocol is confusing but discussion with the maintainer
> has clarified that sector based quantities in requests and the 'sectors'
> value advertized in xenstore should always be in terms of 512-byte
> units and not the advertised logical
The Xen blkif protocol is confusing but discussion with the maintainer
has clarified that sector based quantities in requests and the 'sectors'
value advertized in xenstore should always be in terms of 512-byte
units and not the advertised logical 'sector-size' value.
This series fixes xen-block
The Xen blkif protocol requires that sector based quantities should be
interpreted strictly as multiples of 512 bytes. Specifically:
"first_sect and last_sect in blkif_request_segment, as well as
sector_number in blkif_request, are always expressed in 512-byte units."
This patch modifies the
The mail thread at [1] clarifies that the Xen blkif protocol requires that
'sectors' value reported in xenstore is strictly in terms of 512-byte
units and is not dependent on the logical sector size reported in
'sector-size'.
[1]
Patchew URL:
https://patchew.org/QEMU/20190327124915.22265-1-vsement...@virtuozzo.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
On Wed, Mar 27, 2019 at 01:16:49PM -0400, John Snow wrote:
>
>
> On 3/27/19 5:56 AM, Stefano Garzarella wrote:
> > IEC binary prefixes are already defined in "qemu/units.h",
> > so we can remove redundant definitions in "block/vhdx.h".
> >
> > Signed-off-by: Stefano Garzarella
> > ---
> >
On 3/27/19 2:43 AM, Thomas Huth wrote:
> virtio-pci is optional on s390x, e.g. in downstream RHEL builds, it
> is disabled. On s390x, virtio-ccw should be used instead. Other tests
> like 051 or 240 already use virtio-scsi-ccw instead of virtio-scsi-pci
> on s390x, so let's do the same here and
On 3/27/19 5:56 AM, Stefano Garzarella wrote:
> Using IEC binary prefixes in order to make the code more readable,
> with the exception of DEFAULT_LOG_SIZE because it's passed to
> stringify().
>
> Signed-off-by: Stefano Garzarella
Looks good to me;
Reviewed-by: John Snow
On 3/27/19 5:56 AM, Stefano Garzarella wrote:
> IEC binary prefixes are already defined in "qemu/units.h",
> so we can remove redundant definitions in "block/vhdx.h".
>
> Signed-off-by: Stefano Garzarella
> ---
> block/vhdx.c | 3 ++-
> block/vhdx.h | 6 +-
> 2 files changed, 3
26.03.2019 20:13, Eric Blake wrote:
> The NBD spec is clear that a server that advertises a minimum block
> size should reply to NBD_CMD_BLOCK_STATUS with extents aligned
> accordingly. However, we know that the qemu NBD server implementation
> has had a corner-case bug where it is not compliant
25.03.2019 22:01, Eric Blake wrote:
> The NBD spec is clear that when structured replies are active, a
> simple error reply is acceptable to any command except for
> NBD_CMD_READ. However, we were mistakenly requiring structured errors
> for NBD_CMD_BLOCK_STATUS, and hanging up on a server that
Paolo Bonzini writes:
> With aio=thread, adaptive polling makes latency worse rather than
> better, because it delays the execution of the ThreadPool's
> completion bottom half.
>
> event_notifier_poll() does run while polling, detecting that
> a bottom half was scheduled by a worker thread, but
25.03.2019 22:01, Eric Blake wrote:
> When the server replies with a (structured [*]) error to
> NBD_CMD_BLOCK_STATUS, without any extent information sent first, the
> client code was blindly throwing away the server's error code and
> instead telling the caller that EIO occurred. This has been
With aio=thread, adaptive polling makes latency worse rather than
better, because it delays the execution of the ThreadPool's
completion bottom half.
event_notifier_poll() does run while polling, detecting that
a bottom half was scheduled by a worker thread, but because
ctx->notifier is
Le mer. 27 mars 2019 10:56, Stefano Garzarella a
écrit :
> Using IEC binary prefixes in order to make the code more readable,
> with the exception of DEFAULT_LOG_SIZE because it's passed to
> stringify().
>
> Signed-off-by: Stefano Garzarella
> ---
> block/vhdx-log.c | 2 +-
> block/vhdx.c
bdrv_replace_child() calls bdrv_check_perm() with error_abort on
loosening permissions. However file-locking operations may fail even
in this case, for example on NFS. And this leads to Qemu crash.
Let's ignore such errors, as we do already on permission update commit
and abort.
Signed-off-by:
Le mer. 27 mars 2019 10:56, Stefano Garzarella a
écrit :
> IEC binary prefixes are already defined in "qemu/units.h",
> so we can remove redundant definitions in "block/vhdx.h".
>
> Signed-off-by: Stefano Garzarella
> ---
> block/vhdx.c | 3 ++-
> block/vhdx.h | 6 +-
> 2 files changed, 3
On 3/26/19 5:47 PM, Dongli Zhang wrote:
I am reporting an error that the scsi lun cannot initialize successfully when I
am emulating megasas scsi controller with qemu.
I am not sure if this is issue in qemu or linux kernel.
When 'lun=1' is specified, there is "Unexpected response from lun 1
Thanks,
Also please notice that the mentioned commit in the commit message has it’s
commit id changed to b69864e.
Sam
> On 27 Mar 2019, at 2:35, Eric Blake wrote:
>
> On 3/26/19 2:58 PM, Sam Eiderman wrote:
>> Commit fb2105b ("vmdk: Support version=3 in VMDK descriptor files") fixed
>> the
Using IEC binary prefixes in order to make the code more readable,
with the exception of DEFAULT_LOG_SIZE because it's passed to
stringify().
Signed-off-by: Stefano Garzarella
---
block/vhdx-log.c | 2 +-
block/vhdx.c | 4 ++--
block/vhdx.h | 10 ++
3 files changed, 9
v2:
- Included units.h directly in the vhdx.h header file (John, Philippe)
- Added a comment next to DEFAULT_LOG_SIZE definition (Kevin)
- Added a second patch where I fixed some size constants using IEC
binary prefixes.
Note: checkpatch is not happy about a change in vhdx.h but all the
IEC binary prefixes are already defined in "qemu/units.h",
so we can remove redundant definitions in "block/vhdx.h".
Signed-off-by: Stefano Garzarella
---
block/vhdx.c | 3 ++-
block/vhdx.h | 6 +-
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/block/vhdx.c b/block/vhdx.c
Le mer. 27 mars 2019 10:24, Thomas Huth a écrit :
> iotest 235 currently only works with KVM - this is bad for systems where
> it is not available, e.g. CI pipelines. The test also works when using
> "tcg" as accelerator, so we can simply add that to the list of
> accelerators,
> too.
>
>
iotest 235 currently only works with KVM - this is bad for systems where
it is not available, e.g. CI pipelines. The test also works when using
"tcg" as accelerator, so we can simply add that to the list of accelerators,
too.
Signed-off-by: Thomas Huth
---
v2: Do not remove the test from the
virtio-pci is optional on s390x, e.g. in downstream RHEL builds, it
is disabled. On s390x, virtio-ccw should be used instead. Other tests
like 051 or 240 already use virtio-scsi-ccw instead of virtio-scsi-pci
on s390x, so let's do the same here and always use virtio-scsi-ccw on
s390x.
37 matches
Mail list logo
