On 02/20/2014 02:47 PM, Peter Maydell wrote: > On 20 February 2014 22:36, Mario Smarduch <m.smard...@samsung.com> wrote: >> On 02/20/2014 02:10 PM, Peter Maydell wrote: >>> On 20 February 2014 21:59, Mario Smarduch <m.smard...@samsung.com> wrote: >>>> On 02/20/2014 11:35 AM, Peter Maydell wrote: >>>>> On 20 February 2014 19:09, Mario Smarduch <m.smard...@samsung.com> 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
