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/
Home Products Support Community News


Re: [Xen-ia64-devel] Reserved Register/Field fault not correct handledin

To: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-ia64-devel] Reserved Register/Field fault not correct handledin Xen?
From: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>
Date: Tue, 12 Dec 2006 21:34:02 +0900
Delivery-date: Tue, 12 Dec 2006 04:32:45 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200612121204.03472.dietmar.hahn@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>
References: <200612121204.03472.dietmar.hahn@xxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi, Dietmar

>I had a closer look to my problem described on
>Now I can reproduce the panic in Xen with a dom0-user program.
>The instructions
>movl r16=0xff;;
>mov ar.rsc=r16
>lead to a general exception with function code 0x30 (Reserved Register/Field 
>The trap handler in ivt.S checks only function code <=0x20.
>The other exceptions call dispatch_to_fault_handler() and further 
>In ia64_fault() there is only a check on function code 0x80 (Illegal 
>dependency fault). The function codes 0x30 (Reserved Register/Field fault) 
>and 0x40 lead to the xen-panic!
You are right.

>It seems the code was copied from the linux ia64_fault() routine. But there 
>a call of die_if_kernel(...) and if not kernel a call of 
>force_sig(SIGILL, ...) to kill the user process.
>I believe the solution is here to use FAULT_OR_REFLECT(24) in the trap 
>if the function code is > 0x20 and to extend the ia64_handle_reflection() 
>with handling the vector=24.
>With this 2 fixes the user program gets a SIGILL like on native linux.
>and my mini-os traphandler gets called from the hypervisor, so I can handle 
>the trap on my own.
>Do I see something complete wrong or should I send a patch?
I think your suggestion is almost right.
But should the folloing IA64_ISR_CODE_LFETCH be checked?
(because Privilege Register Fault may be occurred on guest.)

 393         if ((isr & IA64_ISR_NA) &&
 394             ((isr & IA64_ISR_CODE_MASK) == IA64_ISR_CODE_LFETCH)) {
 395                 /*
 396                  * This fault was due to lfetch.fault, set "ed" bit in the
 397                  * psr to cancel the lfetch.
 398                  */
 399                 ia64_psr(regs)->ed = 1;
 400                 printk("ia64_fault: handled lfetch.fault\n");
 401                 return;
 402         }

Could you send patches?

Best Regards,

Akio Takebe

Xen-ia64-devel mailing list