From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH, RFC] x86: make the GDT per-CPU Date: Thu, 11 Sep 2008 13:35:19 +0100 Message-ID: <48C92CA7.76E4.0078.0@novell.com> References: <48C7F75C.76E4.0078.0@novell.com> <48C92AF7.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <48C92AF7.76E4.0078.0@novell.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> "Jan Beulich" 11.09.08 14:28 >>> >>> Keir Fraser 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. Jan