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
| ||
|
Date: Wed, 29 Jun 2011 11:08:07 +0530 From: Suzuki Poulose <suzuki@...ibm.com> To: Sebastian Andrzej Siewior <bigeasy@...utronix.de> CC: "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>, linux ppc dev <linuxppc-dev@...ts.ozlabs.org>, lkml <linux-kernel@...r.kernel.org> Subject: Re: [RFC][PATCH] Kexec support for PPC440x On 06/03/11 19:23, Sebastian Andrzej Siewior wrote: > Suzuki Poulose wrote: >>>> The way you setup the 1:1 mapping should be close to what you are doing on >>>> kernel entry.Isn't it possible to include the file here and in the entry >>>> code? >> >>> I will make this change and resend the patch. >> >> I took a look at the way we do it at kernel entry. It looks more cleaner to leave >> it untouched. Especially, when we add the support for 47x in the future, the code >> will become more unreadable. >> >> What do you think ? > > So the entry code has one 256MiB mapping, you need 8 of those. Entry goes for TLB 63 and you need to be flexible and avoid TLB 63 :). > So after all you don't have that much in common with the entry code. If > you look at the FSL-book code then you will notice that I tried to share > some code. > > I don't understand why you don't flip the address space bit. On fsl we > setup the tmp mapping in the "other address" space so we don't have two > mappings for the same address. The entry code could be doing this with STS > bit, I'm not sure. I am not sure if I understood this correctly. Could you explain how could there be two mappings for the same address ? We are setting up 1:1 mapping for 0-2GiB and the only mapping that could exist (in other words, not invalidated) is PAGE_OFFSET mapping. Since PAGE_OFFSET < 2GiB we won't have multiple mappings. Or in other words we could limit KEXEC_*_MEMORY_LIMIT to PAGE_OFFSET to make sure the crossing doesn't occur. The kernel entry code sets up the mapping without a tmp mapping in 44x. i.e, it uses the mapping setup by the firmware/boot loader. Thanks Suzuki -- 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/
Powered by blists - more mailing lists