From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.vnet.ibm.com>
Cc: virtio@lists.oasis-open.org, virtio-dev@lists.oasis-open.org,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: [virtio] Re: [RFC PATCH 3/3] ccw: map common notifications terminology to ccw
Date: Wed, 11 Apr 2018 09:50:18 +0200 [thread overview]
Message-ID: <20180411095018.61b0caed.cohuck@redhat.com> (raw)
In-Reply-To: <1523398287-25480-4-git-send-email-pasic@linux.vnet.ibm.com>
On Wed, 11 Apr 2018 00:11:27 +0200
Halil Pasic <pasic@linux.vnet.ibm.com> wrote:
[Have not yet looked at your other patches, on my list.]
> The various notifications are introduced and specified in the common
> (i.e. transport agnostic) portion of this specification. How
> notifications are realised for a given transport is something each
> transport has to specify.
>
> Let's make the relationship between the virtio-ccw terms and the common
> terms more obvious.
>
> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
> ---
> content.tex | 41 +++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 41 insertions(+), 0 deletions(-)
>
> diff --git a/content.tex b/content.tex
> index 87cc0e2..27aa17b 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -1938,6 +1938,17 @@ Bytes & Description & Contents \\
> \hline
> \end{tabular}
>
> +A virtio-ccw proxy device facilitates:
> +\begin{itemize}
> +\item Discovery and attachment of virtio devices (as described above).
> +\item Initialization of vitqueues and transport specific facilities (using
s/vitqueues/virtqueues/
> + custom channel commands).
s/custom/virtio-specific/ ?
In a sense, all channel commands other than the basic ones are
'custom' :) They are always device or control unit type specific, only
obeying some rules.
> +\item Notifications (via hypercall and virtual interrupts).
Why 'virtual' interrupts? Better call this 'I/O interrupts' (includes
both classic and adapter interrupts)?
> +\end{itemize}
> +
> +\subsubsection{Channel Commands for Virtio}\label{sec:Virtio Transport Options / Virtio
> +over channel I/O / Basic Concepts/ Channel Commands for Virtio}
> +
> In addition to the basic channel commands, virtio-ccw defines a
> set of channel commands related to configuration and operation of
> virtio:
> @@ -1958,6 +1969,36 @@ virtio:
> #define CCW_CMD_READ_STATUS 0x72
> \end{lstlisting}
>
> +\subsubsection{Notifications}\label{sec:Virtio Transport Options / Virtio
> +over channel I/O / Basic Concepts/ Notifications}
> +
> +Available buffer notifications are realized as a hypercall. No additional
> +setup by the driver is needed. The operation of available buffer
> +notifications is described in section \ref{sec:Virtio Transport Options /
> +Virtio over channel I/O / Device Operation / Guest->Host Notification}.
> +
> +Used buffer notifications are realized either as so called classic or as
> +adapter interrupts depending on a transport level negotiation. The
"as so-called classic or adapter I/O interrupts"?
(I'd really like a reference to I/O interrupts here... especially as
the old, never standardized s390 transport used external interrupts.)
> +initialization is described in sections \ref{sec:Virtio Transport Options
> +/ Virtio over channel I/O / Device Initialization / Setting Up Indicators
> +/ Setting Up Classic Queue Indicators} and \ref{sec:Virtio Transport
> +Options / Virtio over channel I/O / Device Initialization / Setting Up
> +Indicators / Setting Up Two-Stage Queue Indicators} respectively. The
> +operation of each flavor is described in sections \ref{sec:Virtio
> +Transport Options / Virtio over channel I/O / Device Operation /
> +Host->Guest Notification / Notification via Classic I/O Interrupts} and
> +\ref{sec:Virtio Transport Options / Virtio over channel I/O / Device
> +Operation / Host->Guest Notification / Notification via Adapter I/O
> +Interrupts} respectively.
> +
> +Configuration change notifications are done using so called classic
> +interrupts. The initialization is described in section \ref{sec:Virtio
"so-called classic I/O interrupts"
> +Transport Options / Virtio over channel I/O / Device Initialization /
> +Setting Up Indicators / Setting Up Configuration Change Indicators} and
> +the operation in section \ref{sec:Virtio Transport Options / Virtio over
> +channel I/O / Device Operation / Host->Guest Notification / Notification
> +via Classic I/O Interrupts}.
> +
> \devicenormative{\subsubsection}{Basic Concepts}{Virtio Transport Options / Virtio over channel I/O / Basic Concepts}
>
> The virtio-ccw device acts like a normal channel device, as specified
In general, I like this.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
next prev parent reply other threads:[~2018-04-11 7:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 22:11 [virtio] [RFC PATCH 0/3] rework notifications terminology Halil Pasic
2018-04-10 22:11 ` [virtio] [RFC PATCH 1/3] notifications: unify notifications wording in core Halil Pasic
2018-04-11 2:19 ` Stefan Hajnoczi
2018-04-11 10:58 ` Halil Pasic
2018-04-11 11:47 ` Cornelia Huck
2018-04-11 12:35 ` [virtio] Re: [virtio-dev] " Paolo Bonzini
2018-04-11 12:55 ` Cornelia Huck
2018-04-11 13:11 ` Paolo Bonzini
2018-04-10 22:11 ` [virtio] [RFC PATCH 2/3] notifications:notifications as basic virtio facility Halil Pasic
2018-04-11 13:11 ` [virtio] " Cornelia Huck
2018-04-10 22:11 ` [virtio] [RFC PATCH 3/3] ccw: map common notifications terminology to ccw Halil Pasic
2018-04-11 7:50 ` Cornelia Huck [this message]
2018-04-11 13:42 ` [virtio] Re: [virtio-dev] " Halil Pasic
2018-04-11 16:00 ` Cornelia Huck
2018-04-12 11:12 ` Halil Pasic
2018-04-13 9:47 ` Cornelia Huck
2018-04-20 14:53 ` [virtio] Re: [RFC PATCH 0/3] rework notifications terminology Halil Pasic
2018-04-20 15:44 ` Michael S. Tsirkin
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=20180411095018.61b0caed.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.vnet.ibm.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtio@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