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: [PATCH] Fix mca handler so as not to destroy ar(was: Re: [Xen-ia64-d

To: SUZUKI Kazuhiro <kaz@xxxxxxxxxxxxxx>
Subject: Re: [PATCH] Fix mca handler so as not to destroy ar(was: Re: [Xen-ia64-devel] Re: mca handler)
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Mon, 28 Jul 2008 11:20:05 +0900
Cc: yutaka.ezaki@xxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 27 Jul 2008 19:20:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080725.174737.135665615.kaz@xxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080717025446.GB25137%yamahata@xxxxxxxxxxxxx> <20080723.111057.45162041.kaz@xxxxxxxxxxxxxxxxxx> <20080725.174737.135665615.kaz@xxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
On Fri, Jul 25, 2008 at 05:47:37PM +0900, SUZUKI Kazuhiro wrote:
> The following patch fixes the mca handler so as not to destroy ar
> and some bugs.

Thank you for fixing some bugs and it looks basically good.
Some comments below.


> @@ -524,24 +457,111 @@ ia64_reload_tr:
>       srlz.d
>       ;;
>  #ifdef XEN
> -.reload_vhpt:
> -     // 5. VHPT
> -       GET_THIS_PADDR(r1, inserted_vhpt);;
> -       cmp.eq p7,p0=r2,r0
> -(p7)   br.cond.sptk    .overlap_vhpt   // vhpt isn't mapped.
> +     // 5. shared_info
> +     GET_THIS_PADDR(r2, inserted_shared_info);;
> +     ld8 r16=[r2]
> +     mov r18=XSI_SHIFT<<2
> +     movl r20=__pgprot(__DIRTY_BITS | _PAGE_PL_PRIV | _PAGE_AR_RW)
> +     ;;
> +     GET_THIS_PADDR(r2, domain_shared_info);;
> +     ld8 r17=[r2]
> +     ;;
> +     dep r17=0,r17,60,4
> +     ;; 
> +     or r17=r17,r20                  // construct PA | page properties
> +     mov cr.itir=r18
> +     mov cr.ifa=r16
> +     ;;
> +     mov r16=IA64_TR_SHARED_INFO
> +     ;;
> +     itr.d dtr[r16]=r17              // wire in new mapping...
> +     ;; 
> +     srlz.d
> +     ;; 

Unconditionally pinning down shared_info into inserted_shared_info
is wrong because shared_info is shared only with PV domain and xen VMM.
So In VMX domain case, it shouldn't pinned down. Otherwise VMX guest
wrongly accesses to shared_info.
In ia64_do_tlb_purge() case, unconditionally purging
DTR[IA64_TR_SHARED_INFO] is okay, but unconditionally inserting
DTR[IA64_TR_SHARED_INFO] is bad.

thanks,
-- 
yamahata

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