From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAeZZ-0001J6-Bm for qemu-devel@nongnu.org; Thu, 02 Jul 2015 09:30:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAeZU-0003Xd-D2 for qemu-devel@nongnu.org; Thu, 02 Jul 2015 09:30:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35679) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAeZU-0003XL-6z for qemu-devel@nongnu.org; Thu, 02 Jul 2015 09:30:32 -0400 References: <1435664007-4965-1-git-send-email-den@openvz.org> <1435664007-4965-10-git-send-email-den@openvz.org> <5594023F.70104@redhat.com> <1435843180.21037.13.camel@virtuozzo.com> From: Paolo Bonzini Message-ID: <55953CF2.20700@redhat.com> Date: Thu, 2 Jul 2015 15:30:26 +0200 MIME-Version: 1.0 In-Reply-To: <1435843180.21037.13.camel@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 9/9] qemu/kvm: kvm hyper-v based guest crash event handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: asmetanin@virtuozzo.com Cc: "Denis V. Lunev" , qemu-devel@nongnu.org, kvm@vger.kernel.org, =?UTF-8?Q?Andreas_F=c3=a4rber?= On 02/07/2015 15:19, Andrey Smetanin wrote: >>> > > + if (has_msr_hv_crash) { >>> > > + env->msr_hv_crash_ctl = HV_X64_MSR_CRASH_CTL_NOTIFY; >> > >> > The value is always host-defined, so I think it doesn't need a field in >> > CPUX86State. On the other hand, this: > Kernel just works with that value, kernel doesn't setup it. > The user space is allowed to setup this msr if qemu option "hv-crash" is > on. So the code "env->msr_hv_crash_ctl = HV_X64_MSR_CRASH_CTL_NOTIFY;" > setups msr in user space at cpu reset. When cpu setup it's registers > these msr's values are uploaded into kernel. > > Anyway we need a code that initially set up crash ctl msr with value > HV_X64_MSR_CRASH_CTL_NOTIFY. And I think that code should be user space. > Any objections ? Yes, that's correct. What I'm saying, is that the value can be hard-coded and doesn't need a field in CPUX86State. If you want to leave the field that's also okay, but even then it should not be part of the migration state. Paolo