diff mbox series

[RFC,v2,2/9] vfio-ccw: Register a chp_event callback for vfio-ccw

Message ID 20200206213825.11444-3-farman@linux.ibm.com (mailing list archive)
State New, archived
Headers show
Series s390x/vfio-ccw: Channel Path Handling | expand

Commit Message

Eric Farman Feb. 6, 2020, 9:38 p.m. UTC
From: Farhan Ali <alifm@linux.ibm.com>

Register the chp_event callback to receive channel path related
events for the subchannels managed by vfio-ccw.

Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
Signed-off-by: Eric Farman <farman@linux.ibm.com>
---

Notes:
    v1->v2:
     - Move s390dbf before cio_update_schib() call [CH]
    
    v0->v1: [EF]
     - Add s390dbf trace

 drivers/s390/cio/vfio_ccw_drv.c | 44 +++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

Comments

Cornelia Huck Feb. 14, 2020, 12:11 p.m. UTC | #1
On Thu,  6 Feb 2020 22:38:18 +0100
Eric Farman <farman@linux.ibm.com> wrote:

> From: Farhan Ali <alifm@linux.ibm.com>
> 
> Register the chp_event callback to receive channel path related
> events for the subchannels managed by vfio-ccw.

I'm wondering how useful this patch would be on its own.

> 
> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
> 
> Notes:
>     v1->v2:
>      - Move s390dbf before cio_update_schib() call [CH]
>     
>     v0->v1: [EF]
>      - Add s390dbf trace
> 
>  drivers/s390/cio/vfio_ccw_drv.c | 44 +++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
(...)
> @@ -257,6 +258,48 @@ static int vfio_ccw_sch_event(struct subchannel *sch, int process)
>  	return rc;
>  }
>  
> +static int vfio_ccw_chp_event(struct subchannel *sch,
> +			      struct chp_link *link, int event)
> +{
> +	struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
> +	int mask = chp_ssd_get_mask(&sch->ssd_info, link);
> +	int retry = 255;
> +
> +	if (!private || !mask)
> +		return 0;
> +
> +	VFIO_CCW_MSG_EVENT(2, "%pUl (%x.%x.%04x): mask=0x%x event=%d\n",
> +			   mdev_uuid(private->mdev), sch->schid.cssid,
> +			   sch->schid.ssid, sch->schid.sch_no,
> +			   mask, event);
> +
> +	if (cio_update_schib(sch))
> +		return -ENODEV;
> +
> +	switch (event) {
> +	case CHP_VARY_OFF:
> +		/* Path logically turned off */
> +		sch->opm &= ~mask;
> +		sch->lpm &= ~mask;
> +		break;
> +	case CHP_OFFLINE:
> +		/* Path is gone */
> +		cio_cancel_halt_clear(sch, &retry);

Any reason you do this only for CHP_OFFLINE and not for CHP_VARY_OFF?

> +		break;
> +	case CHP_VARY_ON:
> +		/* Path logically turned on */
> +		sch->opm |= mask;
> +		sch->lpm |= mask;
> +		break;
> +	case CHP_ONLINE:
> +		/* Path became available */
> +		sch->lpm |= mask & sch->opm;

If I'm not mistaken, this patch introduces the first usage of sch->opm
in the vfio-ccw code. Are we missing something? Or am I missing
something? :)

> +		break;
> +	}
> +
> +	return 0;
> +}
> +
>  static struct css_device_id vfio_ccw_sch_ids[] = {
>  	{ .match_flags = 0x1, .type = SUBCHANNEL_TYPE_IO, },
>  	{ /* end of list */ },
(...)
Eric Farman Feb. 14, 2020, 4:35 p.m. UTC | #2
On 2/14/20 7:11 AM, Cornelia Huck wrote:
> On Thu,  6 Feb 2020 22:38:18 +0100
> Eric Farman <farman@linux.ibm.com> wrote:
> 
>> From: Farhan Ali <alifm@linux.ibm.com>
>>
>> Register the chp_event callback to receive channel path related
>> events for the subchannels managed by vfio-ccw.
> 
> I'm wondering how useful this patch would be on its own.

Probably not much.  I can't speak to his original thoughts on the
matter, but it doesn't seem to buy us much by itself other than a
consumable sized patch.

> 
>>
>> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
>> Signed-off-by: Eric Farman <farman@linux.ibm.com>
>> ---
>>
>> Notes:
>>     v1->v2:
>>      - Move s390dbf before cio_update_schib() call [CH]
>>     
>>     v0->v1: [EF]
>>      - Add s390dbf trace
>>
>>  drivers/s390/cio/vfio_ccw_drv.c | 44 +++++++++++++++++++++++++++++++++
>>  1 file changed, 44 insertions(+)
>>
> (...)
>> @@ -257,6 +258,48 @@ static int vfio_ccw_sch_event(struct subchannel *sch, int process)
>>  	return rc;
>>  }
>>  
>> +static int vfio_ccw_chp_event(struct subchannel *sch,
>> +			      struct chp_link *link, int event)
>> +{
>> +	struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
>> +	int mask = chp_ssd_get_mask(&sch->ssd_info, link);
>> +	int retry = 255;
>> +
>> +	if (!private || !mask)
>> +		return 0;
>> +
>> +	VFIO_CCW_MSG_EVENT(2, "%pUl (%x.%x.%04x): mask=0x%x event=%d\n",
>> +			   mdev_uuid(private->mdev), sch->schid.cssid,
>> +			   sch->schid.ssid, sch->schid.sch_no,
>> +			   mask, event);
>> +
>> +	if (cio_update_schib(sch))
>> +		return -ENODEV;
>> +
>> +	switch (event) {
>> +	case CHP_VARY_OFF:
>> +		/* Path logically turned off */
>> +		sch->opm &= ~mask;
>> +		sch->lpm &= ~mask;
>> +		break;
>> +	case CHP_OFFLINE:
>> +		/* Path is gone */
>> +		cio_cancel_halt_clear(sch, &retry);
> 
> Any reason you do this only for CHP_OFFLINE and not for CHP_VARY_OFF?

Hrm...  No reason that I can think of.  I can fix this.

> 
>> +		break;
>> +	case CHP_VARY_ON:
>> +		/* Path logically turned on */
>> +		sch->opm |= mask;
>> +		sch->lpm |= mask;
>> +		break;
>> +	case CHP_ONLINE:
>> +		/* Path became available */
>> +		sch->lpm |= mask & sch->opm;
> 
> If I'm not mistaken, this patch introduces the first usage of sch->opm
> in the vfio-ccw code. 

Correct.

> Are we missing something?

Maybe?  :)

>Or am I missing
> something? :)
> 

