On Thu, May 30, 2019 at 11:48:26AM +0800, Zhen Lei wrote:
> This patch removes the ifdefs around CONFIG_IOMMU_DEFAULT_PASSTHROUGH to
> improve readablity.
Avoid having "This patch" or "This commit" in the commit message. It is
tautologically useless.
Also, do
$ git grep 'This patch'
Hi,
On 6/12/19 9:05 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 12, 2019 at 08:43:40AM +0800, Lu Baolu wrote:
Hi Konrad,
Thanks a lot for your reviewing.
On 6/10/19 11:45 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Jun 03, 2019 at 09:16:14AM +0800, Lu Baolu wrote:
This is necessary to avoid
Hi,
On 6/11/19 12:10 AM, Konrad Rzeszutek Wilk wrote:
On Mon, Jun 03, 2019 at 09:16:11AM +0800, Lu Baolu wrote:
The Thunderbolt vulnerabilities are public and have a nice
name as Thunderclap [1] [3] nowadays. This patch series aims
to mitigate those concerns.
.. Forgot to ask but should the
Hi,
On 6/10/19 11:42 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Jun 03, 2019 at 09:16:11AM +0800, Lu Baolu wrote:
The Thunderbolt vulnerabilities are public and have a nice
name as Thunderclap [1] [3] nowadays. This patch series aims
to mitigate those concerns.
An external PCI device is a PCI
Hi,
On 6/11/19 12:08 AM, Konrad Rzeszutek Wilk wrote:
On Mon, Jun 03, 2019 at 09:16:18AM +0800, Lu Baolu wrote:
This adds trace support for the Intel IOMMU driver. It
also declares some events which could be used to trace
the events when an IOVA is being mapped or unmapped in
a domain.
Is
Hi,
On 6/11/19 12:08 AM, Konrad Rzeszutek Wilk wrote:
On Mon, Jun 03, 2019 at 09:16:17AM +0800, Lu Baolu wrote:
This adds a helper to check whether a device needs to use bounce
buffer. It also provides a boot time option to disable the bounce
buffer. Users can use this to prevent the iommu
Hi,
On 6/10/19 11:54 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Jun 03, 2019 at 09:16:16AM +0800, Lu Baolu wrote:
The direct dma implementation depends on swiotlb. Hence, don't
switch of swiotlb since direct dma interfaces are used in this
s/of/off/
Yes.
driver.
But I think you really
On Wed, Jun 12, 2019 at 08:43:40AM +0800, Lu Baolu wrote:
> Hi Konrad,
>
> Thanks a lot for your reviewing.
>
> On 6/10/19 11:45 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jun 03, 2019 at 09:16:14AM +0800, Lu Baolu wrote:
> > > This is necessary to avoid exposing valid kernel data to any
> > >
Hi Pavel,
Thanks a lot for your reviewing.
On 6/11/19 8:10 PM, Pavel Begunkov wrote:
On 03/06/2019 04:16, Lu Baolu wrote:
IOMMU hardware always use paging for DMA remapping. The
minimum mapped window is a page size. The device drivers
may map buffers not filling whole IOMMU window. It
Hi,
On 6/10/19 11:56 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Jun 03, 2019 at 09:16:15AM +0800, Lu Baolu wrote:
IOMMU hardware always use paging for DMA remapping. The
minimum mapped window is a page size. The device drivers
may map buffers not filling whole IOMMU window. It allows
device to
Hi Konrad,
Thanks a lot for your reviewing.
On 6/10/19 11:45 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Jun 03, 2019 at 09:16:14AM +0800, Lu Baolu wrote:
This is necessary to avoid exposing valid kernel data to any
milicious device.
malicious
Yes, thanks.
Suggested-by: Christoph
The drhd and device scope list should be iterated with the
iommu global lock held. Otherwise, a suspicious RCU usage
message will be displayed.
[3.695886] =
[3.695917] WARNING: suspicious RCU usage
[3.695950] 5.2.0-rc2+ #2467 Not tainted
[3.695981]
The iommu driver will ignore some iommu units if there's no
device under its scope or those devices have been explicitly
set to bypass the DMA translation. Don't enable those iommu
units, otherwise the devices under its scope won't work.
Fixes: d8190dc638866 ("iommu/vt-d: Enable DMA remapping
From: Sai Praneeth Prakhya
[No functional changes]
1. Starting with commit df4f3c603aeb ("iommu/vt-d: Remove static identity
map code") there are no callers for iommu_prepare_rmrr_dev() but the
implementation of the function still exists, so remove it. Also, as a
ripple effect remove
The domain_init() and md_domain_init() do almost the same job.
Consolidate them to avoid duplication.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 123 +++-
1 file changed, 36 insertions(+), 87 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
We don't allow a device to be assigned to user level when it is locked
by any RMRR's. Hence, intel_iommu_attach_device() will return error if
a domain of type IOMMU_DOMAIN_UNMANAGED is about to attach to a device
locked by rmrr. But this doesn't apply to a domain of type other than
Otherwise, domain_get_iommu() will be broken.
Fixes: 942067f1b6b97 ("iommu/vt-d: Identify default domains replaced with
private")
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c
Hi Joerg,
This series includes several fixes and cleanups after delegating
DMA domain to generic iommu. Please review and consider them for
linux-next.
Best regards,
Baolu
Change log:
v1->v2:
- Refine "iommu/vt-d: Cleanup after delegating DMA domain to
generic iommu" by removing an
If a device gets a right domain in add_device ops, it shouldn't
return error.
Fixes: 942067f1b6b97 ("iommu/vt-d: Identify default domains replaced with
private")
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 6 --
1 file changed, 6 deletions(-)
diff --git
Hi,
This is supposed to be fixed by this patch
https://lkml.org/lkml/2019/6/3/115
which is part of several RMRR related fixes and enhancements.
Best regards,
Baolu
On 6/12/19 12:55 AM, Qian Cai wrote:
On Sun, 2019-06-09 at 10:37 +0800, Lu Baolu wrote:
Hi Joerg,
This series includes
Hi,
On 6/11/19 10:00 PM, Qian Cai wrote:
On Jun 10, 2019, at 9:41 PM, Lu Baolu wrote:
Ah, good catch!
The device failed to be attached by a DMA domain. Can you please try the
attached fix patch?
It works fine.
Thanks a lot for the report and verification.
Best regards,
Baolu
On Thu, 23 May 2019, Ricardo Neri wrote:
> @@ -52,10 +59,10 @@ static void kick_timer(struct hpet_hld_data *hdata, bool
> force)
> return;
>
> if (hdata->has_periodic)
> - period = watchdog_thresh * hdata->ticks_per_second;
> + period =
On Thu, 23 May 2019, Ricardo Neri wrote:
> HPET timer 2 will be used to drive the HPET-based hardlockup detector.
> Reserve such timer to ensure it cannot be used by user space programs or
> for clock events.
>
> When looking for MSI-capable timers for clock events, skip timer 2 if
> the HPET
On Tue, Jun 11, 2019 at 10:58:23AM -0700, Florian Fainelli wrote:
> Hi Christoph,
I pulled the patches in my tree.
>
> Still with my contrived memory layout where there is no physical memory
> the kernel can use below 4GB, it was possible to fail swiotlb_init(),
> but still not hit
On Tue, 11 Jun 2019 15:35:22 +0100
Jean-Philippe Brucker wrote:
> On 11/06/2019 10:36, Jonathan Cameron wrote:
> >> +/**
> >> + * ioasid_alloc - Allocate an IOASID
> >> + * @set: the IOASID set
> >> + * @min: the minimum ID (inclusive)
> >> + * @max: the maximum ID (inclusive)
> >> + * @private:
Avoid repeating the zeroing of global swiotlb variables in two locations
and introduce swiotlb_cleanup() to do that.
Signed-off-by: Florian Fainelli
---
kernel/dma/swiotlb.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/swiotlb.c
With a specifically contrived memory layout where there is no physical
memory available to the kernel below the 4GB boundary, we will fail to
perform the initial swiotlb_init() call and set no_iotlb_memory to true.
There are drivers out there that call into swiotlb_nr_tbl() to determine
whether
Hi Christoph,
Still with my contrived memory layout where there is no physical memory
the kernel can use below 4GB, it was possible to fail swiotlb_init(),
but still not hit swiotlb_map_single() since all peripherals have a
DMA_BIT_MASK() that is within the remaining addressable physical memory.
> > > > Sure! Makes sense.. per-group default domain type sounds good.
> >
> > I am planning to implement an RFC (supporting only runtime case for
> > now) which works as below
> >
> > 1. User unbinds the driver by writing to sysfs 2. User puts a group in
> > pass through mode by writing "1" to
>
On Tue, 11 Jun 2019 15:37:42 +0100
Jean-Philippe Brucker wrote:
> On 11/06/2019 13:26, Jacob Pan wrote:
> >> +/**
> >> + * ioasid_set_data - Set private data for an allocated ioasid
> >> + * @ioasid: the ID to set data
> >> + * @data: the private data
> >> + *
> >> + * For IOASID that is
On Sun, 2019-06-09 at 10:37 +0800, Lu Baolu wrote:
> Hi Joerg,
>
> This series includes several fixes and cleanups after delegating
> DMA domain to generic iommu. Please review and consider them for
> linux-next.
>
> Best regards,
> Baolu
>
> Lu Baolu (5):
> iommu/vt-d: Don't return error
On 6/10/19 10:26 PM, Christoph Hellwig wrote:
> Looks good to me. When did this start to show up? Do we need
> to push it to Linus this cycle and cc stable?
You need a really contrived memory map layout to reach that situation,
so I don't think it warrants a stable backport.
For ARM64, this
[ Trimming recipients list ]
On 11/06/2019 17:55, Lorenzo Pieralisi wrote:
> On Thu, Mar 28, 2019 at 05:59:48PM +0100, Marc Gonzalez wrote:
>
>> After a lot of poking, I am finally able to use the AR8151 ethernet on the
>> APQ8098 board.
>> The magic bits are the iommu-map prop and the
On Thu, Mar 28, 2019 at 05:59:48PM +0100, Marc Gonzalez wrote:
> Hello everyone,
>
> After a lot of poking, I am finally able to use the AR8151 ethernet on the
> APQ8098 board.
> The magic bits are the iommu-map prop and the PCIE20_PARF_BDF_TRANSLATE_N
> setup.
>
> The WIP thread is archived
[cc +iommu]
On Tue, 11 Jun 2019 20:40:41 +0800
Jiangyiwen wrote:
> Hi Alex,
>
> I found this problem is not very easy to solve, for
> now, in arm64 platform, the "0" physical address
> is a valid system memory address, so in function
> arm_smmu_iova_to_phys() I think it should not use
> "0" as
On Tue, 11 Jun 2019, Christoph Hellwig wrote:
> Hi Alan,
>
> thanks for the explanation. It seems like what usb wants is to:
>
> - set sg_tablesize to 1 for devices that can't handle scatterlist at all
Hmmm. usb-storage (and possible other drivers too) currently handles
such controllers by
On 11/06/2019 13:26, Jacob Pan wrote:
>> +/**
>> + * ioasid_set_data - Set private data for an allocated ioasid
>> + * @ioasid: the ID to set data
>> + * @data: the private data
>> + *
>> + * For IOASID that is already allocated, private data can be set
>> + * via this API. Future lookup can be
On 11/06/2019 11:45, Jonathan Cameron wrote:
>> +pci_disable_pasid(pdev);
>> +master->ssid_bits = 0;
>
> If we are being really fussy about ordering, why have this set of
> ssid_bits after pci_disable_pasid rather than before (to reverse order
> of .._enable_pasid)?
Sure, I'll change
On 11/06/2019 11:19, Jonathan Cameron wrote:
>> +static int arm_smmu_alloc_cd_tables(struct arm_smmu_domain *smmu_domain,
>> +struct arm_smmu_master *master)
>> +{
>> +struct arm_smmu_device *smmu = smmu_domain->smmu;
>> +struct arm_smmu_s1_cfg *cfg =
On 11/06/2019 10:36, Jonathan Cameron wrote:
>> +/**
>> + * ioasid_alloc - Allocate an IOASID
>> + * @set: the IOASID set
>> + * @min: the minimum ID (inclusive)
>> + * @max: the maximum ID (inclusive)
>> + * @private: data private to the caller
>> + *
>> + * Allocate an ID between @min and @max.
On 11/06/2019 10:42, Jonathan Cameron wrote:
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index 519e40fb23ce..b91df613385f 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -536,6 +536,7 @@ struct iommu_fwspec {
>> struct fwnode_handle
> On Jun 10, 2019, at 9:41 PM, Lu Baolu wrote:
>
> Ah, good catch!
>
> The device failed to be attached by a DMA domain. Can you please try the
> attached fix patch?
It works fine.
>
> [ 101.885468] pci :06:00.0: DMAR: Device is ineligible for IOMMU
> domain attach due to platform
The SMMU command queue is a bottleneck in large systems, thanks to the
spin_lock which serialises accesses from all CPUs to the single queue
supported by the hardware.
Attempt to improve this situation by moving to a new algorithm for
inserting commands into the queue, which is lock-free on the
In preparation for rewriting the command queue insertion code to use a
new algorithm, rework many of our queue macro accessors and manipulation
functions so that they operate on the arm_smmu_ll_queue structure where
possible. This will allow us to call these helpers on local variables
without
We've been artificially limiting the size of our queues to 4k so that we
don't end up allocating huge amounts of physically-contiguous memory at
probe time. However, 4k is only enough for 256 commands in the command
queue, so instead let's try to allocate the largest queue that the SMMU
supports,
In preparation for rewriting the command queue insertion code to use a
new algorithm, introduce a new arm_smmu_ll_queue structure which contains
only the information necessary to perform queue arithmetic for a queue
and will later be extended so that we can perform complex atomic
manipulation on
The Q_OVF macro doesn't need to access the arm_smmu_queue structure, so
drop the unused macro argument.
No functional change.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu-v3.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c
In preparation for rewriting the command queue insertion code to use a
new algorithm, separate the software and hardware views of the prod and
cons indexes so that manipulating the software state doesn't
automatically update the hardware state at the same time.
No functional change.
Hi all,
This patch series is an attempt to reduce lock contention when inserting
commands into the Arm SMMUv3 command queue. Unfortunately, our initial
benchmarking has shown mixed results across the board and the changes in
the last patch don't appear to justify their complexity. Based on that,
On 10/06/2019 22:31, Jacob Pan wrote:
> On Mon, 10 Jun 2019 13:45:02 +0100
> Jean-Philippe Brucker wrote:
>
>> On 07/06/2019 18:43, Jacob Pan wrote:
> So it seems we agree on the following:
> - iommu_unregister_device_fault_handler() will never fail
> - iommu driver cleans up all
On Mon, 10 Jun 2019 19:47:07 +0100
Jean-Philippe Brucker wrote:
> Some devices might support multiple DMA address spaces, in particular
> those that have the PCI PASID feature. PASID (Process Address Space
> ID) allows to share process address spaces with devices (SVA),
> partition a device into
On 03/06/2019 04:16, Lu Baolu wrote:
> IOMMU hardware always use paging for DMA remapping. The
> minimum mapped window is a page size. The device drivers
> may map buffers not filling whole IOMMU window. It allows
> device to access to possibly unrelated memory and various
> malicious devices
On Mon, 10 Jun 2019 19:47:14 +0100
Jean-Philippe Brucker wrote:
> Enable PASID for PCI devices that support it. Since the SSID tables are
> allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
> arm_smmu_dev_feature_enable() would be too late, since by that time the
> main
On Mon, 10 Jun 2019 19:47:11 +0100
Jean-Philippe Brucker wrote:
> The SMMU can support up to 20 bits of SSID. Add a second level of page
> tables to accommodate this. Devices that support more than 1024 SSIDs now
> have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context
>
On Mon, 10 Jun 2019 19:47:10 +0100
Jean-Philippe Brucker wrote:
> At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
> page directory per device. However SMMUv3 allows more than one address
> space for some devices, by providing multiple stage-1 page directories. In
>
Hi Daoyuan,
On Tue, Jun 11, 2019 at 6:20 PM Daoyuan Huang
wrote:
>
> hi Tomasz:
>
> Thanks for your review comments, the corresponding modification
> & explanation is under preparation, will update soon.
>
> Thanks.
Thanks.
Note that Alexandre may already be reviewing the rest of this patch,
On Tue, Jun 11, 2019 at 7:07 PM Frederic Chen
wrote:
>
> Hi Tomasz,
>
>
> On Tue, 2019-06-11 at 17:59 +0900, Tomasz Figa wrote:
> > On Tue, Jun 11, 2019 at 5:48 PM Frederic Chen
> > wrote:
> > >
> > > Dear Tomasz,
> > >
> > > I'd like to elaborate more about the tuning_data.va.
> > > Would you
Hi Tomasz,
On Tue, 2019-06-11 at 17:59 +0900, Tomasz Figa wrote:
> On Tue, Jun 11, 2019 at 5:48 PM Frederic Chen
> wrote:
> >
> > Dear Tomasz,
> >
> > I'd like to elaborate more about the tuning_data.va.
> > Would you like to give us some advice about our improvement proposal inline?
> >
> >
On Mon, 10 Jun 2019 19:47:09 +0100
Jean-Philippe Brucker wrote:
> For platform devices that support SubstreamID (SSID), firmware provides
> the number of supported SSID bits. Restrict it to what the SMMU supports
> and cache it into master->ssid_bits.
>
> Signed-off-by: Jean-Philippe Brucker
On Tue, Jun 11, 2019 at 5:48 PM Frederic Chen
wrote:
>
> Dear Tomasz,
>
> I'd like to elaborate more about the tuning_data.va.
> Would you like to give us some advice about our improvement proposal inline?
>
> Thank you very much.
>
>
> On Wed, 2019-05-22 at 03:14 +0800, Frederic Chen wrote:
> >
Hi Christoph, Alan,
> From: Alan Stern, Sent: Tuesday, June 11, 2019 3:46 AM
>
> On Mon, 10 Jun 2019, Christoph Hellwig wrote:
>
> > Hi Yoshihiro,
> >
> > sorry for not taking care of this earlier, today is a public holiday
> > here and thus I'm not working much over the long weekend.
To
Hi Alan,
thanks for the explanation. It seems like what usb wants is to:
- set sg_tablesize to 1 for devices that can't handle scatterlist at all
- set the virt boundary as-is for devices supporting "basic" scatterlist,
although that still assumes they can rejiggle them because for example
62 matches
Mail list logo
