All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: "Zhang, Jonathan Zhixiong" <zjzhang@codeaurora.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>, Fu Wei <fu.wei@linaro.org>,
	Al Stone <al.stone@linaro.org>, Borislav Petkov <bp@alien8.de>,
	Matt Fleming <matt.fleming@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Hanjun Guo <hanjun.guo@linaro.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linaro ACPI Mailman List <linaro-acpi@lists.linaro.org>,
	Timur Tabi <timur@codeaurora.org>
Subject: Re: [PATCH V10 4/5] arm64: apei: implement arch_apei_get_mem_attributes()
Date: Sat, 8 Aug 2015 10:11:44 +0200	[thread overview]
Message-ID: <CAKv+Gu_kuzLf5hSH5KSsZ0cCY1auyzvtWDD6YdLb9bgApj1-Dg@mail.gmail.com> (raw)
In-Reply-To: <20150807185738.GF2625@codeblueprint.co.uk>

On 7 August 2015 at 20:57, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Fri, 07 Aug, at 11:16:03AM, Zhang, Jonathan Zhixiong wrote:
>>
>> On some (future) arm64 platforms, APEI/GHES region may have full
>> coherent access by platform. In such case, the APEI/GHES region have
>> the same memory attributes as the rest of system RAM, such region
>> do not need to be advised by UEFI as separate entry, but as part of
>> system RAM memory region.
>> That being said, for arm64 platforms that do not have WB capability
>> for APEI/GHES region, such region should be mapped accordingly.
>
> OK, so what I need to know right now is whether I need to drop this
> entire series from my pull request or whether you can send a patch on
> top of the existing ones in the EFI 'next' branch to address the mapping
> heuristic in arch_apei_get_mem_attributes().
>
>> >>Jonathan, can you please provide the EFI memory map region attributes
>> >>for the GHES region that requires this series?
>> [Reserved           |   |  |  |  |   |  |  |  |UC]
>
> Assuming this memmap entry is indicative of most GHES region on arm64
> right now, I think it's worth taking this patch as-is and addressing the
> issue Ard raised as a separate patch.
>
> Does that work?
>

I think that is fine.

So we'll expect two patches on top of Matt's -next branch:
- one that removes the redundant __pgprot
- one that inverts the order in which the memory attributes are tested

It would be good to have these in the same release so that the
behavior does not change between releases.

Thanks,
Ard.

  reply	other threads:[~2015-08-08  8:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 13:40 [PATCH V10 0/5] map GHES memory region according to EFI memory map Jonathan (Zhixiong) Zhang
2015-08-06 13:40 ` [PATCH V10 1/5] efi: x86: rearrange efi_mem_attributes() Jonathan (Zhixiong) Zhang
2015-08-06 13:40 ` [PATCH V10 2/5] x86: acpi: implement arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-08-06 13:40 ` [PATCH V10 3/5] arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT Jonathan (Zhixiong) Zhang
2015-08-06 13:40 ` [PATCH V10 4/5] arm64: apei: implement arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-08-07  9:00   ` Ard Biesheuvel
2015-08-07  9:37     ` Matt Fleming
2015-08-07  9:50       ` Ard Biesheuvel
2015-08-07 18:16         ` Zhang, Jonathan Zhixiong
2015-08-07 18:57           ` Matt Fleming
2015-08-08  8:11             ` Ard Biesheuvel [this message]
2015-08-08 16:34               ` Zhang, Jonathan Zhixiong
2015-08-07 17:40     ` Zhang, Jonathan Zhixiong
2015-08-07 18:50       ` Matt Fleming
2015-08-06 13:40 ` [PATCH V10 5/5] acpi, apei: use appropriate pgprot_t to map GHES memoryTo: Matt Fleming <matt.fleming@intel.com>, Thomas Gleixner <tglx@linutronix.de>, fu.wei@linaro.org, al.stone@linaro.org, bp@alien8.de, tony.luck@gmail.com, hanjun.guo@linaro.org rjw@rjwysocki.net, lenb@kernel.org, ying.huang@intel.com, catalin.marinas@arm.com, will.deacon@arm.com Jonathan (Zhixiong) Zhang
2015-08-06 13:40   ` Jonathan (Zhixiong) Zhang

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=CAKv+Gu_kuzLf5hSH5KSsZ0cCY1auyzvtWDD6YdLb9bgApj1-Dg@mail.gmail.com \
    --to=ard.biesheuvel@linaro.org \
    --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=leif.lindholm@linaro.org \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=rjw@rjwysocki.net \
    --cc=timur@codeaurora.org \
    --cc=will.deacon@arm.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.