Review v1/v0

[bertrand-marquis]

Hi Everyone,

This pull request include a number of fixes or changes to handle the review comment we got on virtio mailing list.

Some points are not handled because they need a decision between us first (following summary was generated by chatgpt):

Ordering / Out‑of‑Order Feature Discussion

• Parav Pandit proposes relaxing the strict request/response ordering because it is too constraining for high‑performance data paths. He suggests that the bus may need to deliver responses out of
  order, and the spec should support that for performance.
• Demi Marie Obenour raises reset and out‑of‑order race risks if ordering is relaxed. She suggests a generation/stream number or bus‑level reset semantics to avoid stale or mis‑matched responses.
• Michael S. Tsirkin recommends keeping v1 simple and introducing performance features via optional feature bits. This aligns with making relaxed ordering a negotiated capability rather than a
  baseline requirement.

Configuration Generation Optional Feature Discussion

• Peter Hilber suggests making the SET_CONFIG generation count optional or dropping it, because Linux drivers assume config writes are not rejected and do not retry. His rationale is avoiding
  incompatibility with existing driver behavior.

VQ Enabled Flag Discussion

• Peter Hilber suggests adding an explicit “queue enabled” indication in SET_VQUEUE (and also reporting it in GET_VQUEUE) so drivers can avoid an extra GET_VQUEUE round‑trip just to confirm
  enablement. This is aimed at reducing overhead in the initialization flow.

Device Number Size Discussion

• Parav Pandit argues the 16‑bit device number is too small; he suggests 32‑bit to cover >64k devices and PCI BDF domain usage.
• Demi Marie Obenour argues device identifiers should be 64‑bit or even 128‑bit to ensure long‑term uniqueness.
• Peter Hilber highlights that reuse of device numbers after removal can cause races, and suggests adding a reuse‑limiting policy. He ties this to the broader question of expanding the device number
  space.

EVENT_CONFIG Data Mandatory Discussion

• Demi Marie Obenour proposes making EVENT_CONFIG always include configuration data (MUST), to avoid a round trip. If data is mandatory, she notes that offset/length‑only signaling becomes
  unnecessary.
• There is a noted contradiction with earlier guidance (Peter Hilber) and the current spec change ( I already updated the spec to require offset/length even when data is omitted, keeping data optional as I think this makes sense and i am not quite sure we can mandate the data without breaking compatibility with other transports or existing devices). This needs a clear decision.