Uploaded image for project: 'OASIS Virtual I/O Device (VIRTIO) TC'
  1. OASIS Virtual I/O Device (VIRTIO) TC
  2. VIRTIO-110

MMIO: Feedback from ARM's Brian

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: virtio 1.0 csprd03
    • Fix Version/s: virtio 1.0 cs01
    • Labels:
      None
    • Environment:

      Brian Foley <brian.foley@arm.com>

      Description

      • 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.

        Attachments

          Activity

            People

            • Assignee:
              hornet Pawel Moll (Inactive)
              Reporter:
              hornet Pawel Moll (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: