On Fri, Mar 17, 2017 at 11:53:09AM -0400, Alex Deucher wrote:
> On Fri, Mar 17, 2017 at 8:15 AM, Daniel Drake wrote:
> > Hi,
> >
> > On Mon, Mar 13, 2017 at 2:01 PM, Deucher, Alexander
> > wrote:
> >> > We are unable to boot Acer Aspire E5-553G (AMD FX-9800P RADEON R7) nor
> >> > Acer Aspire E5-5
On Tue, Mar 21, 2017 at 04:01:53PM +, Deucher, Alexander wrote:
> It seems to only affect Stoney systems, but not others (Carrizo,
> Bristol, etc.). Maybe we could just disable it on Stoney until we
> root cause it.
Completion-wait loop timeouts indicate something is seriously wrong. How
can
On Tue, Mar 21, 2017 at 04:17:40PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: 'j...@8bytes.org' [mailto:j...@8bytes.org]
> > Sent: Tuesday, March 21, 2017 12:11 PM
> > To: Deucher, Alexander
> > Cc: Ale
On Tue, Mar 21, 2017 at 04:30:55PM +, Deucher, Alexander wrote:
> > I am preparing a debug-patch that disables ATS for these GPUs so someone
> > with such a chip can test it.
>
> Thanks Joerg.
Here is a debug patch, using the hard hammer of disabling the use of ATS
completly in the AMD IOMMU
On Thu, Apr 27, 2017 at 03:34:06PM +, Zhuo, Qiuxu wrote:
> It looks like the printk is misleading and it’s nothing actually
> failed, but just it isn’t copying if the new kernel is not a kdump
> kernel.
Yes, that is true. But the messages are harmless and you are safe to
ignore them in your us
On Mon, Feb 04, 2013 at 09:54:07PM +0100, Hiroshi Doyu wrote:
> Hiroshi Doyu wrote @ Mon, 04 Feb 2013 22:39:21 +0200 (EET):
>
> > > Upon reflection, that comment probably isn't correct, since the only way
> > > to know where each register range begins, relative to the register
> > > numbers that
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 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
Hi Will,
On Thu, Oct 31, 2013 at 12:59:02AM +, Will Deacon wrote:
> Could you pull this please, Joerg? It would be good to have this in next
> before the merge window...
Just pulled. Sorry for the long delay.
Joerg
___
iommu mailing list
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 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
On Sun, Jul 06, 2014 at 07:25:18PM +, Gabbay, Oded wrote:
> Once we can agree on that, than I think we can agree that kfd and hmm
> can and should be bounded to mm struct and not file descriptors.
The file descriptor concept is the way it works in the rest of the
kernel. It works for numerous
On Mon, Jul 07, 2014 at 01:43:03PM +0300, Oded Gabbay wrote:
> As Jerome pointed out, there are a couple of subsystems/drivers who
> don't rely on file descriptors but on the tear-down of mm struct, e.g.
> aio, ksm, uprobes, khugepaged
What you name here is completly different from what HSA offers
On Mon, Oct 22, 2018 at 12:50:56PM +0100, Robin Murphy wrote:
> To me, that sounds like a very good argument for having separate "attach as
> primary domain" and "attach as aux domain" APIs.
I agree with that, overloading iommu_attach_device() to support
aux-domains is not going to be a maintainab
Hi,
On Wed, Nov 07, 2018 at 11:40:30AM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> On 11/7/18 12:25 AM, j...@8bytes.org wrote:
> Nowadays, we can find PASID granular DMA translation on both ARM and x86
> platforms. With PASID granular DMA translation supported in system iommu, if
>
On Mon, Nov 12, 2018 at 12:26:30PM +, Suthikulpanit, Suravee wrote:
> From: Filippo Sironi
>
> This register should have been programmed with the physical address
> of the memory location containing the shadow tail pointer for
> the guest virtual APIC log instead of the base address.
>
> Fix
Hi Jean-Philippe,
On Thu, Nov 08, 2018 at 06:29:42PM +, Jean-Philippe Brucker wrote:
> (1) My initial approach would have been to use the same page tables for
> the default_domain and this new domain, but it might be precisely what
> you were trying to avoid with this new proposal: a device at
On Wed, Nov 21, 2018 at 12:40:44PM +0800, Lu Baolu wrote:
> Can you please elaborate a bit more about the concept of subdomains?
> From my point of view, an aux-domain is a normal un-managed domain which
> has a PASID and could be attached to any ADIs through the aux-domain
> specific attach/detach
Hi Kevin,
On Thu, Nov 22, 2018 at 08:39:19AM +, Tian, Kevin wrote:
> I agree special action needs to be taken for everything else (other than
> DMA-API), but the point that I didn't get is why the action must be based
> a new SVA-type domain, instead of extending default domain with SVA
> capa
Hi Jean-Philippe,
On Wed, Nov 21, 2018 at 07:05:13PM +, Jean-Philippe Brucker wrote:
> For the moment though, I think we should allow device drivers to use the
> DMA-API at the same time as SVA.
Yeah, that makes sense.
> If a device driver has to map a management ring buffer for example,
> i
On Wed, Nov 28, 2018 at 09:23:35AM +, Yoshihiro Shimoda wrote:
> Yoshihiro Shimoda (2):
> iommu/ipmmu-vmsa: Modify ipmmu_slave_whitelist() to check SoC
> revisions
> iommu/ipmmu-vmsa: add an array of slave devices whitelist
Applied, thanks.
_
Hi,
On Mon, Nov 26, 2018 at 07:29:45AM +, Tian, Kevin wrote:
> btw Baolu just reminded me one thing which is worthy of noting here.
> 'primary' vs. 'aux' concept makes sense only when we look from a device
> p.o.v. That binding relationship is not (*should not be*) carry-and-forwarded
> cross
Hi Kevin,
On Mon, Dec 10, 2018 at 02:06:44AM +, Tian, Kevin wrote:
> Can I interpret above as that you agree with the aux domain concept (i.e. one
> device can be linked to multiple domains) in general, and now we're just
> trying
> to address the remaining open in API level?
Yes, I thouht a
Hi Lu Baolu,
On Mon, Dec 10, 2018 at 10:57:22AM +0800, Lu Baolu wrote:
> > /* Check if a device supports a given feature of the IOMMU-API */
> > bool iommu_dev_has_feature(struct device *dev, enum iommu_dev_features
> > *feat);
>
> Here we pass in a pointer of "enum iommu_dev_features",
On Tue, Dec 11, 2018 at 06:34:23PM +, Jean-Philippe Brucker wrote:
> The cost of enabling those features for a device does seem negligible.
> For the SMMU we need to allocate about 70k of additional memory for the
> initial PASID table, but enabling the PASID cap shouldn't add any
> overhead ot
On Tue, Dec 11, 2018 at 01:35:23PM +, Jean-Philippe Brucker wrote:
> > /* So we need a iommu_aux_detach_all()? */
>
> This could be useful for device drivers that want to do bulk cleanup on
> device removal. If they rely on Function Level Reset to disable PASID
> states for example, they c
Hi Kevin,
On Wed, Dec 12, 2018 at 09:31:27AM +, Tian, Kevin wrote:
> > From: 'j...@8bytes.org'
> > Sent: Monday, December 10, 2018 4:58 PM
> > These represent whether the device together with the IOMMU support
> > them,
> > basically whether the
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 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 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.
___
iommu mailing list
iommu@lists.linux-foundation.org
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
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: iommu@lists.linux-foundation.org
> Cc: linux-ker..
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, Mar 20, 2019 at 08:14:56AM +, Suthikulpanit, Suravee wrote:
> When AVIC is enabled and the VM has discrete device assignment,
> the interrupt remapping table (IRT) is used to keep track of which
> destination APIC ID the IOMMU will inject the device interrput to.
>
> This means every t
Hi Jonathan,
On Mon, Apr 13, 2020 at 10:10:50PM +, Derrick, Jonathan wrote:
> I had to add the following for initial VMD support. The new PCIe domain
> added on VMD endpoint probe didn't have the dev_iommu member set on the
> VMD subdevices, which I'm guessing is due to probe_iommu_group alrea
Hi Jonathan, Hi Daniel,
On Fri, Apr 17, 2020 at 01:14:30AM +, Derrick, Jonathan wrote:
> Hi Daniel> I should have CCed you on this, but it should temporarily resolve
> that
> issue:
> https://lists.linuxfoundation.org/pipermail/iommu/2020-April/043253.html
Yes, this is an issue in the hotplu
On Tue, Jan 24, 2012 at 03:46:01PM +0200, Felipe Balbi wrote:
> On Tue, Jan 24, 2012 at 02:41:21PM +0100, Hiroshi Doyu wrote:
> > Actually I really like the concept of this "domain" now, which hides
> > the H/W hierarchy from users.
> >
> > But in Tegra SMMU/GART case, there's a single one IOMMU d
On Wed, Jan 25, 2012 at 08:40:20AM +0100, Hiroshi Doyu wrote:
> From: Hiroshi DOYU
> Date: Wed, 16 Nov 2011 17:36:37 +0200
> Subject: [PATCH 1/2] ARM: IOMMU: Tegra20: Add iommu_ops for GART driver
>
> Tegra 20 IOMMU H/W, GART (Graphics Address Relocation Table). This
> patch implements struct iom
On Wed, Jan 25, 2012 at 08:39:32AM +0100, Hiroshi Doyu wrote:
> From: Hiroshi DOYU
> Date: Thu, 17 Nov 2011 07:31:31 +0200
> Subject: [PATCH 2/2] ARM: IOMMU: Tegra30: Add iommu_ops for SMMU driver
>
> Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit). This patch
> implements struct iommu_o
On Tue, Aug 12, 2014 at 09:56:11AM -0700, Olav Haugan wrote:
> On 8/12/2014 3:48 AM, Rob Clark wrote:
> > iirc, one plan for 'flags' was some sort of DONT_FLUSH_TLB flag for
> > drivers which wanted to map/unmap N buffers with a single flush at the
> > end. There might have been some other usages
On Mon, Aug 18, 2014 at 01:48:46PM -0700, Olav Haugan wrote:
> On 8/18/2014 11:32 AM, Rob Clark wrote:
> No, I do not have other uses right now. But could imagine use cases like
> "force mapping" flag etc.
I think it is worth discussing to add a flush() function to the
IOMMU-API. I sent a patch-
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 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
Hi Will,
On Fri, Jan 16, 2015 at 02:01:31PM +, Will Deacon wrote:
> I've not received any feedback on this revision of the series, but it's
> working well for me and Laurent showed that it works with his IOMMU too.
>
> Joerg -- can I include this in my pull request for 3.20, or is there
> any
On Mon, Jan 19, 2015 at 03:56:42PM +0200, Laurent Pinchart wrote:
> Yes, and I've rebased them (or actually it, it's a single patch) on v2. I
> haven't had time to test the result yet, I'll try to do so later tonight or
> tomorrow.
Great! Would be good if this can go upstream with more than one
On Wed, Jan 21, 2015 at 04:58:12PM +0200, Laurent Pinchart wrote:
> All my other ipmmu patches have been queued by Joerg in his next branch, on
> which this patch is based. If you base your series on the same branch you can
> just queue this patch on top of it. Do you plan to submit the result to
On Wed, Jan 21, 2015 at 05:07:03PM +0200, Laurent Pinchart wrote:
> As you wish. I just thought you would prefer merging the series with at least
> one user.
Yes, and with your patch there would be two users: ARM-SMMU and the VMSA
IPMMU. So ideally I would apply/pull Will's patches on v3.19-rc5 w
On Wed, Jan 21, 2015 at 05:31:05PM +0200, Laurent Pinchart wrote:
> On Wednesday 21 January 2015 16:27:24 j...@8bytes.org wrote:
> > On Wed, Jan 21, 2015 at 05:07:03PM +0200, Laurent Pinchart wrote:
> > > As you wish. I just thought you would prefer merging the series with at
&g
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);
> >
On Wed, Apr 01, 2015 at 05:36:18PM +0100, Will Deacon wrote:
> The issue (speaking in terms of the ARM SMMU, since that's what I'm familiar
> with) is that we don't know the page sizes until we've chosen our
> translation regime.
Can't you hard-code one regime in the driver and just don't use the
On Tue, Sep 10, 2019 at 05:30:09PM +, Mehta, Sohil wrote:
> On Tue, 2019-09-10 at 10:08 +0200, Joerg Roedel wrote:
> > > + "Unknown", "Unknown", "Unknown", "Unknown", "Unknown",
> > "Unknown", "Unknown", /* 0x49-0x4F */
> >
> > Maybe add the number (0x49-0x4f) to the respecting "Unknown" f
On Mon, Oct 14, 2019 at 08:06:05PM +, Suthikulpanit, Suravee wrote:
> IOMMU Event Log encodes 20-bit PASID for events:
> ILLEGAL_DEV_TABLE_ENTRY
> IO_PAGE_FAULT
> PAGE_TAB_HARDWARE_ERROR
> INVALID_DEVICE_REQUEST
> as:
> PASID[15:0] = bit 47:32
> PASID[19:16] = bit 19:16
On Mon, Oct 14, 2019 at 08:06:19PM +, Suthikulpanit, Suravee wrote:
> Reuse existing macro to simplify the code and improve readability.
>
> Cc: Joerg Roedel
> Cc: Gary R Hook
> Signed-off-by: Suravee Suthikulpanit
> ---
> drivers/iommu/amd_iommu.c | 3 +--
> 1 file changed, 1 insertion(+)
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
On Tue, Feb 13, 2018 at 12:57:23PM +, Jean-Philippe Brucker wrote:
> * bind_device() fails if the device's group has more than one device,
> otherwise calls __bind_device(). This prevents device drivers that are
> oblivious to IOMMU groups from opening a backdoor.
>
> * bind_group() calls __bi
Hi Suravee,
On Tue, Jul 16, 2019 at 04:29:16AM +, Suthikulpanit, Suravee wrote:
> AMD IOMMU requires IntCapXT registers to be setup in order to generate
> its own interrupts (for Event Log, PPR Log, and GA Log) with 32-bit
> APIC destination ID. Without this support, AMD IOMMU MSI interrupts
>
On Tue, Jul 23, 2019 at 07:00:37PM +, Suthikulpanit, Suravee wrote:
> Re-factore the logic for activate/deactivate guest virtual APIC mode (GAM)
> into helper functions, and export them for other drivers (e.g. SVM).
> to support run-time activate/deactivate of SVM AVIC.
>
> Cc: Joerg Roedel
>
On Fri, Jul 17, 2020 at 03:15:43PM +, Sironi, Filippo wrote:
> I don't believe that we want to trust a userspace driver here, this may
> result in hosts becoming unstable because devices are asked to do things
> they aren't meant to do (e.g., DMA beyond 48 bits).
How is the hosts stability aff
On Wed, Jul 22, 2020 at 12:34:57PM +, Sironi, Filippo wrote:
> On Wed, 2020-07-22 at 14:19 +0200, j...@8bytes.org wrote:
> I wouldn't be surprised if a PCIe device raises a PCIe SERR if it is
> asked to do DMA beyond its abilities.
Yeah, but that would also make it imposs
On Wed, Mar 17, 2021 at 07:14:17PM +, Derrick, Jonathan wrote:
> Gentle reminder, for v5.13 ?
This should go through the PCI tree, Bjorn?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi John,
On Fri, Jun 25, 2021 at 05:41:09PM +0100, John Garry wrote:
> We think that this series is ready to go.
>
> There would be a build conflict with the following:
> https://lore.kernel.org/linux-iommu/20210616100500.174507-1-na...@vmware.com/
>
> So please let us know where you stand on it
On Tue, Jul 27, 2021 at 06:51:56AM +, Shameerali Kolothum Thodi wrote:
> A gentle ping on this...
This needs more reviews, and please add
Will Deacon
when you post the next version of this patch-set.
Regards,
Joerg
___
iommu mail
On Mon, Aug 09, 2021 at 08:30:03AM +, Yong Wu (吴勇) wrote:
> Thanks very much for your confirm. I will your Ack for iommu part in
> the next version.
Note that my ack is conditional on the premise that Matthias has
reviewed the IOMMU parts.
Thanks,
Joerg
__
On Mon, Oct 12, 2020 at 08:38:54AM +, Tian, Kevin wrote:
> > From: Jason Wang
> > Jason suggest something like /dev/sva. There will be a lot of other
> > subsystems that could benefit from this (e.g vDPA).
Honestly, I fail to see the benefit of offloading these IOMMU specific
setup tasks to
On Tue, Nov 03, 2020 at 08:56:43AM -0400, Jason Gunthorpe wrote:
> On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote:
> > So having said this, what is the benefit of exposing those SVA internals
> > to user-space?
>
> Only the device use of the PASID is device
On Tue, Nov 03, 2020 at 09:23:35AM -0400, Jason Gunthorpe wrote:
> Userspace needs fine grained control over the composition of the page
> table behind the PASID, 1:1 with the mm_struct is only one use case.
VFIO already offers an interface for that. It shouldn't be too
complicated to expand that
On Tue, Nov 03, 2020 at 10:06:42AM -0400, Jason Gunthorpe wrote:
> The point is that other places beyond VFIO need this
Which and why?
> Sure, but sometimes it is necessary, and in those cases the answer
> can't be "rewrite a SVA driver to use vfio"
This is getting to abstract. Can you come up w
On Tue, Nov 03, 2020 at 11:22:23AM -0400, Jason Gunthorpe wrote:
> This whole thread was brought up by IDXD which has a SVA driver and
> now wants to add a vfio-mdev driver too. SVA devices that want to be
> plugged into VMs are going to be common - this architecture that a SVA
> driver cannot cove
On Tue, Nov 03, 2020 at 01:48:51PM -0400, Jason Gunthorpe wrote:
> I think the same PCI driver with a small flag to support the PF or
> VF is not the same as two completely different drivers in different
> subsystems
There are counter-examples: ixgbe vs. ixgbevf.
Note that also a single driver ca
On Thu, Oct 14, 2021 at 03:00:38AM +, Tian, Kevin wrote:
> I saw a concept of deferred attach in iommu core. See iommu_is_
> attach_deferred(). Currently this is vendor specific and I haven't
> looked into the exact reason why some vendor sets it now. Just
> be curious whether the same reason m
Hi Nipun,
On Thu, Jun 21, 2018 at 03:59:27AM +, Nipun Gupta wrote:
> Will this patch-set be taken for the next kernel release (and via which tree)?
I can take this through IOMMU tree if nobody objects. Please work out
the last remaining comment on patch 7 with Robin and then re-send with
all
Hi Varun,
On Tue, May 05, 2015 at 05:57:32PM +, Varun Sethi wrote:
> Actually PPC32 dependency is incorrect, that's what Emil's patch
> removed. As a result PAMU driver got built on other platforms as well.
> commit f2fafdd954d743a0e68e5cd76dbef2f2454deefa
>
> PAMU driver should depend on PPC
On Wed, May 20, 2015 at 03:15:59PM -0400, Mark Hounschell wrote:
> On 05/20/2015 01:30 PM, William Davis wrote:
> >In an IOMMU environment, the DMA ops would be one of the IOMMU
> >implementations, so these APIs would create a mapping for the peer device
> >resource, even if it's on the same bus. W
Hi Will,
On Thu, Aug 06, 2015 at 04:23:27PM +0100, Will Deacon wrote:
> We're quite keen to get this in for arm64, since we're without IOMMU DMA
> ops and need to get something upstream. Do you think this is likely to
> be merged for 4.3/4.4 or would we be better off doing our own
> arch-private i
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
Hi Nan,
I applied this patch with some formatting fixes, thanks. Details below:
From: "Xiao, Nan (Nan@HPS Performance, Beijing)"
git-am made this author-line out of your patch: "(Nan@HPS <(Nan@HPS>"
Which doesn't even look like a valid email address. I fixed it, but
please include a From: line
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
Hi Robin,
On Tue, Oct 13, 2015 at 01:12:46PM +0100, Robin Murphy wrote:
> Anyway, what are your thoughts on taking this for 4.4? Since the
> dependencies are now in and we're at -rc5 already, I'm on the verge
> of reposting a self-contained version to go through arm64, as we
> really need to unblo
On Thu, Feb 18, 2016 at 04:16:26PM +, Stuart Yoder wrote:
> #define IOMMU_READ(1 << 0)
> #define IOMMU_WRITE (1 << 1)
> -#define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
> +#define IOMMU_CACHE_COHERENT (1 << 2) /* cacheable and coherent */
> #define IOM
On Tue, Jun 28, 2022 at 07:59:39AM +, Shameerali Kolothum Thodi wrote:
> Now that we have all the required acks, could you please pick this series via
> IOMMU tree?
Applied to core branch, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.o
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
88 matches
Mail list logo
