Re: So I tried to use xentrace...

[George Dunlap <george.dunlap@eu.citrix.com>]

Jeremy Fitzhardinge wrote:
>>> (XEN) ----[ Xen-4.1-unstable  x86_64  debug=y  Not tainted ]----
>>> (XEN) CPU:    1
>>> (XEN) RIP:    e008:[<ffff82c4801215b3>] check_lock+0x1b/0x45
>>>     
>>>       
>
> This suggests the problem is with misusing a lock in the wrong interrupt
> context, rather than anything to do with sizes.
>   
Except that, it works for me if I use -S 32, and doesn't if I use -S 512 
(on my 2-core box, equivalent # of pages to -S 256 on your 4-core box). 
:-)  Try it, I suspect it will work.

Also:
* It's a page fault with a null pointer, not a bugcheck.  In a non-debug 
build, it will crash in spin_lock instead of check_lock.
* The fault is in the MMU update hypercall; I believe done when xentrace 
tries to map garbage pages or invalid MFNs.
* This is the exact bug we were getting in product, and the 
bounds-checking fixed it.

Hmm... the bounds checking should be working.  The maximum index is 
meant to be 2048 (2 pages = 8k,  / sizeof(uint32_t) = 2048), and the 
maximum index for you is  1088, well within the t_info size.  Hmm...

 -George