From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH] virtio-balloon spec: rework VIRTIO_BALLOON_F_MUST_TELL_HOST feature, support silent deflation Date: Tue, 28 May 2013 13:45:03 +0300 Message-ID: <20130528104503.GD5467@redhat.com> References: <1368007813-1264-1-git-send-email-pbonzini@redhat.com> <51A381D9.5010800@redhat.com> <20130527160437.GA18270@redhat.com> <51A38552.9050808@redhat.com> <20130527170259.GA18800@redhat.com> <51A46D0B.9080508@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6117 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755737Ab3E1Kom (ORCPT ); Tue, 28 May 2013 06:44:42 -0400 Content-Disposition: inline In-Reply-To: <51A46D0B.9080508@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, May 28, 2013 at 10:38:35AM +0200, Paolo Bonzini wrote: > Il 27/05/2013 19:02, Michael S. Tsirkin ha scritto: > >>> So if we don't want to require all guests to tell host > >>> first, all we need to do is admit it's not a bug. > >> > >> I think we want the possibility for the host to require that. > > > > But why? TELL_HOST makes some optimizations possible, but if > > guest won't cooperate, balloon is useless anyway. > > If the guest won't tell host and still propose the feature, Ack feature but don't tell host? That would be a clear guest bug. AFAIK that's not what windows drivers do. Am I wrong? > then we can > crash it. So we need to know what the guest is going to do, in order to > enable/disable the optimization. > > > If guest cooperates we don't have to require anything, > > just go with what guest tells us it will do. > > Yes. > > >>> Please see > >>> [PATCH] virtio-spec: balloon: MUST_TELL_HOST is optional > >>> that does exactly this. > >> > >> That patch mandates a change in guest behavior that is not compatible > >> with the existing Windows driver. Mine doesn't. > >> > >> Paolo > > > > Hmm I don't see it. > > In fact the goal was to document the Windows driver behaviour > > as correct. > > Can you explain the incompatibility please? > > Whenever "If the X feature is (not) negotiated" is used in the spec, it > means "in general you should be ready to implement both behaviors", or > perhaps the guest should fail to initialize if the feature is not available. "you" meaning host. Yes. But here guest can tell host first *always if it wants to - it will just be a bit slower when reusing pages from balloon. If it acked the feature, it *must* tell host first. > > Here it is the other way round. The existing guest is not checking the > outcome of the negotiation, so the host must check whether negotiation > happened and possibly fail the initialization of the device. It is > sufficiently different from any other case that I don't think a one-word > change is enough. > > The way I read it yesterday I didn't see any change from the current > specification, so the problem of having a "negative feature" remains. This is standard behaviour: - guest can ignore any feature that it does not ack - host must implement both behaviours for guests that do and for guests that do not ack features This is exactly what I'm proposing for TELL_HOST. > Now rereading it, it may be correct, but it is not clear enough. > > Perhaps my patch is even too verbose, but it doesn't leave anything open > for interpretation. > > Paolo I'm fine with adding more clarifications but I don't yet see why do we need a new bit. -- MST