xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Julien Grall <julien.grall@linaro.org>
Cc: jgross@suse.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Tim Deegan <tim@xen.org>,
	george.dunlap@citrix.com, xen-devel <xen-devel@lists.xen.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>
Subject: Re: Xen crashing when killing a domain with no VCPUs allocated
Date: Mon, 21 Jul 2014 11:12:59 +0100	[thread overview]
Message-ID: <53CCE7AB.5060901@eu.citrix.com> (raw)
In-Reply-To: <1405701560.14973.1.camel@kazak.uk.xensource.com>

On 07/18/2014 05:39 PM, Ian Campbell wrote:
> On Fri, 2014-07-18 at 14:27 +0100, Julien Grall wrote:
>> Hi all,
>>
>> I've been played with the function alloc_vcpu on ARM. And I hit one case
>> where this function can failed.
>>
>> During domain creation, the toolstack will call DOMCTL_max_vcpus which may
>> fail, for instance because alloc_vcpu didn't succeed. In this case, the
>> toolstack will call DOMCTL_domaindestroy. And I got the below stack trace.
>>
>> It can be reproduced on Xen 4.5 (and I also suspect Xen 4.4) by returning
>> in an error in vcpu_initialize.
>>
>> I'm not sure how to correctly fix it.
> I think a simple check at the head of the function would be ok.
>
> Alternatively perhaps in sched_mode_domain, which could either detect
> this or could detect a domain in pool0 being moved to pool0 and short
> circuit.
>
> [...]
>> (XEN)    [<00226870>] sched_move_domain+0x3cc/0x42c
>> (XEN)    [<0020925c>] domain_kill+0xc8/0x178
> This call path surprised me but it is from:
>
> commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a
> Author: Juergen Gross <juergen.gross@ts.fujitsu.com>
> Date:   Tue May 20 15:55:42 2014 +0200
>
>      move domain to cpupool0 before destroying it

And this is the second unforseen hypervisor crash that happened as a 
side effect of this patch.  Obviously I need to be more of a bastard as 
a mainainer.

  -George

      parent reply	other threads:[~2014-07-21 10:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-18 13:27 Xen crashing when killing a domain with no VCPUs allocated Julien Grall
2014-07-18 16:39 ` Ian Campbell
2014-07-18 20:26   ` Julien Grall
2014-07-21 10:33     ` George Dunlap
2014-07-21 10:42       ` Andrew Cooper
2014-07-21 10:49         ` George Dunlap
2014-07-21 11:46       ` Julien Grall
2014-07-21 12:57         ` Dario Faggioli
2014-07-23 15:31           ` Jan Beulich
2014-07-24 14:04             ` Julien Grall
2014-07-21 10:12   ` George Dunlap [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=53CCE7AB.5060901@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julien.grall@linaro.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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).