Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1270314 > unrolled thread

Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver Arnd Bergmann <arnd@arndb.de> - 2015-11-16 17:00 +0100
    Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management  driver Sinan Kaya <okaya@codeaurora.org> - 2015-11-16 17:30 +0100
    Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management  driver Sinan Kaya <okaya@codeaurora.org> - 2015-11-21 19:50 +0100

#1270314 — Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver

On Sunday 15 November 2015 15:54:13 Sinan Kaya wrote:
> The Qualcomm Technologies HIDMA device has been designed
> to support virtualization technology. The driver has been
> divided into two to follow the hardware design.
> 
> 1. HIDMA Management driver
> 2. HIDMA Channel driver
> 
> Each HIDMA HW consists of multiple channels. These channels
> share some set of common parameters. These parameters are
> initialized by the management driver during power up.
> Same management driver is used for monitoring the execution
> of the channels. Management driver can change the performance
> behavior dynamically such as bandwidth allocation and
> prioritization.
> 
> The management driver is executed in hypervisor context and
> is the main management entity for all channels provided by
> the device.

Sorry for asking this question so late, but can you explain what the
point is behind this? It seems counterintuitive to me to have a
DMA engine that is meant for speeding up memory-to-memory transfers
when you run it in a virtual machine where you either need to go
through a virtual IOMMU to set up page table entries, as that will
likely cause more performance overhead than you could possibly
gain, or you assume that all the guest memory is pinned, which
in turn destroys a lot of the assumptions that we are making
in KVM to have useful VM guests.

Where am I going wrong here?

>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    |  61 ++++
>  drivers/dma/qcom/Kconfig                           |  10 +
>  drivers/dma/qcom/Makefile                          |   1 +
>  drivers/dma/qcom/hidma_mgmt.c                      | 306 +++++++++++++++++++++
>  drivers/dma/qcom/hidma_mgmt.h                      |  38 +++
>  drivers/dma/qcom/hidma_mgmt_sys.c                  | 231 ++++++++++++++++

Each sysfs file API you add needs a documentation in Documentation/ABI/.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1270336 — Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver

On 11/16/2015 10:58 AM, Arnd Bergmann wrote:
>> The management driver is executed in hypervisor context and
>> > is the main management entity for all channels provided by
>> > the device.
> Sorry for asking this question so late, but can you explain what the
> point is behind this? It seems counterintuitive to me to have a
> DMA engine that is meant for speeding up memory-to-memory transfers
> when you run it in a virtual machine where you either need to go
> through a virtual IOMMU to set up page table entries, as that will
> likely cause more performance overhead than you could possibly
> gain, or you assume that all the guest memory is pinned, which
> in turn destroys a lot of the assumptions that we are making
> in KVM to have useful VM guests.
> 
> Where am I going wrong here?
> 

The behavior of HIDMA is not any different from PCIe. We are using
platform device pass through and giving the control of the entire HIDMA
device to the guest machine. Therefore, we don’t need to trap into host
machine for driver execution.

I agree with the fact that the pages need to be pinned for this to work.
Again, this is not any different from PCIe SRIOV passthrough.

Pinning guest removes use cases like ballooning/overcommit but that is a
choice for end user to make: whether he wants additional I/O performance
or wants higher memory utilization at the cost of lower I/O performance.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274730 — Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver

On 11/16/2015 10:58 AM, Arnd Bergmann wrote:

>>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    |  61 ++++
>>  drivers/dma/qcom/Kconfig                           |  10 +
>>  drivers/dma/qcom/Makefile                          |   1 +
>>  drivers/dma/qcom/hidma_mgmt.c                      | 306 +++++++++++++++++++++
>>  drivers/dma/qcom/hidma_mgmt.h                      |  38 +++
>>  drivers/dma/qcom/hidma_mgmt_sys.c                  | 231 ++++++++++++++++
> 
> Each sysfs file API you add needs a documentation in Documentation/ABI/.
> 
> 	Arnd
> 

I'm working on the sysfs documentation now.

Is there any other question regarding the patch series?

If not, I'd like to have a reviewed-by after the next post if acceptable.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web