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 GDTbeforekexec

To: "Ian Campbell" <Ian.Campbell@xxxxxxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] switch to a known good/static GDTbeforekexec
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 03 Jul 2009 08:15:33 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 03 Jul 2009 00:15:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C672D038.EBA5%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>
References: <C67268C0.885D%keir.fraser@xxxxxxxxxxxxx> <C672D038.EBA5%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 02.07.09 21:59 >>>
>On 02/07/2009 13:38, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>>>> 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)?
>>> While that's correct, we're talking about a single memory write here (plus
>>> the setup code), which I think is no more wasteful than adding the extra
>>> checking that would be needed to see whether we switch between
>>> compat and !compat (including the !need_full_gdt(p) case, where we
>>> don't know what kind of mapping we currently have).
>> Hm yes, fair enough.
>Actually no, I'm not sure what extra checking you think you'd need? You'd
>create the per-vcpu mapping when a vcpu is created and when it changes
>to/from compat mode, and that would be it wouldn't it? You'd only delete
>code from __context_switch(); not add different code to it?

While you're right that my explanation wasn't really correct, moving this
back to the vCPU creation/mode-switching functions doesn't work because
the GDT is now per-CPU (and it's that patch where this code got added to
context switch): The installed mapping depends on the *physical* CPU the
code is running on. So the extra dependency that might be added here
would be to check whether the physical CPU the vCPU is running on
changed, but afair v->processor gets set before entering context_switch(),
so we'd have to additionally capture and store the last used value. Would
you think that's worth it?


Xen-devel mailing list