From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z74Z5-0008RG-1n for qemu-devel@nongnu.org; Mon, 22 Jun 2015 12:27:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z74Z1-0005om-Pz for qemu-devel@nongnu.org; Mon, 22 Jun 2015 12:27:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35163) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z74Z1-0005oK-Et for qemu-devel@nongnu.org; Mon, 22 Jun 2015 12:27:15 -0400 Message-ID: <55883760.6010502@redhat.com> Date: Mon, 22 Jun 2015 18:27:12 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1434989108-20924-1-git-send-email-den@openvz.org> <1434989108-20924-12-git-send-email-den@openvz.org> <55883686.2090209@suse.de> In-Reply-To: <55883686.2090209@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 11/11] qemu/kvm: mark in cpu state that hyper-v crash occured List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , "Denis V. Lunev" Cc: Andrey Smetanin , qemu-devel@nongnu.org, kvm@vger.kernel.org, Juan Quintela On 22/06/2015 18:23, Andreas F=C3=A4rber wrote: >> > @@ -679,6 +679,7 @@ static const VMStateDescription vmstate_msr_hype= rv_crash =3D { >> > VMSTATE_UINT64(env.msr_hv_crash_ctl, X86CPU), >> > VMSTATE_UINT64_ARRAY(env.msr_hv_crash_prm, >> > X86CPU, HV_X64_MSR_CRASH_PARAMS), >> > + VMSTATE_UINT8(env.hv_crash_occurred, X86CPU), >> > VMSTATE_END_OF_LIST() >> > } >> > }; > This looks like a migration format breakage. You probably need to squas= h > it with the preceding patch so that the "cpu/msr_hyperv_crash" > subsection does not change in size between commits. Just incrementing > the version is not an option for subsections, I think? We don't usually care about migration format within the same upstream release, but yes that would be better. On the other hand, I wonder if current_cpu is available in qemu_system_guest_panicked. If so, you could add the field to the generic CPUState struct and migrate it as a subsection of vmstate_cpu_common. Paolo