Since it's only used in this code, for acting as a step between
vary/config off/on, maybe this only needs to be dealing with the lpm
field itself?

>> +		break;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>  static struct css_device_id vfio_ccw_sch_ids[] = {
>>  	{ .match_flags = 0x1, .type = SUBCHANNEL_TYPE_IO, },
>>  	{ /* end of list */ },
> (...)
>
Cornelia Huck March 24, 2020, 3:58 p.m. UTC | #3
On Fri, 14 Feb 2020 11:35:21 -0500
Eric Farman <farman@linux.ibm.com> wrote:

> On 2/14/20 7:11 AM, Cornelia Huck wrote:
> > On Thu,  6 Feb 2020 22:38:18 +0100
> > Eric Farman <farman@linux.ibm.com> wrote:

> > (...)  
> >> @@ -257,6 +258,48 @@ static int vfio_ccw_sch_event(struct subchannel *sch, int process)
> >>  	return rc;
> >>  }
> >>  
> >> +static int vfio_ccw_chp_event(struct subchannel *sch,
> >> +			      struct chp_link *link, int event)
> >> +{
> >> +	struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
> >> +	int mask = chp_ssd_get_mask(&sch->ssd_info, link);
> >> +	int retry = 255;
> >> +
> >> +	if (!private || !mask)
> >> +		return 0;
> >> +
> >> +	VFIO_CCW_MSG_EVENT(2, "%pUl (%x.%x.%04x): mask=0x%x event=%d\n",
> >> +			   mdev_uuid(private->mdev), sch->schid.cssid,
> >> +			   sch->schid.ssid, sch->schid.sch_no,
> >> +			   mask, event);
> >> +
> >> +	if (cio_update_schib(sch))
> >> +		return -ENODEV;
> >> +
> >> +	switch (event) {
> >> +	case CHP_VARY_OFF:
> >> +		/* Path logically turned off */
> >> +		sch->opm &= ~mask;
> >> +		sch->lpm &= ~mask;
> >> +		break;
> >> +	case CHP_OFFLINE:
> >> +		/* Path is gone */
> >> +		cio_cancel_halt_clear(sch, &retry);  
> > 
> > Any reason you do this only for CHP_OFFLINE and not for CHP_VARY_OFF?  
> 
> Hrm...  No reason that I can think of.  I can fix this.
> 
> >   
> >> +		break;
> >> +	case CHP_VARY_ON:
> >> +		/* Path logically turned on */
> >> +		sch->opm |= mask;
> >> +		sch->lpm |= mask;
> >> +		break;
> >> +	case CHP_ONLINE:
> >> +		/* Path became available */
> >> +		sch->lpm |= mask & sch->opm;  
> > 
> > If I'm not mistaken, this patch introduces the first usage of sch->opm
> > in the vfio-ccw code.   
> 
> Correct.
> 
> > Are we missing something?  
> 
> Maybe?  :)
> 
> >Or am I missing
> > something? :)
> >   
> 
> Since it's only used in this code, for acting as a step between
> vary/config off/on, maybe this only needs to be dealing with the lpm
> field itself?

