mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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;
>  	}
>  
> 

  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®