RE: [Xen-devel][VTD][PATCH][RESEND]add a timer for the sharedinterrupt issue for vt-d

["Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>]

The timer value is an experimental value to tolerate. My thought is that is there some possibility that assert-to-inject is too large and then the inject-to-eoi is too small that real interrupt for the HVM cannot be finished normally?

 

Thanks

Xiaohui  

 

---

From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
Sent: 2007年10月20日 19:24
To: Xin, Xiaohui; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel][VTD][PATCH][RESEND]add a timer for the sharedinterrupt issue for vt-d

 

On 20/10/07 12:04, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx> wrote:

For 2) Yes, firstly I think to use the flag of the domain as “is_pasued_by_controller”, but from the experience and from the log file, at the situation which IDE shares interrupt with NIC card, and when the NIC is assigned to HVM guest, “is pasued_by_controller” can deal with most cases, but after unpaused, there are still one or more interrupts can be scheduled. The “is_paused_by_controller” can not deal with all the cases.  So I still use timer to deal with that because timer is simple.

How about setting the timer unconditionally in hvm_do_IRQ_dpci() (i.e., as you do now), but then not touching it at all in vmx_dirq_assist()? Is there much point in resetting the timer in vmx_dirq_assist()? It seems to me you should have an assert-to-eoi latency that you are prepared to tolerate. Does separating out assert-to-inject and inject-to-eoi latencies actually make sense?

 -- Keir

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