Re: [Xen-ia64-devel] EFI Mapping Windows Install Crash Bug

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Wed, Jul 02, 2008 at 05:20:48PM +1000, Simon Horman wrote:
> On Wed, Jul 02, 2008 at 04:20:33PM +1000, Simon Horman wrote:
> > On Tue, Jul 01, 2008 at 09:19:24PM +0900, Isaku Yamahata wrote:
> 
> [snip]
> 
> > > As I'm reviewing the patches, I noticed only xen/arch/ia64/xen/ivt.S
> > > is patched, but xen/arch/ia64/xen/vmx_ivt.S isn't patched.
> > > Isn't it necessary to similar change to vmx_ivt.S?
> > 
> > [ As per our discussion off-line. ]
> > 
> > That is a good question, and one that I wasn't aware of until
> > you brought it up. I think that the answer is likely no, as
> > else the code would be very broken, and as it is it does work
> > most of the time. However, this could just be by chance - for
> > instance the TLB might be seeded with entries it needs. I
> > will look into this further.
> 
> Hi Yamahata-san,
> 
> I believe that the answer to this question is no,
> there is no need to update the VMX page fault handlers.
> 
> As the VHPT is turned off when the EFI RR is active
> the only page fault handlers that are relevant are
> vmx_alt_dtlb_miss and vmx_alt_itlb_miss - and emprically
> from my experience with the non-VMX page fault handlers,
> itlb misses never occur.
> 
> In any case, both vmx_alt_dtlb_miss and vmx_alt_itlb_miss
> employ the following logic in order to tetermine the
> physical address (pa) of a faulting address (ifa).
> 
> #define IA64_MAX_PHYS_BITS      50
> pa = ifa & (((1 << IA64_MAX_PHYS_BITS) - 1) & ~0xfff)
> 
> The case that we are concerned with is when the ifa
> looks like 0xe... or 0xc... instead of a normal Xen
> virtual address which looks like 0xf...
> 
> However, the logic above covers all of these cases,
> and thus the VMX page fault handlers can already
> identity map EFI memory.


Yes basically sounds correct.
It looks like the EFI UC area case isn't handled properly.
What do you think?

Signed-off-by: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>

diff -r 32e557f7c4c8 xen/arch/ia64/vmx/vmx_ivt.S
--- a/xen/arch/ia64/vmx/vmx_ivt.S       Mon Jul 07 11:30:14 2008 +0900
+++ b/xen/arch/ia64/vmx/vmx_ivt.S       Mon Jul 07 12:28:38 2008 +0900
@@ -365,16 +365,22 @@ vmx_alt_dtlb_miss_vmm:
     ;;
     and r22=IA64_ISR_CODE_MASK,r20             // get the isr.code field
     tbit.nz p6,p7=r20,IA64_ISR_SP_BIT          // is speculation bit on?
-    extr.u r18=r16,XEN_VIRT_UC_BIT, 1          // extract UC bit
+    tbit.nz p8,p0=r16,XEN_VIRT_UC_BIT          // is Xen UC region?
+    extr.u r23=r16,59,5                                // iva fault address
+                                               // 0xc0000000_00000000 >> 59 = 
0x18 EFI UC address
+                                               // 0xe0000000_00000000 >> 59 = 
0x1c EFI address
+
     and r19=r19,r16                            // clear ed, reserved bits, and 
PTE control bits
     tbit.nz p9,p0=r20,IA64_ISR_NA_BIT          // is non-access bit on?
     ;;
+    cmp.eq.or p8,p0=0x18,r23                   // Region 6 is UC for EFI
 (p9)cmp.eq.or.andcm p6,p7=IA64_ISR_CODE_LFETCH,r22     // check isr.code field
     dep r24=-1,r24,IA64_PSR_ED_BIT,1
     or r19=r19,r17                             // insert PTE control bits into 
r19
     mov r20=IA64_GRANULE_SHIFT<<2
     ;;
-    dep r19=r18,r19,4,1        // set bit 4 (uncached) if the access was to UC 
region
+(p8)dep r19=-1,r19,4,1                         // set bit 4 (uncached) if 
access to UC area
+
 (p6)mov cr.ipsr=r24
     mov cr.itir=r20
     ;;


-- 
yamahata

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