virtio — archive

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

From: Rusty Russell <[email protected]>
To: [email protected]
Date: Tue, 20 May 2014 00:33:00 -0000

OASIS Issues Tracker <[email protected]> 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.