search for: pud

On Thu, 16 Nov 2006 00:16:26 +0100 Adrian Bunk <bunk@stusta.de> wrote: > Paravirt breaks CONFIG_X86_PAE=y compilation: > > <-- snip --> > > ... > CC init/main.o > In file included from include2/asm/pgtable.h:245, > from > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40, > from >

On Thu, 16 Nov 2006 00:16:26 +0100 Adrian Bunk <bunk@stusta.de> wrote: > Paravirt breaks CONFIG_X86_PAE=y compilation: > > <-- snip --> > > ... > CC init/main.o > In file included from include2/asm/pgtable.h:245, > from > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40, > from >

...using a larger page size. Without > this information, the caller can't safely use a large device PTE to map > the compound page because the CPU might be using smaller PTEs with > different read/write permissions. > > Add two new output flags to indicate the mapping size (PMD or PUD sized) > so that callers know the pages are being mapped with consistent permissions > and a large device page table mapping can be used if one is available. The problem I have with this is that PTE/PMD/PUD are not the only choices for how the CPU might choose to map something. For example,...

...page is mapped by the CPU using a larger page size. Without this information, the caller can't safely use a large device PTE to map the compound page because the CPU might be using smaller PTEs with different read/write permissions. Add two new output flags to indicate the mapping size (PMD or PUD sized) so that callers know the pages are being mapped with consistent permissions and a large device page table mapping can be used if one is available. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- include/linux/hmm.h | 11 ++++++++++- mm/hmm.c | 13 +++++++++++--...

...device page table mapping if one is available. > > > > But what size should the caller use? > > > > You already explained that the caller cannot use compound_ordet() to > > get the size, so what should it be? > > > > Probably this needs to be two flags, PUD and PMD, and the caller should > > use the PUD and PMD sizes to figure out how big it is? > > > > Jason > > > > I guess I didn't explain it as clearly as I thought. :-) > > The page size *can* be determined with compound_order(page) but without the > f...

