Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1199110 > unrolled thread

Re: [PATCH v3 24/24] pmem: convert to generic memremap

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 24/24] pmem: convert to generic memremap Ross Zwisler <ross.zwisler@linux.intel.com> - 2015-08-03 19:30 +0200
    Re: [PATCH v3 24/24] pmem: convert to generic memremap Dan Williams <dan.j.williams@intel.com> - 2015-08-03 20:10 +0200
      Re: [PATCH v3 24/24] pmem: convert to generic memremap Ross Zwisler <ross.zwisler@linux.intel.com> - 2015-08-04 19:00 +0200

#1199110 — Re: [PATCH v3 24/24] pmem: convert to generic memremap

On Thu, 2015-07-30 at 12:55 -0400, Dan Williams wrote:
> Update memremap_pmem() to query the architecture for the mapping type of
> the given persistent memory range  and then pass those flags to generic
> memremap().  arch_memremap_pmem_flags() is provided an address range to
> evaluate in the event an arch has a need for different mapping types by
> address range.  For example the ACPI NFIT carries EFI mapping types in
> its memory range description table.
> 
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  arch/x86/include/asm/io.h |    2 +-
>  arch/x86/mm/ioremap.c     |   16 ++++++++++------
>  include/linux/pmem.h      |   26 +++++++++++++++-----------
>  3 files changed, 26 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 1a9d44ee9ed0..26c81b01419c 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -245,7 +245,7 @@ static inline void flush_write_buffers(void)
>  #endif
>  }
>  
> -void __pmem *arch_memremap_pmem(resource_size_t offset, size_t size);
> +unsigned long arch_memremap_pmem_flags(resource_size_t offset, size_t size);
>  #endif /* __KERNEL__ */
>  
>  extern void native_io_delay(void);
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index ffbfcf2e701b..5a41e3e4ea1e 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -205,6 +205,16 @@ err_free_memtype:
>  	return NULL;
>  }
>  
> +unsigned long arch_memremap_pmem_flags(resource_size_t offset, size_t size)
> +{
> +	/*
> +	 * TODO: check the mapping type provided by platform firmware,
> +	 * per range.
> +	 */
> +	return MEMREMAP_WB;
> +}
> +EXPORT_SYMBOL(arch_memremap_pmem_flags);

I'm not sure that the architecture code has the right information to be able
to tell the caller what the correct mapping is.

I think what you are ultimately looking for is the "Address Range Memory
Mapping Attribute" found in the System Physical Address Range Structure of the
NFIT, right?  (ACPI 6.0, table 5-128)  How can we get to that structure from
nfit-independent architecture code like arch_memremap_pmem_flags()?  It seems
like that if we want to make the mapping type dynamic we should get the flags
from ND when the SPA range is provided by ND, and provide a reasonable default
(WB, it seems) when we are dealing with legacy PMEM?  If PMEM had the flag
from whatever source, it could then pass it in to memremap_pmem(), and get a
mapping of the appropriate caching.

Another option of course is to just ignore the mapping attribute in the NFIT
like we've been doing, and just say "we know WB will be good enough", and
remove the TODO.


--
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/

[toc] | [next] | [standalone]

#1199137

On Mon, Aug 3, 2015 at 10:21 AM, Ross Zwisler
<ross.zwisler@linux.intel.com> wrote:
> On Thu, 2015-07-30 at 12:55 -0400, Dan Williams wrote:
>> Update memremap_pmem() to query the architecture for the mapping type of
>> the given persistent memory range  and then pass those flags to generic
>> memremap().  arch_memremap_pmem_flags() is provided an address range to
>> evaluate in the event an arch has a need for different mapping types by
>> address range.  For example the ACPI NFIT carries EFI mapping types in
>> its memory range description table.
>>
>> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> ---
>>  arch/x86/include/asm/io.h |    2 +-
>>  arch/x86/mm/ioremap.c     |   16 ++++++++++------
>>  include/linux/pmem.h      |   26 +++++++++++++++-----------
>>  3 files changed, 26 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
>> index 1a9d44ee9ed0..26c81b01419c 100644
>> --- a/arch/x86/include/asm/io.h
>> +++ b/arch/x86/include/asm/io.h
>> @@ -245,7 +245,7 @@ static inline void flush_write_buffers(void)
>>  #endif
>>  }
>>
>> -void __pmem *arch_memremap_pmem(resource_size_t offset, size_t size);
>> +unsigned long arch_memremap_pmem_flags(resource_size_t offset, size_t size);
>>  #endif /* __KERNEL__ */
>>
>>  extern void native_io_delay(void);
>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
>> index ffbfcf2e701b..5a41e3e4ea1e 100644
>> --- a/arch/x86/mm/ioremap.c
>> +++ b/arch/x86/mm/ioremap.c
>> @@ -205,6 +205,16 @@ err_free_memtype:
>>       return NULL;
>>  }
>>
>> +unsigned long arch_memremap_pmem_flags(resource_size_t offset, size_t size)
>> +{
>> +     /*
>> +      * TODO: check the mapping type provided by platform firmware,
>> +      * per range.
>> +      */
>> +     return MEMREMAP_WB;
>> +}
>> +EXPORT_SYMBOL(arch_memremap_pmem_flags);
>
> I'm not sure that the architecture code has the right information to be able
> to tell the caller what the correct mapping is.
>

It does in this instance as it has to pick a mapping type that is
compatible with memcpy_to_pmem() and wmb_pmem().

> I think what you are ultimately looking for is the "Address Range Memory
> Mapping Attribute" found in the System Physical Address Range Structure of the
> NFIT, right?  (ACPI 6.0, table 5-128)  How can we get to that structure from
> nfit-independent architecture code like arch_memremap_pmem_flags()?  It seems
> like that if we want to make the mapping type dynamic we should get the flags
> from ND when the SPA range is provided by ND, and provide a reasonable default
> (WB, it seems) when we are dealing with legacy PMEM?  If PMEM had the flag
> from whatever source, it could then pass it in to memremap_pmem(), and get a
> mapping of the appropriate caching.

We can do what ioremap() does and look it up through other means.

> Another option of course is to just ignore the mapping attribute in the NFIT
> like we've been doing, and just say "we know WB will be good enough", and
> remove the TODO.

I agree, but there may be a non-zero chance that a platform
implementation wants strict adherence.  Maybe move the TODO to a
dev_dbg() that flags platforms where the NFIT mapping type is not
"WB"?
--
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/

[toc] | [prev] | [next] | [standalone]

#1200164

On Mon, 2015-08-03 at 11:01 -0700, Dan Williams wrote:
> On Mon, Aug 3, 2015 at 10:21 AM, Ross Zwisler
> <ross.zwisler@linux.intel.com> wrote:
> > On Thu, 2015-07-30 at 12:55 -0400, Dan Williams wrote:
> >> Update memremap_pmem() to query the architecture for the mapping type of
> >> the given persistent memory range  and then pass those flags to generic
> >> memremap().  arch_memremap_pmem_flags() is provided an address range to
> >> evaluate in the event an arch has a need for different mapping types by
> >> address range.  For example the ACPI NFIT carries EFI mapping types in
> >> its memory range description table.
> >>
> >> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> >> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>


--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web