|
[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
Hi Oleksandr,
Oleksandr writes:
[...]
>>> +
>>> + /*
>>> + * 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.
>
> I don't think, ipmmu_assign(deassign)_device callbacks take a
> spinlock, so the micro-TLB management routines inside
> are protected.
Yeah, you are right. Somehow I missed this when checked the code yesterday.
>
>> /* 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?
>
> Good question. Indeed, we need to restore previous state in case of error.
>
>
> I will add the following:
>
> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
> b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
> index c21d2d7..411fc0f 100644
> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
> @@ -702,7 +702,12 @@ static int ipmmu_attach_device(struct
> ipmmu_vmsa_domain *domain,
> int ret = ipmmu_utlb_enable(domain, fwspec->ids[i]);
>
> if ( ret )
> + {
> + while ( i-- )
You will call
> + ipmmu_utlb_disable(domain, fwspec->ids[i]);
for uTLB that caused the error. Likely, this uTLB right now is assigned
for another domain. So, you will disable active uTLB which belongs to
that domain.
> +
> return ret;
> + }
> }
>
> return 0;
--
Volodymyr Babchuk at EPAM
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |