From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGcrl-0008Dd-A2 for qemu-devel@nongnu.org; Thu, 20 Feb 2014 18:17:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGcrd-0001ne-Jn for qemu-devel@nongnu.org; Thu, 20 Feb 2014 18:17:17 -0500 Received: from mailout3.w2.samsung.com ([211.189.100.13]:15523 helo=usmailout3.samsung.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGcrd-0001nC-GY for qemu-devel@nongnu.org; Thu, 20 Feb 2014 18:17:09 -0500 Received: from uscpsbgex3.samsung.com (u124.gpu85.samsung.co.kr [203.254.195.124]) by usmailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N1B00CM4I0IED20@usmailout3.samsung.com> for qemu-devel@nongnu.org; Thu, 20 Feb 2014 18:17:06 -0500 (EST) Message-id: <53068CF1.6000603@samsung.com> Date: Thu, 20 Feb 2014 15:17:05 -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> <53067ADF.7060604@samsung.com> <53068351.8020702@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 02:47 PM, Peter Maydell wrote: > On 20 February 2014 22:36, Mario Smarduch wrote: >> On 02/20/2014 02:10 PM, Peter Maydell wrote: >>> On 20 February 2014 21:59, Mario Smarduch wrote: >>>> 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. >>> >>> Yes, they're supposed to be common across transports, because >>> the backend isn't supposed to care about which transport in >>> particular. If there's a condition where the backend needs to >>> do something which only happens for one transport, maybe we >>> need a new hook. >> >> So something like set_transport_features(...) in VirtiIODeviceClass, >> and call it from the realize hook where you can access >> the virtio-mmio transport class instance. > > Not sure. You should probably also look at whether connecting > a virtio-pci transport to a virtio-net backend gets these feature > bits wrong (that's different from instantiating a single virtio-net-pci > device). I suspect they both get this wrong and this isn't particularly > virtio-mmio specific. > > thanks > -- PMM > It appears separate pci transport/virtio-net backend have the same issue. I'll look at this closer for a more generic solution. Thanks, Mario