[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (VIRTIO-110) MMIO: Feedback from ARM's Brian
[ https://issues.oasis-open.org/browse/VIRTIO-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pawel Moll updated VIRTIO-110: ------------------------------ Affects Version/s: virtio 1.0 csprd03 > 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 > Affects Versions: virtio 1.0 csprd03 > Environment: Brian Foley <brian.foley@arm.com> > Reporter: Pawel Moll > Assignee: Pawel Moll > Fix For: virtio 1.0 csprd04 > > > * 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]