| Message ID | 20180612143915.68065-17-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h > index efc0d4bb3b35..d6edcabacfc7 100644 > --- a/arch/x86/include/asm/mktme.h > +++ b/arch/x86/include/asm/mktme.h > @@ -43,6 +43,9 @@ void mktme_disable(void); > void setup_direct_mapping_size(void); > int sync_direct_mapping(void); > > +#define page_to_virt(x) \ > + (__va(PFN_PHYS(page_to_pfn(x))) + page_keyid(x) * direct_mapping_size) This looks like a super important memory management function being defined in some obscure Intel-specific feature header. How does that work? > #else > #define mktme_keyid_mask ((phys_addr_t)0) > #define mktme_nr_keyids 0 > diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h > index 53c32af895ab..ffad496aadad 100644 > --- a/arch/x86/include/asm/page_64.h > +++ b/arch/x86/include/asm/page_64.h > @@ -23,7 +23,7 @@ static inline unsigned long __phys_addr_nodebug(unsigned long x) > /* use the carry flag to determine if x was < __START_KERNEL_map */ > x = y + ((x > y) ? phys_base : (__START_KERNEL_map - PAGE_OFFSET)); > > - return x; > + return x % direct_mapping_size; > } What are the performance implications of this patch?
On Wed, Jun 13, 2018 at 06:43:08PM +0000, Dave Hansen wrote: > > diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h > > index efc0d4bb3b35..d6edcabacfc7 100644 > > --- a/arch/x86/include/asm/mktme.h > > +++ b/arch/x86/include/asm/mktme.h > > @@ -43,6 +43,9 @@ void mktme_disable(void); > > void setup_direct_mapping_size(void); > > int sync_direct_mapping(void); > > > > +#define page_to_virt(x) \ > > + (__va(PFN_PHYS(page_to_pfn(x))) + page_keyid(x) * direct_mapping_size) > > This looks like a super important memory management function being > defined in some obscure Intel-specific feature header. How does that work? No magic. It overwrites define in <linux/mm.h>. > > #else > > #define mktme_keyid_mask ((phys_addr_t)0) > > #define mktme_nr_keyids 0 > > diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h > > index 53c32af895ab..ffad496aadad 100644 > > --- a/arch/x86/include/asm/page_64.h > > +++ b/arch/x86/include/asm/page_64.h > > @@ -23,7 +23,7 @@ static inline unsigned long __phys_addr_nodebug(unsigned long x) > > /* use the carry flag to determine if x was < __START_KERNEL_map */ > > x = y + ((x > y) ? phys_base : (__START_KERNEL_map - PAGE_OFFSET)); > > > > - return x; > > + return x % direct_mapping_size; > > } > > What are the performance implications of this patch? Let me collect the numbers.
On 06/18/2018 06:34 AM, Kirill A. Shutemov wrote: > On Wed, Jun 13, 2018 at 06:43:08PM +0000, Dave Hansen wrote: >>> diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h >>> index efc0d4bb3b35..d6edcabacfc7 100644 >>> --- a/arch/x86/include/asm/mktme.h >>> +++ b/arch/x86/include/asm/mktme.h >>> @@ -43,6 +43,9 @@ void mktme_disable(void); >>> void setup_direct_mapping_size(void); >>> int sync_direct_mapping(void); >>> >>> +#define page_to_virt(x) \ >>> + (__va(PFN_PHYS(page_to_pfn(x))) + page_keyid(x) * direct_mapping_size) >> >> This looks like a super important memory management function being >> defined in some obscure Intel-specific feature header. How does that work? > > No magic. It overwrites define in <linux/mm.h>. It frankly looks like magic to me. How can this possibly work without ensuring that asm/mktme.h is #included everywhere on every file compiled for the entire architecture? If we look at every definition of page_to_virt() on every architecture in the kernel, we see it uniquely defined in headers that look rather generic. I don't see any precedent for feature-specific definitions. > arch/arm64/include/asm/memory.h:#define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET)) > arch/hexagon/include/asm/page.h:#define page_to_virt(page) __va(page_to_phys(page)) > arch/m68k/include/asm/page_mm.h:#define page_to_virt(page) ({ \ > arch/m68k/include/asm/page_no.h:#define page_to_virt(page) __va(((((page) - mem_map) << PAGE_SHIFT) + PAGE_OFFSET)) > arch/microblaze/include/asm/page.h:# define page_to_virt(page) __va(page_to_pfn(page) << PAGE_SHIFT) > arch/microblaze/include/asm/page.h:# define page_to_virt(page) (pfn_to_virt(page_to_pfn(page))) > arch/nios2/include/asm/page.h:#define page_to_virt(page) \ > arch/riscv/include/asm/page.h:#define page_to_virt(page) (pfn_to_virt(page_to_pfn(page))) > arch/s390/include/asm/page.h:#define page_to_virt(page) pfn_to_virt(page_to_pfn(page)) > arch/xtensa/include/asm/page.h:#define page_to_virt(page) __va(page_to_pfn(page) << PAGE_SHIFT) *If* you do this, I think it 100% *HAS* to be done in a central header, like x86's page.h. We need a single x86 macro for this, not something which can and will change based on #include ordering and Kconfig.
On Mon, Jun 18, 2018 at 01:59:18PM +0000, Dave Hansen wrote: > On 06/18/2018 06:34 AM, Kirill A. Shutemov wrote: > > On Wed, Jun 13, 2018 at 06:43:08PM +0000, Dave Hansen wrote: > >>> diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h > >>> index efc0d4bb3b35..d6edcabacfc7 100644 > >>> --- a/arch/x86/include/asm/mktme.h > >>> +++ b/arch/x86/include/asm/mktme.h > >>> @@ -43,6 +43,9 @@ void mktme_disable(void); > >>> void setup_direct_mapping_size(void); > >>> int sync_direct_mapping(void); > >>> > >>> +#define page_to_virt(x) \ > >>> + (__va(PFN_PHYS(page_to_pfn(x))) + page_keyid(x) * direct_mapping_size) > >> > >> This looks like a super important memory management function being > >> defined in some obscure Intel-specific feature header. How does that work? > > > > No magic. It overwrites define in <linux/mm.h>. > > It frankly looks like magic to me. How can this possibly work without > ensuring that asm/mktme.h is #included everywhere on every file compiled > for the entire architecture? asm/mktme.h is included from asm/page.h. It is functionally identical other architectures. > If we look at every definition of page_to_virt() on every architecture > in the kernel, we see it uniquely defined in headers that look rather > generic. I don't see any precedent for feature-specific definitions. I do. m68k and microblaze have different definitions of the macro depending on CONFIG_MMU. On arm64 it depends on CONFIG_SPARSEMEM_VMEMMAP. > > arch/arm64/include/asm/memory.h:#define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET)) > > arch/hexagon/include/asm/page.h:#define page_to_virt(page) __va(page_to_phys(page)) > > arch/m68k/include/asm/page_mm.h:#define page_to_virt(page) ({ \ > > arch/m68k/include/asm/page_no.h:#define page_to_virt(page) __va(((((page) - mem_map) << PAGE_SHIFT) + PAGE_OFFSET)) > > arch/microblaze/include/asm/page.h:# define page_to_virt(page) __va(page_to_pfn(page) << PAGE_SHIFT) > > arch/microblaze/include/asm/page.h:# define page_to_virt(page) (pfn_to_virt(page_to_pfn(page))) > > arch/nios2/include/asm/page.h:#define page_to_virt(page) \ > > arch/riscv/include/asm/page.h:#define page_to_virt(page) (pfn_to_virt(page_to_pfn(page))) > > arch/s390/include/asm/page.h:#define page_to_virt(page) pfn_to_virt(page_to_pfn(page)) > > arch/xtensa/include/asm/page.h:#define page_to_virt(page) __va(page_to_pfn(page) << PAGE_SHIFT) > > *If* you do this, I think it 100% *HAS* to be done in a central header, > like x86's page.h. We need a single x86 macro for this, not something > which can and will change based on #include ordering and Kconfig. I don't agree. asm/mktme.h included from the single header -- asm/page.h -- and has clear path to linux/mm.h where the default page_to_virt() is defined. I don't see a reason to move it out of feature-specific header. The default page_to_virt() is perfectly fine without MKTME. And it will be obvious on grep.
diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h index efc0d4bb3b35..d6edcabacfc7 100644 --- a/arch/x86/include/asm/mktme.h +++ b/arch/x86/include/asm/mktme.h @@ -43,6 +43,9 @@ void mktme_disable(void); void setup_direct_mapping_size(void); int sync_direct_mapping(void); +#define page_to_virt(x) \ + (__va(PFN_PHYS(page_to_pfn(x))) + page_keyid(x) * direct_mapping_size) + #else #define mktme_keyid_mask ((phys_addr_t)0) #define mktme_nr_keyids 0 diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h index 53c32af895ab..ffad496aadad 100644 --- a/arch/x86/include/asm/page_64.h +++ b/arch/x86/include/asm/page_64.h @@ -23,7 +23,7 @@ static inline unsigned long __phys_addr_nodebug(unsigned long x) /* use the carry flag to determine if x was < __START_KERNEL_map */ x = y + ((x > y) ? phys_base : (__START_KERNEL_map - PAGE_OFFSET)); - return x; + return x % direct_mapping_size; } #ifdef CONFIG_DEBUG_VIRTUAL
Per-KeyID direct mappings require changes into how we find the right virtual address for a page and virt-to-phys address translations. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> --- arch/x86/include/asm/mktme.h | 3 +++ arch/x86/include/asm/page_64.h | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)