Hi Baolu,
> -Original Message-
> From: Lu Baolu
> Sent: Thursday, May 28, 2020 6:52 PM
> To: Prakhya, Sai Praneeth ;
> iommu@lists.linux-foundation.org
> Cc: baolu...@linux.intel.com; Christoph Hellwig ; Joerg Roedel
> ; Raj, Ashok ; Will Deacon
> ; Mehta, Sohil ; Robin
> Murphy ; Jacob
Hi Sai,
On 5/29/20 3:23 AM, Sai Praneeth Prakhya wrote:
Presently, the default domain of an iommu_group is allocated during boot
time (i.e. when a device is being added to a group) and it cannot be
This is inaccurate as Joerg's code has
Hi Sai,
On 5/29/20 3:23 AM, Sai Praneeth Prakhya wrote:
Presently, the default domain of a iommu group is allocated during boot time and
it cannot be changed later. So, the device would typically be either in identity
(pass_through) mode or the device would be in DMA mode as long as the system
Hi Tom,
On 2019-12-21 8:03 a.m., Tom Murphy wrote:
> This patchset converts the intel iommu driver to the dma-iommu api.
Just wanted to note that I've rebased your series on recent kernels and
have done some testing on my old Sandybridge machine (without the DO NOT
MERGE patch) and have found no
On 5/29/20 2:03 AM, Jacob Pan wrote:
Make intel_svm_unbind_mm() a static function.
Fixes: 064a57d7ddfc ("iommu/vt-d: Replace intel SVM APIs with generic
SVA APIs")
Reported-by: kbuild test robot
Signed-off-by: Jacob Pan
Acked-by: Lu Baolu
Best regards,
baolu
---
On Thu, May 28, 2020 at 03:38:26PM -0600, Alex Williamson wrote:
> On Thu, 28 May 2020 13:57:42 -0700
> Ashok Raj wrote:
>
> > All Intel platforms guarantee that all root complex implementations
> > must send transactions up to IOMMU for address translations. Hence for
> > RCiEP devices that are
On Thu, 28 May 2020 13:57:42 -0700
Ashok Raj wrote:
> All Intel platforms guarantee that all root complex implementations
> must send transactions up to IOMMU for address translations. Hence for
> RCiEP devices that are Vendor ID Intel, can claim exception for lack of
> ACS support.
>
>
> 3.16
All Intel platforms guarantee that all root complex implementations
must send transactions up to IOMMU for address translations. Hence for
RCiEP devices that are Vendor ID Intel, can claim exception for lack of
ACS support.
3.16 Root-Complex Peer to Peer Considerations
When DMA remapping is
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Monday, May 25, 2020 6:57 AM
> To: Prakhya, Sai Praneeth
> Cc: Lu Baolu ; iommu@lists.linux-foundation.org
> Subject: Re: [PATCH] iommu: Remove functions that support private domain
>
> On Sun, May 17, 2020 at 08:29:17AM
The default domain type of an iommu group can be changed by writing to
"/sys/kernel/iommu_groups//type" file. Hence, document it's usage
and more importantly spell out its limitations.
Cc: Christoph Hellwig
Cc: Joerg Roedel
Cc: Ashok Raj
Cc: Will Deacon
Cc: Lu Baolu
Cc: Sohil Mehta
Cc:
Presently, the default domain of a iommu group is allocated during boot time and
it cannot be changed later. So, the device would typically be either in identity
(pass_through) mode or the device would be in DMA mode as long as the system is
up and running. There is no way to change the default
Presently, the default domain of an iommu_group is allocated during boot
time (i.e. when a device is being added to a group) and it cannot be
changed later. So, the device would typically be either in identity (also
known as pass_through) mode (controlled by "iommu=pt" kernel command line
"/sys/kernel/iommu_groups//type" file could be read to find out the
default domain type of an iommu group. The default domain of an iommu group
doesn't change after booting and hence could be read directly. But,
after addding support to dynamically change iommu group default domain, the
above
Make intel_svm_unbind_mm() a static function.
Fixes: 064a57d7ddfc ("iommu/vt-d: Replace intel SVM APIs with generic
SVA APIs")
Reported-by: kbuild test robot
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Alex
On Tue, May 26, 2020 at 05:07:15PM -0600, Alex Williamson wrote:
> > ---
> > drivers/iommu/iommu.c | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index 2b471419e26c..31b595dfedde 100644
> >
On Thu, 28 May 2020 11:32:50 +0800
Lu Baolu wrote:
> Hi Jorge,
>
> On 2020/5/27 20:42, Joerg Roedel wrote:
> > Hi Jean-Philippe,
> >
> > On Wed, May 27, 2020 at 12:10:38PM +0200, Jean-Philippe Brucker
> > wrote:
> >> I was wondering if you could take these two patches for v5.8. The
> >> API
Hi Shameer,
On 5/28/20 2:09 PM, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: 28 May 2020 12:48
>> To: Shameerali Kolothum Thodi ;
>> Jean-Philippe Brucker
>> Cc: Robin Murphy ; Joerg Roedel
>> ;
> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: 28 May 2020 12:48
> To: Shameerali Kolothum Thodi ;
> Jean-Philippe Brucker
> Cc: Robin Murphy ; Joerg Roedel
> ; iommu@lists.linux-foundation.org; Linux Kernel Mailing
> List ; Alex Williamson
> ; Srinath
On 5/28/20 11:15 AM, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: 28 May 2020 09:54
>> To: Jean-Philippe Brucker
>> Cc: Will Deacon ; Joerg Roedel ;
>> iommu@lists.linux-foundation.org; Shameerali Kolothum
> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: 28 May 2020 09:54
> To: Jean-Philippe Brucker
> Cc: Will Deacon ; Joerg Roedel ;
> iommu@lists.linux-foundation.org; Shameerali Kolothum Thodi
> ; Linux Kernel Mailing List
> ; Alex Williamson
> ; Srinath
Hi,
On 5/28/20 10:38 AM, Jean-Philippe Brucker wrote:
> [+ Shameer]
>
> On Thu, May 28, 2020 at 09:43:46AM +0200, Auger Eric wrote:
>> Hi,
>>
>> On 5/28/20 9:23 AM, Jean-Philippe Brucker wrote:
>>> On Thu, May 28, 2020 at 10:45:14AM +0530, Srinath Mannam wrote:
On Wed, May 27, 2020 at 11:00
[+ Shameer]
On Thu, May 28, 2020 at 09:43:46AM +0200, Auger Eric wrote:
> Hi,
>
> On 5/28/20 9:23 AM, Jean-Philippe Brucker wrote:
> > On Thu, May 28, 2020 at 10:45:14AM +0530, Srinath Mannam wrote:
> >> On Wed, May 27, 2020 at 11:00 PM Robin Murphy wrote:
> >>>
> >> Thanks Robin for your quick
From: Qiushi Wu
kobject_init_and_add() takes reference even when it fails.
Thus, when kobject_init_and_add() returns an error,
kobject_put() must be called to properly clean up the kobject.
Fixes: d72e31c93746 ("iommu: IOMMU Groups")
Signed-off-by: Qiushi Wu
---
drivers/iommu/iommu.c | 2 +-
Hi,
On 5/28/20 9:23 AM, Jean-Philippe Brucker wrote:
> On Thu, May 28, 2020 at 10:45:14AM +0530, Srinath Mannam wrote:
>> On Wed, May 27, 2020 at 11:00 PM Robin Murphy wrote:
>>>
>> Thanks Robin for your quick response.
>>> On 2020-05-27 17:03, Srinath Mannam wrote:
This patch gives the
On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote:
> Is this slowdown significant? We already iterate over every device
> when applying PCI_FIXUP_FINAL quirks, so if we used the existing
> PCI_FIXUP_FINAL, we wouldn't be adding a new loop. We would only be
> adding two more
On Thu, May 28, 2020 at 10:45:14AM +0530, Srinath Mannam wrote:
> On Wed, May 27, 2020 at 11:00 PM Robin Murphy wrote:
> >
> Thanks Robin for your quick response.
> > On 2020-05-27 17:03, Srinath Mannam wrote:
> > > This patch gives the provision to change default value of MSI IOVA base
> > > to
Hi,
On 5/27/20 7:30 PM, Robin Murphy wrote:
> On 2020-05-27 17:03, Srinath Mannam wrote:
>> This patch gives the provision to change default value of MSI IOVA base
>> to platform's suitable IOVA using module parameter. The present
>> hardcoded MSI IOVA base may not be the accessible IOVA ranges
On 2020/5/28 15:01, Lu Baolu wrote:
On 2020/5/28 0:56, Jon Derrick wrote:
Sub-devices of a real DMA device might exist on a separate segment than
the real DMA device and its IOMMU. These devices should still have a
valid device_domain_info, but the current dma alias model won't
allocate info
On 2020/5/28 0:56, Jon Derrick wrote:
By removing the real DMA indirection in find_domain(), we can allow
sub-devices of a real DMA device to have their own valid
device_domain_info. The dmar lookup and context entry removal paths have
been fixed to account for sub-devices.
Fixes: 2b0140c69637
On 2020/5/28 0:56, Jon Derrick wrote:
Sub-devices of a real DMA device might exist on a separate segment than
the real DMA device and its IOMMU. These devices should still have a
valid device_domain_info, but the current dma alias model won't
allocate info for the subdevice.
This patch adds a
On 2020/5/28 0:56, Jon Derrick wrote:
Domain context mapping can encounter issues with sub-devices of a real
DMA device. A sub-device cannot have a valid context entry due to it
potentially aliasing another device's 16-bit ID. It's expected that
sub-devices of the real DMA device uses the real
On 2020/5/27 下午5:01, Greg Kroah-Hartman wrote:
On Tue, May 26, 2020 at 07:49:09PM +0800, Zhangfei Gao wrote:
Calling pci_fixup_iommu in iommu_fwspec_init, which alloc
iommu_fwnode. Some platform devices appear as PCI but are
actually on the AMBA bus, and they need fixup in
Hi, Bjorn
On 2020/5/28 上午2:18, Bjorn Helgaas wrote:
On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
Some platform devices appear as PCI but are actually on the AMBA bus,
and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
Here introducing PCI_FIXUP_IOMMU, which is
On Wed, May 27, 2020 at 11:13:53PM -0700, Christoph Hellwig wrote:
> On Wed, May 27, 2020 at 01:53:05PM +0200, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > This function is internal to the AMD IOMMU driver and only exported
> > because the amd_iommu_v2 modules calls it. But the reason it
On Wed, May 27, 2020 at 01:53:05PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> This function is internal to the AMD IOMMU driver and only exported
> because the amd_iommu_v2 modules calls it. But the reason it is called
> from there could better be handled by
35 matches
Mail list logo
