Gentle reminder, for v5.13 ?
On Wed, 2021-02-10 at 09:13 -0700, Jon Derrick wrote:
> The Intel Volume Management Device acts similar to a PCI-to-PCI bridge in that
> it changes downstream devices' requester-ids to its own. As VMD supports PCIe
> devices, it has its own MSI-X table and transmits
Hi Krzysztof,
On Mon, 2021-02-08 at 14:11 +0100, Krzysztof Wilczyński wrote:
> Hi Jon,
>
> Thank you for all the work here!
>
> Just a number of suggestions, mainly nitpicks, so feel free to ignore
> these, of course.
>
> [...]
> > +#define VMCFG_MSI_RMP_DIS 0x2
> [...]
>
> What about
On Fri, 2021-02-05 at 15:57 -0600, Bjorn Helgaas wrote:
> On Thu, Feb 04, 2021 at 12:09:06PM -0700, Jon Derrick wrote:
> > VMD will retransmit child device MSI/X using its own MSI/X table and
> > requester-id. This limits the number of MSI/X available to the whole
> > child device domain to the
+Megha
On Wed, 2020-09-30 at 09:57 -0300, Jason Gunthorpe wrote:
> On Wed, Sep 30, 2020 at 12:45:30PM +0000, Derrick, Jonathan wrote:
> > Hi Jason
> >
> > On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thoma
Hi Jason
On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > From: Thomas Gleixner
> >
> > Devices on the VMD bus use their own MSI irq domain, but it is not
> > distinguishable from regular PCI/MSI irq domains. This
On Wed, 2020-08-26 at 21:42 +0100, Marc Zyngier wrote:
> On Wed, 26 Aug 2020 12:16:51 +0100,
> Thomas Gleixner wrote:
> > From: Thomas Gleixner
> >
> > PCI devices behind a VMD bus are not subject to interrupt remapping, but
> > the irq domain for VMD MSI cannot be distinguished from a regular
On Wed, 2020-05-06 at 10:09 +0800, Daniel Drake wrote:
> On Wed, May 6, 2020 at 10:03 AM Lu Baolu wrote:
> > https://lkml.org/lkml/2020/4/14/616
> > [This has been applied in iommu/next.]
> >
> > Hence, there is no need to keep the private domain implementation
> > in the Intel IOMMU driver.
Hi Daniel,
On Fri, 2020-04-17 at 09:03 +0800, Daniel Drake wrote:
> Hi Joerg,
>
> > Hi,
> >
> > here is the second version of this patch-set. The first version with
> > some more introductory text can be found here:
> >
> >
Hi Joerg,
On Tue, 2020-04-07 at 20:37 +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> When a bus is initialized with iommu-ops, all devices on the bus are
> scanned and iommu-groups are allocated for them, and each groups will
> also get a default domain allocated.
>
> Until now this
On Sun, 2020-04-12 at 11:50 +0800, Daniel Drake wrote:
> Hi Jon,
>
> Thanks for picking this up. Apologies for my absence here - I wasn't
> able to work on this recently, but I'm back again now.
>
> On Fri, Apr 10, 2020 at 3:32 AM Jon Derrick
> wrote:
> > This becomes problematic if the real
On Mon, 2020-04-13 at 10:48 +0800, Lu Baolu wrote:
> Hi Daniel,
>
> On 2020/4/13 10:25, Daniel Drake wrote:
> > On Fri, Apr 10, 2020 at 9:22 AM Lu Baolu wrote:
> > > This is caused by the fragile private domain implementation. We are in
> > > process of removing it by enhancing the iommu
Hm that didn't come through right..
On Wed, 2020-04-08 at 18:16 -0600, Jonathan Derrick wrote:
> Hi Daniel,
>
> Reviving this thread
>
> On Thu, 2020-02-20 at 18:06 +0800, Daniel Drake wrote:
> > > On Wed, Feb 19, 2020 at 11:40 AM Lu Baolu
> > > wrote:
> > > > With respect, this is
Hi Daniel,
Reviving this thread
On Thu, 2020-02-20 at 18:06 +0800, Daniel Drake wrote:
> > On Wed, Feb 19, 2020 at 11:40 AM Lu Baolu wrote:
> > > With respect, this is problematical. The parent and all subdevices share
> > > a single translation entry. The DMA mask should be consistent.
> > >
Hi Baolu, Daniel,
Sorry for the delay. Was offline for the last week.
On Thu, 2020-02-20 at 19:58 +0800, Lu Baolu wrote:
> Hi,
>
> On 2020/2/20 18:06, Daniel Drake wrote:
> > > On Wed, Feb 19, 2020 at 11:40 AM Lu Baolu
> > > wrote:
> > > > With respect, this is problematical. The parent and
Hi Daniel, sorry for the delay
On Fri, 2020-02-14 at 17:02 +0800, Daniel Drake wrote:
> From: Jon Derrick
>
> The PCI devices handled by intel-iommu may have a DMA requester on
> another bus, such as VMD subdevices needing to use the VMD endpoint.
>
> The real DMA device is now used for the
Hi Daniel
On Tue, 2020-02-11 at 17:13 +0800, Daniel Drake wrote:
> The PCI devices handled by intel-iommu may have a DMA requester on
> another bus, such as VMD subdevices needing to use the VMD endpoint.
>
> The real DMA device is now used for the DMA mapping, but one case was
> missed earlier,
Good catch. Thanks Baolu.
Will do v5 fixing this and Christoph's nit
On Tue, 2020-01-21 at 09:06 +0800, Lu Baolu wrote:
> Hi,
>
> On 1/18/20 12:27 AM, Jon Derrick wrote:
> > The PCI device may have a DMA requester on another bus, such as VMD
> > subdevices needing to use the VMD endpoint. This
On Tue, 2020-01-14 at 09:54 +0100, Christoph Hellwig wrote:
> On Fri, Jan 10, 2020 at 10:21:12AM -0700, Jon Derrick wrote:
> > Devices on the VMD domain use the VMD endpoint's requester ID and have
> > been relying on the VMD endpoint's DMA operations. The problem with this
> > was that VMD domain
Hi Lorenzo,
On Mon, 2020-01-13 at 12:08 +, Lorenzo Pieralisi wrote:
> On Fri, Jan 10, 2020 at 10:21:08AM -0700, Jon Derrick wrote:
> > v2 Set:
> > https://lore.kernel.org/linux-iommu/1578580256-3483-1-git-send-email-jonathan.derr...@intel.com/T/#t
> > v1 Set:
> >
On Thu, 2020-01-09 at 17:11 -0600, Bjorn Helgaas wrote:
> In subject:
> s/Introduce direct dma alias/Add pci_direct_dma_alias()/
>
> On Thu, Jan 09, 2020 at 07:30:54AM -0700, Jon Derrick wrote:
> > The current dma alias implementation requires the aliased device be on
> > the same bus as the dma
On Thu, 2020-01-09 at 15:33 +0100, Christoph Hellwig wrote:
> On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote:
> > To be used by intel-iommu code to find the correct domain.
>
> Any reason to prefer this version over my patches 2 and 3 from the
> series in August?
2 & 3 of your set
On Thu, 2020-01-09 at 15:36 +0100, Christoph Hellwig wrote:
> On Tue, Dec 31, 2019 at 01:24:22PM -0700, Jon Derrick wrote:
> > Devices on the VMD domain use the VMD endpoint's requester-id and have
> > been relying on the VMD endpoint's dma operations. The downside of this
> > was that VMD domain
On Thu, 2020-01-09 at 15:33 +0100, Christoph Hellwig wrote:
> On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote:
> > To be used by intel-iommu code to find the correct domain.
>
> Any reason to prefer this version over my patches 2 and 3 from the
> series in August?
Mine uses the
On Thu, 2020-01-09 at 15:37 +0100, Christoph Hellwig wrote:
> On Tue, Dec 31, 2019 at 01:24:23PM -0700, Jon Derrick wrote:
> > VMD was the only user of device dma operations. Now that the IOMMU has
> > been made aware of direct DMA aliases, VMD domain devices can reference
> > the VMD endpoint
On Wed, 2019-08-28 at 16:14 +0200, Christoph Hellwig wrote:
> Various helpers need the pci_sysdata just to dereference a single field
> in it. Add a little helper that returns the properly typed sysdata
> pointer to require a little less boilerplate code.
>
> Signed-off-by: Christoph Hellwig
>
On Mon, 2019-08-26 at 17:06 +0200, Christoph Hellwig wrote:
> With a little tweak to the intel-iommu code we should be able to work
> around the VMD mess for the requester IDs without having to create giant
> amounts of boilerplate DMA ops wrapping code. The other advantage of
> this scheme is
Looks good to me
Thanks Christoph
Acked-by: Jon Derrick
On Fri, 2018-12-14 at 15:17 -0600, Bjorn Helgaas wrote:
> Conventional spelling in subject is
>
> PCI: vmd: Use dma_* APIs instead of direct method calls
>
> On Fri, Dec 07, 2018 at 11:07:19AM -0800, Christoph Hellwig wrote:
> > With
27 matches
Mail list logo
