On Tue, Jun 8, 2021 at 5:42 PM Wainer dos Santos Moschetta <
waine...@redhat.com> wrote:
> Hi,
>
> On 6/8/21 11:09 AM, Cleber Rosa wrote:
> > Which can be used to check for any "feature" that is available as a
> > QEMU command line option, and that will return its list of available
> > options.
>
Hi,
On 6/8/21 11:09 AM, Cleber Rosa wrote:
Which can be used to check for any "feature" that is available as a
QEMU command line option, and that will return its list of available
options.
This is a generalization of the list_accel() utility function, which
is itself re-implemented in terms of
On Tue, Jun 8, 2021 at 9:46 PM Eric Blake wrote:
>
> On Tue, Jun 08, 2021 at 07:38:10PM +0300, Nir Soffer wrote:
> > On Tue, Jun 8, 2021 at 12:22 AM Eric Blake wrote:
> > >
> > > On Mon, Jun 07, 2021 at 11:22:04PM +0300, Nir Soffer wrote:
> > > > When zeroing a cluster in an image with backing
12.05.2021 09:42, Vladimir Sementsov-Ogievskiy wrote:
11.05.2021 13:45, Roman Kagan wrote:
On Fri, Apr 16, 2021 at 11:08:54AM +0300, Vladimir Sementsov-Ogievskiy wrote:
Add arguments and logic to support nbd negotiation in the same thread
after successful connection.
Signed-off-by: Vladimir
On Tue, Jun 08, 2021 at 08:18:52PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> drive_backup_prepare() does bdrv_drained_begin() in hope that
> bdrv_drained_end() will be called in drive_backup_clean(). Still we
> need to set state->bs for this to work. That's done too late: a lot of
> failure
08.06.2021 16:16, Paolo Bonzini wrote:
Even though it was only called for devices that have bs->sg set (which
must be character devices), sg_get_max_segments looked at /sys/dev/block
which only works for block devices.
On Linux the sg driver has its own way to provide the maximum number of
On Tue, Jun 08, 2021 at 07:38:10PM +0300, Nir Soffer wrote:
> On Tue, Jun 8, 2021 at 12:22 AM Eric Blake wrote:
> >
> > On Mon, Jun 07, 2021 at 11:22:04PM +0300, Nir Soffer wrote:
> > > When zeroing a cluster in an image with backing file, qemu-img and
> > > qemu-nbd reported the area as a hole.
14.05.2021 00:04, Paolo Bonzini wrote:
On 12/05/21 09:15, Vladimir Sementsov-Ogievskiy wrote:
I don't understand. Why doesn't aio_co_enter go through the ctx !=
qemu_get_current_aio_context() branch and just do aio_co_schedule? That was at
least the idea behind aio_co_wake and
On Tue, Jun 08, 2021 at 03:16:31PM +0200, Paolo Bonzini wrote:
> bs->sg is only true for character devices, but block devices can also
> be used with scsi-block and scsi-generic. Unfortunately BLKSECTGET
> returns bytes in an int for /dev/sgN devices, and sectors in a short
> for block devices,
On Tue, Jun 08, 2021 at 03:16:30PM +0200, Paolo Bonzini wrote:
> For block host devices, I/O can happen through either the kernel file
> descriptor I/O system calls (preadv/pwritev, io_submit, io_uring)
> or the SCSI passthrough ioctl SG_IO.
>
> In the latter case, the size of each transfer can
On Tue, Jun 08, 2021 at 03:16:29PM +0200, Paolo Bonzini wrote:
> I/O to a disk via read/write is not limited by the number of segments allowed
> by the host adapter; the kernel can split requests if needed, and the limit
> imposed by the host adapter can be very low (256k or so) to avoid that
On Tue, Jun 08, 2021 at 03:16:28PM +0200, Paolo Bonzini wrote:
> Even though it was only called for devices that have bs->sg set (which
> must be character devices), sg_get_max_segments looked at /sys/dev/block
> which only works for block devices.
>
> On Linux the sg driver has its own way to
08.06.2021 20:24, Vladimir Sementsov-Ogievskiy wrote:
[try add gitlab issue email to cc, will see how it work :)]
That was bad idea. The message becomes a new comment at issue page. Formatting
is broken, looks bad. I've removed that comment
08.06.2021 20:18, Vladimir Sementsov-Ogievskiy
[try add gitlab issue email to cc, will see how it work :)]
08.06.2021 20:18, Vladimir Sementsov-Ogievskiy wrote:
drive_backup_prepare() does bdrv_drained_begin() in hope that
bdrv_drained_end() will be called in drive_backup_clean(). Still we
need to set state->bs for this to work. That's done
On 08/06/2021 17.35, Alex Bennée wrote:
Thomas Huth writes:
On 08/06/2021 16.27, Alex Bennée wrote:
Richard Henderson writes:
On 6/4/21 8:53 AM, Alex Bennée wrote:
The assumption that the qemu-system-aarch64 image can run all 32 bit
machines is about to be broken...
Um, what?
Really
drive_backup_prepare() does bdrv_drained_begin() in hope that
bdrv_drained_end() will be called in drive_backup_clean(). Still we
need to set state->bs for this to work. That's done too late: a lot of
failure paths in drive_backup_prepare() miss setting state->bs. Fix
that.
Fixes:
On Tue, Jun 8, 2021 at 12:22 AM Eric Blake wrote:
>
> On Mon, Jun 07, 2021 at 11:22:04PM +0300, Nir Soffer wrote:
> > When zeroing a cluster in an image with backing file, qemu-img and
> > qemu-nbd reported the area as a hole. This does not affect the guest
> > since the area is read as zero, but
On 6/8/21 11:01 AM, Thomas Huth wrote:
On 08/06/2021 16.27, Alex Bennée wrote:
Richard Henderson writes:
On 6/4/21 8:53 AM, Alex Bennée wrote:
The assumption that the qemu-system-aarch64 image can run all 32 bit
machines is about to be broken...
Um, what?
Really what we want is to
Thomas Huth writes:
> On 08/06/2021 16.27, Alex Bennée wrote:
>> Richard Henderson writes:
>>
>>> On 6/4/21 8:53 AM, Alex Bennée wrote:
The assumption that the qemu-system-aarch64 image can run all 32 bit
machines is about to be broken...
>>>
>>> Um, what?
>> Really what we want is
On 08/06/2021 16.27, Alex Bennée wrote:
Richard Henderson writes:
On 6/4/21 8:53 AM, Alex Bennée wrote:
The assumption that the qemu-system-aarch64 image can run all 32 bit
machines is about to be broken...
Um, what?
Really what we want is to probe the -M (machines) that a binary
On 6/8/21 7:27 AM, Alex Bennée wrote:
Richard Henderson writes:
On 6/4/21 8:53 AM, Alex Bennée wrote:
The assumption that the qemu-system-aarch64 image can run all 32 bit
machines is about to be broken...
Um, what?
Really what we want is to probe the -M (machines) that a binary
supports
On 08/06/2021 16.41, Alex Bennée wrote:
Thomas Huth writes:
On 08/06/2021 15.42, John Snow wrote:
On 6/4/21 11:53 AM, Alex Bennée wrote:
The assumption that the qemu-system-aarch64 image can run all 32 bit
machines is about to be broken and besides it's not likely this is
What's changing?
On 08/06/2021 16.27, Alex Bennée wrote:
Richard Henderson writes:
On 6/4/21 8:53 AM, Alex Bennée wrote:
The assumption that the qemu-system-aarch64 image can run all 32 bit
machines is about to be broken...
Um, what?
Really what we want is to probe the -M (machines) that a binary
Thomas Huth writes:
> On 08/06/2021 15.42, John Snow wrote:
>> On 6/4/21 11:53 AM, Alex Bennée wrote:
>>> The assumption that the qemu-system-aarch64 image can run all 32 bit
>>> machines is about to be broken and besides it's not likely this is
>> What's changing? I'm not deeply familiar with
On 08/06/2021 15.42, John Snow wrote:
On 6/4/21 11:53 AM, Alex Bennée wrote:
The assumption that the qemu-system-aarch64 image can run all 32 bit
machines is about to be broken and besides it's not likely this is
What's changing? I'm not deeply familiar with aarch64. Why is this
assumption
Richard Henderson writes:
> On 6/4/21 8:53 AM, Alex Bennée wrote:
>> The assumption that the qemu-system-aarch64 image can run all 32 bit
>> machines is about to be broken...
>
> Um, what?
Really what we want is to probe the -M (machines) that a binary
supports rather than just barfing the
On Tue, Jun 08, 2021 at 01:00:08PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 03.06.2021 00:27, Eric Blake wrote:
> > On Fri, Apr 16, 2021 at 11:08:51AM +0300, Vladimir Sementsov-Ogievskiy
> > wrote:
> > > Signed-off-by: Vladimir Sementsov-Ogievskiy
> > > ---
> > > block/nbd.c | 43
On Tue, Jun 08, 2021 at 10:00:01AM +0200, Emanuele Giuseppe Esposito wrote:
> > > Oh, I see - you abandon the iteration in all control flow paths, so
> > > the simpler loop is still okay. Still, this confused me enough on
> > > first read that it may be worth a comment, maybe:
> > >
> > > /* No
This introduces three different parts of a job designed to run
on a custom runner managed by Red Hat. The goals include:
a) serve as a model for other organizations that want to onboard
their own runners, with their specific platforms, build
configuration and tests.
b) bring awareness
Which can be used to check for any "feature" that is available as a
QEMU command line option, and that will return its list of available
options.
This is a generalization of the list_accel() utility function, which
is itself re-implemented in terms of the more generic feature.
Signed-off-by:
In this context, and according to the qemu.utils.list_feature() utility
function, a feature is something is available as a QEMU command line
option that can take the "help" value.
This builds on top of that utility function, and allows test writers
to require, for instance, the "x-remote"
GCC from CentOS Stream 8 is erroring out on a possibily unitialized
varible.
Full version info for the compiler used:
gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-1)
Signed-off-by: Cleber Rosa
---
block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block.c b/block.c
index
This builds on top the "GitLab Custom Runners and Jobs (was: QEMU
Gating CI)" series, showing an example of how other entities can
add their own custom jobs to the GitLab CI pipeline.
First of all, it may be useful to see an actual pipeline (and the
reespective job introduced here) combined with
On 6/4/21 11:53 AM, Alex Bennée wrote:
The assumption that the qemu-system-aarch64 image can run all 32 bit
machines is about to be broken and besides it's not likely this is
What's changing? I'm not deeply familiar with aarch64. Why is this
assumption about to be broken?
improving out
On Tue, Jun 08, 2021 at 09:03:21PM +0800, zhenwei pi wrote:
> On 6/8/21 8:59 PM, Stefan Hajnoczi wrote:
> > On Tue, Jun 08, 2021 at 08:19:20PM +0800, zhenwei pi wrote:
> > > On 6/8/21 4:07 PM, Stefan Hajnoczi wrote:
> > > > On Tue, Jun 08, 2021 at 10:52:05AM +0800, zhenwei pi wrote:
> > > > > On
bs->sg is only true for character devices, but block devices can also
be used with scsi-block and scsi-generic. Unfortunately BLKSECTGET
returns bytes in an int for /dev/sgN devices, and sectors in a short
for block devices, so account for that in the code.
The maximum transfer also need not be
I/O to a disk via read/write is not limited by the number of segments allowed
by the host adapter; the kernel can split requests if needed, and the limit
imposed by the host adapter can be very low (256k or so) to avoid that SG_IO
returns EINVAL if memory is heavily fragmented.
Since this value
From: Joelle van Dyne
Some BSD platforms do not have this header.
Reviewed-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Joelle van Dyne
Message-Id: <20210315180341.31638-...@getutm.app>
Signed-off-by: Paolo Bonzini
---
block.c | 2 +-
meson.build | 1 +
2 files
From: Joelle van Dyne
iOS hosts do not have these defined so we fallback to the
default behaviour.
Co-authored-by: Warner Losh
Reviewed-by: Peter Maydell
Signed-off-by: Joelle van Dyne
Message-Id: <20210315180341.31638-...@getutm.app>
Signed-off-by: Paolo Bonzini
---
block/file-posix.c |
For block host devices, I/O can happen through either the kernel file
descriptor I/O system calls (preadv/pwritev, io_submit, io_uring)
or the SCSI passthrough ioctl SG_IO.
In the latter case, the size of each transfer can be limited by the
HBA, while for file descriptor I/O the kernel is able to
From: Joelle van Dyne
On Darwin (iOS), there are no system level APIs for directly accessing
host block devices. We detect this at configure time.
Signed-off-by: Joelle van Dyne
Message-Id: <20210315180341.31638-...@getutm.app>
Signed-off-by: Paolo Bonzini
---
block/file-posix.c | 33
Hi Kevin,
this is a combination of two series that both affect host block device
support in block/file-posix.c. Joelle's series is unchanged, while
mine was adjusted according to your review of v2.
v1->v2: add missing patch
v2->v3: add max_hw_transfer to BlockLimits
v3->v4: fix compilation
Even though it was only called for devices that have bs->sg set (which
must be character devices), sg_get_max_segments looked at /sys/dev/block
which only works for block devices.
On Linux the sg driver has its own way to provide the maximum number of
iovecs in a scatter/gather list, so add
On 6/8/21 8:59 PM, Stefan Hajnoczi wrote:
On Tue, Jun 08, 2021 at 08:19:20PM +0800, zhenwei pi wrote:
On 6/8/21 4:07 PM, Stefan Hajnoczi wrote:
On Tue, Jun 08, 2021 at 10:52:05AM +0800, zhenwei pi wrote:
On 6/7/21 11:08 PM, Stefan Hajnoczi wrote:
On Mon, Jun 07, 2021 at 09:32:52PM +0800,
On Tue, Jun 08, 2021 at 08:19:20PM +0800, zhenwei pi wrote:
> On 6/8/21 4:07 PM, Stefan Hajnoczi wrote:
> > On Tue, Jun 08, 2021 at 10:52:05AM +0800, zhenwei pi wrote:
> > > On 6/7/21 11:08 PM, Stefan Hajnoczi wrote:
> > > > On Mon, Jun 07, 2021 at 09:32:52PM +0800, zhenwei pi wrote:
> > > > >
On 6/8/21 4:07 PM, Stefan Hajnoczi wrote:
On Tue, Jun 08, 2021 at 10:52:05AM +0800, zhenwei pi wrote:
On 6/7/21 11:08 PM, Stefan Hajnoczi wrote:
On Mon, Jun 07, 2021 at 09:32:52PM +0800, zhenwei pi wrote:
Since 2020, I started to develop a userspace NVMF initiator library:
08.06.2021 14:12, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
[...]
TODO: We also need to deprecate drive-backup transaction action..
But union members in QAPI doesn't support 'deprecated' feature. I tried
to dig a bit, but failed :/ Markus, could you please help with it?
Vladimir Sementsov-Ogievskiy writes:
[...]
> TODO: We also need to deprecate drive-backup transaction action..
> But union members in QAPI doesn't support 'deprecated' feature. I tried
> to dig a bit, but failed :/ Markus, could you please help with it? At
> least by advice?
There are two
03.06.2021 20:49, Vladimir Sementsov-Ogievskiy wrote:
03.06.2021 19:17, Eric Blake wrote:
On Fri, Apr 16, 2021 at 11:08:55AM +0300, Vladimir Sementsov-Ogievskiy wrote:
Add an option for thread to retry connection until success. We'll use
for a thread to retry connection until it succeeds.
On Fri, Jun 04, 2021 at 08:52:26AM +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> This series reimplements flush, dsm, copy, zone reset and format nvm to
> allow cancellation. I posted an RFC back in March ("hw/block/nvme:
> convert ad-hoc aio tracking to aiocb") and I've applied some
11.05.2021 23:54, Roman Kagan wrote:
On Fri, Apr 16, 2021 at 11:08:55AM +0300, Vladimir Sementsov-Ogievskiy wrote:
Add an option for thread to retry connection until success. We'll use
nbd/client-connection both for reconnect and for initial connection in
nbd_open(), so we need a possibility to
02.06.2021 22:14, Eric Blake wrote:
On Fri, Apr 16, 2021 at 11:08:47AM +0300, Vladimir Sementsov-Ogievskiy wrote:
We are going to split connection code to separate file. Now we are
to a separate
ready to give nbd_co_establish_connection() clean and bs-independent
interface.
Signed-off-by:
03.06.2021 00:27, Eric Blake wrote:
On Fri, Apr 16, 2021 at 11:08:51AM +0300, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/nbd.c | 43 ++-
1 file changed, 26 insertions(+), 17 deletions(-)
Commit message
07.06.2021 21:13, Eric Blake wrote:
On Wed, May 05, 2021 at 10:50:00AM +0300, Vladimir Sementsov-Ogievskiy wrote:
We are generally moving to int64_t for both offset and bytes parameters
on all io paths.
Main motivation is realization of 64-bit write_zeroes operation for
fast zeroing large disk
On Tue, Jun 08, 2021 at 10:52:05AM +0800, zhenwei pi wrote:
> On 6/7/21 11:08 PM, Stefan Hajnoczi wrote:
> > On Mon, Jun 07, 2021 at 09:32:52PM +0800, zhenwei pi wrote:
> > > Since 2020, I started to develop a userspace NVMF initiator library:
> > > https://github.com/bytedance/libnvmf
> > > and
On 07/06/2021 11:23, Paolo Bonzini wrote:
On 04/06/21 18:16, Eric Blake wrote:
On Fri, Jun 04, 2021 at 12:07:36PM +0200, Emanuele Giuseppe Esposito
wrote:
Extract to a separate function. Do not rely on FOREACH_SAFE, which is
only "safe" if the *current* node is removed---not if another
Add a CoMutex to protect concurrent access of block-copy
data structures.
This mutex also protects .copy_bitmap, because its thread-safe
API does not prevent it from assigning two tasks to the same
bitmap region.
.finished, .cancelled and reads to .ret and .error_is_read will be
protected in the
By adding acquire/release pairs, we ensure that .ret and .error_is_read
fields are written by block_copy_dirty_clusters before .finished is true.
The atomic here are necessary because the fields are concurrently modified
also outside coroutines.
Signed-off-by: Emanuele Giuseppe Esposito
---
As done in BlockCopyCallState, categorize BlockCopyTask
and BlockCopyState in IN, State and OUT fields.
This is just to understand which field has to be protected with a lock.
.sleep_state is handled in the series "coroutine: new sleep/wake API"
and thus here left as TODO.
Signed-off-by:
From: Paolo Bonzini
Put the logic to determine the copy size in a separate function, so
that there is a simple state machine for the possible methods of
copying data from one BlockDriverState to the other.
Use .method instead of .copy_range as in-out argument, and
include also .zeroes as an
Moving this function in task_end ensures to update the progress
anyways, even if there is an error.
It also helps in next patch, allowing task_end to have only
one critical section.
Reviewed-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Emanuele Giuseppe Esposito
---
block/block-copy.c | 6
This serie of patches aims to reduce the usage of the
AioContexlock in block-copy, by introducing smaller granularity
locks thus on making the block layer thread safe.
This serie depends on my previous serie that brings thread safety
to the smaller API used by block-copy, like ratelimit,
On 6/7/21 7:23 PM, Thomas Huth wrote:
> In downstream, we want to use a different name for the QEMU binary,
> and some people might also use the docs for non-x86 binaries, that's
> why we already created the |qemu_system| placeholder in the past.
> Use it now in the live-block-operations doc, too.
63 matches
Mail list logo
