OASIS Virtual I/O Device (VIRTIO) TC

 View Only
Expand all | Collapse all

[PATCH] ccw: clarify device reset

  • 1.  [PATCH] ccw: clarify device reset

    Posted 10-11-2021 11:39
    Unlike other transports, a reset triggered by the driver is actually complete once the command has been completed. Make this behaviour and the requirements more explicit. Signed-off-by: Cornelia Huck <cohuck@redhat.com> --- We have discussed this before while talking about reset behaviour, but I don't remember sending an actual patch. If this looks good, I'll open an issue. --- conformance.tex 2 ++ content.tex 22 +++++++++++++++++++++- 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/conformance.tex b/conformance.tex index c52f1a40be2d..24e862ad217a 100644 --- a/conformance.tex +++ b/conformance.tex @@ -122,6 +122,7 @@ section{Conformance Targets}label{sec:Conformance / Conformance Targets} item
    ef{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Communicating Status Information} item
    ef{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Host->Guest Notification / Notification via Adapter I/O Interrupts} item
    ef{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Guest->Host Notification} +item
    ef{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices} end{itemize} conformance{subsection}{Network Driver Conformance}label{sec:Conformance / Driver Conformance / Network Driver Conformance} @@ -372,6 +373,7 @@ section{Conformance Targets}label{sec:Conformance / Conformance Targets} item
    ef{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting Up Indicators / Setting Up Two-Stage Queue Indicators} item
    ef{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Host->Guest Notification / Notification via Adapter I/O Interrupts} item
    ef{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Guest->Host Notification} +item
    ef{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices} end{itemize} conformance{subsection}{Network Device Conformance}label{sec:Conformance / Device Conformance / Network Device Conformance} diff --git a/content.tex b/content.tex index 5e716721edb3..0410f46f6a78 100644 --- a/content.tex +++ b/content.tex @@ -2775,8 +2775,28 @@ subsubsection{Guest->Host Notification}label{sec:Virtio Transport Options / Vi subsubsection{Resetting Devices}label{sec:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices} In order to reset a device, a driver sends the -CCW_CMD_VDEV_RESET command. +CCW_CMD_VDEV_RESET command. This command does not carry any payload. +The device signals completion of the reset operation by making the subchannel +status pending to indicate successful completion of the channel command. +Notably, the command not only triggers the reset operation, but the reset +operation is already completed when the operation concludes successfully. + +devicenormative{paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices} + +Before making the subchannel status pending to indicate successful completion +of the reset command, the device MUST reinitialize field{device status} to +zero. + +The device MUST NOT send notifications or interact with the queues after +it signaled successful completion of the reset command. + +drivernormative{paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices} + +The driver MAY consider the reset operation to be complete already after +successful completion of the channel command, although it MAY also verify +reset completion by reading field{device status} via CCW_CMD_READ_STATUS +afterwards. chapter{Device Types}label{sec:Device Types} -- 2.31.1


  • 2.  Re: [PATCH] ccw: clarify device reset

    Posted 10-12-2021 02:55
    On Mon, Oct 11, 2021 at 7:38 PM Cornelia Huck <cohuck@redhat.com> wrote:
    >
    > Unlike other transports, a reset triggered by the driver is actually
    > complete once the command has been completed. Make this behaviour
    > and the requirements more explicit.
    >
    > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
    > ---
    >
    > We have discussed this before while talking about reset behaviour,
    > but I don't remember sending an actual patch.
    >
    > If this looks good, I'll open an issue.
    >
    > ---
    > conformance.tex | 2 ++
    > content.tex | 22 +++++++++++++++++++++-
    > 2 files changed, 23 insertions(+), 1 deletion(-)
    >
    > diff --git a/conformance.tex b/conformance.tex
    > index c52f1a40be2d..24e862ad217a 100644
    > --- a/conformance.tex
    > +++ b/conformance.tex
    > @@ -122,6 +122,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
    > \item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Communicating Status Information}
    > \item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Host->Guest Notification / Notification via Adapter I/O Interrupts}
    > \item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Guest->Host Notification}
    > +\item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    > \end{itemize}
    >
    > \conformance{\subsection}{Network Driver Conformance}\label{sec:Conformance / Driver Conformance / Network Driver Conformance}
    > @@ -372,6 +373,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
    > \item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting Up Indicators / Setting Up Two-Stage Queue Indicators}
    > \item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Host->Guest Notification / Notification via Adapter I/O Interrupts}
    > \item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Guest->Host Notification}
    > +\item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    > \end{itemize}
    >
    > \conformance{\subsection}{Network Device Conformance}\label{sec:Conformance / Device Conformance / Network Device Conformance}
    > diff --git a/content.tex b/content.tex
    > index 5e716721edb3..0410f46f6a78 100644
    > --- a/content.tex
    > +++ b/content.tex
    > @@ -2775,8 +2775,28 @@ \subsubsection{Guest->Host Notification}\label{sec:Virtio Transport Options / Vi
    > \subsubsection{Resetting Devices}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    >
    > In order to reset a device, a driver sends the
    > -CCW_CMD_VDEV_RESET command.
    > +CCW_CMD_VDEV_RESET command. This command does not carry any payload.
    >
    > +The device signals completion of the reset operation by making the subchannel
    > +status pending to indicate successful completion of the channel command.

    Not familiar with ccw, but I wonder what's the meaning of "making the
    subchannel status pending"?

    > +Notably, the command not only triggers the reset operation, but the reset
    > +operation is already completed when the operation concludes successfully.
    > +
    > +\devicenormative{\paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    > +
    > +Before making the subchannel status pending to indicate successful completion
    > +of the reset command, the device MUST reinitialize \field{device status} to
    > +zero.

    Is the ordering of reinitialization and interrupt guaranteed by the transport?

    > +
    > +The device MUST NOT send notifications or interact with the queues after
    > +it signaled successful completion of the reset command.
    > +
    > +\drivernormative{\paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    > +
    > +The driver MAY consider the reset operation to be complete already after
    > +successful completion of the channel command, although it MAY also verify
    > +reset completion by reading \field{device status} via CCW_CMD_READ_STATUS
    > +afterwards.

    I wonder if it's better to say

    The driver MUST consider the reset operation to be complete by either ... or ...

    Thanks

    >
    > \chapter{Device Types}\label{sec:Device Types}
    >
    > --
    > 2.31.1
    >




  • 3.  Re: [PATCH] ccw: clarify device reset

    Posted 10-12-2021 11:17
    On Tue, Oct 12 2021, Jason Wang <jasowang@redhat.com> wrote:

    > On Mon, Oct 11, 2021 at 7:38 PM Cornelia Huck <cohuck@redhat.com> wrote:
    >>
    >> Unlike other transports, a reset triggered by the driver is actually
    >> complete once the command has been completed. Make this behaviour
    >> and the requirements more explicit.
    >>
    >> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
    >> ---
    >>
    >> We have discussed this before while talking about reset behaviour,
    >> but I don't remember sending an actual patch.
    >>
    >> If this looks good, I'll open an issue.
    >>
    >> ---
    >> conformance.tex | 2 ++
    >> content.tex | 22 +++++++++++++++++++++-
    >> 2 files changed, 23 insertions(+), 1 deletion(-)
    >>

    >> @@ -2775,8 +2775,28 @@ \subsubsection{Guest->Host Notification}\label{sec:Virtio Transport Options / Vi
    >> \subsubsection{Resetting Devices}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    >>
    >> In order to reset a device, a driver sends the
    >> -CCW_CMD_VDEV_RESET command.
    >> +CCW_CMD_VDEV_RESET command. This command does not carry any payload.
    >>
    >> +The device signals completion of the reset operation by making the subchannel
    >> +status pending to indicate successful completion of the channel command.
    >
    > Not familiar with ccw, but I wonder what's the meaning of "making the
    > subchannel status pending"?

    Hm, I was wondering whether I'm striking the balance between assuming
    the reader knows the details of how channel I/O works and explaining the
    basic flow...

    Slightly simplified, if a device/control unit has finished processing a
    channel program (whether successfully or not), it places some status in
    the control blocks for the subchannel that serves as its communication
    conduit, one of the values being "status pending". The driver may
    collect the subchannel status at any time, but "status pending" in
    particular means that an interrupt becomes pending. A system may run
    with interrupts disabled, while still polling for pending interrupts, so
    I did not want to write that the device generates an interrupt. Not sure
    if this is now too hard to understand for someone not that familiar with
    the matter, though.

    >
    >> +Notably, the command not only triggers the reset operation, but the reset
    >> +operation is already completed when the operation concludes successfully.
    >> +
    >> +\devicenormative{\paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    >> +
    >> +Before making the subchannel status pending to indicate successful completion
    >> +of the reset command, the device MUST reinitialize \field{device status} to
    >> +zero.
    >
    > Is the ordering of reinitialization and interrupt guaranteed by the transport?

    It is definitely how it should be, i.e. the device performing the reset
    and only then making the subchannel status pending. I had thought this
    was self-evident, and QEMU also works like that, but maybe it really
    needed some clarification. (I assume the zCX thingy also does it like
    that, but I cannot check that myself.)

    >
    >> +
    >> +The device MUST NOT send notifications or interact with the queues after
    >> +it signaled successful completion of the reset command.
    >> +
    >> +\drivernormative{\paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    >> +
    >> +The driver MAY consider the reset operation to be complete already after
    >> +successful completion of the channel command, although it MAY also verify
    >> +reset completion by reading \field{device status} via CCW_CMD_READ_STATUS
    >> +afterwards.
    >
    > I wonder if it's better to say
    >
    > The driver MUST consider the reset operation to be complete by either ... or ...

    We currently say that the driver SHOULD consider reset complete when it
    reads back a zero status. For ccw, completion of the command is required
    before the driver can issue another command (such as to check the device
    status). What I wanted to say here is that the driver is already free to
    consider the reset complete if the command was successful, but that it
    can read back the status _after_ the reset command is through to satisfy
    the generic SHOULD statement.




  • 4.  Re: [PATCH] ccw: clarify device reset

    Posted 10-12-2021 11:17
    On Tue, Oct 12 2021, Jason Wang <jasowang@redhat.com> wrote: > On Mon, Oct 11, 2021 at 7:38 PM Cornelia Huck <cohuck@redhat.com> wrote: >> >> Unlike other transports, a reset triggered by the driver is actually >> complete once the command has been completed. Make this behaviour >> and the requirements more explicit. >> >> Signed-off-by: Cornelia Huck <cohuck@redhat.com> >> --- >> >> We have discussed this before while talking about reset behaviour, >> but I don't remember sending an actual patch. >> >> If this looks good, I'll open an issue. >> >> --- >> conformance.tex 2 ++ >> content.tex 22 +++++++++++++++++++++- >> 2 files changed, 23 insertions(+), 1 deletion(-) >> >> @@ -2775,8 +2775,28 @@ subsubsection{Guest->Host Notification}label{sec:Virtio Transport Options / Vi >> subsubsection{Resetting Devices}label{sec:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices} >> >> In order to reset a device, a driver sends the >> -CCW_CMD_VDEV_RESET command. >> +CCW_CMD_VDEV_RESET command. This command does not carry any payload. >> >> +The device signals completion of the reset operation by making the subchannel >> +status pending to indicate successful completion of the channel command. > > Not familiar with ccw, but I wonder what's the meaning of "making the > subchannel status pending"? Hm, I was wondering whether I'm striking the balance between assuming the reader knows the details of how channel I/O works and explaining the basic flow... Slightly simplified, if a device/control unit has finished processing a channel program (whether successfully or not), it places some status in the control blocks for the subchannel that serves as its communication conduit, one of the values being "status pending". The driver may collect the subchannel status at any time, but "status pending" in particular means that an interrupt becomes pending. A system may run with interrupts disabled, while still polling for pending interrupts, so I did not want to write that the device generates an interrupt. Not sure if this is now too hard to understand for someone not that familiar with the matter, though. > >> +Notably, the command not only triggers the reset operation, but the reset >> +operation is already completed when the operation concludes successfully. >> + >> +devicenormative{paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices} >> + >> +Before making the subchannel status pending to indicate successful completion >> +of the reset command, the device MUST reinitialize field{device status} to >> +zero. > > Is the ordering of reinitialization and interrupt guaranteed by the transport? It is definitely how it should be, i.e. the device performing the reset and only then making the subchannel status pending. I had thought this was self-evident, and QEMU also works like that, but maybe it really needed some clarification. (I assume the zCX thingy also does it like that, but I cannot check that myself.) > >> + >> +The device MUST NOT send notifications or interact with the queues after >> +it signaled successful completion of the reset command. >> + >> +drivernormative{paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices} >> + >> +The driver MAY consider the reset operation to be complete already after >> +successful completion of the channel command, although it MAY also verify >> +reset completion by reading field{device status} via CCW_CMD_READ_STATUS >> +afterwards. > > I wonder if it's better to say > > The driver MUST consider the reset operation to be complete by either ... or ... We currently say that the driver SHOULD consider reset complete when it reads back a zero status. For ccw, completion of the command is required before the driver can issue another command (such as to check the device status). What I wanted to say here is that the driver is already free to consider the reset complete if the command was successful, but that it can read back the status _after_ the reset command is through to satisfy the generic SHOULD statement.


  • 5.  Re: [PATCH] ccw: clarify device reset

    Posted 10-13-2021 06:20

    ? 2021/10/12 ??7:16, Cornelia Huck ??:
    > On Tue, Oct 12 2021, Jason Wang <jasowang@redhat.com> wrote:
    >
    >> On Mon, Oct 11, 2021 at 7:38 PM Cornelia Huck <cohuck@redhat.com> wrote:
    >>> Unlike other transports, a reset triggered by the driver is actually
    >>> complete once the command has been completed. Make this behaviour
    >>> and the requirements more explicit.
    >>>
    >>> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
    >>> ---
    >>>
    >>> We have discussed this before while talking about reset behaviour,
    >>> but I don't remember sending an actual patch.
    >>>
    >>> If this looks good, I'll open an issue.
    >>>
    >>> ---
    >>> conformance.tex | 2 ++
    >>> content.tex | 22 +++++++++++++++++++++-
    >>> 2 files changed, 23 insertions(+), 1 deletion(-)
    >>>
    >>> @@ -2775,8 +2775,28 @@ \subsubsection{Guest->Host Notification}\label{sec:Virtio Transport Options / Vi
    >>> \subsubsection{Resetting Devices}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    >>>
    >>> In order to reset a device, a driver sends the
    >>> -CCW_CMD_VDEV_RESET command.
    >>> +CCW_CMD_VDEV_RESET command. This command does not carry any payload.
    >>>
    >>> +The device signals completion of the reset operation by making the subchannel
    >>> +status pending to indicate successful completion of the channel command.
    >> Not familiar with ccw, but I wonder what's the meaning of "making the
    >> subchannel status pending"?
    > Hm, I was wondering whether I'm striking the balance between assuming
    > the reader knows the details of how channel I/O works and explaining the
    > basic flow...
    >
    > Slightly simplified, if a device/control unit has finished processing a
    > channel program (whether successfully or not), it places some status in
    > the control blocks for the subchannel that serves as its communication
    > conduit, one of the values being "status pending". The driver may
    > collect the subchannel status at any time, but "status pending" in
    > particular means that an interrupt becomes pending.


    So it looks something similar to ISR (interrupt status register) in PCI.


    > A system may run
    > with interrupts disabled, while still polling for pending interrupts, so
    > I did not want to write that the device generates an interrupt.


    I see.


    > Not sure
    > if this is now too hard to understand for someone not that familiar with
    > the matter, though.


    It's not.

    Btw I found the link to S390 Common I/O is broken (at least I can't
    access it from China):

    http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar501/CCONTENTS


    >
    >>> +Notably, the command not only triggers the reset operation, but the reset
    >>> +operation is already completed when the operation concludes successfully.
    >>> +
    >>> +\devicenormative{\paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    >>> +
    >>> +Before making the subchannel status pending to indicate successful completion
    >>> +of the reset command, the device MUST reinitialize \field{device status} to
    >>> +zero.
    >> Is the ordering of reinitialization and interrupt guaranteed by the transport?
    > It is definitely how it should be, i.e. the device performing the reset
    > and only then making the subchannel status pending. I had thought this
    > was self-evident, and QEMU also works like that, but maybe it really
    > needed some clarification. (I assume the zCX thingy also does it like
    > that, but I cannot check that myself.)


    Ok.


    >
    >>> +
    >>> +The device MUST NOT send notifications or interact with the queues after
    >>> +it signaled successful completion of the reset command.
    >>> +
    >>> +\drivernormative{\paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
    >>> +
    >>> +The driver MAY consider the reset operation to be complete already after
    >>> +successful completion of the channel command, although it MAY also verify
    >>> +reset completion by reading \field{device status} via CCW_CMD_READ_STATUS
    >>> +afterwards.
    >> I wonder if it's better to say
    >>
    >> The driver MUST consider the reset operation to be complete by either ... or ...
    > We currently say that the driver SHOULD consider reset complete when it
    > reads back a zero status. For ccw, completion of the command is required
    > before the driver can issue another command (such as to check the device
    > status). What I wanted to say here is that the driver is already free to
    > consider the reset complete if the command was successful, but that it
    > can read back the status _after_ the reset command is through to satisfy
    > the generic SHOULD statement.


    Ok, I'm fine with that.

    Thanks


    >




  • 6.  Re: [PATCH] ccw: clarify device reset

    Posted 10-13-2021 07:01
    On Wed, Oct 13 2021, Jason Wang <jasowang@redhat.com> wrote:

    > Btw I found the link to S390 Common I/O is broken (at least I can't
    > access it from China):
    >
    > http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar501/CCONTENTS

    I'm getting 500 as well.

    Halil, do you know if this has moved somewhere else? If yes, we need to
    update the link.




  • 7.  Re: [PATCH] ccw: clarify device reset

    Posted 10-13-2021 07:01
    On Wed, Oct 13 2021, Jason Wang <jasowang@redhat.com> wrote: > Btw I found the link to S390 Common I/O is broken (at least I can't > access it from China): > > http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar501/CCONTENTS I'm getting 500 as well. Halil, do you know if this has moved somewhere else? If yes, we need to update the link.


  • 8.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-21-2021 16:24
    On Wed, Oct 13 2021, Cornelia Huck <cohuck@redhat.com> wrote:

    > On Wed, Oct 13 2021, Jason Wang <jasowang@redhat.com> wrote:
    >
    >> Btw I found the link to S390 Common I/O is broken (at least I can't
    >> access it from China):
    >>
    >> http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar501/CCONTENTS
    >
    > I'm getting 500 as well.

    Hm, still getting 500, so not a transient error :(

    >
    > Halil, do you know if this has moved somewhere else? If yes, we need to
    > update the link.

    Also, do you have any feedback on this patch?




  • 9.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-21-2021 16:24
    On Wed, Oct 13 2021, Cornelia Huck <cohuck@redhat.com> wrote: > On Wed, Oct 13 2021, Jason Wang <jasowang@redhat.com> wrote: > >> Btw I found the link to S390 Common I/O is broken (at least I can't >> access it from China): >> >> http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar501/CCONTENTS > > I'm getting 500 as well. Hm, still getting 500, so not a transient error :( > > Halil, do you know if this has moved somewhere else? If yes, we need to > update the link. Also, do you have any feedback on this patch?


  • 10.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-21-2021 23:35
    On Thu, 21 Oct 2021 18:23:51 +0200
    Cornelia Huck <cohuck@redhat.com> wrote:

    > >
    > > Halil, do you know if this has moved somewhere else? If yes, we need to
    > > update the link.
    >

    I can't remember they told me about moving it ;)

    I've found this one, and my guess is it works form the outside:

    https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401


    > Also, do you have any feedback on this patch?

    I didn't see anything obviously wrong.

    """
    +The device signals completion of the reset operation by making the subchannel
    +status pending to indicate successful completion of the channel command.
    """

    may be little ambiguous. IMHO the point we should make is that the
    successful completion of the virtio reset happens before the
    successful completion of the ccw that requested the operation. "Status
    pending" is a little broad. We could get status pending with something
    like alert status, at least in theory. And if somebody silly would put
    the reset command with more commands following it in a channel program,
    we would not have to wait for the channel to complete and to see a status pending
    indicated at the subchannel.

    Another interesting question for the reset is system boundary. I.e. what
    exactly is reset. Some publications describe possible electric
    signaling interfaces, and I doubt this kind of a reset would be a
    complete reset of the device from that perspective. But that question is
    not what this patch is about. It just came to my mind.

    Sorry guys I'm already with one foot in vacation. This is the extent to
    which I can contribute right now.

    Regards,
    Halil



  • 11.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-21-2021 23:36
    On Thu, 21 Oct 2021 18:23:51 +0200 Cornelia Huck <cohuck@redhat.com> wrote: > > > > Halil, do you know if this has moved somewhere else? If yes, we need to > > update the link. > I can't remember they told me about moving it ;) I've found this one, and my guess is it works form the outside: https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401 > Also, do you have any feedback on this patch? I didn't see anything obviously wrong. """ +The device signals completion of the reset operation by making the subchannel +status pending to indicate successful completion of the channel command. """ may be little ambiguous. IMHO the point we should make is that the successful completion of the virtio reset happens before the successful completion of the ccw that requested the operation. "Status pending" is a little broad. We could get status pending with something like alert status, at least in theory. And if somebody silly would put the reset command with more commands following it in a channel program, we would not have to wait for the channel to complete and to see a status pending indicated at the subchannel. Another interesting question for the reset is system boundary. I.e. what exactly is reset. Some publications describe possible electric signaling interfaces, and I doubt this kind of a reset would be a complete reset of the device from that perspective. But that question is not what this patch is about. It just came to my mind. Sorry guys I'm already with one foot in vacation. This is the extent to which I can contribute right now. Regards, Halil


  • 12.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-25-2021 01:29
    On Fri, Oct 22, 2021 at 7:35 AM Halil Pasic <pasic@linux.ibm.com> wrote:
    >
    > On Thu, 21 Oct 2021 18:23:51 +0200
    > Cornelia Huck <cohuck@redhat.com> wrote:
    >
    > > >
    > > > Halil, do you know if this has moved somewhere else? If yes, we need to
    > > > update the link.
    > >
    >
    > I can't remember they told me about moving it ;)
    >
    > I've found this one, and my guess is it works form the outside:
    >
    > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401
    >
    >
    > > Also, do you have any feedback on this patch?
    >
    > I didn't see anything obviously wrong.
    >
    > """
    > +The device signals completion of the reset operation by making the subchannel
    > +status pending to indicate successful completion of the channel command.
    > """
    >
    > may be little ambiguous. IMHO the point we should make is that the
    > successful completion of the virtio reset happens before the
    > successful completion of the ccw that requested the operation. "Status
    > pending" is a little broad. We could get status pending with something
    > like alert status, at least in theory. And if somebody silly would put
    > the reset command with more commands following it in a channel program,
    > we would not have to wait for the channel to complete and to see a status pending
    > indicated at the subchannel.
    >
    > Another interesting question for the reset is system boundary. I.e. what
    > exactly is reset. Some publications describe possible electric
    > signaling interfaces, and I doubt this kind of a reset would be a
    > complete reset of the device from that perspective. But that question is
    > not what this patch is about. It just came to my mind.

    Since virtio is built on top of the transport. I think the lower level
    (transport) reset implies a virtio reset.

    Thanks

    >
    > Sorry guys I'm already with one foot in vacation. This is the extent to
    > which I can contribute right now.
    >
    > Regards,
    > Halil
    >




  • 13.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-25-2021 07:37
    On Mon, Oct 25 2021, Jason Wang <jasowang@redhat.com> wrote:

    > On Fri, Oct 22, 2021 at 7:35 AM Halil Pasic <pasic@linux.ibm.com> wrote:
    >> Another interesting question for the reset is system boundary. I.e. what
    >> exactly is reset. Some publications describe possible electric
    >> signaling interfaces, and I doubt this kind of a reset would be a
    >> complete reset of the device from that perspective. But that question is
    >> not what this patch is about. It just came to my mind.
    >
    > Since virtio is built on top of the transport. I think the lower level
    > (transport) reset implies a virtio reset.

    ...ok, maybe I misrepresented your reply in my reply to Halil (should
    not write before the first coffee). But I would indeed expect a
    low-level reset (e.g. a channel subsystem reset) to imply that the
    virtio structures are reset as well.




  • 14.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-25-2021 07:37
    On Mon, Oct 25 2021, Jason Wang <jasowang@redhat.com> wrote: > On Fri, Oct 22, 2021 at 7:35 AM Halil Pasic <pasic@linux.ibm.com> wrote: >> Another interesting question for the reset is system boundary. I.e. what >> exactly is reset. Some publications describe possible electric >> signaling interfaces, and I doubt this kind of a reset would be a >> complete reset of the device from that perspective. But that question is >> not what this patch is about. It just came to my mind. > > Since virtio is built on top of the transport. I think the lower level > (transport) reset implies a virtio reset. ...ok, maybe I misrepresented your reply in my reply to Halil (should not write before the first coffee). But I would indeed expect a low-level reset (e.g. a channel subsystem reset) to imply that the virtio structures are reset as well.


  • 15.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-25-2021 07:34
    On Fri, Oct 22 2021, Halil Pasic <pasic@linux.ibm.com> wrote:

    > On Thu, 21 Oct 2021 18:23:51 +0200
    > Cornelia Huck <cohuck@redhat.com> wrote:
    >
    >> >
    >> > Halil, do you know if this has moved somewhere else? If yes, we need to
    >> > update the link.
    >>
    >
    > I can't remember they told me about moving it ;)
    >
    > I've found this one, and my guess is it works form the outside:
    >
    > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401

    Hm, this one is accessible; however, the 'view' link leads to the same
    500 again, and the 'download' link does not seem to do anything for me...

    >
    >
    >> Also, do you have any feedback on this patch?
    >
    > I didn't see anything obviously wrong.
    >
    > """
    > +The device signals completion of the reset operation by making the subchannel
    > +status pending to indicate successful completion of the channel command.
    > """
    >
    > may be little ambiguous. IMHO the point we should make is that the
    > successful completion of the virtio reset happens before the
    > successful completion of the ccw that requested the operation. "Status
    > pending" is a little broad. We could get status pending with something
    > like alert status, at least in theory. And if somebody silly would put
    > the reset command with more commands following it in a channel program,
    > we would not have to wait for the channel to complete and to see a status pending
    > indicated at the subchannel.

    Right, chaining something else to reset was not something that I had
    considered. I basically wanted a condition that says "the device has
    finished processing the reset ccw, and the driver has a way of knowing
    about this." The driver can find out by looking at the ccw address in
    the scsw, but has to keep the complicated rules for validity of that
    field in mind; that might be too esoteric for the virtio spec. Maybe

    "If the reset command is the last or only channel command in the command
    chain, the device signals completion..."

    Or is simply enough to note that reset is done once the device has
    processed the reset ccw? We should not need to explain the fine details
    of channel I/O processing in the spec.

    >
    > Another interesting question for the reset is system boundary. I.e. what
    > exactly is reset. Some publications describe possible electric
    > signaling interfaces, and I doubt this kind of a reset would be a
    > complete reset of the device from that perspective. But that question is
    > not what this patch is about. It just came to my mind.

    As Jason noted in his mail, that's just virtio-specific reset.

    >
    > Sorry guys I'm already with one foot in vacation. This is the extent to
    > which I can contribute right now.

    Enjoy your vacation!




  • 16.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-25-2021 07:34
    On Fri, Oct 22 2021, Halil Pasic <pasic@linux.ibm.com> wrote: > On Thu, 21 Oct 2021 18:23:51 +0200 > Cornelia Huck <cohuck@redhat.com> wrote: > >> > >> > Halil, do you know if this has moved somewhere else? If yes, we need to >> > update the link. >> > > I can't remember they told me about moving it ;) > > I've found this one, and my guess is it works form the outside: > > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401 Hm, this one is accessible; however, the 'view' link leads to the same 500 again, and the 'download' link does not seem to do anything for me... > > >> Also, do you have any feedback on this patch? > > I didn't see anything obviously wrong. > > """ > +The device signals completion of the reset operation by making the subchannel > +status pending to indicate successful completion of the channel command. > """ > > may be little ambiguous. IMHO the point we should make is that the > successful completion of the virtio reset happens before the > successful completion of the ccw that requested the operation. "Status > pending" is a little broad. We could get status pending with something > like alert status, at least in theory. And if somebody silly would put > the reset command with more commands following it in a channel program, > we would not have to wait for the channel to complete and to see a status pending > indicated at the subchannel. Right, chaining something else to reset was not something that I had considered. I basically wanted a condition that says "the device has finished processing the reset ccw, and the driver has a way of knowing about this." The driver can find out by looking at the ccw address in the scsw, but has to keep the complicated rules for validity of that field in mind; that might be too esoteric for the virtio spec. Maybe "If the reset command is the last or only channel command in the command chain, the device signals completion..." Or is simply enough to note that reset is done once the device has processed the reset ccw? We should not need to explain the fine details of channel I/O processing in the spec. > > Another interesting question for the reset is system boundary. I.e. what > exactly is reset. Some publications describe possible electric > signaling interfaces, and I doubt this kind of a reset would be a > complete reset of the device from that perspective. But that question is > not what this patch is about. It just came to my mind. As Jason noted in his mail, that's just virtio-specific reset. > > Sorry guys I'm already with one foot in vacation. This is the extent to > which I can contribute right now. Enjoy your vacation!


  • 17.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-27-2021 07:59
    On Mon, 25 Oct 2021 09:34:02 +0200
    Cornelia Huck <cohuck@redhat.com> wrote:

    > > I can't remember they told me about moving it ;)
    > >
    > > I've found this one, and my guess is it works form the outside:
    > >
    > > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401
    >
    > Hm, this one is accessible; however, the 'view' link leads to the same
    > 500 again, and the 'download' link does not seem to do anything for me...

    I can confirm that the 'Read' link leads to the same dead-end. But
    download did work for me. I got a .boo file.

    I've contacted the guys who should be responsible for the above page.
    Maybe they can help fix the issue. Will let you know when/if something
    good happens.

    Regards,
    Halil



  • 18.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-27-2021 07:59
    On Mon, 25 Oct 2021 09:34:02 +0200 Cornelia Huck <cohuck@redhat.com> wrote: > > I can't remember they told me about moving it ;) > > > > I've found this one, and my guess is it works form the outside: > > > > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401 > > Hm, this one is accessible; however, the 'view' link leads to the same > 500 again, and the 'download' link does not seem to do anything for me... I can confirm that the 'Read' link leads to the same dead-end. But download did work for me. I got a .boo file. I've contacted the guys who should be responsible for the above page. Maybe they can help fix the issue. Will let you know when/if something good happens. Regards, Halil


  • 19.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-27-2021 08:03
    On Wed, Oct 27, 2021 at 3:59 PM Halil Pasic <pasic@linux.ibm.com> wrote:
    >
    > On Mon, 25 Oct 2021 09:34:02 +0200
    > Cornelia Huck <cohuck@redhat.com> wrote:
    >
    > > > I can't remember they told me about moving it ;)
    > > >
    > > > I've found this one, and my guess is it works form the outside:
    > > >
    > > > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401
    > >
    > > Hm, this one is accessible; however, the 'view' link leads to the same
    > > 500 again, and the 'download' link does not seem to do anything for me...
    >
    > I can confirm that the 'Read' link leads to the same dead-end. But
    > download did work for me. I got a .boo file.

    Downloading doesn't work for me. Just no response.

    Thanks

    >
    > I've contacted the guys who should be responsible for the above page.
    > Maybe they can help fix the issue. Will let you know when/if something
    > good happens.
    >
    > Regards,
    > Halil
    >




  • 20.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-27-2021 09:16
    On Wed, Oct 27 2021, Halil Pasic <pasic@linux.ibm.com> wrote:

    > On Mon, 25 Oct 2021 09:34:02 +0200
    > Cornelia Huck <cohuck@redhat.com> wrote:
    >
    >> > I can't remember they told me about moving it ;)
    >> >
    >> > I've found this one, and my guess is it works form the outside:
    >> >
    >> > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401
    >>
    >> Hm, this one is accessible; however, the 'view' link leads to the same
    >> 500 again, and the 'download' link does not seem to do anything for me...
    >
    > I can confirm that the 'Read' link leads to the same dead-end. But
    > download did work for me. I got a .boo file.

    Maybe the download does not work outside of your vpn? Anyway, a .pdf
    would be much more useful than a .boo, but I understand that it is an
    ancient document.

    >
    > I've contacted the guys who should be responsible for the above page.
    > Maybe they can help fix the issue. Will let you know when/if something
    > good happens.

    Thanks a lot!




  • 21.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-27-2021 09:16
    On Wed, Oct 27 2021, Halil Pasic <pasic@linux.ibm.com> wrote: > On Mon, 25 Oct 2021 09:34:02 +0200 > Cornelia Huck <cohuck@redhat.com> wrote: > >> > I can't remember they told me about moving it ;) >> > >> > I've found this one, and my guess is it works form the outside: >> > >> > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401 >> >> Hm, this one is accessible; however, the 'view' link leads to the same >> 500 again, and the 'download' link does not seem to do anything for me... > > I can confirm that the 'Read' link leads to the same dead-end. But > download did work for me. I got a .boo file. Maybe the download does not work outside of your vpn? Anyway, a .pdf would be much more useful than a .boo, but I understand that it is an ancient document. > > I've contacted the guys who should be responsible for the above page. > Maybe they can help fix the issue. Will let you know when/if something > good happens. Thanks a lot!


  • 22.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-27-2021 22:25
    On Wed, 27 Oct 2021 11:16:22 +0200
    Cornelia Huck <cohuck@redhat.com> wrote:

    > On Wed, Oct 27 2021, Halil Pasic <pasic@linux.ibm.com> wrote:
    >
    > > On Mon, 25 Oct 2021 09:34:02 +0200
    > > Cornelia Huck <cohuck@redhat.com> wrote:
    > >
    > >> > I can't remember they told me about moving it ;)
    > >> >
    > >> > I've found this one, and my guess is it works form the outside:
    > >> >
    > >> > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401
    > >>
    > >> Hm, this one is accessible; however, the 'view' link leads to the same
    > >> 500 again, and the 'download' link does not seem to do anything for me...
    > >
    > > I can confirm that the 'Read' link leads to the same dead-end. But
    > > download did work for me. I got a .boo file.
    >
    > Maybe the download does not work outside of your vpn? Anyway, a .pdf
    > would be much more useful than a .boo, but I understand that it is an
    > ancient document.

    Tried it without VPN, it still works. More precisely the 'Download via
    HTTP' does, and the 'Download Director' link does nothing for me. Did
    you click the former or the latter one?

    Regarding 'Download Director' I suppose one needs to install the applet
    first. The page does link to the installation guide, but I never
    bothered installing it.

    Regards,
    Halil



  • 23.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-27-2021 22:25
    On Wed, 27 Oct 2021 11:16:22 +0200 Cornelia Huck <cohuck@redhat.com> wrote: > On Wed, Oct 27 2021, Halil Pasic <pasic@linux.ibm.com> wrote: > > > On Mon, 25 Oct 2021 09:34:02 +0200 > > Cornelia Huck <cohuck@redhat.com> wrote: > > > >> > I can't remember they told me about moving it ;) > >> > > >> > I've found this one, and my guess is it works form the outside: > >> > > >> > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401 > >> > >> Hm, this one is accessible; however, the 'view' link leads to the same > >> 500 again, and the 'download' link does not seem to do anything for me... > > > > I can confirm that the 'Read' link leads to the same dead-end. But > > download did work for me. I got a .boo file. > > Maybe the download does not work outside of your vpn? Anyway, a .pdf > would be much more useful than a .boo, but I understand that it is an > ancient document. Tried it without VPN, it still works. More precisely the 'Download via HTTP' does, and the 'Download Director' link does nothing for me. Did you click the former or the latter one? Regarding 'Download Director' I suppose one needs to install the applet first. The page does link to the installation guide, but I never bothered installing it. Regards, Halil


  • 24.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-28-2021 06:55
    On Thu, Oct 28 2021, Halil Pasic <pasic@linux.ibm.com> wrote:

    > On Wed, 27 Oct 2021 11:16:22 +0200
    > Cornelia Huck <cohuck@redhat.com> wrote:
    >
    >> On Wed, Oct 27 2021, Halil Pasic <pasic@linux.ibm.com> wrote:
    >>
    >> > On Mon, 25 Oct 2021 09:34:02 +0200
    >> > Cornelia Huck <cohuck@redhat.com> wrote:
    >> >
    >> >> > I can't remember they told me about moving it ;)
    >> >> >
    >> >> > I've found this one, and my guess is it works form the outside:
    >> >> >
    >> >> > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401
    >> >>
    >> >> Hm, this one is accessible; however, the 'view' link leads to the same
    >> >> 500 again, and the 'download' link does not seem to do anything for me...
    >> >
    >> > I can confirm that the 'Read' link leads to the same dead-end. But
    >> > download did work for me. I got a .boo file.
    >>
    >> Maybe the download does not work outside of your vpn? Anyway, a .pdf
    >> would be much more useful than a .boo, but I understand that it is an
    >> ancient document.
    >
    > Tried it without VPN, it still works. More precisely the 'Download via
    > HTTP' does, and the 'Download Director' link does nothing for me. Did
    > you click the former or the latter one?

    Tried again, now it worked. Might have been that "I agree" checkbox.

    Still, .boo is not terribly useful (I don't know which application can
    read it, and there's no MIME-type for it.) The viewer allowed me to
    download a .pdf :(

    > Regarding 'Download Director' I suppose one needs to install the applet
    > first. The page does link to the installation guide, but I never
    > bothered installing it.

    Yes, I'm not sure I want to install some Java thing anyway.




  • 25.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 10-28-2021 06:56
    On Thu, Oct 28 2021, Halil Pasic <pasic@linux.ibm.com> wrote: > On Wed, 27 Oct 2021 11:16:22 +0200 > Cornelia Huck <cohuck@redhat.com> wrote: > >> On Wed, Oct 27 2021, Halil Pasic <pasic@linux.ibm.com> wrote: >> >> > On Mon, 25 Oct 2021 09:34:02 +0200 >> > Cornelia Huck <cohuck@redhat.com> wrote: >> > >> >> > I can't remember they told me about moving it ;) >> >> > >> >> > I've found this one, and my guess is it works form the outside: >> >> > >> >> > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401 >> >> >> >> Hm, this one is accessible; however, the 'view' link leads to the same >> >> 500 again, and the 'download' link does not seem to do anything for me... >> > >> > I can confirm that the 'Read' link leads to the same dead-end. But >> > download did work for me. I got a .boo file. >> >> Maybe the download does not work outside of your vpn? Anyway, a .pdf >> would be much more useful than a .boo, but I understand that it is an >> ancient document. > > Tried it without VPN, it still works. More precisely the 'Download via > HTTP' does, and the 'Download Director' link does nothing for me. Did > you click the former or the latter one? Tried again, now it worked. Might have been that "I agree" checkbox. Still, .boo is not terribly useful (I don't know which application can read it, and there's no MIME-type for it.) The viewer allowed me to download a .pdf :( > Regarding 'Download Director' I suppose one needs to install the applet > first. The page does link to the installation guide, but I never > bothered installing it. Yes, I'm not sure I want to install some Java thing anyway.


  • 26.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 11-26-2021 12:07
    On Wed, Oct 27 2021, Halil Pasic <pasic@linux.ibm.com> wrote:

    > On Mon, 25 Oct 2021 09:34:02 +0200
    > Cornelia Huck <cohuck@redhat.com> wrote:
    >
    >> > I can't remember they told me about moving it ;)
    >> >
    >> > I've found this one, and my guess is it works form the outside:
    >> >
    >> > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401
    >>
    >> Hm, this one is accessible; however, the 'view' link leads to the same
    >> 500 again, and the 'download' link does not seem to do anything for me...
    >
    > I can confirm that the 'Read' link leads to the same dead-end. But
    > download did work for me. I got a .boo file.
    >
    > I've contacted the guys who should be responsible for the above page.
    > Maybe they can help fix the issue. Will let you know when/if something
    > good happens.

    As I've been looking at this thread again: Have you ever heard anything
    back? The 'Read' link remains broken :(




  • 27.  Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 11-26-2021 12:08
    On Wed, Oct 27 2021, Halil Pasic <pasic@linux.ibm.com> wrote: > On Mon, 25 Oct 2021 09:34:02 +0200 > Cornelia Huck <cohuck@redhat.com> wrote: > >> > I can't remember they told me about moving it ;) >> > >> > I've found this one, and my guess is it works form the outside: >> > >> > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SA22720401 >> >> Hm, this one is accessible; however, the 'view' link leads to the same >> 500 again, and the 'download' link does not seem to do anything for me... > > I can confirm that the 'Read' link leads to the same dead-end. But > download did work for me. I got a .boo file. > > I've contacted the guys who should be responsible for the above page. > Maybe they can help fix the issue. Will let you know when/if something > good happens. As I've been looking at this thread again: Have you ever heard anything back? The 'Read' link remains broken :(


  • 28.  Re: [virtio-comment] Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 11-26-2021 17:11
    On Fri, 26 Nov 2021 13:07:25 +0100
    Cornelia Huck <cohuck@redhat.com> wrote:

    > > I've contacted the guys who should be responsible for the above page.
    > > Maybe they can help fix the issue. Will let you know when/if something
    > > good happens.
    >
    > As I've been looking at this thread again: Have you ever heard anything
    > back? The 'Read' link remains broken :(

    Yes I have. They acknowledge that this ain't acceptable user experience
    and are allegedly working with the respective dev team on solving the
    issue. I can ping my ticket...

    Regards,
    Halil



  • 29.  Re: [virtio-comment] Re: [virtio] Re: [PATCH] ccw: clarify device reset

    Posted 11-26-2021 17:11
    On Fri, 26 Nov 2021 13:07:25 +0100 Cornelia Huck <cohuck@redhat.com> wrote: > > I've contacted the guys who should be responsible for the above page. > > Maybe they can help fix the issue. Will let you know when/if something > > good happens. > > As I've been looking at this thread again: Have you ever heard anything > back? The 'Read' link remains broken :( Yes I have. They acknowledge that this ain't acceptable user experience and are allegedly working with the respective dev team on solving the issue. I can ping my ticket... Regards, Halil