linux-kernel - Re: [PATCH V2 3/3] acpi, apei: use EFI memmap to map GHES memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150605102556.GC3679@pd.tnic>
Date:	Fri, 5 Jun 2015 12:25:56 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Matt Fleming <matt@...eblueprint.co.uk>
Cc:	"Jonathan (Zhixiong) Zhang" <zjzhang@...eaurora.org>,
	rjw@...ysocki.net, lenb@...nel.org, ying.huang@...el.com,
	leif.lindholm@...aro.org, al.stone@...aro.org, fu.wei@...aro.org,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linaro-acpi@...ts.linaro.org,
	vgandhi@...eaurora.org, Tony Luck <tony.luck@...il.com>
Subject: Re: [PATCH V2 3/3] acpi, apei: use EFI memmap to map GHES memory

On Fri, Jun 05, 2015 at 10:57:01AM +0100, Matt Fleming wrote:
> [ Cc'ing Boris and Tony. Folks original patch is here,
>   https://lkml.kernel.org/r/1433185940-24770-4-git-send-email-zjzhang@codeaurora.org ]
> 
> On Mon, 01 Jun, at 12:12:20PM, Jonathan (Zhixiong) Zhang wrote:
> > From: "Jonathan (Zhixiong) Zhang" <zjzhang@...eaurora.org>
> > 
> > With ACPI APEI firmware first handling, generic hardware error
> > record is updated by firmware in GHES memory region. When firmware
> > updated GHES memory region in DDR without going through cache,

What is DDR?

I think this needs to be clarified first before we go any further.

I picked up on the sidelines that this might be arm64-specific stuff. If
so, your approach is wrong: you're merging efi_* facilities from x86 and
ia64 into generic efi ones but then doing CONFIG_EFI ifdeffery in GHES.

What you should do instead is have arch-specific:

ghes_ioremap_pfn_irq()
ghes_iounmap_irq()
...

and whatever else functionality which is different on your arch and
which get called from the generic ghes.c driver.

In the arch-specific ones you can go wild with the ifdeffery and whatnot
is needed on that specific arch.

Something like that, at least.

-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/