[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] DomU crash during migration when suspendingsource domain

  • To: "Graham, Simon" <Simon.Graham@xxxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Wed, 14 Feb 2007 15:43:02 +0000
  • Delivery-date: Wed, 14 Feb 2007 07:42:29 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdP6h4+HveIAzruQ3+gt7NQNapEGwANqzaeAADJUVAAAHIl2wAGcwGgAAF4ck4AAAWwQAAAthKtAAA5WAAAAWUOjQ==
  • Thread-topic: [Xen-devel] DomU crash during migration when suspendingsource domain

On 14/2/07 15:08, "Graham, Simon" <Simon.Graham@xxxxxxxxxxx> wrote:

> Let me try that out here and get back to you -- I can submit a patch
> with this specific fix in if it solves the problem.
> Since, as you say, this is just one aspect of dealing with hot plugging
> completely different processors, I somehow feel that a point fix like
> this wouldn't be accepted upstream and instead we'd need to think about
> a more complete solution (If, indeed, this is feasible).

Possibly true. In fact I think if you fix that function then you're going to
die in kobject_unregister() instead. The loop cache_remove_dev() is simply
bogus in your case since num_cache_leaves cannot be trusted.

A broader set of fixes might get accepted upstream because cache_add_dev()
can fail for other reasons too (at least out-of-memory) and any such failure
will cause cache_remove_dev() to barf. But it's not such a simple thing to
fix and it does not solve the general problem for us.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.