preparing for 4.5.1

preparing for 4.5.1

[Jan Beulich]

All,

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.

Thanks, Jan

Re: preparing for 4.5.1

[Andrew Cooper]

On 26/03/15 17:07, Jan Beulich wrote:
> All,
>
> 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.

The XenServer list of backports against 4.5 currently contains no Xen 
patches (which I believe is a first - your backports this morning 
covered everything flagged in my list.)

As for tools side of things:

* c8945d516134 - ocaml/xenctrl: Make failwith_xc() thread safe
* 1a010ca99e9b - ocaml/xenctrl: Fix stub_xc_readconsolering()
* 96e0ee8386cf - tools/hotplug: systemd: Don't ever kill xenstored
* 588df84c0d70 - tools/xenconsoled: Increase file descriptor limit

~Andrew

Re: preparing for 4.5.1 (ARM)

[Ian Campbell]

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.

@ARM folks:

My Backports todo list contains:
      * Some subset of "xen/arm: Bug fixes for the vGIC"
      * 67c7e46 xen: arm32: reduce default size of the xenheap
      * 7466b88 xen: arm: correctly handle continuations for 64-bit
        guests

But I'm pretty bad at remembering to add things to that list.

Based on a scan/grepping of "git cherry -v origin/staging-4.5
origin/staging" I've just added:
      * e9c1747 arm64: fix fls()
      * bf8d458 xen/arm: Don't pass the PSCI-0.2 node to DOM0
      * f01af57 dt-uart: use ':' as separator between path and options

Anyone have anything else I should consider?
Ian.

Re: preparing for 4.5.1 (ARM)

[Julien Grall]

Hi Ian,

On 30/03/15 11:24, Ian Campbell 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.
> 
> @ARM folks:
> 
> My Backports todo list contains:
>       * Some subset of "xen/arm: Bug fixes for the vGIC"
>       * 67c7e46 xen: arm32: reduce default size of the xenheap
>       * 7466b88 xen: arm: correctly handle continuations for 64-bit
>         guests
> 
> But I'm pretty bad at remembering to add things to that list.
> 
> Based on a scan/grepping of "git cherry -v origin/staging-4.5
> origin/staging" I've just added:
>       * e9c1747 arm64: fix fls()
>       * bf8d458 xen/arm: Don't pass the PSCI-0.2 node to DOM0
>       * f01af57 dt-uart: use ':' as separator between path and options
> 
> Anyone have anything else I should consider?

It hasn't been ask for backporting but I think they would be a good
candidate:

c245329 xen: Add populate_pt_range interface to reserve non-leaf level
table entries

e8bb583 xen/arm: Call context_saved() with interrupts enabled during
context switch

770ca10 xen/arm: Blacklist the memory mapped timer (armv7-timer-mem)

Regards,

-- 
Julien Grall

Re: preparing for 4.5.1

[Wei Liu]

On Thu, Mar 26, 2015 at 05:07:26PM +0000, Jan Beulich wrote:
> All,
> 
> 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.
> 

Some tools patches:

f1335f0d7b2402e94e0c6e8a905dc309edaafcfb (and its prerequisites)
1391ca3bfa6555deefa3df620e1aa824652329f5
d79b1c3f1ee10f429a6b4cb59cfd94637bcaca2d
fe3cafd89ab7a9e171a4e8542b00f5f08c7b4f2f

Wei.

> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: preparing for 4.5.1

[Roger Pau Monné]

El 26/03/15 a les 18.07, Jan Beulich ha escrit:
> All,
> 
> 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.

I would like to request the backport of the shared page tables fix
between EPT and IOMMU for PVH:

797842 iommu: fix usage of shared EPT/IOMMU page tables on PVH

Thanks, Roger.

Re: preparing for 4.5.1

[Julien Grall]

Hi,

On 30/03/15 14:15, Roger Pau Monné wrote:
> El 26/03/15 a les 18.07, Jan Beulich ha escrit:
>> All,
>>
>> 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.
> 
> I would like to request the backport of the shared page tables fix
> between EPT and IOMMU for PVH:
> 
> 797842 iommu: fix usage of shared EPT/IOMMU page tables on PVH

