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

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

I am hot on the trail of a bug in vcpu_translate where
itir is getting incorrectly set.  I think I have it
fixed but will need to run tests for a few hours. 

> -----Original Message-----
> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx] 
> Sent: Thursday, October 13, 2005 7:33 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make 
> xen0 more stable
> 
> I didn't see segment fault, I saw some vcpu_translate faults, 
> and it didn't impact the process of build. I'll look into this bug.
> 
> >-----Original Message-----
> >From: Magenheimer, Dan (HP Labs Fort Collins) 
> [mailto:dan.magenheimer@xxxxxx]
> >Sent: 2005å10æ14æ 1:47
> >To: Xu, Anthony
> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >Subject: RE: [Xen-ia64-devel] [PATCH] fixed some bugs to 
> make xen0 more stable
> >
> >> > - 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).
> >
> >After further thought, I'm not going to argue this right now
> >as itâs a very small fraction of context switch overhead.
> >If it proves to be a problem, we can fix it back later.
> >
> >However, my testing is not going well so far.  I had just
> >completed compiling Linux 15 times on tip (with Tristan's
> >SMP patch) without any problems, but 2 of 5 runs so far with
> >this new patch failed with segment faults.
> >
> >Any ideas of what might be causing this?  I can test with
> >a subset of the patch...
> >
> >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