All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Juergen Gross <jgross@suse.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org
Subject: Re: [Patch V6 12/16] mm: provide early_memremap_ro to establish read-only mapping
Date: Thu, 6 Aug 2015 14:46:51 +0200	[thread overview]
Message-ID: <55C3573B.6020509@suse.cz> (raw)
In-Reply-To: <1437108697-4115-13-git-send-email-jgross@suse.com>

On 07/17/2015 06:51 AM, Juergen Gross wrote:
> During early boot as Xen pv domain the kernel needs to map some page
> tables supplied by the hypervisor read only. This is needed to be
> able to relocate some data structures conflicting with the physical
> memory map especially on systems with huge RAM (above 512GB).
>
> Provide the function early_memremap_ro() to provide this read only
> mapping.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-mm@kvack.org
> Cc: linux-arch@vger.kernel.org
> ---
>   include/asm-generic/early_ioremap.h |  2 ++
>   include/asm-generic/fixmap.h        |  3 +++
>   mm/early_ioremap.c                  | 12 ++++++++++++
>   3 files changed, 17 insertions(+)
>
> diff --git a/include/asm-generic/early_ioremap.h b/include/asm-generic/early_ioremap.h
> index a5de55c..316bd04 100644
> --- a/include/asm-generic/early_ioremap.h
> +++ b/include/asm-generic/early_ioremap.h
> @@ -11,6 +11,8 @@ extern void __iomem *early_ioremap(resource_size_t phys_addr,
>   				   unsigned long size);
>   extern void *early_memremap(resource_size_t phys_addr,
>   			    unsigned long size);
> +extern void *early_memremap_ro(resource_size_t phys_addr,
> +			       unsigned long size);

So the function is declared unconditionally...

>   extern void early_iounmap(void __iomem *addr, unsigned long size);
>   extern void early_memunmap(void *addr, unsigned long size);
>
> diff --git a/include/asm-generic/fixmap.h b/include/asm-generic/fixmap.h
> index f23174f..1cbb833 100644
> --- a/include/asm-generic/fixmap.h
> +++ b/include/asm-generic/fixmap.h
> @@ -46,6 +46,9 @@ static inline unsigned long virt_to_fix(const unsigned long vaddr)
>   #ifndef FIXMAP_PAGE_NORMAL
>   #define FIXMAP_PAGE_NORMAL PAGE_KERNEL
>   #endif
> +#if !defined(FIXMAP_PAGE_RO) && defined(PAGE_KERNEL_RO)
> +#define FIXMAP_PAGE_RO PAGE_KERNEL_RO
> +#endif
>   #ifndef FIXMAP_PAGE_NOCACHE
>   #define FIXMAP_PAGE_NOCACHE PAGE_KERNEL_NOCACHE
>   #endif
> diff --git a/mm/early_ioremap.c b/mm/early_ioremap.c
> index e10ccd2..0cfadaf 100644
> --- a/mm/early_ioremap.c
> +++ b/mm/early_ioremap.c
> @@ -217,6 +217,13 @@ early_memremap(resource_size_t phys_addr, unsigned long size)
>   	return (__force void *)__early_ioremap(phys_addr, size,
>   					       FIXMAP_PAGE_NORMAL);
>   }
> +#ifdef FIXMAP_PAGE_RO
> +void __init *
> +early_memremap_ro(resource_size_t phys_addr, unsigned long size)
> +{
> +	return (__force void *)__early_ioremap(phys_addr, size, FIXMAP_PAGE_RO);
> +}
> +#endif

... here we provide a implementation when both CONFIG_MMU and 
FIXMAP_PAGE_RO are defined...

>   #else /* CONFIG_MMU */
>
>   void __init __iomem *
> @@ -231,6 +238,11 @@ early_memremap(resource_size_t phys_addr, unsigned long size)
>   {
>   	return (void *)phys_addr;
>   }
> +void __init *
> +early_memremap_ro(resource_size_t phys_addr, unsigned long size)
> +{
> +	return (void *)phys_addr;
> +}

... and here for !CONFIG_MMU.

So, what about CONFIG_MMU && !FIXMAP_PAGE_RO combinations? Which 
translates to CONFIG_MMU && !PAGE_KERNEL_RO. Maybe they don't exist, but 
then it's still awkward to see the combination in the code left 
unimplemented.

