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

[Simon Horman <horms@xxxxxxxxxxxx>]

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.



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