Re: [Xen-devel] [PATCH v2 16/24] xen/arm: page: Use ARMv8 naming to improve readability

2017-09-21 Thread Julien Grall 

Hi,

On 21/09/17 16:46, Stefano Stabellini wrote:

On Thu, 21 Sep 2017, Julien Grall wrote:

Hi,

On 20/09/17 00:45, Stefano Stabellini wrote:

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 30fcfa0778..899fd1801a 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -26,14 +26,14 @@
* LPAE entry; the 8-bit fields are packed little-endian into MAIR0 and
MAIR1.
*
*aiencoding
- *   MT_UNCACHED  000      -- Strongly Ordered
- *   MT_BUFFERABLE001   0100 0100  -- Non-Cacheable
- *   MT_WRITETHROUGH  010   1010 1010  -- Write-through
- *   MT_WRITEBACK 011   1110 1110  -- Write-back
- *   MT_DEV_SHARED100    0100  -- Device
+ *   MT_DEVICE_nGnRE  000      -- Strongly Ordered/Device nGnRnE


I admit I always hated the "nGnRE" acronym. However, it is on the ARM
ARM too, so if you'd like to introduce it here, I'll accept it. But
please at least expand the acronym in the comment to make it
understandable (same with nGnRnE).


"nGnRE" acronym are not great but convey the meaning of what would be the
resulting attribute.


This is an honest question, no pun intended: how do they convey the
meaning? Personally, I have to look it up every time on the ARM ARM...



For instance MT_UNCACHED does not really say if it is for
device or memory. Lets not even mention MT_BUFFERABLE which is in fact
non-cacheable memory :).



Also, the comment say "nGnRnE" while the definition is MT_DEVICE_nGnRE.


Actually, the comment is correct but not the naming. It should
MT_DEVICE_nGnRnE. I will rename it.

Aside that, I think the comment is understandable. nGnRnE is equivalent to
Strongly ordered. I could expand nGnRnE (non-Gatherable, non-Reordering, No
Early write acknowledgment) but I feel at this stage you can just search the
name in the ARM ARM...


I am not asking to expland the name, only to expand nGnRnE in the
comment on the side. Searching through that pdf is not really a fun
activity.


They are really easy to find compare to other bits of the specs :). 
Expanding is not going to be very useful without looking at the 
definition. I would prefer to add the section of the ARM ARM on top.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/24] xen/arm: page: Use ARMv8 naming to improve readability

2017-09-21 Thread Andre Przywara 
Hi,

On 21/09/17 16:46, Stefano Stabellini wrote:
> On Thu, 21 Sep 2017, Julien Grall wrote:
>> Hi,
>>
>> On 20/09/17 00:45, Stefano Stabellini wrote:
 diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
 index 30fcfa0778..899fd1801a 100644
 --- a/xen/include/asm-arm/page.h
 +++ b/xen/include/asm-arm/page.h
 @@ -26,14 +26,14 @@
* LPAE entry; the 8-bit fields are packed little-endian into MAIR0 and
 MAIR1.
*
*aiencoding
 - *   MT_UNCACHED  000      -- Strongly Ordered
 - *   MT_BUFFERABLE001   0100 0100  -- Non-Cacheable
 - *   MT_WRITETHROUGH  010   1010 1010  -- Write-through
 - *   MT_WRITEBACK 011   1110 1110  -- Write-back
 - *   MT_DEV_SHARED100    0100  -- Device
 + *   MT_DEVICE_nGnRE  000      -- Strongly Ordered/Device nGnRnE
>>>
>>> I admit I always hated the "nGnRE" acronym. However, it is on the ARM
>>> ARM too, so if you'd like to introduce it here, I'll accept it. But
>>> please at least expand the acronym in the comment to make it
>>> understandable (same with nGnRnE).
>>
>> "nGnRE" acronym are not great but convey the meaning of what would be the
>> resulting attribute.

I agree they are hideous to read, but easy to break down once you got
the idea ...

> This is an honest question, no pun intended: how do they convey the
> meaning? Personally, I have to look it up every time on the ARM ARM...

ARMv8 ARM B2.7.2  Device memory

G -> Gathering (can merge multiple accesses into one transfer)
R -> Reordering
E -> Early Write acknowledgement (other agents than the endpoint
(caches) can acknowledge the transfer).

n means not.

