[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

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
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
of 0 just prior to the problem I am seeing. Looking at the Linux
switch code, we first update the TLS selector values of the incoming
context  before we load the segment registers. So, if we preempt the
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
register load. I am  curious to understand why this is not an issue.
are such windows closed. 


K. Y

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.