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] 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 12:11:40 +0100
Cc: Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Thu, 02 Jul 2009 04:12:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C672500B.8846%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: Acn68WnUxTkVYj07SMCr10xI1j0rhwABKjolAANJxEwAAKltrw==
Thread-topic: [Xen-devel] Re: [PATCH] switch to a known good/static GDT before kexec
User-agent: Microsoft-Entourage/12.19.0.090515
On 02/07/2009 11:52, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

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

Okay, having read through __context_switch() in detail with Ian Campbell, we
decided the logic there is correct. If you switch to a !need_full_gdt() vcpu
then you always switch back to the default gdt_table, so the per-domain
mappings do not matter. This also explains why kexec now needs to forcibly
lgdt -- when it forcibly switches back to idle_pg_table the per-domain
mappings will not be there and so we fault on next segment reload.

I have one more question then -- when need_full_gdt(n), why do we always
unconditionally rewrite the l1es mapping the reserved gdt entries? Shouldn't
that be done on vcpu creation only and perhaps on compat mode switch (i.e.,
isn't it wasteful to do it in the context switch path)?

 -- Keir



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