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

OASIS Issues Tracker <> 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.