From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ky Srinivasan" Subject: Re: context switch Date: Tue, 28 Mar 2006 19:44:00 -0500 Message-ID: <442991FF.E57C.0030.0@novell.com> References: <44284B8E.E57C.0030.0@novell.com> <44291E76.E57C.0030.0@novell.com> <44292D32.E57C.0030.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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 >>> On Tue, Mar 28, 2006 at 12:40 pm, in message , Keir Fraser wrote: > On 28 Mar 2006, at 18:33, Ky Srinivasan wrote: > >> Looking more at the generic Linux CS code, saving the selector values >> of the outgoing context and setting the segment registers values to >> zero >> in prepare_arch_switch() we think deals with the problem I have listed >> below (thanks to Jan for pointing this out). > > That's what our own trees do already. > >> While this expensive trick >> may solve this problem, a simpler solution perhaps might be to have an >> efficient mechanism for the guest to manage hypervisor preemptions. > > Why is it expensive? The updates to zero only happen if the previous > selector value was non- zero, which is usually not the case for 64- bit > apps. The expense I was referring to is the selector loads (to zero them out). The prepare_arch_switch() is also used on the 32 bit side as well (for fs and gs). > > Things should work okay even without the zeroing, by the way. It just > avoids an unnecessary failsafe callback into the guest kernel. I fixed > the failsafe handler for x86/64 earlier today. > > -- Keir K. Y