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/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] switch to a known good/static GDT before kex

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] switch to a known good/static GDT before kexec
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 02 Jul 2009 11:52:43 +0100
Cc: Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Thu, 02 Jul 2009 03:53:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C67239FA.8815%keir.fraser@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acn68WnUxTkVYj07SMCr10xI1j0rhwABKjolAANJxEw=
Thread-topic: [Xen-devel] Re: [PATCH] switch to a known good/static GDT before kexec
User-agent: Microsoft-Entourage/
On 02/07/2009 10:18, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

>> switch to a known good/static GDT before kexec
>> kexec has been failing (at least on 32on64, didn't try others) since
>> 18771:8e18dd41c6c7 "x86: reduce GDT switching". Ensure that we are
>> using a known good GDT before attempting to switch to compatability mode.
> I thought 18771 still left us always running on a good GDT, as least as far
> as Xen's own limited needs are concerned. I'd like this in for 3.4.1 of
> course, but I'd also like to understand why the fix is required (and whether
> this is the best fix).


Thinking about this raises another question. Since your patch to allow
arbitrary numbers of VCPUs per domain, does the GDT logic in
__context_switch() work any more? What if you have a next vcpu n for which
!need_full_gdt(n) but where its domain does not have a vcpu_id as large as
p->vcpu_id? Won't you end up with a GDTR pointing at a non-existent mapping
('off the end' of n->domain's per-domain mappings)?

 -- Keir

Xen-devel mailing list