From: "Roger Pau Monné" <roger.pau@citrix.com> To: "Durrant, Paul" <pdurrant@amazon.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, "Juergen Gross" <jgross@suse.com>, Stefano Stabellini <sstabellini@kernel.org>, "Boris Ostrovsky" <boris.ostrovsky@oracle.com> Subject: Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to closed Date: Mon, 9 Dec 2019 13:25:37 +0100 [thread overview] Message-ID: <20191209122537.GV980@Air-de-Roger> (raw) In-Reply-To: <19b5c2fa36b842e58bbdddd602c4e672@EX13D32EUC003.ant.amazon.com> On Mon, Dec 09, 2019 at 12:01:38PM +0000, Durrant, Paul wrote: > > -----Original Message----- > > From: Roger Pau Monné <roger.pau@citrix.com> > > Sent: 09 December 2019 11:39 > > To: Durrant, Paul <pdurrant@amazon.com> > > Cc: linux-kernel@vger.kernel.org; xen-devel@lists.xenproject.org; Juergen > > Gross <jgross@suse.com>; Stefano Stabellini <sstabellini@kernel.org>; > > Boris Ostrovsky <boris.ostrovsky@oracle.com> > > Subject: Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to > > closed > > > > On Thu, Dec 05, 2019 at 02:01:21PM +0000, Paul Durrant wrote: > > > Only force state to closed in the case when the toolstack may need to > > > clean up. This can be detected by checking whether the state in xenstore > > > has been set to closing prior to device removal. > > > > I'm not sure I see the point of this, I would expect that a failure to > > probe or the removal of the device would leave the xenbus state as > > closed, which is consistent with the actual driver state. > > > > Can you explain what's the benefit of leaving a device without a > > driver in such unknown state? > > > > If probe fails then I think it should leave the state alone. If the > state is moved to closed then basically you just killed that > connection to the guest (as the frontend will normally close down > when it sees this change) so, if the probe failure was due to a bug > in blkback or, e.g., a transient resource issue then it's game over > as far as that guest goes. But the connection can be restarted by switching the backend to the init state again. > The ultimate goal here is PV backend re-load that is completely transparent to the guest. Modifying anything in xenstore compromises that so we need to be careful. That's a fine goal, but not switching to closed state in xenbus_dev_remove seems wrong, as you have actually left the frontend without a matching backend and with the state not set to closed. Ie: that would be fine if you explicitly state this is some kind of internal blkback reload, but not for the general case where blkback has been unbound. I think we need someway to difference a blkback reload vs a unbound. Thanks, Roger.
WARNING: multiple messages have this Message-ID (diff)
From: "Roger Pau Monné" <roger.pau@citrix.com> To: "Durrant, Paul" <pdurrant@amazon.com> Cc: Juergen Gross <jgross@suse.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stefano Stabellini <sstabellini@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to closed Date: Mon, 9 Dec 2019 13:25:37 +0100 [thread overview] Message-ID: <20191209122537.GV980@Air-de-Roger> (raw) In-Reply-To: <19b5c2fa36b842e58bbdddd602c4e672@EX13D32EUC003.ant.amazon.com> On Mon, Dec 09, 2019 at 12:01:38PM +0000, Durrant, Paul wrote: > > -----Original Message----- > > From: Roger Pau Monné <roger.pau@citrix.com> > > Sent: 09 December 2019 11:39 > > To: Durrant, Paul <pdurrant@amazon.com> > > Cc: linux-kernel@vger.kernel.org; xen-devel@lists.xenproject.org; Juergen > > Gross <jgross@suse.com>; Stefano Stabellini <sstabellini@kernel.org>; > > Boris Ostrovsky <boris.ostrovsky@oracle.com> > > Subject: Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to > > closed > > > > On Thu, Dec 05, 2019 at 02:01:21PM +0000, Paul Durrant wrote: > > > Only force state to closed in the case when the toolstack may need to > > > clean up. This can be detected by checking whether the state in xenstore > > > has been set to closing prior to device removal. > > > > I'm not sure I see the point of this, I would expect that a failure to > > probe or the removal of the device would leave the xenbus state as > > closed, which is consistent with the actual driver state. > > > > Can you explain what's the benefit of leaving a device without a > > driver in such unknown state? > > > > If probe fails then I think it should leave the state alone. If the > state is moved to closed then basically you just killed that > connection to the guest (as the frontend will normally close down > when it sees this change) so, if the probe failure was due to a bug > in blkback or, e.g., a transient resource issue then it's game over > as far as that guest goes. But the connection can be restarted by switching the backend to the init state again. > The ultimate goal here is PV backend re-load that is completely transparent to the guest. Modifying anything in xenstore compromises that so we need to be careful. That's a fine goal, but not switching to closed state in xenbus_dev_remove seems wrong, as you have actually left the frontend without a matching backend and with the state not set to closed. Ie: that would be fine if you explicitly state this is some kind of internal blkback reload, but not for the general case where blkback has been unbound. I think we need someway to difference a blkback reload vs a unbound. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-12-09 12:25 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-05 14:01 [PATCH 0/4] xen-blkback: support live update Paul Durrant 2019-12-05 14:01 ` [Xen-devel] " Paul Durrant 2019-12-05 14:01 ` [PATCH 1/4] xenbus: move xenbus_dev_shutdown() into frontend code Paul Durrant 2019-12-05 14:01 ` [Xen-devel] " Paul Durrant 2019-12-09 11:33 ` Jürgen Groß 2019-12-09 11:33 ` [Xen-devel] " Jürgen Groß 2019-12-09 11:55 ` Durrant, Paul 2019-12-09 11:55 ` [Xen-devel] " Durrant, Paul 2019-12-09 11:57 ` Jürgen Groß 2019-12-09 11:57 ` [Xen-devel] " Jürgen Groß 2019-12-05 14:01 ` [PATCH 2/4] xenbus: limit when state is forced to closed Paul Durrant 2019-12-05 14:01 ` [Xen-devel] " Paul Durrant 2019-12-09 11:39 ` Roger Pau Monné 2019-12-09 11:39 ` Roger Pau Monné 2019-12-09 11:55 ` Jürgen Groß 2019-12-09 11:55 ` Jürgen Groß 2019-12-09 12:03 ` Durrant, Paul 2019-12-09 12:03 ` Durrant, Paul 2019-12-09 12:08 ` Jürgen Groß 2019-12-09 12:08 ` Jürgen Groß 2019-12-09 12:19 ` Durrant, Paul 2019-12-09 12:19 ` Durrant, Paul 2019-12-09 13:38 ` Jürgen Groß 2019-12-09 13:38 ` Jürgen Groß 2019-12-09 14:06 ` Durrant, Paul 2019-12-09 14:06 ` Durrant, Paul 2019-12-09 14:09 ` Jürgen Groß 2019-12-09 14:09 ` Jürgen Groß 2019-12-09 14:23 ` Durrant, Paul 2019-12-09 14:23 ` Durrant, Paul 2019-12-09 14:41 ` Jürgen Groß 2019-12-09 14:41 ` Jürgen Groß 2019-12-09 14:43 ` Durrant, Paul 2019-12-09 14:43 ` Durrant, Paul 2019-12-09 12:01 ` Durrant, Paul 2019-12-09 12:01 ` Durrant, Paul 2019-12-09 12:25 ` Roger Pau Monné [this message] 2019-12-09 12:25 ` Roger Pau Monné 2019-12-09 12:40 ` Durrant, Paul 2019-12-09 12:40 ` Durrant, Paul 2019-12-09 14:28 ` Roger Pau Monné 2019-12-09 14:28 ` Roger Pau Monné 2019-12-09 14:41 ` Durrant, Paul 2019-12-09 14:41 ` Durrant, Paul 2019-12-09 15:13 ` Roger Pau Monné 2019-12-09 15:13 ` Roger Pau Monné 2019-12-09 16:26 ` Durrant, Paul 2019-12-09 16:26 ` Durrant, Paul 2019-12-09 17:17 ` Roger Pau Monné 2019-12-09 17:17 ` Roger Pau Monné 2019-12-09 17:23 ` Durrant, Paul 2019-12-09 17:23 ` Durrant, Paul 2019-12-05 14:01 ` [PATCH 3/4] xen/interface: don't discard pending work in FRONT/BACK_RING_ATTACH Paul Durrant 2019-12-05 14:01 ` [Xen-devel] " Paul Durrant 2019-12-09 11:41 ` Roger Pau Monné 2019-12-09 11:41 ` Roger Pau Monné 2019-12-09 11:52 ` Jürgen Groß 2019-12-09 11:52 ` Jürgen Groß 2019-12-09 12:50 ` Durrant, Paul 2019-12-09 12:50 ` Durrant, Paul 2019-12-09 13:55 ` Jürgen Groß 2019-12-09 13:55 ` [Xen-devel] " Jürgen Groß 2019-12-09 16:38 ` Durrant, Paul 2019-12-09 16:38 ` [Xen-devel] " Durrant, Paul 2019-12-10 11:42 ` Jürgen Groß 2019-12-10 11:42 ` [Xen-devel] " Jürgen Groß 2019-12-05 14:01 ` [PATCH 4/4] xen-blkback: support dynamic unbind/bind Paul Durrant 2019-12-05 14:01 ` [Xen-devel] " Paul Durrant 2019-12-09 12:17 ` Roger Pau Monné 2019-12-09 12:17 ` [Xen-devel] " Roger Pau Monné 2019-12-09 12:24 ` Durrant, Paul 2019-12-09 12:24 ` [Xen-devel] " Durrant, Paul 2019-12-09 13:57 ` Jürgen Groß 2019-12-09 13:57 ` [Xen-devel] " Jürgen Groß 2019-12-09 14:01 ` Durrant, Paul 2019-12-09 14:01 ` [Xen-devel] " Durrant, Paul
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=20191209122537.GV980@Air-de-Roger \ --to=roger.pau@citrix.com \ --cc=boris.ostrovsky@oracle.com \ --cc=jgross@suse.com \ --cc=linux-kernel@vger.kernel.org \ --cc=pdurrant@amazon.com \ --cc=sstabellini@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.