removing event notification for HVM IRQ injection?

removing event notification for HVM IRQ injection?

[Dong, Eddie]

[-- Attachment #1.1: Type: text/plain, Size: 640 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1274 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: removing event notification for HVM IRQ injection?

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 852 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 1583 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: removing event notification for HVM IRQ injection?

[Dong, Eddie]

[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 2347 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: removing event notification for HVM IRQ injection?

[Steven Smith]

[-- Attachment #1.1: Type: text/plain, Size: 1107 bytes --]

> 	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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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