[Qemu-devel] balloon vs postcopy migrate

[Qemu-devel] balloon vs postcopy migrate

[Dr. David Alan Gilbert]

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?

Dave

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

Re: [Qemu-devel] balloon vs postcopy migrate

[Pankaj Gupta]

> 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.

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

Re: [Qemu-devel] balloon vs postcopy migrate

[Dr. David Alan Gilbert]

* 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

Re: [Qemu-devel] balloon vs postcopy migrate

[Dr. David Alan Gilbert]

* Dr. David Alan Gilbert (dgilbert@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?)


As a follow up question; why is 'balloon_page' part of virtio-balloon.c
rather than balloon.c ?

I'm thinking of implementing (3) by putting a queue in front
of balloon_page, but it seems to make more sense to put that
type of thing in shared code (migration shouldn't need to know
it's virtio that's the transport?)

Dave

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