From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cornelia Huck Subject: Re: [PATCH RFC v6 18/20] virtio: support revision-specific features Date: Mon, 2 Feb 2015 15:10:34 +0100 Message-ID: <20150202151034.17281cf4.cornelia.huck@de.ibm.com> References: <1418304322-7546-1-git-send-email-cornelia.huck@de.ibm.com> <1418304322-7546-19-git-send-email-cornelia.huck@de.ibm.com> <20141228083206.GA6802@redhat.com> <20150107172232.57cbeb31.cornelia.huck@de.ibm.com> <20150107191006.GB8734@redhat.com> <20150130150808.007c6572.cornelia.huck@de.ibm.com> <20150201212919.GB9804@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150201212919.GB9804@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: "Michael S. Tsirkin" Cc: thuth@linux.vnet.ibm.com, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org List-Id: virtualization@lists.linuxfoundation.org On Sun, 1 Feb 2015 23:29:20 +0200 "Michael S. Tsirkin" wrote: > On Fri, Jan 30, 2015 at 03:08:08PM +0100, Cornelia Huck wrote: > > On Wed, 7 Jan 2015 21:10:07 +0200 > > "Michael S. Tsirkin" wrote: > > > > > On Wed, Jan 07, 2015 at 05:22:32PM +0100, Cornelia Huck wrote: > > > > On Sun, 28 Dec 2014 10:32:06 +0200 > > > > "Michael S. Tsirkin" wrote: > > > > > > > > > On Thu, Dec 11, 2014 at 02:25:20PM +0100, Cornelia Huck wrote: > > > > > > Devices may support different sets of feature bits depending on which > > > > > > revision they're operating at. Let's give the transport a way to > > > > > > re-query the device about its features when the revision has been > > > > > > changed. > > > > > > > > > > > > Signed-off-by: Cornelia Huck > > > > > > > > > > So now we have both get_features and get_features_rev, and > > > > > it's never clear which revision does host_features refer to. > > > > > IMHO that's just too messy. > > > > > Let's add get_legacy_features and host_legacy_features instead? > > > > > > > > I wanted to avoid touching anything that does not support version 1. > > > > And this interface might still work for later revisions, no? > > > > > > We can add _modern_ then, or rename host_features to host_legacy_features > > > everywhere as preparation. > > > > > > > OK, I've ditched the "don't modify old stuff" goal and introduced > > ->get_features_legacy(). For now, devices will add VERSION_1 in their > > ->get_features() callback when they support it. (For many devices, this > > will be the only difference between the two callbacks.) > > > > Two sets of host_features don't make much sense to me. > > It's the most natural implementation given that > some features are only set for legacy and some (will be) only > for modern interfaces. We may be talking about different things: There's the host_features field which is referenced by the different device types, and there are the sets of features for legacy or modern devices. These are currently set dynamically in the ->get_features() callbacks, although we could possibly convert them to pre-set values like in the kernel. Then I agree, two sets would be natural. But I'd rather stick with the current method, if only to avoid churn.