* [PATCH] ccw: clarify device reset @ 2021-10-11 11:38 Cornelia Huck 2021-10-12 2:54 ` Jason Wang 0 siblings, 1 reply; 17+ messages in thread From: Cornelia Huck @ 2021-10-11 11:38 UTC (permalink / raw) To: virtio, virtio-comment; +Cc: Jason Wang, Halil Pasic, Cornelia Huck 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. +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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] ccw: clarify device reset 2021-10-11 11:38 [PATCH] ccw: clarify device reset Cornelia Huck @ 2021-10-12 2:54 ` Jason Wang 2021-10-12 11:16 ` [virtio] " Cornelia Huck 0 siblings, 1 reply; 17+ messages in thread From: Jason Wang @ 2021-10-12 2:54 UTC (permalink / raw) To: Cornelia Huck; +Cc: virtio, virtio-comment, Halil Pasic 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-12 2:54 ` Jason Wang @ 2021-10-12 11:16 ` Cornelia Huck 2021-10-13 6:20 ` Jason Wang 0 siblings, 1 reply; 17+ messages in thread From: Cornelia Huck @ 2021-10-12 11:16 UTC (permalink / raw) To: Jason Wang; +Cc: virtio, virtio-comment, Halil Pasic 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. --------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] ccw: clarify device reset 2021-10-12 11:16 ` [virtio] " Cornelia Huck @ 2021-10-13 6:20 ` Jason Wang 2021-10-13 7:01 ` [virtio] " Cornelia Huck 0 siblings, 1 reply; 17+ messages in thread From: Jason Wang @ 2021-10-13 6:20 UTC (permalink / raw) To: Cornelia Huck; +Cc: virtio, virtio-comment, Halil Pasic 在 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-13 6:20 ` Jason Wang @ 2021-10-13 7:01 ` Cornelia Huck 2021-10-21 16:23 ` Cornelia Huck 0 siblings, 1 reply; 17+ messages in thread From: Cornelia Huck @ 2021-10-13 7:01 UTC (permalink / raw) To: Jason Wang; +Cc: virtio, virtio-comment, Halil Pasic 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. --------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-13 7:01 ` [virtio] " Cornelia Huck @ 2021-10-21 16:23 ` Cornelia Huck 2021-10-21 23:35 ` Halil Pasic 0 siblings, 1 reply; 17+ messages in thread From: Cornelia Huck @ 2021-10-21 16:23 UTC (permalink / raw) To: Halil Pasic; +Cc: virtio, virtio-comment, Jason Wang 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? --------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-21 16:23 ` Cornelia Huck @ 2021-10-21 23:35 ` Halil Pasic 2021-10-25 1:29 ` Jason Wang 2021-10-25 7:34 ` Cornelia Huck 0 siblings, 2 replies; 17+ messages in thread From: Halil Pasic @ 2021-10-21 23:35 UTC (permalink / raw) To: Cornelia Huck; +Cc: virtio, virtio-comment, Jason Wang, Halil Pasic 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-21 23:35 ` Halil Pasic @ 2021-10-25 1:29 ` Jason Wang 2021-10-25 7:36 ` Cornelia Huck 2021-10-25 7:34 ` Cornelia Huck 1 sibling, 1 reply; 17+ messages in thread From: Jason Wang @ 2021-10-25 1:29 UTC (permalink / raw) To: Halil Pasic; +Cc: Cornelia Huck, virtio, virtio-comment 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-25 1:29 ` Jason Wang @ 2021-10-25 7:36 ` Cornelia Huck 0 siblings, 0 replies; 17+ messages in thread From: Cornelia Huck @ 2021-10-25 7:36 UTC (permalink / raw) To: Jason Wang, Halil Pasic; +Cc: virtio, virtio-comment 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. --------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-21 23:35 ` Halil Pasic 2021-10-25 1:29 ` Jason Wang @ 2021-10-25 7:34 ` Cornelia Huck 2021-10-27 7:58 ` Halil Pasic 1 sibling, 1 reply; 17+ messages in thread From: Cornelia Huck @ 2021-10-25 7:34 UTC (permalink / raw) To: Halil Pasic; +Cc: virtio, virtio-comment, Jason Wang, Halil Pasic 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! --------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-25 7:34 ` Cornelia Huck @ 2021-10-27 7:58 ` Halil Pasic 2021-10-27 8:02 ` Jason Wang ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Halil Pasic @ 2021-10-27 7:58 UTC (permalink / raw) To: Cornelia Huck; +Cc: virtio, virtio-comment, Jason Wang, Halil Pasic 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-27 7:58 ` Halil Pasic @ 2021-10-27 8:02 ` Jason Wang 2021-10-27 9:16 ` Cornelia Huck 2021-11-26 12:07 ` Cornelia Huck 2 siblings, 0 replies; 17+ messages in thread From: Jason Wang @ 2021-10-27 8:02 UTC (permalink / raw) To: Halil Pasic; +Cc: Cornelia Huck, virtio, virtio-comment 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-27 7:58 ` Halil Pasic 2021-10-27 8:02 ` Jason Wang @ 2021-10-27 9:16 ` Cornelia Huck 2021-10-27 22:25 ` Halil Pasic 2021-11-26 12:07 ` Cornelia Huck 2 siblings, 1 reply; 17+ messages in thread From: Cornelia Huck @ 2021-10-27 9:16 UTC (permalink / raw) To: Halil Pasic; +Cc: virtio, virtio-comment, Jason Wang, Halil Pasic 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! --------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-27 9:16 ` Cornelia Huck @ 2021-10-27 22:25 ` Halil Pasic 2021-10-28 6:55 ` [virtio-comment] " Cornelia Huck 0 siblings, 1 reply; 17+ messages in thread From: Halil Pasic @ 2021-10-27 22:25 UTC (permalink / raw) To: Cornelia Huck; +Cc: virtio, virtio-comment, Jason Wang, Halil Pasic 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [virtio-comment] Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-27 22:25 ` Halil Pasic @ 2021-10-28 6:55 ` Cornelia Huck 0 siblings, 0 replies; 17+ messages in thread From: Cornelia Huck @ 2021-10-28 6:55 UTC (permalink / raw) To: Halil Pasic; +Cc: virtio, virtio-comment, Jason Wang, Halil Pasic 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. This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* [virtio-comment] Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-10-27 7:58 ` Halil Pasic 2021-10-27 8:02 ` Jason Wang 2021-10-27 9:16 ` Cornelia Huck @ 2021-11-26 12:07 ` Cornelia Huck 2021-11-26 17:11 ` Halil Pasic 2 siblings, 1 reply; 17+ messages in thread From: Cornelia Huck @ 2021-11-26 12:07 UTC (permalink / raw) To: Halil Pasic; +Cc: virtio, virtio-comment, Jason Wang 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 :( This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [virtio-comment] Re: [virtio] Re: [PATCH] ccw: clarify device reset 2021-11-26 12:07 ` Cornelia Huck @ 2021-11-26 17:11 ` Halil Pasic 0 siblings, 0 replies; 17+ messages in thread From: Halil Pasic @ 2021-11-26 17:11 UTC (permalink / raw) To: Cornelia Huck; +Cc: virtio, virtio-comment, Jason Wang, Halil Pasic 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-11-26 17:11 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-11 11:38 [PATCH] ccw: clarify device reset Cornelia Huck 2021-10-12 2:54 ` Jason Wang 2021-10-12 11:16 ` [virtio] " Cornelia Huck 2021-10-13 6:20 ` Jason Wang 2021-10-13 7:01 ` [virtio] " Cornelia Huck 2021-10-21 16:23 ` Cornelia Huck 2021-10-21 23:35 ` Halil Pasic 2021-10-25 1:29 ` Jason Wang 2021-10-25 7:36 ` Cornelia Huck 2021-10-25 7:34 ` Cornelia Huck 2021-10-27 7:58 ` Halil Pasic 2021-10-27 8:02 ` Jason Wang 2021-10-27 9:16 ` Cornelia Huck 2021-10-27 22:25 ` Halil Pasic 2021-10-28 6:55 ` [virtio-comment] " Cornelia Huck 2021-11-26 12:07 ` Cornelia Huck 2021-11-26 17:11 ` Halil Pasic
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.