On 18.05.22 17:32, Arnd Bergmann wrote:
Hello Arnd
On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko <olekstysh@xxxxxxxxx> wrote:
diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml b/Documentation/devicetree/bindings/virtio/mmio.yaml
index 10c22b5..29a0932 100644
--- a/Documentation/devicetree/bindings/virtio/mmio.yaml
+++ b/Documentation/devicetree/bindings/virtio/mmio.yaml
@@ -13,6 +13,9 @@ description:
See https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio for
more details.
+allOf:
+ - $ref: /schemas/arm/xen,dev-domid.yaml#
+
properties:
compatible:
const: virtio,mmio
@@ -33,6 +36,10 @@ properties:
description: Required for devices making accesses thru an IOMMU.
maxItems: 1
+ xen,dev-domid:
+ description: Required when Xen grant mappings need to be enabled for device.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
required:
- compatible
- reg
Sorry for joining the discussion late. Have you considered using the
generic iommu
binding here instead of a custom property?
I have to admit - no, I haven't. I was thinking that Xen specific
feature should be communicated using Xen specific DT property.
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>;
};
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)?
Arnd
--
Regards,
Oleksandr Tyshchenko
