All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksandr <olekstysh@gmail.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>, Julien Grall <julien@xen.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
Date: Sat, 23 Apr 2022 18:23:19 +0300	[thread overview]
Message-ID: <6ac03d9f-a678-60e9-ca6e-fcbe1aee51d3@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2204221534080.915916@ubuntu-linux-20-04-desktop>


On 23.04.22 02:00, Stefano Stabellini wrote:

Hello Stefano

> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Use the presence of recently introduced "xen,dev-domid" property
>> in the device node as a clear indicator of enabling Xen grant
>> mappings scheme for that device and read the ID of Xen domain where
>> the corresponding backend resides. The ID (domid) is used as
>> an argument to the Xen grant mapping APIs.
>>
>> Also introduce xen_is_grant_dma_device() to check whether xen-grant
>> DMA ops need to be set for a passed device.
>>
>> Remove the hardcoded domid 0 in xen_grant_setup_dma_ops().
>>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> ---
>> Changes RFC -> V1:
>>     - new patch, split required changes from commit:
>>      "[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
>>     - update checks in xen_virtio_setup_dma_ops() to only support
>>       DT devices for now
>>     - remove the "virtio,mmio" check from xen_is_virtio_device()
>>     - remane everything according to the new naming scheme:
>>       s/virtio/grant_dma
>> ---
>>   drivers/xen/grant-dma-ops.c | 25 ++++++++++++++++++-------
>>   include/xen/xen-ops.h       |  5 +++++
>>   2 files changed, 23 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
>> index 0e69aa8..70d5d77 100644
>> --- a/drivers/xen/grant-dma-ops.c
>> +++ b/drivers/xen/grant-dma-ops.c
>> @@ -66,11 +66,6 @@ static struct xen_grant_dma_data *find_xen_grant_dma_data(struct device *dev)
>>    * Such a DMA address is formed by using the grant reference as a frame
>>    * number and setting the highest address bit (this bit is for the backend
>>    * to be able to distinguish it from e.g. a mmio address).
>> - *
>> - * Note that for now we hard wire dom0 to be the backend domain. In order
>> - * to support any domain as backend we'd need to add a way to communicate
>> - * the domid of this backend, e.g. via Xenstore, via the PCI-device's
>> - * config space or DT/ACPI.
>>    */
>>   static void *xen_grant_dma_alloc(struct device *dev, size_t size,
>>   				 dma_addr_t *dma_handle, gfp_t gfp,
>> @@ -277,6 +272,16 @@ static const struct dma_map_ops xen_grant_dma_ops = {
>>   	.dma_supported = xen_grant_dma_supported,
>>   };
>>   
>> +bool xen_is_grant_dma_device(struct device *dev)
>> +{
>> +	/* XXX Handle only DT devices for now */
>> +	if (!dev->of_node)
>> +		return false;
>> +
>> +	return of_property_read_bool(dev->of_node, "xen,dev-domid");
>> +}
>> +EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
>> +
>>   void xen_grant_setup_dma_ops(struct device *dev)
>>   {
>>   	struct xen_grant_dma_data *data;
>> @@ -288,8 +293,14 @@ void xen_grant_setup_dma_ops(struct device *dev)
>>   		return;
>>   	}
>>   
>> -	/* XXX The dom0 is hardcoded as the backend domain for now */
>> -	dev_domid = 0;
>> +	/* XXX ACPI and PCI devices unsupported for now */
>> +	if (dev_is_pci(dev) || !dev->of_node)
>> +		goto err;
> I think we can remove the "dev_is_pci" check, right?

I think, yes (at least for now). I will remove the inclusion of #include 
<linux/pci.h> as well.


>
>
>> +	if (of_property_read_u32(dev->of_node, "xen,dev-domid", &dev_domid)) {
>> +		dev_err(dev, "xen,dev-domid property is not present\n");
>> +		goto err;
>> +	}
>>   
>>   	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>>   	if (!data) {
>> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
>> index 4f9fad5..62be9dc 100644
>> --- a/include/xen/xen-ops.h
>> +++ b/include/xen/xen-ops.h
>> @@ -223,10 +223,15 @@ static inline void xen_preemptible_hcall_end(void) { }
>>   
>>   #ifdef CONFIG_XEN_GRANT_DMA_OPS
>>   void xen_grant_setup_dma_ops(struct device *dev);
>> +bool xen_is_grant_dma_device(struct device *dev);
>>   #else
>>   static inline void xen_grant_setup_dma_ops(struct device *dev)
>>   {
>>   }
>> +static inline bool xen_is_grant_dma_device(struct device *dev)
>> +{
>> +	return false;
>> +}
>>   #endif /* CONFIG_XEN_GRANT_DMA_OPS */
>>   
>>   #endif /* INCLUDE_XEN_OPS_H */
>> -- 
>> 2.7.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
-- 
Regards,

Oleksandr Tyshchenko


WARNING: multiple messages have this Message-ID (diff)
From: Oleksandr <olekstysh@gmail.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Juergen Gross <jgross@suse.com>, Julien Grall <julien@xen.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH V1 5/6] xen/grant-dma-ops: Retrieve the ID of backend's domain for DT devices
Date: Sat, 23 Apr 2022 18:23:19 +0300	[thread overview]
Message-ID: <6ac03d9f-a678-60e9-ca6e-fcbe1aee51d3@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2204221534080.915916@ubuntu-linux-20-04-desktop>


On 23.04.22 02:00, Stefano Stabellini wrote:

Hello Stefano

> On Fri, 22 Apr 2022, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Use the presence of recently introduced "xen,dev-domid" property
>> in the device node as a clear indicator of enabling Xen grant
>> mappings scheme for that device and read the ID of Xen domain where
>> the corresponding backend resides. The ID (domid) is used as
>> an argument to the Xen grant mapping APIs.
>>
>> Also introduce xen_is_grant_dma_device() to check whether xen-grant
>> DMA ops need to be set for a passed device.
>>
>> Remove the hardcoded domid 0 in xen_grant_setup_dma_ops().
>>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> ---
>> Changes RFC -> V1:
>>     - new patch, split required changes from commit:
>>      "[PATCH 4/6] virtio: Various updates to xen-virtio DMA ops layer"
>>     - update checks in xen_virtio_setup_dma_ops() to only support
>>       DT devices for now
>>     - remove the "virtio,mmio" check from xen_is_virtio_device()
>>     - remane everything according to the new naming scheme:
>>       s/virtio/grant_dma
>> ---
>>   drivers/xen/grant-dma-ops.c | 25 ++++++++++++++++++-------
>>   include/xen/xen-ops.h       |  5 +++++
>>   2 files changed, 23 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
>> index 0e69aa8..70d5d77 100644
>> --- a/drivers/xen/grant-dma-ops.c
>> +++ b/drivers/xen/grant-dma-ops.c
>> @@ -66,11 +66,6 @@ static struct xen_grant_dma_data *find_xen_grant_dma_data(struct device *dev)
>>    * Such a DMA address is formed by using the grant reference as a frame
>>    * number and setting the highest address bit (this bit is for the backend
>>    * to be able to distinguish it from e.g. a mmio address).
>> - *
>> - * Note that for now we hard wire dom0 to be the backend domain. In order
>> - * to support any domain as backend we'd need to add a way to communicate
>> - * the domid of this backend, e.g. via Xenstore, via the PCI-device's
>> - * config space or DT/ACPI.
>>    */
>>   static void *xen_grant_dma_alloc(struct device *dev, size_t size,
>>   				 dma_addr_t *dma_handle, gfp_t gfp,
>> @@ -277,6 +272,16 @@ static const struct dma_map_ops xen_grant_dma_ops = {
>>   	.dma_supported = xen_grant_dma_supported,
>>   };
>>   
>> +bool xen_is_grant_dma_device(struct device *dev)
>> +{
>> +	/* XXX Handle only DT devices for now */
>> +	if (!dev->of_node)
>> +		return false;
>> +
>> +	return of_property_read_bool(dev->of_node, "xen,dev-domid");
>> +}
>> +EXPORT_SYMBOL_GPL(xen_is_grant_dma_device);
>> +
>>   void xen_grant_setup_dma_ops(struct device *dev)
>>   {
>>   	struct xen_grant_dma_data *data;
>> @@ -288,8 +293,14 @@ void xen_grant_setup_dma_ops(struct device *dev)
>>   		return;
>>   	}
>>   
>> -	/* XXX The dom0 is hardcoded as the backend domain for now */
>> -	dev_domid = 0;
>> +	/* XXX ACPI and PCI devices unsupported for now */
>> +	if (dev_is_pci(dev) || !dev->of_node)
>> +		goto err;
> I think we can remove the "dev_is_pci" check, right?

I think, yes (at least for now). I will remove the inclusion of #include 
<linux/pci.h> as well.


>
>
>> +	if (of_property_read_u32(dev->of_node, "xen,dev-domid", &dev_domid)) {
>> +		dev_err(dev, "xen,dev-domid property is not present\n");
>> +		goto err;
>> +	}
>>   
>>   	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>>   	if (!data) {
>> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
>> index 4f9fad5..62be9dc 100644
>> --- a/include/xen/xen-ops.h
>> +++ b/include/xen/xen-ops.h
>> @@ -223,10 +223,15 @@ static inline void xen_preemptible_hcall_end(void) { }
>>   
>>   #ifdef CONFIG_XEN_GRANT_DMA_OPS
>>   void xen_grant_setup_dma_ops(struct device *dev);
>> +bool xen_is_grant_dma_device(struct device *dev);
>>   #else
>>   static inline void xen_grant_setup_dma_ops(struct device *dev)
>>   {
>>   }
>> +static inline bool xen_is_grant_dma_device(struct device *dev)
>> +{
>> +	return false;
>> +}
>>   #endif /* CONFIG_XEN_GRANT_DMA_OPS */
>>   
>>   #endif /* INCLUDE_XEN_OPS_H */
>> -- 
>> 2.7.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
-- 
Regards,

Oleksandr Tyshchenko


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

  reply	other threads:[~2022-04-23 15:23 UTC|newest]

Thread overview: 79+ 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 ` Oleksandr Tyshchenko
2022-04-22 16:50 ` [PATCH V1 1/6] arm/xen: Introduce xen_setup_dma_ops() Oleksandr Tyshchenko
2022-04-22 16:50   ` Oleksandr Tyshchenko
2022-04-22 22:59   ` Stefano Stabellini
2022-04-22 22:59     ` Stefano Stabellini
2022-04-23 14:35     ` Oleksandr
2022-04-23 14:35       ` Oleksandr
2022-04-23 16:32   ` Christoph Hellwig
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:50   ` 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 16:51   ` Oleksandr Tyshchenko
2022-04-22 23:00   ` Stefano Stabellini
2022-04-22 23:00     ` Stefano Stabellini
2022-04-23  7:05     ` Oleksandr
2022-04-23  7:05       ` Oleksandr
2022-04-23  9:10       ` Juergen Gross
2022-04-23  9:10         ` Juergen Gross
2022-04-23 15:25         ` Oleksandr
2022-04-23 15:25           ` Oleksandr
2022-04-23 16:40   ` Christoph Hellwig
2022-04-23 16:40     ` Christoph Hellwig
2022-04-24 16:53     ` Oleksandr
2022-04-24 16:53       ` Oleksandr
2022-04-24 18:08       ` Boris Ostrovsky
2022-04-24 18:08         ` Boris Ostrovsky
2022-04-25  7:53         ` Juergen Gross
2022-04-25  7:53           ` Juergen Gross
2022-04-25  7:47       ` Juergen Gross
2022-04-25  7:47         ` Juergen Gross
2022-04-25  7:58         ` Christoph Hellwig
2022-04-25  7:58           ` Christoph Hellwig
2022-04-25  9:14           ` Juergen Gross
2022-04-25  9:14             ` Juergen Gross
2022-04-25 20:38             ` Oleksandr
2022-04-25 20:38               ` Oleksandr
2022-04-25 21:25               ` Borislav Petkov
2022-04-25 21:25                 ` Borislav Petkov
2022-04-26  5:16                 ` Juergen Gross
2022-04-26  5:16                   ` Juergen Gross
2022-04-26  8:41                   ` Borislav Petkov
2022-04-26  8:41                     ` Borislav Petkov
2022-04-26  9:36                     ` Juergen Gross
2022-04-26  9:36                       ` Juergen Gross
2022-04-26 11:16                       ` Borislav Petkov
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 16:51   ` [PATCH V1 4/6] dt-bindings: Add xen, dev-domid " Oleksandr Tyshchenko
2022-04-22 23:00   ` Stefano Stabellini
2022-04-22 23:00     ` Stefano Stabellini
2022-04-22 23:00     ` Stefano Stabellini
2022-04-23 14:37     ` Oleksandr
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-02 21:59     ` Rob Herring
2022-05-02 21:59     ` Rob Herring
2022-05-03 17:09     ` Oleksandr
2022-05-03 17:09       ` Oleksandr
2022-05-04  0:02       ` Rob Herring
2022-05-04  0:02         ` Rob Herring
2022-05-04  0:02         ` Rob Herring
2022-05-05 10:12         ` Oleksandr
2022-05-05 10:12           ` Oleksandr
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 16:51   ` Oleksandr Tyshchenko
2022-04-22 23:00   ` Stefano Stabellini
2022-04-22 23:00     ` Stefano Stabellini
2022-04-23 15:23     ` Oleksandr [this message]
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 16:51   ` Oleksandr Tyshchenko
2022-04-22 23:00   ` Stefano Stabellini
2022-04-22 23:00     ` Stefano Stabellini
2022-04-23 16:42   ` Christoph Hellwig
2022-04-23 16:42     ` Christoph Hellwig
2022-04-24 16:07     ` Oleksandr
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=6ac03d9f-a678-60e9-ca6e-fcbe1aee51d3@gmail.com \
    --to=olekstysh@gmail.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=hch@infradead.org \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=sstabellini@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.