Ok, I went over this again and also looked at what the standard I/O
subchannel driver does, and I think this is fine, as the lpm basically
factors in the opm already. (Will need to keep this in mind for the
following patches.)

> 
> >> +		break;
> >> +	}
> >> +
> >> +	return 0;
> >> +}
> >> +
> >>  static struct css_device_id vfio_ccw_sch_ids[] = {
> >>  	{ .match_flags = 0x1, .type = SUBCHANNEL_TYPE_IO, },
> >>  	{ /* end of list */ },  
> > (...)
> >   
>
Eric Farman March 26, 2020, 2:09 a.m. UTC | #4
On 3/24/20 11:58 AM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 11:35:21 -0500
> Eric Farman <farman@linux.ibm.com> wrote:
> 
>> On 2/14/20 7:11 AM, Cornelia Huck wrote:
>>> On Thu,  6 Feb 2020 22:38:18 +0100
>>> Eric Farman <farman@linux.ibm.com> wrote:
> 
>>> (...)  
>>>> @@ -257,6 +258,48 @@ static int vfio_ccw_sch_event(struct subchannel *sch, int process)
>>>>  	return rc;
>>>>  }
>>>>  
>>>> +static int vfio_ccw_chp_event(struct subchannel *sch,
>>>> +			      struct chp_link *link, int event)
>>>> +{
>>>> +	struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
>>>> +	int mask = chp_ssd_get_mask(&sch->ssd_info, link);
>>>> +	int retry = 255;
>>>> +
>>>> +	if (!private || !mask)
>>>> +		return 0;
>>>> +
>>>> +	VFIO_CCW_MSG_EVENT(2, "%pUl (%x.%x.%04x): mask=0x%x event=%d\n",
>>>> +			   mdev_uuid(private->mdev), sch->schid.cssid,
>>>> +			   sch->schid.ssid, sch->schid.sch_no,
>>>> +			   mask, event);
>>>> +
>>>> +	if (cio_update_schib(sch))
>>>> +		return -ENODEV;
>>>> +
>>>> +	switch (event) {
>>>> +	case CHP_VARY_OFF:
>>>> +		/* Path logically turned off */
>>>> +		sch->opm &= ~mask;
>>>> +		sch->lpm &= ~mask;
>>>> +		break;
>>>> +	case CHP_OFFLINE:
>>>> +		/* Path is gone */
>>>> +		cio_cancel_halt_clear(sch, &retry);  
>>>
>>> Any reason you do this only for CHP_OFFLINE and not for CHP_VARY_OFF?  
>>
>> Hrm...  No reason that I can think of.  I can fix this.
>>
>>>   
>>>> +		break;
>>>> +	case CHP_VARY_ON:
>>>> +		/* Path logically turned on */
>>>> +		sch->opm |= mask;
>>>> +		sch->lpm |= mask;
>>>> +		break;
>>>> +	case CHP_ONLINE:
>>>> +		/* Path became available */
>>>> +		sch->lpm |= mask & sch->opm;  
>>>
>>> If I'm not mistaken, this patch introduces the first usage of sch->opm
>>> in the vfio-ccw code.   
>>
>> Correct.
>>
>>> Are we missing something?  
>>
>> Maybe?  :)
>>
>>> Or am I missing
>>> something? :)
>>>   
>>
>> Since it's only used in this code, for acting as a step between
>> vary/config off/on, maybe this only needs to be dealing with the lpm
>> field itself?
> 
> Ok, I went over this again and also looked at what the standard I/O
> subchannel driver does, and I think this is fine, as the lpm basically
> factors in the opm already. (Will need to keep this in mind for the
> following patches.)

