On 27/11/15 09:51, Huaitong Han wrote: > Changes in v2: > *Rebase all patches in staging branch > *Disable X86_CR4_PKE on hypervisor, and delete pkru_read/write functions, and > use xsave state read to get pkru value. > *Delete the patch that adds pkeys support for do_page_fault. > *Add pkeys support for gva2gfn so that setting _PAGE_PK_BIT in the return > value can get propagated to the guest correctly. > > The protection-key feature provides an additional mechanism by which IA-32e > paging controls access to usermode addresses. > > Hardware support for protection keys for user pages is enumerated with CPUID > feature flag CPUID.7.0.ECX[3]:PKU. Software support is CPUID.7.0.ECX[4]:OSPKE > with the setting of CR4.PKE(bit 22). > > When CR4.PKE = 1, every linear address is associated with the 4-bit protection > key located in bits 62:59 of the paging-structure entry that mapped the page > containing the linear address. The PKRU register determines, for each > protection key, whether user-mode addresses with that protection key may be > read or written. > > The PKRU register (protection key rights for user pages) is a 32-bit register > with the following format: for each i (0 ≤ i ≤ 15), PKRU[2i] is the > access-disable bit for protection key i (ADi); PKRU[2i+1] is the write-disable > bit for protection key i (WDi). > > Software can use the RDPKRU and WRPKRU instructions with ECX = 0 to read and > write PKRU. In addition, the PKRU register is XSAVE-managed state and can thus > be read and written by instructions in the XSAVE feature set. > > PFEC.PK (bit 5) is defined as protection key violations. > > The specification of Protection Keys can be found at SDM (4.6.2, volume 3) > http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf.
Just for my own understand, do you have a sample use-case for protection keys? As everything can WRPKRU, I cant see how it would actually be useful. Clearly there is a usecase or you (Intel) wouldn't have gone to the effort of putting into silicon. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel