From: Oleksandr <olekstysh@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: xen-devel@lists.xenproject.org,
virtualization@lists.linux-foundation.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
Jason Wang <jasowang@redhat.com>,
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>
Subject: Re: [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
Date: Thu, 5 May 2022 13:12:17 +0300 [thread overview]
Message-ID: <87009e86-8999-eac9-a5c9-feef196f69fc@gmail.com> (raw)
In-Reply-To: <YnHCgBsQ90cJ58+0@robh.at.kernel.org>
On 04.05.22 03:02, Rob Herring wrote:
Hello Rob
> On Tue, May 03, 2022 at 08:09:32PM +0300, Oleksandr wrote:
>> On 03.05.22 00:59, Rob Herring wrote:
>>
>> Hello Rob
>>
>>
>>> On Fri, Apr 22, 2022 at 07:51:01PM +0300, Oleksandr Tyshchenko wrote:
>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>
>>>> Introduce Xen specific binding for the virtualized device (e.g. virtio)
>>>> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>>>>
>>>> This binding indicates that Xen grant mappings scheme needs to be
>>>> enabled for the device which DT node contains that property and specifies
>>>> the ID of Xen domain where the corresponding backend resides. The ID
>>>> (domid) is used as an argument to the grant mapping APIs.
>>>>
>>>> This is needed for the option to restrict memory access using Xen grant
>>>> mappings to work which primary goal is to enable using virtio devices
>>>> in Xen guests.
>>>>
>>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>> ---
>>>> Changes RFC -> V1:
>>>> - update commit subject/description and text in description
>>>> - move to devicetree/bindings/arm/
>>>> ---
>>>> .../devicetree/bindings/arm/xen,dev-domid.yaml | 37 ++++++++++++++++++++++
>>>> 1 file changed, 37 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>>> new file mode 100644
>>>> index 00000000..ef0f747
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>>>> @@ -0,0 +1,37 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/arm/xen,dev-domid.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Xen specific binding for the virtualized device (e.g. virtio)
>>>> +
>>>> +maintainers:
>>>> + - Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>> +
>>>> +select: true
>>> Do we really need to support this property everywhere?
>> From my understanding - yes.
>>
>> As, I think, any device node describing virtulized device in the guest
>> device tree can have this property. Initially (in the RFC series) the
>> "solution to restrict memory access using Xen grant mappings" was
>> virtio-specific.
>>
>> Although the support of virtio is a primary target of this series, we
>> decided to generalize this work and expand it to any device [1]. So the Xen
>> grant mappings scheme (this property to be used for) can be theoretically
>> used for any device emulated by the Xen backend.
>>
>>
>>>> +
>>>> +description:
>>>> + This binding indicates that Xen grant mappings scheme needs to be enabled
>>>> + for that device and specifies the ID of Xen domain where the corresponding
>>>> + device (backend) resides. This is needed for the option to restrict memory
>>>> + access using Xen grant mappings to work.
>>>> +
>>>> +properties:
>>>> + xen,dev-domid:
>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>> + description:
>>>> + The domid (domain ID) of the domain where the device (backend) is running.
>>>> +
>>>> +additionalProperties: true
>>>> +
>>>> +examples:
>>>> + - |
>>>> + virtio_block@3000 {
>>> virtio@3000
>> ok, will change
>>
>>
>>>> + compatible = "virtio,mmio";
>>>> + reg = <0x3000 0x100>;
>>>> + interrupts = <41>;
>>>> +
>>>> + /* The device is located in Xen domain with ID 1 */
>>>> + xen,dev-domid = <1>;
>>> This fails validation:
>>>
>>> Documentation/devicetree/bindings/arm/xen,dev-domid.example.dtb: virtio_block@3000: xen,dev-domid: [[1]] is not of type 'object'
>>> From schema: /home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/virtio/mmio.yaml
>> Thank you for pointing this out, my fault, I haven't "properly" checked this
>> before. I think, we need to remove "compatible = "virtio,mmio"; here
> Uhh, no. That just means the example is incomplete. You need to add this
> property or reference this schema from virtio/mmio.yaml.
ok, I got it
>
>
>> diff --git a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> index 2daa8aa..d2f2140 100644
>> --- a/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> +++ b/Documentation/devicetree/bindings/arm/xen,dev-domid.yaml
>> @@ -28,7 +28,7 @@ additionalProperties: true
>> examples:
>> - |
>> virtio_block@3000 {
>> - compatible = "virtio,mmio";
>> + /* ... */
>> reg = <0x3000 0x100>;
>> interrupts = <41>;
>>
>>
>>
>>> The property has to be added to the virtio/mmio.yaml schema. If it is
>>> not needed elsewhere, then *just* add the property there.
>> As I described above, the property is not virtio specific and can be used
>> for any virtualized device for which Xen grant mappings scheme needs to be
>> enabled (xen-grant DMA-mapping layer).
> But that's a finite list of devices, right?
Right
> In any case, you have to
> list the property anywhere it can be used.
Agree
If I got it right, we need to add to virtio/mmio.yaml something like:
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
This passed validation.
Could you please clarify, is my understanding correct?
>
> Rob
--
Regards,
Oleksandr Tyshchenko
next prev parent reply other threads:[~2022-05-05 10:12 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 16:50 [PATCH V1 0/6] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer Oleksandr Tyshchenko
2022-04-22 16:50 ` [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops() Oleksandr Tyshchenko
2022-04-22 22:59 ` Stefano Stabellini
2022-04-23 14:35 ` Oleksandr
2022-04-23 16:32 ` Christoph Hellwig
2022-04-22 16:50 ` [PATCH V1 2/6] xen/grants: support allocating consecutive grants Oleksandr Tyshchenko
2022-04-22 16:51 ` [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen Oleksandr Tyshchenko
2022-04-22 23:00 ` Stefano Stabellini
2022-04-23 7:05 ` Oleksandr
2022-04-23 9:10 ` Juergen Gross
2022-04-23 15:25 ` Oleksandr
2022-04-23 16:40 ` Christoph Hellwig
2022-04-24 16:53 ` Oleksandr
2022-04-24 18:08 ` Boris Ostrovsky
2022-04-25 7:53 ` Juergen Gross
2022-04-25 7:47 ` Juergen Gross
2022-04-25 7:58 ` Christoph Hellwig
2022-04-25 9:14 ` Juergen Gross
2022-04-25 20:38 ` Oleksandr
2022-04-25 21:25 ` Borislav Petkov
2022-04-26 5:16 ` Juergen Gross
2022-04-26 8:41 ` Borislav Petkov
2022-04-26 9:36 ` Juergen Gross
2022-04-26 11:16 ` Borislav Petkov
2022-04-22 16:51 ` [PATCH V1 4/6] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops Oleksandr Tyshchenko
2022-04-22 23:00 ` [PATCH V1 4/6] dt-bindings: Add xen, dev-domid " Stefano Stabellini
2022-04-23 14:37 ` Oleksandr
2022-05-02 21:59 ` [PATCH V1 4/6] dt-bindings: Add xen,dev-domid " Rob Herring
2022-05-03 17:09 ` Oleksandr
2022-05-04 0:02 ` Rob Herring
2022-05-05 10:12 ` Oleksandr [this message]
2022-04-22 16:51 ` [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices Oleksandr Tyshchenko
2022-04-22 23:00 ` Stefano Stabellini
2022-04-23 15:23 ` Oleksandr
2022-04-22 16:51 ` [PATCH V1 6/6] arm/xen: Assign xen-grant DMA ops for xen-grant DMA devices Oleksandr Tyshchenko
2022-04-22 23:00 ` Stefano Stabellini
2022-04-23 16:42 ` Christoph Hellwig
2022-04-24 16:07 ` Oleksandr
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=87009e86-8999-eac9-a5c9-feef196f69fc@gmail.com \
--to=olekstysh@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=hch@infradead.org \
--cc=jasowang@redhat.com \
--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@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).