Andrew Thornton
2014-04-29 01:37:16 UTC
Hi All,
Included below is the Google feedback on âVirtual I/O Device (VIRTIO)
Version 1.0 Committee Speciï¬cation Draft 01 03 December 2013â. This is
feedback collected
â â
âfrom
â â
a number of people
â â
but communications will be channeled through me.
The feedback is ordered by spec section numbers:
*General Virtio*
*3.1 Driver Initialization*
A descâription of
â â
the shutdown process is missing. Specifically the driver *must *reset the
device or disarm the virtio queues or bus mastering before allowing the
memory backing the virtio queues to be reused. It would probably be good
to specify a preferred mechanism.
*4.1.1 PCI Device Discovery*
This use of PCI device IDâs is an unusual way to handle PCI identification
and plays badly with Windows. Could we instead require the device ID be
0x10xx where xx is the already defined sub-vendor code. This reflects the
current reality of implementation requirements.
*4.1.2.1 Common Configuration structure layout*
*device_status*
âThe spec states "â
Writing 0 resets the device
â". H
ow does the driver know when its complete. Proposal
â:â
the resetting driver will poll this register for a non-zero value until the
reset is complete after which DMA and interrupts will not occur.
*queue_size*
Is there a way to find the maximum queue size without resetting the whole
device?
*queue_enable*
What happens to the state of the queue when queue_enable transitions from
non-zero to zero?
*queue_desc/queue_avail/queue_usedâ*
Does a zero address indicate a disabled queue? This is how current devices
work but spec clarification would be useful.
*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?
*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.
*4.1.3.1.3 Virtio Configuration*
What happens when an invalid size is written to the queue_size register?
*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.
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?
*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). How does the driver
recover the device? Is a virtio reset sufficient? What about inflight
DMAs?
*Virtio Net*
*5.1.6.4 Control Virtqueue*
Could the virtio_net_ctrl
â â
âstructure âbe split into an request and response structure
â â
withâ command specific data present in both giving a space for the device
to respond with data instead of just a boolean ack. Could a vendor
specific command be added to allow for extensions?
*Virtio SCSI*
*max_channel, max_target, max_lun*
Are comparisons here less-than or less-than-or-equal? Both interpretations
are in the fields.
Could we standardize on returning the VIRTIO_SCSI_S_TRANSPORT_FAILURE code
for in flight commands when the device is unplugged.
The spec states âall task attributes may be mapped to SIMPLE by the
deviceâ - this makes S_ORDERED, S_HEAD_OF_QUEUE or S_ACA commands
impossible to issue - plus some commands have implicit head of queue
attribute conflicting with this statement.
VIRTIO_SCSI_S_OVERRUN - could the length referred to be clarified - the
virtio buffers or the allocation_length in the CBD?
VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET - what is the expected behavior when
commands are in flight? What about an incomplete TMF_ABORT?
That's all folks - t
hanks in advance for your consideration,
Andyâ
â
â Thorntonâ
Included below is the Google feedback on âVirtual I/O Device (VIRTIO)
Version 1.0 Committee Speciï¬cation Draft 01 03 December 2013â. This is
feedback collected
â â
âfrom
â â
a number of people
â â
but communications will be channeled through me.
The feedback is ordered by spec section numbers:
*General Virtio*
*3.1 Driver Initialization*
A descâription of
â â
the shutdown process is missing. Specifically the driver *must *reset the
device or disarm the virtio queues or bus mastering before allowing the
memory backing the virtio queues to be reused. It would probably be good
to specify a preferred mechanism.
*4.1.1 PCI Device Discovery*
This use of PCI device IDâs is an unusual way to handle PCI identification
and plays badly with Windows. Could we instead require the device ID be
0x10xx where xx is the already defined sub-vendor code. This reflects the
current reality of implementation requirements.
*4.1.2.1 Common Configuration structure layout*
*device_status*
âThe spec states "â
Writing 0 resets the device
â". H
ow does the driver know when its complete. Proposal
â:â
the resetting driver will poll this register for a non-zero value until the
reset is complete after which DMA and interrupts will not occur.
*queue_size*
Is there a way to find the maximum queue size without resetting the whole
device?
*queue_enable*
What happens to the state of the queue when queue_enable transitions from
non-zero to zero?
*queue_desc/queue_avail/queue_usedâ*
Does a zero address indicate a disabled queue? This is how current devices
work but spec clarification would be useful.
*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?
*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.
*4.1.3.1.3 Virtio Configuration*
What happens when an invalid size is written to the queue_size register?
*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.
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?
*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). How does the driver
recover the device? Is a virtio reset sufficient? What about inflight
DMAs?
*Virtio Net*
*5.1.6.4 Control Virtqueue*
Could the virtio_net_ctrl
â â
âstructure âbe split into an request and response structure
â â
withâ command specific data present in both giving a space for the device
to respond with data instead of just a boolean ack. Could a vendor
specific command be added to allow for extensions?
*Virtio SCSI*
*max_channel, max_target, max_lun*
Are comparisons here less-than or less-than-or-equal? Both interpretations
are in the fields.
Could we standardize on returning the VIRTIO_SCSI_S_TRANSPORT_FAILURE code
for in flight commands when the device is unplugged.
The spec states âall task attributes may be mapped to SIMPLE by the
deviceâ - this makes S_ORDERED, S_HEAD_OF_QUEUE or S_ACA commands
impossible to issue - plus some commands have implicit head of queue
attribute conflicting with this statement.
VIRTIO_SCSI_S_OVERRUN - could the length referred to be clarified - the
virtio buffers or the allocation_length in the CBD?
VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET - what is the expected behavior when
commands are in flight? What about an incomplete TMF_ABORT?
That's all folks - t
hanks in advance for your consideration,
Andyâ
â
â Thorntonâ
--
*"Debugging is twice as hard as writing the code in the first place.*
*Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."*
(Brian W. Kernighan)
*"Debugging is twice as hard as writing the code in the first place.*
*Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."*
(Brian W. Kernighan)