[OASIS Issue Tracker] (VIRTIO-110) MMIO: Feedback from ARM's Brian

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Pawel Moll created VIRTIO-110:
---------------------------------

             Summary: MMIO: Feedback from ARM's Brian
                 Key: VIRTIO-110
                 URL: https://issues.oasis-open.org/browse/VIRTIO-110
             Project: OASIS Virtual I/O Device (VIRTIO) TC
          Issue Type: Bug
            Reporter: Pawel Moll
            Assignee: Pawel Moll
             Fix For: virtio 1.0 csprd03


* 4.2 "Therefore most of operations like..."

Should be "Therefore most operations including"


* 4.2.1 "MMIO provides no generic device discovery"

Should be "MMIO provides no generic device discovery mechanism"


* 4.2.2 "MMIO virtio devices provides"

Should be "MMIO virtio devices provide" or "An MMIO virtio device
provides"


* 4.2.2 DeviceFeatures, DriverFeatures: "First bit"

Should probably be "the least signficiant bit".


* 4.2.2 QueueNum "therefore size of the Descriptor Table and both
Available and Used rings"

This is a bit confusing and a bit ambiguous. I think it would be clearer
as "i.e. the size of the descriptor table, the number of entries in the
availabe ring, and the number of entries in the used ring." (otherwise
it's not clear if you mean size(DT) == size(available)+size(used), or 


* 4.2.2 QueueReady: "Ready to be used"

Slightly confusing here: could mean 'CPU has updated the available
ring/DT', when it really means 'the DT/available ring have first been
initialised to sensible values'. Might be better to copy the PCI
description which says 'the device may execute requests from this
virtual queue'.  


* 4.2.2 ConfigGeneration:

I was a bit lost as to what counts as a configuration change. I think
the ref to section 2.3 doesn't help. Sec 4.2.2.1 is a bit better: "The
device MUST change ConfigGeneration if there is any risk of a device
seeing an inconsistent configuration state, but it MAY only change the
value after a configuration read operation.", but I think that the PCI
description (and the note following) is a bit clearer: "The device MUST
present a changed config_generation after the driver has read a
device-specific configuration value which has changed since any part of
the device-specific configuration was last read. (Note, counter can wrap
so do this...)


* 4.2.2 InterruptAck: "Writing to this register notifies the device that
the interrupt has been handled"

Does this mean if InterruptStatus=3 and I write 1, I'm acking the ring
update but not the configuration change? What happens if I try to ack
something that hasn't happened, eg write 3 when InterruptStatus==0?


* 4.2.2 Along with saying the registers are LE, should we say that all
register accesses must be aligned, 32-bit accesses, and anything else is
undefined behaviour? 


* 4.2.2.2 "When QueueReady is not zero, the drive..."

Period missing at end of sentence.




--
This message was sent by Atlassian JIRA
(v6.2.2#6258)