From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N7qhH-000739-IJ for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:23:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N7qhC-00072h-TG for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:23:46 -0500 Received: from [199.232.76.173] (port=53382 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N7qhC-00072a-Kh for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:23:42 -0500 Received: from mail2.shareable.org ([80.68.89.115]:57886) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N7qhC-0001Sv-9o for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:23:42 -0500 Date: Tue, 10 Nov 2009 13:23:36 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning (V2) Message-ID: <20091110132336.GB28509@shareable.org> References: <1257782838.2835.5.camel@aglitke> <20091109190001.GA3808@shareable.org> <4AF88672.8080102@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF88672.8080102@us.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: agl@linux.vnet.ibm.com, qemu-devel@nongnu.org, Avi Kivity Anthony Liguori wrote: > Jamie Lokier wrote: > >Adam Litke wrote: > > > >>+ s->stats.pswapin = has_feature(dev, > >>VIRTIO_BALLOON_F_RPT_SWAP_OUT) ? > >>+ dev->stats.pswapin : -1; > >> > > > >(etc.) > > > >Why not simply have the guest fill in the unused fields with -1, and > >say that's how "no meaningful value" is represented in the ABI? > > > >All guests have to know about all those fields anyway, for the > >structure layout. Is there any benefit to specifying feature bits in > >advance over simply storing -1 there? > > > > Features are negotiated. It lets a host advertise the support of a > feature and it lets the guest acknowledge it's support of a feature. > > Most importantly, why invent a new mechanism when we already have one? In this case, the guest already has to have those fields in the structure. It's not like something where the guest doesn't know about a feature at all, and then a later driver adds new capabilities. That would require feature bits or an ABI version, I agree. But the real motivation for my comment was seeing the bulk of the patch being definitions and tests for lots of feature bits which do something trivial that the guest can easily do. The feature bits don't seem to simplify anything in this case. As for preparing to be consistent with future additions, presumably if another 20 fields are added, there won't be sufficient bits in the feature word anyway, so an "extended feature bits" feature will be needed. -- Jamie