qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
Date: Mon, 22 Mar 2010 10:03:29 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 03/22/2010 09:50 AM, Michael S. Tsirkin wrote:
On Mon, Mar 22, 2010 at 09:49:03AM -0500, Anthony Liguori wrote:
On 03/22/2010 08:30 AM, Paul Brook wrote:
A VirtIOBlock device cannot be a VirtIODevice while being a
VirtIOPCIProxy (proxy is a poor name, btw).

It really ought to be:

DeviceState ->   VirtIODevice ->   VirtIOBlock

and:

PCIDevice ->   VirtIOPCI : implements VirtIOBus

The interface between the VirtIODevice and VirtIOBus is the virtio
transport.

The main reason a separate bus is needed is the same reason it's needed
in Linux.  VirtIOBlock has to be tied to some bus.  It cannot be tied to
the PCI bus without having it be part of the implementation detail.
Introducing another bus type fixes this (and it's what we do in the
   kernel).

Why does virtio need a device state and bus at all?

Because you need VirtIOBlock to have qdev properties that can be set.

You also need VirtIOPCI to have separate qdev properties that can be set.

Can't it just be an internal implementation interface, which happens to be
used by all devices that happen to exposed a block device over a virtio
transport?

Theoretically, yes, but given the rest of the infrastructure's
interaction with qdev, making it a device makes the most sense IMHO.
Does this boil down to qdev wanting to be the 1st field
in the structure, again? We can just lift that limitation.

No, I don't think it's relevant at all.

It's a classic OOP problem.

VirtIOBlock is-a VirtIODevice, VirtIODevice is-a DeviceState

VirtIOPCI is-a PCIDevice, PCIDevice is-a Device State.

But VirtIODevice is-a VirtIOPCI device isn't always true so it can't be an is-a relationship. Initially, this was true and that's why the code was structured that way. Now that we have two type so of virtio transports, we need to change the modelling. It needs to get inverted into a has-a relationship. IOW, VirtIOPCI has-a VirtIODevice.

When one device has-a one or more other devices, we model that as a Bus.

It's just like SCSI.  SCSIDisk is-a SCSIDevice, SCSIDevice is-a DeviceState.

LSIState is-a PCIDevice, PCIDevice is-a DeviceState.

LSIState has-a SCSIDevice because LSIState implements the SCSIBus interface.

I can't envision any reason why we would ever want to have two MSI
vectors for a given queue.
No. OTOH whether we want a shared vector or a per-vq vector
might depend on the device being used.

Yup. From a users perspective, we don't want them to create two separate devices and manipulate parameters. We definitely want one interface where we can manipulate both VirtIODevice and VirtIOPCI parameters.

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]