All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dave@treblig.org>
To: steven.sistare@oracle.com
Cc: qemu-devel@nongnu.org
Subject: Trying cpr
Date: Mon, 21 Apr 2025 13:38:48 +0000	[thread overview]
Message-ID: <aAZKaMkKYPlmBMcZ@gallifrey> (raw)

Hi Steve,
  I've just had a go with cpr-transfer, it's quite interesting.
I was just trying it on my (AMD) desktop.

* I was running with qemu displaying graphics, and after migration
the source display got updated every time I moved my mouse into the
source window; the VM was still stopped, but I guess that means
the source GUI is still parsing the guest VRAM and displaying it.
I'm not sure if there's any other interactions - e.g. is there any
situation where the source GUI will try and write into the shared
guest ram?

* Given that you pass fd's over the CPR socket, had you considered
passing main migration fd's over it as well, that way you'd
only need one incoming.

* The guest noticed the time skew:
  timekeeping watchdog on CPU1: Marking clocksource 'tsc' as unstable because the skew is too large:
     'kvm-clock' wd_nsec: 556248511 wd_new: 4a93129e69 wd_alst: 4a71eaf0aa mask: (all f's)
     'tsc' cs_nsec: 514023131 cs_now: 1047f1d8489 cs_last: 10414538c1 mask: (all f's)
     Clocksource 'tsc' skewed -42225380 ns (-42 ms) over watchdog 'kvm-clock' interval of 556248511 ns (556 ms)
     'kvm-clock' (not 'tsc') is current clocksource

  (That was hand copied, probably with some typos - who knew the
   GUI doesn't let you copy/paste from serial0...)


The source commandline was:
./try/qemu-system-x86_64  -object memory-backend-file,id=ram0,size=4G,mem-path=/dev/shm/qemuram0,share=on -m 4G -machine memory-backend=ram0,aux-ram-share=on -cpu host --enable-kvm -smp 16 -drive if=virtio,file=/discs/more/images/debian-13-nocloud-amd64-daily.qcow2 -qmp stdio

The dest commandline was:
./try/qemu-system-x86_64 -object memory-backend-file,id=ram0,size=4G,mem-path=/dev/shm/qemuram0,share=on -m 4G -machine memory-backend=ram0,aux-ram-share=on -cpu host --enable-kvm -smp 16 -drive if=virtio,file=/discs/more/images/debian-13-nocloud-amd64-daily.qcow2 -incoming tcp:0:44444 -incoming '{"channel-type": "cpr", "addr": { "transport": "socket", "type": "unix", "path": "cpr.sock"}}'

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/


             reply	other threads:[~2025-04-21 13:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-21 13:38 Dr. David Alan Gilbert [this message]
2025-04-21 15:22 ` Trying cpr Dongli Zhang
2025-04-21 17:07   ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aAZKaMkKYPlmBMcZ@gallifrey \
    --to=dave@treblig.org \
    --cc=qemu-devel@nongnu.org \
    --cc=steven.sistare@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.