From: Will Deacon <will@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
Claire Chang <tientzu@chromium.org>,
Rob Herring <robh+dt@kernel.org>,
mpe@ellerman.id.au, Joerg Roedel <joro@8bytes.org>,
Frank Rowand <frowand.list@gmail.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
boris.ostrovsky@oracle.com, jgross@suse.com,
Christoph Hellwig <hch@lst.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
benh@kernel.crashing.org, paulus@samba.org,
"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Stefano Stabellini <sstabellini@kernel.org>,
grant.likely@arm.com, xypron.glpk@gmx.de,
Thierry Reding <treding@nvidia.com>,
mingo@kernel.org, bauerman@linux.ibm.com, peterz@infradead.org,
Greg KH <gregkh@linuxfoundation.org>,
Saravana Kannan <saravanak@google.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
heikki.krogerus@linux.intel.com,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Randy Dunlap <rdunlap@infradead.org>,
Dan Williams <dan.j.williams@intel.com>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
linux-devicetree <devicetree@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
linuxppc-dev@lists.ozlabs.org, xen-devel@lists.xenproject.org,
Nicolas Boichat <drinkcat@chromium.org>,
Jim Quinlan <james.quinlan@broadcom.com>,
Tomasz Figa <tfiga@chromium.org>,
bskeggs@redhat.com, Bjorn Helgaas <bhelgaas@google.com>,
chris@chris-wilson.co.uk, Daniel Vetter <daniel@ffwll.ch>,
airlied@linux.ie, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, jani.nikula@linux.intel.com,
Jianxiong Gao <jxgao@google.com>,
joonas.lahtinen@linux.intel.com, linux-pci@vger.kernel.org,
maarten.lankhorst@linux.intel.com, matthew.auld@intel.com,
rodrigo.vivi@intel.com, thomas.hellstrom@linux.intel.com,
Tom Lendacky <thomas.lendacky@amd.com>,
Qian Cai <quic_qiancai@quicinc.com>
Subject: Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Mon, 5 Jul 2021 20:03:52 +0100 [thread overview]
Message-ID: <20210705190352.GA19461@willie-the-truck> (raw)
In-Reply-To: <YN/7xcxt/XGAKceZ@Ryzen-9-3900X.localdomain>
Hi Nathan,
I may have just spotted something in these logs...
On Fri, Jul 02, 2021 at 10:55:17PM -0700, Nathan Chancellor wrote:
> [ 2.340956] pci 0000:0c:00.1: Adding to iommu group 4
> [ 2.340996] pci 0000:0c:00.2: Adding to iommu group 4
> [ 2.341038] pci 0000:0c:00.3: Adding to iommu group 4
> [ 2.341078] pci 0000:0c:00.4: Adding to iommu group 4
> [ 2.341122] pci 0000:0c:00.6: Adding to iommu group 4
> [ 2.341163] pci 0000:0d:00.0: Adding to iommu group 4
> [ 2.341203] pci 0000:0d:00.1: Adding to iommu group 4
> [ 2.361821] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40
> [ 2.361839] pci 0000:00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
> [ 2.361846] PPR X2APIC NX GT IA GA PC GA_vAPIC
> [ 2.361861] AMD-Vi: Interrupt remapping enabled
> [ 2.361865] AMD-Vi: Virtual APIC enabled
> [ 2.361870] AMD-Vi: X2APIC enabled
> [ 2.362272] AMD-Vi: Lazy IO/TLB flushing enabled
So at this point, the AMD IOMMU driver does:
swiotlb = (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
where 'swiotlb' is a global variable indicating whether or not swiotlb
is in use. It's picked up a bit later on by pci_swiotlb_late_init(), which
will call swiotlb_exit() if 'swiotlb' is false.
Now, that used to work fine, because swiotlb_exit() clears
'io_tlb_default_mem' to NULL, but now with the restricted DMA changes, I
think that all the devices which have successfully probed beforehand will
have stale pointers to the freed structure in their 'dev->dma_io_tlb_mem'
field.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: heikki.krogerus@linux.intel.com,
thomas.hellstrom@linux.intel.com, peterz@infradead.org,
joonas.lahtinen@linux.intel.com, dri-devel@lists.freedesktop.org,
chris@chris-wilson.co.uk, grant.likely@arm.com, paulus@samba.org,
Frank Rowand <frowand.list@gmail.com>,
mingo@kernel.org, Marek Szyprowski <m.szyprowski@samsung.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Saravana Kannan <saravanak@google.com>,
xypron.glpk@gmx.de, Joerg Roedel <joro@8bytes.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Christoph Hellwig <hch@lst.de>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
bskeggs@redhat.com, linux-pci@vger.kernel.org,
xen-devel@lists.xenproject.org,
Thierry Reding <treding@nvidia.com>,
intel-gfx@lists.freedesktop.org, matthew.auld@intel.com,
linux-devicetree <devicetree@vger.kernel.org>,
Jianxiong Gao <jxgao@google.com>, Daniel Vetter <daniel@ffwll.ch>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
maarten.lankhorst@linux.intel.com, airlied@linux.ie,
Dan Williams <dan.j.williams@intel.com>,
linuxppc-dev@lists.ozlabs.org, jani.nikula@linux.intel.com,
Rob Herring <robh+dt@kernel.org>,
rodrigo.vivi@intel.com, Bjorn Helgaas <bhelgaas@google.com>,
Claire Chang <tientzu@chromium.org>,
boris.ostrovsky@oracle.com,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
jgross@suse.com, Nicolas Boichat <drinkcat@chromium.org>,
Greg KH <gregkh@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Qian Cai <quic_qiancai@quicinc.com>,
lkml <linux-kernel@vger.kernel.org>,
Tomasz Figa <tfiga@chromium.org>,
"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Jim Quinlan <james.quinlan@broadcom.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Robin Murphy <robin.murphy@arm.com>,
bauerman@linux.ibm.com
Subject: Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Mon, 5 Jul 2021 20:03:52 +0100 [thread overview]
Message-ID: <20210705190352.GA19461@willie-the-truck> (raw)
In-Reply-To: <YN/7xcxt/XGAKceZ@Ryzen-9-3900X.localdomain>
Hi Nathan,
I may have just spotted something in these logs...
On Fri, Jul 02, 2021 at 10:55:17PM -0700, Nathan Chancellor wrote:
> [ 2.340956] pci 0000:0c:00.1: Adding to iommu group 4
> [ 2.340996] pci 0000:0c:00.2: Adding to iommu group 4
> [ 2.341038] pci 0000:0c:00.3: Adding to iommu group 4
> [ 2.341078] pci 0000:0c:00.4: Adding to iommu group 4
> [ 2.341122] pci 0000:0c:00.6: Adding to iommu group 4
> [ 2.341163] pci 0000:0d:00.0: Adding to iommu group 4
> [ 2.341203] pci 0000:0d:00.1: Adding to iommu group 4
> [ 2.361821] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40
> [ 2.361839] pci 0000:00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
> [ 2.361846] PPR X2APIC NX GT IA GA PC GA_vAPIC
> [ 2.361861] AMD-Vi: Interrupt remapping enabled
> [ 2.361865] AMD-Vi: Virtual APIC enabled
> [ 2.361870] AMD-Vi: X2APIC enabled
> [ 2.362272] AMD-Vi: Lazy IO/TLB flushing enabled
So at this point, the AMD IOMMU driver does:
swiotlb = (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
where 'swiotlb' is a global variable indicating whether or not swiotlb
is in use. It's picked up a bit later on by pci_swiotlb_late_init(), which
will call swiotlb_exit() if 'swiotlb' is false.
Now, that used to work fine, because swiotlb_exit() clears
'io_tlb_default_mem' to NULL, but now with the restricted DMA changes, I
think that all the devices which have successfully probed beforehand will
have stale pointers to the freed structure in their 'dev->dma_io_tlb_mem'
field.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: heikki.krogerus@linux.intel.com,
thomas.hellstrom@linux.intel.com, peterz@infradead.org,
benh@kernel.crashing.org, joonas.lahtinen@linux.intel.com,
dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
grant.likely@arm.com, paulus@samba.org,
Frank Rowand <frowand.list@gmail.com>,
mingo@kernel.org, Stefano Stabellini <sstabellini@kernel.org>,
Saravana Kannan <saravanak@google.com>,
xypron.glpk@gmx.de,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Christoph Hellwig <hch@lst.de>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
bskeggs@redhat.com, linux-pci@vger.kernel.org,
xen-devel@lists.xenproject.org,
Thierry Reding <treding@nvidia.com>,
intel-gfx@lists.freedesktop.org, matthew.auld@intel.com,
linux-devicetree <devicetree@vger.kernel.org>,
Jianxiong Gao <jxgao@google.com>, Daniel Vetter <daniel@ffwll.ch>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
maarten.lankhorst@linux.intel.com, airlied@linux.ie,
Dan Williams <dan.j.williams@intel.com>,
linuxppc-dev@lists.ozlabs.org, jani.nikula@linux.intel.com,
Rob Herring <robh+dt@kernel.org>,
rodrigo.vivi@intel.com, Bjorn Helgaas <bhelgaas@google.com>,
Claire Chang <tientzu@chromium.org>,
boris.ostrovsky@oracle.com,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
jgross@suse.com, Nicolas Boichat <drinkcat@chromium.org>,
Greg KH <gregkh@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Qian Cai <quic_qiancai@quicinc.com>,
lkml <linux-kernel@vger.kernel.org>,
"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Jim Quinlan <james.quinlan@broadcom.com>,
mpe@ellerman.id.au, Tom Lendacky <thomas.lendacky@amd.com>,
Robin Murphy <robin.murphy@arm.com>,
bauerman@linux.ibm.com
Subject: Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Mon, 5 Jul 2021 20:03:52 +0100 [thread overview]
Message-ID: <20210705190352.GA19461@willie-the-truck> (raw)
In-Reply-To: <YN/7xcxt/XGAKceZ@Ryzen-9-3900X.localdomain>
Hi Nathan,
I may have just spotted something in these logs...
On Fri, Jul 02, 2021 at 10:55:17PM -0700, Nathan Chancellor wrote:
> [ 2.340956] pci 0000:0c:00.1: Adding to iommu group 4
> [ 2.340996] pci 0000:0c:00.2: Adding to iommu group 4
> [ 2.341038] pci 0000:0c:00.3: Adding to iommu group 4
> [ 2.341078] pci 0000:0c:00.4: Adding to iommu group 4
> [ 2.341122] pci 0000:0c:00.6: Adding to iommu group 4
> [ 2.341163] pci 0000:0d:00.0: Adding to iommu group 4
> [ 2.341203] pci 0000:0d:00.1: Adding to iommu group 4
> [ 2.361821] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40
> [ 2.361839] pci 0000:00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
> [ 2.361846] PPR X2APIC NX GT IA GA PC GA_vAPIC
> [ 2.361861] AMD-Vi: Interrupt remapping enabled
> [ 2.361865] AMD-Vi: Virtual APIC enabled
> [ 2.361870] AMD-Vi: X2APIC enabled
> [ 2.362272] AMD-Vi: Lazy IO/TLB flushing enabled
So at this point, the AMD IOMMU driver does:
swiotlb = (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
where 'swiotlb' is a global variable indicating whether or not swiotlb
is in use. It's picked up a bit later on by pci_swiotlb_late_init(), which
will call swiotlb_exit() if 'swiotlb' is false.
Now, that used to work fine, because swiotlb_exit() clears
'io_tlb_default_mem' to NULL, but now with the restricted DMA changes, I
think that all the devices which have successfully probed beforehand will
have stale pointers to the freed structure in their 'dev->dma_io_tlb_mem'
field.
Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: heikki.krogerus@linux.intel.com,
thomas.hellstrom@linux.intel.com, peterz@infradead.org,
dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
grant.likely@arm.com, paulus@samba.org,
Frank Rowand <frowand.list@gmail.com>,
mingo@kernel.org, Marek Szyprowski <m.szyprowski@samsung.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Saravana Kannan <saravanak@google.com>,
xypron.glpk@gmx.de, Joerg Roedel <joro@8bytes.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Christoph Hellwig <hch@lst.de>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
bskeggs@redhat.com, linux-pci@vger.kernel.org,
xen-devel@lists.xenproject.org,
Thierry Reding <treding@nvidia.com>,
intel-gfx@lists.freedesktop.org, matthew.auld@intel.com,
linux-devicetree <devicetree@vger.kernel.org>,
Jianxiong Gao <jxgao@google.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
airlied@linux.ie, Dan Williams <dan.j.williams@intel.com>,
linuxppc-dev@lists.ozlabs.org, Rob Herring <robh+dt@kernel.org>,
rodrigo.vivi@intel.com, Bjorn Helgaas <bhelgaas@google.com>,
Claire Chang <tientzu@chromium.org>,
boris.ostrovsky@oracle.com,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
jgross@suse.com, Nicolas Boichat <drinkcat@chromium.org>,
Greg KH <gregkh@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Qian Cai <quic_qiancai@quicinc.com>,
lkml <linux-kernel@vger.kernel.org>,
Tomasz Figa <tfiga@chromium.org>,
"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Jim Quinlan <james.quinlan@broadcom.com>,
mpe@ellerman.id.au, Tom Lendacky <thomas.lendacky@amd.com>,
Robin Murphy <robin.murphy@arm.com>,
bauerman@linux.ibm.com
Subject: Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Mon, 5 Jul 2021 20:03:52 +0100 [thread overview]
Message-ID: <20210705190352.GA19461@willie-the-truck> (raw)
In-Reply-To: <YN/7xcxt/XGAKceZ@Ryzen-9-3900X.localdomain>
Hi Nathan,
I may have just spotted something in these logs...
On Fri, Jul 02, 2021 at 10:55:17PM -0700, Nathan Chancellor wrote:
> [ 2.340956] pci 0000:0c:00.1: Adding to iommu group 4
> [ 2.340996] pci 0000:0c:00.2: Adding to iommu group 4
> [ 2.341038] pci 0000:0c:00.3: Adding to iommu group 4
> [ 2.341078] pci 0000:0c:00.4: Adding to iommu group 4
> [ 2.341122] pci 0000:0c:00.6: Adding to iommu group 4
> [ 2.341163] pci 0000:0d:00.0: Adding to iommu group 4
> [ 2.341203] pci 0000:0d:00.1: Adding to iommu group 4
> [ 2.361821] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40
> [ 2.361839] pci 0000:00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
> [ 2.361846] PPR X2APIC NX GT IA GA PC GA_vAPIC
> [ 2.361861] AMD-Vi: Interrupt remapping enabled
> [ 2.361865] AMD-Vi: Virtual APIC enabled
> [ 2.361870] AMD-Vi: X2APIC enabled
> [ 2.362272] AMD-Vi: Lazy IO/TLB flushing enabled
So at this point, the AMD IOMMU driver does:
swiotlb = (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
where 'swiotlb' is a global variable indicating whether or not swiotlb
is in use. It's picked up a bit later on by pci_swiotlb_late_init(), which
will call swiotlb_exit() if 'swiotlb' is false.
Now, that used to work fine, because swiotlb_exit() clears
'io_tlb_default_mem' to NULL, but now with the restricted DMA changes, I
think that all the devices which have successfully probed beforehand will
have stale pointers to the freed structure in their 'dev->dma_io_tlb_mem'
field.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: heikki.krogerus@linux.intel.com,
thomas.hellstrom@linux.intel.com, peterz@infradead.org,
benh@kernel.crashing.org, dri-devel@lists.freedesktop.org,
chris@chris-wilson.co.uk, grant.likely@arm.com, paulus@samba.org,
Frank Rowand <frowand.list@gmail.com>,
mingo@kernel.org, Marek Szyprowski <m.szyprowski@samsung.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Saravana Kannan <saravanak@google.com>,
xypron.glpk@gmx.de, Joerg Roedel <joro@8bytes.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Christoph Hellwig <hch@lst.de>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
bskeggs@redhat.com, linux-pci@vger.kernel.org,
xen-devel@lists.xenproject.org,
Thierry Reding <treding@nvidia.com>,
intel-gfx@lists.freedesktop.org, matthew.auld@intel.com,
linux-devicetree <devicetree@vger.kernel.org>,
Jianxiong Gao <jxgao@google.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
airlied@linux.ie, Dan Williams <dan.j.williams@intel.com>,
linuxppc-dev@lists.ozlabs.org, Rob Herring <robh+dt@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Claire Chang <tientzu@chromium.org>,
boris.ostrovsky@oracle.com,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
jgross@suse.com, Nicolas Boichat <drinkcat@chromium.org>,
Greg KH <gregkh@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Qian Cai <quic_qiancai@quicinc.com>,
lkml <linux-kernel@vger.kernel.org>,
Tomasz Figa <tfiga@chromium.org>,
"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Jim Quinlan <james.quinlan@broadcom.com>,
mpe@ellerman.id.au, Tom Lendacky <thomas.lendacky@amd.com>,
Robin Murphy <robin.murphy@arm.com>,
bauerman@linux.ibm.com
Subject: Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Mon, 5 Jul 2021 20:03:52 +0100 [thread overview]
Message-ID: <20210705190352.GA19461@willie-the-truck> (raw)
In-Reply-To: <YN/7xcxt/XGAKceZ@Ryzen-9-3900X.localdomain>
Hi Nathan,
I may have just spotted something in these logs...
On Fri, Jul 02, 2021 at 10:55:17PM -0700, Nathan Chancellor wrote:
> [ 2.340956] pci 0000:0c:00.1: Adding to iommu group 4
> [ 2.340996] pci 0000:0c:00.2: Adding to iommu group 4
> [ 2.341038] pci 0000:0c:00.3: Adding to iommu group 4
> [ 2.341078] pci 0000:0c:00.4: Adding to iommu group 4
> [ 2.341122] pci 0000:0c:00.6: Adding to iommu group 4
> [ 2.341163] pci 0000:0d:00.0: Adding to iommu group 4
> [ 2.341203] pci 0000:0d:00.1: Adding to iommu group 4
> [ 2.361821] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40
> [ 2.361839] pci 0000:00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
> [ 2.361846] PPR X2APIC NX GT IA GA PC GA_vAPIC
> [ 2.361861] AMD-Vi: Interrupt remapping enabled
> [ 2.361865] AMD-Vi: Virtual APIC enabled
> [ 2.361870] AMD-Vi: X2APIC enabled
> [ 2.362272] AMD-Vi: Lazy IO/TLB flushing enabled
So at this point, the AMD IOMMU driver does:
swiotlb = (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
where 'swiotlb' is a global variable indicating whether or not swiotlb
is in use. It's picked up a bit later on by pci_swiotlb_late_init(), which
will call swiotlb_exit() if 'swiotlb' is false.
Now, that used to work fine, because swiotlb_exit() clears
'io_tlb_default_mem' to NULL, but now with the restricted DMA changes, I
think that all the devices which have successfully probed beforehand will
have stale pointers to the freed structure in their 'dev->dma_io_tlb_mem'
field.
Will
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-07-05 19:04 UTC|newest]
Thread overview: 245+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-24 15:55 [PATCH v15 00/12] Restricted DMA Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 01/12] swiotlb: Refactor swiotlb init functions Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 02/12] swiotlb: Refactor swiotlb_create_debugfs Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 03/12] swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 04/12] swiotlb: Update is_swiotlb_buffer to add a struct device argument Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 05/12] swiotlb: Update is_swiotlb_active " Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-30 1:43 ` Nathan Chancellor
2021-06-30 1:43 ` [Intel-gfx] " Nathan Chancellor
2021-06-30 1:43 ` Nathan Chancellor
2021-06-30 1:43 ` Nathan Chancellor
2021-06-30 1:43 ` Nathan Chancellor
2021-06-30 9:17 ` Claire Chang
2021-06-30 9:17 ` Claire Chang
2021-06-30 9:17 ` [Intel-gfx] " Claire Chang
2021-06-30 9:17 ` Claire Chang
2021-06-30 9:17 ` Claire Chang
2021-06-30 9:17 ` Claire Chang
2021-06-30 11:43 ` Will Deacon
2021-06-30 11:43 ` [Intel-gfx] " Will Deacon
2021-06-30 11:43 ` Will Deacon
2021-06-30 11:43 ` Will Deacon
2021-06-30 11:43 ` Will Deacon
2021-06-30 15:56 ` Nathan Chancellor
2021-06-30 15:56 ` [Intel-gfx] " Nathan Chancellor
2021-06-30 15:56 ` Nathan Chancellor
2021-06-30 15:56 ` Nathan Chancellor
2021-06-30 15:56 ` Nathan Chancellor
2021-07-01 7:40 ` Will Deacon
2021-07-01 7:40 ` [Intel-gfx] " Will Deacon
2021-07-01 7:40 ` Will Deacon
2021-07-01 7:40 ` Will Deacon
2021-07-01 7:40 ` Will Deacon
2021-07-01 7:52 ` Nathan Chancellor
2021-07-01 7:52 ` [Intel-gfx] " Nathan Chancellor
2021-07-01 7:52 ` Nathan Chancellor
2021-07-01 7:52 ` Nathan Chancellor
2021-07-01 7:52 ` Nathan Chancellor
2021-07-02 13:58 ` Will Deacon
2021-07-02 13:58 ` [Intel-gfx] " Will Deacon
2021-07-02 13:58 ` Will Deacon
2021-07-02 13:58 ` Will Deacon
2021-07-02 13:58 ` Will Deacon
2021-07-02 15:13 ` Robin Murphy
2021-07-02 15:13 ` [Intel-gfx] " Robin Murphy
2021-07-02 15:13 ` Robin Murphy
2021-07-02 15:13 ` Robin Murphy
2021-07-02 15:13 ` Robin Murphy
2021-07-03 5:55 ` Nathan Chancellor
2021-07-03 5:55 ` [Intel-gfx] " Nathan Chancellor
2021-07-03 5:55 ` Nathan Chancellor
2021-07-03 5:55 ` Nathan Chancellor
2021-07-03 5:55 ` Nathan Chancellor
2021-07-05 7:29 ` Claire Chang
2021-07-05 7:29 ` Claire Chang
2021-07-05 7:29 ` [Intel-gfx] " Claire Chang
2021-07-05 7:29 ` Claire Chang
2021-07-05 7:29 ` Claire Chang
2021-07-05 7:29 ` Claire Chang
2021-07-05 18:25 ` Nathan Chancellor
2021-07-05 18:25 ` [Intel-gfx] " Nathan Chancellor
2021-07-05 18:25 ` Nathan Chancellor
2021-07-05 18:25 ` Nathan Chancellor
2021-07-05 18:25 ` Nathan Chancellor
2021-07-05 19:03 ` Will Deacon [this message]
2021-07-05 19:03 ` [Intel-gfx] " Will Deacon
2021-07-05 19:03 ` Will Deacon
2021-07-05 19:03 ` Will Deacon
2021-07-05 19:03 ` Will Deacon
2021-07-06 4:48 ` Christoph Hellwig
2021-07-06 4:48 ` [Intel-gfx] " Christoph Hellwig
2021-07-06 4:48 ` Christoph Hellwig
2021-07-06 4:48 ` Christoph Hellwig
2021-07-06 13:24 ` Will Deacon
2021-07-06 13:24 ` [Intel-gfx] " Will Deacon
2021-07-06 13:24 ` Will Deacon
2021-07-06 13:24 ` Will Deacon
2021-07-06 13:24 ` Will Deacon
2021-07-06 14:01 ` Robin Murphy
2021-07-06 14:01 ` [Intel-gfx] " Robin Murphy
2021-07-06 14:01 ` Robin Murphy
2021-07-06 14:01 ` Robin Murphy
2021-07-06 14:01 ` Robin Murphy
2021-07-06 14:05 ` Christoph Hellwig
2021-07-06 14:05 ` [Intel-gfx] " Christoph Hellwig
2021-07-06 14:05 ` Christoph Hellwig
2021-07-06 14:05 ` Christoph Hellwig
2021-07-06 14:46 ` Konrad Rzeszutek Wilk
2021-07-06 14:46 ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-07-06 14:46 ` Konrad Rzeszutek Wilk
2021-07-06 14:46 ` Konrad Rzeszutek Wilk
2021-07-06 14:46 ` Konrad Rzeszutek Wilk
2021-07-06 16:57 ` Will Deacon
2021-07-06 16:57 ` [Intel-gfx] " Will Deacon
2021-07-06 16:57 ` Will Deacon
2021-07-06 16:57 ` Will Deacon
2021-07-06 16:57 ` Will Deacon
2021-07-06 16:59 ` Konrad Rzeszutek Wilk
2021-07-06 16:59 ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-07-06 16:59 ` Konrad Rzeszutek Wilk
2021-07-06 16:59 ` Konrad Rzeszutek Wilk
2021-07-06 16:59 ` Konrad Rzeszutek Wilk
2021-07-12 13:56 ` Will Deacon
2021-07-12 13:56 ` [Intel-gfx] " Will Deacon
2021-07-12 13:56 ` Will Deacon
2021-07-12 13:56 ` Will Deacon
2021-07-12 13:56 ` Will Deacon
2021-07-14 0:06 ` Konrad Rzeszutek Wilk
2021-07-14 0:06 ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-07-14 0:06 ` Konrad Rzeszutek Wilk
2021-07-14 0:06 ` Konrad Rzeszutek Wilk
2021-07-14 0:06 ` Konrad Rzeszutek Wilk
2021-07-06 15:39 ` Robin Murphy
2021-07-06 15:39 ` [Intel-gfx] " Robin Murphy
2021-07-06 15:39 ` Robin Murphy
2021-07-06 15:39 ` Robin Murphy
2021-07-06 15:39 ` Robin Murphy
2021-07-06 17:06 ` Will Deacon
2021-07-06 17:06 ` [Intel-gfx] " Will Deacon
2021-07-06 17:06 ` Will Deacon
2021-07-06 17:06 ` Will Deacon
2021-07-06 17:06 ` Will Deacon
2021-07-06 19:14 ` Nathan Chancellor
2021-07-06 19:14 ` [Intel-gfx] " Nathan Chancellor
2021-07-06 19:14 ` Nathan Chancellor
2021-07-06 19:14 ` Nathan Chancellor
2021-07-06 19:14 ` Nathan Chancellor
2021-07-08 16:44 ` Will Deacon
2021-07-08 16:44 ` [Intel-gfx] " Will Deacon
2021-07-08 16:44 ` Will Deacon
2021-07-08 16:44 ` Will Deacon
2021-07-08 16:44 ` Will Deacon
2021-06-24 15:55 ` [PATCH v15 07/12] swiotlb: Move alloc_size to swiotlb_find_slots Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 08/12] swiotlb: Refactor swiotlb_tbl_unmap_single Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 09/12] swiotlb: Add restricted DMA alloc/free support Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 10/12] swiotlb: Add restricted DMA pool initialization Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-08-24 14:26 ` Guenter Roeck
2021-08-24 14:26 ` Guenter Roeck
2021-08-24 14:26 ` [Intel-gfx] " Guenter Roeck
2021-08-24 14:26 ` Guenter Roeck
2021-08-27 3:50 ` Claire Chang
2021-08-27 3:50 ` Claire Chang
2021-08-27 3:50 ` [Intel-gfx] " Claire Chang
2021-08-27 3:50 ` Claire Chang
2021-08-27 3:50 ` Claire Chang
2021-08-27 3:50 ` Claire Chang
2021-08-27 6:58 ` Andy Shevchenko
2021-08-27 6:58 ` Andy Shevchenko
2021-08-27 6:58 ` [Intel-gfx] " Andy Shevchenko
2021-08-27 6:58 ` Andy Shevchenko
2021-08-27 6:58 ` Andy Shevchenko
2021-06-24 15:55 ` [PATCH v15 11/12] dt-bindings: of: Add restricted DMA pool Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` [PATCH v15 12/12] of: Add plumbing for " Claire Chang
2021-06-24 15:55 ` [Intel-gfx] " Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-06-24 15:55 ` Claire Chang
2021-07-02 3:08 ` Guenter Roeck
2021-07-02 3:08 ` [Intel-gfx] " Guenter Roeck
2021-07-02 3:08 ` Guenter Roeck
2021-07-02 3:08 ` Guenter Roeck
2021-07-02 3:08 ` Guenter Roeck
2021-07-02 11:39 ` Robin Murphy
2021-07-02 11:39 ` [Intel-gfx] " Robin Murphy
2021-07-02 11:39 ` Robin Murphy
2021-07-02 11:39 ` Robin Murphy
2021-07-02 11:39 ` Robin Murphy
2021-07-02 13:18 ` Will Deacon
2021-07-02 13:18 ` [Intel-gfx] " Will Deacon
2021-07-02 13:18 ` Will Deacon
2021-07-02 13:18 ` Will Deacon
2021-07-02 13:18 ` Will Deacon
2021-07-02 13:48 ` Guenter Roeck
2021-07-02 13:48 ` [Intel-gfx] " Guenter Roeck
2021-07-02 13:48 ` Guenter Roeck
2021-07-02 13:48 ` Guenter Roeck
2021-07-02 13:48 ` Guenter Roeck
2021-06-24 16:42 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA Patchwork
2021-06-24 19:19 ` [PATCH v15 00/12] " Konrad Rzeszutek Wilk
2021-06-24 19:19 ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-06-24 19:19 ` Konrad Rzeszutek Wilk
2021-06-24 19:19 ` Konrad Rzeszutek Wilk
2021-06-24 19:19 ` Konrad Rzeszutek Wilk
2021-06-25 0:41 ` Claire Chang
2021-06-25 0:41 ` Claire Chang
2021-06-25 0:41 ` [Intel-gfx] " Claire Chang
2021-06-25 0:41 ` Claire Chang
2021-06-25 0:41 ` Claire Chang
2021-06-25 0:41 ` Claire Chang
2021-06-25 12:30 ` Will Deacon
2021-06-25 12:30 ` [Intel-gfx] " Will Deacon
2021-06-25 12:30 ` Will Deacon
2021-06-25 12:30 ` Will Deacon
2021-06-25 12:30 ` Will Deacon
2021-07-02 15:48 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA (rev2) Patchwork
2021-07-05 7:57 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA (rev3) Patchwork
2021-07-06 18:57 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA (rev5) Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210705190352.GA19461@willie-the-truck \
--to=will@kernel.org \
--cc=airlied@linux.ie \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bauerman@linux.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=bgolaszewski@baylibre.com \
--cc=bhelgaas@google.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bskeggs@redhat.com \
--cc=chris@chris-wilson.co.uk \
--cc=dan.j.williams@intel.com \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=drinkcat@chromium.org \
--cc=frowand.list@gmail.com \
--cc=grant.likely@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=heikki.krogerus@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=iommu@lists.linux-foundation.org \
--cc=james.quinlan@broadcom.com \
--cc=jani.nikula@linux.intel.com \
--cc=jgross@suse.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=joro@8bytes.org \
--cc=jxgao@google.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=m.szyprowski@samsung.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=nathan@kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=quic_qiancai@quicinc.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rodrigo.vivi@intel.com \
--cc=saravanak@google.com \
--cc=sstabellini@kernel.org \
--cc=tfiga@chromium.org \
--cc=thomas.hellstrom@linux.intel.com \
--cc=thomas.lendacky@amd.com \
--cc=tientzu@chromium.org \
--cc=treding@nvidia.com \
--cc=xen-devel@lists.xenproject.org \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.