On 10.06.19 22:51, Julien Grall wrote:
I was. But I also had time to think about the commit message and I would be
happy to commit with just what it is currently written.
I have now applied to my staging branch with my acked-by. I will commit it
tonight.
Great. Thank you.
Thank you for
On 6/10/19 4:49 PM, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
On 31.05.19 20:11, Julien Grall wrote:
Here my take on the commit message:
gic_interrupt() was implemented using a loop to limit the cost of the
trap if there are multiple interrupts pending.
At the moment, interrupts ar
Hello Julien,
On 31.05.19 20:11, Julien Grall wrote:
Here my take on the commit message:
gic_interrupt() was implemented using a loop to limit the cost of the trap if
there are multiple interrupts pending.
At the moment, interrupts are unmasked by gic_interrupt() before calling do_{IRQ,
LPI
On Fri, 31 May 2019, Julien Grall wrote:
> Hi Andrii,
>
> On 30/05/2019 17:12, Andrii Anisov wrote:
> > On 29.05.19 18:32, Julien Grall wrote:
> > > It would have been nice to at least fix up the commit message with the
> > > typoes (and rewording) I mentioned in my previous e-mail.
> > > Your com
On 31/05/2019 18:25, Andre Przywara wrote:
On Tue, 28 May 2019 18:07:19 +0100
Julien Grall wrote:
[ ... ]
While looking at the code, I noticed that in the new vgic vgic_get_irq()
looks unsafe to be called with interrupt unmasked. This is because one
of the callee (vgic_get_lpi()) takes a sp
On Fri, 31 May 2019 18:16:52 +0100
Julien Grall wrote:
> Hi,
>
> On 30/05/2019 17:14, Andrii Anisov wrote:
> >
> >
> > On 29.05.19 18:32, Julien Grall wrote:
> >>> BTW, do you hear about plans for the new vgic? Some time ago it was said
> >>> that
> >>> new vgic implementation going to rep
On Tue, 28 May 2019 18:07:19 +0100
Julien Grall wrote:
[ ... ]
> While looking at the code, I noticed that in the new vgic vgic_get_irq()
> looks unsafe to be called with interrupt unmasked. This is because one
> of the callee (vgic_get_lpi()) takes a spinlock and not a spinlock_irq.
> Andre,
Hi,
On 30/05/2019 17:14, Andrii Anisov wrote:
On 29.05.19 18:32, Julien Grall wrote:
BTW, do you hear about plans for the new vgic? Some time ago it was said that
new vgic implementation going to replace the old one, and optimizing the old
is worthless. But as I see, there are no updates int
Hi Andrii,
On 30/05/2019 17:12, Andrii Anisov wrote:
On 29.05.19 18:32, Julien Grall wrote:
It would have been nice to at least fix up the commit message with the typoes
(and rewording) I mentioned in my previous e-mail.
Your commit message needs to explained why this is fine to keep the interr
On 29.05.19 18:32, Julien Grall wrote:
BTW, do you hear about plans for the new vgic? Some time ago it was said that
new vgic implementation going to replace the old one, and optimizing the old is
worthless. But as I see, there are no updates into that area yet.
We need help to make it happ
On 29.05.19 18:32, Julien Grall wrote:
It would have been nice to at least fix up the commit message with the typoes
(and rewording) I mentioned in my previous e-mail.
Your commit message needs to explained why this is fine to keep the interrupt
masked a bit longer. I wrote the explanation in
On 29/05/2019 11:31, Andrii Anisov wrote:
Hello Julien,
Hi,
On 28.05.19 20:07, Julien Grall wrote:
Title: Interrupts are still unmasked when executing action for interrupt
routed to Xen. So you need to be more specific. How about
"xen/arm: gic: Defer the decision to unmask interrupts to do
Hello Julien,
On 28.05.19 20:07, Julien Grall wrote:
Title: Interrupts are still unmasked when executing action for interrupt routed
to Xen. So you need to be more specific. How about
"xen/arm: gic: Defer the decision to unmask interrupts to do_{LPI, IRQ}()"?
Looks good.
On 5/27/19 10:29 A
(+ Andre)
Hi,
Title: Interrupts are still unmasked when executing action for interrupt
routed to Xen. So you need to be more specific. How about
"xen/arm: gic: Defer the decision to unmask interrupts to do_{LPI, IRQ}()"?
On 5/27/19 10:29 AM, Andrii Anisov wrote:
From: Andrii Anisov
This re
From: Andrii Anisov
This reduces the number of context switches in case we have coming guest
interrupts from different sources at a high rate. What is likely for
multimedia use-cases.
Having irqs unlocked here makes us go through trap path again in case we
have a new guest interrupt arrived (even
15 matches
Mail list logo
