Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753098AbbFCCop (ORCPT ); Tue, 2 Jun 2015 22:44:45 -0400 Received: from mga09.intel.com ([134.134.136.24]:11445 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752992AbbFCCoi (ORCPT ); Tue, 2 Jun 2015 22:44:38 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,544,1427785200"; d="scan'208";a="704340626" Message-ID: <556E692B.6000500@linux.intel.com> Date: Wed, 03 Jun 2015 10:40:43 +0800 From: Xiao Guangrong User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paolo Bonzini CC: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 12/15] KVM: MTRR: introduce mtrr_for_each_mem_type References: <1432983566-15773-1-git-send-email-guangrong.xiao@linux.intel.com> <1432983566-15773-13-git-send-email-guangrong.xiao@linux.intel.com> <556C26D4.6030205@redhat.com> In-Reply-To: <556C26D4.6030205@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2164 Lines: 82 On 06/01/2015 05:33 PM, Paolo Bonzini wrote: > > > On 30/05/2015 12:59, Xiao Guangrong wrote: >> +struct mtrr_looker { >> + /* input fields. */ >> + struct kvm_mtrr *mtrr_state; >> + u64 start; >> + u64 end; > > s/looker/iter/ or s/looker/lookup/ Good to me. > >> +static void mtrr_lookup_start(struct mtrr_looker *looker) >> +{ >> + looker->mem_type = -1; >> + >> + if (!looker->mtrr_state->mtrr_enabled) { >> + looker->partial_map = true; >> + return; >> + } >> + >> + if (!mtrr_lookup_fixed_start(looker)) >> + mtrr_lookup_var_start(looker); >> +} >> + > > Separating mtrr_lookup_start and mtrr_lookup_init is weird. Agreed, will fold mtrr_lookup_start() into mtrr_lookup_init(). > > There are common parts of mtrr_lookup_*_start and mtrr_lookup_*_next. > For example this: > >> + looker->mem_type = looker->mtrr_state->fixed_ranges[index]; >> + looker->start = fixed_mtrr_range_end_addr(seg, index); >> + return true; > > in mtrr_lookup_fixed_start is the same as this: > >> >> + end = fixed_mtrr_range_end_addr(looker->seg, looker->index); >> + >> + /* switch to next segment. */ >> + if (end >= eseg->end) { >> + looker->seg++; >> + looker->index = 0; >> + >> + /* have looked up for all fixed MTRRs. */ >> + if (looker->seg >= ARRAY_SIZE(fixed_seg_table)) >> + return mtrr_lookup_var_start(looker); >> + >> + end = fixed_mtrr_range_end_addr(looker->seg, looker->index); >> + } >> + >> + looker->mem_type = mtrr_state->fixed_ranges[looker->index]; >> + looker->start = end; > > in mtrr_lookup_fixed_next. Can you try to make them more common? Yes, i will check them carefully and introduce common functions to do it. > > Basically you should have > > +#define mtrr_for_each_mem_type(_looker_, _mtrr_, _gpa_start_, _gpa_end_) \ > + for (mtrr_lookup_init(_looker_, _mtrr_, _gpa_start_, _gpa_end_); \ > + !mtrr_lookup_end(_looker_); mtrr_lookup_next(_looker_)) Good idea, will do it in v2. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/