lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 19 May 2022 09:03:28 +0300 From: Oleksandr <olekstysh@...il.com> To: Stefano Stabellini <sstabellini@...nel.org> Cc: Arnd Bergmann <arnd@...db.de>, xen-devel <xen-devel@...ts.xenproject.org>, "open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE" <virtualization@...ts.linux-foundation.org>, DTML <devicetree@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>, Jason Wang <jasowang@...hat.com>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Julien Grall <julien@....org>, Juergen Gross <jgross@...e.com>, "Michael S. Tsirkin" <mst@...hat.com>, Christoph Hellwig <hch@...radead.org>, Jean-Philippe Brucker <jean-philippe@...aro.org> Subject: Re: [PATCH V2 5/7] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops On 19.05.22 04:06, Stefano Stabellini wrote: Hello Stefano > On Thu, 19 May 2022, Oleksandr wrote: >>> On Wed, May 18, 2022 at 5:06 PM Oleksandr <olekstysh@...il.com> wrote: >>>> On 18.05.22 17:32, Arnd Bergmann wrote: >>>>> On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko >>>>> <olekstysh@...il.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@...0 { >>>> 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? > I think Arnd was primarily suggesting to reuse the IOMMU Device Tree > bindings, not necessarily the IOMMU drivers framework in Linux (although > that would be an added bonus.) > > I know from previous discussions with you that making the grant table > fit in the existing IOMMU drivers model is difficult, but just reusing > the Device Tree bindings seems feasible? I started experimenting with that. As wrote in a separate email, I got a deferred probe timeout, after inserting required nodes into guest device tree, which seems to be a consequence of the unavailability of IOMMU, I will continue to investigate this question. -- Regards, Oleksandr Tyshchenko
Powered by blists - more mailing lists