..._PAGES); + + +static void hvvm_pte_unmap(pmd_t *pmd, unsigned long addr) +{ + pte_t *pte; + pte_t ptent; + + pte = pte_offset_kernel(pmd, addr); + ptent = ptep_get_and_clear(&init_mm, addr, pte); + WARN_ON(!pte_none(ptent) && !pte_present(ptent)); +} + +static inline void hvvm_pmd_unmap(pud_t *pud, unsigned long addr) +{ + pmd_t *pmd; + + pmd = pmd_offset(pud, addr); + if (pmd_none_or_clear_bad(pmd)) + return; + hvvm_pte_unmap(pmd, addr); +} + +static inline void hvvm_pud_unmap(pgd_t *pgd, unsigned long addr) +{ + pud_t *pud; + + pud = pud_offset(pgd, addr); + if (pud_none_or_clear_b...

..._PAGES); + + +static void hvvm_pte_unmap(pmd_t *pmd, unsigned long addr) +{ + pte_t *pte; + pte_t ptent; + + pte = pte_offset_kernel(pmd, addr); + ptent = ptep_get_and_clear(&init_mm, addr, pte); + WARN_ON(!pte_none(ptent) && !pte_present(ptent)); +} + +static inline void hvvm_pmd_unmap(pud_t *pud, unsigned long addr) +{ + pmd_t *pmd; + + pmd = pmd_offset(pud, addr); + if (pmd_none_or_clear_bad(pmd)) + return; + hvvm_pte_unmap(pmd, addr); +} + +static inline void hvvm_pud_unmap(pgd_t *pgd, unsigned long addr) +{ + pud_t *pud; + + pud = pud_offset(pgd, addr); + if (pud_none_or_clear_b...

I''m sure everyone has seen the drop of VMI patches for Linux at this point, but just in case, the link is included below. I''ve read this version of the VMI spec and have made my way through most of the patches. While I wasn''t really that impressed with the first spec wrt Xen, the second version seems to be much more palatable. Specifically, the code inlining and

We only need the special pud_entry walker if PUD-sized hugepages and pte mappings are supported, else the common pagewalk code will take care of the iteration. Not implementing this callback reduced the amount of code compiled for non-x86 platforms, and also fixes compile failures with other architectures when helpers like pu...

...g to indicate this so that callers know it is safe to > use a large device page table mapping if one is available. But what size should the caller use? You already explained that the caller cannot use compound_ordet() to get the size, so what should it be? Probably this needs to be two flags, PUD and PMD, and the caller should use the PUD and PMD sizes to figure out how big it is? Jason

...clude/asm-x86_64/page.h +++ clean-start/include/asm-x86_64/page.h @@ -64,16 +64,44 @@ typedef struct { unsigned long pgd; } pg typedef struct { unsigned long pgprot; } pgprot_t; +static inline unsigned long native_pte_val(pte_t pte) +{ + return pte.pte; +} + +static inline unsigned long native_pud_val(pud_t pud) +{ + return pud.pud; +} + + +static inline unsigned long native_pmd_val(pmd_t pmd) +{ + return pmd.pmd; +} + +static inline unsigned long native_pgd_val(pgd_t pgd) +{ + return pgd.pgd; +} + + +#ifdef CONFIG_PARAVIRT +#include <asm/paravirt.h> +#else + #define pte_val(x) ((x).p...

...clude/asm-x86_64/page.h +++ clean-start/include/asm-x86_64/page.h @@ -64,16 +64,44 @@ typedef struct { unsigned long pgd; } pg typedef struct { unsigned long pgprot; } pgprot_t; +static inline unsigned long native_pte_val(pte_t pte) +{ + return pte.pte; +} + +static inline unsigned long native_pud_val(pud_t pud) +{ + return pud.pud; +} + + +static inline unsigned long native_pmd_val(pmd_t pmd) +{ + return pmd.pmd; +} + +static inline unsigned long native_pgd_val(pgd_t pgd) +{ + return pgd.pgd; +} + + +#ifdef CONFIG_PARAVIRT +#include <asm/paravirt.h> +#else + #define pte_val(x) ((x).p...

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

static pmd_t * __init one_md_table_init(pgd_t *pgd) { pud_t *pud; pmd_t *pmd_table; #ifdef CONFIG_X86_PAE pmd_table = (pmd_t *) alloc_bootmem_low_pages(PAGE_SIZE); paravirt_alloc_pmd(__pa(page_table) >> PAGE_SHIFT); ^^^^^^^^^^ pmd_table? set_pgd(pgd, __pgd(__pa(pmd_table) | _PAGE_PRESENT)); pud = pud_offset(pg...

static pmd_t * __init one_md_table_init(pgd_t *pgd) { pud_t *pud; pmd_t *pmd_table; #ifdef CONFIG_X86_PAE pmd_table = (pmd_t *) alloc_bootmem_low_pages(PAGE_SIZE); paravirt_alloc_pmd(__pa(page_table) >> PAGE_SHIFT); ^^^^^^^^^^ pmd_table? set_pgd(pgd, __pgd(__pa(pmd_table) | _PAGE_PRESENT)); pud = pud_offset(pg...

When operating on an unpinned pagetable (ie, one under construction or destruction), it isn''t necessary to use a hypercall to update a pud/pmd entry. Jan Beulich observed that a similar optimisation avoided many thousands of hypercalls while doing a kernel build. One tricky part is that early in the kernel boot there''s no page structure, so we can''t check to see if the page is pinned. In that case, we just always...

This series contain fixes to make the paravirt_ops code compile and boot on x86_64. This is a follow-up for the previous series from Glauber.

This series contain fixes to make the paravirt_ops code compile and boot on x86_64. This is a follow-up for the previous series from Glauber.

...rmware.c | 743 ++++++++++++++++++++++++++++++++++ kernel/kexec.c | 46 ++- 20 files changed, 2331 insertions(+), 18 deletions(-) Daniel Kiper (11): kexec: introduce kexec firmware support x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE xen: Introduce architecture independent data for kexec/kdump x86/xen: Introduce architecture dependent data for kexec/kdump x86/xen: Register resources required by kexec-tools x86/xen: Add i386 kexec/kdump implementation x86/xen: Add x86_64 kexec/kdump imp...