From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4w0g-0003S9-B8 for qemu-devel@nongnu.org; Tue, 06 Mar 2012 10:09:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4w0H-0005nv-RC for qemu-devel@nongnu.org; Tue, 06 Mar 2012 10:09:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4w0H-0005ng-Jk for qemu-devel@nongnu.org; Tue, 06 Mar 2012 10:08:41 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q26F8d61003297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Mar 2012 10:08:39 -0500 Date: Tue, 6 Mar 2012 17:08:50 +0200 From: "Michael S. Tsirkin" Message-ID: <20120306150850.GG12096@redhat.com> References: <1331036527-7651-1-git-send-email-pbonzini@redhat.com> <1331036527-7651-3-git-send-email-pbonzini@redhat.com> <20120306145529.GF12096@redhat.com> <4F562669.7060703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F562669.7060703@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/3] virtio-balloon: note optional features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: amit.shah@redhat.com, uobergfe@redhat.com, owasserm@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com On Tue, Mar 06, 2012 at 03:59:53PM +0100, Paolo Bonzini wrote: > Il 06/03/2012 15:55, Michael S. Tsirkin ha scritto: > > > It is not a problem if the destination does not have > > > VIRTIO_BALLOON_F_MUST_TELL_HOST. In that case, the guest > > > will simply do useless virtqueue traffic, but the destination > > > does not have a problem. > > > (In fact, it _is_ a problem if the destination has > > > VIRTIO_BALLOON_F_MUST_TELL_HOST but the source does not. > > > The feature bit should have been backwards! Luckily, > > > our implementation is free from this problem). > > > > > > Signed-off-by: Paolo Bonzini > > > > Can't we just add a flag to control this feature? > > I think the sane thing here would be to remove it from the spec. > > Paolo I guess we could but what does it buy us? -- MST