From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/xsave: simplify xcomp_bv initialization Date: Thu, 17 Dec 2015 17:46:52 +0000 Message-ID: <5672F50C.3000506@citrix.com> References: <5672F7CE02000078000C0D8F@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a9cdl-0002tr-Pl for xen-devel@lists.xenproject.org; Thu, 17 Dec 2015 17:46:57 +0000 In-Reply-To: <5672F7CE02000078000C0D8F@prv-mh.provo.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 Cc: Keir Fraser , Shuai Ruan List-Id: xen-devel@lists.xenproject.org On 17/12/15 16:58, Jan Beulich wrote: > This eliminates a number of pointless conditionals: Bits 0 and 1 of > xcomp_bv don't matter anyway, and as long as none of bits 2..62 are > set, setting bit 63 is pointless too. xcomp_bv[63] is the indication of whether the area is compressed or not. It will be set by the processor when an XSAVEC instruction is issued, and until that point, it doesn't particularly matter as no bits are set. However, it is an ABI indication of the size of the xsave area. It turns out that we are redundantly allocating an uncompressed xsave, even when we will only used the compressed form. For now, I don't think there is any harm, as the lack of XSTATE_COMPACTION_ENABLED causes the size indication to actually be correct, but it will become necessary when we start making use of the optimisations that compaction allows. Reviewed-by: Andrew Cooper (On that note, I really should make some patches for my planned cleanup for XSA-165. I have just been too busy recently.)