From: Christoffer Dall <christoffer.dall@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Andre Przywara <andre.przywara@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] KVM: arm/arm64: Remove struct vgic_irq pending field
Date: Mon, 23 Jan 2017 17:06:50 +0100 [thread overview]
Message-ID: <20170123160650.GF15850@cbox> (raw)
In-Reply-To: <ef1d4338-8348-74a7-390d-dcc60fc47607@arm.com>
On Mon, Jan 23, 2017 at 03:44:16PM +0000, Marc Zyngier wrote:
> On 23/01/17 13:39, Christoffer Dall wrote:
> > One of the goals behind the VGIC redesign was to get rid of cached or
> > intermediate state in the data structures, but we decided to allow
> > ourselves to precompute the pending value of an IRQ based on the line
> > level and pending latch state. However, this has now become difficult
> > to base proper GICv3 save/restore on, because there is a potential to
> > modify the pending state without knowing if an interrupt is edge or
> > level configured.
> >
> > See the following post and related message for more background:
> > https://lists.cs.columbia.edu/pipermail/kvmarm/2017-January/023195.html
> >
> > This commit gets rid of the precomputed pending field in favor of a
> > function that calculates the value when needed, irq_is_pending().
> >
> > The soft_pending field is renamed to pending_latch to represent that
> > this latch is the equivalent hardware latch which gets manipulated by
> > the input signal for edge-triggered interrupts and when writing to the
> > SPENDR/CPENDR registers.
> >
> > After this commit save/restore code should be able to simply restore the
> > pending_latch state, line_level state, and config state in any order and
> > get the desired result.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> I admit having lost a few brain cells looking at this patch, and I can't
> prove it wrong! ;-) I like the fact that it now provides a safe
> abstraction to the pending state, and that there is exactly *one* place
> where line_level is evaluated.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>
Thanks!
I suppose looking at this again, I don't need the
"irq_set_pending_latch()" indirection but I can just set this variable
directly. What do you think? Would it be cleaner?
-Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] KVM: arm/arm64: Remove struct vgic_irq pending field
Date: Mon, 23 Jan 2017 17:06:50 +0100 [thread overview]
Message-ID: <20170123160650.GF15850@cbox> (raw)
In-Reply-To: <ef1d4338-8348-74a7-390d-dcc60fc47607@arm.com>
On Mon, Jan 23, 2017 at 03:44:16PM +0000, Marc Zyngier wrote:
> On 23/01/17 13:39, Christoffer Dall wrote:
> > One of the goals behind the VGIC redesign was to get rid of cached or
> > intermediate state in the data structures, but we decided to allow
> > ourselves to precompute the pending value of an IRQ based on the line
> > level and pending latch state. However, this has now become difficult
> > to base proper GICv3 save/restore on, because there is a potential to
> > modify the pending state without knowing if an interrupt is edge or
> > level configured.
> >
> > See the following post and related message for more background:
> > https://lists.cs.columbia.edu/pipermail/kvmarm/2017-January/023195.html
> >
> > This commit gets rid of the precomputed pending field in favor of a
> > function that calculates the value when needed, irq_is_pending().
> >
> > The soft_pending field is renamed to pending_latch to represent that
> > this latch is the equivalent hardware latch which gets manipulated by
> > the input signal for edge-triggered interrupts and when writing to the
> > SPENDR/CPENDR registers.
> >
> > After this commit save/restore code should be able to simply restore the
> > pending_latch state, line_level state, and config state in any order and
> > get the desired result.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> I admit having lost a few brain cells looking at this patch, and I can't
> prove it wrong! ;-) I like the fact that it now provides a safe
> abstraction to the pending state, and that there is exactly *one* place
> where line_level is evaluated.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>
Thanks!
I suppose looking at this again, I don't need the
"irq_set_pending_latch()" indirection but I can just set this variable
directly. What do you think? Would it be cleaner?
-Christoffer
next prev parent reply other threads:[~2017-01-23 16:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-23 13:39 [PATCH] KVM: arm/arm64: Remove struct vgic_irq pending field Christoffer Dall
2017-01-23 13:39 ` Christoffer Dall
2017-01-23 15:44 ` Marc Zyngier
2017-01-23 15:44 ` Marc Zyngier
2017-01-23 16:06 ` Christoffer Dall [this message]
2017-01-23 16:06 ` Christoffer Dall
2017-01-23 16:30 ` Peter Maydell
2017-01-23 16:30 ` Peter Maydell
2017-01-23 18:33 ` Christoffer Dall
2017-01-23 18:33 ` Christoffer Dall
2017-01-23 17:57 ` Andre Przywara
2017-01-23 17:57 ` Andre Przywara
2017-01-23 18:34 ` Christoffer Dall
2017-01-23 18:34 ` Christoffer Dall
2017-01-24 10:01 ` Andre Przywara
2017-01-24 10:01 ` Andre Przywara
2017-01-24 10:39 ` Christoffer Dall
2017-01-24 10:39 ` Christoffer Dall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170123160650.GF15850@cbox \
--to=christoffer.dall@linaro.org \
--cc=andre.przywara@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.