WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Graham, Simon" <Simon.Graham@xxxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] DomU crash during migration when suspendingsource domain
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 14 Feb 2007 14:56:41 +0000
Delivery-date: Wed, 14 Feb 2007 06:56:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <342BAC0A5467384983B586A6B0B3767104A6A851@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdP6h4+HveIAzruQ3+gt7NQNapEGwANqzaeAADJUVAAAHIl2wAGcwGgAAF4ck4AAAWwQAAAthKt
Thread-topic: [Xen-devel] DomU crash during migration when suspendingsource domain
User-agent: Microsoft-Entourage/11.2.5.060620
On 14/2/07 14:43, "Graham, Simon" <Simon.Graham@xxxxxxxxxxx> wrote:

> Do you plan to do this for PV domains as well as HVM?

Yes, we have a special paravirtualised CPUID interface which Linux uses. So
this can be done.
 
> I guess I'm not quite sure I fully understand -- since we hot remove all
> the processors (but one - I guess that is an issue) and then hot add
> them again after migration, you would think it would be OK to hot add a
> completely different processor -- of course there will be issues with
> the Linux code given that you cant actually test this on a
> non-virtualized system.

You might indeed think that. Unfortunately code can depend on the fact that
all x86 systems (at least so far) have symmetric cache hierarchies. In the
case of this particular code, num_cache_leaves is latched during boot based
on CPU0's CPUID result. This value is then considered safe to use for all
CPUs forever more, which is not a good assumption in your case.

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.

> You misunderstand my point -- in an FT environment, you MUST be able to
> upgrade and repair hardware without taking the domain down -- clearly
> this would normally be to an equivalent or higher functionality system
> but we cant guarantee that there wont be a new spiffy processor that
> causes this same issue to arise or that we wont run into some similar
> issue when replacing faulty hardware (the original system might no
> longer be available for example).

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!

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel