From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: fpu_taskswitch adjustment proposal Date: Fri, 15 Jun 2012 18:06:14 +0100 Message-ID: References: <4FDB790F020000780008A406@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FDB790F020000780008A406@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On 15/06/2012 17:03, "Jan Beulich" wrote: > While pv-ops so far doesn't care to eliminate the two trap-and- > emulate CR0 accesses from the asm/xor.h save/restore > operations, the legacy x86-64 kernel uses conditional clts()/stts() > for this purpose. While looking into whether to extend this to the > newly added (in 3.5) AVX operations there I realized that this isn't > fully correct: It doesn't properly nest inside a kernel_fpu_begin()/ > kernel_fpu_end() pair (as it will stts() at the end no matter what > the original state of CR0.TS was). > > In order to not introduce completely new hypercalls to overcome > this (fpu_taskswitch isn't really extensible on its own), I'm > considering to add a new VM assist, altering the fpu_taskswitch > behavior so that it would return an indicator whether any change > to the virtual CR0.TS was done. That way, the kernel can > implement a true save/restore cycle here. It should be possible for the guest kernel to track its CR0.TS setting shouldn't it? It gets modified only via a few paravirt hooks, and implicitly cleared on #NM. -- Keir > In order to allow the kernel to run on older hypervisors without > extra conditionals (behaving the same way as it does currently, > i.e. with the incorrect nesting), the return value 0 (which the > hypercall currently always returns) would need to be used to > indicate that the bit got actually flipped (such that on an old > hypervisor an updated kernel would always think that > something needs to be restored). > > Would that be an acceptable solution? Can someone think of > other ways to deal with this? (And - is pv-ops interested in > eliminating the two CR0 access emulations in what is supposed > to be a fast path?) > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel