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

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, May 19, 2014 at 10:22:27PM +0930, Rusty Russell wrote:
> 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?

Device could set NEEDS_RESET, though it won't be able
to send interrupts.

> > 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.

But we could set an ISR bit for the config interrupt, if people
want to share these vectors between devices.
I'll post a spec patch shortly.

> > 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.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php