From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [RFC PATCH] Drop error return if size mismatch is due to xcr0 settings Date: Thu, 9 Oct 2014 16:56:49 +0100 Message-ID: <5436B041.9070104@citrix.com> References: <1412792976-6696-1-git-send-email-dkoch@verizon.com> <20141009114539.e701a4337830f2330fb5e729@verizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141009114539.e701a4337830f2330fb5e729@verizon.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: Don Koch Cc: Keir Fraser , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 09/10/14 16:45, Don Koch wrote: > On Wed, 8 Oct 2014 14:29:36 -0400 > Don Koch wrote: > >> This prevents migration from 4.3 to 4.4 (or newer) xen on AMD machines, at >> least. > A clarification: a previous change made migration from xen 4.3 to 4.4 on AMD > machine fail. This patch provides a (minimal) fix for the problem. IMO, it should > be targeted for 4.5 and 4.4.x (whatever the next 'x' is). > > If it's decided to add the other changes I've suggested, those could be provided > in a separate patch, especially if we're time constrained (like for getting it > into 4.5). > > -d Can you explain what the bug is and why this is an appropriate fix? What is happening here is that the migration stream is providing an xsave area larger than the size it should be based on the xcr0 sent with it. This means that either the sending Xen sent a bogus record, or the new Xen has incorrectly calculated the size from xcr0, but *both* of these cases are potential VM data corruption issues. As this currently stands with no analysis of the problem and proof as to why the change is safe, dropping the "return -EOPNOTSUPP;" is not valid IMO. ~Andrew