From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57431) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCvu3-0006NU-Dv for qemu-devel@nongnu.org; Tue, 14 Jun 2016 17:29:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCvtz-0006OU-8n for qemu-devel@nongnu.org; Tue, 14 Jun 2016 17:29:42 -0400 Received: from mail-db3on0128.outbound.protection.outlook.com ([157.55.234.128]:4096 helo=emea01-db3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCvty-0006O1-Gd for qemu-devel@nongnu.org; Tue, 14 Jun 2016 17:29:39 -0400 References: <1465900120-2350-1-git-send-email-den@openvz.org> <20160614195921.GK17952@thinpad.lan.raisama.net> <57606CD4.4020609@openvz.org> <20160614205442.GL17952@thinpad.lan.raisama.net> From: "Denis V. Lunev" Message-ID: <57607026.502@openvz.org> Date: Tue, 14 Jun 2016 23:59:18 +0300 MIME-Version: 1.0 In-Reply-To: <20160614205442.GL17952@thinpad.lan.raisama.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/1] cpu: report hyperv feature words through qom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Paolo Bonzini , Marcelo Tosatti , Evgeny Yakovlev , qemu-devel@nongnu.org, Richard Henderson On 06/14/2016 11:54 PM, Eduardo Habkost wrote: > On Tue, Jun 14, 2016 at 11:45:08PM +0300, Denis V. Lunev wrote: >> On 06/14/2016 10:59 PM, Eduardo Habkost wrote: >>> On Tue, Jun 14, 2016 at 01:28:40PM +0300, Denis V. Lunev wrote: >>>> From: Evgeny Yakovlev >>>> >>>> This change adds hyperv feature words report through qom rpc. >>>> >>>> When VM is configured with hyperv features enabled libvirt will check that >>>> required featured words are set in cpuid leaf 40000003 through qom >>>> request. >>>> >>>> Currently qemu does not report hyperv feature words which prevents windows >>>> guests from starting with libvirt. >>>> >>>> Signed-off-by: Evgeny Yakovlev >>>> Signed-off-by: Denis V. Lunev >>>> CC: Paolo Bonzini >>>> CC: Richard Henderson >>>> CC: Eduardo Habkost >>>> CC: Marcelo Tosatti >>> Which QEMU version did you use to test this? Some of those properties already >>> exist. See: >>> >>> static Property x86_cpu_properties[] = { >>> [...] >>> { .name = "hv-spinlocks", .info = &qdev_prop_spinlocks }, >>> DEFINE_PROP_BOOL("hv-relaxed", X86CPU, hyperv_relaxed_timing, false), >>> DEFINE_PROP_BOOL("hv-vapic", X86CPU, hyperv_vapic, false), >>> DEFINE_PROP_BOOL("hv-time", X86CPU, hyperv_time, false), >>> DEFINE_PROP_BOOL("hv-crash", X86CPU, hyperv_crash, false), >>> DEFINE_PROP_BOOL("hv-reset", X86CPU, hyperv_reset, false), >>> DEFINE_PROP_BOOL("hv-vpindex", X86CPU, hyperv_vpindex, false), >>> DEFINE_PROP_BOOL("hv-runtime", X86CPU, hyperv_runtime, false), >>> DEFINE_PROP_BOOL("hv-synic", X86CPU, hyperv_synic, false), >>> DEFINE_PROP_BOOL("hv-stimer", X86CPU, hyperv_stimer, false), >>> [...] >>> DEFINE_PROP_STRING("hv-vendor-id", X86CPU, hyperv_vendor_id), >>> DEFINE_PROP_END_OF_LIST() >>> }; >>> >>> QEMU will crash if you try to register the properties twice: >>> >>> $ ./x86_64-softmmu/qemu-system-x86_64 >>> qemu-system-x86_64: /home/ehabkost/rh/proj/virt/qemu/target-i386/cpu.c:3094: x86_cpu_register_bit_prop: Assertion `fp->ptr == field' failed. >>> Aborted (core dumped) >>> >>> I like the idea of moving hyperv feature information inside the features array, >>> though. >> no, idea is a bit different. >> >> The user selects properties in the command line to enable >> different HyperV enlightenments. This is how we do that >> and this is how the QEMU is expected to work. >> >> After that libvirt starts to check that these properties do >> work. In order to do that it executes qom-get and expects >> to find enabled HyperV enlightenments in the guest CPUID. >> >> This is the idea of this patch. > And why exactly moving hyperv feature information inside the > CPUX86State::features array wouldn't do exactly what you say > above? > property remains ;) OK, may be I have missed you point. I fear word "move" in your letter. I think we "add" it to features. Anyway, I got your point that features comes first, CPUID is filled in the base of features. No prob. Den