From: "H. Peter Anvin" <hpa@zytor.com>
To: KY Srinivasan <kys@microsoft.com>
Cc: Jason Wang <jasowang@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
"gleb@redhat.com" <gleb@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv
Date: Tue, 23 Jul 2013 11:45:51 -0700 [thread overview]
Message-ID: <51EECF5F.8000901@zytor.com> (raw)
In-Reply-To: <e31a95e22bbc4c8dbbf76f88b8c90581@SN2PR03MB061.namprd03.prod.outlook.com>
On 07/23/2013 10:45 AM, KY Srinivasan wrote:
>>
>> One strategy would be to pick the *last* one in the CPUID list, since
>> the ones before it are logically the one(s) being emulated...
>
> Is it always possible to guarantee this ordering. As a hypothetical, what if hypervisor A
> emulates Hypervisor B and Hypervisor B emulates Hypervisor A. In this case we cannot
> have any "order" based detection that can yield "correct" detection. I define "correctness"
> as follows:
>
> If a guest can run on both the hypervisors, the guest should detect the true native
> Hypervisor.
>
My point was that most hypervisors tend to put the native signature at
the end of the list starting at 0x40000000, just to deal with naïve
guests which only look at 0x40000000 and not beyond. So a natural
convention would be to "use the last entry in the list you know how to
handle."
-hpa
next prev parent reply other threads:[~2013-07-23 18:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 9:41 [PATCH 1/4] x86: introduce hypervisor_cpuid_base() Jason Wang
2013-07-23 9:41 ` [PATCH 2/4] xen: switch to use hypervisor_cpuid_base() Jason Wang
2013-07-23 11:16 ` Paolo Bonzini
2013-07-23 15:55 ` Konrad Rzeszutek Wilk
2013-07-23 9:41 ` [PATCH 3/4] kvm: " Jason Wang
2013-07-23 11:16 ` Paolo Bonzini
2013-07-23 9:41 ` [PATCH 4/4] x86: properly handle kvm emulation of hyperv Jason Wang
2013-07-23 11:17 ` Paolo Bonzini
2013-07-23 13:55 ` KY Srinivasan
2013-07-23 14:48 ` H. Peter Anvin
2013-07-23 17:45 ` KY Srinivasan
2013-07-23 18:45 ` H. Peter Anvin [this message]
2013-07-23 22:42 ` KY Srinivasan
2013-07-24 4:37 ` Jason Wang
2013-07-24 4:48 ` H. Peter Anvin
2013-07-24 6:54 ` Jason Wang
2013-07-24 7:06 ` Paolo Bonzini
2013-07-24 14:01 ` KY Srinivasan
2013-07-24 15:14 ` H. Peter Anvin
2013-07-24 19:05 ` KY Srinivasan
2013-07-24 21:37 ` H. Peter Anvin
2013-07-25 7:59 ` Paolo Bonzini
2013-07-25 8:12 ` Jason Wang
2013-07-23 10:04 ` [PATCH 1/4] x86: introduce hypervisor_cpuid_base() H. Peter Anvin
2013-07-23 11:16 ` Paolo Bonzini
2013-07-23 16:03 ` H. Peter Anvin
2013-07-24 4:44 ` Jason Wang
2013-07-24 4:47 ` H. Peter Anvin
2013-07-23 13:48 ` Gleb Natapov
2013-07-24 4:34 ` Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51EECF5F.8000901@zytor.com \
--to=hpa@zytor.com \
--cc=gleb@redhat.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox