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