Ram Pai <linuxram@xxxxxxxxxx> writes: > On Fri, Mar 16, 2018 at 10:02:22PM +1100, Balbir Singh wrote: >> On Fri, Mar 16, 2018 at 9:33 PM, Ram Pai <linuxram@xxxxxxxxxx> wrote: >> > Applications need the ability to associate an address-range with some >> > key and latter revert to its initial default key. Pkey-0 comes close to >> > providing this function but falls short, because the current >> > implementation disallows applications to explicitly associate pkey-0 to >> > the address range. >> > >> > Clarify the semantics of pkey-0 and provide the corresponding >> > implementation. >> > >> > Pkey-0 is special with the following semantics. >> > (a) it is implicitly allocated and can never be freed. It always exists. >> > (b) it is the default key assigned to any address-range. >> > (c) it can be explicitly associated with any address-range. >> > >> > Tested on powerpc only. Could not test on x86. >> >> Ram, >> >> I was wondering if we should check the AMOR values on the ppc side to make sure >> that pkey0 is indeed available for use as default. I am still of the >> opinion that we > > AMOR cannot be read/written by the OS in priviledge-non-hypervisor-mode. > We could try testing if key-0 is available to the OS by temproarily > changing the bits key-0 bits of AMR or IAMR register. But will be > dangeorous to do, for you might disable read,execute of all the pages, > since all pages are asscoiated with key-0 bydefault. No we should do what firmware tells us. If it says key 0 is available we use it, otherwise we don't. Now if you notice the way the firmware API (device tree property) is defined, it tells us how many keys are available, counting from 0. So for pkey 0 to be reserved there must be 0 keys available. End of story. cheers
