OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] [PATCH 15/18] CCW: Separate normative and descriptive sections.


On Wed, 19 Feb 2014 17:09:52 +1030
Rusty Russell <rusty@au1.ibm.com> wrote:

> Signed-off-by: Rusty Russell <rusty@au1.ibm.com>
> ---
>  content.tex | 54 +++++++++++++++++++++++++++++++++++++++---------------
>  1 file changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/content.tex b/content.tex
> index b3dfccf..e2cf1b7 100644
> --- a/content.tex
> +++ b/content.tex

> @@ -2225,10 +2224,16 @@ in \hyperref[intro:S390 PoP]{[S390 PoP]} and \hyperref[intro:S390 Common I/O]{[S
>    device MUST present a check condition if the transmitted data does
>    not contain enough data to process the command. If the driver submitted
>    a buffer that was too long, the device SHOULD accept the command.
> -  The driver SHOULD attempt to provide the correct length even if it
> -  suppresses length checks.
>  \end{itemize}
> 
> +\drivernormative{Virtio Transport Options / Virtio over channel I/O / Basic Concepts}
> +
> +A driver for virtio-ccw devices MUST check for a control unit
> +type of 0x3832 and MUST ignore the device type and model.
> +
> +A driver SHOULD attempt to provide the correct length even if it
> +suppresses length checks.

This sentence needs to be expanded, or it is hard to understand due to
missing context after the move:

"A driver SHOULD attempt to provide the correct length in a channel
command even if it suppresses length checks for that command."

> +
>  \subsection{Device Initialization}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization}
> 
>  virtio-ccw uses several channel commands to set up a device.

> @@ -2553,8 +2568,14 @@ For notifying the driver of virtqueue buffers, the device sets the
>  bit in the guest-provided indicator area at the corresponding offset.
>  The guest-provided summary indicator is set to 0x01. An adapter I/O
>  interrupt for the corresponding interruption subclass is generated.
> +
> +\devicenormative{Virtio Transport Options / Virtio over channel I/O / Device Operation / Host->Guest Notification / Notification via Adapter I/O Interrupts}
> +
>  The device SHOULD only generate an adapter I/O interrupt if the
> -summary indicator had not been set prior to notification. The driver
> +summary indicator had not been set prior to notification.
> +
> +\drivernormative{Virtio Transport Options / Virtio over channel I/O / Device Operation / Host->Guest Notification / Notification via Adapter I/O Interrupts}
> +The driver
>  MUST clear the summary indicator after receiving an adapter I/O
>  interrupt before it processes the queue indicators.

And I just noticed that there's a slight technical problem with that
statement. I'll fix that separately.

> 
> @@ -2585,12 +2606,15 @@ GPR  &   Input Value     & Output Value \\
>  \hline
>  \end{tabular}
> 
> +\devicenormative{Virtio Transport Options / Virtio over channel I/O / Device Operation / Guest->Host Notification}
>  The device MUST ignore bits 0-31 (counting from the left) of GPR2.
>  This aligns passing the subchannel ID with the way it is passed
>  for the existing I/O instructions.
> 
>  Host cookie is an optional per-virtqueue 64 bit value that MAY be
>  used by the hypervisor to speed up the notification execution.
> +
> +\drivernormative{Virtio Transport Options / Virtio over channel I/O / Device Operation / Guest->Host Notification}
>  For each notification, the output value is returned in GPR2 and

Hm, don't we need to split that? It is the device that returns the
value in gpr2 and the driver that should put it into gpr4 for the next
notification.

>  SHOULD be passed in GPR4 for the next notification:
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]