Just to make sure I don't misunderstand, when you say "I think this is
fine" ... Do you mean keeping the opm field within vfio-ccw, as this
patch does?  Or removing it, and only adjusting the lpm within vfio-ccw,
as I suggested in my response just above?

(It's long in the day, and should not look at vfio-ccw at this hour.)

> 
>>
>>>> +		break;
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>>  static struct css_device_id vfio_ccw_sch_ids[] = {
>>>>  	{ .match_flags = 0x1, .type = SUBCHANNEL_TYPE_IO, },
>>>>  	{ /* end of list */ },  
>>> (...)
>>>   
>>
>
Cornelia Huck March 26, 2020, 6:47 a.m. UTC | #5
On Wed, 25 Mar 2020 22:09:40 -0400
Eric Farman <farman@linux.ibm.com> wrote:

> On 3/24/20 11:58 AM, Cornelia Huck wrote:
> > On Fri, 14 Feb 2020 11:35:21 -0500
> > Eric Farman <farman@linux.ibm.com> wrote:
> >   
> >> On 2/14/20 7:11 AM, Cornelia Huck wrote:  
> >>> On Thu,  6 Feb 2020 22:38:18 +0100
> >>> Eric Farman <farman@linux.ibm.com> wrote:  

> >>>> +	case CHP_ONLINE:
> >>>> +		/* Path became available */
> >>>> +		sch->lpm |= mask & sch->opm;    
> >>>
> >>> If I'm not mistaken, this patch introduces the first usage of sch->opm
> >>> in the vfio-ccw code.     
> >>
> >> Correct.
> >>  
> >>> Are we missing something?    
> >>
> >> Maybe?  :)
> >>  
> >>> Or am I missing
> >>> something? :)
> >>>     
> >>
> >> Since it's only used in this code, for acting as a step between
> >> vary/config off/on, maybe this only needs to be dealing with the lpm
> >> field itself?  
> > 
> > Ok, I went over this again and also looked at what the standard I/O
> > subchannel driver does, and I think this is fine, as the lpm basically
> > factors in the opm already. (Will need to keep this in mind for the
> > following patches.)  
> 
> Just to make sure I don't misunderstand, when you say "I think this is
> fine" ... Do you mean keeping the opm field within vfio-ccw, as this
> patch does?  Or removing it, and only adjusting the lpm within vfio-ccw,
> as I suggested in my response just above?

