search for: split_large_page

...te: > On 4/15/20 8:53 AM, Joerg Roedel wrote: > > Hi Mike, > > > > On Tue, Apr 14, 2020 at 07:03:44PM +0000, Mike Stunes wrote: > > > set_memory_decrypted needs to check the return value. I see it > > > consistently return ENOMEM. I've traced that back to split_large_page > > > in arch/x86/mm/pat/set_memory.c. > > > > I agree that the return code needs to be checked. But I wonder why this > > happens. The split_large_page() function returns -ENOMEM when > > alloc_pages() fails. Do you boot the guest with minal RAM assigned? > &gt...

...crypted((unsigned long)ghcb, >> + sizeof(*ghcb) >> PAGE_SHIFT); >> + memset(ghcb, 0, sizeof(*ghcb)); >> + } >> +} >> + > > set_memory_decrypted needs to check the return value. I see it > consistently return ENOMEM. I've traced that back to split_large_page > in arch/x86/mm/pat/set_memory.c. At that point the guest won't be able to communicate with the hypervisor, too. Maybe we should BUG() here to terminate further processing? Thanks, Tom >

...crypted((unsigned long)ghcb, >> + sizeof(*ghcb) >> PAGE_SHIFT); >> + memset(ghcb, 0, sizeof(*ghcb)); >> + } >> +} >> + > > set_memory_decrypted needs to check the return value. I see it > consistently return ENOMEM. I've traced that back to split_large_page > in arch/x86/mm/pat/set_memory.c. At that point the guest won't be able to communicate with the hypervisor, too. Maybe we should BUG() here to terminate further processing? Thanks, Tom >

On 4/14/20 3:12 PM, Dave Hansen wrote: > On 4/14/20 1:04 PM, Tom Lendacky wrote: >>> set_memory_decrypted needs to check the return value. I see it >>> consistently return ENOMEM. I've traced that back to split_large_page >>> in arch/x86/mm/pat/set_memory.c. >> >> At that point the guest won't be able to communicate with the >> hypervisor, too. Maybe we should BUG() here to terminate further >> processing? > > Escalating an -ENOMEM into a crashed kernel seems a bit extreme...

Hi Mike, On Tue, Apr 14, 2020 at 07:03:44PM +0000, Mike Stunes wrote: > set_memory_decrypted needs to check the return value. I see it > consistently return ENOMEM. I've traced that back to split_large_page > in arch/x86/mm/pat/set_memory.c. I agree that the return code needs to be checked. But I wonder why this happens. The split_large_page() function returns -ENOMEM when alloc_pages() fails. Do you boot the guest with minal RAM assigned? Regards, Joerg

