All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
To: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	agross-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	arnd-r2nGTMty4D4@public.gmane.org,
	linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org,
	christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	shankerd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	Vikram Sethi <vikrams-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Subject: Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver
Date: Fri, 15 Jan 2016 17:32:06 +0000	[thread overview]
Message-ID: <56992D16.6070800@arm.com> (raw)
In-Reply-To: <56992987.5080603-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

On 15/01/16 17:16, Sinan Kaya wrote:
>>>> This doesn't seem to tie into KVM or VFIO, and as far as I can tell
>>>> there's no mechanism for associating channels with a particular virtual
>>>> address space (i.e. no configuration of an external or internal IOMMU),
>>>> nor pinning of guest pages to allow for DMA to occur safely.
>>>
>>> I'm using VFIO platform driver for this purpose. VFIO platform driver is 
>>> capable of assigning any platform device to a guest machine with this driver. 
>>
>> Typically VFIO-platform also comes with a corresponding reset driver.
>> You don't need one?
> 
> The HIDMA channel driver resets the channel before using it. That's why, I never
> bothered with writing a reset driver on the hypervisor.
> 
>>
>>> You just unbind the HIDMA channel driver from the hypervisor and bind to vfio
>>> driver using the very same approach you'd use with PCIe. 
>>>
>>> Of course, this all assumes the presence of an IOMMU driver on the system. VFIO
>>> driver uses the IOMMU driver to create the mappings. 
>>
>> No IOMMU was described in the DT binding. It sounds like you'd need an
>> optional (not present in the guest) iommus property per-channel
> 
> You are right. I missed that part. I'll update the device-tree binding documentation.
> 
>>
>>> The mechanism used here is not different from VFIO PCI from user perspective.
>>>
>>>>
>>>> Given that, I'm at a loss as to how this would be used in a hypervisor
>>>> context. What am I missing?
>>>>
>>>> Are there additional patches, or do you have some userspace that works
>>>> with this in some limited configuration?
>>>
>>> No, these are the only patches. We have one patch for the QEMU but from kernel
>>> perspective this is it. 
>>
>> Do you have a link to that? Seeing it would help to ease my concerns.
> 
> The QEMU driver has not been posted yet. As far as I know, it just discovers the memory
> resources on the platform object and creates mappings for the guest machine only. 
> 
> Shanker Donthineni and Vikram Sethi will post the QEMU patch later.

Then may I suggest you both synchronize your submissions? I'd really
like to hear from the QEMU maintainers that they are satisfied with that
side of the story as well.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver
Date: Fri, 15 Jan 2016 17:32:06 +0000	[thread overview]
Message-ID: <56992D16.6070800@arm.com> (raw)
In-Reply-To: <56992987.5080603@codeaurora.org>

On 15/01/16 17:16, Sinan Kaya wrote:
>>>> This doesn't seem to tie into KVM or VFIO, and as far as I can tell
>>>> there's no mechanism for associating channels with a particular virtual
>>>> address space (i.e. no configuration of an external or internal IOMMU),
>>>> nor pinning of guest pages to allow for DMA to occur safely.
>>>
>>> I'm using VFIO platform driver for this purpose. VFIO platform driver is 
>>> capable of assigning any platform device to a guest machine with this driver. 
>>
>> Typically VFIO-platform also comes with a corresponding reset driver.
>> You don't need one?
> 
> The HIDMA channel driver resets the channel before using it. That's why, I never
> bothered with writing a reset driver on the hypervisor.
> 
>>
>>> You just unbind the HIDMA channel driver from the hypervisor and bind to vfio
>>> driver using the very same approach you'd use with PCIe. 
>>>
>>> Of course, this all assumes the presence of an IOMMU driver on the system. VFIO
>>> driver uses the IOMMU driver to create the mappings. 
>>
>> No IOMMU was described in the DT binding. It sounds like you'd need an
>> optional (not present in the guest) iommus property per-channel
> 
> You are right. I missed that part. I'll update the device-tree binding documentation.
> 
>>
>>> The mechanism used here is not different from VFIO PCI from user perspective.
>>>
>>>>
>>>> Given that, I'm at a loss as to how this would be used in a hypervisor
>>>> context. What am I missing?
>>>>
>>>> Are there additional patches, or do you have some userspace that works
>>>> with this in some limited configuration?
>>>
>>> No, these are the only patches. We have one patch for the QEMU but from kernel
>>> perspective this is it. 
>>
>> Do you have a link to that? Seeing it would help to ease my concerns.
> 
> The QEMU driver has not been posted yet. As far as I know, it just discovers the memory
> resources on the platform object and creates mappings for the guest machine only. 
> 
> Shanker Donthineni and Vikram Sethi will post the QEMU patch later.

