All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Andre Przywara <andre.przywara@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org,
	Shanker Donthineni <shankerd@codeaurora.org>,
	Vijay Kilari <vijay.kilari@gmail.com>
Subject: Re: [PATCH v3 06/26] ARM: GICv3 ITS: introduce device mapping
Date: Mon, 3 Apr 2017 19:56:14 +0100	[thread overview]
Message-ID: <a675cdec-2889-e659-f412-0a7c2386c840@arm.com> (raw)
In-Reply-To: <20170331180525.30038-7-andre.przywara@arm.com>

Hi Andre,

Mostly repeating my comments from the previous version.

On 31/03/17 19:05, Andre Przywara wrote:

[...]

> +static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid,
> +                             uint8_t size_bits, paddr_t itt_addr, bool valid)
> +{
> +    uint64_t cmd[4];
> +
> +    if ( valid )
> +    {
> +        ASSERT(size_bits < 32);

Again, it would be better if you do the check against the real number in 
hardware (i.e GITS_TYPER.ID_bits).

> +        ASSERT(!(itt_addr & ~GENMASK_ULL(51, 8)));
> +    }
> +    cmd[0] = GITS_CMD_MAPD | ((uint64_t)deviceid << 32);
> +    cmd[1] = size_bits;

I would have expected to see size_bits - 1 to accommodate all the 
helpers rather than relying on them.

[...]

> +static int remove_mapped_guest_device(struct its_devices *dev)
> +{
> +    int ret;
> +
> +    if ( dev->hw_its )
> +    {
> +        /* MAPD also discards all events with this device ID. */
> +        int ret = its_send_cmd_mapd(dev->hw_its, dev->host_devid, 0, 0, false);

You are re-defining ret. Why?

[...]

> +static struct host_its *gicv3_its_find_by_doorbell(paddr_t doorbell_address)
> +{
> +    struct host_its *hw_its;
> +
> +    list_for_each_entry(hw_its, &host_its_list, entry)
> +    {
> +        if ( hw_its->addr + ITS_DOORBELL_OFFSET == doorbell_address )

Again, why not storing the ITS address rather than the doorbell to avoid 
"+ ITS_DOORBELL_OFFSET" ?

[...]

> +/*
> + * Map a hardware device, identified by a certain host ITS and its device ID
> + * to domain d, a guest ITS (identified by its doorbell address) and device ID.
> + * Also provide the number of events (MSIs) needed for that device.
> + * This does not check if this particular hardware device is already mapped
> + * at another domain, it is expected that this would be done by the caller.
> + */
> +int gicv3_its_map_guest_device(struct domain *d,
> +                               paddr_t host_doorbell, uint32_t host_devid,
> +                               paddr_t guest_doorbell, uint32_t guest_devid,
> +                               uint32_t nr_events, bool valid)

I am sure I said it somewhere in this series, nr_events likely needs to 
be sanitized against the hardware value. Same for host_devid.

[...]

> +        parent = *new;
> +        cmp = compare_its_guest_devices(temp, guest_doorbell, guest_devid);
> +        if ( !cmp )
> +        {
> +            if ( !valid )
> +                rb_erase(&temp->rbnode, &d->arch.vgic.its_devices);
> +
> +            spin_unlock(&d->arch.vgic.its_devices_lock);
> +
> +            if ( valid )

Again, a printk(XENLOG_GUEST...) here would be useful to know which host 
DeviceID was associated to the guest DeviceID.

> +                return -EBUSY;
> +
> +            return remove_mapped_guest_device(temp);

Again, just above you removed the device from the RB-tree but this 
function may fail and never free the memory. This means that memory will 
be leaked leading to a potential denial of service.

> +        }
> +
> +        if ( cmp > 0 )
> +            new = &((*new)->rb_left);
> +        else
> +            new = &((*new)->rb_right);
> +    }
> +
> +    if ( !valid )
> +        goto out_unlock;
> +
> +    ret = -ENOMEM;
> +
> +    /* An Interrupt Translation Table needs to be 256-byte aligned. */
> +    itt_addr = _xzalloc(nr_events * hw_its->itte_size, 256);

See Vijay's comment. But why don't you round up nr_events at the 
beginning once for all rather than doing it in the middle?

[...]

> +out_unlock:
> +    spin_unlock(&d->arch.vgic.its_devices_lock);
> +    if ( dev )
> +    {
> +        xfree(dev->pend_irqs);
> +        xfree(dev->host_lpi_blocks);

Where is host_lpi_blocks allocated? Why is it freed here?

> +    }
> +    xfree(itt_addr);
> +    xfree(dev);
> +    return ret;
> +}
> +
> +/* Removing any connections a domain had to any ITS in the system. */
> +void gicv3_its_unmap_all_devices(struct domain *d)
> +{
> +    struct rb_node *victim;
> +    struct its_devices *dev;
> +
> +    /*
> +     * This is an easily readable, but suboptimal implementation.
> +     * It uses the provided iteration wrapper and erases each node, which
> +     * possibly triggers rebalancing.
> +     * This seems overkill since we are going to abolish the whole tree, but
> +     * avoids an open-coded re-implementation of the traversal functions with
> +     * some recursive function calls.
> +     */

Well, you updated the comment but it does not make the performance 
problem going away... Xen cannot be preempted, so if it takes too long, 
you will have an impact on the overall system.

As said previously, I think it would be fair to assume that all devices 
will be deassigned before the ITS is destroyed. So I would just drop 
this function. Not that we have the same assumption in the SMMU driver.

If you disagree please say why. But ignoring comments will not help here.

> +restart:
> +    spin_lock(&d->arch.vgic.its_devices_lock);
> +    if ( (victim = rb_first(&d->arch.vgic.its_devices)) )
> +    {
> +        dev = rb_entry(victim, struct its_devices, rbnode);
> +        rb_erase(victim, &d->arch.vgic.its_devices);
> +
> +        spin_unlock(&d->arch.vgic.its_devices_lock);
> +
> +        remove_mapped_guest_device(dev);
> +
> +        goto restart;
> +    }
> +
> +    spin_unlock(&d->arch.vgic.its_devices_lock);
> +}
> +
>  /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
>  void gicv3_its_dt_init(const struct dt_device_node *node)
>  {
> @@ -459,6 +685,7 @@ void gicv3_its_dt_init(const struct dt_device_node *node)
>          its_data->addr = addr;
>          its_data->size = size;
>          its_data->dt_node = its;
> +        spin_lock_init(&its_data->cmd_lock);

This should be in patch #5.

>
>          printk("GICv3: Found ITS @0x%lx\n", addr);
>
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index d61479d..6242252 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -1450,6 +1450,9 @@ static int vgic_v3_domain_init(struct domain *d)
>      d->arch.vgic.nr_regions = rdist_count;
>      d->arch.vgic.rdist_regions = rdist_regions;
>
> +    spin_lock_init(&d->arch.vgic.its_devices_lock);
> +    d->arch.vgic.its_devices = RB_ROOT;
> +

Again, the placement of those 2 lines are likely wrong. This should 
belong to the vITS and not the vgic-v3.

I think it would make sense to get a patch that introduces a skeleton 
for the vITS before this patch and start plumbing through.

>      /*
>       * Domain 0 gets the hardware address.
>       * Guests get the virtual platform layout.
> @@ -1522,6 +1525,7 @@ static int vgic_v3_domain_init(struct domain *d)
>
>  static void vgic_v3_domain_free(struct domain *d)
>  {
> +    gicv3_its_unmap_all_devices(d);

See my comment above regarding this function.

>      xfree(d->arch.vgic.rdist_regions);
>  }


[...]

> diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
> index 4c2ae1c..4ade5f6 100644
> --- a/xen/include/asm-arm/gic_v3_its.h
> +++ b/xen/include/asm-arm/gic_v3_its.h
> @@ -48,6 +48,10 @@
>  #define GITS_TYPER_DEVICE_ID_BITS(r)    (((r & GITS_TYPER_DEVIDS_MASK) >> \
>                                                 GITS_TYPER_DEVIDS_SHIFT) + 1)
>  #define GITS_TYPER_IDBITS_SHIFT         8
> +#define GITS_TYPER_ITT_SIZE_SHIFT       4
> +#define GITS_TYPER_ITT_SIZE_MASK        (0xfUL << GITS_TYPER_ITT_SIZE_SHIFT)
> +#define GITS_TYPER_ITT_SIZE(r)          ((((r) & GITS_TYPER_ITT_SIZE_MASK) >> \
> +                                                GITS_TYPER_ITT_SIZE_SHIFT) + 1)
>
>  #define GITS_IIDR_VALUE                 0x34c
>
> @@ -94,7 +98,10 @@
>  #define GITS_CMD_MOVALL                 0x0e
>  #define GITS_CMD_DISCARD                0x0f
>
> +#define ITS_DOORBELL_OFFSET             0x10040
> +
>  #include <xen/device_tree.h>
> +#include <xen/rbtree.h>
>
>  #define HOST_ITS_FLUSH_CMD_QUEUE        (1U << 0)
>  #define HOST_ITS_USES_PTA               (1U << 1)
> @@ -109,6 +116,7 @@ struct host_its {
>      unsigned int devid_bits;
>      spinlock_t cmd_lock;
>      void *cmd_buf;
> +    unsigned int itte_size;

Stefano mentioned:
"I would move itte_size and its initialization to the patch that
introduced struct host_its."

>      unsigned int flags;
>  };

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-04-03 18:56 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31 18:04 [PATCH v3 00/26] arm64: Dom0 ITS emulation Andre Przywara
2017-03-31 18:05 ` [PATCH v3 01/26] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT Andre Przywara
2017-03-31 23:08   ` Stefano Stabellini
2017-03-31 18:05 ` [PATCH v3 02/26] ARM: GICv3: allocate LPI pending and property table Andre Przywara
2017-03-31 22:59   ` Stefano Stabellini
2017-04-03  9:05     ` Andre Przywara
2017-04-03 18:16       ` Stefano Stabellini
2017-04-03 13:53   ` Julien Grall
2017-04-03 14:01     ` Julien Grall
2017-03-31 18:05 ` [PATCH v3 03/26] ARM: GICv3 ITS: allocate device and collection table Andre Przywara
2017-03-31 23:06   ` Stefano Stabellini
2017-04-03 15:38   ` Julien Grall
2017-04-03 17:22     ` Julien Grall
2017-04-03 19:39       ` Andre Przywara
2017-04-03 20:46         ` Julien Grall
2017-03-31 18:05 ` [PATCH v3 04/26] ARM: GICv3 ITS: map ITS command buffer Andre Przywara
2017-03-31 23:10   ` Stefano Stabellini
2017-04-03 16:00   ` Julien Grall
2017-03-31 18:05 ` [PATCH v3 05/26] ARM: GICv3 ITS: introduce ITS command handling Andre Przywara
2017-03-31 23:16   ` Stefano Stabellini
2017-04-03 17:32   ` Julien Grall
2017-03-31 18:05 ` [PATCH v3 06/26] ARM: GICv3 ITS: introduce device mapping Andre Przywara
2017-03-31 23:20   ` Stefano Stabellini
2017-04-01  8:01   ` Vijay Kilari
2017-04-03 18:33     ` Julien Grall
2017-04-03 18:56   ` Julien Grall [this message]
2017-03-31 18:05 ` [PATCH v3 07/26] ARM: GICv3 ITS: introduce host LPI array Andre Przywara
2017-03-31 23:24   ` Stefano Stabellini
2017-03-31 18:05 ` [PATCH v3 08/26] ARM: GICv3: introduce separate pending_irq structs for LPIs Andre Przywara
2017-03-31 18:05 ` [PATCH v3 09/26] ARM: GICv3: forward pending LPIs to guests Andre Przywara
2017-03-31 18:05 ` [PATCH v3 10/26] ARM: GICv3: enable ITS and LPIs on the host Andre Przywara
2017-03-31 18:05 ` [PATCH v3 11/26] ARM: vGICv3: handle virtual LPI pending and property tables Andre Przywara
2017-04-04 12:55   ` Julien Grall
2017-04-04 12:56     ` Julien Grall
2017-03-31 18:05 ` [PATCH v3 12/26] ARM: vGICv3: Handle disabled LPIs Andre Przywara
2017-03-31 18:05 ` [PATCH v3 13/26] ARM: vGICv3: introduce basic ITS emulation bits Andre Przywara
2017-03-31 18:05 ` [PATCH v3 14/26] ARM: vITS: introduce translation table walks Andre Przywara
2017-03-31 18:05 ` [PATCH v3 15/26] ARM: vITS: handle CLEAR command Andre Przywara
2017-03-31 18:05 ` [PATCH v3 16/26] ARM: vITS: handle INT command Andre Przywara
2017-03-31 18:05 ` [PATCH v3 17/26] ARM: vITS: handle MAPC command Andre Przywara
2017-03-31 18:05 ` [PATCH v3 18/26] ARM: vITS: handle MAPD command Andre Przywara
2017-03-31 18:05 ` [PATCH v3 19/26] ARM: vITS: handle MAPTI command Andre Przywara
2017-04-01  8:32   ` Vijay Kilari
2017-03-31 18:05 ` [PATCH v3 20/26] ARM: vITS: handle MOVI command Andre Przywara
2017-03-31 18:05 ` [PATCH v3 21/26] ARM: vITS: handle DISCARD command Andre Przywara
2017-03-31 18:05 ` [PATCH v3 22/26] ARM: vITS: handle INV command Andre Przywara
2017-03-31 18:05 ` [PATCH v3 23/26] ARM: vITS: handle INVALL command Andre Przywara
2017-03-31 18:05 ` [PATCH v3 24/26] ARM: vITS: create and initialize virtual ITSes for Dom0 Andre Przywara
2017-03-31 18:05 ` [PATCH v3 25/26] ARM: vITS: create ITS subnodes for Dom0 DT Andre Przywara
2017-03-31 18:05 ` [PATCH v3 26/26] ARM: vGIC: advertise LPI support Andre Przywara
2017-04-04 17:06   ` Julien Grall
2017-04-01 20:37 ` [PATCH v3 00/26] arm64: Dom0 ITS emulation Julien Grall

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=a675cdec-2889-e659-f412-0a7c2386c840@arm.com \
    --to=julien.grall@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=shankerd@codeaurora.org \
    --cc=sstabellini@kernel.org \
    --cc=vijay.kilari@gmail.com \
    --cc=xen-devel@lists.xenproject.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 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.