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

RE: [Xen-devel] [PATCH] remove HVM halt timer


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
  • Date: Fri, 10 Nov 2006 16:59:34 +0800
  • Delivery-date: Fri, 10 Nov 2006 01:00:45 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AccEnswNUkAD/BhaQT+W4uZ/emiWdAAAYqyKAABK//AAAKXPCwAAhOTw
  • Thread-topic: [Xen-devel] [PATCH] remove HVM halt timer

>The advantage of the blocking hypercall is that it safely checks
>local_events_need_delivery() before actually blocking. This is 
>necessary to
>avoid wakeup-waiting races. Now, this doesn't actually work 
>for HVM guests
>(yet) as it checks the wrong condition (event-channel upcall 
>flag rather
>than state of the PIC/LAPIC) *but* it will mean that when the
>local_events_need_delivery() macro is fixed, the blocking 
>hypercall will
>automatically do the right thing for us. The blocking code in 
>your patch
>will not.

New patch attached.


>
>If you want to collect stats when you're scheduled out, the 
>correct place to
>do that is context_switch(). But we already collect generic 
>scheduler stats
>and generate trace entries. What else might be of interest?
>

Some vmexit info there, acturally current way should work too, but I
don't want to insert code in multiple place.

-Xin

Attachment: remove_hvm_halt_timer.2.patch
Description: remove_hvm_halt_timer.2.patch

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

 


Rackspace

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