[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51EECF5F.8000901@zytor.com>
Date: Tue, 23 Jul 2013 11:45:51 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: KY Srinivasan <kys@...rosoft.com>
CC: Jason Wang <jasowang@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"x86@...nel.org" <x86@...nel.org>,
"gleb@...hat.com" <gleb@...hat.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] x86: properly handle kvm emulation of hyperv
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists