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] [PATCH, RFC] x86: make the GDT per-CPU

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH, RFC] x86: make the GDT per-CPU
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 11 Sep 2008 13:35:19 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 11 Sep 2008 05:35:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48C92AF7.76E4.0078.0@xxxxxxxxxx>
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: <48C7F75C.76E4.0078.0@xxxxxxxxxx> <C4EEB789.26F59%keir.fraser@xxxxxxxxxxxxx> <48C92AF7.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> "Jan Beulich" <jbeulich@xxxxxxxxxx> 11.09.08 14:28 >>>
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 11.09.08 12:54 >>>
>>You would need to use l1e_write_atomic() in the context-switch code, to make
>>sure all VCPU's hypervisor reserved GDT mappings are always valid. Actually
>>you must at least use l1e_write() in any case -- it is not safe to not use
>>one of those macros on a live pagetable (by which I mean possibly in use by
>>some CPU) because a direct write of a PAE pte is not atomic and can cause
>>the pte to pass through a bogus intermediate state (which could be bogusly
>>prefetched by a CPU into its TLB. Yuk!).
>Ah, yes. l1e_write() should be sufficient, though, as the slot(s) that get(s)
>written cannot be validly in use on any CPU (for other than speculation).

Actually, not really - on PAE, any address ever put in these slots comes
from the Xen heap, so the upper bits are always clear. But for preventing
this to be a latent bug, I'll make the change anyway.

Btw., if there was a callout from the scheduler when a vCPU gets moved
to a new CPU, it would even be possible to get this out of the context
switch path altogether I think.


Xen-devel mailing list