linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: okaya@codeaurora.org (Sinan Kaya)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver
Date: Mon, 16 Nov 2015 11:25:35 -0500	[thread overview]
Message-ID: <564A037F.602@codeaurora.org> (raw)
In-Reply-To: <6159200.u9U0p8aIkU@wuerfel>

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

  reply	other threads:[~2015-11-16 16:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-15 20:54 [PATCH V5 0/3] add Qualcomm Technologies HIDMA driver Sinan Kaya
2015-11-15 20:54 ` [PATCH V5 1/3] dma: qcom_bam_dma: move to qcom directory Sinan Kaya
2015-11-15 20:54 ` [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya
2015-11-16 15:58   ` Arnd Bergmann
2015-11-16 16:25     ` Sinan Kaya [this message]
2015-11-21 18:43     ` Sinan Kaya
2015-11-15 20:54 ` [PATCH V5 3/3] dma: add Qualcomm Technologies HIDMA channel driver Sinan Kaya

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=564A037F.602@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.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).