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

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

  • To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, "Keir Fraser" <keir@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Graham, Simon" <Simon.Graham@xxxxxxxxxxx>
  • Date: Wed, 14 Feb 2007 10:31:55 -0500
  • Delivery-date: Wed, 14 Feb 2007 07:31:15 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdP6h4+HveIAzruQ3+gt7NQNapEGwANqzaeAADJUVAAAHIl2wAGcwGgAAF4ck4AAAWwQAAAtdeQAAEfZaA=
  • Thread-topic: [Xen-devel] DomU crash during migration whensuspendingsource domain

Thanks Mats,

> At present, there's not much filtering going on in that code, but it's
> capable of filtering any and all CPUID functionality used by a PV
> guest.
> HVM also has the same capability of filtering.
> Would it make sense to have a sparse array of CPUID leaves and masks
> for
> the respective entries, or did you have some better idea?

No good ideas yet - just trolling for suggestions ;-)

> The real problem with migrating to a "lesser" platform is things like:
> Linux starts by determining which method is the best for calculating
> checksums, copying disk-blocks, etc, etc. Let's say that the kernel
> decides to use SSE registers for this purpose. You then migrate this
> a processor that doesn't have SSE instructions... Fail Fail Fail.
> Other features of the same sort would be large pages (not supported by
> Xen at present), PAE support, etc, etc.

Yikes - hadn't thought of these ones but now you point it out it's

Clearly we're going to have to implement some careful compatibility
checking AND potentially use the feature hiding approach to make all
systems appear to have equivalent processors.


Xen-devel mailing list



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