From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGbfF-00025M-Js for qemu-devel@nongnu.org; Thu, 20 Feb 2014 17:00:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGbf7-0002sD-T1 for qemu-devel@nongnu.org; Thu, 20 Feb 2014 17:00:17 -0500 Received: from mailout2.w2.samsung.com ([211.189.100.12]:19798 helo=usmailout2.samsung.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGbf7-0002rZ-PP for qemu-devel@nongnu.org; Thu, 20 Feb 2014 17:00:09 -0500 Received: from uscpsbgex3.samsung.com (u124.gpu85.samsung.co.kr [203.254.195.124]) by mailout2.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N1B00LSTEG7WP50@mailout2.w2.samsung.com> for qemu-devel@nongnu.org; Thu, 20 Feb 2014 17:00:07 -0500 (EST) Message-id: <53067ADF.7060604@samsung.com> Date: Thu, 20 Feb 2014 13:59:59 -0800 From: Mario Smarduch MIME-version: 1.0 References: <52FD328A.40605@samsung.com> <52FD3593.3040109@samsung.com> <5306458C.3090808@samsung.com> <530652EC.5030004@samsung.com> In-reply-to: Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= , "Michael S. Tsirkin" , QEMU Developers , Anthony Liguori , Patch Tracking On 02/20/2014 11:35 AM, Peter Maydell wrote: > On 20 February 2014 19:09, Mario Smarduch wrote: >> host features since you don't know what virtio device will be plugged >> in later. > > I think this function is the right place to set these properties, > yes. What I'm saying is that I don't see why you're doing it > this way rather than using the existing per-backend hook. > Maybe there's a reason not to use that hook, but you don't say. > Appears virtio-net beckend hooks are common to several transports, and would require virtio-mmio exception to set the host_features. If I'm missing something please recommend. >> It's virtio_net_properties[] can only set virtio-net >> properites when it's instantiated. I think the proper way would >> be to refactor virtio-mmio to similar structure PCI version uses then >> one virtio_net_properties[] can be used selecting PCI or virtio-mmio at >> compile time. But right now it's unclear to me how pci and virtio-mmio >> versions intend to co-exist. > > This is the result of a refactoring last year to allow virtio-mmio. > Basically the underlying structure now is: > > [some virtio transport device] <- virtio bus -> [virtio backend] > > where the transport could be mmio, PCI, CCW, etc, and the > backend is net, blk, balloon, etc. We also provide devices > which are "virtio PCI transport plus a specific backend" > for (a) user convenience and (b) backwards compatibility, since > the pre-refactoring structure put the transport and backend > all in one lump. The all-in-one-lump arrangement is legacy: > we shouldn't break it, but it's not the model for virtio-mmio > to follow either. > > The transport shouldn't know anything specific about the > backend it's plugged into (or vice-versa), but it's fine > for there to be hook functions so the transport and backend > can call each other at the appropriate times. > > thanks > -- PMM >