On 2016-03-10 at 12:21 "'Kanoj Sarcar' via Akaros"
<[email protected]> wrote:
> Agreed. Note that I created pat_init() as a routine, that can migrate
> into arch code and be
> invoked from the correct spot. I suggest we integrate the patch as is
> (its just me that is
> probably turning on this support anyway :-)), then transport the
> pat_init() call to a better
> location. See below:
Let me see if I can come up with something that sorts this out.
> So two things: all processors must agree on the setting, and cache/TLB
> flush must happen afterwards.
We actually have a horrendously broken place where we set the MTRRs (it
worked on my nehalem in 2009, but breaks just about everything else).
So this would be an appropriate place to do the PAT work.
> I am just trying to stay as close to Linux as possible. Who knows what
> problems can show
> up with PAT1 != PAT5 or having WT and WC together. Or actually having
> PAT=1 in PTE (which
> Linux has a comment about avoiding from the Intel guys in
> arch/x86/mm/pat.c:pat_init()) :
>
> /* Set PWT to Write-Combining. All other bits stay the same */
> /*
> * PTE encoding used in Linux:
> * PAT
> * |PCD
> * ||PWT
> * |||
> * 000 WB _PAGE_CACHE_WB
> * 001 WC _PAGE_CACHE_WC
> * 010 UC- _PAGE_CACHE_UC_MINUS
> * 011 UC _PAGE_CACHE_UC
> * PAT bit unused
> */
I think they just choose to not use PTE_PAT. I didn't see anything in
the SDM saying we can't use it.
> > > +static unsigned long pgprot_val(int vmprot)
> > > +{
> > > + unsigned long prot = PTE_P | PTE_U | PTE_A;
> > > +
> > > + if (vmprot & PROT_WRITE)
> > > + prot |= PTE_W | PTE_D;
> >
> > Just curious, why are PTE_A and PTE_D set?
> >
> >
> >
> I wanted to avoid the cpu coming and setting those bits. I am not sure
> whether Linux
> does the same for the user level uncached mapping, I could check if
> you think there's
> an issue.
I think the CPU is allowed to write those bits anyways.
My main concern was that this code was trying to do something to trick
the rest of the kernel that these pages were dirtied/accessed, as if
part of a memory management algorithm. That probably won't work with
any code that clears the dirty bit (e.g. a clock algorithm), unless
something somewhere else sets the bits again.
I think it's harmless to set those bits in advance, so no need to
worry. I was just wondering if something magical was going on. =)
> I believe Linux has something similar (Documentation/x86/pat.txt),
> but yes, I am only
> interested in the user address stuff for now.
Sounds good. I'll put together something that should be easy to work
with.
Barret
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
