From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo5Uv-0002By-Fa for qemu-devel@nongnu.org; Mon, 19 Oct 2015 04:08:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zo5Us-0005sS-Al for qemu-devel@nongnu.org; Mon, 19 Oct 2015 04:08:49 -0400 Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:35366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo5Us-0005sG-5B for qemu-devel@nongnu.org; Mon, 19 Oct 2015 04:08:46 -0400 Received: by wicll6 with SMTP id ll6so84074880wic.0 for ; Mon, 19 Oct 2015 01:08:45 -0700 (PDT) Sender: Paolo Bonzini References: <20151016153356.28104.48612.stgit@gimli.home> From: Paolo Bonzini Message-ID: <5624A50A.1040107@redhat.com> Date: Mon, 19 Oct 2015 10:08:42 +0200 MIME-Version: 1.0 In-Reply-To: <20151016153356.28104.48612.stgit@gimli.home> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] kvm: Allow the Hyper-V vendor ID to be specified List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson , qemu-devel@nongnu.org, kvm@vger.kernel.org Cc: imammedo@redhat.com On 16/10/2015 17:38, Alex Williamson wrote: > According to Microsoft documentation, the signature in the standard > hypervisor CPUID leaf at 0x40000000 identifies the Vendor ID and is > for reporting and diagnostic purposes only. We can therefore allow > the user to change it to whatever they want, within the 12 character > limit. Add a new hyperv-vendor-id option to the -cpu flag to allow > for this, ex: > > -cpu host,hv_time,hv_vendor_id=KeenlyKVM > > Link: http://msdn.microsoft.com/library/windows/hardware/hh975392 > Signed-off-by: Alex Williamson > --- > > v2: Replace abort() with truncating the string, error report updated > > Igor also had the idea of creating a DEFINE_PROP_STRING_LEN property > where we could enforce the length earlier in the parameter checking. > If we like that idea, we probably need to do it first since we don't > want to switch from truncating to erroring between releases. I can > work on that if preferred. Thanks, I applied this one, because the truncation matches what is done in other places (ACPI tables, SCSI product/vendor, etc.) Paolo