From: Oleksandr <olekstysh@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
"open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE"
<virtualization@lists.linux-foundation.org>,
DTML <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
Jason Wang <jasowang@redhat.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Julien Grall <julien@xen.org>, Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>
Subject: Re: [PATCH V2 5/7] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
Date: Thu, 19 May 2022 02:32:35 +0300 [thread overview]
Message-ID: <460a746c-6b61-214b-4653-44a1430e314d@gmail.com> (raw)
In-Reply-To: <CAK8P3a1YhkEZ8gcbXHEa5Bwx-4VVRJO8SUHf8=RNWRsc2Yo-+A@mail.gmail.com>
On 18.05.22 19:39, Arnd Bergmann wrote:
Hello Arnd
> On Wed, May 18, 2022 at 5:06 PM Oleksandr <olekstysh@gmail.com> wrote:
>> On 18.05.22 17:32, Arnd Bergmann wrote:
>>> On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko <olekstysh@gmail.com> wrote:
>>> This would mean having a device
>>> node for the grant-table mechanism that can be referred to using the 'iommus'
>>> phandle property, with the domid as an additional argument.
>> I assume, you are speaking about something like the following?
>>
>>
>> xen_dummy_iommu {
>> compatible = "xen,dummy-iommu";
>> #iommu-cells = <1>;
>> };
>>
>> virtio@3000 {
>> compatible = "virtio,mmio";
>> reg = <0x3000 0x100>;
>> interrupts = <41>;
>>
>> /* The device is located in Xen domain with ID 1 */
>> iommus = <&xen_dummy_iommu 1>;
>> };
> Right, that's that's the idea,
thank you for the confirmation
> except I would not call it a 'dummy'.
> From the perspective of the DT, this behaves just like an IOMMU,
> even if the exact mechanism is different from most hardware IOMMU
> implementations.
well, agree
>
>>> It does not quite fit the model that Linux currently uses for iommus,
>>> as that has an allocator for dma_addr_t space
>> yes (# 3/7 adds grant-table based allocator)
>>
>>
>>> , but it would think it's
>>> conceptually close enough that it makes sense for the binding.
>> Interesting idea. I am wondering, do we need an extra actions for this
>> to work in Linux guest (dummy IOMMU driver, etc)?
> It depends on how closely the guest implementation can be made to
> resemble a normal iommu. If you do allocate dma_addr_t addresses,
> it may actually be close enough that you can just turn the grant-table
> code into a normal iommu driver and change nothing else.
Unfortunately, I failed to find a way how use grant references at the
iommu_ops level (I mean to fully pretend that we are an IOMMU driver). I
am not too familiar with that, so what is written below might be wrong
or at least not precise.
The normal IOMMU driver in Linux doesn’t allocate DMA addresses by
itself, it just maps (IOVA-PA) what was requested to be mapped by the
upper layer. The DMA address allocation is done by the upper layer
(DMA-IOMMU which is the glue layer between DMA API and IOMMU API
allocates IOVA for PA?). But, all what we need here is just to allocate
our specific grant-table based DMA addresses (DMA address = grant
reference + offset in the page), so let’s say we need an entity to take
a physical address as parameter and return a DMA address (what actually
commit #3/7 is doing), and that’s all. So working at the dma_ops layer
we get exactly what we need, with the minimal changes to guest
infrastructure. In our case the Xen itself acts as an IOMMU.
Assuming that we want to reuse the IOMMU infrastructure somehow for our
needs. I think, in that case we will likely need to introduce a new
specific IOVA allocator (alongside with a generic one) to be hooked up
by the DMA-IOMMU layer if we run on top of Xen. But, even having the
specific IOVA allocator to return what we indeed need (DMA address =
grant reference + offset in the page) we will still need the specific
minimal required IOMMU driver to be present in the system anyway in
order to track the mappings(?) and do nothing with them, returning a
success (this specific IOMMU driver should have all mandatory callbacks
implemented).
I completely agree, it would be really nice to reuse generic IOMMU
bindings rather than introducing Xen specific property if what we are
trying to implement in current patch series fits in the usage of
"iommus" in Linux more-less. But, if we will have to add more
complexity/more components to the code for the sake of reusing device
tree binding, this raises a question whether that’s worthwhile.
Or I really missed something?
>
> Arnd
--
Regards,
Oleksandr Tyshchenko
next prev parent reply other threads:[~2022-05-18 23:33 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-07 18:19 [PATCH V2 0/7] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer Oleksandr Tyshchenko
2022-05-07 18:19 ` [PATCH V2 1/7] arm/xen: Introduce xen_setup_dma_ops() Oleksandr Tyshchenko
2022-05-07 18:52 ` Catalin Marinas
2022-05-07 18:19 ` [PATCH V2 2/7] xen/grants: support allocating consecutive grants Oleksandr Tyshchenko
2022-05-11 18:00 ` Oleksandr
2022-05-11 21:09 ` Boris Ostrovsky
2022-05-12 6:11 ` Oleksandr
2022-05-12 20:01 ` Boris Ostrovsky
2022-05-13 5:33 ` Juergen Gross
2022-05-13 10:43 ` Oleksandr
2022-05-14 2:34 ` Boris Ostrovsky
2022-05-16 5:59 ` Juergen Gross
2022-05-16 16:00 ` Boris Ostrovsky
2022-05-16 18:30 ` Oleksandr
2022-05-16 18:57 ` Boris Ostrovsky
2022-05-07 18:19 ` [PATCH V2 3/7] xen/grant-dma-ops: Add option to restrict memory access under Xen Oleksandr Tyshchenko
2022-05-09 21:39 ` Stefano Stabellini
2022-05-07 18:19 ` [PATCH V2 4/7] xen/virtio: Enable restricted memory access using Xen grant mappings Oleksandr Tyshchenko
2022-05-09 21:39 ` Stefano Stabellini
2022-05-07 18:19 ` [PATCH V2 5/7] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops Oleksandr Tyshchenko
2022-05-09 21:39 ` [PATCH V2 5/7] dt-bindings: Add xen, dev-domid " Stefano Stabellini
2022-05-17 0:27 ` [PATCH V2 5/7] dt-bindings: Add xen,dev-domid " Rob Herring
2022-05-18 14:12 ` Oleksandr
2022-05-18 14:32 ` Arnd Bergmann
2022-05-18 16:06 ` Oleksandr
2022-05-18 16:39 ` Arnd Bergmann
2022-05-18 23:32 ` Oleksandr [this message]
2022-05-19 1:06 ` Stefano Stabellini
2022-05-19 6:03 ` Oleksandr
2022-05-23 17:30 ` Oleksandr
2022-05-24 1:58 ` Stefano Stabellini
2022-05-24 16:01 ` Rob Herring
2022-05-24 18:34 ` Saravana Kannan
2022-05-25 16:30 ` Oleksandr
2022-05-24 16:11 ` Oleksandr
2022-05-24 17:59 ` Stefano Stabellini
2022-05-25 11:15 ` Oleksandr
2022-05-18 18:59 ` Rob Herring
2022-05-18 23:48 ` Oleksandr
2022-05-07 18:19 ` [PATCH V2 6/7] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices Oleksandr Tyshchenko
2022-05-09 21:39 ` Stefano Stabellini
2022-05-07 18:19 ` [PATCH V2 7/7] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices Oleksandr Tyshchenko
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=460a746c-6b61-214b-4653-44a1430e314d@gmail.com \
--to=olekstysh@gmail.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=hch@infradead.org \
--cc=jasowang@redhat.com \
--cc=jean-philippe@linaro.org \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=oleksandr_tyshchenko@epam.com \
--cc=robh+dt@kernel.org \
--cc=sstabellini@kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=xen-devel@lists.xenproject.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).