On Fri, 26 Apr 2019 17:53:43 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 4/24/19 1:31 AM, Jacob Pan wrote:
> > Guest shared virtual address (SVA) may require host to shadow guest
> > PASID tables. Guest PASID can also be allocated from the host via
> > enlightened interfaces. In this case, guest
Michael S. Tsirkin writes:
> On Wed, Apr 24, 2019 at 10:01:56PM -0300, Thiago Jung Bauermann wrote:
>>
>> Michael S. Tsirkin writes:
>>
>> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
>> >>
>> >> Michael S. Tsirkin writes:
>> >>
>> >> > On Thu, Mar 21, 2019 at
From: Joerg Roedel
[ Upstream commit 3c677d206210f53a4be972211066c0f1cd47fe12 ]
The exlcusion range limit register needs to contain the
base-address of the last page that is part of the range, as
bits 0-11 of this register are treated as 0xfff by the
hardware for comparisons.
So correctly set
From: Joerg Roedel
[ Upstream commit 3c677d206210f53a4be972211066c0f1cd47fe12 ]
The exlcusion range limit register needs to contain the
base-address of the last page that is part of the range, as
bits 0-11 of this register are treated as 0xfff by the
hardware for comparisons.
So correctly set
From: Joerg Roedel
[ Upstream commit 3c677d206210f53a4be972211066c0f1cd47fe12 ]
The exlcusion range limit register needs to contain the
base-address of the last page that is part of the range, as
bits 0-11 of this register are treated as 0xfff by the
hardware for comparisons.
So correctly set
On Fri, 26 Apr 2019 17:42:05 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 4/24/19 1:31 AM, Jacob Pan wrote:
> > Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
> > With PASID granular translation type set to 0x11b, translation
> > result from the first level(FL) also subject to a
From: Joerg Roedel
[ Upstream commit 3c677d206210f53a4be972211066c0f1cd47fe12 ]
The exlcusion range limit register needs to contain the
base-address of the last page that is part of the range, as
bits 0-11 of this register are treated as 0xfff by the
hardware for comparisons.
So correctly set
From: Joerg Roedel
[ Upstream commit 3c677d206210f53a4be972211066c0f1cd47fe12 ]
The exlcusion range limit register needs to contain the
base-address of the last page that is part of the range, as
bits 0-11 of this register are treated as 0xfff by the
hardware for comparisons.
So correctly set
From: Joerg Roedel
[ Upstream commit 3c677d206210f53a4be972211066c0f1cd47fe12 ]
The exlcusion range limit register needs to contain the
base-address of the last page that is part of the range, as
bits 0-11 of this register are treated as 0xfff by the
hardware for comparisons.
So correctly set
On Wed, Apr 24, 2019 at 09:15:25PM +0200, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Joerg Roedel
> ---
> drivers/iommu/amd_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Wed, Apr 24, 2019 at 09:16:10PM +0200, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Joerg Roedel
> ---
> drivers/iommu/intel-iommu.c | 2 +-
> drivers/iommu/intel_irq_remapping.c | 2 +-
> 2 files
On Wed, Apr 24, 2019 at 05:50:51PM +0100, Tom Murphy wrote:
> check if there is a not-present cache present and flush it if there is.
>
> Signed-off-by: Tom Murphy
> ---
> drivers/iommu/amd_iommu.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/iommu/amd_iommu.c
Hi Jordan,
On Mon, Mar 18, 2019 at 08:19:12AM -0600, Jordan Crouse wrote:
> Adreno GPUs can an internal mechanism to switch the pagetable address in the
> attached arm-smmu v2 IOMMU so that each individual rendering process can have
> their own pagetable. The driver uses iommu_map and iommu_unmap
On 25/04/2019 19:19, Jacob Pan wrote:
> Hi Christoph,
>
> On Tue, 23 Apr 2019 23:19:03 -0700
> Christoph Hellwig wrote:
>
>> On Tue, Apr 23, 2019 at 04:31:06PM -0700, Jacob Pan wrote:
>>> The allocator doesn't really belong in drivers/iommu because some
>>> drivers would like to allocate PASIDs
On Fri, Apr 26, 2019 at 12:47:43PM +0100, Jean-Philippe Brucker wrote:
> >> On Tue, Apr 23, 2019 at 04:31:06PM -0700, Jacob Pan wrote:
> >>> The allocator doesn't really belong in drivers/iommu because some
> >>> drivers would like to allocate PASIDs for devices that aren't
> >>> managed by an
On Wed, Apr 24, 2019 at 12:52:52PM +0100, Will Deacon wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
> for-joerg/arm-smmu/updates
Pulled, thanks Will.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Fri, 26 Apr 2019 05:21:15 -0700
Christoph Hellwig wrote:
> On Fri, Apr 26, 2019 at 12:47:43PM +0100, Jean-Philippe Brucker wrote:
> > >> On Tue, Apr 23, 2019 at 04:31:06PM -0700, Jacob Pan wrote:
> > >>> The allocator doesn't really belong in drivers/iommu because
> > >>> some drivers would
Hi Jacob,
On 4/24/19 1:31 AM, Jacob Pan wrote:
> When Shared Virtual Address (SVA) is enabled for a guest OS via
> vIOMMU, we need to provide invalidation support at IOMMU API and driver
> level. This patch adds Intel VT-d specific function to implement
> iommu passdown invalidate API for shared
On Wed, Apr 24, 2019 at 05:06:38PM +0200, Christoph Hellwig wrote:
> > + if (!dma_release_from_contiguous(dev, page, count))
> > + __free_pages(page, get_order(size));
>
> Same for dma_release_from_contiguous - drop the _from, pass the
> actual size,
On Fri, Apr 26, 2019 at 01:21:12PM -0700, Nicolin Chen wrote:
> What do you think of dma_free_contiguous() instead? I feel "free"
> is a bit more commonly used (in dma-mapping.h) and it's shorter.
Yeah, that sounds good.
___
iommu mailing list
On Wed, 24 Apr 2019 19:27:26 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 4/24/19 1:31 AM, Jacob Pan wrote:
> > When VT-d driver runs in the guest, PASID allocation must be
> > performed via virtual command interface. This patch register a
> registers
will fix
> > custom IOASID allocator which
On Thu, 25 Apr 2019 12:04:01 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 4/24/19 1:31 AM, Jacob Pan wrote:
> > Make use of generic IOASID code to manage PASID allocation,
> > free, and lookup.
> >
> > Signed-off-by: Jacob Pan
> > ---
> > drivers/iommu/Kconfig | 1 +
> >
On 4/26/19 1:40 AM, Jacob Pan wrote:
> On Wed, 24 Apr 2019 19:27:52 +0200
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 4/24/19 1:31 AM, Jacob Pan wrote:
>>> From: Lu Baolu
>>>
>>> If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the
>>> IOMMU driver should rely on the emulation
Hi Jacob,
On 4/25/19 11:29 PM, Jacob Pan wrote:
> Hi Eric,
>
> Thanks for the review.
>
> On Thu, 25 Apr 2019 12:03:42 +0200
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 4/24/19 1:31 AM, Jacob Pan wrote:
>>> Sometimes, IOASID allocation must be handled by platform specific
>>> code. The use
Hi Tom,
On Mon, Apr 15, 2019 at 07:05:56PM +0100, Tom Murphy wrote:
> dma_ops_domain_free() expects domain to be in a global list.
> Arguably, could be called before protection_domain_init().
This could in theory create new races because a not fully initialized
domain becomes visible in the
From: Joerg Roedel
This variable hold a global list of allocated protection
domains in the AMD IOMMU driver. By now this list is never
traversed anymore, so the list and the lock protecting it
can be removed.
Cc: Tom Murphy
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 33
On Wed, Apr 17, 2019 at 10:41:19AM +0800, Wen Yang wrote:
> drivers/iommu/mtk_iommu.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
[ Adding more people. ]
On Wed, Apr 17, 2019 at 05:12:57PM +0800, Pan Bian wrote:
> The use count of svm->mm is incremented by mmget_not_zero. However, it
> is not dropped when the address is not canonical. This patch fixes the
> bug.
>
> Fixes: 9d8c3af31607("iommu/vt-d: IOMMU Page Request needs
On Fri, Apr 26, 2019 at 10:52:28AM -0400, Qian Cai wrote:
> Applying some memory pressure would causes smartpqi offline even in today's
> linux-next. This can always be reproduced by a LTP test cases [1] or sometimes
> just compiling kernels.
>
> Reverting the commit "iommu/amd: Set exclusion
On 4/26/19 9:44 AM, Joerg Roedel wrote:
> On Thu, Apr 18, 2019 at 01:46:24PM -0500, Gustavo A. R. Silva wrote:
>> Make use of the struct_size() helper instead of an open-coded version
>> in order to avoid any potential type mistakes, in particular in the
>> context in which this code is being
On Thu, Apr 25, 2019 at 10:07:19AM +0800, Lu Baolu wrote:
> This is not VT-d specific. It's just how generic IOMMU works.
>
> Normally, IOMMU works in paging mode. So if a driver issues DMA with
> IOVA 0x0123, IOMMU can remap it with a physical address 0x0123.
> But we should never expect
On Fri, 26 Apr 2019 11:06:54 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 4/25/19 11:29 PM, Jacob Pan wrote:
> > Hi Eric,
> >
> > Thanks for the review.
> >
> > On Thu, 25 Apr 2019 12:03:42 +0200
> > Auger Eric wrote:
> >
> >> Hi Jacob,
> >>
> >> On 4/24/19 1:31 AM, Jacob Pan wrote:
> >>>
Hi Jacob,
On 4/24/19 1:31 AM, Jacob Pan wrote:
> Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
> With PASID granular translation type set to 0x11b, translation
> result from the first level(FL) also subject to a second level(SL)
> page table translation. This mode is used for SVA
Hi Jacob,
On 4/24/19 1:31 AM, Jacob Pan wrote:
> Guest shared virtual address (SVA) may require host to shadow guest
> PASID tables. Guest PASID can also be allocated from the host via
> enlightened interfaces. In this case, guest needs to bind the guest
> mm, i.e. cr3 in guest phisical address
Hi
On 4/24/19 1:31 AM, Jacob Pan wrote:
> Use combined macro for_each_svm_dev() to simplify SVM device iteration.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> drivers/iommu/intel-svm.c | 76
>
On Fri, Apr 19, 2019 at 02:43:29PM +0800, Lu Baolu wrote:
> drivers/iommu/intel-iommu.c | 6 ++
> 1 file changed, 6 insertions(+)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Thu, Apr 18, 2019 at 01:46:24PM -0500, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, replace code of the following
On Tue, Apr 23, 2019 at 03:50:08PM +0800, Kefeng Wang wrote:
> drivers/iommu/omap-iommu.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Tue, Apr 23, 2019 at 09:03:34PM +0100, Tom Murphy wrote:
> These checks were intended to handle devices not mapped by the IOMMU.
> Since the AMD IOMMU driver uses per-device dma_ops these functions can
> no longer be called by direct mapped devices. So these checks aren't
> needed anymore.
>
>
On Fri, 26 Apr 2019 09:24:29 +0200
Auger Eric wrote:
> > Agreed
> >>> +#define VCMD_VRSP_RESULE(e) (((e) >> 8) &
> >>> 0xf)
> >> nit: s/RESULE/RSLT?
> > yes. Also the mask bits should be 8 to 63
> > s/0xf/GENMASK_ULL(63, 8))/
> Well the macro definition looks
On Thu, Apr 25, 2019 at 11:30:54AM +, Laurentiu Tudor wrote:
> > I think the first step is to move the two USB controller that can only
> > DMA to their own BAR off the existing DMA coherent infrastructure. The
> > controllers are already identified using the HCD_LOCAL_MEM flag, so we
> >
Applying some memory pressure would causes smartpqi offline even in today's
linux-next. This can always be reproduced by a LTP test cases [1] or sometimes
just compiling kernels.
Reverting the commit "iommu/amd: Set exclusion range correctly" fixed the issue.
[ 213.437112] smartpqi
On Fri, 26 Apr 2019 15:38:46 +0200
Joerg Roedel wrote:
> [ Adding more people. ]
>
> On Wed, Apr 17, 2019 at 05:12:57PM +0800, Pan Bian wrote:
> > The use count of svm->mm is incremented by mmget_not_zero. However,
> > it is not dropped when the address is not canonical. This patch
> > fixes
On Fri, 2019-04-26 at 17:26 +0200, Joerg Roedel wrote:
> On Fri, Apr 26, 2019 at 10:52:28AM -0400, Qian Cai wrote:
> > Applying some memory pressure would causes smartpqi offline even in today's
> > linux-next. This can always be reproduced by a LTP test cases [1] or
> > sometimes
> > just
Hi Jacob,
On 4/24/19 1:31 AM, Jacob Pan wrote:
> To convert to/from cache types and granularities between generic and
> VT-d specific counterparts, a 2D arrary is used. Introduce the limits
array
> to help define the converstion array size.
conversion
>
> Signed-off-by: Jacob Pan
> ---
>
45 matches
Mail list logo
