From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
To: Bob Liu <liubo95@huawei.com>, Yisheng Xie <xieyisheng1@huawei.com>
Cc: joro@8bytes.org, robh+dt@kernel.org, mark.rutland@arm.com,
lorenzo.pieralisi@arm.com, hanjun.guo@linaro.org,
sudeep.holla@arm.com, rjw@rjwysocki.net, lenb@kernel.org,
will.deacon@arm.com, robin.murphy@arm.com,
robert.moore@intel.com, lv.zheng@intel.com,
iommu@lists.linux-foundation.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devel@acpica.org,
chenjiankang1@huawei.com, xieyisheng@huawei.com
Subject: Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3
Date: Thu, 7 Sep 2017 17:32:13 +0100 [thread overview]
Message-ID: <bde256dd-6550-6c40-fe2c-2bd1cc1339d3@arm.com> (raw)
In-Reply-To: <1d358989-48bb-ccde-d7d9-36e004bc2d78@huawei.com>
On 07/09/17 02:41, Bob Liu wrote:
>> This would require some work in moving the PCI bits at the end of the
>> series. I can reserve some time in the coming months to do it, but I need
>> to know what to focus on. Are you able to test SSID as well?
>>
>
> Yes, but the difficulty is our devices are on-chip integrated hardware accelerators which requires complicate driver.
> You may need much time to understand the driver.
> That's the same case as intel/amd SVM, the current user is their GPU :-(
>
> Btw, what kind of device/method do you think is ideal for testing arm-SVM?
A simple, bare DMA engine would be ideal. Something just capable of
performing memcpy with parameters (PASID, input IOVA, output IOVA, size)
can be used for validating SVM and virtualization. You could easily create
reproducible unit tests and userspace drivers. If it supports isolated
channels (as in SR-IOV), even better.
As you said, having a useful device like a full GPU/accelerator as opposed
to a dummy validation engine makes it difficult to fully test the SMMU.
However it can be helpful for evaluating driver performances and is still
good enough for confirming that the IOMMU works.
Thanks,
Jean
next prev parent reply other threads:[~2017-09-07 16:28 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-31 8:20 [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3 Yisheng Xie
2017-08-31 8:20 ` [RFC PATCH 1/6] dt-bindings: document stall and PASID properties for IOMMU masters Yisheng Xie
2017-09-05 12:52 ` Jean-Philippe Brucker
2017-08-31 8:20 ` [RFC PATCH 2/6] iommu/of: Add stall and pasid properties to iommu_fwspec Yisheng Xie
2017-09-05 12:52 ` Jean-Philippe Brucker
2017-08-31 8:20 ` [RFC PATCH 3/6] ACPI: IORT: " Yisheng Xie
2017-08-31 8:20 ` [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices Yisheng Xie
2017-09-05 12:53 ` Jean-Philippe Brucker
2017-09-06 0:51 ` Bob Liu
2017-09-06 1:20 ` Yisheng Xie
2017-08-31 8:20 ` [RFC PATCH 5/6] iommu/arm-smmu-v3: fix panic when handle stall mode irq Yisheng Xie
2017-09-05 12:53 ` Jean-Philippe Brucker
2017-08-31 8:20 ` [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S Yisheng Xie
2017-09-05 12:54 ` Jean-Philippe Brucker
2017-09-06 2:23 ` Yisheng Xie
2017-09-13 3:06 ` Will Deacon
2017-09-13 10:11 ` Yisheng Xie
2017-09-13 15:47 ` Jean-Philippe Brucker
2017-09-13 17:11 ` Will Deacon
2017-09-05 12:56 ` [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3 Jean-Philippe Brucker
2017-09-06 1:02 ` Bob Liu
2017-09-06 9:57 ` Jean-Philippe Brucker
2017-09-07 1:41 ` Bob Liu
2017-09-07 16:32 ` Jean-Philippe Brucker [this message]
2017-09-13 1:11 ` Bob Liu
2017-09-06 1:16 ` Yisheng Xie
2017-09-06 9:59 ` Jean-Philippe Brucker
2017-09-07 1:55 ` Bob Liu
2017-09-07 16:30 ` Jean-Philippe Brucker
2017-09-06 1:24 ` Hanjun Guo
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=bde256dd-6550-6c40-fe2c-2bd1cc1339d3@arm.com \
--to=jean-philippe.brucker@arm.com \
--cc=chenjiankang1@huawei.com \
--cc=devel@acpica.org \
--cc=devicetree@vger.kernel.org \
--cc=hanjun.guo@linaro.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liubo95@huawei.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=lv.zheng@intel.com \
--cc=mark.rutland@arm.com \
--cc=rjw@rjwysocki.net \
--cc=robert.moore@intel.com \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=sudeep.holla@arm.com \
--cc=will.deacon@arm.com \
--cc=xieyisheng1@huawei.com \
--cc=xieyisheng@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).