From: Auger Eric <eric.auger@redhat.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [RFC PATCH 18/33] irqchip/gic-v3-its: Add VLPI map/unmap operations
Date: Thu, 16 Mar 2017 09:59:20 +0100 [thread overview]
Message-ID: <0d249e3e-6189-3dc4-2d9e-d1c9291ddab1@redhat.com> (raw)
In-Reply-To: <1484648454-21216-19-git-send-email-marc.zyngier@arm.com>
Hi,
On 17/01/2017 11:20, Marc Zyngier wrote:
> In order to let a VLPI being injected into a guest, the VLPI must
> be mapped using the VMAPTI command. When moved to a different vcpu,
> it must be moved with the VMOVI command.
>
> These commands are issued via the irq_set_vcpu_affinity method,
> making sure we unmap the corresponding host LPI first.
>
> The reverse is also done when the VLPI is unmapped from the guest.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 174 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 174 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 1bd78ca..d50a019 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -115,6 +115,7 @@ struct its_node {
> struct event_lpi_map {
> unsigned long *lpi_map;
> u16 *col_map;
> + struct its_vlpi_map *vlpi_map;
> irq_hw_number_t lpi_base;
> int nr_lpis;
> };
> @@ -201,6 +202,21 @@ struct its_cmd_desc {
> struct {
> struct its_collection *col;
> } its_invall_cmd;
> +
> + struct {
> + struct its_vpe *vpe;
> + struct its_device *dev;
> + u32 virt_id;
> + u32 event_id;
> + bool db_enabled;
> + } its_vmapti_cmd;
> +
> + struct {
> + struct its_vpe *vpe;
> + struct its_device *dev;
> + u32 event_id;
> + bool db_enabled;
> + } its_vmovi_cmd;
> };
> };
>
> @@ -217,6 +233,9 @@ struct its_cmd_block {
> typedef struct its_collection *(*its_cmd_builder_t)(struct its_cmd_block *,
> struct its_cmd_desc *);
>
> +typedef struct its_vpe *(*its_cmd_vbuilder_t)(struct its_cmd_block *,
> + struct its_cmd_desc *);
> +
> static void its_mask_encode(u64 *raw_cmd, u64 val, int h, int l)
> {
> u64 mask = GENMASK_ULL(h, l);
> @@ -269,6 +288,26 @@ static void its_encode_collection(struct its_cmd_block *cmd, u16 col)
> its_mask_encode(&cmd->raw_cmd[2], col, 15, 0);
> }
>
> +static void its_encode_vpeid(struct its_cmd_block *cmd, u16 vpeid)
> +{
> + its_mask_encode(&cmd->raw_cmd[1], vpeid, 47, 32);
> +}
> +
> +static void its_encode_virt_id(struct its_cmd_block *cmd, u32 virt_id)
> +{
> + its_mask_encode(&cmd->raw_cmd[2], virt_id, 31, 0);
> +}
> +
> +static void its_encode_db_phys_id(struct its_cmd_block *cmd, u32 db_phys_id)
> +{
> + its_mask_encode(&cmd->raw_cmd[2], db_phys_id, 63, 32);
> +}
> +
> +static void its_encode_db_valid(struct its_cmd_block *cmd, bool db_valid)
> +{
> + its_mask_encode(&cmd->raw_cmd[2], db_valid, 0, 0);
> +}
> +
> static inline void its_fixup_cmd(struct its_cmd_block *cmd)
> {
> /* Let's fixup BE commands */
> @@ -427,6 +466,50 @@ static struct its_collection *its_build_invall_cmd(struct its_cmd_block *cmd,
> return NULL;
> }
>
> +static struct its_vpe *its_build_vmapti_cmd(struct its_cmd_block *cmd,
> + struct its_cmd_desc *desc)
> +{
> + u32 db;
> +
> + if (desc->its_vmapti_cmd.db_enabled)
> + db = desc->its_vmapti_cmd.vpe->vpe_db_lpi;
> + else
> + db = 1023;
> +
> + its_encode_cmd(cmd, GITS_CMD_VMAPTI);
> + its_encode_devid(cmd, desc->its_vmapti_cmd.dev->device_id);
> + its_encode_vpeid(cmd, desc->its_vmapti_cmd.vpe->vpe_id);
> + its_encode_event_id(cmd, desc->its_vmapti_cmd.event_id);
> + its_encode_db_phys_id(cmd, db);
> + its_encode_virt_id(cmd, desc->its_vmapti_cmd.virt_id);
> +
> + its_fixup_cmd(cmd);
> +
> + return desc->its_vmapti_cmd.vpe;
> +}
> +
> +static struct its_vpe *its_build_vmovi_cmd(struct its_cmd_block *cmd,
> + struct its_cmd_desc *desc)
> +{
> + u32 db;
> +
> + if (desc->its_vmovi_cmd.db_enabled)
> + db = desc->its_vmovi_cmd.vpe->vpe_db_lpi;
> + else
> + db = 1023;
> +
> + its_encode_cmd(cmd, GITS_CMD_VMOVI);
> + its_encode_devid(cmd, desc->its_vmovi_cmd.dev->device_id);
> + its_encode_vpeid(cmd, desc->its_vmovi_cmd.vpe->vpe_id);
> + its_encode_event_id(cmd, desc->its_vmovi_cmd.event_id);
> + its_encode_db_phys_id(cmd, db);
> + its_encode_db_valid(cmd, true);
> +
> + its_fixup_cmd(cmd);
> +
> + return desc->its_vmovi_cmd.vpe;
> +}
> +
> static u64 its_cmd_ptr_to_offset(struct its_node *its,
> struct its_cmd_block *ptr)
> {
> @@ -570,6 +653,16 @@ static void its_build_sync_cmd(struct its_cmd_block *sync_cmd,
> static __its_send_single_cmd(its_send_single_command, its_cmd_builder_t,
> struct its_collection, its_build_sync_cmd)
>
> +static void its_build_vsync_cmd(struct its_cmd_block *sync_cmd,
> + struct its_vpe *sync_vpe)
> +{
> + its_encode_cmd(sync_cmd, GITS_CMD_VSYNC);
> + its_encode_vpeid(sync_cmd, sync_vpe->vpe_id);
why don't we need the its_fixup_cmd() here as well? I see it is not
there in its_build_sync_cmd either.
> +}
> +
> +static __its_send_single_cmd(its_send_single_vcommand, its_cmd_vbuilder_t,
> + struct its_vpe, its_build_vsync_cmd)
> +
> static void its_send_int(struct its_device *dev, u32 event_id)
> {
> struct its_cmd_desc desc;
> @@ -663,6 +756,33 @@ static void its_send_invall(struct its_node *its, struct its_collection *col)
> its_send_single_command(its, its_build_invall_cmd, &desc);
> }
>
> +static void its_send_vmapti(struct its_device *dev, u32 id)
> +{
> + struct its_vlpi *vlpi = &dev->event_map.vlpi_map->vlpis[id];
> + struct its_cmd_desc desc;
> +
> + desc.its_vmapti_cmd.vpe = dev->event_map.vlpi_map->vpes[vlpi->vpe_idx];
> + desc.its_vmapti_cmd.dev = dev;
> + desc.its_vmapti_cmd.virt_id = vlpi->vintid;
> + desc.its_vmapti_cmd.event_id = id;
> + desc.its_vmapti_cmd.db_enabled = vlpi->db_enabled;
> +
> + its_send_single_vcommand(dev->its, its_build_vmapti_cmd, &desc);
> +}
> +
> +static void its_send_vmovi(struct its_device *dev, u32 id)
> +{
> + struct its_vlpi *vlpi = &dev->event_map.vlpi_map->vlpis[id];
> + struct its_cmd_desc desc;
> +
> + desc.its_vmovi_cmd.vpe = dev->event_map.vlpi_map->vpes[vlpi->vpe_idx];
> + desc.its_vmovi_cmd.dev = dev;
> + desc.its_vmovi_cmd.event_id = id;
> + desc.its_vmovi_cmd.db_enabled = vlpi->db_enabled;
> +
> + its_send_single_vcommand(dev->its, its_build_vmovi_cmd, &desc);
> +}
> +
> /*
> * irqchip functions - assumes MSI, mostly.
> */
> @@ -754,6 +874,20 @@ static void its_irq_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
> iommu_dma_map_msi_msg(d->irq, msg);
> }
>
> +static int its_install_vlpi_map(struct its_device *its_dev,
> + struct its_vlpi_map *map)
> +{
> + struct its_vlpi_map *old_map;
> +
> + if (map->nr_vlpis != its_dev->event_map.nr_lpis)
> + return -EINVAL;
> + old_map = cmpxchg(&its_dev->event_map.vlpi_map, NULL, map);
> + if (old_map && WARN_ON(old_map != map))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static int its_irq_set_irqchip_state(struct irq_data *d,
> enum irqchip_irq_state which,
> bool state)
> @@ -785,11 +919,51 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info)
> switch (info->cmd_type) {
> case MAP_VLPI:
> {
> + int ret;
> +
> + if (!info->map)
> + return -EINVAL;
> +
> + ret = its_install_vlpi_map(its_dev, info->map);
> + if (ret)
> + return ret;
> +
> + if (irqd_is_forwarded_to_vcpu(d)) {
> + /* Already mapped, move it around */
> + its_send_vmovi(its_dev, event);
> + } else {
> + /* Drop the physical mapping */
> + its_send_discard(its_dev, event);
> +
> + /* and install the virtual one */
> + its_send_vmapti(its_dev, event);
Just a question about error handling. Do we have any guarantee the ITS
commands won't fail?
> + irqd_set_forwarded_to_vcpu(d);
Don't we need a lock to guarantee the forwarded state and the ITS state
are consistent?
don't you need some sanity check on the vINTID?
Thanks
Eric
> +
> + /*
> + * The host will never see that interrupt
> + * firing again, so it is vital that we don't
> + * do any lazy masking.
> + */
> + irq_set_status_flags(d->irq, IRQ_DISABLE_UNLAZY);
> + }
> +
> return 0;
> }
>
> case UNMAP_VLPI:
> {
> + if (!its_dev->event_map.vlpi_map ||
> + !irqd_is_forwarded_to_vcpu(d))
> + return -EINVAL;
> +
> + /* Drop the virtual mapping */
> + its_send_discard(its_dev, event);
> +
> + /* and restore the physical one */
> + irqd_clr_forwarded_to_vcpu(d);
> + irq_clear_status_flags(d->irq, IRQ_DISABLE_UNLAZY);
> + its_send_mapvi(its_dev, d->hwirq, event);
> +
> return 0;
> }
>
>
next prev parent reply other threads:[~2017-03-16 8:59 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-17 10:20 [RFC PATCH 00/33] irqchip: Core support for GICv4 Marc Zyngier
2017-01-17 10:20 ` [RFC PATCH 01/33] irqchip/gic-v3: Add redistributor iterator Marc Zyngier
2017-02-13 9:39 ` Thomas Gleixner
2017-02-13 21:12 ` Shanker Donthineni
2017-02-16 12:47 ` Auger Eric
2017-06-19 15:26 ` Marc Zyngier
2017-01-17 10:20 ` [RFC PATCH 02/33] irqchip/gic-v3: Add VLPI/DirectLPI discovery Marc Zyngier
2017-02-13 9:39 ` Thomas Gleixner
2017-02-13 21:39 ` Shanker Donthineni
2017-02-16 13:19 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 03/33] irqchip/gic-v3-its: Refactor command encoding Marc Zyngier
2017-02-13 9:54 ` Thomas Gleixner
2017-02-16 13:19 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 04/33] irqchip/gic-v3-its: Move LPI definitions around Marc Zyngier
2017-02-13 9:55 ` Thomas Gleixner
2017-02-16 13:22 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 05/33] irqchip/gic-v3-its: Zero command on allocation Marc Zyngier
2017-02-13 9:55 ` Thomas Gleixner
2017-01-17 10:20 ` [RFC PATCH 06/33] irqchip/gic-v3-its: Add probing for VLPI properties Marc Zyngier
2017-02-13 10:00 ` Thomas Gleixner
2017-02-16 13:46 ` Auger Eric
2017-02-13 21:58 ` Shanker Donthineni
2017-01-17 10:20 ` [RFC PATCH 07/33] irqchip/gic-v3-its: Macro-ize its_send_single_command Marc Zyngier
2017-02-13 10:24 ` Thomas Gleixner
2017-02-16 14:59 ` Auger Eric
2017-02-17 6:15 ` Auger Eric
2017-06-19 15:38 ` Marc Zyngier
2017-01-17 10:20 ` [RFC PATCH 08/33] irqchip/gic-v3-its: Implement irq_set_irqchip_state for pending state Marc Zyngier
2017-02-13 10:28 ` Thomas Gleixner
2017-02-16 14:59 ` Auger Eric
2017-02-17 6:15 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 09/33] irqchip/gic-v3-its: Split out property table allocation Marc Zyngier
2017-02-13 10:28 ` Thomas Gleixner
2017-02-17 6:15 ` Auger Eric
2017-06-19 15:42 ` Marc Zyngier
2017-02-17 20:40 ` Prakash B
2017-01-17 10:20 ` [RFC PATCH 10/33] irqchip/gic-v4-its: Allow use of indirect VCPU tables Marc Zyngier
2017-02-13 10:28 ` Thomas Gleixner
2017-02-13 22:14 ` Shanker Donthineni
2017-06-19 14:47 ` Marc Zyngier
2017-02-17 6:15 ` Auger Eric
2017-03-16 21:50 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 11/33] irqchip/gic-v3-its: Split out pending table allocation Marc Zyngier
2017-02-13 10:29 ` Thomas Gleixner
2017-02-13 22:31 ` Shanker Donthineni
2017-03-16 8:57 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 12/33] irqchip/gic-v3-its: Rework LPI freeing Marc Zyngier
2017-02-13 10:30 ` Thomas Gleixner
2017-03-16 8:57 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 13/33] irqchip/gic-v3-its: Generalize device table allocation Marc Zyngier
2017-02-13 10:31 ` Thomas Gleixner
2017-03-16 8:57 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 14/33] irqchip/gic-v3-its: Generalize LPI configuration Marc Zyngier
2017-02-13 10:32 ` Thomas Gleixner
2017-03-16 8:57 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 15/33] irqchip/gic-v4: Add management structure definitions Marc Zyngier
2017-02-13 10:33 ` Thomas Gleixner
2017-03-16 8:58 ` Auger Eric
2017-06-19 15:48 ` Marc Zyngier
2017-01-17 10:20 ` [RFC PATCH 16/33] irqchip/gic-v3-its: Add GICv4 ITS command definitions Marc Zyngier
2017-02-13 10:34 ` Thomas Gleixner
2017-03-16 8:58 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 17/33] irqchip/gic-v3-its: Add VLPI configuration hook Marc Zyngier
2017-02-13 10:37 ` Thomas Gleixner
2017-02-13 23:07 ` Shanker Donthineni
2017-06-19 14:52 ` Marc Zyngier
2017-03-16 8:59 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 18/33] irqchip/gic-v3-its: Add VLPI map/unmap operations Marc Zyngier
2017-03-16 8:59 ` Auger Eric [this message]
2017-06-19 13:08 ` Marc Zyngier
2017-01-17 10:20 ` [RFC PATCH 19/33] irqchip/gic-v3-its: Add VLPI configuration handling Marc Zyngier
2017-02-13 10:38 ` Thomas Gleixner
2017-03-16 8:59 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 20/33] irqchip/gic-v3-its: Add VPE domain infrastructure Marc Zyngier
2017-02-13 10:40 ` Thomas Gleixner
2017-06-19 13:54 ` Marc Zyngier
2017-03-16 9:18 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 21/33] irqchip/gic-v3-its: Add VPE irq domain allocation/teardown Marc Zyngier
2017-02-13 10:45 ` Thomas Gleixner
2017-02-13 23:25 ` Shanker Donthineni
2017-03-16 9:27 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 22/33] irqchip/gic-v3-its: Add VPE irq domain [de]activation Marc Zyngier
2017-02-13 10:45 ` Thomas Gleixner
2017-01-17 10:20 ` [RFC PATCH 23/33] irqchip/gic-v3-its: Add VPENDBASER/VPROPBASER accessors Marc Zyngier
2017-02-13 10:46 ` Thomas Gleixner
2017-02-13 23:39 ` Shanker Donthineni
2017-06-19 15:03 ` Marc Zyngier
2017-03-16 21:03 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 24/33] irqchip/gic-v3-its: Add VPE scheduling Marc Zyngier
2017-02-13 10:48 ` Thomas Gleixner
2017-02-14 0:13 ` Shanker Donthineni
2017-06-19 15:23 ` Marc Zyngier
2017-02-14 1:24 ` Shanker Donthineni
2017-03-16 21:23 ` Auger Eric
2017-03-16 21:41 ` Shanker Donthineni
2017-06-19 9:34 ` Marc Zyngier
2017-01-17 10:20 ` [RFC PATCH 25/33] irqchip/gic-v3-its: Add VPE invalidation hook Marc Zyngier
2017-02-13 10:48 ` Thomas Gleixner
2017-01-17 10:20 ` [RFC PATCH 26/33] irqchip/gic-v3-its: Add VPE affinity changes Marc Zyngier
2017-02-13 10:56 ` Thomas Gleixner
2017-01-17 10:20 ` [RFC PATCH 27/33] irqchip/gic-v3-its: Add VPE interrupt masking Marc Zyngier
2017-02-13 10:57 ` Thomas Gleixner
2017-03-16 21:58 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 28/33] irqchip/gic-v3-its: Support VPE doorbell invalidation even when !DirectLPI Marc Zyngier
2017-02-13 11:15 ` Thomas Gleixner
2017-02-14 0:44 ` Shanker Donthineni
2017-06-19 13:31 ` Marc Zyngier
2017-01-17 10:20 ` [RFC PATCH 29/33] irqchip/gic-v4: Add per-VM VPE domain creation Marc Zyngier
2017-02-13 11:16 ` Thomas Gleixner
2017-01-17 10:20 ` [RFC PATCH 30/33] irqchip/gic-v4: Add VPE command interface Marc Zyngier
2017-02-13 11:16 ` Thomas Gleixner
2017-03-16 21:17 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 31/33] irqchip/gic-v4: Add VLPI configuration interface Marc Zyngier
2017-02-13 11:17 ` Thomas Gleixner
2017-03-16 21:08 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 32/33] irqchip/gic-v4: Add some basic documentation Marc Zyngier
2017-02-13 11:17 ` Thomas Gleixner
2017-03-16 21:02 ` Auger Eric
2017-01-17 10:20 ` [RFC PATCH 33/33] irqchip/gic-v4: Enable low-level GICv4 operations Marc Zyngier
2017-02-13 11:17 ` Thomas Gleixner
2017-02-13 11:19 ` [RFC PATCH 00/33] irqchip: Core support for GICv4 Thomas Gleixner
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=0d249e3e-6189-3dc4-2d9e-d1c9291ddab1@redhat.com \
--to=eric.auger@redhat.com \
--cc=christoffer.dall@linaro.org \
--cc=jason@lakedaemon.net \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®