LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: baolu.lu@linux.intel.com, David Woodhouse <dwmw2@infradead.org>,
Joerg Roedel <joro@8bytes.org>,
kevin.tian@intel.com, ashok.raj@intel.com, dima@arista.com,
tmurphy@arista.com, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, jacob.jun.pan@intel.com
Subject: Re: [PATCH v4 10/15] iommu/vt-d: Probe DMA-capable ACPI name space devices
Date: Mon, 3 Jun 2019 08:35:39 +0800 [thread overview]
Message-ID: <23d9d04c-c3fd-716e-dd66-eb5119aad4f9@linux.intel.com> (raw)
In-Reply-To: <20190529061626.GA26055@infradead.org>
Hi,
On 5/29/19 2:16 PM, Christoph Hellwig wrote:
> On Sat, May 25, 2019 at 01:41:31PM +0800, Lu Baolu wrote:
>> Some platforms may support ACPI name-space enumerated devices
>> that are capable of generating DMA requests. Platforms which
>> support DMA remapping explicitly declares any such DMA-capable
>> ACPI name-space devices in the platform through ACPI Name-space
>> Device Declaration (ANDD) structure and enumerate them through
>> the Device Scope of the appropriate remapping hardware unit.
>>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>
> Isn't this something that should be handled through the IOMMU API so
> that it covers other IOMMU types as well?
>
> How does this scheme compare to the one implemented in
> drivers/acpi/arm64/iort.c?
>
This part of code was added to be compatible with the past.
Yes. I've ever thought about this. But these devices sit on the acpi bus
together with other devices which are not DMA-capable. And on some
platforms these devices exist on the pci bus as well.
Best regards,
Baolu
next prev parent reply other threads:[~2019-06-03 0:42 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-25 5:41 [PATCH v4 00/15] iommu/vt-d: Delegate DMA domain to generic iommu Lu Baolu
2019-05-25 5:41 ` [PATCH v4 01/15] iommu: Add API to request DMA domain for device Lu Baolu
2019-05-25 5:41 ` [PATCH v4 02/15] iommu/vt-d: Implement apply_resv_region iommu ops entry Lu Baolu
2019-05-25 5:41 ` [PATCH v4 03/15] iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions Lu Baolu
2019-05-25 5:41 ` [PATCH v4 04/15] iommu/vt-d: Enable DMA remapping after rmrr mapped Lu Baolu
2019-05-25 5:41 ` [PATCH v4 05/15] iommu/vt-d: Add device_def_domain_type() helper Lu Baolu
2019-05-25 5:41 ` [PATCH v4 06/15] iommu/vt-d: Delegate the identity domain to upper layer Lu Baolu
2019-05-25 5:41 ` [PATCH v4 07/15] iommu/vt-d: Delegate the dma " Lu Baolu
2020-08-21 18:33 ` Chris Wilson
2020-08-24 6:31 ` Lu Baolu
2020-08-24 8:35 ` Chris Wilson
2020-08-25 3:13 ` Lu Baolu
2019-05-25 5:41 ` [PATCH v4 08/15] iommu/vt-d: Identify default domains replaced with private Lu Baolu
2019-05-25 5:41 ` [PATCH v4 09/15] iommu/vt-d: Handle 32bit device with identity default domain Lu Baolu
2019-05-25 5:41 ` [PATCH v4 10/15] iommu/vt-d: Probe DMA-capable ACPI name space devices Lu Baolu
2019-05-29 6:16 ` Christoph Hellwig
2019-06-03 0:35 ` Lu Baolu [this message]
2019-05-25 5:41 ` [PATCH v4 11/15] iommu/vt-d: Implement is_attach_deferred iommu ops entry Lu Baolu
2019-05-25 5:41 ` [PATCH v4 12/15] iommu/vt-d: Cleanup get_valid_domain_for_dev() Lu Baolu
2019-07-18 3:12 ` Alex Williamson
2019-07-19 9:04 ` Lu Baolu
2019-07-19 15:23 ` Alex Williamson
2019-08-02 1:30 ` Alex Williamson
2019-08-02 7:17 ` Lu Baolu
2019-08-02 16:54 ` Alex Williamson
2019-08-04 3:16 ` Lu Baolu
2019-08-06 0:06 ` Lu Baolu
2019-05-25 5:41 ` [PATCH v4 13/15] iommu/vt-d: Remove startup parameter from device_def_domain_type() Lu Baolu
2019-05-25 5:41 ` [PATCH v4 14/15] iommu/vt-d: Remove duplicated code for device hotplug Lu Baolu
2019-05-25 5:41 ` [PATCH v4 15/15] iommu/vt-d: Remove static identity map code Lu Baolu
2019-05-27 15:00 ` [PATCH v4 00/15] iommu/vt-d: Delegate DMA domain to generic iommu Joerg Roedel
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=23d9d04c-c3fd-716e-dd66-eb5119aad4f9@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=dima@arista.com \
--cc=dwmw2@infradead.org \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tmurphy@arista.com \
--subject='Re: [PATCH v4 10/15] iommu/vt-d: Probe DMA-capable ACPI name space devices' \
/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
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).