OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[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:
------------------------------

    Proposal: 
Proposed changes:
1. https://www.oasis-open.org/apps/org/workgroup/virtio/email/archives/201408/msg00013.html
2. https://www.oasis-open.org/apps/org/workgroup/virtio/email/archives/201408/msg00014.html
3. https://www.oasis-open.org/apps/org/workgroup/virtio/email/archives/201408/msg00025.html

  was:Proposed changes: https://www.oasis-open.org/apps/org/workgroup/virtio/email/archives/201407/msg00025.html


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