From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vijay Kilari Subject: Re: preparing for 4.5.1 Date: Tue, 14 Apr 2015 19:25:33 +0530 Message-ID: References: <55144ADE020000780006E157@mail.emea.novell.com> <1427968916.4037.32.camel@citrix.com> <552B9BDE020000780007158A@mail.emea.novell.com> <1429017161.15516.48.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yi1JP-0003S8-28 for xen-devel@lists.xenproject.org; Tue, 14 Apr 2015 13:55:35 +0000 Received: by wgso17 with SMTP id o17so12941436wgs.1 for ; Tue, 14 Apr 2015 06:55:33 -0700 (PDT) In-Reply-To: <1429017161.15516.48.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Julien Grall , xen-devel , Vijaya Kumar K , Jan Beulich , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Tue, Apr 14, 2015 at 6:42 PM, Ian Campbell wrote: > On Mon, 2015-04-13 at 09:35 +0100, Jan Beulich wrote: >> >>> On 02.04.15 at 12:01, wrote: >> > On Thu, 2015-03-26 at 17:07 +0000, Jan Beulich wrote: >> >> having been released mid January, it is time to get ready for 4.5.1-rc1. >> >> Please reply with backport requests which you consider necessary but >> >> still missing. Please also be patient with them being pulled in - I'll be >> >> gone the coming two weeks, and I'd hope to get an RC1 put together >> >> soon thereafter. >> > >> > On my list for ARM I have this patch, which also touches x86. What do >> > you think? >> >> If it fixes a real problem in 4.5 (rather than just a theoretical one, >> exposed only in 4.6), then I'm fine with this (and assume since it's >> mostly for ARM you'll take care of doing and applying the backport). > > The original impetus was a bit lost in the various iterations. I think > it was something which was exposed by Vijay's new ITS code, which did a > larger vmalloc than any existing code and exposed the issue. Vijay, is > that correct? Yes, correct. Any allocation beyond 128MB will fail. > > I think it is unlikely that there is anything in 4.5 which would do a > similarly large vmalloc, or at least I don't recall any reports of such. > > So I think the conclusion is not to backport the patch, unless someone > knows of a practical issue on 4.5. > > For those new to the CC line the commit is below. > > Thanks, > Ian. > > commit c2453291b177cc2e89dc104bd4233c3d8bb73922 > Author: Vijaya Kumar K > Date: Tue Mar 24 17:14:47 2015 +0530 > > xen: Add populate_pt_range interface to reserve non-leaf level table entries > > On x86, for the pages mapped with PAGE_HYPERVISOR attribute > non-leaf page tables are allocated with valid pte entries. > and with MAP_SMALL_PAGES attribute only non-leaf page tables are > allocated with invalid (valid bit set to 0) pte entries. > However on arm this is not the case. On arm for the pages > mapped with PAGE_HYPERVISOR and MAP_SMALL_PAGES both > non-leaf and leaf level page table are allocated with valid bit > in pte entries. > > This behaviour in arm makes common vmap code fail to > allocate memory beyond 128MB as described below. > > In vm_init, map_pages_to_xen() is called for mapping > vm_bitmap. Initially one page of vm_bitmap is allocated > and mapped using PAGE_HYPERVISOR attribute. > For the rest of vm_bitmap pages, MAP_SMALL_PAGES attribute > is used to map. > > In ARM for both PAGE_HYPERVISOR and MAP_SMALL_PAGES, valid bit > is set to 1 in pte entry for these mapping. > > In vm_alloc(), map_pages_to_xen() is failing for >128MB because > for this next vm_bitmap page the mapping is already set in vm_init() > with valid bit set in pte entry. So map_pages_to_xen() in > ARM returns error. > > With this patch, MAP_SMALL_PAGES is dropped and arch specific > populate_pt_range() api is introduced to populate non-leaf > page table entries for the requested pages. Added RESERVE option > to map non-leaf page table entries. > > Signed-off-by: Vijaya Kumar K > Acked-by: Jan Beulich > Acked-by: Ian Campbell > [ ijc -- rewrote subject line ] > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index 7d4ba0c..d103f8f 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -827,7 +827,8 @@ static int create_xen_table(lpae_t *entry) > > enum xenmap_operation { > INSERT, > - REMOVE > + REMOVE, > + RESERVE > }; > > static int create_xen_entries(enum xenmap_operation op, > @@ -859,12 +860,15 @@ static int create_xen_entries(enum xenmap_operation op, > > switch ( op ) { > case INSERT: > + case RESERVE: > if ( third[third_table_offset(addr)].pt.valid ) > { > printk("create_xen_entries: trying to replace an existing mapping addr=%lx mfn=%lx\n", > addr, mfn); > return -EINVAL; > } > + if ( op == RESERVE ) > + break; > pte = mfn_to_xen_entry(mfn, ai); > pte.pt.table = 1; > write_pte(&third[third_table_offset(addr)], pte); > @@ -898,6 +902,13 @@ int map_pages_to_xen(unsigned long virt, > { > return create_xen_entries(INSERT, virt, mfn, nr_mfns, flags); > } > + > +int populate_pt_range(unsigned long virt, unsigned long mfn, > + unsigned long nr_mfns) > +{ > + return create_xen_entries(RESERVE, virt, mfn, nr_mfns, 0); > +} > + > void destroy_xen_mappings(unsigned long v, unsigned long e) > { > create_xen_entries(REMOVE, v, 0, (e - v) >> PAGE_SHIFT, 0); > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index 8e29675..786ed47 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -5725,6 +5725,12 @@ int map_pages_to_xen( > return 0; > } > > +int populate_pt_range(unsigned long virt, unsigned long mfn, > + unsigned long nr_mfns) > +{ > + return map_pages_to_xen(virt, mfn, nr_mfns, MAP_SMALL_PAGES); > +} > + > void destroy_xen_mappings(unsigned long s, unsigned long e) > { > bool_t locking = system_state > SYS_STATE_boot; > diff --git a/xen/common/vmap.c b/xen/common/vmap.c > index 783cea3..739d468 100644 > --- a/xen/common/vmap.c > +++ b/xen/common/vmap.c > @@ -40,7 +40,7 @@ void __init vm_init(void) > bitmap_fill(vm_bitmap, vm_low); > > /* Populate page tables for the bitmap if necessary. */ > - map_pages_to_xen(va, 0, vm_low - nr, MAP_SMALL_PAGES); > + populate_pt_range(va, 0, vm_low - nr); > } > > void *vm_alloc(unsigned int nr, unsigned int align) > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h > index 3e7b0ae..8de5e26 100644 > --- a/xen/include/asm-arm/page.h > +++ b/xen/include/asm-arm/page.h > @@ -64,7 +64,6 @@ > #define PAGE_HYPERVISOR (WRITEALLOC) > #define PAGE_HYPERVISOR_NOCACHE (DEV_SHARED) > #define PAGE_HYPERVISOR_WC (DEV_WC) > -#define MAP_SMALL_PAGES PAGE_HYPERVISOR > > /* > * Stage 2 Memory Type. > diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h > index a769084..a066363 100644 > --- a/xen/include/xen/mm.h > +++ b/xen/include/xen/mm.h > @@ -55,7 +55,12 @@ int map_pages_to_xen( > unsigned long nr_mfns, > unsigned int flags); > void destroy_xen_mappings(unsigned long v, unsigned long e); > - > +/* > + * Create only non-leaf page table entries for the > + * page range in Xen virtual address space. > + */ > +int populate_pt_range(unsigned long virt, unsigned long mfn, > + unsigned long nr_mfns); > /* Claim handling */ > unsigned long domain_adjust_tot_pages(struct domain *d, long pages); > int domain_set_outstanding_pages(struct domain *d, unsigned long pages); > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel