From: SeongJae Park <sj@kernel.org>
To: Andrii Chepurnyi <andrii.chepurnyi82@gmail.com>
Cc: Oleksandr <olekstysh@gmail.com>, SeongJae Park <sj@kernel.org>,
roger.pau@citrix.com, jgross@suse.com, axboe@kernel.dk,
boris.ostrovsky@oracle.com, mheyne@amazon.de,
xen-devel@lists.xenproject.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] xen-blkback: fix persistent grants negotiation
Date: Fri, 15 Jul 2022 15:46:43 +0000 [thread overview]
Message-ID: <20220715154643.54334-1-sj@kernel.org> (raw)
In-Reply-To: <CAJwUmVB6H3iTs-C+U=v-pwJB7-_ZRHPxHzKRJZ22xEPW7z8a=g@mail.gmail.com>
Hello,
Oleksandr, thank you for Cc-ing Andrii. Andrii, thank you for the comment!
On Fri, 15 Jul 2022 15:00:10 +0300 Andrii Chepurnyi <andrii.chepurnyi82@gmail.com> wrote:
> [-- Attachment #1: Type: text/plain, Size: 5237 bytes --]
>
> Hello All,
>
> I faced the mentioned issue recently and just to bring more context here is
> our setup:
> We use pvblock backend for Android guest. It starts using u-boot with
> pvblock support(which frontend doesn't support the persistent grants
> feature), later it loads and starts the Linux kernel(which frontend
> supports the persistent grants feature). So in total, we have sequent two
> different frontends reconnection, the first of which doesn't support
> persistent grants.
> So the original patch [1] perfectly solves the original issue and provides
> the ability to use persistent grants after the reconnection when Linux
> frontend which supports persistent grants comes into play.
> At the same time [2] will disable the persistent grants feature for the
> first and second frontend.
Thank you for this great explanation of your situation.
> Is it possible to keep [1] as is?
Yes, my concerns about Max's original patch[1] are conflicting behavior
description in the document[1] and different behavior on blkfront-side
'feature_persistent' parameter. I will post Max's patch again with patches for
blkfront behavior change and Documents updates.
[1] https://lore.kernel.org/xen-devel/20220121102309.27802-1-sj@kernel.org/
Thanks,
SJ
>
> [1]
> https://lore.kernel.org/xen-devel/20220106091013.126076-1-mheyne@amazon.de/
> [2] https://lore.kernel.org/xen-devel/20220714224410.51147-1-sj@kernel.org/
>
> Best regards,
> Andrii
>
> On Fri, Jul 15, 2022 at 1:15 PM Oleksandr <olekstysh@gmail.com> wrote:
>
> >
> > On 15.07.22 01:44, SeongJae Park wrote:
> >
> >
> > Hello all.
> >
> > Adding Andrii Chepurnyi to CC who have played with the use-case which
> > required reconnect recently and faced some issues with
> > feature_persistent handling.
[...]
next parent reply other threads:[~2022-07-15 15:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAJwUmVB6H3iTs-C+U=v-pwJB7-_ZRHPxHzKRJZ22xEPW7z8a=g@mail.gmail.com>
2022-07-15 15:46 ` SeongJae Park [this message]
2022-07-14 22:44 [PATCH v2] xen-blkback: fix persistent grants negotiation SeongJae Park
2022-07-15 10:15 ` Oleksandr
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=20220715154643.54334-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=andrii.chepurnyi82@gmail.com \
--cc=axboe@kernel.dk \
--cc=boris.ostrovsky@oracle.com \
--cc=jgross@suse.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mheyne@amazon.de \
--cc=olekstysh@gmail.com \
--cc=roger.pau@citrix.com \
--cc=stable@vger.kernel.org \
--cc=xen-devel@lists.xenproject.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