From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH RFC v1 2/2] hyper-v: initialize Hyper-V CPUID leafs. Date: Mon, 17 Oct 2011 15:57:43 +0200 Message-ID: <4E9C3457.1080300@redhat.com> References: <1318843022-20344-1-git-send-email-vrozenfe@redhat.com> <1318843022-20344-3-git-send-email-vrozenfe@redhat.com> <4E9BF816.3010205@redhat.com> <4E9C0641.4080107@redhat.com> <4E9C069F.209@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" , qemu-devel To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43887 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753337Ab1JQN5t (ORCPT ); Mon, 17 Oct 2011 09:57:49 -0400 In-Reply-To: <4E9C069F.209@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/17/2011 12:42 PM, Paolo Bonzini wrote: > On 10/17/2011 12:41 PM, Avi Kivity wrote: >> > Even not counting that hyper-v support should IMHO not be in >> > KVM-specific code, I still think this shouldn't remove KVM leaves >> > completely but rather move them to 0x40000100. The KVM >> > paravirtualization code then can similarly probe with 0x100 stride up >> > to 0x40001000. This is what was done for Xen, and it allows to >> enable >> > enlightenments independent of whether the guest is Linux or Windows. >> > >> > However, let's get a third opinion---Avi, what do you think? >> >> I agree with you, especially as this already works for Xen. >> >> Note it doesn't completely solve the issue (so we have two interfaces, >> which is the preferred one?), but it's better than nothing. > > Windows doesn't look beyond 0x40000000, so Hyper-V stays there and KVM > has to shift. So MS solved that part for us. :) I mean, suppose Linux finds hyper-v at 000 and kvm at 100. Is it kvm impersonating hyper-v, or a future hyper-v impersonating kvm, or something else (TAINT_CRAP?) impersonating both? -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFnhS-000335-6Y for qemu-devel@nongnu.org; Mon, 17 Oct 2011 09:57:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFnhN-0001iM-Du for qemu-devel@nongnu.org; Mon, 17 Oct 2011 09:57:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFnhN-0001i9-6q for qemu-devel@nongnu.org; Mon, 17 Oct 2011 09:57:49 -0400 Message-ID: <4E9C3457.1080300@redhat.com> Date: Mon, 17 Oct 2011 15:57:43 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1318843022-20344-1-git-send-email-vrozenfe@redhat.com> <1318843022-20344-3-git-send-email-vrozenfe@redhat.com> <4E9BF816.3010205@redhat.com> <4E9C0641.4080107@redhat.com> <4E9C069F.209@redhat.com> In-Reply-To: <4E9C069F.209@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC v1 2/2] hyper-v: initialize Hyper-V CPUID leafs. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel , "kvm@vger.kernel.org" On 10/17/2011 12:42 PM, Paolo Bonzini wrote: > On 10/17/2011 12:41 PM, Avi Kivity wrote: >> > Even not counting that hyper-v support should IMHO not be in >> > KVM-specific code, I still think this shouldn't remove KVM leaves >> > completely but rather move them to 0x40000100. The KVM >> > paravirtualization code then can similarly probe with 0x100 stride up >> > to 0x40001000. This is what was done for Xen, and it allows to >> enable >> > enlightenments independent of whether the guest is Linux or Windows. >> > >> > However, let's get a third opinion---Avi, what do you think? >> >> I agree with you, especially as this already works for Xen. >> >> Note it doesn't completely solve the issue (so we have two interfaces, >> which is the preferred one?), but it's better than nothing. > > Windows doesn't look beyond 0x40000000, so Hyper-V stays there and KVM > has to shift. So MS solved that part for us. :) I mean, suppose Linux finds hyper-v at 000 and kvm at 100. Is it kvm impersonating hyper-v, or a future hyper-v impersonating kvm, or something else (TAINT_CRAP?) impersonating both? -- error compiling committee.c: too many arguments to function