On Wed, 2014-07-16 at 15:28 -0600, Toshi Kani wrote: > On Tue, 2014-07-15 at 20:40 -0400, Konrad Rzeszutek Wilk wrote: > > On July 15, 2014 5:23:24 PM EDT, Toshi Kani wrote: > > >On Tue, 2014-07-15 at 13:09 -0700, H. Peter Anvin wrote: > > >> On 07/15/2014 12:34 PM, Toshi Kani wrote: > : > > >> > > >> I have given this piece of feedback at least three times now, > > >possibly > > >> to different people, and I'm getting a bit grumpy about it: > > >> > > >> We already have an issue with Xen, because Xen assigned mappings > > >> differently and it is incompatible with the use of PAT in Linux. As > > >a > > >> result we get requests for hacks to work around this, which is > > >something > > >> I really don't want to see. I would like to see a design involving a > > >> "reverse PAT" table where the kernel can hold the mapping between > > >memory > > >> types and page table encodings (including the two different ones for > > >> small and large pages.) > > > > > >Thanks for pointing this out! (And sorry for making you repeat it three > > >time...) I was not aware of the issue with Xen. I will look into the > > >email archive to see what the Xen issue is, and how it can be > > >addressed. > > > > https://lkml.org/lkml/2011/11/8/406 > > Thanks Konrad for the pointer! > > Since [__]change_page_attr_set_clr() and __change_page_attr() have no > knowledge about PAT and simply work with specified PTE flags, they do > not seem to fit well with additional PAT abstraction table... > > I think the root of this issue is that the kernel ignores the PAT bit. > Since __change_page_attr() only supports 4K pages, set_memory_() > can set the PAT bit into the clear mask. > > Attached is a patch with this approach (apply on top of this series - > not tested). The kernel still does not support the PAT bit, but it > behaves slightly better. Hi Peter, Konrad, Do you have any comments / suggestions for this approach? Thanks! -Toshi