On Mon, Mar 23, 2020 at 12:28:34PM +1100, Alexey Kardashevskiy wrote:
[full quote deleted, please follow proper quoting rules]
> > +static bool dma_alloc_direct(struct device *dev, const struct dma_map_ops
> > *ops)
> > +{
> > + if (!ops)
> > + return true;
> > +
> > + /*
> > +
On Mon, Mar 23, 2020 at 09:37:05AM +0100, Christoph Hellwig wrote:
> > > + /*
> > > + * Allows IOMMU drivers to bypass dynamic translations if the DMA mask
> > > + * is large enough.
> > > + */
> > > + if (dev->dma_ops_bypass) {
> > > + if (min_not_zero(dev->coherent_dma_mask, dev->bus_d
On 20/03/2020 16:33, Marc Zyngier wrote:
JFYI, I've been playing for "perf annotate" today and it's giving
strange results for my NVMe testing. So "report" looks somewhat sane,
if not a worryingly high % for arm_smmu_cmdq_issue_cmdlist():
55.39% irq/342-nvme0q1 [kernel.kallsyms] [k]
arm
On 23/03/2020 19:37, Christoph Hellwig wrote:
> On Mon, Mar 23, 2020 at 12:28:34PM +1100, Alexey Kardashevskiy wrote:
>
> [full quote deleted, please follow proper quoting rules]
>
>>> +static bool dma_alloc_direct(struct device *dev, const struct dma_map_ops
>>> *ops)
>>> +{
>>> + if (!ops
On 2020-03-23 09:03, John Garry wrote:
On 20/03/2020 16:33, Marc Zyngier wrote:
JFYI, I've been playing for "perf annotate" today and it's giving
strange results for my NVMe testing. So "report" looks somewhat sane,
if not a worryingly high % for arm_smmu_cmdq_issue_cmdlist():
55.39% irq/
Hi Robin,
On 2020-03-12 17:35, Robin Murphy wrote:
On 2020-03-12 6:28 am, Sai Prakash Ranjan wrote:
Hi Robin,
Are you talking about this one for SoC specific change -
https://lore.kernel.org/patchwork/patch/1183530/
Exactly - this particular wheel needs no reinventing at all.
[ I guess I
Hi Bharat,
Please add the IOMMU list on your next posting
On Mon, Mar 23, 2020 at 02:11:08PM +0530, Bharat Bhushan wrote:
> Different endpoint can support different page size, probe
> endpoint if it supports specific page size otherwise use
> global page sizes.
>
> Signed-off-by: Bharat Bhushan
On 2020-03-20 2:16 pm, Christoph Hellwig wrote:
Several IOMMU drivers have a bypass mode where they can use a direct
mapping if the devices DMA mask is large enough. Add generic support
to the core dma-mapping code to do that to switch those drivers to
a common solution.
Hmm, this is _almost_,
On Mon, Mar 23, 2020 at 12:14:08PM +, Robin Murphy wrote:
> On 2020-03-20 2:16 pm, Christoph Hellwig wrote:
>> Several IOMMU drivers have a bypass mode where they can use a direct
>> mapping if the devices DMA mask is large enough. Add generic support
>> to the core dma-mapping code to do that
Christoph Hellwig writes:
> On Mon, Mar 23, 2020 at 09:37:05AM +0100, Christoph Hellwig wrote:
>> > > +/*
>> > > + * Allows IOMMU drivers to bypass dynamic translations if the
>> > > DMA mask
>> > > + * is large enough.
>> > > + */
>> > > +if (dev->dma_ops
Hi Joerg,
Thanks for tackling this!
On 2020-03-20 9:14 am, Joerg Roedel wrote:
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions and simplify the code
where possible with this change.
Tested-by: Will Deacon # arm-smmu
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu
On Mon, Mar 23, 2020 at 07:58:01PM +1100, Alexey Kardashevskiy wrote:
> >> 0x100.. .. 0x101..
> >>
> >> 2x4G, each is 1TB aligned. And we can map directly only the first 4GB
> >> (because of the maximum IOMMU table size) but not the other. And 1:1 on
> >> that "pseries" is done with
On Mon, Mar 23, 2020 at 09:07:38PM +0530, Aneesh Kumar K.V wrote:
>
> This is what I was trying, but considering I am new to DMA subsystem, I
> am not sure I got all the details correct. The idea is to look at the
> cpu addr and see if that can be used in direct map fashion(is
> bus_dma_limit the
Hi Jean,
> -Original Message-
> From: Jean-Philippe Brucker
> Sent: Monday, March 23, 2020 3:30 PM
> To: Bharat Bhushan
> Cc: j...@8bytes.org; m...@redhat.com; jasow...@redhat.com;
> virtualizat...@lists.linux-foundation.org; iommu@lists.linux-foundation.org;
> eric.au...@redhat.com
> Su
Hi Jean,
> -Original Message-
> From: Jean-Philippe Brucker
> Sent: Monday, March 23, 2020 3:30 PM
> To: Bharat Bhushan
> Cc: j...@8bytes.org; m...@redhat.com; jasow...@redhat.com;
> virtualizat...@lists.linux-foundation.org; iommu@lists.linux-foundation.org;
> eric.au...@redhat.com
> Su
On Sun, 22 Mar 2020 09:29:32 +0800
Lu Baolu wrote:
> On 2020/3/21 7:27, Jacob Pan wrote:
> > Memory type related flags can be grouped together for one simple
> > check.
> >
> > ---
> > v9 renamed from EMT to MTS since these are memory type support
> > flags. ---
> >
> > Signed-off-by: Jacob Pan
These user messages are not really informational,
but mostly of debug nature. Lower their severity.
Signed-off-by: Ezequiel Garcia
---
drivers/iommu/iommu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 3e3528436e0
Hi Jean
On Fri, Mar 20, 2020 at 10:29:55AM +0100, Jean-Philippe Brucker wrote:
> > +#define to_intel_svm_dev(handle) container_of(handle, struct
> > intel_svm_dev, sva)
> > +struct iommu_sva *
> > +intel_svm_bind(struct device *dev, struct mm_struct *mm, void *drvdata)
> > +{
> > + struct iommu
On 2020/3/24 7:01, Raj, Ashok wrote:
Hi Jean
On Fri, Mar 20, 2020 at 10:29:55AM +0100, Jean-Philippe Brucker wrote:
+#define to_intel_svm_dev(handle) container_of(handle, struct intel_svm_dev,
sva)
+struct iommu_sva *
+intel_svm_bind(struct device *dev, struct mm_struct *mm, void *drvdata)
+{
On 2020/3/24 3:37, Jacob Pan wrote:
On Sun, 22 Mar 2020 09:29:32 +0800> Lu Baolu wrote:
On 2020/3/21 7:27, Jacob Pan wrote:
Memory type related flags can be grouped together for one simple
check.
---
v9 renamed from EMT to MTS since these are memory type support
flags. ---
Signed-off-by: Ja
On 24/03/2020 04:22, Christoph Hellwig wrote:
> On Mon, Mar 23, 2020 at 09:07:38PM +0530, Aneesh Kumar K.V wrote:
>>
>> This is what I was trying, but considering I am new to DMA subsystem, I
>> am not sure I got all the details correct. The idea is to look at the
>> cpu addr and see if that can
On 24/03/2020 04:20, Christoph Hellwig wrote:
> On Mon, Mar 23, 2020 at 07:58:01PM +1100, Alexey Kardashevskiy wrote:
0x100.. .. 0x101..
2x4G, each is 1TB aligned. And we can map directly only the first 4GB
(because of the maximum IOMMU table size) but not the
On 24/03/2020 14:37, Alexey Kardashevskiy wrote:
>
>
> On 24/03/2020 04:20, Christoph Hellwig wrote:
>> On Mon, Mar 23, 2020 at 07:58:01PM +1100, Alexey Kardashevskiy wrote:
> 0x100.. .. 0x101..
>
> 2x4G, each is 1TB aligned. And we can map directly only the first 4
Alexey Kardashevskiy writes:
> On 24/03/2020 04:22, Christoph Hellwig wrote:
>> On Mon, Mar 23, 2020 at 09:07:38PM +0530, Aneesh Kumar K.V wrote:
>>>
>>> This is what I was trying, but considering I am new to DMA subsystem, I
>>> am not sure I got all the details correct. The idea is to look at t
On Mon, Mar 23, 2020 at 06:04:37PM +, Bharat Bhushan wrote:
> > > -static int viommu_domain_finalise(struct viommu_dev *viommu,
> > > +static int viommu_domain_finalise(struct viommu_endpoint *vdev,
> > > struct iommu_domain *domain)
> > > {
> > > int ret;
> > >
25 matches
Mail list logo
