On Wed, May 18, 2022 at 5:06 PM Oleksandr [off-list ref] wrote:

On 18.05.22 17:32, Arnd Bergmann wrote:

quoted

On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko [off-list ref] wrote:

quoted

  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, 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.

quoted

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)

quoted

, 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.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel