From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu22w-0007Mw-RS for qemu-devel@nongnu.org; Thu, 27 Nov 2014 11:36:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xu22q-0001Jk-Jo for qemu-devel@nongnu.org; Thu, 27 Nov 2014 11:35:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu22q-0001Jg-Bq for qemu-devel@nongnu.org; Thu, 27 Nov 2014 11:35:52 -0500 Date: Thu, 27 Nov 2014 18:35:40 +0200 From: "Michael S. Tsirkin" Message-ID: <20141127163540.GC27124@redhat.com> References: <1417101409-29482-1-git-send-email-cornelia.huck@de.ibm.com> <20141127152422.GA26747@redhat.com> <20141127163139.7db48144.cornelia.huck@de.ibm.com> <20141127154211.GC26747@redhat.com> <20141127170651.67f918e2.cornelia.huck@de.ibm.com> <20141127161825.GA27124@redhat.com> <20141127172842.42782626.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141127172842.42782626.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [PATCH RFC v4 00/16] qemu: towards virtio-1 host support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: thuth@linux.vnet.ibm.com, rusty@rustcorp.com.au, qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org On Thu, Nov 27, 2014 at 05:28:42PM +0100, Cornelia Huck wrote: > On Thu, 27 Nov 2014 18:18:25 +0200 > "Michael S. Tsirkin" wrote: > > > On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote: > > > > So we should have a per-device callback into the transport layer, say > > > check_legacy()? > > > > I would just have 2 masks: legacy_features and features. > > But these belong to the device type and the transport just needs to > trigger usage of the right one, right? Yes. > > > > > For ccw, this would check for the negotiated revision; for mmio, it > > > could check a device property configured with the device; and for pci, > > > whatever the mechanism is there :) > > > > > > A transport not implementing this callback is simply considered > > > legacy-only. > > > > I dislike callbacks. Let's just give all info to core, > > and have it DTRT. > > > Have a is_legacy flag in the vdev that is initialized to 1, and > transports can unset it when the revision is negotiated or during init? I would say have modern_features, legacy_features, and set host_features correctly. -- MST