From: Ingo Molnar <mingo@kernel.org>
To: Toshi Kani <toshi.kani@hp.com>
Cc: akpm@linux-foundation.org, hpa@zytor.com, tglx@linutronix.de,
mingo@redhat.com, linux-mm@kvack.org, x86@kernel.org,
linux-kernel@vger.kernel.org, dave.hansen@intel.com,
Elliott@hp.com, pebolle@tiscali.nl
Subject: Re: [PATCH v2 3/4] mtrr, x86: Clean up mtrr_type_lookup()
Date: Fri, 13 Mar 2015 13:37:23 +0100 [thread overview]
Message-ID: <20150313123722.GA4152@gmail.com> (raw)
In-Reply-To: <1426180690-24234-4-git-send-email-toshi.kani@hp.com>
* Toshi Kani <toshi.kani@hp.com> wrote:
> MTRRs contain fixed and variable entries. mtrr_type_lookup()
> may repeatedly call __mtrr_type_lookup() to handle a request
> that overlaps with variable entries. However,
> __mtrr_type_lookup() also handles the fixed entries and other
> conditions, which do not have to be repeated. This patch moves
> such code from __mtrr_type_lookup() to mtrr_type_lookup().
>
> This patch also changes the 'else if (start < 0x1000000)',
> which checks a fixed range but has an extra zero in the address,
> to 'else' with no condition.
>
> Lastly, the patch updates the function headers to clarify the
> return values and output argument. It also updates comments to
> clarify that the repeating is necessary to handle overlaps with
> the default type, since overlaps with multiple entries alone
> can be handled without such repeating.
>
> There is no functional change in this patch.
>
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>
> ---
> arch/x86/kernel/cpu/mtrr/generic.c | 102 +++++++++++++++++++-----------------
> 1 file changed, 53 insertions(+), 49 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
> index a82e370..ef34a4f 100644
> --- a/arch/x86/kernel/cpu/mtrr/generic.c
> +++ b/arch/x86/kernel/cpu/mtrr/generic.c
> @@ -102,12 +102,16 @@ static int check_type_overlap(u8 *prev, u8 *curr)
> return 0;
> }
>
> -/*
> - * Error/Semi-error returns:
> - * 0xFF - when MTRR is not enabled
> - * *repeat == 1 implies [start:end] spanned across MTRR range and type returned
> - * corresponds only to [start:*partial_end].
> - * Caller has to lookup again for [*partial_end:end].
> +/**
> + * __mtrr_type_lookup - look up memory type in MTRR variable entries
> + *
> + * Return Value:
> + * memory type - Matched memory type or the default memory type (unmatched)
> + *
> + * Output Argument:
> + * repeat - Set to 1 when [start:end] spanned across MTRR range and type
> + * returned corresponds only to [start:*partial_end]. Caller has
> + * to lookup again for [*partial_end:end].
> */
> static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)
> {
> @@ -116,42 +120,10 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)
> u8 prev_match, curr_match;
>
> *repeat = 0;
> - if (!mtrr_state_set)
> - return 0xFF;
> -
> - if (!mtrr_state.enabled)
> - return 0xFF;
>
> /* Make end inclusive end, instead of exclusive */
> end--;
>
> - /* Look in fixed ranges. Just return the type as per start */
> - if (mtrr_state.have_fixed && (start < 0x100000)) {
> - int idx;
> -
> - if (start < 0x80000) {
> - idx = 0;
> - idx += (start >> 16);
> - return mtrr_state.fixed_ranges[idx];
> - } else if (start < 0xC0000) {
> - idx = 1 * 8;
> - idx += ((start - 0x80000) >> 14);
> - return mtrr_state.fixed_ranges[idx];
> - } else if (start < 0x1000000) {
> - idx = 3 * 8;
> - idx += ((start - 0xC0000) >> 12);
> - return mtrr_state.fixed_ranges[idx];
> - }
> - }
> -
> - /*
> - * Look in variable ranges
> - * Look of multiple ranges matching this address and pick type
> - * as per MTRR precedence
> - */
> - if (!(mtrr_state.enabled & 2))
> - return mtrr_state.def_type;
> -
> prev_match = 0xFF;
> for (i = 0; i < num_var_ranges; ++i) {
> unsigned short start_state, end_state, inclusive;
> @@ -180,7 +152,8 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)
> * Return the type for first region and a pointer to
> * the start of second region so that caller will
> * lookup again on the second region.
> - * Note: This way we handle multiple overlaps as well.
> + * Note: This way we handle overlaps with multiple
> + * entries and the default type properly.
> */
> if (start_state)
> *partial_end = base + get_mtrr_size(mask);
> @@ -209,21 +182,18 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)
> return curr_match;
> }
>
> - if (mtrr_tom2) {
> - if (start >= (1ULL<<32) && (end < mtrr_tom2))
> - return MTRR_TYPE_WRBACK;
> - }
> -
> if (prev_match != 0xFF)
> return prev_match;
>
> return mtrr_state.def_type;
> }
>
> -/*
> - * Returns the effective MTRR type for the region
> - * Error return:
> - * 0xFF - when MTRR is not enabled
> +/**
> + * mtrr_type_lookup - look up memory type in MTRR
> + *
> + * Return Values:
> + * memory type - The effective MTRR type for the region
> + * 0xFF - MTRR is disabled
> */
> u8 mtrr_type_lookup(u64 start, u64 end)
> {
> @@ -231,12 +201,43 @@ u8 mtrr_type_lookup(u64 start, u64 end)
> int repeat;
> u64 partial_end;
>
> + if (!mtrr_state_set || !mtrr_state.enabled)
> + return 0xFF;
> +
> + /* Look in fixed ranges. Just return the type as per start */
> + if (mtrr_state.have_fixed && (start < 0x100000)) {
> + int idx;
> +
> + if (start < 0x80000) {
> + idx = 0;
> + idx += (start >> 16);
> + return mtrr_state.fixed_ranges[idx];
> + } else if (start < 0xC0000) {
> + idx = 1 * 8;
> + idx += ((start - 0x80000) >> 14);
> + return mtrr_state.fixed_ranges[idx];
> + } else {
> + idx = 3 * 8;
> + idx += ((start - 0xC0000) >> 12);
> + return mtrr_state.fixed_ranges[idx];
> + }
> + }
So why not put this into a separate helper function - named
mtrr_type_lookup_fixed()? It has little relation to variable ranges.
> +
> + /*
> + * Look in variable ranges
> + * Look of multiple ranges matching this address and pick type
> + * as per MTRR precedence
> + */
> + if (!(mtrr_state.enabled & 2))
> + return mtrr_state.def_type;
> +
> type = __mtrr_type_lookup(start, end, &partial_end, &repeat);
And this then should be named mtrr_type_lookup_variable() or so?
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Toshi Kani <toshi.kani@hp.com>
Cc: akpm@linux-foundation.org, hpa@zytor.com, tglx@linutronix.de,
mingo@redhat.com, linux-mm@kvack.org, x86@kernel.org,
linux-kernel@vger.kernel.org, dave.hansen@intel.com,
Elliott@hp.com, pebolle@tiscali.nl
Subject: Re: [PATCH v2 3/4] mtrr, x86: Clean up mtrr_type_lookup()
Date: Fri, 13 Mar 2015 13:37:23 +0100 [thread overview]
Message-ID: <20150313123722.GA4152@gmail.com> (raw)
In-Reply-To: <1426180690-24234-4-git-send-email-toshi.kani@hp.com>
* Toshi Kani <toshi.kani@hp.com> wrote:
> MTRRs contain fixed and variable entries. mtrr_type_lookup()
> may repeatedly call __mtrr_type_lookup() to handle a request
> that overlaps with variable entries. However,
> __mtrr_type_lookup() also handles the fixed entries and other
> conditions, which do not have to be repeated. This patch moves
> such code from __mtrr_type_lookup() to mtrr_type_lookup().
>
> This patch also changes the 'else if (start < 0x1000000)',
> which checks a fixed range but has an extra zero in the address,
> to 'else' with no condition.
>
> Lastly, the patch updates the function headers to clarify the
> return values and output argument. It also updates comments to
> clarify that the repeating is necessary to handle overlaps with
> the default type, since overlaps with multiple entries alone
> can be handled without such repeating.
>
> There is no functional change in this patch.
>
> Signed-off-by: Toshi Kani <toshi.kani@hp.com>
> ---
> arch/x86/kernel/cpu/mtrr/generic.c | 102 +++++++++++++++++++-----------------
> 1 file changed, 53 insertions(+), 49 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
> index a82e370..ef34a4f 100644
> --- a/arch/x86/kernel/cpu/mtrr/generic.c
> +++ b/arch/x86/kernel/cpu/mtrr/generic.c
> @@ -102,12 +102,16 @@ static int check_type_overlap(u8 *prev, u8 *curr)
> return 0;
> }
>
> -/*
> - * Error/Semi-error returns:
> - * 0xFF - when MTRR is not enabled
> - * *repeat == 1 implies [start:end] spanned across MTRR range and type returned
> - * corresponds only to [start:*partial_end].
> - * Caller has to lookup again for [*partial_end:end].
> +/**
> + * __mtrr_type_lookup - look up memory type in MTRR variable entries
> + *
> + * Return Value:
> + * memory type - Matched memory type or the default memory type (unmatched)
> + *
> + * Output Argument:
> + * repeat - Set to 1 when [start:end] spanned across MTRR range and type
> + * returned corresponds only to [start:*partial_end]. Caller has
> + * to lookup again for [*partial_end:end].
> */
> static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)
> {
> @@ -116,42 +120,10 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)
> u8 prev_match, curr_match;
>
> *repeat = 0;
> - if (!mtrr_state_set)
> - return 0xFF;
> -
> - if (!mtrr_state.enabled)
> - return 0xFF;
>
> /* Make end inclusive end, instead of exclusive */
> end--;
>
> - /* Look in fixed ranges. Just return the type as per start */
> - if (mtrr_state.have_fixed && (start < 0x100000)) {
> - int idx;
> -
> - if (start < 0x80000) {
> - idx = 0;
> - idx += (start >> 16);
> - return mtrr_state.fixed_ranges[idx];
> - } else if (start < 0xC0000) {
> - idx = 1 * 8;
> - idx += ((start - 0x80000) >> 14);
> - return mtrr_state.fixed_ranges[idx];
> - } else if (start < 0x1000000) {
> - idx = 3 * 8;
> - idx += ((start - 0xC0000) >> 12);
> - return mtrr_state.fixed_ranges[idx];
> - }
> - }
> -
> - /*
> - * Look in variable ranges
> - * Look of multiple ranges matching this address and pick type
> - * as per MTRR precedence
> - */
> - if (!(mtrr_state.enabled & 2))
> - return mtrr_state.def_type;
> -
> prev_match = 0xFF;
> for (i = 0; i < num_var_ranges; ++i) {
> unsigned short start_state, end_state, inclusive;
> @@ -180,7 +152,8 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)
> * Return the type for first region and a pointer to
> * the start of second region so that caller will
> * lookup again on the second region.
> - * Note: This way we handle multiple overlaps as well.
> + * Note: This way we handle overlaps with multiple
> + * entries and the default type properly.
> */
> if (start_state)
> *partial_end = base + get_mtrr_size(mask);
> @@ -209,21 +182,18 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)
> return curr_match;
> }
>
> - if (mtrr_tom2) {
> - if (start >= (1ULL<<32) && (end < mtrr_tom2))
> - return MTRR_TYPE_WRBACK;
> - }
> -
> if (prev_match != 0xFF)
> return prev_match;
>
> return mtrr_state.def_type;
> }
>
> -/*
> - * Returns the effective MTRR type for the region
> - * Error return:
> - * 0xFF - when MTRR is not enabled
> +/**
> + * mtrr_type_lookup - look up memory type in MTRR
> + *
> + * Return Values:
> + * memory type - The effective MTRR type for the region
> + * 0xFF - MTRR is disabled
> */
> u8 mtrr_type_lookup(u64 start, u64 end)
> {
> @@ -231,12 +201,43 @@ u8 mtrr_type_lookup(u64 start, u64 end)
> int repeat;
> u64 partial_end;
>
> + if (!mtrr_state_set || !mtrr_state.enabled)
> + return 0xFF;
> +
> + /* Look in fixed ranges. Just return the type as per start */
> + if (mtrr_state.have_fixed && (start < 0x100000)) {
> + int idx;
> +
> + if (start < 0x80000) {
> + idx = 0;
> + idx += (start >> 16);
> + return mtrr_state.fixed_ranges[idx];
> + } else if (start < 0xC0000) {
> + idx = 1 * 8;
> + idx += ((start - 0x80000) >> 14);
> + return mtrr_state.fixed_ranges[idx];
> + } else {
> + idx = 3 * 8;
> + idx += ((start - 0xC0000) >> 12);
> + return mtrr_state.fixed_ranges[idx];
> + }
> + }
So why not put this into a separate helper function - named
mtrr_type_lookup_fixed()? It has little relation to variable ranges.
> +
> + /*
> + * Look in variable ranges
> + * Look of multiple ranges matching this address and pick type
> + * as per MTRR precedence
> + */
> + if (!(mtrr_state.enabled & 2))
> + return mtrr_state.def_type;
> +
> type = __mtrr_type_lookup(start, end, &partial_end, &repeat);
And this then should be named mtrr_type_lookup_variable() or so?
Thanks,
Ingo
next prev parent reply other threads:[~2015-03-13 12:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-12 17:18 [PATCH v2 0/4] mtrr, mm, x86: Enhance MTRR checks for huge I/O mapping Toshi Kani
2015-03-12 17:18 ` Toshi Kani
2015-03-12 17:18 ` [PATCH v2 1/4] mm, x86: Document return values of mapping funcs Toshi Kani
2015-03-12 17:18 ` Toshi Kani
2015-03-12 17:18 ` [PATCH v2 2/4] mtrr, x86: Fix MTRR lookup to handle inclusive entry Toshi Kani
2015-03-12 17:18 ` Toshi Kani
2015-03-12 17:18 ` [PATCH v2 3/4] mtrr, x86: Clean up mtrr_type_lookup() Toshi Kani
2015-03-12 17:18 ` Toshi Kani
2015-03-13 12:37 ` Ingo Molnar [this message]
2015-03-13 12:37 ` Ingo Molnar
2015-03-13 13:53 ` Toshi Kani
2015-03-13 13:53 ` Toshi Kani
2015-03-12 17:18 ` [PATCH v2 4/4] mtrr, mm, x86: Enhance MTRR checks for KVA huge page mapping Toshi Kani
2015-03-12 17:18 ` Toshi Kani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150313123722.GA4152@gmail.com \
--to=mingo@kernel.org \
--cc=Elliott@hp.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=pebolle@tiscali.nl \
--cc=tglx@linutronix.de \
--cc=toshi.kani@hp.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.