From: "Michael S. Tsirkin" <mst@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: "Viresh Kumar" <viresh.kumar@linaro.org>,
virtio-comment@lists.linux.dev,
"Vincent Guittot" <vincent.guittot@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
"Parav Pandit" <parav@nvidia.com>,
"Matias Ezequiel Vara Larsen" <mvaralar@redhat.com>,
"Stefano Garzarella" <sgarzare@redhat.com>
Subject: Re: [PATCH V8] virtio-transport: Add a section to define mandatory transport requirements
Date: Wed, 31 Jul 2024 05:54:53 -0400 [thread overview]
Message-ID: <20240731055129-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <87a5hx99se.fsf@redhat.com>
On Wed, Jul 31, 2024 at 11:43:13AM +0200, Cornelia Huck wrote:
> On Wed, Jul 31 2024, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> > On 30-07-24, 09:14, Michael S. Tsirkin wrote:
> >> Let's order it sensibly though, in the order in which stuff is used
> >
> > Right.
> >
> > diff --git a/newtransport.tex b/newtransport.tex
> > new file mode 100644
> > index 000000000000..3b760250a4c0
> > --- /dev/null
> > +++ b/newtransport.tex
> > @@ -0,0 +1,44 @@
> > +\chapter{Creating New Transports}\label{sec:Creating New Transports}
> > +
> > +Devices and drivers utilize various transport methods to facilitate
> > +communication, such as PCI, MMIO, or Channel I/O. These transport
> > +methods determine multiple aspects of the interaction between the device
> > +and the driver, including device discovery, capability exchange,
> > +interrupt handling, and data transfer. For instance, in a host/guest
> > +architecture, the host might expose a device to the guest via a virtual
> > +PCI bus, and the guest would employ a PCI device driver to interface
> > +with the device.
> > +
> > +This section outlines the mandatory requirements that a transport method
> > +implements.
> > +
> > +A transport provides a mechanism to implement configuration space for
> > +the device.
> > +
> > +A transport provides a mechanism for the driver to identify the device
> > +type.
> > +
> > +A transport provides a mechanism for the driver to read the device's
> > +status bit.
>
> Either "status bits", or "status" (as below.)
It is actually "FEATURES_OK status bit" I think.
> > +
> > +A transport provides a mechanism for the driver to modify the device's
> > +status.
> > +
> > +A transport provides a mechanism for the driver to read and modify the
> > +device's feature bits.
> > +
> > +A transport allows one or more virtqueues to be implemented by the
> > +device. The number of virtqueues is device specific and not specified by
> > +the transport.
>
> Do we also need to say that the transport provides a mechanism for the
> driver to discover the number of virtqueues?
Some do, but it does not have to. Legacy pci did not do it,
modern does but it is mostly used for sanity checking.
> > +
> > +A transport provides a mechanism for the driver to communicate virtqueue
> > +configuration and memory location to the device.
> > +
> > +A transport provides a mechanism for the device to send device
> > +notifications to the driver, such as used buffer notifications.
> > +
> > +A transport provides a mechanism for the driver to send driver
> > +notifications to the device, such as available buffer notifications.
> > +
> > +A transport provides a mechanism for the driver to initiate a device
> > +reset.
next prev parent reply other threads:[~2024-07-31 9:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-30 7:29 [PATCH V8] virtio-transport: Add a section to define mandatory transport requirements Viresh Kumar
2024-07-30 13:14 ` Michael S. Tsirkin
2024-07-31 9:04 ` Viresh Kumar
2024-07-31 9:43 ` Cornelia Huck
2024-07-31 9:54 ` Michael S. Tsirkin [this message]
2024-07-31 10:15 ` Cornelia Huck
2024-07-31 12:16 ` Michael S. Tsirkin
2024-08-06 10:50 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240731055129-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=cohuck@redhat.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=mvaralar@redhat.com \
--cc=parav@nvidia.com \
--cc=sgarzare@redhat.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=virtio-comment@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.