RE: [Xen-ia64-devel] metaphysical mode

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> Is below scenario possible?

I agree that it appears theoretically possible.  Do you
have a reproducible test case that demonstrates it
happening (e.g. causes the domain to panic where the
faulting address is near ar.bsp)?  

If not, a reasonable solution for now might be to change
the panic_domain message to something like "see
xen/arch/ia64/technote/metaphysical" and add this
file with your explanation and proposed fix.  Then
we could revisit it when we have more functionality
working and a good regression suite to test it to
ensure other bugs don't get introduced by the change.
I am hesitant to fix theoretical bugs that might
introduce instability when so many other things
need to be done.

> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx] 
> Sent: Thursday, December 01, 2005 12:17 AM
> To: Magenheimer, Dan (HP Labs Fort Collins); 
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] metaphysical mode
> 
> Dan,
> There definitely has idr(101) mode, when nested data tlb 
> fault or vhpt fault happen, linux will turn off psr.dt and 
> walk three level page table to get correct pte.
> Is below scenario possible?
> 1. Linux OS turn off psr.dt in nested data tlb handler, that 
> means metaphysical=1.
> 2. Linux OS walks through tree level page table using 
> physical address, 
> 3. It is possible data tlb miss happens ( machine psr dt 
> always be turned on) when linux OS walk through tree level 
> page table, then control goes to HV,
> 4. HV handles this tlb miss and "rfi" to linux OS kernel.
> 5. Guest may have his register stack frame (which may belong 
> to linux application, or linux kernel), so this "rfi" may 
> cause mandatory RSE load, if corresponding tlb is gone, 
> another data tlb miss happens.
> 6. At this time, metaphysical=1 and ifa does not belong to region 0,
> Current implementation can't handle this scenario, because 
> there are not guest psr it dt rt information.
> 
> Current implementation is,
> 
>     if (PSCB(vcpu,metaphysical_mode) && !(!is_data && region)) {
>         // dom0 may generate an uncacheable physical address (msb=1)
>         if (region && ((region != 4) || (vcpu->domain != dom0))) {
> // FIXME: This seems to happen even though it shouldn't.  
> Need to track
> // this down, but since it has been apparently harmless, just 
> flag it for now
> //          panic_domain(vcpu_regs(vcpu),
>             printk(
>              "vcpu_translate: bad physical address: %p\n",address);
>         }
>         *pteval = (address & _PAGE_PPN_MASK) | __DIRTY_BITS | 
> _PAGE_PL_2 | _PAGE_AR_RWX;
>         *itir = PAGE_SHIFT << 2;
>         phys_translate_count++;
>         return IA64_NO_FAULT;
>     }
>     else if (!region && warn_region0_address) {
>         REGS *regs = vcpu_regs(vcpu);
>         unsigned long viip = PSCB(vcpu,iip);
>         unsigned long vipsr = PSCB(vcpu,ipsr);
>         unsigned long iip = regs->cr_iip;
>         unsigned long ipsr = regs->cr_ipsr;
>         printk("vcpu_translate: bad address %p, viip=%p, 
> vipsr=%p, iip=%p, ipsr=%p continuing\n", address, viip, 
> vipsr, iip, ipsr);
>     }
> 
> If we have it dt rt information, the implementation will be 
> simple and clear.
> if( is metaphysical){
>       if(isr.x==1){           // instruction tlb miss  
>               if( is region 0)
>                               handle it;
>               else
>                       Unimplemented address space fault;
>       }
>       Else (isr.rs==1){    // caused by mandatory RSE access
>               If( is region 0)
>                               Handle it;
>               Else
>                       Unimplemented address space fault;
>       }
>       Else{   // caused by memory access
>               If( is region 0 or 4)
>                               Handle it;
>               Else
>                       Unimplemented address space fault;
>       }
> }
> 
> Thanks
> -Anthony
> 
> >-----Original Message-----
> >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On 
> Behalf Of Magenheimer,
> >Dan (HP Labs Fort Collins)
> >Sent: 2005å12æ1æ 7:55
> >To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: [Xen-ia64-devel] metaphysical mode
> >
> >Anthony's recent proposed patch reminded me of some
> >documentation about metaphysical mode that I had written
> >some time ago.  I thought I had sent this out, but
> >could not find it on the list, so I cleaned it up
> >a bit and am sending it out now.  This isn't intended
> >to imply that the design/implementation is cast in stone,
> >just to describe the intent.
> >
> >Dan
> >
> >===============
> >
> >Paravirtualization allows us to slightly modify an architecture
> >to disallow or change the semantics for certain operations in
> >order to obtain a substantial performance gain.  One usage of
> >paravirtualization on Xen/ia64 involves the usage of physical
> >addressing:
> >
> >There are three translation bits in IPF's psr to determine whether
> >an address to be used is physical or virtual, one bit each to
> >control instruction access, data access, and register stack
> >access, respectively psr.it, psr.dt, and psr.rt.  Some
> >combinations of these bits can be very difficult to
> >fully virtualize with adequate performance; an IPF
> >OS executes physical accesses frequently enough that trapping
> >every physical access (and possibly emulating physical
> >instruction accesses) is too slow.  Ideally, we would like
> >to allow guest physical addresses to be translated to machine
> >addresses using the existing virtual addressing hardware
> >and mechanisms.
> >
> >The resulting implementation on Xen/ia64 (heavily leveraged
> >from the HP vBlades project) is called metaphysical memory.
> >When a guest enters "metaphysical mode", the physical psr
> >it/dt/rt bits remain set (virtual addressing) and region
> >register 0 is changed to use a per-guest reserved region id.
> >
> >The implementation of metaphysical mode has some ramifications.
> >When metaphysical=1:
> >- all guest accesses in region 0 are accesses to (meta)physical
> >  memory
> >- guest data accesses outside of region 0 are also accesses
> >  to metaphysical memory, but since no guest will be assigned
> >  physical memory with an address that large, all data accesses
> >  outside of region 0 will result in a [TBD] fault
> >- instruction data accesses outside of region 0 are executed
> >  as if they are virtual accesses
> >- a guest may not set all combinations of the psr it/dt/rt bits.
> >  Attempts to set these combinations results in a Reserved
> >  register/field fault [note: not currently implemented]
> >
> >     idr     <--psr.it, psr.dt, psr.rt
> >     000     metaphysical mode
> >     001     not permitted
> >     010     not permitted
> >     011     not currently permitted [should it be?]
> >     100     metaphysical mode
> >     101     not permitted
> >     110     not permitted
> >     111     virtual mode (metaphysical=0)
> >
> >- reads of psr.it/dt/rt (mov psr.l= instruction) may not reflect
> >  the bits that were last set
> >- delivery of an interruption does not change the state of
> >  metaphysical mode and ipsr.it/dt/rt bits are set to [???]
> >
> >_______________________________________________
> >Xen-ia64-devel mailing list
> >Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >http://lists.xensource.com/xen-ia64-devel
> 

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