Not really, no.
Sent from my tablet, pardon any formatting problems.
> On Sep 22, 2014, at 06:31, Christopher Covington wrote:
>
>> On 09/19/2014 05:46 PM, H. Peter Anvin wrote:
>> On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
However, it sounds to me that at least for KVM, it is ve
On 09/22/2014 07:17 AM, H. Peter Anvin wrote:
>
> It could, but how would you enumerate that? A new "RDRAND-CPL-0" CPUID
> bit pretty much would be required.
>
Note that there are two things that differ: the CPL 0-ness and the
performance/exhaustibility attributes.
-hpa
_
On 09/22/2014 06:31 AM, Christopher Covington wrote:
> On 09/19/2014 05:46 PM, H. Peter Anvin wrote:
>> On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
However, it sounds to me that at least for KVM, it is very easy just to
emulate the RDRAND instruction. The hypervisor would report
On 09/19/2014 02:42 PM, Andy Lutomirski wrote:
> On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
> wrote:
>> On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
>>> Hi all-
>>>
>>> I would like to standardize on a very simple protocol by which a guest
>>> OS can obtain an RNG seed early in boot
On 09/19/2014 05:46 PM, H. Peter Anvin wrote:
> On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
>>>
>>> However, it sounds to me that at least for KVM, it is very easy just to
>>> emulate the RDRAND instruction. The hypervisor would report to the guest
>>> that RDRAND is supported in CPUID and the
Hi Andy,
On Fri, 2014-09-19 at 11:20 -0700, Andy Lutomirski wrote:
> [cc: Alok Kataria at VMware]
>
> On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov wrote:
> > On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote:
> >> On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov wrote:
> >> > On F
Il 19/09/2014 22:46, Andy Lutomirski ha scritto:
>> >
>> > However, it sounds to me that at least for KVM, it is very easy just to
>> > emulate the RDRAND instruction. The hypervisor would report to the guest
>> > that RDRAND is supported in CPUID and the emulate the instruction when
>> > guest
On 09/19/2014 04:35 PM, Theodore Ts'o wrote:
> On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
>>
>> Actually, a much bigger reason is because it lets rogue guest *user
>> space*, even will a well-behaved guest OS, do something potentially
>> harmful to the host.
>
> Right, but if
On Fri, Sep 19, 2014 at 4:35 PM, Theodore Ts'o wrote:
> On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
>>
>> Actually, a much bigger reason is because it lets rogue guest *user
>> space*, even will a well-behaved guest OS, do something potentially
>> harmful to the host.
>
> Right
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
>
> Actually, a much bigger reason is because it lets rogue guest *user
> space*, even will a well-behaved guest OS, do something potentially
> harmful to the host.
Right, but if the host kernel is dependent on the guest OS for
secur
On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
>
> To force deterministic execution.
>
> I incorrectly thought that the kernel could switch RDRAND on and off.
> It turns out that a hypervisor can do this, but not the kernel. Also,
> determinism is lost anyway because of TSX, which *also* can't b
On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
>
> To force deterministic execution.
>
> I incorrectly thought that the kernel could switch RDRAND on and off.
> It turns out that a hypervisor can do this, but not the kernel. Also,
> determinism is lost anyway because of TSX, which *also* can't b
On Fri, Sep 19, 2014 at 3:57 PM, Theodore Ts'o wrote:
> On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote:
>> On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o wrote:
>> > On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
>> >>
>> >> There is a huge disadvantage to the fa
On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote:
> On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o wrote:
> > On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
> >>
> >> There is a huge disadvantage to the fact that CPUID is a user space
> >> instruction, though.
> >
>
On Fri, Sep 19, 2014 at 3:06 PM, Andy Lutomirski wrote:
> On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o wrote:
>> On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
>>>
>>> There is a huge disadvantage to the fact that CPUID is a user space
>>> instruction, though.
>>
>> But if the
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o wrote:
> On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
>>
>> There is a huge disadvantage to the fact that CPUID is a user space
>> instruction, though.
>
> But if the goal is to provide something like getrandom(2) direct from
> the
On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
>
> There is a huge disadvantage to the fact that CPUID is a user space
> instruction, though.
But if the goal is to provide something like getrandom(2) direct from
the Host OS, it's not necessarily harmful to allow the Guest ring 3
On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
>>
>> However, it sounds to me that at least for KVM, it is very easy just to
>> emulate the RDRAND instruction. The hypervisor would report to the guest
>> that RDRAND is supported in CPUID and the emulate the instruction when guest
>> executes it.
On Fri, Sep 19, 2014 at 11:20:49AM -0700, Andy Lutomirski wrote:
> [cc: Alok Kataria at VMware]
>
> On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov wrote:
> > On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote:
> >> On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov wrote:
> >> > On Fri,
On Fri, Sep 19, 2014 at 1:21 PM, Nadav Amit wrote:
>
> On Sep 19, 2014, at 9:42 PM, Andy Lutomirski wrote:
>
>> On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
>> wrote:
>>> On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
Hi all-
I would like to standardize on a very simple
On Sep 19, 2014, at 9:42 PM, Andy Lutomirski wrote:
> On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
> wrote:
>> On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
>>> Hi all-
>>>
>>> I would like to standardize on a very simple protocol by which a guest
>>> OS can obtain an RNG seed earl
---
From: Andy Lutomirski [mailto:l...@amacapital.net]
Sent: Thursday, September 18, 2014 12:07 PM
To: Paolo Bonzini
Cc: Jun Nakajima; KY Srinivasan; Mathew John; Theodore Ts'o; John Starks; kvm
list; Gleb Natapov; Niels Ferguson; David Hepkin; H. Peter Anvin; Jake Oshins;
Linux Virtualization
Su
Lutomirski [mailto:l...@amacapital.net]
Sent: Thursday, September 18, 2014 12:04 PM
To: Niels Ferguson
Cc: H. Peter Anvin; Nakajima, Jun; KY Srinivasan; Paolo Bonzini; Mathew John;
Theodore Ts'o; John Starks; kvm list; Gleb Natapov; David Hepkin; Jake Oshins;
Linux Virtualization
Subject: Re: Stan
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
wrote:
> On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
>> Hi all-
>>
>> I would like to standardize on a very simple protocol by which a guest
>> OS can obtain an RNG seed early in boot.
>>
>> The main design requirements are:
>>
>> - The i
On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
> Hi all-
>
> I would like to standardize on a very simple protocol by which a guest
> OS can obtain an RNG seed early in boot.
>
> The main design requirements are:
>
> - The interface should be very easy to use. Linux, at least, will
> want to u
[cc: Alok Kataria at VMware]
On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov wrote:
> On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote:
>> On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov wrote:
>> > On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote:
>> >> On 09/19/2014
On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote:
> On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov wrote:
> > On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote:
> >> On 09/19/2014 10:15 AM, Gleb Natapov wrote:
> >> > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter An
On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov wrote:
> On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote:
>> On 09/19/2014 10:15 AM, Gleb Natapov wrote:
>> > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
>> >> On 09/19/2014 09:53 AM, Gleb Natapov wrote:
>> >>> On Fr
On Fri, Sep 19, 2014 at 10:21:27AM -0700, Andy Lutomirski wrote:
> On Sep 19, 2014 9:53 AM, "Gleb Natapov" wrote:
> >
> > On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
> > > On 09/19/2014 09:37 AM, Gleb Natapov wrote:
> > > >
> > > > Linux detects what hypervior it runs on very e
On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote:
> On 09/19/2014 10:15 AM, Gleb Natapov wrote:
> > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
> >> On 09/19/2014 09:53 AM, Gleb Natapov wrote:
> >>> On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
>
On Fri, Sep 19, 2014 at 10:36 AM, H. Peter Anvin wrote:
> On 09/19/2014 10:21 AM, Andy Lutomirski wrote:
>>>
>>> There is a huge disadvantage to the fact that CPUID is a user space
>>> instruction, though.
>>
>> We can always make cpuid on the leaf in question return all zeros if CPL > 0.
>>
>
> N
On 09/19/2014 10:21 AM, Andy Lutomirski wrote:
>>
>> There is a huge disadvantage to the fact that CPUID is a user space
>> instruction, though.
>
> We can always make cpuid on the leaf in question return all zeros if CPL > 0.
>
Not sure that is better...
-hpa
On Sep 19, 2014 9:40 AM, "H. Peter Anvin" wrote:
>
> On 09/19/2014 09:14 AM, Nakajima, Jun wrote:
> >
> > I slept on it, and I think using the CPUID instruction alone would be
> > simple and efficient:
> > - We have a huge space for CPUID leaves
> > - CPUID also works for user-level
> > - It can t
On Sep 19, 2014 9:53 AM, "Gleb Natapov" wrote:
>
> On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
> > On 09/19/2014 09:37 AM, Gleb Natapov wrote:
> > >
> > > Linux detects what hypervior it runs on very early
> >
> > Not anywhere close to early enough. We're talking for uses like
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
> On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
>> On 09/19/2014 09:53 AM, Gleb Natapov wrote:
>>> On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
>
> Linux detects
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
> On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
>> On 09/19/2014 09:53 AM, Gleb Natapov wrote:
>>> On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
>
> Linux detects
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
> On 09/19/2014 09:53 AM, Gleb Natapov wrote:
> > On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
> >> On 09/19/2014 09:37 AM, Gleb Natapov wrote:
> >>>
> >>> Linux detects what hypervior it runs on very early
> >>
> >>
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
> On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
>> On 09/19/2014 09:37 AM, Gleb Natapov wrote:
>>>
>>> Linux detects what hypervior it runs on very early
>>
>> Not anywhere close to early enough. We're talking for uses like kASLR.
>>
>
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
> On 09/19/2014 09:37 AM, Gleb Natapov wrote:
> >
> > Linux detects what hypervior it runs on very early
>
> Not anywhere close to early enough. We're talking for uses like kASLR.
>
Still to early to do:
h = cpuid(HYPERVIOR_SIGN
On 09/19/2014 09:14 AM, Nakajima, Jun wrote:
>
> I slept on it, and I think using the CPUID instruction alone would be
> simple and efficient:
> - We have a huge space for CPUID leaves
> - CPUID also works for user-level
> - It can take an additional 32-bit parameter (ECX), and returns 4
> 32-bit
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
>
> Linux detects what hypervior it runs on very early
Not anywhere close to early enough. We're talking for uses like kASLR.
-hpa
___
Virtualization mailing list
Virtualization@lists.linux-foundatio
On Thu, Sep 18, 2014 at 03:00:05PM -0700, Andy Lutomirski wrote:
> On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin wrote:
> > I suggest we come to consensus on a specific CPUID leaf where an OS needs
> > to look to determine if a hypervisor supports this capability. We could
> > define a new CPUI
Il 19/09/2014 18:14, Nakajima, Jun ha scritto:
> For example,
> - CPUID 0x4801.EAX would return the feature presence (e.g. in
> EBX), and the result in EDX:EAX (if present) at the same time, or
> - CPUID 0x4801.EAX would return the feature presence only, and
> CPUID 0x4802.EAX (acts lik
On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski wrote:
> On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski wrote:
>> On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun
>> wrote:
>>> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski
>>> wrote:
>>>
So, as a concrete straw-man:
CPUID l
Il 18/09/2014 23:54, David Hepkin ha scritto:
> The chief advantage I see to using a hypercall based mechanism is
> that it would work across more architectures. MSR's and CPUID's are
> specific to X86. If we ever wanted this same mechanism to be
> available on an architecture that doesn't suppor
On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski wrote:
> On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun wrote:
>> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski wrote:
>>
>>> So, as a concrete straw-man:
>>>
>>> CPUID leaf 0x4800 would return a maximum leaf number in EAX (e.g.
>>> 0x48000
On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun wrote:
> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski wrote:
>
>> So, as a concrete straw-man:
>>
>> CPUID leaf 0x4800 would return a maximum leaf number in EAX (e.g.
>> 0x4801) along with a signature value (e.g. "CrossHVPara\0") in
>> EB
On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski wrote:
> So, as a concrete straw-man:
>
> CPUID leaf 0x4800 would return a maximum leaf number in EAX (e.g.
> 0x4801) along with a signature value (e.g. "CrossHVPara\0") in
> EBX, ECX, and EDX.
>
> CPUID 0x4801.EAX would contain an MSR
On Thu, Sep 18, 2014 at 2:57 PM, H. Peter Anvin wrote:
> On 09/18/2014 02:46 PM, David Hepkin wrote:
>> I'm not sure what you mean by "this mechanism?" Are you suggesting that
>> each hypervisor put "CrossHVPara\0" somewhere in the 0x4000 - 0x400f
>> CPUID range, and an OS has to do a f
On 09/18/2014 03:00 PM, Andy Lutomirski wrote:
> On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin wrote:
>> I'm not sure what you mean by "this mechanism?" Are you suggesting that
>> each hypervisor put "CrossHVPara\0" somewhere in the 0x4000 - 0x400f
>> CPUID range, and an OS has to do a
On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin wrote:
> I'm not sure what you mean by "this mechanism?" Are you suggesting that each
> hypervisor put "CrossHVPara\0" somewhere in the 0x4000 - 0x400f CPUID
> range, and an OS has to do a full scan of this CPUID range on boot to find
> it?
On 09/18/2014 02:46 PM, David Hepkin wrote:
> I'm not sure what you mean by "this mechanism?" Are you suggesting that each
> hypervisor put "CrossHVPara\0" somewhere in the 0x4000 - 0x400f CPUID
> range, and an OS has to do a full scan of this CPUID range on boot to find
> it? That see
On Thu, Sep 18, 2014 at 2:21 PM, Nakajima, Jun wrote:
> On Thu, Sep 18, 2014 at 12:07 PM, Andy Lutomirski wrote:
>
>> Might Intel be willing to extend that range to 0x4000 -
>> 0x400f? And would Microsoft be okay with using this mechanism for
>> discovery?
>
> So, for CPUID, the SDM (Tab
On Thu, Sep 18, 2014 at 12:07 PM, Andy Lutomirski wrote:
> Might Intel be willing to extend that range to 0x4000 -
> 0x400f? And would Microsoft be okay with using this mechanism for
> discovery?
So, for CPUID, the SDM (Table 3-17. Information Returned by CPUID) says today:
"No existing
ake Oshins; Linux
Virtualization
Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed?
Quite frankly it might make more sense to define a cross-VM *cpuid* range. The
cpuid leaf can just point to the MSR. The big question is who will be willing
to be the registrar.
On Septembe
: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels
Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux
Virtualization
Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed?
Il 18/09/2014 19:13, Nakajima, Jun ha scritto:
> In term
On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini wrote:
>
>> > Actually, that MSR address range has been reserved for that purpose, along
>> > with:
>> > - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal)
>> > - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID)
>>
>> I don't know whethe
On Thu, Sep 18, 2014 at 11:54 AM, Niels Ferguson wrote:
> Defining a standard way of transferring random numbers between the host and
> the guest is an excellent idea.
>
> As the person who writes the RNG code in Windows, I have a few comments:
>
> DETECTION:
> It should be possible to detect thi
> > Actually, that MSR address range has been reserved for that purpose, along
> > with:
> > - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal)
> > - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID)
>
> I don't know whether this is documented anywhere, but Linux tries to
> detect a h
> >> However, I think it would be better to have the MSR (and perhaps CPUID)
> >> outside the hypervisor-reserved ranges, so that it becomes architecturally
> >> defined. In some sense it is similar to the HYPERVISOR CPUID feature.
> >
> > Yes, given that we want this to be hypervisor agnostic.
>
y, September 18, 2014 10:18 AM
>>>> To: Nakajima, Jun; KY Srinivasan
>>>> Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb
>Natapov; Niels
>>>> Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake
>Oshins; Linux
>>>>
Sent: Thursday, September 18, 2014 10:18 AM
>>> To: Nakajima, Jun; KY Srinivasan
>>> Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels
>>> Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux
>>> Virtualization
&
;> Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels
>> Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux
>> Virtualization
>> Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed?
>>
>> Il
Niels
> Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux
> Virtualization
> Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed?
>
> Il 18/09/2014 19:13, Nakajima, Jun ha scritto:
> > In terms of the address for the MSR, I suggest th
Il 18/09/2014 19:13, Nakajima, Jun ha scritto:
> In terms of the address for the MSR, I suggest that you choose one
> from the range between 4000H - 40FFH. The SDM (35.1
> ARCHITECTURAL MSRS) says "All existing and
> future processors will not implement any features using any MSR in
> this
On Thu, Sep 18, 2014 at 9:36 AM, KY Srinivasan wrote:
>
> I am copying other Hyper-V engineers to this discussion.
>
Thanks, K.Y.
In terms of the address for the MSR, I suggest that you choose one
from the range between 4000H - 40FFH. The SDM (35.1
ARCHITECTURAL MSRS) says "All existing
> -Original Message-
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Thursday, September 18, 2014 8:38 AM
> To: H. Peter Anvin
> Cc: KY Srinivasan; Linux Virtualization; kvm list; Gleb Natapov; Paolo
> Bonzini;
> Theodore Ts'o
> Subject: Re:
Il 18/09/2014 17:44, Andy Lutomirski ha scritto:
> Slight correction: QEMU/KVM has optional support for Hyper-V feature
> enumeration. Ideally the RNG seed mechanism would be enabled by
> default, but I don't know whether the QEMU maintainers would be okay
> with enabling the Hyper-V cpuid mechani
On Thu, Sep 18, 2014 at 8:38 AM, Andy Lutomirski wrote:
> On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin wrote:
>> On 09/18/2014 07:40 AM, KY Srinivasan wrote:
The main questions are what MSR index to use and how to detect the
presence of the MSR. I've played with two approaches:
On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin wrote:
> On 09/18/2014 07:40 AM, KY Srinivasan wrote:
>>>
>>> The main questions are what MSR index to use and how to detect the
>>> presence of the MSR. I've played with two approaches:
>>>
>>> 1. Use CPUID to detect the presence of this feature.
> -Original Message-
> From: virtualization-boun...@lists.linux-foundation.org
> [mailto:virtualization-boun...@lists.linux-foundation.org] On Behalf Of Andy
> Lutomirski
> Sent: Wednesday, September 17, 2014 7:51 PM
> To: Linux Virtualization; kvm list
> Cc: Gleb Natapov; Paolo Bonzini;
On 09/18/2014 07:40 AM, KY Srinivasan wrote:
>>
>> The main questions are what MSR index to use and how to detect the
>> presence of the MSR. I've played with two approaches:
>>
>> 1. Use CPUID to detect the presence of this feature. This is very easy for
>> KVM to implement by using a KVM-specif
72 matches
Mail list logo
