From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: XSAVE save/restore shortcomings Date: Thu, 05 Sep 2013 12:53:16 +0200 Message-ID: <5228629C.2090103@redhat.com> References: <5220884102000078000EFA99@nat28.tlf.novell.com> <52208BD602000078000EFACC@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VHXBe-0006al-O8 for xen-devel@lists.xenproject.org; Thu, 05 Sep 2013 10:53:18 +0000 Received: by mail-ea0-f180.google.com with SMTP id h10so810478eaj.11 for ; Thu, 05 Sep 2013 03:53:17 -0700 (PDT) In-Reply-To: <52208BD602000078000EFACC@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 Cc: xen-devel , Keir Fraser , Donald D Dugger , Jun Nakajima List-Id: xen-devel@lists.xenproject.org Il 30/08/2013 12:11, Jan Beulich ha scritto: > I'd like to make clear that the change presented is going to handle > only the most trivial cases (where any new xsave state addition > adds to the end of the save area). This is an effect of a more > fundamental flaw in the original design (which the patch doesn't try > to revise, as it's not clear to me yet what the best approach here is): > While the XSAVE hardware specification allows for each piece to be > individually savable/restorable, both PV and HVM save/restore > assume a single monolithic blob. Which is already going to be a > problem: AVX-512 as well as MPX conflict with LWP. And obviously > it can't be excluded that we'll see CPUs supporting AVX-512 but not > MPX as well as guests using the former but not the latter, and > neither can be dealt with under the current design. This should not be a problem, the manual says "The layout of the XSAVE/XRSTOR save area is fixed and may contain non-contiguous individual save areas. The XSAVE/XRSTOR save area is not compacted if some features are not saved or are not supported by the processor and/or by system software". Note "by the processor": the way I read this, size may vary (which is why CPUID.0Dh exists, basically), but offsets are guaranteed to be constant. Thus the only problem is LWP. Given AMD's current non-involvement in x86, it may be simpler to avoid the problem completely by not implementing virtual LWP... Paolo > I therefore think that we'll need to start over from scratch with > how save/restore is to be implemented, breaking up the current > monolithic block into individual pieces. But before working on a > proposal, I'd first like to hear whether others can see better (and > namely less intrusive) ways of dealing with the problem. > > Jan >