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

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

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

> In this particular case it is quite arguable that
> cache_remove_shared_cpu_map() should check cpuid4_info[i]!=NULL, just
> as
> done in cache_shared_cpu_map_setup(). I can make this fix in our tree
> but
> something similar ought to be submitted upstream too. I'm pretty
> certain
> that this will fix your crash.

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).

> Upgrading upwards actually tends to be okay. I can't think of any
> practical
> examples of how that might fail. After all, worst case we can hide the
> extra
> features from the guest since we have some control over CPUID.
> *Downgrading*
> is the problem!

Understood... I can conceive of cases where this would not be true, but
I agree that Intel/AMD usually do a good job of ensuring backward
compatibility so we could hide the newer features until all systems have
the newer processors in place and you reboot the domains.


Xen-devel mailing list



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