From: Matt Fleming <matt@codeblueprint.co.uk>
To: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
Cc: Matt Fleming <matt.fleming@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, ying.huang@intel.com, tony.luck@gmail.com,
fu.wei@linaro.org, al.stone@linaro.org, bp@alien8.de,
rjw@rjwysocki.net, catalin.marinas@arm.com, will.deacon@arm.com,
hanjun.guo@linaro.org, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org,
timur@codeaurora.org
Subject: Re: [PATCH V9 2/5] x86: acpi: implement arch_apei_get_mem_attributes()
Date: Mon, 3 Aug 2015 17:22:23 +0100 [thread overview]
Message-ID: <20150803162223.GP2725@codeblueprint.co.uk> (raw)
In-Reply-To: <1438292109-4170-3-git-send-email-zjzhang@codeaurora.org>
On Thu, 30 Jul, at 02:35:06PM, Jonathan (Zhixiong) Zhang wrote:
> From: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
>
> ... to allow arch specific implementation of getting page
> protection type associated with a physical address.
>
> On x86, we currently have no way to lookup the EFI memory map
> attributes for a region in a consistent way because the
> memmap is discarded after efi_free_boot_services(). So if
> you call efi_mem_attributes() during boot and at runtime,
> you could theoretically see different attributes.
>
> Since we are yet to see any x86 platforms that require
> anything other than PAGE_KERNEL (some arm64 platforms
> require the equivalent of PAGE_KERNEL_NOCACHE), return that
> until we know differently.
>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> ---
> arch/x86/kernel/acpi/apei.c | 19 +++++++++++++++++++
> include/acpi/apei.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/x86/kernel/acpi/apei.c b/arch/x86/kernel/acpi/apei.c
> index c280df6b2aa2..675bd46c4e17 100644
> --- a/arch/x86/kernel/acpi/apei.c
> +++ b/arch/x86/kernel/acpi/apei.c
> @@ -60,3 +60,22 @@ void arch_apei_flush_tlb_one(unsigned long addr)
> {
> __flush_tlb_one(addr);
> }
> +
> +static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
> +{
> +
> + /*
> + * We currently have no way to lookup the EFI memory map
> + * attributes for a region in a consistent way because the
> + * memmap is discarded after efi_free_boot_services(). So if
> + * you call efi_mem_attributes() during boot and at runtime,
> + * you could theoretically see different attributes.
> + *
> + * Since we are yet to see any x86 platforms that require
> + * anything other than PAGE_KERNEL (some arm64 platforms
> + * require the equivalent of PAGE_KERNEL_NOCACHE), return that
> + * until we know differently.
> + */
> +
> + return __pgprot(PAGE_KERNEL);
> +}
> diff --git a/include/acpi/apei.h b/include/acpi/apei.h
> index 284801ac7042..64a12ce9880b 100644
> --- a/include/acpi/apei.h
> +++ b/include/acpi/apei.h
> @@ -46,6 +46,7 @@ int erst_clear(u64 record_id);
> int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr, void *data);
> void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err);
> void arch_apei_flush_tlb_one(unsigned long addr);
> +pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
>
> #endif
> #endif
This doesn't compile :(
/home/matt/src/kernels/efi/arch/x86/kernel/acpi/apei.c:64:24: error: static declaration of ‘arch_apei_get_mem_attribute’ follows non-static declaration
static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
^
In file included from /home/matt/src/kernels/efi/arch/x86/kernel/acpi/apei.c:15:0:
/home/matt/src/kernels/efi/include/acpi/apei.h:48:10: note: previous declaration of ‘arch_apei_get_mem_attribute’ was here
pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
^
/home/matt/src/kernels/efi/arch/x86/kernel/acpi/apei.c: In function ‘arch_apei_get_mem_attribute’:
/home/matt/src/kernels/efi/arch/x86/kernel/acpi/apei.c:80:2: error: incompatible types when initializing type ‘long unsigned int’ using type ‘pgprot_t’
return __pgprot(PAGE_KERNEL);
--
Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2015-08-03 16:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 21:35 [PATCH V9 0/5] map GHES memory region according to EFI memory map Jonathan (Zhixiong) Zhang
2015-07-30 21:35 ` Jonathan (Zhixiong) Zhang
2015-07-30 21:35 ` [PATCH V9 1/5] efi: x86: rearrange efi_mem_attributes() Jonathan (Zhixiong) Zhang
2015-07-30 21:35 ` [PATCH V9 2/5] x86: acpi: implement arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-08-03 16:22 ` Matt Fleming [this message]
2015-07-30 21:35 ` [PATCH V9 3/5] arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT Jonathan (Zhixiong) Zhang
2015-07-30 21:35 ` [PATCH V9 4/5] arm64: apei: implement arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-07-30 21:35 ` [PATCH V9 5/5] acpi, apei: use appropriate pgprot_t to map GHES memory Jonathan (Zhixiong) Zhang
2015-08-03 11:26 ` [PATCH V9 0/5] map GHES memory region according to EFI memory map Will Deacon
2015-08-03 11:26 ` Will Deacon
[not found] ` <20150803112658.GE10501-5wv7dgnIgG8@public.gmane.org>
2015-08-03 16:23 ` Matt Fleming
2015-08-03 16:23 ` Matt Fleming
2015-08-04 4:25 ` Borislav Petkov
2015-08-04 4:25 ` Borislav Petkov
2015-08-04 15:41 ` Zhang, Jonathan Zhixiong
2015-08-04 15:41 ` Zhang, Jonathan Zhixiong
[not found] ` <55C0DD30.9070800-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-08-05 9:21 ` Matt Fleming
2015-08-05 9:21 ` Matt Fleming
[not found] ` <20150805092125.GB4332-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-08-05 15:58 ` Zhang, Jonathan Zhixiong
2015-08-05 15:58 ` Zhang, Jonathan Zhixiong
2015-08-05 16:10 ` Matt Fleming
2015-08-05 16:10 ` Matt Fleming
2015-08-05 16:13 ` Matt Fleming
2015-08-05 16:13 ` Matt Fleming
2015-08-06 13:47 ` Zhang, Jonathan Zhixiong
2015-08-06 13:47 ` Zhang, Jonathan Zhixiong
2015-08-05 9:21 ` Matt Fleming
2015-08-05 9:21 ` Matt Fleming
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=20150803162223.GP2725@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=al.stone@linaro.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=fu.wei@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=hpa@zytor.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mingo@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=timur@codeaurora.org \
--cc=tony.luck@gmail.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
--cc=ying.huang@intel.com \
--cc=zjzhang@codeaurora.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.