Subject: Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle
 non-indirect grant with 64KB pages
To: Julien Grall <julien.grall@citrix.com>, <xen-devel@lists.xenproject.org>,
        <linux-kernel@vger.kernel.org>
References: <1445264354-23648-1-git-send-email-julien.grall@citrix.com>
 <1445264354-23648-3-git-send-email-julien.grall@citrix.com>
 <5644C111.2020006@citrix.com> <5644CCA8.4090003@citrix.com>
 <5644D19B.4000900@citrix.com> <5644D494.3030700@citrix.com>
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        David Vrabel <david.vrabel@citrix.com>
From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com>
Message-ID: <5644D973.9000809@citrix.com>
Date: Thu, 12 Nov 2015 19:24:51 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5644D494.3030700@citrix.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3148
Lines: 84

El 12/11/15 a les 19.04, Julien Grall ha escrit:
> On 12/11/15 17:51, Roger Pau Monné wrote:
>> El 12/11/15 a les 18.30, Julien Grall ha escrit:
>>> Hi,
>>>
>>> On 12/11/15 16:40, Roger Pau Monné wrote:
>>>>> [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg02200.html
>>>>>
>>>>> Signed-off-by: Julien Grall <julien.grall@citrix.com>
>>>>
>>>> LGTM, only a couple of typos and a simplification:
>>>>
>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>
>>> Do you mean Acked-by? ;)
>>
>> Yes, I also had problems with smtp, so I thought this one was actually
>> not sent. You have another one with a proper Ack :).
>>
>>>>> +
>>>>> +	/* The I/O request may be split in two */
>>>>> +	if (unlikely(s->associated_id != NO_ASSOCIATED_ID)) {
>>>>> +		struct blk_shadow *s2 = &info->shadow[s->associated_id];
>>>>> +
>>>>> +		/* Keep the status of the current response in shadow */
>>>>> +		s->status = (bret->status == BLKIF_RSP_OKAY) ?
>>>>> +			REQ_DONE : REQ_FAIL;
>>>>> +
>>>>> +		/* Wait the second response if not yet here */
>>>>> +		if (s2->status == REQ_WAITING)
>>>>> +			return 0;
>>>>> +
>>>>> +		/*
>>>>> +		 * The status of the current response will be used in
>>>>> +		 * order to know if the request has failed.
>>>>> +		 * Update the current response status only if has not
>>>>> +		 * failed.
>>>>> +		 */
>>>>> +		if (bret->status == BLKIF_RSP_OKAY && s2->status == REQ_FAIL)
>>>>
>>>> This could be simplified by only checking if s2->status == REQ_FAIL.
>>>
>>> I didn't do it because bret->status may be different than
>>> BLKIF_RSP_ERROR (for instance BLKIF_RSP_EOPNOTSUPP).
>>
>> I think this is not actually possible in practice, but what if
>> bret->status == BLKIF_RSP_OKAY and the bret from s2 actually had
>> BLKIF_RSP_EOPNOTSUPP, wouldn't we loose the EOPNOTSUPP by
>> unconditionally setting BLKIF_RSP_ERROR?
> 
> No because EOPNOTSUPP are used when an operation is not supported. As
> the 2 ring request is coming from the same I/O request, it will always
> have the same operation.
> 
> So if one get EOPNOTSUPP the other will get too.

That's why I said that I think it's not currently possible. IMHO, it's
fine as it is now.

The only scenario I can think of that can lead to that combination is
that we migrate the guest and one request gets processed by one backend
that supports the operation, while the other request get processed by a
backend that doesn't support it.

With your current implementation we would return an error code anyway,
which is not that bad I guess.

>>
>> Should s->status be able to store all the possible return codes from the
>> response (OK/ERROR/NOTSUPP)?
> 
> That could would work. However, how do you decide which will be the
> final status?

It should be the most restrictive one, for example if we have ERROR and
NOTSUPP we should return ERROR, while if we have OK and NOTSUPP we
should return NOTSUPP.

Roger.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/