Skip to contentSkip to conversation

x86-64-phys-ma.patch

PATCH In review Arun Sharma 2 participants 4 messages May 12, 2005

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 x86-64-phys-ma.patch

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

linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c +1 -1
@@ -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) &&
#1 lore raw
Quoted 1 line · Arun Sharma

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

Quoted 20 lines
linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c 2005-05-12 13:23:19 -07:00 +1 -1
@@ -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
[email protected]
http://lists.xensource.com/xen-devel

#2 lore raw
Quoted 10 lines · Christian Limpach
Quoted 1 line · Arun Sharma

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

===== linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c 1.7 vs edited =====

linux-2.6.11-xen-sparse/arch/xen/x86_64/mm/init.c +1 -1
@@ -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 =====

linux-2.6.11-xen-sparse/include/asm-xen/asm-x86_64/page.h +1 -0
@@ -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)
 {

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#3 lore raw
Quoted 6 lines · Arun Sharma
Quoted 5 lines · Christian Limpach
Quoted 1 line · Arun Sharma

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

Quoted 8 lines
Quoted 5 lines

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