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] context switch

 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). 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. We
could build this mechanism in a way  that does not compromise the
ability of the hypervisor to deal with buggy guests while still
supporting efficient implementation of guests. This preemption
management framework also would be useful in dealing with bad preemption
problems in SMP guests. Would there be an interest in implementing this
preemption management framework.

Regards,
 
K. Y

>>> "Ky Srinivasan" <ksrinivasan@xxxxxxxxxx> 03/28/06 11:31 am >>> 
In debugging the sles9 port on 64 bit MP machines, I am seeing a
problem
where the hypervisor takes a fault in loading fs in the context switch
code (load_segments()). The selector is one of the TLS selectors. It
appears that the cpu in question has updated this selector with a
value
of 0 just prior to the problem I am seeing. Looking at the Linux
context
switch code, we first update the TLS selector values of the incoming
context  before we load the segment registers. So, if we preempt the
CPU
after it has modified the gdt table but before it loads up the segment
registers, we could get into a situation where when the hypervisor
resumes the preempted domain on this cpu, we could fault on the
segment
register load. I am  curious to understand why this is not an issue.
How
are such windows closed. 

Regards,

K. Y



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


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

<Prev in Thread] Current Thread [Next in Thread>