[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (VIRTIO-100) Google feedback on draft 1
Rusty Russell created VIRTIO-100: ------------------------------------ Summary: Google feedback on draft 1 Key: VIRTIO-100 URL: https://tools.oasis-open.org/issues/browse/VIRTIO-100 Project: OASIS Virtual I/O Device (VIRTIO) TC Issue Type: Bug Affects Versions: virtio 1.0 csprd01 Environment: Reported-by: Andrew Thornton <andrewth@google.com> Reporter: Rusty Russell From: https://lists.oasis-open.org/archives/virtio-comment/201404/msg00003.html General Virtio 3.1 Driver Initialization A description 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? -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]