[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] iommu/arm: Don't allow the same micro-TLB to be shared between domains


  • To: Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>
  • From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Date: Wed, 29 Jan 2020 16:07:42 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=egpBj0puFRNHzj57pAhC2RxY+jNXmY/TzmHzBQs3Eys=; b=J6A9TDSsFfQ33NjZz+C8qWkx+Z5kKa8s7PPpdsAARdOwO6x4vTYbGpAm6qLi74cu4ZHbEplNTGiNNWF5mOZ9isGXT3ciVNnG/scbU0K2WNq14Q8VeoEEt45yqvJJQZC/0PRletZhCcKbAQZ3vA5TnttAcylJ+FQEcwsJc4v6X16gjiKzWdvC7Njm9dcY3OV0fDCq8sryyjDLqy0FlmXogPMBsjQjp/XVCb/DSgd+Q30IJ53w3uH8SE0takul5K3u9Mf3YgzgKx8w8knNiewAmfVX3CP9WJZGKHPDF7i5xR/bECQQZGp6JetUUUAyNETxpzIoGAH91h25jo4TnC0m0g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=brrh18XASr/FPxW06+fy2dvck19HQ7ZdhqyNW8Srt5RVzLYiFN5joenddq8FZ1DuKWZ/3/F5lSES7VVC59V7MPC8TsB7AhR1LBncxa2Vw+wkpTA6GKYCg9dbpnTjPMSRU/QJ0Z65V0i5K4PZqUiRYxZ8I82FIEP+xo+dMOPdfmYjf32zLUzYLJqAb9su343PwbjzmzpSox6IYBUXIsNH58+Zl9BNfTmqCzrT4fS5HHvF2X5fchDd5BpzN9bAT3kx0DjrbYWoHg0m5CHJtspBxBDk+0Bhh7bgadrWRwIXFoybvjSO8DiOlphBS9UzMWSBGtIt/AbTecYULu3e4jT8jQ==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Volodymyr_Babchuk@xxxxxxxx;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Wed, 29 Jan 2020 16:08:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHV1rQn7uvWmtBMUUCKekbfSzRsQagBzvuA
  • Thread-topic: [PATCH] iommu/arm: Don't allow the same micro-TLB to be shared between domains

Hi Oleksandr,

Oleksandr Tyshchenko writes:

[...]
> @@ -434,19 +435,45 @@ static void ipmmu_tlb_invalidate(struct 
> ipmmu_vmsa_domain *domain)
>  }
>  
>  /* Enable MMU translation for the micro-TLB. */
> -static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain *domain,
> -                              unsigned int utlb)
> +static int ipmmu_utlb_enable(struct ipmmu_vmsa_domain *domain,
> +                             unsigned int utlb)
>  {
>      struct ipmmu_vmsa_device *mmu = domain->mmu;
> +    uint32_t data;
Just nitpicking: I believe, that "imuctr" is better name than "data".

> +
> +    /*
> +     * We need to prevent the use cases where devices which use the same
> +     * micro-TLB are assigned to different Xen domains (micro-TLB cannot be
> +     * shared between multiple Xen domains, since it points to the context 
> bank
> +     * to use for the page walk).
> +     * As each Xen domain uses individual context bank pointed by context_id,
> +     * we can potentially recognize that use case by comparing current and 
> new
> +     * context_id for already enabled micro-TLB and prevent different context
> +     * bank from being set.
> +     */
> +    data = ipmmu_read(mmu, IMUCTR(utlb));
I can see that this code is not covered by spinlock. So, I believe,
there can be a race comdition, when this register is being read on two
CPUs simultaneously.

> +    if ( data & IMUCTR_MMUEN )
> +    {
> +        unsigned int context_id;
> +
> +        context_id = (data & IMUCTR_TTSEL_MASK) >> IMUCTR_TTSEL_SHIFT;
> +        if ( domain->context_id != context_id )
> +        {
> +            dev_err(mmu->dev, "Micro-TLB %u already assigned to IPMMU 
> context %u\n",
> +                    utlb, context_id);
> +            return -EINVAL;
> +        }
> +    }
>  
>      /*
>       * TODO: Reference-count the micro-TLB as several bus masters can be
> -     * connected to the same micro-TLB. Prevent the use cases where
> -     * the same micro-TLB could be shared between multiple Xen domains.
> +     * connected to the same micro-TLB.
>       */
>      ipmmu_write(mmu, IMUASID(utlb), 0);
> -    ipmmu_write(mmu, IMUCTR(utlb), ipmmu_read(mmu, IMUCTR(utlb)) |
> +    ipmmu_write(mmu, IMUCTR(utlb), data |
>                  IMUCTR_TTSEL_MMU(domain->context_id) | IMUCTR_MMUEN);
> +
> +    return 0;
>  }
>  
>  /* Disable MMU translation for the micro-TLB. */
> @@ -671,7 +698,12 @@ static int ipmmu_attach_device(struct ipmmu_vmsa_domain 
> *domain,
>          dev_info(dev, "Reusing IPMMU context %u\n", domain->context_id);
>  
>      for ( i = 0; i < fwspec->num_ids; ++i )
> -        ipmmu_utlb_enable(domain, fwspec->ids[i]);
> +    {
> +        int ret = ipmmu_utlb_enable(domain, fwspec->ids[i]);
> +
> +        if ( ret )
> +            return ret;
I can't see error path where ipmmu_utlb_disable() would be called for
already enable uTLBs. Is this normal?

> +    }
>  
>      return 0;
>  }


-- 
Volodymyr Babchuk at EPAM
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.