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