This patch breaks compilation on ARM. It has to be backported with

9bac5f5     passthrough: share_p2m: fix build failure on ARM

Regards,

-- 
Julien Grall

Re: preparing for 4.5.1

[Jim Fehlig]

Wei Liu wrote:
> On Thu, Mar 26, 2015 at 05:07:26PM +0000, Jan Beulich wrote:
>   
>> All,
>>
>> 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.
>>
>>     
>
> Some tools patches:
>
>   
> f1335f0d7b2402e94e0c6e8a905dc309edaafcfb (and its prerequisites)

>From my testing, the prerequisite is only
93699882d98cce9736d6e871db303275df1138a2

> 1391ca3bfa6555deefa3df620e1aa824652329f5
> d79b1c3f1ee10f429a6b4cb59cfd94637bcaca2d
> fe3cafd89ab7a9e171a4e8542b00f5f08c7b4f2f
>   

Along with these, some other very useful tools patches (still stuck in
staging)

commit 4783c99aab866f470bd59368cfbf5ad5f677b0ec
Author: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue Mar 17 09:30:57 2015 -0600

libxl: In domain death search, start search at first domid we want

commit 1c91d6fba20c1517d78076d412d33cb41f501be5
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue Mar 17 09:30:58 2015 -0600

libxl: Domain destroy: unlock userdata earlier

commit 188e9c541f698109a76cf334b925c77b6007aba1
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu Mar 5 16:28:04 2015 +0000

libxl: Domain destroy: fork

Regards,
Jim

Re: preparing for 4.5.1

[Ian Campbell]

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?

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);


> 
> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: preparing for 4.5.1

[Jan Beulich]

>>> 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).

Jan

Re: preparing for 4.5.1

[Jan Beulich]

>>> On 30.03.15 at 15:15, <roger.pau@citrix.com> wrote:
> El 26/03/15 a les 18.07, Jan Beulich ha escrit:
>> All,
>> 
>> 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.
> 
> I would like to request the backport of the shared page tables fix
> between EPT and IOMMU for PVH:
> 
> 797842 iommu: fix usage of shared EPT/IOMMU page tables on PVH

Apart from you having failed to also request the fixup on top (as
pointed out by Julien) you also didn't give a reason for the request.
Aiui this is a PVH Dom0 fix only, and PVH Dom0 doesn't even come
near to be supported in 4.5.

Jan

Re: preparing for 4.5.1

[Andrew Cooper]

On 13/04/15 09:36, Jan Beulich wrote:
>>>> On 30.03.15 at 15:15, <roger.pau@citrix.com> wrote:
>> El 26/03/15 a les 18.07, Jan Beulich ha escrit:
>>> All,
>>>
>>> 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.
>> I would like to request the backport of the shared page tables fix
>> between EPT and IOMMU for PVH:
>>
>> 797842 iommu: fix usage of shared EPT/IOMMU page tables on PVH
> Apart from you having failed to also request the fixup on top (as
> pointed out by Julien) you also didn't give a reason for the request.
> Aiui this is a PVH Dom0 fix only, and PVH Dom0 doesn't even come
> near to be supported in 4.5.

I would concur.  PVH is experimental and in need of a large quantity of
work before it could plausibly be supported (and therefore qualify for
backports).

Anyone working on PVH while it is experimental should be using unstable.

~Andrew

Re: preparing for 4.5.1

[Ian Campbell]

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?

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);

Re: preparing for 4.5.1

[Vijay Kilari]

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

Re: preparing for 4.5.1

[Ian Campbell]

On Tue, 2015-04-14 at 19:25 +0530, Vijay Kilari wrote:
> 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.

Thanks.

You are not aware of any such large large allocations in the 4.5 code
base I think, so lets not worry about this patch as a backport.

Ian.

> 
> >
> > 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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel