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
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 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
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
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
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
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
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
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
Hello Fabiano,
First of all thanks a lot for the quick follow up to my issue!
I just want to point out that with only mapped-ram enabled (without
multifd) savevm/loadvm do not lead to a crash but just to an error
according to my (few) experiments (on upstream).
Ciao
Marco
On Thursday, March 27
ned-off-by: Marco Cavenati
---
Hello,
Please note that this depends on my previous fix [0] (which has already
been reviewed) in order to work.
The code in this patch is inspired by commit
0478b030fa2530cbbfc4d6432e8e39a16d06865b that adds the same feature to
QIOChannelFile.
Thank you,
Regards
VMState")
Signed-off-by: Marco Cavenati
---
migration/channel-block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/channel-block.c b/migration/channel-block.c
index fff8d87094..b0477f5b6d 100644
--- a/migration/channel-block.c
+++ b/migration/ch
13 matches
Mail list logo
