|
xen-devel
RE: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing(HVM/Do
>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: 2007年8月10日 15:37
>> How is the priority defined?
>
>It is defined dynamically by the move-to-back policy of the priority list.
Considering the sharing between high-speed device and low-speed
device, simple move-to-back policy (once EOI) is not most efficient.
At least we can take interrupt frequency as one factor of priority too.
>
>> What's reasonable time for different device requirement?
>
>For the timeout? Actually I'm not sure how important having a timeout
>actually is -- unless in the worst case it can reset the PCI device and
>ensure the line is quiesced in that way. Otherwise a non-responsive
>guest is
>unlikely to deassert its device and hence you cannot timeout and
>re-enable
>the interrupt line anyway. I consider this to be a secondary issue in
>implementing shared interrupts, and can reasonably be left until later.
>
Seems you are talking about a bogus case where guest is not willing
to handle the injection (like driver unload) but leaves device in assertion
state. Yes, for such bogus condition happen, there's nothing to do
except disabling the physical RTE.
While my question is about the efficiency of timeout under different
condition. Say the top of the list is HVM domain at the time, and
HVM domain has vRTE masked (driver unload, or previous injection is
in handle), in this case we may not want to inject now and wait same
'reasonable time' for non-response and instead move-to-back can
make effect immediately.
>> PV irq sharing takes response from all shared side, and Guy's RFC
>> only takes dom0's response. Now your suggestion is much simpler
>> toward timeout only, but what do you expect the final performance
>> to be?
>
>The timeout isn't part of this method's normal operation. The usual case
>will be that we deliver to just one guest -- at the front of our priority
>list -- and it was the correct single guest to deliver the interrupt to. In
This is hard to tell, since no clue to check whether it's right one due
to randomness of interrupt occurrence.
>
>Worst case is where multiple devices are issuing interrupts
>simultaneously,
>of course. In this case we do truely *need* to issue the interrupt to
>multiple guests. This will work, but be a bit slow. I think this is true of
>the Neocleus algorithm too, however.
>
>In conclusion, my algorithm works well when I run through it in my
>head. :-)
>
Definitely, this is a workable approach and can be applied to both
solutions. My concern is just how it behaves considering performance. :-)
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home