[PATCH] ccw: clarify device reset

[PATCH] ccw: clarify device reset

[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

Re: [PATCH] ccw: clarify device reset

[Jason Wang]

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
>

[virtio] Re: [PATCH] ccw: clarify device reset

[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. 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 

Re: [PATCH] ccw: clarify device reset

[Jason Wang]

在 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


>

[virtio] Re: [PATCH] ccw: clarify device reset

[Cornelia Huck]

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 

Re: [virtio] Re: [PATCH] ccw: clarify device reset

[Cornelia Huck]

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 

Re: [virtio] Re: [PATCH] ccw: clarify device reset

[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

Re: [virtio] Re: [PATCH] ccw: clarify device reset

[Jason Wang]

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
>

Re: [virtio] Re: [PATCH] ccw: clarify device reset

[Cornelia Huck]

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 

Re: [virtio] Re: [PATCH] ccw: clarify device reset

[Cornelia Huck]

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 

Re: [virtio] Re: [PATCH] ccw: clarify device reset

[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

Re: [virtio] Re: [PATCH] ccw: clarify device reset

[Jason Wang]

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
>

Re: [virtio] Re: [PATCH] ccw: clarify device reset

[Cornelia Huck]

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 

Re: [virtio] Re: [PATCH] ccw: clarify device reset

[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

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

[Cornelia Huck]

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/

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

[Cornelia Huck]

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/

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

[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