All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Simon Martin <furryfuttock@gmail.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-users@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Atom2 <ariel.atom2@web2web.at>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Is: Xen pci backend state transition from Closed -> Initialized broken. Was:Re: 10s shutdown delay for PV guests with PCI passthrough
Date: Mon, 4 Aug 2014 09:53:36 -0400	[thread overview]
Message-ID: <20140804135336.GB17843@laptop.dumpdata.com> (raw)
In-Reply-To: <979055991.20140720210138@gmail.com>

On Sun, Jul 20, 2014 at 09:01:38PM +0100, Simon Martin wrote:
> Hello Konrad,
> 
> Friday, July 18, 2014, 7:45:06 PM, you wrote:
> 
> >>
> >> 3.- frontend set state XenbusStateInitialising and waits for frontend
> >> to go to a state in the interval [XenbusStateInitWait,
> >> XenbusStateClosed).
> >> 
> >> If I perform step 3 then the frontend never exits as the backend state
> >> stays at XenbusStateClosed
> 
> > It looks like there is no code for XenbusStateInitialising so it
> > just ignores it. There is a state for XenbusStateInitialised.
> 
> OK.  So  do  I set XenbusStateInitialised? If so, what's the handshake
> value from the backend?

Looking at the code (xen_pcibk_frontend_changed) it looks like it
will ignore it - as 'xen_pcibk_attach' does:

149         /* Make sure we only do this setup once */                              
150         if (xenbus_read_driver_state(pdev->xdev->nodename) !=                   
151             XenbusStateInitialised)            

so it will just exit (as the last state is XenbusStateClosed) and not
perform the steps. 

It looks like the steps it expects are that the backend state gets
moved by a toolstack to XenbusStateInitialised.  Comparing that
to the other backend drivers - like Xen Block backend - it looks
like it is missing a step. That is if fe is XenbusStateClosed
the be goes to XenbusStateClosed. If the fe goes to XenbusStateInitialising
the be should be OK continuing if it was in
XenbusStateClosed (reconnect) or in XenbusStateInitialised (first time).

Would this patch help (not compile tested)?

diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 4a7e6e0..c518b42 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -143,12 +143,20 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
 	int err = 0;
 	int gnt_ref, remote_evtchn;
 	char *magic = NULL;
-
+	int state;
 
 	mutex_lock(&pdev->dev_lock);
+	state = xenbus_read_driver_state(pdev->xdev->nodename);
+	/* Frontend reconnected after closing. */
+	if (state == XenbusStateClosed) {
+		err = xenbus_switch_state(pdev->xdev, XenbusStateInitialized);
+		if (err)
+			xenbus_dev_fatal(pdev->xdev, err, "Error switching to initialized state!");
+		/* Re-read */
+		state = xenbus_read_driver_state(pdev->xdev->nodename);
+	}
 	/* Make sure we only do this setup once */
-	if (xenbus_read_driver_state(pdev->xdev->nodename) !=
-	    XenbusStateInitialised)
+	if (state != XenbusStateInitialised)
 		goto out;
 
 	/* Wait for frontend to state that it has published the configuration */
> 
> >> 
> >> If I do not perform step 3 then PV shutsdown after a 10s timeout.
> 
> > How does it shutdown? What causes the shutdown?
> 
> PV will exit, however xl does not release the domain for another 10s.

That looks to be another issue. Maybe it is already fixed by some
of the patches I posted (search for " xen/pciback: Don't deadlock when unbinding.").

> 
> -- 
> Best regards,
>  Simon                            mailto:furryfuttock@gmail.com
> 

      reply	other threads:[~2014-08-04 13:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17 14:41 10s shutdown delay for PV guests with PCI passthrough Simon Martin
2014-07-18 18:45 ` Konrad Rzeszutek Wilk
2014-07-20 20:01   ` Simon Martin
2014-08-04 13:53     ` Konrad Rzeszutek Wilk [this message]

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=20140804135336.GB17843@laptop.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=ariel.atom2@web2web.at \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=furryfuttock@gmail.com \
    --cc=ian.campbell@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=xen-users@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 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.