RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Thanks!  Looks like you found some very difficult bugs! 

> - Changing lazy PAL mapping switch to eager switch per domain 
> switch, since vti domain always depends on pal call.

Can you explain this?  Aren't PAL calls always intercepted
by Xen even with VTI?  It seems that the lazy PAL mapping
approach should work for VTI also.  It's a shame to spend all
those cycles on every context switch when PAL calls are so rare
(after initial startup anyway).

Thanks,
Dan

> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx] 
> Sent: Thursday, October 13, 2005 3:28 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-ia64-devel] [PATCH] fixed some bugs to make 
> xen0 more stable
> 
> Dan,
> 
> When we debugged VTIdomainN, we found and fixed some bugs.
> This patch is based on ver 7332
> 
> - Consistence of region id mangling algrithm:
>     - Metaphysical RID is not mangled, which may conflict 
> with other domain's virtual RID
>     - Sometimes rr0 is mangled, but sometimes not
>     - Sometimes only rid value is saved to 
> saved_rr0_metaphysical, but sometimes the whole value.
> 
> - Nat bit consumption happens but handled as priv_emulate to 
> forward progress.But this is definitely wrong. We found 
> reason of nat consumption from fast_rfi,which doesn't save 
> unat again after spill guest states, and then use guest unat 
> to fill guest states when return.
> 
> - In some corner case, timer interrupt handler won't update 
> itm and then return directly. When that happens, machine 
> timer interrupt disappears until guest timer interrupt sets 
> v_itm actively. But vti domain depends on ac_timer while the 
> latter will stop when above condition happens. Then if 
> current context is vti domain, context switch disappears and 
> machine halt.
> 
> Also many compatibility issues to support non-vti and vti 
> domain are solved,eg:
> - Changing lazy PAL mapping switch to eager switch per domain 
> switch, since vti domain always depends on pal call.
> - evtchn_notify should also vcpu_wake target domain, since 
> vti domain may block for io emulation. Xenolinux is free of 
> this issue, since it's always runnable.
> 
> 
> Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
> Signed-off-by Anthony Xu <anthony.xu@xxxxxxxxx>
> 
> 
> Thanks
> Anthony
> 
> 

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