From: Robin Murphy <robin.murphy@arm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
kevin.tian@intel.com, linux-pci@vger.kernel.org,
jasowang@redhat.com, virtualization@lists.linux-foundation.org,
iommu@lists.linux-foundation.org, sebastien.boeuf@intel.com,
jacob.jun.pan@intel.com, bhelgaas@google.com
Subject: Re: [PATCH 3/3] iommu/virtio: Enable x86 support
Date: Mon, 17 Feb 2020 14:10:27 +0000 [thread overview]
Message-ID: <057a460a-4b8e-54ca-0181-a5e5c16d7206@arm.com> (raw)
In-Reply-To: <20200217083112-mutt-send-email-mst@kernel.org>
On 17/02/2020 1:31 pm, Michael S. Tsirkin wrote:
> On Mon, Feb 17, 2020 at 01:22:44PM +0000, Robin Murphy wrote:
>> On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
>>> On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
>>>> On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
>>>>> On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote:
>>>>>> On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
>>>>>>> With the built-in topology description in place, x86 platforms can now
>>>>>>> use the virtio-iommu.
>>>>>>>
>>>>>>> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>>>>>>> ---
>>>>>>> drivers/iommu/Kconfig | 3 ++-
>>>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>>>>>>> index 068d4e0e3541..adcbda44d473 100644
>>>>>>> --- a/drivers/iommu/Kconfig
>>>>>>> +++ b/drivers/iommu/Kconfig
>>>>>>> @@ -508,8 +508,9 @@ config HYPERV_IOMMU
>>>>>>> config VIRTIO_IOMMU
>>>>>>> bool "Virtio IOMMU driver"
>>>>>>> depends on VIRTIO=y
>>>>>>> - depends on ARM64
>>>>>>> + depends on (ARM64 || X86)
>>>>>>> select IOMMU_API
>>>>>>> + select IOMMU_DMA
>>>>>>
>>>>>> Can that have an "if X86" for clarity? AIUI it's not necessary for
>>>>>> virtio-iommu itself (and really shouldn't be), but is merely to satisfy the
>>>>>> x86 arch code's expectation that IOMMU drivers bring their own DMA ops,
>>>>>> right?
>>>>>>
>>>>>> Robin.
>>>>>
>>>>> In fact does not this work on any platform now?
>>>>
>>>> There is ongoing work to use the generic IOMMU_DMA ops on X86. AMD IOMMU
>>>> has been converted recently [1] but VT-d still implements its own DMA ops
>>>> (conversion patches are on the list [2]). On Arm the arch Kconfig selects
>>>> IOMMU_DMA, and I assume we'll have the same on X86 once Tom's work is
>>>> complete. Until then I can add a "if X86" here for clarity.
>>>>
>>>> Thanks,
>>>> Jean
>>>>
>>>> [1] https://lore.kernel.org/linux-iommu/20190613223901.9523-1-murphyt7@tcd.ie/
>>>> [2] https://lore.kernel.org/linux-iommu/20191221150402.13868-1-murphyt7@tcd.ie/
>>>
>>> What about others? E.g. PPC?
>>
>> That was the point I was getting at - while iommu-dma should build just fine
>> for the likes of PPC, s390, 32-bit Arm, etc., they have no architecture code
>> to correctly wire up iommu_dma_ops to devices. Thus there's currently no
>> point pulling it in and pretending it's anything more than a waste of space
>> for architectures other than arm64 and x86. It's merely a historical
>> artefact of the x86 DMA API implementation that when the IOMMU drivers were
>> split out to form drivers/iommu they took some of their relevant arch code
>> with them.
>>
>> Robin.
>
>
> Rather than white-listing architectures, how about making the
> architectures in question set some kind of symbol, and depend on it?
Umm, that's basically what we have already? Architectures that use
iommu_dma_ops select IOMMU_DMA.
The only issue is the oddity of x86 treating IOMMU drivers as part of
its arch code, which has never come up against a cross-architecture
driver until now. Hence the options of either maintaining that paradigm
and having the 'x86 arch code' aspect of this driver "select IOMMU_DMA
if x86" such that it works out equivalent to AMD_IOMMU, or a more
involved cleanup to move that responsibility out of
drivers/iommu/Kconfig entirely and have arch/x86/Kconfig do something
like "select IOMMU_DMA if IOMMU_API", as Jean suggested up-thread.
In the specific context of IOMMU_DMA we're not talking about any kind of
white-list, merely a one-off special case for one particular architecture.
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-02-17 14:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 16:04 [PATCH 0/3] virtio-iommu on non-devicetree platforms Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 1/3] iommu/virtio: Add topology description to virtio-iommu config space Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 2/3] PCI: Add DMA configuration for virtual platforms Jean-Philippe Brucker
2020-02-14 17:03 ` Robin Murphy
2020-02-17 9:12 ` Jean-Philippe Brucker
2020-02-14 16:04 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2020-02-14 16:57 ` Robin Murphy
2020-02-16 9:50 ` Michael S. Tsirkin
2020-02-17 9:01 ` Jean-Philippe Brucker
2020-02-17 13:01 ` Michael S. Tsirkin
2020-02-17 13:22 ` Robin Murphy
2020-02-17 13:31 ` Michael S. Tsirkin
2020-02-17 14:10 ` Robin Murphy [this message]
2021-03-16 19:16 [PATCH 0/3] Add support for ACPI VIOT Jean-Philippe Brucker
2021-03-16 19:16 ` [PATCH 3/3] iommu/virtio: Enable x86 support Jean-Philippe Brucker
2021-03-18 10:44 ` Joerg Roedel
2021-03-18 11:43 ` Robin Murphy
2021-04-15 15:14 ` Jean-Philippe Brucker
2021-03-18 18:28 ` Michael S. Tsirkin
2021-04-15 15:15 ` Jean-Philippe Brucker
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=057a460a-4b8e-54ca-0181-a5e5c16d7206@arm.com \
--to=robin.murphy@arm.com \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=jasowang@redhat.com \
--cc=jean-philippe@linaro.org \
--cc=kevin.tian@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=mst@redhat.com \
--cc=sebastien.boeuf@intel.com \
--cc=virtualization@lists.linux-foundation.org \
/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).