Done. More details in the ARM ARM.

Cheers,
Andre.

>> For instance MT_UNCACHED does not really say if it is for
>> device or memory. Lets not even mention MT_BUFFERABLE which is in fact
>> non-cacheable memory :).
>>
>>>
>>> Also, the comment say "nGnRnE" while the definition is MT_DEVICE_nGnRE.
>>
>> Actually, the comment is correct but not the naming. It should
>> MT_DEVICE_nGnRnE. I will rename it.
>>
>> Aside that, I think the comment is understandable. nGnRnE is equivalent to
>> Strongly ordered. I could expand nGnRnE (non-Gatherable, non-Reordering, No
>> Early write acknowledgment) but I feel at this stage you can just search the
>> name in the ARM ARM...
> 
> I am not asking to expland the name, only to expand nGnRnE in the
> comment on the side. Searching through that pdf is not really a fun
> activity.
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/24] xen/arm: page: Use ARMv8 naming to improve readability

2017-09-21 Thread Stefano Stabellini 
On Thu, 21 Sep 2017, Julien Grall wrote:
> Hi,
> 
> On 20/09/17 00:45, Stefano Stabellini wrote:
> > > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > > index 30fcfa0778..899fd1801a 100644
> > > --- a/xen/include/asm-arm/page.h
> > > +++ b/xen/include/asm-arm/page.h
> > > @@ -26,14 +26,14 @@
> > >* LPAE entry; the 8-bit fields are packed little-endian into MAIR0 and
> > > MAIR1.
> > >*
> > >*aiencoding
> > > - *   MT_UNCACHED  000      -- Strongly Ordered
> > > - *   MT_BUFFERABLE001   0100 0100  -- Non-Cacheable
> > > - *   MT_WRITETHROUGH  010   1010 1010  -- Write-through
> > > - *   MT_WRITEBACK 011   1110 1110  -- Write-back
> > > - *   MT_DEV_SHARED100    0100  -- Device
> > > + *   MT_DEVICE_nGnRE  000      -- Strongly Ordered/Device nGnRnE
> > 
> > I admit I always hated the "nGnRE" acronym. However, it is on the ARM
> > ARM too, so if you'd like to introduce it here, I'll accept it. But
> > please at least expand the acronym in the comment to make it
> > understandable (same with nGnRnE).
> 
> "nGnRE" acronym are not great but convey the meaning of what would be the
> resulting attribute.

This is an honest question, no pun intended: how do they convey the
meaning? Personally, I have to look it up every time on the ARM ARM...


> For instance MT_UNCACHED does not really say if it is for
> device or memory. Lets not even mention MT_BUFFERABLE which is in fact
> non-cacheable memory :).
> 
> > 
> > Also, the comment say "nGnRnE" while the definition is MT_DEVICE_nGnRE.
> 
> Actually, the comment is correct but not the naming. It should
> MT_DEVICE_nGnRnE. I will rename it.
> 
> Aside that, I think the comment is understandable. nGnRnE is equivalent to
> Strongly ordered. I could expand nGnRnE (non-Gatherable, non-Reordering, No
> Early write acknowledgment) but I feel at this stage you can just search the
> name in the ARM ARM...

I am not asking to expland the name, only to expand nGnRnE in the
comment on the side. Searching through that pdf is not really a fun
activity.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/24] xen/arm: page: Use ARMv8 naming to improve readability

2017-09-21 Thread Julien Grall 

Hi,

On 20/09/17 00:45, Stefano Stabellini wrote:

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 30fcfa0778..899fd1801a 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -26,14 +26,14 @@
   * LPAE entry; the 8-bit fields are packed little-endian into MAIR0 and MAIR1.
   *
   *aiencoding
- *   MT_UNCACHED  000      -- Strongly Ordered
- *   MT_BUFFERABLE001   0100 0100  -- Non-Cacheable
- *   MT_WRITETHROUGH  010   1010 1010  -- Write-through
- *   MT_WRITEBACK 011   1110 1110  -- Write-back
- *   MT_DEV_SHARED100    0100  -- Device
+ *   MT_DEVICE_nGnRE  000      -- Strongly Ordered/Device nGnRnE


I admit I always hated the "nGnRE" acronym. However, it is on the ARM
ARM too, so if you'd like to introduce it here, I'll accept it. But
please at least expand the acronym in the comment to make it
understandable (same with nGnRnE).