Would it be perhaps simpler to assume the same thing as in
drivers/base/firmware_class.c ?

/* Some architectures don't have PAGE_KERNEL_RO */
#ifndef PAGE_KERNEL_RO
#define PAGE_KERNEL_RO PAGE_KERNEL
#endif

Or would it be dangerous here to silently lose the read-only protection?

>
>   void __init early_iounmap(void __iomem *addr, unsigned long size)
>   {
>

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Juergen Gross <jgross@suse.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org
Subject: Re: [Patch V6 12/16] mm: provide early_memremap_ro to establish read-only mapping
Date: Thu, 6 Aug 2015 14:46:51 +0200	[thread overview]
Message-ID: <55C3573B.6020509@suse.cz> (raw)
In-Reply-To: <1437108697-4115-13-git-send-email-jgross@suse.com>

On 07/17/2015 06:51 AM, Juergen Gross wrote:
> During early boot as Xen pv domain the kernel needs to map some page
> tables supplied by the hypervisor read only. This is needed to be
> able to relocate some data structures conflicting with the physical
> memory map especially on systems with huge RAM (above 512GB).
>
> Provide the function early_memremap_ro() to provide this read only
> mapping.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Acked-by: Konrad Rzeszutek Wilk <Konrad.wilk@oracle.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-mm@kvack.org
> Cc: linux-arch@vger.kernel.org
> ---
>   include/asm-generic/early_ioremap.h |  2 ++
>   include/asm-generic/fixmap.h        |  3 +++
>   mm/early_ioremap.c                  | 12 ++++++++++++
>   3 files changed, 17 insertions(+)
>
> diff --git a/include/asm-generic/early_ioremap.h b/include/asm-generic/early_ioremap.h
> index a5de55c..316bd04 100644
> --- a/include/asm-generic/early_ioremap.h
> +++ b/include/asm-generic/early_ioremap.h
> @@ -11,6 +11,8 @@ extern void __iomem *early_ioremap(resource_size_t phys_addr,
>   				   unsigned long size);
>   extern void *early_memremap(resource_size_t phys_addr,
>   			    unsigned long size);
> +extern void *early_memremap_ro(resource_size_t phys_addr,
> +			       unsigned long size);

So the function is declared unconditionally...

>   extern void early_iounmap(void __iomem *addr, unsigned long size);
>   extern void early_memunmap(void *addr, unsigned long size);
>
> diff --git a/include/asm-generic/fixmap.h b/include/asm-generic/fixmap.h
> index f23174f..1cbb833 100644
> --- a/include/asm-generic/fixmap.h
> +++ b/include/asm-generic/fixmap.h
> @@ -46,6 +46,9 @@ static inline unsigned long virt_to_fix(const unsigned long vaddr)
>   #ifndef FIXMAP_PAGE_NORMAL
>   #define FIXMAP_PAGE_NORMAL PAGE_KERNEL
>   #endif
> +#if !defined(FIXMAP_PAGE_RO) && defined(PAGE_KERNEL_RO)
> +#define FIXMAP_PAGE_RO PAGE_KERNEL_RO
> +#endif
>   #ifndef FIXMAP_PAGE_NOCACHE
>   #define FIXMAP_PAGE_NOCACHE PAGE_KERNEL_NOCACHE
>   #endif
> diff --git a/mm/early_ioremap.c b/mm/early_ioremap.c
> index e10ccd2..0cfadaf 100644
> --- a/mm/early_ioremap.c
> +++ b/mm/early_ioremap.c
> @@ -217,6 +217,13 @@ early_memremap(resource_size_t phys_addr, unsigned long size)
>   	return (__force void *)__early_ioremap(phys_addr, size,
>   					       FIXMAP_PAGE_NORMAL);
>   }
> +#ifdef FIXMAP_PAGE_RO
> +void __init *
> +early_memremap_ro(resource_size_t phys_addr, unsigned long size)
> +{
> +	return (__force void *)__early_ioremap(phys_addr, size, FIXMAP_PAGE_RO);
> +}
> +#endif

... here we provide a implementation when both CONFIG_MMU and 
FIXMAP_PAGE_RO are defined...

