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]

Message-ID: <504A0858.4080508@redhat.com>
Date:	Fri, 07 Sep 2012 16:44:40 +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 16:25, Michael S. Tsirkin ha scritto:
>> > 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.
> BTW I don't see a need to avoid deflateq.
> Without MUST_TELL_HOST you can just deflate and then
> bounce telling the host out to a thread.

Yes, that's fine too.

>> > 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.
> This is the MUST_TELL_HOST.

Almost.  One is "the guest, if really needed, can tell the host of
pages".  If not negotiated, and the host does not support it, the host
must break the guest (e.g. fail to offer any virtqueues).

The other is "the guest, though, would prefer not to do so".  It is
different because the guest can proceed in a fallback mode even if the
host doesn't offer it.

You're interpreting features as something that dictates behavior, but
they're really just advisory.  You could negotiate VIRTIO_BLK_F_TOPOLOGY
and end up never reading the fields; you could negotiate
VIRTIO_NET_F_GUEST_ANNOUNCE and never send a guest announcement.

>> > * guest will always do silent deflation: current Windows driver.
> Not exactly. It is not silent. It tells host
> just after use.

Yeah, but no difference from the POV of the driver.

Delaying or avoiding is the same in the end.  The spec says it well: "In
this case, deflation advice is merely a courtesy".

>> > 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.
> So this case is just existing interface. OK.
> 
>> >   ** 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.
>> > 
> This last trickery confuses me.  It just does not make sense to set both
> SILENT and TELL: either you are silent or you tell.

"I can be chatty if you ask me, but I'd rather be silent if you let me".

TELL is a request of the host to the guest; the guest can agree or not.

SILENT is a request of the guest to the host; the host can agree or not.

> What is the benefit of avoiding host notification?
> It seems cleaner for the host to know the state.

Yeah, if you want to do it you can.

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/