From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 3/9] KVM: arm/arm64: Don't cache the timer IRQ level
Date: Tue, 19 Dec 2017 21:35:20 +0100 [thread overview]
Message-ID: <20171219203520.GD5380@cbox> (raw)
In-Reply-To: <517ead96-a689-d6f6-564f-67b1cd020daf@arm.com>
On Tue, Dec 19, 2017 at 02:17:38PM +0000, Julien Thierry wrote:
> Hi Christoffer,
>
> A few nits in the commit message.
>
> On 13/12/17 10:45, Christoffer Dall wrote:
> >The timer was modeled after a strict idea of modelling an interrupt line
>
> nit: modelling (also, modeled after a strict idea of modelling?)
>
Yes, I model the modelling of models of modeled timers. Is that not
clear? ;)
> >level in software, meaning that only transitions in the level needed to
>
> s/needed/need/ ?
>
ack
> >be reported to the VGIC. This works well for the timer, because the
> >arch timer code is in complete control of the device and can track the
> >transitions of the line.
> >
> >However, as we are about to support using the HW bit in the VGIC not
> >just for the timer, but also for VFIO which cannot track transitions of
> >the interrupt line, we have to decide on an interface for level
> >triggered mapped interrupts to the GIC, which both the timer and VFIO
>
> "level triggered interrupts mapped to the GIC" ?
>
an interface to the GIC for level ...
My writing here is really crap. Thanks for pointing that out.
> >can use.
> >
> >VFIO only sees an asserting transition of the physical interrupt line,
> >and tells the VGIC when that happens. That means that part of the
> >interrupt flow is offloaded to the hardware.
> >
> >To use the same interface for VFIO devices and the timer, we therefore
> >have to change the timer (we cannot change VFIO because it doesn't know
> >the details of the device it is assigning to a VM).
> >
> >Luckily, changing the timer is simple, we just need to stop 'caching'
> >the line level, but instead let the VGIC know the state of the timer
> >every time there is a potential change in the line level, and when the
> >line level should be asserted from the timer ISR. The VGIC can ignore
> >extra notifications using its validate mechanism.
> >
> >Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> >Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
>
Thanks,
-Christoffer
next prev parent reply other threads:[~2017-12-19 20:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 10:45 [PATCH v8 0/9] Handle forwarded level-triggered interrupts Christoffer Dall
2017-12-13 10:45 ` [PATCH v8 1/9] KVM: arm/arm64: Remove redundant preemptible checks Christoffer Dall
2017-12-13 10:45 ` [PATCH v8 2/9] KVM: arm/arm64: Factor out functionality to get vgic mmio requester_vcpu Christoffer Dall
2017-12-13 10:45 ` [PATCH v8 3/9] KVM: arm/arm64: Don't cache the timer IRQ level Christoffer Dall
2017-12-13 19:38 ` Marc Zyngier
2017-12-19 14:17 ` Julien Thierry
2017-12-19 20:35 ` Christoffer Dall [this message]
2017-12-13 10:45 ` [PATCH v8 4/9] KVM: arm/arm64: vgic: Support level-triggered mapped interrupts Christoffer Dall
2017-12-13 10:45 ` [PATCH v8 5/9] KVM: arm/arm64: Support a vgic interrupt line level sample function Christoffer Dall
2017-12-13 10:45 ` [PATCH v8 6/9] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs Christoffer Dall
2017-12-13 10:46 ` [PATCH v8 7/9] KVM: arm/arm64: Provide a get_input_level for the arch timer Christoffer Dall
2017-12-13 19:45 ` Marc Zyngier
2017-12-13 10:46 ` [PATCH v8 8/9] KVM: arm/arm64: Avoid work when userspace iqchips are not used Christoffer Dall
2017-12-13 20:05 ` Marc Zyngier
2017-12-19 13:34 ` Christoffer Dall
2017-12-19 13:55 ` Marc Zyngier
2017-12-19 14:18 ` Christoffer Dall
2017-12-19 14:32 ` Marc Zyngier
2017-12-13 10:46 ` [PATCH v8 9/9] KVM: arm/arm64: Update timer and forwarded irq documentation Christoffer Dall
2017-12-13 20:15 ` Marc Zyngier
2017-12-19 20:29 ` Christoffer Dall
2017-12-19 20:35 ` Marc Zyngier
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=20171219203520.GD5380@cbox \
--to=christoffer.dall@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).