linux-kernel - Re: [PATCH part4 2/4] x86, acpica, acpi: Try to find if SRAT is overrided earlier.

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: <5208D4E5.6030808@gmail.com>
Date:	Mon, 12 Aug 2013 20:28:21 +0800
From:	Tang Chen <imtangchen@...il.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Tang Chen <tangchen@...fujitsu.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Bob Moore <robert.moore@...el.com>,
	Lv Zheng <lv.zheng@...el.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <lenb@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Thomas Renninger <trenn@...e.de>,
	Jiang Liu <jiang.liu@...wei.com>,
	Zhang Yanfei <zhangyanfei@...fujitsu.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH part4 2/4] x86, acpica, acpi: Try to find if SRAT is overrided
 earlier.

On 08/10/2013 07:34 AM, Yinghai Lu wrote:
> On Fri, Aug 9, 2013 at 2:41 AM, Tang Chen<tangchen@...fujitsu.com>  wrote:
>> On 08/09/2013 12:29 AM, Yinghai Lu wrote:
>> ......
>>
>>>
>>> Please check if you can reuse first half of my patchset, so find and copy
>>> override table earlier. the copied acpi tables could be near kernel code
>>> range.
>>>
>>
>> I don't think we need to do the finding step at that early time, in
>> head64.c stage.
>>
>> Before pagetables are setup, we can use early_ioremap() to map the
>> memory we want to access. We don't need to use phys addr. We can do
>> it in setup_arch(), which has nothing to do with 32bit or 64bit.
>
> if override the acpi tables early, you don't need to check firmware srat and
> then override srat.
> just check last one will be used by kernel.
>
> So you don't need to dig initrd to find srat anymore.

The current logic is find tables in firmware, and override them. I
don't think it is a big deal.

Even if we want to override first, and then skip the table in
firmware (install one time), we still don't need to do it in head64.c,
right ?

>
>>
>>
>>> Move finding in head64.c stage could help xen/dom0 a bit.
>>> as Konrad is working on patchset with acpi override in xen hypervisor.
>>> We can avoid override acpi table two times. Esp xen like to change
>>> DMAR to XMAR.
>>
>>
>> Would you please give some more info about this, and explain why finding
>> override tables in head64.c stage is helpful for xen ?
>
> xen usually can change acpi tables and pass to dom0 kernel. like change DMAR
> to hide it to dom0 kernel.
>
> also distribution could have same kernel to support bare metal and dom0.
>
> so if we find the override kernel early in head64.c, dom0 path will not copy
> actually as no one try to find that for them.
>

I don't know the detail, but seeing from your description, doing
override in head64.c may avoid a copy. If doing such a copy in xen
is not that difficult, I think we can do it for now. Modifying
acpi_initrd_override() logic will need to modify a lot of things.

Just like the local node pagetable, I think it is better to do
xen things after memory hotplug is done.

Thanks.

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