>   #else /* CONFIG_MMU */
>
>   void __init __iomem *
> @@ -231,6 +238,11 @@ early_memremap(resource_size_t phys_addr, unsigned long size)
>   {
>   	return (void *)phys_addr;
>   }
> +void __init *
> +early_memremap_ro(resource_size_t phys_addr, unsigned long size)
> +{
> +	return (void *)phys_addr;
> +}

... and here for !CONFIG_MMU.

So, what about CONFIG_MMU && !FIXMAP_PAGE_RO combinations? Which 
translates to CONFIG_MMU && !PAGE_KERNEL_RO. Maybe they don't exist, but 
then it's still awkward to see the combination in the code left 
unimplemented.

Would it be perhaps simpler to assume the same thing as in
drivers/base/firmware_class.c ?

/* Some architectures don't have PAGE_KERNEL_RO */
#ifndef PAGE_KERNEL_RO
#define PAGE_KERNEL_RO PAGE_KERNEL
#endif

Or would it be dangerous here to silently lose the read-only protection?

>
>   void __init early_iounmap(void __iomem *addr, unsigned long size)
>   {
>

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

  parent reply	other threads:[~2015-08-06 12:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-17  4:51 [Patch V6 00/16] xen: support pv-domains larger than 512GB Juergen Gross
2015-07-17  4:51 ` [Patch V6 01/16] xen: sync with xen headers Juergen Gross
2015-07-17  4:51 ` [Patch V6 02/16] xen: save linear p2m list address in shared info structure Juergen Gross
2015-07-17  4:51 ` [Patch V6 03/16] xen: don't build mfn tree if tools don't need it Juergen Gross
2015-07-17  4:51 ` [Patch V6 04/16] xen: eliminate scalability issues from initial mapping setup Juergen Gross
2015-07-17  4:51 ` [Patch V6 05/16] xen: move static e820 map to global scope Juergen Gross
2015-07-17  4:51 ` [Patch V6 06/16] xen: split counting of extra memory pages from remapping Juergen Gross
2015-07-17  4:51 ` [Patch V6 07/16] xen: check memory area against e820 map Juergen Gross
2015-07-17  4:51 ` [Patch V6 08/16] xen: find unused contiguous memory area Juergen Gross
2015-07-17  4:51 ` [Patch V6 09/16] xen: check for kernel memory conflicting with memory layout Juergen Gross
2015-07-17  4:51 ` [Patch V6 10/16] xen: check pre-allocated page tables for conflict with memory map Juergen Gross
2015-07-17  4:51 ` [Patch V6 11/16] xen: check for initrd conflicting with e820 map Juergen Gross
2015-07-17  4:51 ` [Patch V6 12/16] mm: provide early_memremap_ro to establish read-only mapping Juergen Gross
2015-07-17  4:51   ` Juergen Gross
2015-07-21  4:49   ` Juergen Gross
2015-07-21  4:49     ` Juergen Gross
2015-07-29  9:20     ` Juergen Gross
2015-07-29  9:20       ` Juergen Gross
2015-08-05 11:16       ` Juergen Gross
2015-08-05 11:16         ` Juergen Gross
2015-08-06 12:46   ` Vlastimil Babka [this message]
2015-08-06 12:46     ` Vlastimil Babka
2015-08-06 13:02     ` Juergen Gross
2015-08-06 13:02       ` Juergen Gross
2015-08-06 13:08       ` Vlastimil Babka
2015-08-06 13:08         ` Vlastimil Babka
2015-07-17  4:51 ` [Patch V6 13/16] xen: add explicit memblock_reserve() calls for special pages Juergen Gross
2015-07-17  4:51 ` [Patch V6 14/16] xen: move p2m list if conflicting with e820 map Juergen Gross
2015-07-17  4:51 ` [Patch V6 15/16] xen: allow more than 512 GB of RAM for 64 bit pv-domains Juergen Gross
2015-07-17  4:51 ` [Patch V6 16/16] xen: remove no longer needed p2m.h Juergen Gross
2015-07-20 12:14 ` [Xen-devel] [Patch V6 00/16] xen: support pv-domains larger than 512GB David Vrabel
2015-07-20 12:14   ` David Vrabel
2015-08-06 13:59 ` David Vrabel
2015-08-06 13:59   ` David Vrabel

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=55C3573B.6020509@suse.cz \
    --to=vbabka@suse.cz \
    --cc=arnd@arndb.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=xen-devel@lists.xensource.com \
    /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.