On 09/12/20 15:03, no-re...@patchew.org wrote:
Patchew URL:
https://patchew.org/QEMU/20201209135355.561745-1-mlevi...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20201209135355.561745-1-mlevi...@redhat
This function wraps bdrv_co_delete_file for the common case of removing a file,
which was just created by format driver, on an error condition.
It hides the -ENOTSUPP error, and reports all other errors otherwise.
Signed-off-by: Maxim Levitsky
Reviewed-by: Alberto Garcia
---
block.c
When the underlying block device doesn't support the
bdrv_co_delete_file interface, an 'Error' object was leaked.
Signed-off-by: Maxim Levitsky
Reviewed-by: Alberto Garcia
---
block/crypto.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/crypto.c b/block/crypto.c
index aef5a5721a..
Use the bdrv_co_delete_file interface to delete the underlying
file if qcow2 initialization fails (e.g due to bad encryption secret)
This makes the qcow2 driver behave the same way as the luks driver behaves.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1845353
V3: addressed review feedb
This refactoring is now possible thanks to this function.
Signed-off-by: Maxim Levitsky
Reviewed-by: Alberto Garcia
---
block/crypto.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/block/crypto.c b/block/crypto.c
index b3a5275132..1d30fde38e 100644
--- a/b
If the qcow initialization fails, we should remove the file if it was
already created, to avoid leaving stale files around.
We already do this for luks raw images.
Signed-off-by: Maxim Levitsky
Reviewed-by: Alberto Garcia
---
block/qcow2.c | 6 --
1 file changed, 4 insertions(+), 2 deletio
On Wed, 2020-12-09 at 18:41 +0100, Alberto Garcia wrote:
> On Wed 09 Dec 2020 05:44:41 PM CET, Maxim Levitsky wrote:
> > @@ -3847,12 +3847,13 @@ static int coroutine_fn
> > qcow2_co_create_opts(BlockDriver *drv,
> >
> > /* Create the qcow2 image (format layer) */
> > ret = qcow2_co_cre
On Wed, 2020-12-09 at 18:34 +0100, Alberto Garcia wrote:
> On Wed 09 Dec 2020 05:44:39 PM CET, Maxim Levitsky wrote:
> > +void coroutine_fn bdrv_co_delete_file_noerr(BlockDriverState *bs)
> > +{
> > +Error *local_err = NULL;
> > +
> > +if (!bs) {
> > +return;
> > +}
> > +
> > +
From: Marc-André Lureau
By making libvhost-user a subproject, check it builds
standalone (without the global QEMU cflags etc).
Note that the library still relies on QEMU include/qemu/atomic.h and
linux_headers/.
Signed-off-by: Marc-André Lureau
Message-Id: <20201125100640.366523-6-marcandre.lu
From: Stefan Hajnoczi
Do not validate input with g_return_val_if(). This API is intended for
checking programming errors and is compiled out with -DG_DISABLE_CHECKS.
Use an explicit if statement for input validation so it cannot
accidentally be compiled out.
Suggested-by: Markus Armbruster
Sig
On Wed 09 Dec 2020 05:44:41 PM CET, Maxim Levitsky wrote:
> @@ -3847,12 +3847,13 @@ static int coroutine_fn
> qcow2_co_create_opts(BlockDriver *drv,
>
> /* Create the qcow2 image (format layer) */
> ret = qcow2_co_create(create_options, errp);
> +
> +finish:
> if (ret < 0) {
> -
Am 09.12.2020 um 10:33 hat Daniel P. Berrangé geschrieben:
> On Tue, Dec 08, 2020 at 03:38:22PM +0100, Kevin Wolf wrote:
> > Am 08.12.2020 um 13:59 hat Li Feng geschrieben:
> > > This patch addresses this issue:
> > > When accessing a volume on an NFS filesystem without supporting the file
> > >
On Fri, Dec 04, 2020 at 12:39:07PM -0600, Eric Blake wrote:
> On 12/4/20 10:53 AM, Sergio Lopez wrote:
> > When switching between AIO contexts we need to me make sure that both
> > recv_coroutine and send_coroutine are not scheduled to run. Otherwise,
> > QEMU may crash while attaching the new cont
Am 09.12.2020 um 17:51 hat Sergio Lopez geschrieben:
> On Mon, Dec 07, 2020 at 04:37:53PM +0100, Kevin Wolf wrote:
> > Am 04.12.2020 um 17:53 hat Sergio Lopez geschrieben:
> > > On dataplane start, acquire the new AIO context before calling
> > > 'blk_set_aio_context', releasing it immediately afte
On Wed 09 Dec 2020 05:44:40 PM CET, Maxim Levitsky wrote:
> This refactoring is now possible thanks to this function.
>
> Signed-off-by: Maxim Levitsky
Reviewed-by: Alberto Garcia
Berto
On Wed 09 Dec 2020 05:44:39 PM CET, Maxim Levitsky wrote:
> +void coroutine_fn bdrv_co_delete_file_noerr(BlockDriverState *bs)
> +{
> +Error *local_err = NULL;
> +
> +if (!bs) {
> +return;
> +}
> +
> +int ret = bdrv_co_delete_file(bs, &local_err);
^^^
According to th
On Mon, Dec 07, 2020 at 04:37:53PM +0100, Kevin Wolf wrote:
> Am 04.12.2020 um 17:53 hat Sergio Lopez geschrieben:
> > On dataplane start, acquire the new AIO context before calling
> > 'blk_set_aio_context', releasing it immediately afterwards. This
> > prevents reaching the AIO context attach/det
When the underlying block device doesn't support the
bdrv_co_delete_file interface, an 'Error' object was leaked.
Signed-off-by: Maxim Levitsky
Reviewed-by: Alberto Garcia
---
block/crypto.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/crypto.c b/block/crypto.c
index aef5a5721a..
This function wraps bdrv_co_delete_file for the common case of removing a file,
which was just created by format driver, on an error condition.
It hides the -ENOTSUPP error, and reports all other errors otherwise.
Signed-off-by: Maxim Levitsky
---
block.c | 23
If the qcow initialization fails, we should remove the file if it was
already created, to avoid leaving stale files around.
We already do this for luks raw images.
Signed-off-by: Maxim Levitsky
---
block/qcow2.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/block/qc
This refactoring is now possible thanks to this function.
Signed-off-by: Maxim Levitsky
---
block/crypto.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/block/crypto.c b/block/crypto.c
index b3a5275132..1d30fde38e 100644
--- a/block/crypto.c
+++ b/block/cry
Use the bdrv_co_delete_file interface to delete the underlying
file if qcow2 initialization fails (e.g due to bad encryption secret)
This makes the qcow2 driver behave the same way as the luks driver behaves.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1845353
V3: addressed review feedb
Patchew URL:
https://patchew.org/QEMU/20201209135355.561745-1-mlevi...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20201209135355.561745-1-mlevi...@redhat.com
Subject: [PATCH v2 0/5] SCSI: fix transfer l
On Wed, 2020-12-09 at 06:03 -0800, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20201209135355.561745-1-mlevi...@redhat.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Type: series
> Message-id: 2
On Wed, Dec 9, 2020 at 7:19 AM Peter Lieven wrote:
>
> Am 01.12.20 um 13:40 schrieb Peter Lieven:
> > Hi,
> >
> >
> > i would like to submit a series for 6.0 which will convert the aio hooks to
> > native coroutine hooks and add write zeroes support.
> >
> > The aio routines are nowadays just an
When the device doesn't support the VPD block limits page, we emulate it even
for SCSI passthrough.
As a part of the emulation we need to add it to the 'Supported VPD Pages'
The code that does this adds it to the page, but it doesn't increase the length
of the data to be copied to the guest, thus
Switch file-posix to expose only the max_ioctl_transfer limit.
Let the iscsi driver work as it did before since it is bound by the transfer
limit in both regular read/write and in SCSI passthrough case.
Switch the scsi-disk and scsi-block drivers to read the SG max transfer limits
using the new b
From: Tom Yan
sg devices have different major/minor than their corresponding
block devices. Using sysfs to get max segments never really worked
for them.
Fortunately the sg driver provides an ioctl to get sg_tablesize,
which is apparently equivalent to max segments.
Signed-off-by: Tom Yan
Sign
Maximum transfer size when accessing a kernel block device is only relevant
when using SCSI passthrough (SG_IO ioctl) since only in this case the requests
are passed directly to underlying hardware with no pre-processing.
Same is true when using /dev/sg* character devices (which only support SG_IO)
From: Tom Yan
We can and should get max transfer length and max segments for all host
devices / cdroms (on Linux).
Also use MIN_NON_ZERO instead when we clamp max transfer length against
max segments.
Signed-off-by: Tom Yan
Signed-off-by: Maxim Levitsky
---
block/file-posix.c | 59 ++
This patch series attempts to provide a solution to the problem of the transfer
limits of the raw file driver (host_device/file-posix), some of which I
already tried to fix in the past.
I included 2 patches from Tom Yan which fix two issues with reading the limits
correctly from the */dev/sg* char
09.12.2020 15:32, Vladimir Sementsov-Ogievskiy wrote:
test-aio-multithread: ../util/qemu-coroutine-lock.c:197: qemu_co_mutex_wake:
Assertion `mutex == co->wait_on_mutex' failed.
Thread 18 "test-aio-multit" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe5ffb700 (LWP 2454
09.12.2020 15:32, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
I have a coredump of our qemu branch, based on rhev-2.12.0-44.el7_8.2,
which in turn is based on v2.12.0.. And don't have any kind of
reproduce.
The backtrace:
#0 aio_co_schedule (ctx=0x0, co=0x55dd539fa340) at util/async.c:45
Hi all!
I have a coredump of our qemu branch, based on rhev-2.12.0-44.el7_8.2,
which in turn is based on v2.12.0.. And don't have any kind of
reproduce.
The backtrace:
#0 aio_co_schedule (ctx=0x0, co=0x55dd539fa340) at util/async.c:455
#1 0x55dd51149716 in aio_co_enter (ctx=, co=)
Am 01.12.20 um 13:40 schrieb Peter Lieven:
> Hi,
>
>
> i would like to submit a series for 6.0 which will convert the aio hooks to
> native coroutine hooks and add write zeroes support.
>
> The aio routines are nowadays just an emulation on top of coroutines which
> add additional overhead.
>
> F
nfs_client_open returns the file size in sectors. This effectively
makes it impossible to open files larger than 1TB.
Fixes: a1a42af422d46812f1f0cebe6b230c20409a3731
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Lieven
---
block/nfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Dec 8 10:16, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Commit 37712e00b1f0 ("hw/block/nvme: factor out pmr setup") changed the
> control flow such that the CAP register is erronously cleared after
> nvme_init_pmr() has configured it. Since the entire NvmeCtrl structure
> is zero-filled ini
From: Klaus Jensen
Add support for TP 4065a ("Simple Copy Command"), v2020.05.04
("Ratified").
The implementation uses a bounce buffer to first read in the source
logical blocks, then issue a write of that bounce buffer. The default
maximum number of source logical blocks is 128, translating to
From: Klaus Jensen
Add new data structures and types for the Simple Copy command.
Signed-off-by: Klaus Jensen
Cc: Stefan Hajnoczi
Cc: Fam Zheng
Reviewed-by: Minwoo Im
Acked-by: Stefan Hajnoczi
---
include/block/nvme.h | 45 ++--
1 file changed, 43 in
From: Klaus Jensen
Add support for TP 4065 ("Simple Copy Command").
Changes for v4
* merge for-loops (Keith)
Changes for v3
* rebased on nvme-next
* changed the default msrc value to a more reasonable 127 from 255 to
better align with the default mcl value of 128.
Changes for v2
Hello,
Reviewed-by: Minwoo Im
Although individual qemu-storage-daemon QMP commands are identical to
QEMU QMP commands, qemu-storage-daemon only supports a subset of QEMU's
QMP commands. Generate a manual page of just the commands supported by
qemu-storage-daemon so that users know exactly what is available in
qemu-storage-daemo
The MAINTAINERS file was not updated when the storage daemon was merged.
Signed-off-by: Stefan Hajnoczi
Acked-by: Kevin Wolf
Reviewed-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 68bc160f41..8676730cc9 1
Document the qemu-storage-daemon tool. Most of the command-line options
are identical to their QEMU counterparts. Perhaps Sphinx hxtool
integration could be extended to extract documentation for individual
command-line options so they can be shared. For now the
qemu-storage-daemon simply refers to
v3:
* Address Kevin's comments
v2:
* Drop block-core.json h2 header removal, add an h1 header to
storage-daemon/qapi/qapi-schema.json instead [Kevin]
* Add Examples section to man page [Kevin]
Add documentation for the qemu-storage-daemon program and its QMP commands.
The man page looks lik
On Tue, Oct 06, 2020 at 12:22:55PM +0200, Kevin Wolf wrote:
> Am 10.09.2020 um 16:43 hat Stefan Hajnoczi geschrieben:
> > Although qemu-storage-daemon QMP commands are identical to QEMU QMP
> > commands they are a subset. Generate a manual page of just the commands
> > supported by qemu-storage-dae
On Dec 9 07:13, Keith Busch wrote:
> On Tue, Dec 08, 2020 at 09:33:39AM +0100, Klaus Jensen wrote:
> > +static uint16_t nvme_copy(NvmeCtrl *n, NvmeRequest *req)
> > +{
>
>
>
> > +for (i = 0; i < nr; i++) {
> > +uint32_t _nlb = le16_to_cpu(range[i].nlb) + 1;
> > +if (_nlb > l
Hi Dmitry,
By and large, this looks OK to me. There are still some issues here and
there, and some comments of mine that you did not address, but I will
follow up with patches to fix that. Let's get this merged.
It looks like the nvme-next you rebased on is slightly old and missing
two commits:
On Tue, Dec 08, 2020 at 03:38:22PM +0100, Kevin Wolf wrote:
> Am 08.12.2020 um 13:59 hat Li Feng geschrieben:
> > This patch addresses this issue:
> > When accessing a volume on an NFS filesystem without supporting the file
> > lock,
> > tools, like qemu-img, will complain "Failed to lock byte 100
49 matches
Mail list logo
