[PATCH] x86-64-phys-ma.patch

[PATCH] x86-64-phys-ma.patch

[Arun Sharma]

phys is machine physical already. So we shouldn't try to convert guest physical to machine physical.

Signed-off-by: Arun Sharma <arun.sharma@intel.com>

--- a/linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c	2005-05-12 13:23:19 -07:00
+++ b/linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c	2005-05-12 13:23:19 -07:00
@@ -328,7 +328,7 @@
 		}
 	}
 
-	new_pte = pfn_pte(phys >> PAGE_SHIFT, prot);
+	new_pte = pfn_pte_ma(phys >> PAGE_SHIFT, prot);
 	pte = pte_offset_kernel(pmd, vaddr);
 
 	if (!pte_none(*pte) &&

Re: [PATCH] x86-64-phys-ma.patch

[Christian Limpach]

On 5/12/05, Arun Sharma <arun.sharma@intel.com> wrote:
> phys is machine physical already. So we shouldn't try to convert guest physical to machine physical.

Are you sure that the test a few lines further down shouldn't use (a
to be defined -- see i386) pte_val_ma to compare the currently
installed pte with the to-be-installed one?  You might be comparing
random values otherwise...

    christian

> 
> Signed-off-by: Arun Sharma <arun.sharma@intel.com>
> 
> --- a/linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c 2005-05-12 13:23:19 -07:00
> +++ b/linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c 2005-05-12 13:23:19 -07:00
> @@ -328,7 +328,7 @@
>                 }
>         }
> 
> -       new_pte = pfn_pte(phys >> PAGE_SHIFT, prot);
> +       new_pte = pfn_pte_ma(phys >> PAGE_SHIFT, prot);
>         pte = pte_offset_kernel(pmd, vaddr);
> 
>         if (!pte_none(*pte) &&
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: [PATCH] x86-64-phys-ma.patch

[Arun Sharma]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

Christian Limpach wrote:
> On 5/12/05, Arun Sharma <arun.sharma@intel.com> wrote:
> 
>>phys is machine physical already. So we shouldn't try to convert guest physical to machine physical.
> 
> 
> Are you sure that the test a few lines further down shouldn't use (a
> to be defined -- see i386) pte_val_ma to compare the currently
> installed pte with the to-be-installed one?  You might be comparing
> random values otherwise...
> 

Sounds reasonable. I tested that this incremental patch doesn't cause 
any new regressions.

	-Arun


[-- Attachment #2: pte-val-ma.patch --]
[-- Type: text/plain, Size: 965 bytes --]

===== linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c 1.7 vs edited =====
--- 1.7/linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c	2005-05-12 10:17:01 -07:00
+++ edited/linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c	2005-05-12 14:32:18 -07:00
@@ -332,7 +332,7 @@
 	pte = pte_offset_kernel(pmd, vaddr);
 
 	if (!pte_none(*pte) &&
-	    pte_val(*pte) != (pte_val(new_pte) & __supported_pte_mask))
+	    pte_val_ma(*pte) != (pte_val_ma(new_pte) & __supported_pte_mask))
 		pte_ERROR(*pte);
 
         /* 
===== linux-2.6.11-xen-sparse/include/asm-xen/asm-x86_64/page.h 1.2 vs edited =====
--- 1.2/linux-2.6.11-xen-sparse/include/asm-xen/asm-x86_64/page.h	2005-04-02 12:27:09 -08:00
+++ edited/linux-2.6.11-xen-sparse/include/asm-xen/asm-x86_64/page.h	2005-05-12 14:26:58 -07:00
@@ -92,6 +92,7 @@
 
 #define pte_val(x)	(((x).pte & 1) ? machine_to_phys((x).pte) : \
 			 (x).pte)
+#define pte_val_ma(x)	((x).pte)
 
 static inline unsigned long pmd_val(pmd_t x)
 {

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] x86-64-phys-ma.patch

[Christian Limpach]

On 5/12/05, Arun Sharma <arun.sharma@intel.com> wrote:
> Christian Limpach wrote:
> > On 5/12/05, Arun Sharma <arun.sharma@intel.com> wrote:
> >
> >>phys is machine physical already. So we shouldn't try to convert guest physical to machine physical.
> >
> >
> > Are you sure that the test a few lines further down shouldn't use (a
> > to be defined -- see i386) pte_val_ma to compare the currently
> > installed pte with the to-be-installed one?  You might be comparing
> > random values otherwise...
> >
> 
> Sounds reasonable. I tested that this incremental patch doesn't cause
> any new regressions.

Thanks -- checked in.

     christian