"nGnRE" acronym are not great but convey the meaning of what would be 
the resulting attribute. For instance MT_UNCACHED does not really say if 
it is for device or memory. Lets not even mention MT_BUFFERABLE which is 
in fact non-cacheable memory :).




Also, the comment say "nGnRnE" while the definition is MT_DEVICE_nGnRE.


Actually, the comment is correct but not the naming. It should 
MT_DEVICE_nGnRnE. I will rename it.


Aside that, I think the comment is understandable. nGnRnE is equivalent 
to Strongly ordered. I could expand nGnRnE (non-Gatherable, 
non-Reordering, No Early write acknowledgment) but I feel at this stage 
you can just search the name in the ARM ARM...






+ *   MT_NORMAL_NC 001   0100 0100  -- Non-Cacheable
+ *   MT_NORMAL_WT 010   1010 1010  -- Write-through
+ *   MT_NORMAL_WB 011   1110 1110  -- Write-back
+ *   MT_DEVICE_nGnRE  100    0100  -- Device nGnRE
   *   ??   101
   *   reserved 110
- *   MT_WRITEALLOC111      -- Write-back write-allocate
+ *   MT_NORMAL111      -- Write-back write-allocate
   */
  #define MAIR0VAL 0xeeaa4400
  #define MAIR1VAL 0xff04
@@ -47,16 +47,16 @@
   * registers, as defined above.
   *
   */
