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

Groups > linux.kernel > #1198755 > unrolled thread

Re: [PATCH V9 0/5] map GHES memory region according to EFI memory map

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 V9 0/5] map GHES memory region according to EFI memory map Will Deacon <will.deacon@arm.com> - 2015-08-03 13:30 +0200
    Re: [PATCH V9 0/5] map GHES memory region according to EFI memory map Matt Fleming <matt@codeblueprint.co.uk> - 2015-08-03 18:30 +0200
      Re: [PATCH V9 0/5] map GHES memory region according to EFI memory map Borislav Petkov <bp@alien8.de> - 2015-08-04 06:30 +0200

#1198755 — Re: [PATCH V9 0/5] map GHES memory region according to EFI memory map

Hi Jonathan,

On Thu, Jul 30, 2015 at 10:35:04PM +0100, Jonathan (Zhixiong) Zhang wrote:
> From: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
> 
> On a platform with APEI (ACPI Platform Error Interface) enabled, firmware
> updates a memory region with hardware error record using nocache
> attribute. When OS reads the region, since it maps the region with
> cacahed attribute even though EFI memory map defines this region as
> uncached, OS gets stale data and errorneously reports there is no new
> HW error.
> 
> When ghes driver maps the memory region, it uses the cache attribute
> according to EFI memory map, if EFI memory map feature is enabled
> at runtime.
> 
> Since both arch/x86 and arch/ia64 implemented architecture agnostic EFI
> memory map attribue lookup function efi_memattributes(), the code is
> moved from arch/x86 into EFI subsystem and is declared as __weak; archs
> other than ia64 should not override the default implementation.
> 
> V9:
> 1. Rebased to arm64-upstream-14543 of arm64/master.
> 2. Match strict MM type in arch_apei_get_mem_attribute().

I guess this is all going via Matt's tree? I'm happy to take the new
memory type in arch/arm64/ if there's nothing currently queued, but I
suspect it makes more sense for it to stay together.

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

#1199023

On Mon, 03 Aug, at 12:26:58PM, Will Deacon wrote:
> 
> I guess this is all going via Matt's tree? I'm happy to take the new
> memory type in arch/arm64/ if there's nothing currently queued, but I
> suspect it makes more sense for it to stay together.

Right, it probably does make sense to take this through a single tree.

I'm still waiting for the ACPI folks to chime in on whether this series
makes sense, and in particular I'd like to hear from people that have
touched ghes.c in the past.

Rafael, Boris?

-- 
Matt Fleming, Intel Open Source Technology Center
--
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]

#1199405

On Mon, Aug 03, 2015 at 05:23:54PM +0100, Matt Fleming wrote:
> Rafael, Boris?

The ghes.c change looks fine I guess. The whole patchset makes sense
now, with the arch bits extracted. So

Acked-by: Borislav Petkov <bp@suse.de>

However, we probably should work towards adhering to EFI memory
attributes on x86, long term, as we talked. But that's a future thing.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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