On Tue, Jun 11, 2024 at 05:40:45PM +0000, Parav Pandit wrote:

...

From: Cornelia Huck cohuck@redhat.com Sent: Tuesday, June 11, 2024 8:59 PM

On Tue, Jun 11 2024, Parav Pandit parav@nvidia.com wrote:

...

Hi Viresh,

...

From: Viresh Kumar viresh.kumar@linaro.org Sent: Tuesday, June 11, 2024 11:06 AM

[..]

...

diff --git a/content.tex b/content.tex index 0a62dce5f65f..e2a836327818 100644 --- a/content.tex +++ b/content.tex @@ -631,8 +631,86 @@ \section{Device Cleanup}\label{sec:General Initialization And Device Operation /

\chapter{Virtio Transport Options}\label{sec:Virtio Transport Options}

-Virtio can use various different buses, thus the standard is split -into virtio general and bus-specific sections. +Devices and drivers can use different transport methods to enable +interaction, for example PCI, MMIO, or Channel I/O. The transport +methods define various aspects of the communication between the +device and the driver, like device discovery, exchanging +capabilities, interrupt handling, data transfer, etc. For example, +in a host/guest architecture, the host might expose a device to the +guest on a PCI bus, and the guest will use a PCI-specific driver to interact

with it.

...

...

+The standard contains sections describing the transport-agnostic +parts of virtio, and sections describing how individual transports +implement virtio.

+\section{Virtio Transport Requirements}\label{sec:Virtio Transport +Options / Virtio Transport Requirements}

+There are some mechanisms that any transport is required to +implement, and some requirements that devices and drivers are

required to follow.

...

...

+\subsection{Transport Requirements}\label{sec:Virtio Transport +Options / Virtio Transport Requirements / Transport Requirements}

+A transport provides a mechanism for the driver to discover the device.

I would like to add a normative.

A transport MAY provide a mechanism to create and destroy virtio devices.

(for example PCI transport provides this).

I'm not a fan of that statement: the transport already allows for the driver to discover a device, whether that happens statically or dynamically really is the choice of the transport, and I don't think we should go into that much detail.

Discovery != life cycle management of the device. The whole purpose of this section to clarify the transport requirements scope and guidelines for new transport. And if its incomplete I don't see a point of having this section at all.

I see it as complementing the section about adding new devices. So we give some hints on how to add a new transport, basically a transport developer is documenting his/her journey for others to follow. Yes this does add support overhead, it will get out of sync so we better make this clear straight away. Not enough transports are going to be added to spend too many cycles making this complete, I think.

Anyways, not too critical for me either.

...

[I'll go offline now, so please don't expect further responses from me right now...]