From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/1] KVM: X86: add the support of XSAVE/XRSTOR to guest Date: Thu, 06 May 2010 22:45:07 +0300 Message-ID: <4BE31C43.9060506@redhat.com> References: <1272518554-20357-1-git-send-email-dexuan.cui@intel.com> <4BDD8896.2000607@redhat.com> <1865303E0DED764181A9D882DEF65FB61A82B51D4A@shsmsx502.ccr.corp.intel.com> <4BE27A5A.2020903@redhat.com> <1865303E0DED764181A9D882DEF65FB61A82B51D4C@shsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" , "Yang, Sheng" To: "Cui, Dexuan" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:2750 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754263Ab0EFTpM (ORCPT ); Thu, 6 May 2010 15:45:12 -0400 In-Reply-To: <1865303E0DED764181A9D882DEF65FB61A82B51D4C@shsmsx502.ccr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/06/2010 05:20 PM, Cui, Dexuan wrote: > >> However, switching xcr0 may be slow. That's our experience with msrs. >> Can you measure its latency? >> > We can measure that. > However, I think the changing xcr0 to guest xcr0 in handle_xsetbv() is necessary -- > or else, inside guest xgetbv() would return host xcr0 rather than guest xcr0 -- > this is obviously incorrect. Once handle_xsetbv() changes the xcr0 to guest's value, > the xsetbv() in kvm_fx_restore_host() is also necessary, and the xsetbv() in > kvm_fx_restore_guest() is also necessary. So looks guest can't run with the > host xcr0. > Right. Moreover, xsave would write into memory the guest doesn't expect. >> btw, it needs save/restore for live migration, as well as save/restore >> for the new fpu state. >> > Yes. This part is missing. Sheng and I is also doing this -- it may be a bittle > troublesome as the number of XSTATEs can grown as time goes on. We'll > have to handle the compatibility issue. > Reserve tons of space in the ioctl - and we can use the same format as xsave. All those control registers are annoying, we have cr1 and cr5-cr7 free, cr9-cr15 on x86_64, infinite msr space, and now we have XCRs. Great. Looking forward to YCR0. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.