Then may I suggest you both synchronize your submissions? I'd really
like to hear from the QEMU maintainers that they are satisfied with that
side of the story as well.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: Sinan Kaya <okaya@codeaurora.org>, Mark Rutland <mark.rutland@arm.com>
Cc: dmaengine@vger.kernel.org, timur@codeaurora.org,
	devicetree@vger.kernel.org, cov@codeaurora.org,
	vinod.koul@intel.com, jcm@redhat.com, agross@codeaurora.org,
	arnd@arndb.de, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	christoffer.dall@linaro.org, shankerd@codeaurora.org,
	Vikram Sethi <vikrams@codeaurora.org>
Subject: Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver
Date: Fri, 15 Jan 2016 17:32:06 +0000	[thread overview]
Message-ID: <56992D16.6070800@arm.com> (raw)
In-Reply-To: <56992987.5080603@codeaurora.org>

On 15/01/16 17:16, Sinan Kaya wrote:
>>>> This doesn't seem to tie into KVM or VFIO, and as far as I can tell
>>>> there's no mechanism for associating channels with a particular virtual
>>>> address space (i.e. no configuration of an external or internal IOMMU),
>>>> nor pinning of guest pages to allow for DMA to occur safely.
>>>
>>> I'm using VFIO platform driver for this purpose. VFIO platform driver is 
>>> capable of assigning any platform device to a guest machine with this driver. 
>>
>> Typically VFIO-platform also comes with a corresponding reset driver.
>> You don't need one?
> 
> The HIDMA channel driver resets the channel before using it. That's why, I never
> bothered with writing a reset driver on the hypervisor.
> 
>>
>>> You just unbind the HIDMA channel driver from the hypervisor and bind to vfio
>>> driver using the very same approach you'd use with PCIe. 
>>>
>>> Of course, this all assumes the presence of an IOMMU driver on the system. VFIO
>>> driver uses the IOMMU driver to create the mappings. 
>>
>> No IOMMU was described in the DT binding. It sounds like you'd need an
>> optional (not present in the guest) iommus property per-channel
> 
> You are right. I missed that part. I'll update the device-tree binding documentation.
> 
>>
>>> The mechanism used here is not different from VFIO PCI from user perspective.
>>>
>>>>
>>>> Given that, I'm at a loss as to how this would be used in a hypervisor
>>>> context. What am I missing?
>>>>
>>>> Are there additional patches, or do you have some userspace that works
>>>> with this in some limited configuration?
>>>
>>> No, these are the only patches. We have one patch for the QEMU but from kernel
>>> perspective this is it. 
>>
>> Do you have a link to that? Seeing it would help to ease my concerns.
> 
> The QEMU driver has not been posted yet. As far as I know, it just discovers the memory
> resources on the platform object and creates mappings for the guest machine only. 
> 
> Shanker Donthineni and Vikram Sethi will post the QEMU patch later.

