On Fri, May 09, 2025 at 11:14:41PM +0200, Marco Cavenati wrote:
> On Friday, May 09, 2025 18:21 CEST, Peter Xu wrote:
>
> > So you don't really need to take sequence of snapshots? Hmm, that sounds
> > like a completely different use case that I originally thought.
>
> Correct
>
> > Have you t
On Friday, May 09, 2025 18:21 CEST, Peter Xu wrote:
> So you don't really need to take sequence of snapshots? Hmm, that sounds
> like a completely different use case that I originally thought.
Correct
> Have you thought of leveraging ignore-shared and MAP_PRIVATE for the major
> chunk of gues
On Fri, May 09, 2025 at 02:51:47PM +0200, Marco Cavenati wrote:
> Hello Peter,
>
> On Thursday, May 08, 2025 22:23 CEST, Peter Xu wrote:
>
> > > The scenarios where zeroing is not required (incoming migration and
> > > -loadvm) share a common characteristic: the VM has not yet run in the
> > > c
Hello Peter,
On Thursday, May 08, 2025 22:23 CEST, Peter Xu wrote:
> > The scenarios where zeroing is not required (incoming migration and
> > -loadvm) share a common characteristic: the VM has not yet run in the
> > current QEMU process.
> > To avoid splitting read_ramblock_mapped_ram(), could
On Thu, Apr 24, 2025 at 03:44:49PM +0200, Marco Cavenati wrote:
> > If we decide we need to explicitly select that new code, I don't think
> > we need any new capability, because the user has no choice in it. We
> > know that loadvm needs it, but -loadvm doesn't, any other sort of
> > mapped-ram mi
On Thursday, April 17, 2025 17:12 CEST, Fabiano Rosas wrote:
> For enabling mapped-ram generically at this point I think we don't have
> much choice but to introduce a new version of read_ramblock_mapped_ram()
> that writes zero pages. It would need to discriminate the zero pages,
> (instead of d
"Marco Cavenati" writes:
> On Tuesday, April 15, 2025 15:50 CEST, Fabiano Rosas wrote:
>
>> > So, I see your point on performance, but I'm not fully comfortable
>> > with the difference in zero page handling between mapped-ram on
>> > and mapped-ram off. In the former case zero pages are skipped
On Tuesday, April 15, 2025 15:50 CEST, Fabiano Rosas wrote:
> > So, I see your point on performance, but I'm not fully comfortable
> > with the difference in zero page handling between mapped-ram on
> > and mapped-ram off. In the former case zero pages are skipped, while
> > in the latter they ar
"Marco Cavenati" writes:
> On Friday, April 11, 2025 14:24 CEST, Fabiano Rosas wrote:
>
>> > If bitmap 0 implies zero page, we could call `ram_handle_zero`
>> > in `read_ramblock_mapped_ram` for the clear bits.
>> > Or do you fear this might be unnecessary expensive for migration?
>>
>> Yes, un
On Tue, 15 Apr 2025 at 16:33, Daniel P. Berrangé wrote:
> Because that's what the QEMU API specification declares
> * Not all implementations will support this facility, so may report
> * an error. To avoid errors, the caller may check for the feature
> * flag QIO_CHANNEL_FEATURE_SEEKABLE prior
On Tue, Apr 15, 2025 at 05:27:02PM +0530, Prasad Pandit wrote:
> On Tue, 15 Apr 2025 at 16:33, Daniel P. Berrangé wrote:
> > Because that's what the QEMU API specification declares
> > * Not all implementations will support this facility, so may report
> > * an error. To avoid errors, the caller
Hi,
On Tue, 15 Apr 2025 at 15:51, Daniel P. Berrangé wrote:
> It is actually NOT really connected to lseek, and as such
* For file and fd channels _FEATURE_SEEKABLE is set when/if lseek(2) works.
->
https://gitlab.com/qemu-project/qemu/-/commit/401e311ff72e0a62c834bfe466de68a82cfd90cb
>
On Tue, Apr 15, 2025 at 04:14:08PM +0530, Prasad Pandit wrote:
> Hi,
>
> On Tue, 15 Apr 2025 at 15:51, Daniel P. Berrangé wrote:
> > It is actually NOT really connected to lseek, and as such
>
> * For file and fd channels _FEATURE_SEEKABLE is set when/if lseek(2) works.
> ->
> https://git
On Fri, Apr 04, 2025 at 01:49:44PM +0530, Prasad Pandit wrote:
> On Thu, 27 Mar 2025 at 20:03, Marco Cavenati
> wrote:
> > Enable the use of the mapped-ram migration feature with savevm/loadvm
> > snapshots by adding the QIO_CHANNEL_FEATURE_SEEKABLE feature to
> > QIOChannelBlock. Implement io_pr
On Friday, April 11, 2025 14:24 CEST, Fabiano Rosas wrote:
> > If bitmap 0 implies zero page, we could call `ram_handle_zero`
> > in `read_ramblock_mapped_ram` for the clear bits.
> > Or do you fear this might be unnecessary expensive for migration?
>
> Yes, unfortunately the peformance differen
"Marco Cavenati" writes:
> On Thursday, April 10, 2025 21:52 CEST, Fabiano Rosas wrote:
>
>> We'll need to add the infrastructure to reject multifd and direct-io
>> before this. The rest of the capabilities should not affect mapped-ram,
>> so it's fine (for now) if we don't honor them.
>
> Ok, t
On Thursday, April 10, 2025 21:52 CEST, Fabiano Rosas wrote:
> We'll need to add the infrastructure to reject multifd and direct-io
> before this. The rest of the capabilities should not affect mapped-ram,
> so it's fine (for now) if we don't honor them.
Ok, thanks for the update.
> What about
Marco Cavenati writes:
> Enable the use of the mapped-ram migration feature with savevm/loadvm
> snapshots by adding the QIO_CHANNEL_FEATURE_SEEKABLE feature to
> QIOChannelBlock. Implement io_preadv and io_pwritev methods to provide
> positioned I/O capabilities that don't modify the channel's p
On Mon, 7 Apr 2025 at 14:31, Marco Cavenati wrote:
> As you said the capability is used internally. Its goal is to signal to
> other QEMU code that the QIOChannel is seekable.
> 'qio_channel_pwritev' and 'qio_channel_preadv' can be used only if
> the QIOChannel has the 'QIO_CHANNEL_FEATURE_SEEKABL
On Tuesday, April 08, 2025 07:25 CEST, Prasad Pandit wrote:
> * _channel_preadv/_writev functions are generic. They are independent
> of whether the underlying channel is file or socket or memory or
> something else. They are called if and when they are defined and they
> in turn call channel sp
Hello,
On Monday, April 07, 2025 08:47 CEST, Prasad Pandit wrote:
> * If seeking is managed internally by pread(2)/pwrite(2) and co.
> functions, then that is independent of the
> 'QIO_CHANNEL_FEATURE_SEEKABLE' flag; This flag is QEMU specific, it is
> not available outside of QEMU/io/ system. p
Hi,
On Fri, 4 Apr 2025 at 17:35, Marco Cavenati wrote:
> The QIO_CHANNEL_FEATURE_SEEKABLE flag is set to indicate that
> the channel supports seekable operations. This flag is more about
> signaling capability rather than dictating the use of the specific
> lseek(2) function.
* Yes.
> In this c
On Friday, April 04, 2025 12:14 CEST, Prasad Pandit wrote:
> * If the r/w pointer adjustment (lseek(2)) is not required, then why
> set the '*_FEATURE_SEEKABLE' flag?
The QIO_CHANNEL_FEATURE_SEEKABLE flag is set to indicate that
the channel supports seekable operations. This flag is more about
Hi,
On Fri, 4 Apr 2025 at 14:35, Marco Cavenati wrote:
> Almost. Unlike lseek(2), pread(2) and co. do not have side effects on the
> fd's offset.
> From the man page:
> > The pread() and pwrite() system calls are especially useful in
> > multithreaded applications. They allow multiple threads
Hello Prasad,
On Friday, April 04, 2025 10:19 CEST, Prasad Pandit wrote:
> * IIUC, when _FEATURE_SEEKABLE is set, the channel I/O sequence
> eventually makes underlying preadv(2)/pwritev(2) calls, which use
> lseek(2) to adjust the stream r/w pointer with the given offset,
> before doing the r/w
On Thu, 27 Mar 2025 at 20:03, Marco Cavenati wrote:
> Enable the use of the mapped-ram migration feature with savevm/loadvm
> snapshots by adding the QIO_CHANNEL_FEATURE_SEEKABLE feature to
> QIOChannelBlock. Implement io_preadv and io_pwritev methods to provide
> positioned I/O capabilities that
Enable the use of the mapped-ram migration feature with savevm/loadvm
snapshots by adding the QIO_CHANNEL_FEATURE_SEEKABLE feature to
QIOChannelBlock. Implement io_preadv and io_pwritev methods to provide
positioned I/O capabilities that don't modify the channel's position
pointer.
Signed-off-by:
27 matches
Mail list logo
