Xen devel - Oct 2006 - removing event notification for HVM IRQ injection?

Steven:
	When looking at improving the HVM TPR acceleration, I noticed
your previous patch (CSET:10974) replaced evtchn_set_pending in both
hlt_timer_fn & vlapic_accept_irq with hvm_prod_vcpu. I am not sure for
the purpose but at least one thing is missed after this patch: previous
evtchn_set_pending may use physical IPI to interrupt target VP while
hvm_prod_vcpu not. If the target VP is running, delivering guest IRQ  (
both hlt_timer_fn & vlapic_accept_irq ) to a running VP have to use
physical IPI to interrupt the execution to inject IRQ, without this the
logic may be wrong.
	Can u share more lights with us?
thx,eddie


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

On 20/10/06 10:10 am, "Dong, Eddie" <eddie.dong@intel.com>
wrote:
>         When looking at improving the HVM TPR acceleration, I noticed your
> previous patch (CSET:10974) replaced evtchn_set_pending in both
hlt_timer_fn &
> vlapic_accept_irq with hvm_prod_vcpu. I am not sure for the purpose but at
> least one thing is missed after this patch: previous evtchn_set_pending may
> use physical IPI to interrupt target VP while hvm_prod_vcpu not. If the
target
> VP is running, delivering guest IRQ  ( both hlt_timer_fn &
vlapic_accept_irq )
> to a running VP have to use physical IPI to interrupt the execution to
inject
> IRQ, without this the logic may be wrong.
> 
>         Can u share more lights with us?
I suggest killing hvm_prod_vcpu() entirely and callers use vcpu_kick()
instead. I think vcpu_kick() does exactly what you want.

 -- Keir



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

That looks fine:-)

________________________________

From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
Sent: 2006年10月21日 2:09
To: Dong, Eddie; ssmith@xensource.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] removing event notification for HVM IRQ injection?


On 20/10/06 10:10 am, "Dong, Eddie" <eddie.dong@intel.com>
wrote:



	       When looking at improving the HVM TPR acceleration, I noticed your
previous patch (CSET:10974) replaced evtchn_set_pending in both hlt_timer_fn
& vlapic_accept_irq with hvm_prod_vcpu. I am not sure for the purpose but at
least one thing is missed after this patch: previous evtchn_set_pending may use
physical IPI to interrupt target VP while hvm_prod_vcpu not. If the target VP is
running, delivering guest IRQ  ( both hlt_timer_fn & vlapic_accept_irq ) to
a running VP have to use physical IPI to interrupt the execution to inject IRQ,
without this the logic may be wrong.
	
	        Can u share more lights with us? 
	


I suggest killing hvm_prod_vcpu() entirely and callers use vcpu_kick() instead.
I think vcpu_kick() does exactly what you want.

 -- Keir



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

> 	When looking at improving the HVM TPR acceleration, I noticed
> your previous patch (CSET:10974) replaced evtchn_set_pending in both
> hlt_timer_fn & vlapic_accept_irq with hvm_prod_vcpu. I am not sure for
> the purpose
The aim here was to make sure that HVM domains could use Xen event
channels normally without interfering with the device model''s use of
them.  Previously, the device model fired an event channel into the
HVM domain to tell it to wake up, and this could cause problems (or at
least confusion) if the domain was trying to use event channels for
its own purposes.  After this patch, the device model event channel
terminates in Xen, which is much easier to work with.
> but at least one thing is missed after this patch: previous
> evtchn_set_pending may use physical IPI to interrupt target VP while
> hvm_prod_vcpu not. If the target VP is running, delivering guest IRQ  (
> both hlt_timer_fn & vlapic_accept_irq ) to a running VP have to use
> physical IPI to interrupt the execution to inject IRQ, without this the
> logic may be wrong.
I think Keir already answered this.

Steven.


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