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
|
Home