All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Pankaj Gupta <pagupta@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>,
	aarcange@redhat.com, Luiz Capitulino <lcapitulino@redhat.com>,
	qemu-devel@nongnu.org, gal@redhat.com
Subject: Re: [Qemu-devel] balloon vs postcopy migrate
Date: Tue, 3 Feb 2015 17:38:16 +0000	[thread overview]
Message-ID: <20150203173815.GL2332@work-vm> (raw)
In-Reply-To: <1032377914.4158867.1422984992735.JavaMail.zimbra@redhat.com>

* Pankaj Gupta (pagupta@redhat.com) wrote:
> 
> > Hi,
> >   Andrea pointed out there is a risk that a guest inflating its
> > balloon during a postcopy migrate could cause us problems, and
> > I wanted to see what the best way of avoiding the problem was.
> > 
> > Guests inflating there balloon cause an madvise(MADV_DONTNEED) on
> > the host, marking pages as not present, that will potentially trigger
> > a userfault, that we are using in postcopy to detect pages that need
> > to be fetched from the source.
> > 
> > In theory, at the moment guests *should* only ask for a balloon
> > inflation if they've been asked to do so by the host; however there
> > are no guards for that, and it's been suggested giving the
> > guest more freedom might be a good idea anyway.
> > 
> > My alternatives seem to be:
> >    1) Stop servicing the message queue from the guest so
> >      that we just don't notice the inflate messages until
> >      afterwards.  (Easy for Qemu, not sure how the guests
> >      will like an unserviced queue).
> > 
> >    2) I could keep servicing the queue and ignore the messages
> >      (Easy for everyone, not very nice in actual used memory -
> >       does it cause any long term problems other than that?)
> > 
> >    3) I could keep servicing the queue but put the messages
> >      in a list somewhere that replay after migrate has finished.
> >      (That list sounds bounded only in a very large way?)
> > 
> > Thoughts?
> 
> Can we have some global flag somewhere when Post copy is ON/active.
> And we can ignore or defer only inflate/ballon messages/commands while 
> servicing the commands with some warnings.
> 
> Just my thought on logic. Not sure if I am missing some background here.

Oh yes, the global flag is the easy part; the only question is what
the best thing to do is when it's set.

Dave

> 
> > 
> > Dave
> > 
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
> > 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2015-02-03 17:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-03 17:09 [Qemu-devel] balloon vs postcopy migrate Dr. David Alan Gilbert
2015-02-03 17:36 ` Pankaj Gupta
2015-02-03 17:38   ` Dr. David Alan Gilbert [this message]
2015-02-10 18:49 ` 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=20150203173815.GL2332@work-vm \
    --to=dgilbert@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=gal@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=pagupta@redhat.com \
    --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.