On 08/09/2012 10:13 AM, Stefan Bader wrote:
> Avi, was the last version of the patch (only adding the flag to the nested
> MSRs)
> good for submitting to stable from your point of view?
>
Yes, it is correct. I forwarded it to stable, thanks.
--
error compiling committee.c: too many argument
On 06.08.2012 16:40, Stefan Bader wrote:
> On 05.08.2012 11:18, Avi Kivity wrote:
>> On 08/03/2012 01:57 PM, Stefan Bader wrote:
No, you're backporting the entire feature. All we need is to expose
RDPMC intercept to the guest.
>>>
>>> Oh well, I thought that was the thing you asked for..
On 05.08.2012 11:18, Avi Kivity wrote:
> On 08/03/2012 01:57 PM, Stefan Bader wrote:
>>> No, you're backporting the entire feature. All we need is to expose
>>> RDPMC intercept to the guest.
>>
>> Oh well, I thought that was the thing you asked for...
>
> Sorry for being unclear.
>
>>
>>> It sho
On 08/03/2012 01:57 PM, Stefan Bader wrote:
>> No, you're backporting the entire feature. All we need is to expose
>> RDPMC intercept to the guest.
>
> Oh well, I thought that was the thing you asked for...
Sorry for being unclear.
>
>> It should be sufficient to backport the bits in
>> nested
> No, you're backporting the entire feature. All we need is to expose
> RDPMC intercept to the guest.
Oh well, I thought that was the thing you asked for...
> It should be sufficient to backport the bits in
> nested_vmx_setup_ctls_msrs() and nested_vmx_exit_handled().
Ok, how about that? It is
On 08/02/2012 06:19 PM, Stefan Bader wrote:
> I started to pick #7 (#6 is in to have things in-sync between
> SVM and VMX). Most other patches then were needed as dependencies.
> The only difference here is #2 which I found being applied together
> with #1 (which is a dependency). Since #2 is rathe
I started to pick #7 (#6 is in to have things in-sync between
SVM and VMX). Most other patches then were needed as dependencies.
The only difference here is #2 which I found being applied together
with #1 (which is a dependency). Since #2 is rather change to add
support than to fix a bug it was app
On 08/01/2012 06:07 PM, Nadav Har'El wrote:
> On Wed, Aug 01, 2012, Avi Kivity wrote about "Re: Nested kvm_intel broken on
> pre 3.3 hosts":
>> Right - it's not just kvm-as-a-guest that will trip on this. But
>> there's no point in everyone backporti
On Wed, Aug 01, 2012 at 06:07:07PM +0300, Nadav Har'El wrote:
> On Wed, Aug 01, 2012, Avi Kivity wrote about "Re: Nested kvm_intel broken on
> pre 3.3 hosts":
> > Right - it's not just kvm-as-a-guest that will trip on this. But
> > there's no point i
On Wed, Aug 01, 2012, Avi Kivity wrote about "Re: Nested kvm_intel broken on
pre 3.3 hosts":
> Right - it's not just kvm-as-a-guest that will trip on this. But
> there's no point in everyone backporting it on their own. If you're
> doing the backport, please po
On 08/01/2012 05:26 PM, Stefan Bader wrote:
>>> According to Intel SDM there was never CPU that didn't support RDPMC
>>> exiting. Looks like unfortunate nested VMX bug.
>>
>> Moreover, that same commit fixes the bug in nested vmx. So if you
>> update your host kernel to the same version as your
On 01.08.2012 16:08, Avi Kivity wrote:
> On 08/01/2012 04:39 PM, Gleb Natapov wrote:
>> On Wed, Aug 01, 2012 at 01:29:11PM +0200, Stefan Bader wrote:
>>> I have been looking at a report[1] about the kvm_intel module failing to
>>> load on
>>> linux v3.3 and newer guests when running on a v3.2 host
On 08/01/2012 04:39 PM, Gleb Natapov wrote:
> On Wed, Aug 01, 2012 at 01:29:11PM +0200, Stefan Bader wrote:
>> I have been looking at a report[1] about the kvm_intel module failing to
>> load on
>> linux v3.3 and newer guests when running on a v3.2 host. Bisection turned up
>> the
>> following pa
On Wed, Aug 01, 2012 at 01:29:11PM +0200, Stefan Bader wrote:
> I have been looking at a report[1] about the kvm_intel module failing to load
> on
> linux v3.3 and newer guests when running on a v3.2 host. Bisection turned up
> the
> following patch:
>
> commit fee84b079d5ddee2247b5c1f53162c330c
14 matches
Mail list logo