Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1306349 > unrolled thread
| Started by | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| First post | 2016-01-11 15:50 +0100 |
| Last post | 2016-01-15 19:10 +0100 |
| Articles | 8 on this page of 28 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH v12 0/7] dma: add Qualcomm Technologies HIDMA driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-11 15:50 +0100
[PATCH V12 4/7] dma: add Qualcomm Technologies HIDMA channel driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-11 15:50 +0100
[PATCH V12 2/7] dma: hidma: Add Device Tree support Sinan Kaya <okaya@codeaurora.org> - 2016-01-11 15:50 +0100
Re: [PATCH V12 2/7] dma: hidma: Add Device Tree support Mark Rutland <mark.rutland@arm.com> - 2016-01-15 16:20 +0100
Re: [PATCH V12 2/7] dma: hidma: Add Device Tree support Mark Rutland <mark.rutland@arm.com> - 2016-01-15 16:40 +0100
Re: [PATCH V12 2/7] dma: hidma: Add Device Tree support Sinan Kaya <okaya@codeaurora.org> - 2016-01-15 18:10 +0100
Re: [PATCH V12 2/7] dma: hidma: Add Device Tree support Mark Rutland <mark.rutland@arm.com> - 2016-01-18 12:50 +0100
Re: [PATCH V12 2/7] dma: hidma: Add Device Tree support Sinan Kaya <okaya@codeaurora.org> - 2016-01-15 18:00 +0100
Re: [PATCH V12 2/7] dma: hidma: Add Device Tree support Mark Rutland <mark.rutland@arm.com> - 2016-01-18 13:00 +0100
Re: [PATCH V12 2/7] dma: hidma: Add Device Tree support Sinan Kaya <okaya@codeaurora.org> - 2016-01-18 15:10 +0100
[PATCH V12 6/7] dma: qcom_hidma: add debugfs hooks Sinan Kaya <okaya@codeaurora.org> - 2016-01-11 15:50 +0100
[PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-11 15:50 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Mark Rutland <mark.rutland@arm.com> - 2016-01-15 16:10 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-15 16:20 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Mark Rutland <mark.rutland@arm.com> - 2016-01-15 16:30 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-15 18:20 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Marc Zyngier <marc.zyngier@arm.com> - 2016-01-15 18:40 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-15 23:50 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Marc Zyngier <marc.zyngier@arm.com> - 2016-01-18 10:10 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-22 19:40 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Marc Zyngier <marc.zyngier@arm.com> - 2016-01-15 16:20 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Mark Rutland <mark.rutland@arm.com> - 2016-01-15 16:40 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-15 17:10 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-20 23:20 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-15 16:50 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Marc Zyngier <marc.zyngier@arm.com> - 2016-01-15 18:30 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya <okaya@codeaurora.org> - 2016-01-15 18:50 +0100
Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver Marc Zyngier <marc.zyngier@arm.com> - 2016-01-15 19:10 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Date | 2016-01-15 16:20 +0100 |
| Subject | Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver |
| Message-ID | <qRekq-7Xi-27@gated-at.bofh.it> |
| In reply to | #1310203 |
On 15/01/16 14:56, Mark Rutland wrote: > Hi, > > [adding KVM people, given this is meant for virtualization] > > On Mon, Jan 11, 2016 at 09:45:43AM -0500, 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. > > You mention repeatedly that this is designed for virtualization, but > looking at the series as it stands today I can't see how this operates > from the host side. Nor the guest's, TBH. How do host and guest communicate, what is the infrastructure, how is it meant to be used? A lot of questions, and no answer whatsoever in this series. > > 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. > > 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? Well, this looks so far like a code dumping exercise. I'd very much appreciate a HIDMA101 crash course: - How do host and guest communicate? - How is the integration performed in the hypervisor? - Does the HYP side requires any context switch (and how is that done)? - What makes it safe? Without any of this information (and pointer to the code to back it up), I'm very reluctant to take any of this. Thanks, M. -- Jazz is not dead. It just smells funny...
[toc] | [prev] | [next] | [standalone]
| From | Mark Rutland <mark.rutland@arm.com> |
|---|---|
| Date | 2016-01-15 16:40 +0100 |
| Subject | Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver |
| Message-ID | <qReDM-84a-29@gated-at.bofh.it> |
| In reply to | #1310217 |
On Fri, Jan 15, 2016 at 03:14:28PM +0000, Marc Zyngier wrote: > On 15/01/16 14:56, Mark Rutland wrote: > > Hi, > > > > [adding KVM people, given this is meant for virtualization] > > > > On Mon, Jan 11, 2016 at 09:45:43AM -0500, 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. > > > > You mention repeatedly that this is designed for virtualization, but > > looking at the series as it stands today I can't see how this operates > > from the host side. > > Nor the guest's, TBH. How do host and guest communicate, what is the > infrastructure, how is it meant to be used? A lot of questions, and no > answer whatsoever in this series. I think the guest's PoV is fairly simple and understood. The DMA channel is pased in as with any passthrough of any other platform device. No communication with the host is necessary -- an isolated channel is usable. The larger concern is isolation, given the lack of IOMMU, or anything obvious w.r.t. pinning of pages. > > 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. > > > > 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? > > Well, this looks so far like a code dumping exercise. I'd very much > appreciate a HIDMA101 crash course: > > - How do host and guest communicate? > - How is the integration performed in the hypervisor? > - 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. > - What makes it safe? 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? > Without any of this information (and pointer to the code to back it up), > I'm very reluctant to take any of this. Likewise. Thanks, Mark.
[toc] | [prev] | [next] | [standalone]
| From | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| Date | 2016-01-15 17:10 +0100 |
| Subject | Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver |
| Message-ID | <qRf6N-5r-3@gated-at.bofh.it> |
| In reply to | #1310225 |
On 1/15/2016 10:36 AM, Mark Rutland wrote: > On Fri, Jan 15, 2016 at 03:14:28PM +0000, Marc Zyngier wrote: >> On 15/01/16 14:56, Mark Rutland wrote: >>> Hi, >>> >>> [adding KVM people, given this is meant for virtualization] >>> >>> On Mon, Jan 11, 2016 at 09:45:43AM -0500, 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. >>> >>> You mention repeatedly that this is designed for virtualization, but >>> looking at the series as it stands today I can't see how this operates >>> from the host side. >> >> Nor the guest's, TBH. How do host and guest communicate, what is the >> infrastructure, how is it meant to be used? A lot of questions, and no >> answer whatsoever in this series. > > I think the guest's PoV is fairly simple and understood. The DMA channel > is pased in as with any passthrough of any other platform device. > > No communication with the host is necessary -- an isolated channel is > usable. > Correct, I'm behind on emails. I'm following you. > The larger concern is isolation, given the lack of IOMMU, or anything > obvious w.r.t. pinning of pages. > I assume the presence of an IOMMU if used in the guest machine. I wonder if I can place a check and make the driver fail if IOMMU driver is not present. Any ideas? >>> 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. >>> >>> 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? I forgot to mention that these are the only kernel patches. A userspace application is being built as we speak by another team. The userspace application will use sysfs to communicate to the management driver. The management driver knows how to change runtime characteristics like priority and weight. >> >> Well, this looks so far like a code dumping exercise. I'd very much >> appreciate a HIDMA101 crash course: >> >> - How do host and guest communicate? >> - How is the integration performed in the hypervisor? >> - 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. Agreed. > >> - What makes it safe? > > 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 I tried to address your concern on v10 last series. Here is brief summary. Each channel device has a sysfs entry named chid. What: /sys/devices/platform/hidma-*/chid + /sys/devices/platform/QCOM8061:*/chid Each management object has one priority and weight file per channel. +What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority + /sys/devices/platform/QCOM8060:*/chanops/chan*/priority Suppose you want to change the priority of a channel you assigned to guess, the userspace application goes and reads the chid value of the channel. Then goes to chanops/chan<chid>/ directory and can change priority and weight parameters here. Here is how the directory looks like. QCOM8060:00 is a management object. QCOM8061:0x are the channel objects. /sys/devices/platform/QCOM8060:00# ls QCOM8061:00 QCOM8061:01 QCOM8061:02 QCOM8061:03 QCOM8061:04 QCOM8061:05 chanops <other common attributes> > >> Without any of this information (and pointer to the code to back it up), >> I'm very reluctant to take any of this. > > Likewise. > > Thanks, > Mark. > -- 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
[toc] | [prev] | [next] | [standalone]
| From | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| Date | 2016-01-20 23:20 +0100 |
| Subject | Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver |
| Message-ID | <qT9gE-4lI-63@gated-at.bofh.it> |
| In reply to | #1310240 |
Mark, On 1/15/2016 11:01 AM, Sinan Kaya wrote: >> 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 > > I tried to address your concern on v10 last series. Here is brief summary. > > Each channel device has a sysfs entry named chid. > What: /sys/devices/platform/hidma-*/chid > + /sys/devices/platform/QCOM8061:*/chid > > > Each management object has one priority and weight file per channel. > +What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority > + /sys/devices/platform/QCOM8060:*/chanops/chan*/priority > > Suppose you want to change the priority of a channel you assigned to guess, > the userspace application goes and reads the chid value of the channel. > > Then goes to chanops/chan<chid>/ directory and can change priority and weight > parameters here. > > Here is how the directory looks like. QCOM8060:00 is a management object. > QCOM8061:0x are the channel objects. > > /sys/devices/platform/QCOM8060:00# ls > QCOM8061:00 > QCOM8061:01 > QCOM8061:02 > QCOM8061:03 > QCOM8061:04 > QCOM8061:05 > chanops > <other common attributes> > > > > Did this answer your question? I'm capturing all the questions and answers as FAQ into the cover letter as I keep repeating myself for every single reviewer. Besides from the "lack of documentation", is there any code related change you'd like to discuss in the series. -- 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
[toc] | [prev] | [next] | [standalone]
| From | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| Date | 2016-01-15 16:50 +0100 |
| Subject | Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver |
| Message-ID | <qReNs-89q-5@gated-at.bofh.it> |
| In reply to | #1310217 |
On 1/15/2016 10:14 AM, Marc Zyngier wrote: > On 15/01/16 14:56, Mark Rutland wrote: >> Hi, >> >> [adding KVM people, given this is meant for virtualization] >> >> On Mon, Jan 11, 2016 at 09:45:43AM -0500, 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. >> >> You mention repeatedly that this is designed for virtualization, but >> looking at the series as it stands today I can't see how this operates >> from the host side. > > Nor the guest's, TBH. How do host and guest communicate, what is the > infrastructure, how is it meant to be used? A lot of questions, and no > answer whatsoever in this series. I always make an analogy of HIDMA channel driver to a PCI endpoint device driver (8139too for example) running on the guest machine. Both HIDMA and PCI uses device pass-through approach. I don't have an infrastructure for host and guest to communicate as I don't need to. A HIDMA channel is assigned to a guest machine after an unbind from the host machine. Guest machine uses HIDMA channel driver to offload DMA operations. 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. > >> >> 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. >> >> 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? > > Well, this looks so far like a code dumping exercise. I'd very much > appreciate a HIDMA101 crash course: Sure, I'm ready to answer any questions. This is really a VFIO platform course. Not a HIDMA driver course. The approach is not different if you assign a platfom SATA (AHCI) or SDHC driver to a guest machine. The summary is that: - IOMMU takes care of the mappings via VFIO driver. - Guest machine owns the HW. No hypervisor interaction. > > - 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. > > Without any of this information (and pointer to the code to back it up), > I'm very reluctant to take any of this. Please let me know what exactly is not clear. You don't write a virtualization driver for 8139too driver. The driver works whether it is running in the guest machine or the hypervisor. The 8139too driver does not trap to the hypervisor for functionality when used in device pass-through mode. No difference here. > > Thanks, > > M. > -- 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
[toc] | [prev] | [next] | [standalone]
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Date | 2016-01-15 18:30 +0100 |
| Subject | Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver |
| Message-ID | <qRgmf-OC-13@gated-at.bofh.it> |
| In reply to | #1310229 |
On 15/01/16 15:40, Sinan Kaya wrote: > On 1/15/2016 10:14 AM, Marc Zyngier wrote: >> On 15/01/16 14:56, Mark Rutland wrote: >>> Hi, >>> >>> [adding KVM people, given this is meant for virtualization] >>> >>> On Mon, Jan 11, 2016 at 09:45:43AM -0500, 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. >>> >>> You mention repeatedly that this is designed for virtualization, but >>> looking at the series as it stands today I can't see how this operates >>> from the host side. >> >> Nor the guest's, TBH. How do host and guest communicate, what is the >> infrastructure, how is it meant to be used? A lot of questions, and no >> answer whatsoever in this series. > > I always make an analogy of HIDMA channel driver to a PCI endpoint device driver (8139too for example) > running on the guest machine. > > Both HIDMA and PCI uses device pass-through approach. > > I don't have an infrastructure for host and guest to communicate as I don't need to. > A HIDMA channel is assigned to a guest machine after an unbind from the host machine. > > Guest machine uses HIDMA channel driver to offload DMA operations. 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. > >> >>> >>> 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. >>> >>> 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? >> >> Well, this looks so far like a code dumping exercise. I'd very much >> appreciate a HIDMA101 crash course: > > Sure, I'm ready to answer any questions. This is really a VFIO platform course. Not > a HIDMA driver course. The approach is not different if you assign a platfom > SATA (AHCI) or SDHC driver to a guest machine. I happen to have an idea of how VFIO works... > > The summary is that: > - IOMMU takes care of the mappings via VFIO driver. > - Guest machine owns the HW. No hypervisor interaction. Then it might be worth mentioning all of this > >> >> - 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. And what does the hypervisor do with those in the meantime? Above, you say "Guest machine owns the HW". So what is that hypervisor code used for? Is that your reset driver? You may want to drop the "hypervisor" designation, BTW, because this has no real connection to virtualisation. > > 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. > >> >> Without any of this information (and pointer to the code to back it up), >> I'm very reluctant to take any of this. > > Please let me know what exactly is not clear. > > You don't write a virtualization driver for 8139too driver. The driver works whether it is running in the > guest machine or the hypervisor. Exactly. No hypervisor code needed whatsoever. So please get rid of this hypervisor nonsense! ;-) Thanks, M. -- Jazz is not dead. It just smells funny...
[toc] | [prev] | [next] | [standalone]
| From | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| Date | 2016-01-15 18:50 +0100 |
| Subject | Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver |
| Message-ID | <qRgFz-W7-1@gated-at.bofh.it> |
| In reply to | #1310301 |
>> >> Sure, I'm ready to answer any questions. This is really a VFIO platform course. Not >> a HIDMA driver course. The approach is not different if you assign a platfom >> SATA (AHCI) or SDHC driver to a guest machine. > > I happen to have an idea of how VFIO works... > OK. Good to know that we are speaking the same language. >> >> The summary is that: >> - IOMMU takes care of the mappings via VFIO driver. >> - Guest machine owns the HW. No hypervisor interaction. > > Then it might be worth mentioning all of this > Sure thing. I'm trying to locate where the right place would be. I'll target commit message and source code for now. >> >>> >>> - 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. > > And what does the hypervisor do with those in the meantime? Above, you > say "Guest machine owns the HW". The guest machine owns the channel HW which runs independent of the management HW. > 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. Multiple HIDMA channels share common HW resources. The management driver is able to change the priority (high/low) and weight (round-robin priority) of each HIDMA channel on the flight. The system administrator will use a userspace application to allocate HW resources to each channel via the management driver. The management driver does some common configuration too for these parameters. The management interface also has to be enabled before any channel can be enabled. - max-write-burst-bytes: Maximum write burst in bytes that HIDMA can occupy the bus for in a single transaction. A memcpy requested is fragmented to multiples of this amount. This parameter is used while writing into destination memory. Setting this value incorrectly can starve other peripherals in the system. - max-read-burst-bytes: Maximum read burst in bytes that HIDMA can occupy the bus for in a single transaction. A memcpy request is fragmented to multiples of this amount. This parameter is used while reading the source memory. Setting this value incorrectly can starve other peripherals in the system. - max-write-transactions: This value is how many times a write burst is applied back to back while writing to the destination before yielding the bus. - max-read-transactions: This value is how many times a read burst is applied back to back while reading the source before a yielding the bus. - channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC. Once a reset is applied to the HW, HW starts a timer for reset operation to confirm. If reset is not completed within this time, HW reports reset failure. > > You may want to drop the "hypervisor" designation, BTW, because this has > no real connection to virtualisation. > Would you use host/guest relationship? >> >> 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. >> >>> >>> Without any of this information (and pointer to the code to back it up), >>> I'm very reluctant to take any of this. >> >> Please let me know what exactly is not clear. >> >> You don't write a virtualization driver for 8139too driver. The driver works whether it is running in the >> guest machine or the hypervisor. > > Exactly. No hypervisor code needed whatsoever. So please get rid of this > hypervisor nonsense! ;-) > I need the management driver for administrative purposes and common initialization. I like the split SW design as it follows the HW design too. > Thanks, > > M. > -- 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
[toc] | [prev] | [next] | [standalone]
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Date | 2016-01-15 19:10 +0100 |
| Subject | Re: [PATCH V12 3/7] dma: add Qualcomm Technologies HIDMA management driver |
| Message-ID | <qRgYX-1jy-21@gated-at.bofh.it> |
| In reply to | #1310310 |
On 15/01/16 17:44, Sinan Kaya wrote: >>> [...] >> You may want to drop the "hypervisor" designation, BTW, because this has >> no real connection to virtualisation. >> > > Would you use host/guest relationship? Not even that. This is a host/user relationship, as VFIO is in no way virtualisation specific. It just gives you a way to make a device accessible to userspace. KVM is just a specialised instance of a more generic problem. > >>> >>> 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. >>> >>>> >>>> Without any of this information (and pointer to the code to back it up), >>>> I'm very reluctant to take any of this. >>> >>> Please let me know what exactly is not clear. >>> >>> You don't write a virtualization driver for 8139too driver. The driver works whether it is running in the >>> guest machine or the hypervisor. >> >> Exactly. No hypervisor code needed whatsoever. So please get rid of this >> hypervisor nonsense! ;-) >> > > I need the management driver for administrative purposes and common initialization. > I like the split SW design as it follows the HW design too. I have no problem with the split design (whatever floats your boat), more with the terminology which I find very confusing. It would be a lot better if you stuck with management (host) and client (user), or some other general terminology. Thanks, M. -- Jazz is not dead. It just smells funny...
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web