All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Lu Baolu <baolu.lu@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>,
	Sanjay Kumar <sanjay.k.kumar@intel.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Dave Jiang <dave.jiang@intel.com>, Liu Yi L <yi.l.liu@intel.com>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] iommu/vt-d: Disallow SVA if devices don't support 64-bit address
Date: Wed, 21 Jul 2021 12:12:10 +0100	[thread overview]
Message-ID: <5662caea-a974-e511-9509-010606fda251@arm.com> (raw)
In-Reply-To: <4d3a2546-da21-605d-26a9-1f6f52123056@linux.intel.com>

On 2021-07-21 02:50, Lu Baolu wrote:
> Hi Robin,
> 
> Thanks a lot for reviewing my patch!
> 
> On 7/20/21 5:27 PM, Robin Murphy wrote:
>> On 2021-07-20 02:38, Lu Baolu wrote:
>>> When the device and CPU share an address space (such as SVA), the device
>>> must support the same addressing capability as the CPU. The CPU does not
>>> consider the addressing ability of any device when managing the page 
>>> table
>>> of a process, so the device must have enough addressing ability to bind
>>> the page table of the process.
>>>
>>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>>> ---
>>>   drivers/iommu/intel/iommu.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
>>> index f45c80ce2381..f3cca1dd384d 100644
>>> --- a/drivers/iommu/intel/iommu.c
>>> +++ b/drivers/iommu/intel/iommu.c
>>> @@ -5372,6 +5372,9 @@ static int intel_iommu_enable_sva(struct device 
>>> *dev)
>>>       if (!(iommu->flags & VTD_FLAG_SVM_CAPABLE))
>>>           return -ENODEV;
>>> +    if (!dev->dma_mask || *dev->dma_mask != DMA_BIT_MASK(64))
>>
>> Careful - VFIO doesn't set DMA masks (since it doesn't use the DMA API),
> 
> SVA doesn't work through the VFIO framework.

Did anyone say it does? My point is that, as far as I understand, the 
SVA UAPI is very much intended to work *with* VFIO, and even if the 
finer details are still mired in the /dev/ioasid discussion today we 
should definitely expect to see VFIO-like use-cases at some point. I 
certainly don't see why any of the guest SVA stuff exists already if not 
for VFIO-assigned devices?

>> so this appears to be relying on another driver having bound previously,
> 
> Yes. You are right.
> 
>> otherwise the mask would still be the default 32-bit one from 
>> pci_setup_device(). I'm not sure that's an entirely robust assumption.
> 
> Currently SVA implementation always requires a native kernel driver. The
> assumption is that the drivers should check and set 64-bit addressing
> capability before calling iommu_sva_xxx() APIs.

...and given that that is not a documented requirement, and certainly 
not a technical one (even a self-contained kernel driver could choose to 
only use SVA contexts and not touch the DMA API), it's an inherently 
fragile assumption which I'm confident *will* be broken eventually :)

Robin.

>>> +        return -ENODEV;
>>> +
>>>       if (intel_iommu_enable_pasid(iommu, dev))
>>>           return -ENODEV;
>>>
> 
> Best regards,
> baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Lu Baolu <baolu.lu@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>,
	Sanjay Kumar <sanjay.k.kumar@intel.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Dave Jiang <dave.jiang@intel.com>, Liu Yi L <yi.l.liu@intel.com>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] iommu/vt-d: Disallow SVA if devices don't support 64-bit address
Date: Wed, 21 Jul 2021 12:12:10 +0100	[thread overview]
Message-ID: <5662caea-a974-e511-9509-010606fda251@arm.com> (raw)
In-Reply-To: <4d3a2546-da21-605d-26a9-1f6f52123056@linux.intel.com>

