Re: [virtio] [OASIS Issue Tracker] (VIRTIO-104) PCI Operatoin

[Rusty Russell <rusty@au1.ibm.com>]

OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org> writes:

> Rusty Russell created VIRTIO-104:
> ------------------------------------
>
>              Summary: PCI Operatoin
>                  Key: VIRTIO-104
>                  URL: https://tools.oasis-open.org/issues/browse/VIRTIO-104
>              Project: OASIS Virtual I/O Device (VIRTIO) TC
>           Issue Type: Sub-task
>     Affects Versions: virtio 1.0 csprd01
>             Reporter: Rusty Russell
>             Assignee: Michael Tsirkin

Since Michael hasn't replied to this, I'll tackle it.

> 4.1.3.1 Device Initialization
>
> The driver must enable PCI bus mastering before programming any virtio
> queues.  (Otherwise the device shouldn’t be accessing memory but this
> has been historically ignored).  What happens when the bus master
> enable bit is cleared when virtio is running?

Undefined, but I think that's OK: don't do this?

> 4.1.3.1.1 Virtio Device Configuration Layout Detection
>
> Instead of using PCI_CAP_ID_VNDR could a unique capability be
> allocated from the PCI SIG?  It would be useful to be able to identify
> the VIRTIO capability without special driver knowledge.

It would be possible, but I can't see a reason we'd want to attach
virtio capabilities to random devices.  But perhaps I just lack
imagination - and willingness to deal with not one but two standards
bodies.  I look forward to someone carrying that flag for virtio 2.0 :)

> 4.1.3.1.3 Virtio Configuration
>
> What happens when an invalid size is written to the queue_size register?

Undefined.  Though it might be OK if it is corrected before the queue is
enabled.  At which point in the latest draft there is a
DEVICE_NEEDS_RESET status bit which *could* be set by the device.

> 4.1.3.4 Notification of Device Configuration Changes
>
> What portion of configuration space should be re-examined?  We assume just the device specific fields and not BARs or other generic configuration.  The spec should clarify this.

The draft 02 has the following (clearer) language:

Some virtio PCI devices can change the device configuration state, as
reflected in the device-specific configuration region of the device. In
this case:

> In the MSI-X enablement case no mention of setting an interrupt status
> bit.  In the case where a unique MSI isn’t allocated to this table
> entry how does the driver detect this?  

Yes, if you share MSI-X vectors you'll need to poll the virtqueues to
see which one needs servicing.  Having an interrupt status bit would
cause an exit.

> Clarification of runtime device error handling
>
> When an error occurs such as invalid descriptor or a DMA to an invalid
> address what does the device do?  i.e. does it continue processing the
> current descriptor or does it halt (our preference).

It is currently undefined.

> How does the driver recover the device?  Is a virtio reset sufficient?
> What about inflight DMAs?

Yes, a virtio reset is our big hammer.  It must be sufficient to stop
in-flight DMAs and reset the device.

Cheers,
Rusty.