[Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

2018-11-28 Thread Andrii Anisov
From: Andrii Anisov An IRQ assigned to guest always has an action. This removes another odd check on guest IRQ path. Also getting an unknown interrupt is very unlikely on a non-debug platform. Signed-off-by: Andrii Anisov --- xen/arch/arm/irq.c | 14 +++--- 1 file changed, 7 insertions

Re: [Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

2018-12-11 Thread Julien Grall
Hi Andrii, On 28/11/2018 21:32, Andrii Anisov wrote: From: Andrii Anisov An IRQ assigned to guest always has an action. This removes another odd check on guest IRQ path. And you can't see any potential race in that code happening in the future? Also getting an unknown interrupt is very unl

Re: [Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

2018-12-12 Thread Andrii Anisov
On 11.12.18 16:48, Julien Grall wrote: And you can't see any potential race in that code happening in the future? It is protected with `desc->lock` so far. If one decided to get it from under the lock, the race is possible with `release_irq()`. Also getting an unknown interrupt is very unli

Re: [Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

2018-12-12 Thread Julien Grall
On 12/12/2018 11:30, Andrii Anisov wrote: On 11.12.18 16:48, Julien Grall wrote: And you can't see any potential race in that code happening in the future? It is protected with `desc->lock` so far. If one decided to get it from under the lock, the race is possible with `release_irq()`. A

Re: [Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

2018-12-12 Thread Andrii Anisov
Julien, On 12.12.18 13:59, Julien Grall wrote: An ASSERT(...) is already embed in irq_get_guest_info(desc). Yep. I thought about the ASSERT(...) over the current printk yesterday. But I discarded it because it does not give you more information if something went really wrong as the stack t

Re: [Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

2018-12-12 Thread Julien Grall
Hi, On 12/12/2018 13:51, Andrii Anisov wrote: Julien, On 12.12.18 13:59, Julien Grall wrote: An ASSERT(...) is already embed in irq_get_guest_info(desc). Yep. I thought about the ASSERT(...) over the current printk yesterday. But I discarded it because it does not give you more information

Re: [Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

2018-12-12 Thread Andrii Anisov
On 12.12.18 16:49, Julien Grall wrote: ASSERT only tells you that desc->action was NULL. It does not tell you which IRQ has the desc->action == NULL. Ah, yes. It is a bit a shame we don't have way to provide another message with ASSERT to help you debugging. We might have implemented an a

Re: [Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

2018-12-12 Thread Julien Grall
On 12/12/2018 14:58, Andrii Anisov wrote: On 12.12.18 16:49, Julien Grall wrote: ASSERT only tells you that desc->action was NULL. It does not tell you which IRQ has the desc->action == NULL. Ah, yes. It is a bit a shame we don't have way to provide another message with ASSERT to help you

Re: [Xen-devel] [RFC 11/16] irq: skip action avalability check for guest's IRQ

2018-12-12 Thread Andrii Anisov
On 12.12.18 17:08, Julien Grall wrote: Is it just because it adds a couple more instruction in the guest case? And add unlikely for XEN IRQ case. That was the idea. The check is mainly there to catch error in debug build. I supposed a race with `release_irq()`, but found out that we are safe