Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
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 


  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