On Tue, Oct 08, 2013 at 10:47:49AM -0600, Bjorn Helgaas wrote:
> I still have no idea what an "aperture type IOMMU" is,
> other than that it is "different."
An aperture based IOMMU is basically any GART-like IOMMU which can only
remap a small window (the aperture) of the DMA address space. DMA
out
On Thu, Jun 20, 2013 at 02:29:30PM +, Sethi Varun-B16395 wrote:
> Hi Joerg,
> My PAMU driver patches depend on this patch which was Ack by Kumar. Should I
> resubmit this patch as well?
Yes, please. Add the collected Acked-bys and submit everything that is
missing in v3.10-rc6.
Joer
On Tue, Apr 30, 2013 at 05:09:32PM +, Sethi Varun-B16395 wrote:
> Would you take this patchset for 3.10 merge?
Not this time. The final patch came in very late and is pretty big too.
For code of that size I would like to have a few weeks more testing in
next and probably also a non-Freescale R
On Mon, Nov 12, 2018 at 12:23:14PM +, Suthikulpanit, Suravee wrote:
> From: Wei Wang
>
> There is a race condition when accessing kvm->arch.apic_access_page_done.
> Due to it, x86_set_memory_region will fail when creating the second vcpu
> for a svm guest.
>
> Add a mutex_lock to serialize t
On Tue, May 29, 2018 at 04:10:24PM +, Kani, Toshi wrote:
> Can you explain why you think allocating a page here is a major problem?
Because a larger allocation is more likely to fail. And if you fail the
allocation, you also fail to free more pages, which _is_ a problem. So
better avoid any al
Hi Feng,
On Tue, Jan 06, 2015 at 01:10:19AM +, Wu, Feng wrote:
> Ping...
>
> Hi Joerg & David,
>
> Could you please have a look at the IOMMU part of this series (patch 02 - 04,
> patch 06 - 09 , patch 26)?
>
> Hi Thomas, Ingo, & Peter,
>
> Could you please have a look at this series, espe
On Thu, Apr 26, 2018 at 04:21:19PM +, Kani, Toshi wrote:
> All pages under the pmd had been unmapped and then lazy TLB purged with
> INVLPG before coming to this code path. Speculation is not allowed to
> pages without mapping.
CPUs have not only TLBs, but also page-walk caches which cache
in
On Thu, Apr 26, 2018 at 05:49:58PM +, Kani, Toshi wrote:
> On Thu, 2018-04-26 at 19:23 +0200, j...@8bytes.org wrote:
> > So the PMD entry you clear can still be in a page-walk cache and this
> > needs to be flushed too before you can free the PTE page. Otherwise
> > page
On Thu, Apr 26, 2018 at 10:30:14PM +, Kani, Toshi wrote:
> Thanks for the clarification. After reading through SDM one more time, I
> agree that we need a TLB purge here. Here is my current understanding.
>
> - INVLPG purges both TLB and paging-structure caches. So, PMD cache was
> purged on
On Fri, Apr 27, 2018 at 01:39:23PM +0200, Michal Hocko wrote:
> On Fri 27-04-18 09:37:20, j...@8bytes.org wrote:
> [...]
> > So until we make the generic ioremap code in lib/ioremap.c smarter about
> > unmapping/remapping ranges the best solution is making my fix work again
>
On Fri, Apr 27, 2018 at 05:22:28PM +0530, Chintan Pandya wrote:
> I'm bit confused here. Are you pointing to race within ioremap/vmalloc
> framework while updating the page table or race during tlb ops. Since
> later is arch dependent, I would not comment. But if the race being
> discussed here whi
On Fri, Apr 27, 2018 at 02:31:51PM +, Kani, Toshi wrote:
> So, we can add the step 2 on top of this patch.
> 1. Clear pud/pmd entry.
> 2. System wide TLB flush <-- TO BE ADDED BY NEW PATCH
> 3. Free its underlining pmd/pte page.
This still lacks the page-table synchronization and will thus
On Mon, Feb 25, 2019 at 08:51:22PM +, Michael Kelley wrote:
> Joerg -- What's your take on this patch set now that it has settled down? If
> you are good with it, from the Microsoft standpoint we're hoping that it
> can get into linux-next this week (given the extra week due to 5.0-rc8).
I ca
On Wed, May 07, 2014 at 01:54:52PM +0800, Su, Friendy wrote:
>
> From: Su Friendy
>
> set_device_exclusion_range(u16 devid, struct ivmd_header *m) enables
> exclusion range for ONE device. IOMMU does not translate the access
> to the exclusion range from the device.
>
> The device is specified
Hey David,
On Mon, Apr 14, 2014 at 05:03:51PM +, Woodhouse, David wrote:
> Jiang, if you can then let me have a copy with a signed-off-by I'll
> shepherd it upstream along with your other patch which is already in my
> iommu-2.6.git tree.
What is the state of these fixes? I plan to send out a
On Wed, Apr 16, 2014 at 01:58:44PM +, Woodhouse, David wrote:
> On Wed, 2014-04-16 at 15:37 +0200, j...@8bytes.org wrote:
> > What is the state of these fixes? I plan to send out a pull-request
> > before easter and hoped to include these fixes as well.
>
> I'm trav
On Mon, Sep 01, 2014 at 02:17:44PM +0800, Su, Friendy wrote:
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index 3783e0b..148ab61 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -747,7 +747,7 @@ static int __init add_speci
Hi Nan,
On Mon, Aug 24, 2015 at 06:26:33AM +, Xiao, Nan (Nan@HPS Performance,
Beijing) wrote:
> drivers/iommu/intel-iommu.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 0649b94..4213598 1006
On Tue, Aug 25, 2015 at 08:46:27AM +, Xiao, Nan (Nan@HPservers-Core-OE-PSC)
wrote:
> Yes, your patch is simple and better!
Okay, I queued this patch to my x86/vt-d branch:
>From 03932776424a799c3f065a69e98076a78530288b Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Tue, 25 Aug 2015 10:54
On Tue, Aug 25, 2015 at 09:15:39AM +, Xiao, Nan (Nan@HPservers-Core-OE-PSC)
wrote:
> In commit message:
>
> > There is a bug in iommu_context_addr() which will always use the lower
> > context table, event when the upper context table needs to be used. Fix
> > this issue.
>
> I think it sh
On Mon, Feb 02, 2015 at 10:20:49AM +, Will Deacon wrote:
> On Fri, Jan 30, 2015 at 09:55:55PM +, Arnd Bergmann wrote:
> > - reg = (iova & ~0xfff) >> 32;
> > + reg = ((u64)iova & ~0xfff) >> 32;
> > writel_relaxed(reg, cb_base + ARM_SMMU_CB_ATS1PR_HI);
> >
Adding a few more people to Cc.
On Sun, Feb 03, 2019 at 10:27:09AM +, wen yang wrote:
> Make sure to drop the reference to the device taken by
> of_find_device_by_node() on driver unbind.
>
> Signed-off-by: Wen Yang
> Cc: Joerg Roedel
> Cc: io...@lists.linux-foundation.org
> Cc: linux-kerne
Hi Suravee,
On Thu, Jan 17, 2019 at 08:44:36AM +, Suthikulpanit, Suravee wrote:
> Then, in __domain_flush_pages, we issue command when the dev_iommu[] >= 0.
> This should preserve previous behavior, and only add flushing condition to
> the specific IOMMU in detached state. Please let me know w
Hi Suravee,
On Tue, Jan 22, 2019 at 03:53:18PM +, Suthikulpanit, Suravee wrote:
> Thanks for the detail. Alright then, let's just go with the version you
> sent on 1/16/19. Do you want me to resend V3 with that changes, or
> would you be taking care of that?
Please send me a v3 based on the d
Hi Suravee,
On Wed, Jan 16, 2019 at 04:15:10AM +, Suthikulpanit, Suravee wrote:
> From: Suravee Suthikulpanit
>
> When a device switches domain, IOMMU driver detach device from the old
> domain, and attach device to the new domain. During this period
> the host table root pointer is not set,
On Wed, Jan 16, 2019 at 04:16:25AM +, Suthikulpanit, Suravee wrote:
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index 525659b88ade..ab31ba75da1b 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -1248,7 +1248,13 @@ static void __domain_fl
On Wed, Jan 16, 2019 at 02:08:55PM +, Suthikulpanit, Suravee wrote:
> Actually, I am not sure how we would be missing the flush on the last device.
> In my test, I am seeing the flush command being issued correctly during
> vfio_unmap_unpin(), which is after all devices are detached.
> Although
On Wed, Jan 16, 2019 at 02:40:59PM +, Suthikulpanit, Suravee wrote:
> Actually, device_flush_dte(alias) should be needed regardless of this patch.
> Are you planning to add this?
Yes, I stumbled over this while writing the diff. I'll submit that as a
separate patch.
Thanks,
Joerg
Hi Suravee,
On Thu, Jan 24, 2019 at 03:25:19AM +, Suthikulpanit, Suravee wrote:
> Actually, I just noticed that device_flush_dte() has already handled flushing
> the DTE
> for alias device as well. Please see the link below.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/iommu/am
On Thu, Jan 24, 2019 at 04:16:45AM +, Suthikulpanit, Suravee wrote:
> drivers/iommu/amd_iommu.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
Applied, thanks Suravee.
On Thu, Jan 24, 2019 at 02:17:34PM +, Suthikulpanit, Suravee wrote:
> On 1/24/19 9:11 PM, j...@8bytes.org wrote:
> > On Thu, Jan 24, 2019 at 04:16:45AM +, Suthikulpanit, Suravee wrote:
> >> drivers/iommu/amd_iommu.c | 15 +++
> >> 1 file c
On Thu, Jun 09, 2016 at 03:48:44PM +, Vesely, Jan wrote:
> On Sat, 2016-05-21 at 14:11 -0400, Jan Vesely wrote:
> > From: Jan Vesely
> >
> > Signed-off-by: Jan Vesely
> > ---
> > drivers/iommu/amd_iommu.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/iommu/amd_iomm
Hi Mark,
On Tue, Feb 17, 2015 at 02:48:03PM -0500, Mark Hounschell wrote:
> I understand that AMD IOMMU support is not available for 32-bit
> kernels. I believe the INTEL IOMMU is supported there. Not knowing
> why, I was curious if that is going to remain that way?
Yes, I have no plan on making
33 matches
Mail list logo
