From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Zhu Lingshan <lingshan.zhu@intel.com>,
cohuck@redhat.com, sgarzare@redhat.com, stefanha@redhat.com,
nrupal.jani@intel.com, Piotr.Uminski@intel.com,
hang.yuan@intel.com, virtio-comment@lists.oasis-open.org
Subject: Re: [PATCH V4 1/4] Introduce virito transport virtqueue
Date: Thu, 8 Sep 2022 01:38:00 -0400 [thread overview]
Message-ID: <20220908013614-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1b89ee30-463e-23ae-9616-746f48ec6fa4@redhat.com>
On Thu, Sep 08, 2022 at 11:18:10AM +0800, Jason Wang wrote:
>
> 在 2022/8/26 18:00, Zhu Lingshan 写道:
> > This commit introduces transport virtqueue as a new transport
> > layer for virtio devices. And the format of the commands
> > through the transport virtqueue is defined as well.
> >
> > We also give examples for the management devices and the
> > managed devices.
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > Signed-off-by: Zhu Lingshan <lingshan.zhu@intel.com>
> > ---
> > content.tex | 113 +++++++++++++++++++++++++++++++++++++++++++++++
> > introduction.tex | 3 ++
> > 2 files changed, 116 insertions(+)
> >
> > diff --git a/content.tex b/content.tex
> > index e863709..0f2dee4 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -2895,6 +2895,119 @@ \subsubsection{Resetting Devices}\label{sec:Virtio Transport Options / Virtio ov
> > MAY also choose to verify reset completion by reading \field{device status} via
> > CCW_CMD_READ_STATUS and checking whether it is 0 afterwards.
> > +\section{Virtio Over Transport Virtqueue}\label{sec:Virtio Transport Options Virtio Over Transport Virtqueue}
> > +
> > +In some cases, it is challenging to implement a virtio device in a transport specific method.
> > +
> > +One example is that a physical device may try to present multiple virtio (maybe virtual) devices
> > +with limited transport specific resources.
> > +
> > +Another example is to implement transport-independent virtio devices.
> > +In those cases, a transport virtqueue could be used as the transport layer to
> > +implement virtio managed device.
> > +
> > +\subsection{Basic Concepts}\label{sec:Virtio Transport Options / Virtio over Transport Virtqueue / Basic Concepts}
> > +
> > +Feature bit VIRTIO_F_TRANSPT_VQ indicates that a device offers a transport virtqueue.
> > +
> > +\subsubsection{The Management Device}\label{sec:Virtio Transport Options / Virtio over Transport Virtqueue / Basic Concepts / The Management Device}
> > +
> > +A device that offers feature bit VIRTIO_F_TRANSPT_VQ and a transport virtqueue is a management device.
> > +
> > +For example, a PCIe device with a transport virtqueue and offers VIRTIO_F_TRANSPT_VQ is a management device.
> > +
> > +A set of management commands with a format defined in section \ref{sec:Virtio Transport Options / Virtio over Transport Virtqueue / Format of Commands through Transport Virtqueue}
> > +is processed over the transport virtqueue.
> > +
> > +\devicenormative{\subsubsection}{The Management Device}{Virtio Transport Options / Virtio Over Transport Virtqueue / Basic Concepts / The management Device}
> > +
> > +The management device MUST offer feature bit VIRTIO_F_TRANSPT_VQ and a transport virtqueue.
> > +
> > +\subsubsection{The Managed Device}\label{sec:Virtio Transport Options / Virtio over Transport Virtqueue / Basic Concepts / The Managed Device}
> > +
> > +A managed device is a kind of device that is created, destroyed and configured through a transport virtqueue,
> > +it utilizes the transport virtqueue as its transport layer.
> > +
> > +Virtio can use the transport virtqueue to implement managed devices
> > +
> > +An example of managed devices is a Scalable I/O Virtualization \hyperref[intro:SIOV]{[SIOV]} VDEV which is created and managed
> > +through a transport virtqueue of a management device.
> > +
> > +A managed device and its management device work in a sub-device and parent-device topology.
> > +
> > +\devicenormative{\subsubsection}{The Managed Device}{Virtio Transport Options / Virtio Over Transport Virtqueue / Basic Concepts / The Managed Device}
> > +
> > +A managed device should be isolated from other managed devices on DMA and interrupts.
>
>
> I'd suggest to say
>
> "Managed devices are isolated from each other and from the management
> device."
>
> Since DMA and interrupts which is only available on some transport are not a
> must for a virtio device to work.
Guys, have you looked at the RFC I posted at all?
I'm disappointed this is still going in its own direction
ignoring the obvious similarities between the two concepts.
How many versions of managed/management parent/child
etc can we have?
Can the wording I posted be reused? I certainly made the effort.
I imagine that the virtio transport can become just
1- a new group type
2- a feature bit
3- a set of commands for managing scalable IOV enabled with said bit
I can add (1) to my patchset if you like.
Jason I thought you agreed this made sense?
--
MST
next prev parent reply other threads:[~2022-09-08 5:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220826100034.200432-1-lingshan.zhu@intel.com>
2022-08-26 10:00 ` [PATCH V4 1/4] Introduce virito transport virtqueue Zhu Lingshan
2022-09-08 3:18 ` Jason Wang
2022-09-08 5:38 ` Michael S. Tsirkin [this message]
2022-09-08 6:21 ` Jason Wang
2022-09-08 6:49 ` Michael S. Tsirkin
2022-09-08 6:44 ` [virtio-comment] " Zhu, Lingshan
2022-09-08 6:30 ` Zhu, Lingshan
2022-08-26 10:00 ` [PATCH V4 2/4] Introduce the commands set of the transport vq Zhu Lingshan
2022-08-26 10:00 ` [PATCH V4 3/4] Describe the process to present a managed device Zhu Lingshan
2022-08-26 10:00 ` [PATCH V4 4/4] Add transport vq number for virtio blk and net Zhu Lingshan
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=20220908013614-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=Piotr.Uminski@intel.com \
--cc=cohuck@redhat.com \
--cc=hang.yuan@intel.com \
--cc=jasowang@redhat.com \
--cc=lingshan.zhu@intel.com \
--cc=nrupal.jani@intel.com \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox