mbox series

[0/2] iommufd: Only enforce_cache_coherency when allocating hwpt

Message ID cover.1697848510.git.nicolinc@nvidia.com
Headers
Series iommufd: Only enforce_cache_coherency when allocating hwpt |

Message

Nicolin Chen Oct. 21, 2023, 12:37 a.m. UTC 
  https://lore.kernel.org/linux-iommu/20231020135501.GG3952@nvidia.com/
The conversation above concluded that a hwpt should only enforce cache
coherency per device at the stage of its allocation, and it should not
be changed or updated in the attach/replace routines.

Add two patches dropping the enforce_cache_coherency calls from attach
and replce routines respectively, since they were introduced with two
different commits.

Nicolin Chen (2):
  iommufd/device: Drop enforce_cache_coherency in
    iommufd_device_do_replace
  iommufd/device: Drop enforce_cache_coherency in
    iommufd_hw_pagetable_attach

 drivers/iommu/iommufd/device.c          | 19 ++-----------------
 drivers/iommu/iommufd/hw_pagetable.c    |  2 +-
 drivers/iommu/iommufd/iommufd_private.h |  1 -
 3 files changed, 3 insertions(+), 19 deletions(-)

Comments

Baolu Lu Oct. 21, 2023, 1:32 a.m. UTC | #1 
On 2023/10/21 8:37, Nicolin Chen wrote:
> https://lore.kernel.org/linux-iommu/20231020135501.GG3952@nvidia.com/
> The conversation above concluded that a hwpt should only enforce cache
> coherency per device at the stage of its allocation, and it should not
> be changed or updated in the attach/replace routines.
> 
> Add two patches dropping the enforce_cache_coherency calls from attach
> and replce routines respectively, since they were introduced with two
> different commits.
> 
> Nicolin Chen (2):
>    iommufd/device: Drop enforce_cache_coherency in
>      iommufd_device_do_replace
>    iommufd/device: Drop enforce_cache_coherency in
>      iommufd_hw_pagetable_attach
> 
>   drivers/iommu/iommufd/device.c          | 19 ++-----------------
>   drivers/iommu/iommufd/hw_pagetable.c    |  2 +-
>   drivers/iommu/iommufd/iommufd_private.h |  1 -
>   3 files changed, 3 insertions(+), 19 deletions(-)

Hi Kevin and Jason,

With these two fixes, there's no issue in the intel driver any more. Do
I understand it right?

Best regards,
baolu
Jason Gunthorpe Oct. 21, 2023, 4:39 p.m. UTC | #2 
On Sat, Oct 21, 2023 at 09:32:32AM +0800, Baolu Lu wrote:
> On 2023/10/21 8:37, Nicolin Chen wrote:
> > https://lore.kernel.org/linux-iommu/20231020135501.GG3952@nvidia.com/
> > The conversation above concluded that a hwpt should only enforce cache
> > coherency per device at the stage of its allocation, and it should not
> > be changed or updated in the attach/replace routines.
> > 
> > Add two patches dropping the enforce_cache_coherency calls from attach
> > and replce routines respectively, since they were introduced with two
> > different commits.
> > 
> > Nicolin Chen (2):
> >    iommufd/device: Drop enforce_cache_coherency in
> >      iommufd_device_do_replace
> >    iommufd/device: Drop enforce_cache_coherency in
> >      iommufd_hw_pagetable_attach
> > 
> >   drivers/iommu/iommufd/device.c          | 19 ++-----------------
> >   drivers/iommu/iommufd/hw_pagetable.c    |  2 +-
> >   drivers/iommu/iommufd/iommufd_private.h |  1 -
> >   3 files changed, 3 insertions(+), 19 deletions(-)
> 
> Hi Kevin and Jason,
> 
> With these two fixes, there's no issue in the intel driver any more. Do
> I understand it right?

I think so, as long as it is an allocation only time flag there isn't
much trouble for the driver.

VFIO, I think, still does the old algorithm however.

Jason
Tian, Kevin Oct. 23, 2023, 2:55 a.m. UTC | #3 
> From: Baolu Lu <baolu.lu@linux.intel.com>
> Sent: Saturday, October 21, 2023 9:33 AM
> 
> On 2023/10/21 8:37, Nicolin Chen wrote:
> > https://lore.kernel.org/linux-
> iommu/20231020135501.GG3952@nvidia.com/
> > The conversation above concluded that a hwpt should only enforce cache
> > coherency per device at the stage of its allocation, and it should not
> > be changed or updated in the attach/replace routines.
> >
> > Add two patches dropping the enforce_cache_coherency calls from attach
> > and replce routines respectively, since they were introduced with two
> > different commits.
> >
> > Nicolin Chen (2):
> >    iommufd/device: Drop enforce_cache_coherency in
> >      iommufd_device_do_replace
> >    iommufd/device: Drop enforce_cache_coherency in
> >      iommufd_hw_pagetable_attach
> >
> >   drivers/iommu/iommufd/device.c          | 19 ++-----------------
> >   drivers/iommu/iommufd/hw_pagetable.c    |  2 +-
> >   drivers/iommu/iommufd/iommufd_private.h |  1 -
> >   3 files changed, 3 insertions(+), 19 deletions(-)
> 
> Hi Kevin and Jason,
> 
> With these two fixes, there's no issue in the intel driver any more. Do
> I understand it right?
> 

But code-wise it's still good to explicitly disallow enforce-cc on a
non-empty domain if there is no plan to support it. Just no Fix to
stable.
Baolu Lu Oct. 23, 2023, 3:09 a.m. UTC | #4 
On 10/23/23 10:55 AM, Tian, Kevin wrote:
>> From: Baolu Lu <baolu.lu@linux.intel.com>
>> Sent: Saturday, October 21, 2023 9:33 AM
>>
>> On 2023/10/21 8:37, Nicolin Chen wrote:
>>> https://lore.kernel.org/linux-
>> iommu/20231020135501.GG3952@nvidia.com/
>>> The conversation above concluded that a hwpt should only enforce cache
>>> coherency per device at the stage of its allocation, and it should not
>>> be changed or updated in the attach/replace routines.
>>>
>>> Add two patches dropping the enforce_cache_coherency calls from attach
>>> and replce routines respectively, since they were introduced with two
>>> different commits.
>>>
>>> Nicolin Chen (2):
>>>     iommufd/device: Drop enforce_cache_coherency in
>>>       iommufd_device_do_replace
>>>     iommufd/device: Drop enforce_cache_coherency in
>>>       iommufd_hw_pagetable_attach
>>>
>>>    drivers/iommu/iommufd/device.c          | 19 ++-----------------
>>>    drivers/iommu/iommufd/hw_pagetable.c    |  2 +-
>>>    drivers/iommu/iommufd/iommufd_private.h |  1 -
>>>    3 files changed, 3 insertions(+), 19 deletions(-)
>>
>> Hi Kevin and Jason,
>>
>> With these two fixes, there's no issue in the intel driver any more. Do
>> I understand it right?
>>
> 
> But code-wise it's still good to explicitly disallow enforce-cc on a
> non-empty domain if there is no plan to support it. Just no Fix to
> stable.

Yes. Make sense. The device driver implementation should be self-
contained.

Best regards,
baolu