Re: [PATCH] KVM: MTRR: fix fixed MTRR segment look up

2015-12-14 Thread Paolo Bonzini


On 14/12/2015 15:39, Alexis D...t wrote:
> It fixes the slow-down of VM running with pci-passthrough, since some MTRR
> range changed from MTRR_TYPE_WRBACK to MTRR_TYPE_UNCACHABLE.
> 
> Fixes: fa61213746a ("KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type")
> Bugzilla: (https://bugzilla.kernel.org/show_bug.cgi?id=107561)
> 
> Signed-off-by: Alexis Dambricourt 
> ---
>  arch/x86/kvm/mtrr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
> index 9e8bf13..adc54e1 100644
> --- a/arch/x86/kvm/mtrr.c
> +++ b/arch/x86/kvm/mtrr.c
> @@ -267,7 +267,7 @@ static int fixed_mtrr_addr_to_seg(u64 addr)
> 
> for (seg = 0; seg < seg_num; seg++) {
> mtrr_seg = _seg_table[seg];
> -   if (mtrr_seg->start >= addr && addr < mtrr_seg->end)
> +   if (mtrr_seg->start <= addr && addr < mtrr_seg->end)

So this if could never be true.

> return seg;
> }
> 
> --
> 

While that's embarrassing, :)  it would only apply to memory in the 640K-1M
range, while the logs in the BZ have

nov 22 17:06:49 Core-i7-5.lan kernel: vmx_get_mt_mask got the following: cpu=6, 
vcpu=0, gfn=67fe00, MMIO=0, cache=0

Note that this is a page above 4GB, which is why in the BZ I thought that
the culprit was MAXPHYADDR (and I still believe it is, at least for the
OVMF case---there are probably two bugs, and your patch fixes one).

Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] KVM: MTRR: fix fixed MTRR segment look up

2015-12-14 Thread Alexis D...t
>From what I see in my case, it was especially gfn from 0x0 to 0xA0
which are deadly impacted by the wrong cache property.

2015-12-14 16:36 GMT+01:00 Paolo Bonzini :
>
>
> On 14/12/2015 15:39, Alexis D...t wrote:
>> It fixes the slow-down of VM running with pci-passthrough, since some MTRR
>> range changed from MTRR_TYPE_WRBACK to MTRR_TYPE_UNCACHABLE.
>>
>> Fixes: fa61213746a ("KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type")
>> Bugzilla: (https://bugzilla.kernel.org/show_bug.cgi?id=107561)
>>
>> Signed-off-by: Alexis Dambricourt 
>> ---
>>  arch/x86/kvm/mtrr.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
>> index 9e8bf13..adc54e1 100644
>> --- a/arch/x86/kvm/mtrr.c
>> +++ b/arch/x86/kvm/mtrr.c
>> @@ -267,7 +267,7 @@ static int fixed_mtrr_addr_to_seg(u64 addr)
>>
>> for (seg = 0; seg < seg_num; seg++) {
>> mtrr_seg = _seg_table[seg];
>> -   if (mtrr_seg->start >= addr && addr < mtrr_seg->end)
>> +   if (mtrr_seg->start <= addr && addr < mtrr_seg->end)
>
> So this if could never be true.
>
>> return seg;
>> }
>>
>> --
>>
>
> While that's embarrassing, :)  it would only apply to memory in the 640K-1M
> range, while the logs in the BZ have
>
> nov 22 17:06:49 Core-i7-5.lan kernel: vmx_get_mt_mask got the following: 
> cpu=6, vcpu=0, gfn=67fe00, MMIO=0, cache=0
>
> Note that this is a page above 4GB, which is why in the BZ I thought that
> the culprit was MAXPHYADDR (and I still believe it is, at least for the
> OVMF case---there are probably two bugs, and your patch fixes one).
>
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] KVM: MTRR: fix fixed MTRR segment look up

2015-12-14 Thread Paolo Bonzini


On 14/12/2015 17:06, Alexis D...t wrote:
> From what I see in my case, it was especially gfn from 0x0 to 0xA0
> which are deadly impacted by the wrong cache property.

Yes, indeed.  I'll send the patch to Linus this week; I've now posted to
the BZ a second patch for GFNs above 4GB.

Paolo

> 2015-12-14 16:36 GMT+01:00 Paolo Bonzini :
>> >
>> >
>> > On 14/12/2015 15:39, Alexis D...t wrote:
>>> >> It fixes the slow-down of VM running with pci-passthrough, since some 
>>> >> MTRR
>>> >> range changed from MTRR_TYPE_WRBACK to MTRR_TYPE_UNCACHABLE.
>>> >>
>>> >> Fixes: fa61213746a ("KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type")
>>> >> Bugzilla: (https://bugzilla.kernel.org/show_bug.cgi?id=107561)
>>> >>
>>> >> Signed-off-by: Alexis Dambricourt 
>>> >> ---
>>> >>  arch/x86/kvm/mtrr.c | 2 +-
>>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
>>> >> index 9e8bf13..adc54e1 100644
>>> >> --- a/arch/x86/kvm/mtrr.c
>>> >> +++ b/arch/x86/kvm/mtrr.c
>>> >> @@ -267,7 +267,7 @@ static int fixed_mtrr_addr_to_seg(u64 addr)
>>> >>
>>> >> for (seg = 0; seg < seg_num; seg++) {
>>> >> mtrr_seg = _seg_table[seg];
>>> >> -   if (mtrr_seg->start >= addr && addr < mtrr_seg->end)
>>> >> +   if (mtrr_seg->start <= addr && addr < mtrr_seg->end)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] KVM: MTRR: fix fixed MTRR segment look up

2015-12-14 Thread Alexis D...t
It fixes the slow-down of VM running with pci-passthrough, since some MTRR
range changed from MTRR_TYPE_WRBACK to MTRR_TYPE_UNCACHABLE.

Fixes: fa61213746a ("KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type")
Bugzilla: (https://bugzilla.kernel.org/show_bug.cgi?id=107561)

Signed-off-by: Alexis Dambricourt 
---
 arch/x86/kvm/mtrr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 9e8bf13..adc54e1 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -267,7 +267,7 @@ static int fixed_mtrr_addr_to_seg(u64 addr)

for (seg = 0; seg < seg_num; seg++) {
mtrr_seg = _seg_table[seg];
-   if (mtrr_seg->start >= addr && addr < mtrr_seg->end)
+   if (mtrr_seg->start <= addr && addr < mtrr_seg->end)
return seg;
}

--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html