Then may I suggest you both synchronize your submissions? I'd really
like to hear from the QEMU maintainers that they are satisfied with that
side of the story as well.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  parent reply	other threads:[~2016-01-15 17:32 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-11 14:45 [PATCH v12 0/7] dma: add Qualcomm Technologies HIDMA driver Sinan Kaya
2016-01-11 14:45 ` Sinan Kaya
2016-01-11 14:45 ` [PATCH V12 1/7] dma: qcom_bam_dma: move to qcom directory Sinan Kaya
2016-01-11 14:45   ` Sinan Kaya
2016-01-11 14:45   ` Sinan Kaya
2016-01-11 14:45 ` [PATCH V12 2/7] dma: hidma: Add Device Tree support Sinan Kaya
2016-01-11 14:45   ` Sinan Kaya
2016-01-11 14:45   ` Sinan Kaya
2016-01-15 15:16   ` Mark Rutland
2016-01-15 15:16     ` Mark Rutland
2016-01-15 15:30     ` Mark Rutland
2016-01-15 15:30       ` Mark Rutland
2016-01-15 17:05       ` Sinan Kaya
2016-01-15 17:05         ` Sinan Kaya
2016-01-18 11:39         ` Mark Rutland
2016-01-18 11:39           ` Mark Rutland
2016-01-15 16:49     ` Sinan Kaya
2016-01-15 16:49       ` Sinan Kaya
     [not found]       ` <5699232E.60809-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-01-18 11:49         ` Mark Rutland
2016-01-18 11:49           ` Mark Rutland
2016-01-18 11:49           ` Mark Rutland
2016-01-18 14:04           ` Sinan Kaya
2016-01-18 14:04             ` Sinan Kaya
2016-01-11 14:45 ` [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya
2016-01-11 14:45   ` Sinan Kaya
2016-01-15 14:56   ` Mark Rutland
2016-01-15 14:56     ` Mark Rutland
2016-01-15 14:56     ` Mark Rutland
2016-01-15 15:12     ` Sinan Kaya
2016-01-15 15:12       ` Sinan Kaya
2016-01-15 15:12       ` Sinan Kaya
2016-01-15 15:22       ` Mark Rutland
2016-01-15 15:22         ` Mark Rutland
2016-01-15 15:22         ` Mark Rutland
2016-01-15 17:16         ` Sinan Kaya
2016-01-15 17:16           ` Sinan Kaya
     [not found]           ` <56992987.5080603-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-01-15 17:32             ` Marc Zyngier [this message]
2016-01-15 17:32               ` Marc Zyngier
2016-01-15 17:32               ` Marc Zyngier
2016-01-15 22:47               ` Sinan Kaya
2016-01-15 22:47                 ` Sinan Kaya
2016-01-15 22:47                 ` Sinan Kaya
2016-01-18  9:06                 ` Marc Zyngier
2016-01-18  9:06                   ` Marc Zyngier
2016-01-18  9:06                   ` Marc Zyngier
2016-01-22 18:38         ` Sinan Kaya
2016-01-22 18:38           ` Sinan Kaya
2016-01-22 18:38           ` Sinan Kaya
2016-01-15 15:14     ` Marc Zyngier
2016-01-15 15:14       ` Marc Zyngier
2016-01-15 15:14       ` Marc Zyngier
2016-01-15 15:36       ` Mark Rutland
2016-01-15 15:36         ` Mark Rutland
2016-01-15 16:01         ` Sinan Kaya
2016-01-15 16:01           ` Sinan Kaya
2016-01-15 16:01           ` Sinan Kaya
2016-01-20 22:18           ` Sinan Kaya
2016-01-20 22:18             ` Sinan Kaya
2016-01-20 22:18             ` Sinan Kaya
2016-01-15 15:40       ` Sinan Kaya
2016-01-15 15:40         ` Sinan Kaya
2016-01-15 15:40         ` Sinan Kaya
     [not found]         ` <569912F3.9040507-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-01-15 17:28           ` Marc Zyngier
2016-01-15 17:28             ` Marc Zyngier
2016-01-15 17:28             ` Marc Zyngier
2016-01-15 17:44             ` Sinan Kaya
2016-01-15 17:44               ` Sinan Kaya
2016-01-15 18:08               ` Marc Zyngier
2016-01-15 18:08                 ` Marc Zyngier
2016-01-11 14:45 ` [PATCH V12 4/7] dma: add Qualcomm Technologies HIDMA channel driver Sinan Kaya
2016-01-11 14:45   ` Sinan Kaya
2016-01-11 14:45 ` [PATCH V12 5/7] dma: qcom_hidma: implement lower level hardware interface Sinan Kaya
2016-01-11 14:45   ` Sinan Kaya
2016-01-11 14:45 ` [PATCH V12 6/7] dma: qcom_hidma: add debugfs hooks Sinan Kaya
2016-01-11 14:45   ` Sinan Kaya
2016-01-11 14:45 ` [PATCH V12 7/7] dma: qcom_hidma: add support for object hierarchy Sinan Kaya
2016-01-11 14:45   ` 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=56992D16.6070800@arm.com \
    --to=marc.zyngier-5wv7dgnigg8@public.gmane.org \
    --cc=agross-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=shankerd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=vikrams-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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.