06.09.2019 22:57, Maxim Levitsky wrote:
> This commit tries to clarify few function arguments,
> and add comments describing the encrypt/decrypt interface
>
> Signed-off-by: Maxim Levitsky
> ---
> block/qcow2-cluster.c | 10 +++
> block/qcow2-threads.c | 61
Currently, attaching zoned block devices (i.e., storage devices
compliant to ZAC/ZBC standards) using several virtio methods doesn't
work properly as zoned devices appear as regular block devices at the
guest. This may cause unexpected i/o errors and, potentially, some
data corruption.
To be more
This commit adds Zoned Device Model (as defined in T10 ZBC and
T13 ZAC standards) as a block driver property, along with some
useful access functions.
A new backend driver permission, BLK_PERM_SUPPORT_HM_ZONED, is also
introduced. Only the drivers having this permission will be allowed
to open
The purpose of this patch is to recognize a zoned block device (ZBD)
when it is opened as a raw file. The new code initializes the zoned
model propery introduced by the previous commit.
This commit is Linux-specific as it gets the Zoned Block Device Model
value (none/host-managed/host-aware) from
Abort opening a zoned device as a raw file in case the chosen
block backend driver lacks proper support for this type of
storage.
Signed-off-by: Dmitry Fomichev
Reviewed-by: Stefan Hajnoczi
---
block/file-posix.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
Added a new boolean argument to blkconf_apply_backend_options()
to let the common block code know whether the chosen block
backend can handle host managed zoned block devices.
blkconf_apply_backend_options() then sets BLK_PERM_SUPPORT_HM_ZONED
permission accordingly. The raw code can then use
06.09.2019 19:01, Anton Nefedov wrote:
> Signed-off-by: Anton Nefedov
Reviewed-by: Vladimir Sementsov-Ogievskiy
> ---
> hw/scsi/scsi-disk.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index
I received an off-list report of failure to connect to an NBD server
expecting an x509 certificate, when the client was attempting something
similar to this command line:
$ ./x86_64-softmmu/qemu-system-x86_64 -name 'blah' -machine q35 -nodefaults \
-object
06.09.2019 22:57, Maxim Levitsky wrote:
> This fixes subtle corruption introduced by luks threaded encryption
> in commit 8ac0f15f335
My fault, I'm sorry :( And great thanks for investigating this!
>
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1745922
>
> The corruption happens
