[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Thu, 13 Oct 2005 10:47:11 -0700
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 13 Oct 2005 17:44:21 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcXP2HRI83rf2/ODRBuc5moDrgGuwgAGusrwAAqDThA=
  • Thread-topic: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.