...arch/i386/mm/pageattr.c 2005-08-31 14:41:49.000000000 -0700 @@ -33,7 +33,7 @@ pte_t *lookup_address(unsigned long addr return NULL; if (pmd_large(*pmd)) return (pte_t *)pmd; - return pte_offset_kernel(pmd, address); + return pte_offset_kernel(pmd, address); } static struct page *split_large_page(unsigned long address, pgprot_t prot) @@ -54,8 +54,8 @@ static struct page *split_large_page(uns pbase = (pte_t *)page_address(base); SetPagePTE(virt_to_page(pbase)); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { - set_pte(&pbase[i], pfn_pte(addr >> PAGE_S...

...arch/i386/mm/pageattr.c 2005-08-31 14:41:49.000000000 -0700 @@ -33,7 +33,7 @@ pte_t *lookup_address(unsigned long addr return NULL; if (pmd_large(*pmd)) return (pte_t *)pmd; - return pte_offset_kernel(pmd, address); + return pte_offset_kernel(pmd, address); } static struct page *split_large_page(unsigned long address, pgprot_t prot) @@ -54,8 +54,8 @@ static struct page *split_large_page(uns pbase = (pte_t *)page_address(base); SetPagePTE(virt_to_page(pbase)); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { - set_pte(&pbase[i], pfn_pte(addr >> PAGE_S...

...nux-2.6.13/arch/i386/mm/pageattr.c =================================================================== --- linux-2.6.13.orig/arch/i386/mm/pageattr.c 2005-08-24 09:31:05.000000000 -0700 +++ linux-2.6.13/arch/i386/mm/pageattr.c 2005-08-24 09:31:31.000000000 -0700 @@ -52,8 +52,9 @@ static struct page *split_large_page(uns address = __pa(address); addr = address & LARGE_PAGE_MASK; pbase = (pte_t *)page_address(base); + SetPagePTE(virt_to_page(pbase)); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { - set_pte(&pbase[i], pfn_pte(addr >> PAGE_SHIFT, + set_pte(&pba...

...nux-2.6.13/arch/i386/mm/pageattr.c =================================================================== --- linux-2.6.13.orig/arch/i386/mm/pageattr.c 2005-08-24 09:31:05.000000000 -0700 +++ linux-2.6.13/arch/i386/mm/pageattr.c 2005-08-24 09:31:31.000000000 -0700 @@ -52,8 +52,9 @@ static struct page *split_large_page(uns address = __pa(address); addr = address & LARGE_PAGE_MASK; pbase = (pte_t *)page_address(base); + SetPagePTE(virt_to_page(pbase)); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { - set_pte(&pbase[i], pfn_pte(addr >> PAGE_SHIFT, + set_pte(&pba...

On 4/14/20 1:04 PM, Tom Lendacky wrote: >> set_memory_decrypted needs to check the return value. I see it >> consistently return ENOMEM. I've traced that back to split_large_page >> in arch/x86/mm/pat/set_memory.c. > > At that point the guest won't be able to communicate with the > hypervisor, too. Maybe we should BUG() here to terminate further > processing? Escalating an -ENOMEM into a crashed kernel seems a bit extreme. Granted, the guest may be i...

...e) | _PAGE_PRESENT)); +#else + paravirt_alloc_pd(__pa(swapper_pg_dir) >> PAGE_SHIFT); #endif /* Enable PSE if available */ =================================================================== --- a/arch/i386/mm/pageattr.c +++ b/arch/i386/mm/pageattr.c @@ -60,6 +60,7 @@ static struct page *split_large_page(uns address = __pa(address); addr = address & LARGE_PAGE_MASK; pbase = (pte_t *)page_address(base); + paravirt_alloc_pt(page_to_pfn(base)); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { set_pte(&pbase[i], pfn_pte(addr >> PAGE_SHIFT,...

...e) | _PAGE_PRESENT)); +#else + paravirt_alloc_pd(__pa(swapper_pg_dir) >> PAGE_SHIFT); #endif /* Enable PSE if available */ =================================================================== --- a/arch/i386/mm/pageattr.c +++ b/arch/i386/mm/pageattr.c @@ -60,6 +60,7 @@ static struct page *split_large_page(uns address = __pa(address); addr = address & LARGE_PAGE_MASK; pbase = (pte_t *)page_address(base); + paravirt_alloc_pt(page_to_pfn(base)); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { set_pte(&pbase[i], pfn_pte(addr >> PAGE_SHIFT,...

...e) | _PAGE_PRESENT)); +#else + paravirt_alloc_pd(__pa(swapper_pg_dir) >> PAGE_SHIFT); #endif /* Enable PSE if available */ =================================================================== --- a/arch/i386/mm/pageattr.c +++ b/arch/i386/mm/pageattr.c @@ -60,6 +60,7 @@ static struct page *split_large_page(uns address = __pa(address); addr = address & LARGE_PAGE_MASK; pbase = (pte_t *)page_address(base); + paravirt_alloc_pt(page_to_pfn(base)); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { set_pte(&pbase[i], pfn_pte(addr >> PAGE_SHIFT,...

...e) | _PAGE_PRESENT)); +#else + paravirt_alloc_pd(__pa(swapper_pg_dir) >> PAGE_SHIFT); #endif /* Enable PSE if available */ =================================================================== --- a/arch/i386/mm/pageattr.c +++ b/arch/i386/mm/pageattr.c @@ -60,6 +60,7 @@ static struct page *split_large_page(uns address = __pa(address); addr = address & LARGE_PAGE_MASK; pbase = (pte_t *)page_address(base); + paravirt_alloc_pt(page_to_pfn(base)); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { set_pte(&pbase[i], pfn_pte(addr >> PAGE_SHIFT,...

Is there any real use in having a ctor/dtor for the pgd cache? Given that all pgd allocation happens via pgd_alloc/pgd_free, why not just fold the [cd]tor in? I'm asking because Xen wants pgd[3] to be unshared in the PAE case, and it looks to me like the easiest way to handle that is by making pgd_alloc/free pv-ops and doing the appropriate thing in the Xen code. Would need to sort out the

Is there any real use in having a ctor/dtor for the pgd cache? Given that all pgd allocation happens via pgd_alloc/pgd_free, why not just fold the [cd]tor in? I'm asking because Xen wants pgd[3] to be unshared in the PAE case, and it looks to me like the easiest way to handle that is by making pgd_alloc/free pv-ops and doing the appropriate thing in the Xen code. Would need to sort out the

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-rc7 + your patches + the last batch of pv_ops patches I posted. This patch generally restricts itself to Xen-specific parts of the tree, though it does make a few small changes elsewhere. These patches include: - some helper routines for allocating address space and walking pagetables - Xen

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-rc7 + your patches + the last batch of pv_ops patches I posted. This patch generally restricts itself to Xen-specific parts of the tree, though it does make a few small changes elsewhere. These patches include: - some helper routines for allocating address space and walking pagetables - Xen

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-git13 + patches-2.6.21-git7-070507-1.tar.gz (I think "unwinder" is the only patch which doesn't apply to git13, and the sched-clock patches are the only ones which this series actually needs). Changes since the last posting: - More netfront review and cleanup - Added ability to

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-git13 + patches-2.6.21-git7-070507-1.tar.gz (I think "unwinder" is the only patch which doesn't apply to git13, and the sched-clock patches are the only ones which this series actually needs). Changes since the last posting: - More netfront review and cleanup - Added ability to