I meant the code change done in this patch: We update the lpm whenever
the opm is changed, and use the lpm. I'd like to keep the opm separate,
just so that we are clear where each value comes from.
Eric Farman March 26, 2020, 11:54 a.m. UTC | #6
On 3/26/20 2:47 AM, Cornelia Huck wrote:
> On Wed, 25 Mar 2020 22:09:40 -0400
> Eric Farman <farman@linux.ibm.com> wrote:
> 
>> On 3/24/20 11:58 AM, Cornelia Huck wrote:
>>> On Fri, 14 Feb 2020 11:35:21 -0500
>>> Eric Farman <farman@linux.ibm.com> wrote:
>>>   
>>>> On 2/14/20 7:11 AM, Cornelia Huck wrote:  
>>>>> On Thu,  6 Feb 2020 22:38:18 +0100
>>>>> Eric Farman <farman@linux.ibm.com> wrote:  
> 
>>>>>> +	case CHP_ONLINE:
>>>>>> +		/* Path became available */
>>>>>> +		sch->lpm |= mask & sch->opm;    
>>>>>
>>>>> If I'm not mistaken, this patch introduces the first usage of sch->opm
>>>>> in the vfio-ccw code.     
>>>>
>>>> Correct.
>>>>  
>>>>> Are we missing something?    
>>>>
>>>> Maybe?  :)
>>>>  
>>>>> Or am I missing
>>>>> something? :)
>>>>>     
>>>>
>>>> Since it's only used in this code, for acting as a step between
>>>> vary/config off/on, maybe this only needs to be dealing with the lpm
>>>> field itself?  
>>>
>>> Ok, I went over this again and also looked at what the standard I/O
>>> subchannel driver does, and I think this is fine, as the lpm basically
>>> factors in the opm already. (Will need to keep this in mind for the
>>> following patches.)  
>>
>> Just to make sure I don't misunderstand, when you say "I think this is
>> fine" ... Do you mean keeping the opm field within vfio-ccw, as this
>> patch does?  Or removing it, and only adjusting the lpm within vfio-ccw,
>> as I suggested in my response just above?
> 
> I meant the code change done in this patch: We update the lpm whenever
> the opm is changed, and use the lpm. I'd like to keep the opm separate,
> just so that we are clear where each value comes from.
> 

Great.  Thanks for that clarification.
diff mbox series

Patch

diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 91989269faf1..a99705e2fd73 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -19,6 +19,7 @@ 
 
 #include <asm/isc.h>
 
+#include "chp.h"
 #include "ioasm.h"
 #include "css.h"
 #include "vfio_ccw_private.h"
@@ -257,6 +258,48 @@  static int vfio_ccw_sch_event(struct subchannel *sch, int process)
 	return rc;
 }
 
+static int vfio_ccw_chp_event(struct subchannel *sch,
+			      struct chp_link *link, int event)
+{
+	struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
+	int mask = chp_ssd_get_mask(&sch->ssd_info, link);
+	int retry = 255;
+
+	if (!private || !mask)
+		return 0;
+
+	VFIO_CCW_MSG_EVENT(2, "%pUl (%x.%x.%04x): mask=0x%x event=%d\n",
+			   mdev_uuid(private->mdev), sch->schid.cssid,
+			   sch->schid.ssid, sch->schid.sch_no,
+			   mask, event);
+
+	if (cio_update_schib(sch))
+		return -ENODEV;
+
+	switch (event) {
+	case CHP_VARY_OFF:
+		/* Path logically turned off */
+		sch->opm &= ~mask;
+		sch->lpm &= ~mask;
+		break;
+	case CHP_OFFLINE:
+		/* Path is gone */
+		cio_cancel_halt_clear(sch, &retry);
+		break;
+	case CHP_VARY_ON:
+		/* Path logically turned on */
+		sch->opm |= mask;
+		sch->lpm |= mask;
+		break;
+	case CHP_ONLINE:
+		/* Path became available */
+		sch->lpm |= mask & sch->opm;
+		break;
+	}
+
+	return 0;
+}
+
 static struct css_device_id vfio_ccw_sch_ids[] = {
 	{ .match_flags = 0x1, .type = SUBCHANNEL_TYPE_IO, },
 	{ /* end of list */ },
@@ -274,6 +317,7 @@  static struct css_driver vfio_ccw_sch_driver = {
 	.remove = vfio_ccw_sch_remove,
 	.shutdown = vfio_ccw_sch_shutdown,
 	.sch_event = vfio_ccw_sch_event,
+	.chp_event = vfio_ccw_chp_event,
 };
 
 static int __init vfio_ccw_debug_init(void)