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 in the future. The management driver is executed in host context and is the main management entity for all channels provided by the device. ------------------------ What's new ------------------------ - Add back default number of descriptors. - Fix compilation error in VFIO ACPI support. - Merge the event-channel patch back to DTS and channel driver. ------------------------ Git repos ------------------------ QEMU Support https://www.codeaurora.org/cgit/quic/qemu/qemu/log/?h=v2.5.0-sriov ------------------------ History of Changes ------------------------ dma: hidma: Add Device Tree Binding Changes from V13: (https://lkml.org/lkml/2016/1/29/672) * merged event-channel change. dma: add Qualcomm Technologies HIDMA channel driver Changes from V13: (https://lkml.org/lkml/2016/1/29/685) * add back default descriptor count * merged event-channel change. dma: qcom_hidma: add support for object hierarchy Changes from V13: (https://lkml.org/lkml/2016/1/29/680) * initialize platform info data structure. * configure DMA by calling of_dma_configure. DMA mask was not set when * IOMMU driver is not present for the children devices. vfio, platform: add support for ACPI while detecting the reset driver Changes from V13: (https://lkml.org/lkml/2016/1/29/679) * add forgotten pointer during merge * clarify the driver loading rules in commit message ------------------------ FAQ ------------------------ - 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. - 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. I just rely on the platform VFIO driver to do the work. - How do host and guest communicate, what is the infrastructure, how is HIDMA meant to be used? They don't. Guest machine uses HIDMA channel driver to offload DMA operations in isolation. The guest machine owns the HW registers for the channel. It doesn't need to trap to host for register read/writes etc. All guest machine pages used are assumed to be pinned similar to VFIO PCI. The reason is performance. The IOMMU takes care of the address translation for me. - How do host and guest communicate? They don't. - How is the integration performed in the hypervisor? Hypervisor has a bunch of channel resources. For each guest machine, the channel gets unbound from the hypervisor. Channels get bind to each VFIO platform device and then control is given to the guest machine. Once the guest machine is shutdown, VFIO driver still owns the channel device. It can assign the device to another guest machine. - Does the HYP side requires any context switch (and how is that done)? No communication is needed. - What makes it safe? No communication is needed. - Does the HYP side requires any context switch (and how is that done)? I don't believe this requires any context-switch -- it's the same as assigning any other platform device other than additional proeprties being controlled in the managament interface. - I'm concerned with how this is safe, and with the userspace interface. e.g. if the user wants to up the QoS for a VM, how to they find the right channel in sysfs to alter? The HW supports changing the QoS values on the flight. In order to locate the object, I'm exporting a chid attribute in sysfs. Each management object has one priority and weight file per channel that is indexed by the channel id read from the DMA object. /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority /sys/devices/platform/QCOM8060:*/chanops/chan*/priority - So what is that hypervisor code used for? Is that your reset driver? The HIDMA "management" driver which runs at the hypervisor owns the management HW. Management driver serves two purposes. 1. Common bus parameter configuration (could be called reset driver). 2. Fine tuning the HW resources on the flight. Sinan Kaya (9): dma: qcom_bam_dma: move to qcom directory dma: hidma: Add Device Tree binding dma: add Qualcomm Technologies HIDMA management driver dma: add Qualcomm Technologies HIDMA channel driver dma: qcom_hidma: implement lower level hardware interface dma: qcom_hidma: add debugfs hooks dma: qcom_hidma: add support for object hierarchy vfio, platform: add support for ACPI while detecting the reset driver vfio, platform: add QTI HIDMA reset driver Documentation/ABI/testing/sysfs-platform-hidma | 9 + .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++ .../devicetree/bindings/dma/qcom_hidma_mgmt.txt | 89 ++ drivers/dma/Kconfig | 11 +- drivers/dma/Makefile | 2 +- drivers/dma/qcom/Kconfig | 29 + drivers/dma/qcom/Makefile | 5 + drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 +- drivers/dma/qcom/hidma.c | 746 +++++++++++++++++ drivers/dma/qcom/hidma.h | 162 ++++ drivers/dma/qcom/hidma_dbg.c | 219 +++++ drivers/dma/qcom/hidma_ll.c | 927 +++++++++++++++++++++ drivers/dma/qcom/hidma_mgmt.c | 407 +++++++++ drivers/dma/qcom/hidma_mgmt.h | 39 + drivers/dma/qcom/hidma_mgmt_sys.c | 295 +++++++ drivers/vfio/platform/reset/Kconfig | 9 + drivers/vfio/platform/reset/Makefile | 2 + .../vfio/platform/reset/vfio_platform_amdxgbe.c | 3 +- .../platform/reset/vfio_platform_calxedaxgmac.c | 3 +- .../vfio/platform/reset/vfio_platform_qcomhidma.c | 99 +++ drivers/vfio/platform/vfio_platform_common.c | 80 +- drivers/vfio/platform/vfio_platform_private.h | 41 +- 22 files changed, 3235 insertions(+), 43 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt create mode 100644 drivers/dma/qcom/Kconfig create mode 100644 drivers/dma/qcom/Makefile rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%) create mode 100644 drivers/dma/qcom/hidma.c create mode 100644 drivers/dma/qcom/hidma.h create mode 100644 drivers/dma/qcom/hidma_dbg.c create mode 100644 drivers/dma/qcom/hidma_ll.c create mode 100644 drivers/dma/qcom/hidma_mgmt.c create mode 100644 drivers/dma/qcom/hidma_mgmt.h create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c create mode 100644 drivers/vfio/platform/reset/vfio_platform_qcomhidma.c -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
