From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Alexis D...t" Subject: Re: [PATCH] KVM: MTRR: fix fixed MTRR segment look up Date: Mon, 14 Dec 2015 17:06:18 +0100 Message-ID: References: <566EE1FB.8050708@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: kvm@vger.kernel.org To: Paolo Bonzini Return-path: Received: from mail-ig0-f178.google.com ([209.85.213.178]:35093 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751654AbbLNQGj (ORCPT ); Mon, 14 Dec 2015 11:06:39 -0500 Received: by mail-ig0-f178.google.com with SMTP id to4so8079842igc.0 for ; Mon, 14 Dec 2015 08:06:38 -0800 (PST) In-Reply-To: <566EE1FB.8050708@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: >>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 = &fixed_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