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


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

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

Subject: Re: [virtio] Re: [virtio-dev] Re: [RFC PATCH 3/3] ccw: map common notifications terminology to ccw

On 04/11/2018 06:00 PM, Cornelia Huck wrote:
> On Wed, 11 Apr 2018 15:42:34 +0200
> Halil Pasic <pasic@linux.vnet.ibm.com> wrote:
>> On 04/11/2018 09:50 AM, Cornelia Huck wrote:
>>> On Wed, 11 Apr 2018 00:11:27 +0200
>>> Halil Pasic <pasic@linux.vnet.ibm.com> wrote:
>>>> +\item Notifications (via hypercall and virtual interrupts).  
>>> Why 'virtual' interrupts? Better call this 'I/O interrupts' (includes
>>> both classic and adapter interrupts)?
>> The idea was 'hypercall' and 'virtual' should harmonize well. These
>> I/O interrupts are kind of 'real' from the perspective of the virtual
>> machine, but are 'virtual' from the perspective of HW and AR perspective. 
> Yes, but that's an implementation detail. I/O interrupts follow the
> same architecture in any case, there's nothing special about I/O
> interrupts for virtio.

I'm not sure about that. For instance, there is this check your
notifiers unsolicited subchannel associated I/O interruption. I don't
think this is just plain old channel I/O interrupt handling.

>> What I mean, there is AFAIU no way to implement a control unit
>> and device combo in HW attach it to a z box and do virtio over CIO
>> naively.
> It does not seem completely impossible (I/O interrupts are abstractions
> already). The diagnose notification might be a problem, though :)

I don't understand. How would the control unit/device (let's say CU
connected to an FCP feature) sent 'classic' indicators?

>> Even with classic I/O interrupts we have to do set indicator + inject
>> subchannel interrupt to realize a notification. This is however
>> form core perspective one notification/even/interrupt.
> But the I/O interrupt + indicators combination already exits (cf.
> QDIO). I don't think we should single out virtio.

Consider the reader of this spec. QDIO is not PoP material. I don't
think the virtio-ccw (as specified here) can be implemented over it either.
My understanding of QDIO is very limited. With that limited understanding
I would say that there are some similarities, but that is it.

Bottom line is the following. The statement 'A driver receiving a virtio
configuration change notifications corresponds to a (classic) I/O 
interruption for the subchannel corresponding to the  virtio-ccw proxy 
device.' is at best an oversimplification for me. (In fact making a I/O
interrupt pending can be optimized away under certain circumstances.)

That is why I used 'Notifications (via hypercall and virtual interrupts).'
instead of 'Notifications (via hypercall and I/O interrupts)'. IMHO the first
one points the people into the right direction, while remaining blurry
enough, and hinting think virtual (that is not strictly architecture).

AFAIU other transports don't have this 'can not be implemented
natively staying within the present architectural boundaries'.

But you seem bothered by this 'virtual' and I respect that. So how about
'Notifications (via hypercall and a combination of I/O interrupts and
indicator bits).'?

>> So this is why I added this 'virtual' (to hint it may not fit anything
>> one can find in the PoP perfectly).
> I certainly would welcome addition of the adapter interrupt
> architecture to the PoP :)

I've adopted a policy of acting on the assumption that the
company has good reasons for publishing what is published
and keeping unpublished what is not. It would be certainly
easier for me to do my work, if all architecture were public.

>>>> +\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"?  
>> Valid. These are indeed called 'adapter I/O interrupts' through out
>> this spec. I was i a hurry to write up something demonstrating he idea,
>> so I did not check this. I think these are usually called 'adapter interrupts'
>> (without the I/O in between) elsewhere, but internal integrity is more
>> important.
>> I will take it.
>>> (I'd really like a reference to I/O interrupts here... especially as
>>> the old, never standardized s390 transport used external interrupts.)
>> You mean with the wording you proposed, or something more? If something
>> more could you do a patch on top (later)?
> I think simply adding "I/O" should be enough.



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