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
| ||
|
Message-ID: <53CD4EB2.5020709@zytor.com> Date: Mon, 21 Jul 2014 10:32:34 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: Toshi Kani <toshi.kani@...com> CC: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, tglx@...utronix.de, mingo@...hat.com, akpm@...ux-foundation.org, arnd@...db.de, plagnioj@...osoft.com, tomi.valkeinen@...com, linux-mm@...ck.org, linux-kernel@...r.kernel.org, stefan.bader@...onical.com, luto@...capital.net, airlied@...il.com, bp@...en8.de Subject: Re: [RFC PATCH 0/11] Support Write-Through mapping on x86 On 07/21/2014 10:16 AM, Toshi Kani wrote: > > You are right. I was under a wrong impression that > __change_page_attr() always splits a large pages into 4KB pages, but I > overlooked the fact that it can handle a large page as well. So, this > approach does not work... > If it did it would be a major fail. >> I would also like a systematic way to deal with the fact >> that Xen (sigh) is stuck with a separate mapping system. >> >> I guess Linux could adopt the Xen mappings if that makes it easier, as >> long as that doesn't have a negative impact on native hardware -- we can >> possibly deal with some older chips not being optimal. > > I see. I agree that supporting the PAT bit is the right direction, but > I do not know how much effort we need. I will study on this. > >> However, my thinking has been to have a "reverse PAT" table in memory of memory >> types to encodings, both for regular and large pages. > > I am not clear about your idea of the "reverse PAT" table. Would you > care to elaborate? How is it different from using pte_val() being a > paravirt function on Xen? First of all, paravirt functions are the root of all evil, and we want to reduce and eliminate them to the utmost level possible. But yes, we could plumb that up that way if we really need to. What I'm thinking of is a table which can deal with both the moving PTE bit, Xen, and the scattered encodings by having a small table from types to encodings, and not use the encodings directly until fairly late it the pipe. I suspect, but I'm not sure, that we would also need the inverse operation. -hpa -- 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