From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 10/15] KVM: arm64: connect LPIs to the VGIC emulation
Date: Wed, 22 Jun 2016 18:02:55 +0100 [thread overview]
Message-ID: <576AC4BF.2070900@arm.com> (raw)
In-Reply-To: <576ABC50.6000201@arm.com>
On 22/06/16 17:26, Marc Zyngier wrote:
> On 17/06/16 13:08, Andre Przywara wrote:
>> LPIs are dynamically created (mapped) at guest runtime and their
>> actual number can be quite high, but is mostly assigned using a very
>> sparse allocation scheme. So arrays are not an ideal data structure
>> to hold the information.
>> We use an RCU protected list to hold all mapped LPIs. vgic_its_get_lpi()
>> iterates the list using RCU list primitives, so it's safe to be called
>> from an non-preemptible context like the KVM exit/entry path.
>> Also we store a pointer to that struct vgic_irq in our struct its_itte,
>> so we can easily access it.
>> Eventually we call our new vgic_its_get_lpi() from vgic_get_irq(), so
>> the VGIC code gets transparently access to LPIs.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>
> I'm skipping the review of this particular patch until you've switched
> to the kref API.
As an added comment, and having gone through this and the following
patches, I cannot see what having an RCU list brings us if we're also
using refcounting. Taking a spinlock on the read side feels very dodgy
(what guarantees that we can make forward progress without messing with
the grace period?), and I feel that we need to keep things relatively
simple. Not simplistic, but slightly simpler.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2016-06-22 17:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-17 12:08 [PATCH v6 00/15] KVM: arm64: GICv3 ITS emulation Andre Przywara
2016-06-17 12:08 ` [PATCH v6 01/15] KVM: arm/arm64: move redistributor kvm_io_devices Andre Przywara
2016-06-17 12:08 ` [PATCH v6 02/15] KVM: arm/arm64: check return value for kvm_register_vgic_device Andre Przywara
2016-06-17 12:08 ` [PATCH v6 03/15] KVM: extend struct kvm_msi to hold a 32-bit device ID Andre Przywara
2016-06-17 12:08 ` [PATCH v6 04/15] KVM: arm/arm64: extend arch CAP checks to allow per-VM capabilities Andre Przywara
2016-06-17 12:08 ` [PATCH v6 05/15] KVM: arm/arm64: VGIC: add refcounting for IRQs Andre Przywara
2016-06-22 8:18 ` Andre Przywara
2016-06-22 8:26 ` Marc Zyngier
2016-06-17 12:08 ` [PATCH v6 06/15] KVM: arm64: handle ITS related GICv3 redistributor registers Andre Przywara
2016-06-22 14:07 ` Marc Zyngier
2016-06-22 14:39 ` Andre Przywara
2016-06-22 14:59 ` Marc Zyngier
2016-06-17 12:08 ` [PATCH v6 07/15] KVM: arm64: introduce ITS emulation file with MMIO framework Andre Przywara
2016-06-22 14:48 ` Marc Zyngier
2016-06-22 15:03 ` Andre Przywara
2016-06-22 15:24 ` Marc Zyngier
2016-06-17 12:08 ` [PATCH v6 08/15] KVM: arm64: introduce new KVM ITS device Andre Przywara
2016-06-22 15:23 ` Marc Zyngier
2016-06-17 12:08 ` [PATCH v6 09/15] KVM: arm64: implement basic ITS register handlers Andre Przywara
2016-06-22 16:19 ` Marc Zyngier
2016-06-17 12:08 ` [PATCH v6 10/15] KVM: arm64: connect LPIs to the VGIC emulation Andre Przywara
2016-06-22 16:26 ` Marc Zyngier
2016-06-22 17:02 ` Marc Zyngier [this message]
2016-06-17 12:08 ` [PATCH v6 11/15] KVM: arm64: read initial LPI pending table Andre Przywara
2016-06-17 12:08 ` [PATCH v6 12/15] KVM: arm64: allow updates of LPI configuration table Andre Przywara
2016-06-17 12:08 ` [PATCH v6 13/15] KVM: arm64: implement ITS command queue command handlers Andre Przywara
2016-06-17 12:08 ` [PATCH v6 14/15] KVM: arm64: implement MSI injection in ITS emulation Andre Przywara
2016-06-17 12:08 ` [PATCH v6 15/15] KVM: arm64: enable ITS emulation as a virtual MSI controller Andre Przywara
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=576AC4BF.2070900@arm.com \
--to=marc.zyngier@arm.com \
--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).