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


[Xen-devel] xen_tlb_flush_all mfn validation panic

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] xen_tlb_flush_all mfn validation panic
From: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Date: Thu, 24 Dec 2009 15:06:24 +0000
Delivery-date: Thu, 24 Dec 2009 07:06:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I'm seeing the following when trying to boot a guest domain with the
current xen-unstable:

(XEN) mm.c:2695:d0 Bad gmfn_to_mfn                                              
------------[ cut here ]------------                                            
kernel BUG at /home/kjm/xen/linux-2.6.18-xen.hg/arch/i386/mm/hypervisor.c:123!  
invalid opcode: 0000 [#1]                                                       
Modules linked in: video thermal processor fan container button battery asus_acd
CPU:    0                                                                       
EIP:    0061:[<c011d145>]    Not tainted VLI                                    
EFLAGS: 00010282   ( #1)                                           
EIP is at xen_tlb_flush_all+0x35/0x40                                           
eax: fffffff2   ebx: deadbeef   ecx: deadbeef   edx: deadbeef                   
esi: deadbeef   edi: c5350dc8   ebp: cf877dcc   esp: cf877db8                   
ds: 007b   es: 007b   ss: 0069                                                  
Process xenwatch (pid: 9, ti=cf876000 task=cf855030 task.ti=cf876000)           
Stack: 0000000a ffffffff c5388000 d11ba000 05350067 cf877e80 c0166610 00000000  
       00000000 c01310fa cf877dfc 00000000 00000000 00000001 00000000 0001bf06  
       cf877e24 8f0560fc 00000150 00000067 00000000 05350000 00000000 00000063  
Call Trace:                                                                     
 [<c0106221>] show_stack_log_lvl+0xb1/0xe0                                      
 [<c0106486>] show_registers+0x1b6/0x240                                        
 [<c0106641>] die+0x131/0x330                                                   
 [<c01068d8>] do_trap+0x98/0xe0                                                 
 [<c0107170>] do_invalid_op+0xa0/0xb0                                           
 [<c0105d5b>] error_code+0x2b/0x30                                              
 [<c0166610>] unmap_vm_area+0x330/0x370                                         
 [<c0166694>] __remove_vm_area+0x44/0x60                                        
 [<c01666cb>] remove_vm_area+0x1b/0x30                                          
 [<c0316c44>] free_vm_area+0x14/0x30                                            
 [<c032648e>] netif_disconnect+0xce/0x180                                       
 [<c0325c3f>] frontend_changed+0x26f/0x630                                      
 [<c0314e55>] otherend_changed+0xa5/0xb0                                        
 [<c0312c71>] xenwatch_handle_callback+0x21/0x60                                
 [<c0313a15>] xenwatch_thread+0x135/0x150                                       
 [<c013c266>] kthread+0x106/0x110                                               
 [<c0103005>] kernel_thread_helper+0x5/0x10                                     
Code: 83 ec 14 89 5d f8 8d 5d ec 89 75 fc be f0 7f 00 00 c7 45 ec 0a 00 00 00 e 
EIP: [<c011d145>] xen_tlb_flush_all+0x35/0x40 SS:ESP 0069:cf877db8 

The initial "bad gmfn" message seems to be due to an attempt to validate
the mfn argument to the mmuext_op.  It's not surprising to me that this
fails as xen_tlb_flush_all doesn't supply an mfn argument - it's not
needed for the MMUEXT_TLB_FLUSH_ALL command.  Is there something that is
supposed to mean that the mfn argument should be valid even when not
explicitly set by the caller, or is the validation of the mfn for all
mmuext_op commands a bug?



Xen-devel mailing list

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