All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vijay Kilari <vijay.kilari@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Julien Grall <julien.grall@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: preparing for 4.5.1
Date: Tue, 14 Apr 2015 19:25:33 +0530	[thread overview]
Message-ID: <CALicx6uUPtCuYY_w-0zZ3fqAPxD4pXzoKkQ3Czc9a=xd+cpbwg@mail.gmail.com> (raw)
In-Reply-To: <1429017161.15516.48.camel@citrix.com>

On Tue, Apr 14, 2015 at 6:42 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Mon, 2015-04-13 at 09:35 +0100, Jan Beulich wrote:
>> >>> On 02.04.15 at 12:01, <ian.campbell@citrix.com> 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 <Vijaya.Kumar@caviumnetworks.com>
> 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<Vijaya.Kumar@caviumnetworks.com>
>     Acked-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Ian Campbell <ian.campbell@citrix.com>
>     [ 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

  reply	other threads:[~2015-04-14 13:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-26 17:07 preparing for 4.5.1 Jan Beulich
2015-03-26 17:19 ` Andrew Cooper
2015-03-30 10:24 ` preparing for 4.5.1 (ARM) Ian Campbell
2015-03-30 12:04   ` Julien Grall
2015-03-30 12:57 ` preparing for 4.5.1 Wei Liu
2015-04-02  0:48   ` Jim Fehlig
2015-03-30 13:15 ` Roger Pau Monné
2015-03-30 14:07   ` Julien Grall
2015-04-13  8:36   ` Jan Beulich
2015-04-13  9:05     ` Andrew Cooper
2015-04-02 10:01 ` Ian Campbell
2015-04-13  8:35   ` Jan Beulich
2015-04-14 13:12     ` Ian Campbell
2015-04-14 13:55       ` Vijay Kilari [this message]
2015-04-14 14:09         ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALicx6uUPtCuYY_w-0zZ3fqAPxD4pXzoKkQ3Czc9a=xd+cpbwg@mail.gmail.com' \
    --to=vijay.kilari@gmail.com \
    --cc=JBeulich@suse.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=Vijaya.Kumar@caviumnetworks.com \
    --cc=ian.campbell@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.