linux-kernel - Re: [PATCH] virtio-balloon spec: provide a version of the "silent deflate" feature that works

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 07 Sep 2012 16:04:13 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
CC:	Rusty Russell <rusty@...tcorp.com.au>, fes@...gle.com,
	aarcange@...hat.com, riel@...hat.com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, mikew@...gle.com, yinghan@...gle.com,
	virtualization@...ts.linux-foundation.org, yvugenfi@...hat.com,
	vrozenfe@...hat.com
Subject: Re: [PATCH] virtio-balloon spec: provide a version of the "silent
 deflate" feature that works

Il 07/09/2012 14:44, Michael S. Tsirkin ha scritto:
>> Well, according to your reading of the spec.
>>
>> In the spec I'm reading "Host must be told before pages from the balloon
>> are used".  Doesn't say anything about the guest.
> 
> No? How is host told then? By divine force?

For a simple madvise-based implementation such as the one in QEMU, the
host doesn't need to be told about anything (except periodic updating of
the "actual" field, or the statsq).

The guest doesn't need at all to use the deflateq in fact.

>> Now, indeed a very free interpretation is "Guest will tell host before
>> pages from the balloon are used".  It turns out that it's exactly what
>> guests have been doing, hence that's exactly what I'm proposing now:
>> rename the feature to VIRTIO_BALLOON_F_WILL_TELL_HOST.
> 
> Rename is fine.

Cool.

>> Yes, that part we agree on I think.  We disagree that (after the rename)
>> QEMU should start always proposing VIRTIO_BALLOON_F_WILL_TELL_HOST.
> 
> Not always. It must be off if compatibility with old qemu is disabled.

Yes, of course.

>> _Plus_ adding the new feature bit, which is needed to actually tell the
> 
> This part I do not get.  What is silent deflate, why is it useful
> and what it has to do with what we are discussing here?

Silent deflate is deflating just by using the page, without using the
deflateq at all.  So it can be done even from GFP_ATOMIC context.

But knowing that the guest will _not_ deflate silently also benefits the
host. This is the cause of unpinning ballooned pages and pinning them
again upon deflation. This allows cooperative memory overcommit even if
the guests' memory is pinned, similar to what Xen did before it
supported overcommit.  This is the second feature bit.

There are three cases:

* guest will never do silent deflation: current Linux driver.  Host may
do munlock/mlock dance.  Negotiates VIRTIO_BALLOON_F_WILL_TELL_HOST
only, features = VIRTIO_BALLOON_F_WILL_TELL_HOST.

* guest will always do silent deflation: current Windows driver.
Negotiates nothing, or if it cares it can negotiate
VIRTIO_BALLOON_F_SILENT_DEFLATE.  Host mustn't do munlock/mlock dance.

* guest may do silent deflation if available: combo of Linux driver +
Frank's driver.  Negotiates both features, looks at
VIRTIO_BALLOON_F_SILENT_DEFLATE host feature to decide how to behave:

  ** If PCI passthrough, the host will not negotiate
     VIRTIO_BALLOON_F_SILENT_DEFLATE.  The driver will behave as the
     current Linux driver, the host can do the munlock/mlock dance.

  ** If no PCI passthrough, the host will negotiate
     VIRTIO_BALLOON_F_SILENT_DEFLATE, and the driver can balloon more
     aggressively and not use the deflateq.

Paolo
--
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/