WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] metaphysical mode

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] metaphysical mode
From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Thu, 1 Dec 2005 15:17:20 +0800
Delivery-date: Thu, 01 Dec 2005 07:17:06 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcX2CYSRKFg65Y42SMaLa72Va1Q7MgAN5HWA
Thread-topic: [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

<Prev in Thread] Current Thread [Next in Thread>