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