On 11-06-24, 07:41, Parav Pandit wrote:

Got it. I agree to Michael's suggestion "I feel a non-normative section is enough for this." So following his guidance, we should remove it from the requirements and have this as,

"implementation guide" or appendix section and it also looks good without the key wards too.

Otherwise, this requirement section becomes the example of how not to write normative in a normative section. (and we want to avoid future such examples).

I am okay with whatever Cornelia and Michael finalize on this.

...

I wonder if it will cause some confusion, i.e. about the state of the virtqueues on device reset. I understand what you are saying, but is it a given that virtqueues will be reset once device is ?

Yes, it is given. See the spec snippet: " A device MUST NOT send notifications or interact with the queues after indicating completion of the reset by reinitializing device status to 0, until the driver re-initializes the device."

I read this a bit differently TBH. It only says that the device shouldn't interact with vqs between reset and reinitialize states. It doesn't really talk about virtqueues getting reset with the device.

...

I looked at: "Basic Facilities of a Virtio Device" -> "Device Reset", and it doesn't talk about vitqueue being reset with the device.

It is covered.

I am okay to remove it, since you are sure about it :)

...

Also there is a separate section about, "Virtqueue Reset" and it talks about the possibility of a virtqueue getting reset alone.

Maybe something like ?

The driver asks the device to reset itself (and its virtqueues) if, for example, the driver times out waiting for a notification from the device for a previously queued request.

A requirement should be, a transport should provide a mechanism to reset an individual virtqueue. (it is not must).

Right, I can add another requirement for separate resetting of virtqueues.