Re: [Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline function

[Anthony Liguori <anthony@codemonkey.ws>]

Michael S. Tsirkin wrote:
> On Mon, Aug 10, 2009 at 03:33:59PM -0500, Anthony Liguori wrote:
>   
>> There ought to be a way to layer qdev properties that achieves this goal  
>> so that when you create a virtio-pci-block device, you have the ability  
>> to turn off indirect sg without virtio-block having to know what that is.
>>     
>
> I don't understand, sorry. Why do you insist on involving pci here?
> ring layout has nothing to do with pci, does it?

What I'm saying is that virtio-blk-pci, which is the qdev instantiation 
of virtio-pci + virtio-blk, should be able to have a set of qdev 
properties that is composed of a combination of at least two sets of 
properties: virtio-blk's qdev properties and virtio-pci's qdev properties.

Right now, all of the properties are defined in virtio-pci.c, so you 
could add a property that was DEFINE_PROP_BOOL("indirect-sg", ...), that 
you could then use to selectively enable/disable indirect sg on 
virtio-blk-pci devices without ever having to involve virtio-blk.c.

Ideally, we wouldn't have the properties centralized in virtio-pci.c.  
Rather, it would be nice if virtio-blk.c could have a set of properties 
and virtio-pci.c could just add those properties to it's own set of 
properties.

Today, we don't have a concept of a ring abstraction.  If we did, then 
virtio-ring.c could have it's own set of properties.

N.B. I expect that the in-kernel virtio-net device is going to be 
separate qdev device than virtio-net-pci.  It can have an identical 
guest interface but within qemu, it should be a separate device.  This 
is how we handle the in-kernel PIT and it's how we should handle the 
in-kernel APIC.

Regards,

Anthony Liguori