Michael S. Tsirkin wrote: > On Mon, Aug 10, 2009 at 05:35:13PM -0500, Anthony Liguori wrote: > >> 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. >> > > Yea. But indirect ring entries is not virtio-pci property. It's a ring feature and the ring implementation is currently in the generic virtio code. Ring features really have no home today so virtio-pci seems logical. > And ev > with virtio-pci properies, such as MSI, specific device should > have control over number of vectors. > Devices, or instantiation of the devices? The later is what I'm suggesting. Let's say we supported virtio-vbus along with virtio-pci. What does virtio_blk_get_features() do to mask out sg_indirect? For all virtio-blk knows, it could be on top of virtio-vbus. > Me as a user? We can't expect the user to tweak such low level stuff for > each device. So devices such as block should have a say in which ring > format options are used, in a way optimal for the specific usage. My > example is that virtio net has merged buffers so indirect ring is > probably just useless. And again, pci seems to have nothing to do with > it, so why drag it in? > If you want to tweak such thing, why not use default property values for virtio-blk-pci's definition in virtio-pci.c? That keeps it out of virtio-blk.c. >> 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. >> > > Ugh. What advantages does this have? It keeps a clean separate of the two devices. It actually ends up making things a lot easier to understand because it's clear what portions of code are not being used for the in-kernel device models. > This would break things like > migrating between userspace and kernel virtio (something that I > support). The PIT uses a common state structure and common code for save/restore. This makes migration compatible. > IMO, this should work like MSI, detect capability and just > have virtio go faster, with a disable flag for troubleshooting purposes. > > Can migration between in-kernel and userspace PIT work? > If yes we would be better off changing that, as well. > Take a look at i8524{,-kvm.c} in qemu-kvm and how it's instantiated in pc.c. It ends up being really straight forward. > Separate devices should be for things that have guest-visible > differences. Don't try to encode random information into the device > name. > In this case, it's two separate implementations of the same device. I think it makes sense for them to be separate devices. Regards, Anthony Liguori _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization