xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Atom2 <ariel.atom2@web2web.at>,
	xen-users@lists.xenproject.org
Subject: Re: [Xen-users] substantial shutdown delay for PV guests with PCI -passthrough
Date: Wed, 19 Mar 2014 09:00:02 -0400	[thread overview]
Message-ID: <20140319130002.GC8694@phenom.dumpdata.com> (raw)
In-Reply-To: <1395228384.10203.65.camel@kazak.uk.xensource.com>

On Wed, Mar 19, 2014 at 11:26:24AM +0000, Ian Campbell wrote:
> On Wed, 2014-03-19 at 01:25 +0100, Atom2 wrote:
> > So it seems that pretty much at the start of the 10s delay the state 
> > changed from 4 to 6 and stays at that value even after the first 10s 
> > delay is over - whatever that means.
> 
> 4 == Connected
> 6 == Closed
> 
> I think what is happening is that the domain is shutting down, which
> causes pciback to transition to the closed state (because the f.e. went
> away, so this is a reasonable thing for it to do).
> 
> The bug appears to be that libxl is trying to "hot unplug" the devices
> on shutdown when they have already been effectively "cold unplugged" by
> the domain going down.
> 
> Perhaps libxl__device_pci_remove_xenstore should observe that the state
> is > 4 (hence closing/closed) and not bother doing anything, i.e. only
> waiting iff the state is <4 (init, connecting etc)? Or unconditionally
> removing the nodes if state > 4. (perhaps state 7, reconfiguring needs
> handling here too)
> 
> Or perhaps the force parameter passed to remove_common (which indicates
> destroy rather than unplug) ought to be propagated down to this code and
> $something done with it.
> 
> Roger, Ian, any thoughts on that?

This reminds me of this bug:

commit 098b1aeaf4d6149953b8f1f8d55c21d85536fbff
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Jun 10 16:48:09 2013 -0400

    xen/pcifront: Deal with toolstack missing 'XenbusStateClosing' state.

... snip..
    
    In other words, this 4(Connected)->5(Closing)->4(Connected) state
    was expected, while 4(Connected)->.... anything but 5(Closing)->4(Connected)
    was not. This patch removes that aggressive check and allows
    Xen pcifront to work with the 'xl' toolstack (for one or more
    PCI devices) and with 'xm' toolstack (for more than two PCI
    devices).
    
But this seems to be a different state issue?

Ariel/Atom2, do you see this behavior with 'xend'? And what is the version of Linux
kernel you are running as guest?
> 
> Ian.
> 

  reply	other threads:[~2014-03-19 13:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5325B828.1060303@web2web.at>
     [not found] ` <1395050430.4122.29.camel@kazak.uk.xensource.com>
     [not found]   ` <53273B3C.40707@web2web.at>
2014-03-18 10:15     ` [Xen-users] substantial shutdown delay for PV guests with PCI -passthrough Ian Campbell
2014-03-18 13:01       ` Atom2
2014-03-18 15:07         ` Ian Campbell
2014-03-19  0:25           ` Atom2
2014-03-19 11:26             ` Ian Campbell
2014-03-19 13:00               ` Konrad Rzeszutek Wilk [this message]
2014-03-19 14:03                 ` Atom2
2014-03-19 15:45                   ` Ian Jackson
2014-03-20  2:31                     ` Atom2
2014-03-20 11:52                       ` Ian Jackson
2014-03-20 13:53                         ` Pasi Kärkkäinen
2014-03-20 15:28                           ` Ian Jackson
2014-03-20 19:34                           ` Atom2
2014-03-20 19:32                         ` Atom2
2014-03-21 18:11                           ` Ian Jackson
2014-03-21 19:39                             ` Atom2
2014-04-02 14:44                               ` Ian Jackson
2014-04-02 15:17                                 ` Atom2
2014-04-18 21:47                                   ` Atom2
2014-04-19  0:12                                     ` Konrad Rzeszutek Wilk
2014-04-19 18:59                                       ` Atom2
2014-04-22 10:44                                         ` George Dunlap
2014-04-22 12:02                                           ` Atom2

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=20140319130002.GC8694@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=ariel.atom2@web2web.at \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).