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
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
