On 2012-08-14 15:14, Avi Kivity wrote: > On 08/14/2012 02:05 PM, Jan Kiszka wrote: >> On 2012-08-14 13:01, Avi Kivity wrote: >>> On 08/14/2012 10:33 AM, Jan Kiszka wrote: >>>> >>>> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e >>>> injection with feedback to allow lost-tick compensation) is the current >>>> standard that other archs should pick up. >>> >>> KVM_IRQ_LINE_STATUS may not make sense on all architectures. >>> >>> I don't think we're really deprecating KVM_IRQ_LINE or discouraging its >>> use. It's not like the kernel-allocated memory slot ioctls. >> >> I do not think it makes sense to provide both interfaces long term >> (provided we ever do a cut). Also, it's almost trivial to provide the >> add-on feature of KVM_IRQ_LINE_STATUS, and it keeps the door open for >> IRQ decoalescing. If there is no way for an arch to detect coalescing, >> it can still return >0 unconditionally. > > That's lying. I don't see how anything bad can come out of it, but we > can always be surprised. If we can't support something, let's not claim > we do.
Fortunately, we are not in this position on ARM. It has in in-kernel irqchip and can tell if some line is still being processed. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
