From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/xsave: Remove xfeat_mask checking from validate_xstate() Date: Fri, 30 May 2014 12:57:18 +0100 Message-ID: <5388721E.3090301@citrix.com> References: <1401439171-1916-1-git-send-email-andrew.cooper3@citrix.com> <53887C0B02000078000B5425@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53887C0B02000078000B5425@mail.emea.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@lists.xen.org Cc: keir@xen.org List-Id: xen-devel@lists.xenproject.org On 30/05/2014 12:39, Jan Beulich wrote: >>>> Andrew Cooper 05/30/14 10:39 AM >>> >> validate_xsave() is call from the HVM and PV codepaths which load new vcpu >> xsave state, usually as part of migration. In both cases, this is the >> xfeature_mask of the saving Xen rather than the restoring Xen. >> >> Given that the xsave state itself is checked for consistency and validity on >> the current cpus, checking whether it was valid for the cpu before migration >> is not interesting (or indeed relevant, as the error can't be distinguished > >from the other validity checking). > > While I'm not entirely opposed to this, I'm also not fully convinced - the data > being available, it can as well be used for additional sanity checking. > > Jan > What further sanity checking would be wanted/needed? The sending Xen must have gotten this correct else it wouldn't have an xsave area to send in the first place. If the receiving the Xen found parts it didn't like, the local validity checks would fail. As far as I can see, the only case this might do something unexpected is if the individual xfeature_mask got changed on transit, at which point the receiving Xen would fail the xsave load, despite the xsave area being valid for the current cpu. ~Andrew