Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1268187

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

From Julien Grall <julien.grall@citrix.com>
Newsgroups linux.kernel
Subject Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages
Date 2015-11-12 19:40 +0100
Message-ID <qu4WS-42L-25@gated-at.bofh.it> (permalink)
References (2 earlier) <qu3eq-2V6-17@gated-at.bofh.it> <qu40O-3rz-21@gated-at.bofh.it> <qu4kb-3yL-25@gated-at.bofh.it> <qu4tQ-3RE-23@gated-at.bofh.it> <qu4Nd-3Zg-49@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 12/11/15 18:24, Roger Pau Monné wrote:
>> 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.

hmmm ... We would return an error to the block layer rather than 0
because the operation is not supported.

That reminds me that blkif_recover needs to be fixed to support
splitting request. I haven't done it because ARM doesn't yet support
suspend/resume (CCing Ian who is working on it).

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

I will give a look.

-- 
Julien Grall
--
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/

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect grant with  64KB pages Roger Pau Monné <roger.pau@citrix.com> - 2015-11-12 17:50 +0100
  Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect  grant with 64KB pages Julien Grall <julien.grall@citrix.com> - 2015-11-12 18:40 +0100
    Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle  non-indirect grant with 64KB pages Roger Pau Monné <roger.pau@citrix.com> - 2015-11-12 19:00 +0100
      Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect  grant with 64KB pages Julien Grall <julien.grall@citrix.com> - 2015-11-12 19:10 +0100
        Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle  non-indirect grant with 64KB pages Roger Pau Monné <roger.pau@citrix.com> - 2015-11-12 19:30 +0100
          Re: [Xen-devel] [PATCH v2 2/2] block/xen-blkfront: Handle non-indirect  grant with 64KB pages Julien Grall <julien.grall@citrix.com> - 2015-11-12 19:40 +0100

csiph-web