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

Re: [PATCH v5 2/4] xen: do not return -EEXIST if iommu_add_dt_device is called twice


  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 23 Jul 2021 15:02:49 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=RLDeg85buIAlpXcnKlA0k0lH5eIqObzBLDKPFK6dyYE=; b=KsxWAJS5fNjAdjDFnOGw+d1O+ai79FOdcxjiAHRO8maZLnk5BIdvKwNRj5Fd7+GSx1ehxZPOkJwtXTh0TaUk4vcd77jF6sc1ZdCKUtYU65lWJtgqmcEnMnvYaPiM1f2ZsFdll9TqCrqHZ7HtP7rc9HP5eH5HAYLDYvcOcPWS1hSVn+Qb/JLvCsIEzo2EoJ1fSha0UamoTKkPojbTAeH6tlAOY6DbpPl8VTv3dPjjzvjjx6GIlUNY/ekj2psQaEpelrqtE3hnCQ/TiKk4nxX4dpWguwFUDPn+Xnfz98goqg6ljk+YoVo1qJs4+po1WWRAYDIDhAqxl3AS5dzZaainAA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FZ0NmJPPc/6QC861I78WvTH/cW716XWAOb8XWLGOXLHc4XLUetZ+QvAn5jnEa64ZhsKe7tqgwqXu2F42Oavfy5mvZiCU9uUvcH7Q4z7NE+jH+IchfYzMjk53Kk5HgcdyAw+3A65agSKkCdUgmtmWIx22/po6OzTpAY/qlIb1+6+u7smHs2X6jV06eCSXGkVJONQ2PljavNdp7t2zjHOGIWITsJdhv8OXxLWkN4m5hBOsqusQcLh4EZDf0EV0SbjLoAOwCO1jR7nj9U/DvXwdd4bR7f4zDZ3ZJ4U82wLXayZWnEdDtFFfp3YOxLaQk1H1WNscjFt6/CQfFd28mOr19w==
  • Authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=suse.com;
  • Cc: Bertrand.Marquis@xxxxxxx, Volodymyr_Babchuk@xxxxxxxx, rahul.singh@xxxxxxx, brian.woods@xxxxxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Fri, 23 Jul 2021 13:03:14 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.07.2021 11:28, Julien Grall wrote:
> Hi Jan,
> 
> On 23/07/2021 07:31, Jan Beulich wrote:
>> On 23.07.2021 01:36, Stefano Stabellini wrote:
>>> --- a/xen/drivers/passthrough/device_tree.c
>>> +++ b/xen/drivers/passthrough/device_tree.c
>>> @@ -140,8 +140,13 @@ int iommu_add_dt_device(struct dt_device_node *np)
>>>       if ( !ops )
>>>           return -EINVAL;
>>>   
>>> +    /*
>>> +     * Some Device Trees may expose both legacy SMMU and generic
>>> +     * IOMMU bindings together. If both are present, the device
>>> +     * can be already added.
>>> +     */
>>>       if ( dev_iommu_fwspec_get(dev) )
>>> -        return -EEXIST;
>>> +        return 0;
>>
>> Since the xen: prefix in the subject made me go look (I wouldn't have
>> if it had been e.g. dt: ), I may as well ask: Since previously there
>> was concern about bogus duplicate entries, does this concern go away
>> no altogether?
> 
> The check wasn't originally added because of legacy vs generic binding.
> 
> It was added because in some circumstances iommu_add_dt_device() could 
> genuinely be called twice (for instance if the device is re-assigned). 
> This was returning -EEXIST rather than 0 so the caller can decide 
> whether it is normal that the device is already added.

Okay. If that distinction is of no interest anymore, then I can see
this wanting dropping.

> Calling iommu_add_dt_device() twice doesn't hurt but after patch #1 
> (this patch should really be first), dev_iommu_fwspec_get() will return 
> a non-NULL pointer as the legacy devices are added when the IOMMU is probed.
> 
>> It's one thing for there to be a legacy and a generic
>> binding, but another if you found two legacy or two generic ones, I
>> would think.
> 
> I am not quite too sure what you mean by "two legacy" and "two generic". 
> Can you clarify it?

Well, I'm having trouble describing it in different terms. I mean
two entries of the same kind (both legacy or both generic) referring
to the same device, thus leading to the function recognizing the 2nd
time round that the device is already there.

Jan




 


Rackspace

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