-#define MT_UNCACHED  0x0
-#define MT_BUFFERABLE0x1
-#define MT_WRITETHROUGH  0x2
-#define MT_WRITEBACK 0x3
-#define MT_DEV_SHARED0x4
-#define MT_WRITEALLOC0x7
-
-#define PAGE_HYPERVISOR (MT_WRITEALLOC)
-#define PAGE_HYPERVISOR_NOCACHE (MT_DEV_SHARED)
-#define PAGE_HYPERVISOR_WC  (MT_BUFFERABLE)
+#define MT_DEVICE_nGnRnE 0x0
+#define MT_NORMAL_NC 0x1
+#define MT_NORMAL_WT 0x2
+#define MT_NORMAL_WB 0x3
+#define MT_DEVICE_nGnRE  0x4
+#define MT_NORMAL0x7
+
+#define PAGE_HYPERVISOR (MT_NORMAL)
+#define PAGE_HYPERVISOR_NOCACHE (MT_DEVICE_nGnRE)
+#define PAGE_HYPERVISOR_WC  (MT_NORMAL_NC)
  
  /*

   * Defines for changing the hypervisor PTE .ro and .nx bits. This is only to 
be


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/24] xen/arm: page: Use ARMv8 naming to improve readability

2017-09-19 Thread Stefano Stabellini 
On Tue, 12 Sep 2017, Julien Grall wrote:
> This is based on the Linux ARMv8 naming scheme (see arch/arm64/mm/proc.S). 
> Each
> type will contain "NORMAL" or "DEVICE" to make clear whether each attribute
> targets device or normal memory.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> Changes in v2:
> * Move the patch before "xen/arm: page: Clean-up the definition
> of MAIRVAL"
> ---
>  xen/arch/arm/kernel.c |  2 +-
>  xen/arch/arm/mm.c | 28 ++--
>  xen/arch/arm/platforms/vexpress.c |  2 +-
>  xen/drivers/video/arm_hdlcd.c |  2 +-
>  xen/include/asm-arm/page.h| 32 
>  5 files changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index 9c183f96da..a12baa86e7 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -54,7 +54,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned 
> long len)
>  s = paddr & (PAGE_SIZE-1);
>  l = min(PAGE_SIZE - s, len);
>  
> -set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), MT_BUFFERABLE);
> +set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), MT_NORMAL_NC);
>  memcpy(dst, src + s, l);
>  clean_dcache_va_range(dst, l);
>  
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 7ffeb36bfa..fc76f03526 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -290,7 +290,7 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
> attr)
>  
>  switch ( attr )
>  {
> -case MT_BUFFERABLE:
> +case MT_NORMAL_NC:
>  /*
>   * ARM ARM: Overlaying the shareability attribute (DDI
>   * 0406C.b B3-1376 to 1377)
> @@ -305,8 +305,8 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
> attr)
>   */
>  e.pt.sh = LPAE_SH_OUTER;
>  break;
> -case MT_UNCACHED:
> -case MT_DEV_SHARED:
> +case MT_DEVICE_nGnRnE:
> +case MT_DEVICE_nGnRE:
>  /*
>   * Shareability is ignored for non-Normal memory, Outer is as
>   * good as anything.
> @@ -369,7 +369,7 @@ static void __init create_mappings(lpae_t *second,
>  
>  count = nr_mfns / LPAE_ENTRIES;
>  p = second + second_linear_offset(virt_offset);
> -pte = mfn_to_xen_entry(_mfn(base_mfn), MT_WRITEALLOC);
> +pte = mfn_to_xen_entry(_mfn(base_mfn), MT_NORMAL);
>  if ( granularity == 16 * LPAE_ENTRIES )
>  pte.pt.contig = 1;  /* These maps are in 16-entry contiguous chunks. 
> */
>  for ( i = 0; i < count; i++ )
> @@ -422,7 +422,7 @@ void *map_domain_page(mfn_t mfn)
>  else if ( map[slot].pt.avail == 0 )
>  {
>  /* Commandeer this 2MB slot */
> -pte = mfn_to_xen_entry(_mfn(slot_mfn), MT_WRITEALLOC);
> +pte = mfn_to_xen_entry(_mfn(slot_mfn), MT_NORMAL);
>  pte.pt.avail = 1;
>  write_pte(map + slot, pte);
>  break;
> @@ -543,7 +543,7 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
>  {
>  paddr_t ma = va + phys_offset;
>  
> -return mfn_to_xen_entry(maddr_to_mfn(ma), MT_WRITEALLOC);
> +return mfn_to_xen_entry(maddr_to_mfn(ma), MT_NORMAL);
>  }
>  
>  /* Map the FDT in the early boot page table */
> @@ -652,7 +652,7 @@ void __init setup_pagetables(unsigned long 
> boot_phys_offset, paddr_t xen_paddr)
>  /* Initialise xen second level entries ... */
>  /* ... Xen's text etc */
>  
> -pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_WRITEALLOC);
> +pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_NORMAL);
>  pte.pt.xn = 0;/* Contains our text mapping! */
>  xen_second[second_table_offset(XEN_VIRT_START)] = pte;
>  
> @@ -669,7 +669,7 @@ void __init setup_pagetables(unsigned long 
> boot_phys_offset, paddr_t xen_paddr)
>  
>  /* ... Boot Misc area for xen relocation */
>  dest_va = BOOT_RELOC_VIRT_START;
> -pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_WRITEALLOC);
> +pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_NORMAL);
>  /* Map the destination in xen_second. */
>  xen_second[second_table_offset(dest_va)] = pte;
>  /* Map the destination in boot_second. */
> @@ -700,7 +700,7 @@ void __init setup_pagetables(unsigned long 
> boot_phys_offset, paddr_t xen_paddr)
>  unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
>  if ( !is_kernel(va) )
>  break;
> -pte = mfn_to_xen_entry(mfn, MT_WRITEALLOC);
> +pte = mfn_to_xen_entry(mfn, MT_NORMAL);
>  pte.pt.table = 1; /* 4k mappings always have this bit set */
>  if ( is_kernel_text(va) || is_kernel_inittext(va) )
>  {
> @@ -771,7 +771,7 @@ int init_secondary_pagetables(int cpu)
>  for ( i = 0; i < DOMHEAP_SECOND_PAGES; i++ )
>  {
>  pte = mfn_to_xen_entry(virt_to_mfn(domheap+i*LPAE_ENTRIES),
> -   MT_WRITEALLOC);
> +

[Xen-devel] [PATCH v2 16/24] xen/arm: page: Use ARMv8 naming to improve readability

2017-09-12 Thread Julien Grall 
This is based on the Linux ARMv8 naming scheme (see arch/arm64/mm/proc.S). Each
type will contain "NORMAL" or "DEVICE" to make clear whether each attribute
targets device or normal memory.

Signed-off-by: Julien Grall 

---

Changes in v2:
* Move the patch before "xen/arm: page: Clean-up the definition
of MAIRVAL"
---
 xen/arch/arm/kernel.c |  2 +-
 xen/arch/arm/mm.c | 28 ++--
 xen/arch/arm/platforms/vexpress.c |  2 +-
 xen/drivers/video/arm_hdlcd.c |  2 +-
 xen/include/asm-arm/page.h| 32 
 5 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 9c183f96da..a12baa86e7 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -54,7 +54,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long 
len)
 s = paddr & (PAGE_SIZE-1);
 l = min(PAGE_SIZE - s, len);
 
-set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), MT_BUFFERABLE);
+set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), MT_NORMAL_NC);
 memcpy(dst, src + s, l);
 clean_dcache_va_range(dst, l);
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7ffeb36bfa..fc76f03526 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -290,7 +290,7 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
attr)
 
 switch ( attr )
 {
-case MT_BUFFERABLE:
+case MT_NORMAL_NC:
 /*
  * ARM ARM: Overlaying the shareability attribute (DDI
  * 0406C.b B3-1376 to 1377)
@@ -305,8 +305,8 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
attr)
  */
 e.pt.sh = LPAE_SH_OUTER;
 break;
-case MT_UNCACHED:
-case MT_DEV_SHARED:
+case MT_DEVICE_nGnRnE:
+case MT_DEVICE_nGnRE:
 /*
  * Shareability is ignored for non-Normal memory, Outer is as
  * good as anything.
@@ -369,7 +369,7 @@ static void __init create_mappings(lpae_t *second,
 
 count = nr_mfns / LPAE_ENTRIES;
 p = second + second_linear_offset(virt_offset);
-pte = mfn_to_xen_entry(_mfn(base_mfn), MT_WRITEALLOC);
+pte = mfn_to_xen_entry(_mfn(base_mfn), MT_NORMAL);
 if ( granularity == 16 * LPAE_ENTRIES )
 pte.pt.contig = 1;  /* These maps are in 16-entry contiguous chunks. */
 for ( i = 0; i < count; i++ )
@@ -422,7 +422,7 @@ void *map_domain_page(mfn_t mfn)
 else if ( map[slot].pt.avail == 0 )
 {
 /* Commandeer this 2MB slot */
-pte = mfn_to_xen_entry(_mfn(slot_mfn), MT_WRITEALLOC);
+pte = mfn_to_xen_entry(_mfn(slot_mfn), MT_NORMAL);
 pte.pt.avail = 1;
 write_pte(map + slot, pte);
 break;
@@ -543,7 +543,7 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
 {
 paddr_t ma = va + phys_offset;
 
-return mfn_to_xen_entry(maddr_to_mfn(ma), MT_WRITEALLOC);
+return mfn_to_xen_entry(maddr_to_mfn(ma), MT_NORMAL);
 }
 
 /* Map the FDT in the early boot page table */
@@ -652,7 +652,7 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 /* Initialise xen second level entries ... */
 /* ... Xen's text etc */
 
-pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_WRITEALLOC);
+pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_NORMAL);
 pte.pt.xn = 0;/* Contains our text mapping! */
 xen_second[second_table_offset(XEN_VIRT_START)] = pte;
 
@@ -669,7 +669,7 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 
 /* ... Boot Misc area for xen relocation */
 dest_va = BOOT_RELOC_VIRT_START;
-pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_WRITEALLOC);
+pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_NORMAL);
 /* Map the destination in xen_second. */
 xen_second[second_table_offset(dest_va)] = pte;
 /* Map the destination in boot_second. */
@@ -700,7 +700,7 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
 if ( !is_kernel(va) )
 break;
-pte = mfn_to_xen_entry(mfn, MT_WRITEALLOC);
+pte = mfn_to_xen_entry(mfn, MT_NORMAL);
 pte.pt.table = 1; /* 4k mappings always have this bit set */
 if ( is_kernel_text(va) || is_kernel_inittext(va) )
 {
@@ -771,7 +771,7 @@ int init_secondary_pagetables(int cpu)
 for ( i = 0; i < DOMHEAP_SECOND_PAGES; i++ )
 {
 pte = mfn_to_xen_entry(virt_to_mfn(domheap+i*LPAE_ENTRIES),
-   MT_WRITEALLOC);
+   MT_NORMAL);
 pte.pt.table = 1;
 write_pte([first_table_offset(DOMHEAP_VIRT_START+i*FIRST_SIZE)], 
pte);
 }
@@ -869,13 +869,13 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
 mfn_t first_mfn = alloc_boot_pages(1, 1);