linux-kernel - Re: [RFC PATCH 3/4] virtio_balloon: add pressure notification via a new virtqueue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20140120095913.31f8b0fd@redhat.com>
Date:	Mon, 20 Jan 2014 09:59:13 -0500
From:	Luiz Capitulino <lcapitulino@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org, riel@...hat.com,
	aarcange@...hat.com, aquini@...hat.com, mst@...hat.com,
	vdavydov@...allels.com, amit.shah@...hat.com, dfediuck@...hat.com,
	alitke@...hat.com, "Daniel Kiper" <dkiper@...-space.pl>
Subject: Re: [RFC PATCH 3/4] virtio_balloon: add pressure notification via a
 new virtqueue

On Mon, 20 Jan 2014 12:43:45 +1030
Rusty Russell <rusty@...tcorp.com.au> wrote:

> Luiz Capitulino <lcapitulino@...hat.com> writes:
> > On Fri, 17 Jan 2014 09:10:47 +1030
> > Rusty Russell <rusty@...tcorp.com.au> wrote:
> >
> >> Luiz Capitulino <lcapitulino@...hat.com> writes:
> >> > From: Luiz capitulino <lcapitulino@...hat.com>
> >> >
> >> > This commit adds support to a new virtqueue called message virtqueue.
> >> 
> >> OK, this needs a lot of thought (especially since reworking the virtio
> >> balloon is on the TODO list for the OASIS virtio technical committee...)
> >> 
> >> But AFAICT this is a way of explicitly saying "no" to the host's target
> >> (vs the implicit method of just not meeting the target).  I'm not sure
> >> that gives enough information to the host.  On the other hand, I'm not
> >> sure what information we *can* give.
> >> 
> >> Should we instead be counter-proposing a target?
> >
> > The problem is how to estimate a target value. I found it simpler
> > to just try to obey what the host is asking for (and fail if not
> > possible) than trying to make the guest negotiate with the host.
> 
> Understood, but we already do this the other way where the host tells
> the guest how much memory to give up.
> 
> And is a guest expected to automatically inflate the balloon even if the
> host doesn't want the memory, or wait to be asked?

In my current design the guest always waits to be asked. Actually, all
automatic inflates and deflates are started by the host. An advantage
of this approach is that all the logic stays on the host, which makes
things simple as it matches with current balloon design.

Btw, you asked about what information we could provide to the host and
I forgot something important. The vmpressure notification (take a look
at patch 1/4 and patch 2/4) does provide an information that could be
interesting to have in the host: it provides a pressure level ("low",
"medium" or "critical") which is part of kernel's ABI with user-space.

I'm thinking about using this pressure level information to implement
different policies for automatic ballooning, which could be set by
the user or a management tool.

> > >> What does qemu do with this information?
> > >
> > > There are two possible scenarios:
> > >
> > >  1. The balloon driver is currently inflating when it gets under
> > >     pressure
> > >
> > >     QEMU resets "num_pages" to the current balloon size. This
> > >     cancels the on-going inflate
> > >
> > >  2. The balloon driver is not inflating, eg. it's possibly sleeping
> > >
> > >    QEMU issues a deflate
> > >
> > > But note that those scenarios are not supposed to be used with the
> > > current device, they are part of the automatic ballooning feature.
> > > I CC'ed you on the QEMU patch, you can find it here case you didn't
> > > see it:
> > >
> > >  http://marc.info/?l=kvm&m=138988966315690&w=2
> 
> Yes, caught that after I replied; I should have checked first.
> 
> It seems like we are still figuring out how to do ballooning.  The
> best approach in cases like this is to make it simple, so I don't hate
> this.

Good news to me :)

> But note that Daniel Kiper and I have been discussing a new virtio
> balloon for draft 2 of the standard.  I'll CC you when I post that to
> one of the OASIS virtio mailing lists.

Thank you, I appreciate that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/