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

Re: [PATCH v2 1/4] IOMMU/x86: switch to alternatives-call patching in further instances


  • To: paul@xxxxxxx
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 28 Jan 2022 11:36:56 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=72GN5dE/UvS737PEGXDv2rGsm6JboRHNJEnW8SC4O+A=; b=LnEzRK/Qn9Tg7ivvSfZZPBex7HmcTkqER3ozuSp4iof2qKG/vEuiWNBVRivLLL6XbqTfzXXAdxUUk46UW/Gf9mgz9a+QWYGjQzNDcEtFyZgPXa8a22Emj6FrgJq6UQWRvagES3/01k/0Es+rlPiwrvDH66hzrmq6b3m9VyW+zdYaOcVenTniAVbeAVG0kfj193a37azYjjJ5I015sswkFpe1pbWUWbNm9HNsqYkbOC2z5R8GAb8T8DH1sAuzKe8zK94c1Q6wU3DHnSGGgKXO4lyrRaNe7kh3/CrU9C+98DDityoMqI1Qf5xoXkTpmFazPawaW4Em+ePZ410p6yByzg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fi5W1342fbhXUSxl0mf2T36+VIzLH1Zp99876P8KxUUXgqvAbDhKyFq/8yUowEOuqnw+k+gYyJ3eUmSrw+41ZNw5+bUSmaohQPTj9skh+bt8fArscuXxqVZ/Yi6RYBwUISS6jyesObEmZLRL4xcmdlvSIjhI2STjN8LqWNq2PMuUe2+dkLNk6BhTdwiOItlypj92y8qV6amnEq/b0Z8A7rNf4hbKyppMuFyPU6MI/LcCf6UI4wownEKmo54+X7cU9+AzjBACeBTuvlKEnWtuqXzCTf71Xu+qHS0aLsQso6sI2TKvdYCk1as1+r9fsdTDU5Be6+TtfBEvBgK3RmdsIA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 28 Jan 2022 10:37:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28.01.2022 10:28, Durrant, Paul wrote:
> On 27/01/2022 14:47, Jan Beulich wrote:
>> @@ -1457,24 +1462,24 @@ static int iommu_get_device_group(
>>       if ( !is_iommu_enabled(d) || !ops->get_device_group_id )
>>           return 0;
>>   
>> -    group_id = ops->get_device_group_id(seg, bus, devfn);
>> +    group_id = iommu_call(ops, get_device_group_id, seg, bus, devfn);
>>   
>>       pcidevs_lock();
>>       for_each_pdev( d, pdev )
>>       {
>> -        if ( (pdev->seg != seg) ||
>> -             ((pdev->bus == bus) && (pdev->devfn == devfn)) )
>> +        unsigned int b = pdev->bus;
>> +        unsigned int df = pdev->devfn;
>> +
>> +        if ( (pdev->seg != seg) || ((b == bus) && (df == devfn)) )
>>               continue;
>>   
>> -        if ( xsm_get_device_group(XSM_HOOK, (seg << 16) | (pdev->bus << 8) 
>> | pdev->devfn) )
>> +        if ( xsm_get_device_group(XSM_HOOK, (seg << 16) | (b << 8) | df) )
>>               continue;
>>   
>> -        sdev_id = ops->get_device_group_id(seg, pdev->bus, pdev->devfn);
>> +        sdev_id = iommu_call(ops, get_device_group_id, seg, b, df);
>>           if ( (sdev_id == group_id) && (i < max_sdevs) )
>>           {
>> -            bdf = 0;
>> -            bdf |= (pdev->bus & 0xff) << 16;
>> -            bdf |= (pdev->devfn & 0xff) << 8;
>> +            bdf = (b << 16) | (df << 8);
> 
> Don't we have a macro for this now? Probably best to start using it 
> whilst modifying the code.

We don't. And it would feel somewhat misleading to use PCI_BDF2(b, df) << 8
here. The situation is even worse imo: Besides there not being a macro, I
also cannot seem to find any documentation on this non-standard layout (BDF
shifted left by 8). Yet then again I also can't spot any caller of
xc_get_device_group() ...

> Reviewed-by: Paul Durrant <paul@xxxxxxx>

Thanks.

Jan




 


Rackspace

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