On 2021-07-21 02:50, Lu Baolu wrote:
> Hi Robin,
> 
> Thanks a lot for reviewing my patch!
> 
> On 7/20/21 5:27 PM, Robin Murphy wrote:
>> On 2021-07-20 02:38, Lu Baolu wrote:
>>> When the device and CPU share an address space (such as SVA), the device
>>> must support the same addressing capability as the CPU. The CPU does not
>>> consider the addressing ability of any device when managing the page 
>>> table
>>> of a process, so the device must have enough addressing ability to bind
>>> the page table of the process.
>>>
>>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>>> ---
>>>   drivers/iommu/intel/iommu.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
>>> index f45c80ce2381..f3cca1dd384d 100644
>>> --- a/drivers/iommu/intel/iommu.c
>>> +++ b/drivers/iommu/intel/iommu.c
>>> @@ -5372,6 +5372,9 @@ static int intel_iommu_enable_sva(struct device 
>>> *dev)
>>>       if (!(iommu->flags & VTD_FLAG_SVM_CAPABLE))
>>>           return -ENODEV;
>>> +    if (!dev->dma_mask || *dev->dma_mask != DMA_BIT_MASK(64))
>>
>> Careful - VFIO doesn't set DMA masks (since it doesn't use the DMA API),
> 
> SVA doesn't work through the VFIO framework.

Did anyone say it does? My point is that, as far as I understand, the 
SVA UAPI is very much intended to work *with* VFIO, and even if the 
finer details are still mired in the /dev/ioasid discussion today we 
should definitely expect to see VFIO-like use-cases at some point. I 
certainly don't see why any of the guest SVA stuff exists already if not 
for VFIO-assigned devices?

>> so this appears to be relying on another driver having bound previously,
> 
> Yes. You are right.
> 
>> otherwise the mask would still be the default 32-bit one from 
>> pci_setup_device(). I'm not sure that's an entirely robust assumption.
> 
> Currently SVA implementation always requires a native kernel driver. The
> assumption is that the drivers should check and set 64-bit addressing
> capability before calling iommu_sva_xxx() APIs.

...and given that that is not a documented requirement, and certainly 
not a technical one (even a self-contained kernel driver could choose to 
only use SVA contexts and not touch the DMA API), it's an inherently 
fragile assumption which I'm confident *will* be broken eventually :)

Robin.

>>> +        return -ENODEV;
>>> +
>>>       if (intel_iommu_enable_pasid(iommu, dev))
>>>           return -ENODEV;
>>>
> 
> Best regards,
> baolu

  reply	other threads:[~2021-07-21 11:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20  1:38 [PATCH 0/5] iommu/vt-d: Several minor adjustments Lu Baolu
2021-07-20  1:38 ` Lu Baolu
2021-07-20  1:38 ` [PATCH 1/5] iommu/vt-d: Refactor Kconfig a bit Lu Baolu
2021-07-20  1:38   ` Lu Baolu
2021-07-20  1:38 ` [PATCH 2/5] iommu/vt-d: Enable Intel IOMMU scalable mode by default Lu Baolu
2021-07-20  1:38   ` Lu Baolu
2021-07-20  1:38 ` [PATCH 3/5] iommu/vt-d: Preset A/D bits for user space DMA usage Lu Baolu
2021-07-20  1:38   ` Lu Baolu
2021-07-20  1:38 ` [PATCH 4/5] iommu/vt-d: Disallow SVA if devices don't support 64-bit address Lu Baolu
2021-07-20  1:38   ` Lu Baolu
2021-07-20  9:27   ` Robin Murphy
2021-07-20  9:27     ` Robin Murphy
2021-07-21  1:50     ` Lu Baolu
2021-07-21  1:50       ` Lu Baolu
2021-07-21 11:12       ` Robin Murphy [this message]
2021-07-21 11:12         ` Robin Murphy
2021-07-21 14:17         ` Lu Baolu
2021-07-21 14:17           ` Lu Baolu
2021-07-20  1:38 ` [PATCH 5/5] iommu/vt-d: Allow devices to have more than 32 outstanding PRs Lu Baolu
2021-07-20  1:38   ` Lu Baolu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5662caea-a974-e511-9509-010606fda251@arm.com \
    --to=robin.murphy@arm.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sanjay.k.kumar@intel.com \
    --cc=yi.l.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.