public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v7 09/22] s390: vfio-ap: register matrix device with VFIO mdev framework
Date: Mon, 30 Jul 2018 14:18:21 +0000	[thread overview]
Message-ID: <f4d4e55c-5594-bc61-040c-bbe584df6e01@linux.ibm.com> (raw)
In-Reply-To: <6a31797f-c8be-bb3d-c515-029ec52a56bf@linux.ibm.com>



On 07/30/2018 01:28 PM, Cornelia Huck wrote:
> On Mon, 30 Jul 2018 13:24:24 +0200
> Pierre Morel <pmorel@linux.ibm.com> wrote:
> 
>> On 30/07/2018 11:49, Cornelia Huck wrote:
>>> On Fri, 27 Jul 2018 16:17:47 +0200
>>> Halil Pasic <pasic@linux.ibm.com> wrote:
>>>   
>>>> On 07/26/2018 09:54 PM, Christian Borntraeger wrote:
>>>>> @@ -65,6 +66,21 @@ static int vfio_ap_matrix_dev_create(void)
>>>>>     {
>>>>>     	int ret;
>>>>>     
>>>>> +	mutex_init(&matrix_dev.lock);
>>>>> +	INIT_LIST_HEAD(&matrix_dev.mdev_list);
>>>>> +
>>>>> +	/* Test if PQAP(QCI) instruction is available */
>>>>> +	if (test_facility(12)) {
>>>>> +		ret = ap_qci(&matrix_dev.info);
>>>>> +		if (ret && (ret != -EOPNOTSUPP)) {
>>>> After Connie's curiosity was piqued I gave this another look. If
>>>> I read the ap_qci() documentation and code correctly, it can return
>>>> either 0 or -EOPNOTSUPP, but nothing else. So basically this
>>>> is a dead branch.
>>> Can it return -EOPNOTSUPP if facility 12 is present?
>>
>> I do not think it is reasonable to continue if
>> we stated that facility 12 is present but the ap_qci function failed.
>>
>> So I propose that we return an error and break the insmod.
> 
> So, would that be a bug? If yes, returning an error makes sense.
> 
> (I can't check the documentation to find out about the interaction
> between facility 12 and PQAP(QCI)...)

If we are in z architectural mode and  facility 12 is indicated and
ap_qci() returns an error code, it's because of an exception while
executing the PQAP instruction. The reason can be a bad input pointer
or other stuff. It is likely a bug. I'm not sure how this interacts
with machine checks though. I think we should report the problem
and give up.  

> --
> To unsubscribe from this list: send the line "unsubscribe linux-s390" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

       reply	other threads:[~2018-07-30 14:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6a31797f-c8be-bb3d-c515-029ec52a56bf@linux.ibm.com>
2018-07-30 14:18 ` Halil Pasic [this message]
     [not found] <46d292dd-7578-1ba6-4561-d42a6441debf@linux.ibm.com>
2018-08-02 11:18 ` [PATCH v7 09/22] s390: vfio-ap: register matrix device with VFIO mdev framework Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f4d4e55c-5594-bc61-040c-bbe584df6e01@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox