[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [RFC PATCH] pseries: use qemu_irq_raise() in spapr_msi_wr
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [RFC PATCH] pseries: use qemu_irq_raise() in spapr_msi_write() |
Date: |
Sat, 28 May 2016 13:10:58 +1000 |
User-agent: |
Mutt/1.6.1 (2016-04-27) |
On Fri, May 27, 2016 at 03:55:32PM +0800, Li Zhong wrote:
>
> > On May 27, 2016, at 09:38, David Gibson <address@hidden> wrote:
> >
> > On Tue, May 10, 2016 at 09:18:13AM +0800, Li Zhong wrote:
> >> It seems that both ics_set_irq() and ics_kvm_set_irq() don't do anything
> >> useful for MSIs with val = 0, so maybe the pulse in spapr_msi_write()
> >> could be replaced with a single raise?
> >>
> >> Signed-off-by: Li Zhong <address@hidden <mailto:address@hidden>>
> >
> > I'm not clear. Does the current code actually cause problems? Or are
> > you just suggesting a cleanup?
>
> I think it’s some sort of cleanup, though my original intention was to save a
> function call and some condition checks in the code path. No real problems.
Yeah, I can't imagine that call is a meaningful overhead, especially
since I suspect it may get inlined.
> > I believe the convention in qemu is that edge or message triggered
> > interrupts are tripped with qemu_irq_pulse().
>
> After thinking more about the concept, and checking more code, I agree
> it is the convention to use the qemu_irq_pulse() to keep the “irq state” as
> lowered. However, as qemu_irq maintains the irq state through its
> handler, so it depends on the handler’s implementation whether a
> qemu_irq_lower() is needed?
Yeah, unless we observe this causing a real problem I think I'll just
leave this as is.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature