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: Mon, 2 Jun 2014 11:07:34 +0100 Message-ID: <538C4CE6.5000501@citrix.com> References: <1401439171-1916-1-git-send-email-andrew.cooper3@citrix.com> <53887C0B02000078000B5425@mail.emea.novell.com> <5388721E.3090301@citrix.com> <538C39160200007800016AD3@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <538C39160200007800016AD3@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 Cc: keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 02/06/14 07:43, Jan Beulich wrote: >>>> On 30.05.14 at 13:57, wrote: >> 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. > Whether the loading would fail really depends on what exactly became > corrupted. The current behaviour is that the load would fail, as validate_xstate() would fail. > > But in the end the question is - are you intending to no longer > communicate this bit of information in the v2 migration stream? > > Jan > Ideally I would like to cease communicating this in the v2 stream. ~Andrew