All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eric Wheeler <qemu-devel@lists.ewheeler.net>
Cc: qemu-devel@nongnu.org, peterx@redhat.com
Subject: Re: [Qemu-devel] Migration without memory page transfer
Date: Fri, 27 Apr 2018 10:24:14 +0100	[thread overview]
Message-ID: <20180427092413.GA2609@work-vm> (raw)
In-Reply-To: <alpine.LRH.2.11.1804262308190.12327@mail.ewheeler.net>

* Eric Wheeler (qemu-devel@lists.ewheeler.net) wrote:
> Hello all,

Hi Eric,

> This is my first time inside of the qemu code, so your help is greatly 
> appreciated!
> 
> I have been experimenting with stop/start of VMs to/from a migration 
> stream that excludes RAM pages and let the RAM pages come from memory file 
> provided by the memory-backend-file called '/dev/shm/mem'.
> 
> To disable writing of memory pages to the migration stream, I've disabled 
> calls to ram_find_and_save_block in ram_save_iterate() and 
> ram_save_complete() (see patch below).  Thus, the migration stream has the 
> "ram" SaveStateEntry section start/ends, but no pages:

You're in luck, because someone else has just done something very
similar.

> qemu-system-x86_64 \
> 	-object memory-backend-file,prealloc=no,mem-path=/dev/shm/mem,id=ram-node0,host-nodes=0,policy=bind,size=64m,share=on \
> 	-numa node,nodeid=0,cpus=0,memdev=ram-node0\
> 	-m 64 -vnc 0:0
> 
> Once the VM is running, I press ctrl-B to get the IPXE prompt and then 
> run 'kernel http://192.168.0.1/foo' to start a network request and watch 
> it in tcpdump.
> 
> Once the download starts, I save the migration file:
> 	migrate "exec:cat > /dev/shm/t"
> 
> 	# ls -lh /dev/shm/t
> 	-rw-r--r-- 1 root root 321K Apr 26 16:06 /dev/shm/t
> 
> Now I can kill qemu and boot it again with -incoming:
> 
> qemu-system-x86_64 \
> 	-object memory-backend-file,prealloc=no,mem-path=/dev/shm/mem,id=ram-node0,host-nodes=0,policy=bind,size=64m,share=on \
> 	-numa node,nodeid=0,cpus=0,memdev=ram-node0\
> 	-m 64 -vnc 0:0 \
> 	-incoming 'exec:cat /dev/shm/t'
> 
> It seems to work.  That is, network traffic continues (http from IPXE) 
> which I can see from tcpdump.  I can type into the console and it moves 
> the cursor around---but there is nothing on the screen except the blinking 
> text-mode cursor!  I can even blindly start a new transfer in ipxe: kernel 
> http://192.168.0.222/foo2 and see it in tcpdump.
> 
> So what am I missing here?  Is the video memory not saved to /dev/shm/mem?
> 
> Or perhaps it is saved, but VGA isn't initialized to use what is 
> already in /dev/shm/mem?  I've tried the cirrus, std, and vmware drivers 
> to see if they behave differently, but the do not seem to.

They have their own RAMBlocks, not the main RAM, so that does need
migrating.

The patch here:
   http://lists.gnu.org/archive/html/qemu-devel/2018-04/msg00003.html

should do what you want.
You need to turn on the bypass-shared-memory capability.
   migrate_set_capability bypass-shared-memory on

Dave


> Thanks for your help!


> --
> Eric Wheeler
> 
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 021d583..9f4bfff 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2267,9 +2267,9 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
>      t0 = qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
>      i = 0;
>      while ((ret = qemu_file_rate_limit(f)) == 0) {
> -        int pages;
> +        int pages = 0;
>  
> -        pages = ram_find_and_save_block(rs, false);
> +        if (0) pages = ram_find_and_save_block(rs, false);
>          /* no more pages to sent */
>          if (pages == 0) {
>              done = 1;
> @@ -2338,9 +2338,9 @@ static int ram_save_complete(QEMUFile *f, void *opaque)
>  
>      /* flush all remaining blocks regardless of rate limiting */
>      while (true) {
> -        int pages;
> +        int pages = 0;
>  
> -        pages = ram_find_and_save_block(rs, !migration_in_colo_state());
> +        if (0) pages = ram_find_and_save_block(rs, !migration_in_colo_state());
>          /* no more blocks to sent */
>          if (pages == 0) {
>              break;
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

      parent reply	other threads:[~2018-04-27  9:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 23:33 [Qemu-devel] Migration without memory page transfer Eric Wheeler
2018-04-27  2:45 ` Peter Xu
2018-05-05 20:30   ` Eric Wheeler
2018-04-27  9:24 ` Dr. David Alan Gilbert [this message]

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=20180427092413.GA2609@work-vm \
    --to=dgilbert@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@lists.ewheeler.net \
    --cc=qemu-devel@nongnu.org \
    /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.