Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

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@xxxxxxxxxx>
>>
>> LGTM, only a couple of typos and a simplification:
>>
>> Signed-off-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx>
> 
> 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?

Should s->status be able to store all the possible return codes from the
response (OK/ERROR/NOTSUPP)?

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel