Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Sjur, On Thu, Dec 6, 2012 at 9:45 PM, Sjur Brændeland wrote: > I just posted a RFC patch-set on this to linux-kernel@vger.kernel.org. > Review comments is welcomed :-) Great, will take a look, thanks a lot! > I have run into one issue with the dynamically allocated notifyids. When > allocating multiple virtio devices, only ids for the first virtio > device is allocated > when the remote device is started. This is fails for me, because I need to > know > all of the kick-ids before starting the remote device. > > Do you have any preference on how to solve this, Ohad? > > One idea could be to call rproc->start from a work-queue and wait for > completion > of firmware loading before actually starting. In this way we will not > trigger start-up > of the remote device before all virtio devices and their kick-ids are > allocated. Yes, it would work, but I'm not sure it would be very intuitive for others to understand why we spawn a new context upon powering on the processor. Seems to me we may want instead to fix the problem directly by splitting rproc_handle_vdev() to two stages, where the second stage will only include the rproc_add_virtio_dev() part, and will be invoked after all vdev have been processed. Will that work for you ? Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Sjur, On Thu, Dec 6, 2012 at 9:45 PM, Sjur Brændeland sjurb...@gmail.com wrote: I just posted a RFC patch-set on this to linux-kernel@vger.kernel.org. Review comments is welcomed :-) Great, will take a look, thanks a lot! I have run into one issue with the dynamically allocated notifyids. When allocating multiple virtio devices, only ids for the first virtio device is allocated when the remote device is started. This is fails for me, because I need to know all of the kick-ids before starting the remote device. Do you have any preference on how to solve this, Ohad? One idea could be to call rproc-start from a work-queue and wait for completion of firmware loading before actually starting. In this way we will not trigger start-up of the remote device before all virtio devices and their kick-ids are allocated. Yes, it would work, but I'm not sure it would be very intuitive for others to understand why we spawn a new context upon powering on the processor. Seems to me we may want instead to fix the problem directly by splitting rproc_handle_vdev() to two stages, where the second stage will only include the rproc_add_virtio_dev() part, and will be invoked after all vdev have been processed. Will that work for you ? Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Ohad, On Sat, Aug 11, 2012 at 2:34 PM, Ohad Ben-Cohen wrote: > On Fri, Aug 10, 2012 at 6:30 PM, Ohad Ben-Cohen wrote: >> This will solve all sort of open issues we have (or going to have soon): >> ... > 1. dynamically-allocated address of the vrings can be communicated > 2. vdev statuses can be communicated > 3. virtio config space will finally become bi-directional as it should I just posted a RFC patch-set on this to linux-kernel@vger.kernel.org. Review comments is welcomed :-) > and 5. let the remote processor know about the notifyids that we've > dynamically allocated. I have run into one issue with the dynamically allocated notifyids. When allocating multiple virtio devices, only ids for the first virtio device is allocated when the remote device is started. This is fails for me, because I need to know all of the kick-ids before starting the remote device. Do you have any preference on how to solve this, Ohad? One idea could be to call rproc->start from a work-queue and wait for completion of firmware loading before actually starting. In this way we will not trigger start-up of the remote device before all virtio devices and their kick-ids are allocated. Thanks, Sjur -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Ohad, On Sat, Aug 11, 2012 at 2:34 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Fri, Aug 10, 2012 at 6:30 PM, Ohad Ben-Cohen o...@wizery.com wrote: This will solve all sort of open issues we have (or going to have soon): ... 1. dynamically-allocated address of the vrings can be communicated 2. vdev statuses can be communicated 3. virtio config space will finally become bi-directional as it should I just posted a RFC patch-set on this to linux-kernel@vger.kernel.org. Review comments is welcomed :-) and 5. let the remote processor know about the notifyids that we've dynamically allocated. I have run into one issue with the dynamically allocated notifyids. When allocating multiple virtio devices, only ids for the first virtio device is allocated when the remote device is started. This is fails for me, because I need to know all of the kick-ids before starting the remote device. Do you have any preference on how to solve this, Ohad? One idea could be to call rproc-start from a work-queue and wait for completion of firmware loading before actually starting. In this way we will not trigger start-up of the remote device before all virtio devices and their kick-ids are allocated. Thanks, Sjur -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
On Fri, Aug 10, 2012 at 6:30 PM, Ohad Ben-Cohen wrote: > This will solve all sort of open issues we have (or going to have soon): > > 1. dynamically-allocated address of the vrings can be communicated > 2. vdev statuses can be communicated > 3. virtio config space will finally become bi-directional as it should > 4. dynamically probed rproc-to-rproc IPC could then take place and 5. let the remote processor know about the notifyids that we've dynamically allocated. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
On Fri, Aug 10, 2012 at 6:30 PM, Ohad Ben-Cohen o...@wizery.com wrote: This will solve all sort of open issues we have (or going to have soon): 1. dynamically-allocated address of the vrings can be communicated 2. vdev statuses can be communicated 3. virtio config space will finally become bi-directional as it should 4. dynamically probed rproc-to-rproc IPC could then take place and 5. let the remote processor know about the notifyids that we've dynamically allocated. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Sjur, On Thu, Aug 9, 2012 at 11:35 PM, Sjur Brændeland wrote: > Any thoughts on how to go about to fix this? The general direction I have in mind is to put the resource table in its final location while we do the first pass of fw parsing. This will solve all sort of open issues we have (or going to have soon): 1. dynamically-allocated address of the vrings can be communicated 2. vdev statuses can be communicated 3. virtio config space will finally become bi-directional as it should 4. dynamically probed rproc-to-rproc IPC could then take place It's the real deal :) The only problem with this approach is that the resource table isn't reloaded throughout cycles of power up/down, and that is insecure. We'll have to manually reload it somewhere after the rproc is powered down (or before it is powered up again). This change will break existing firmwares, but it looks required and inevitable. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Sjur, On Thu, Aug 9, 2012 at 11:35 PM, Sjur Brændeland sjurb...@gmail.com wrote: Any thoughts on how to go about to fix this? The general direction I have in mind is to put the resource table in its final location while we do the first pass of fw parsing. This will solve all sort of open issues we have (or going to have soon): 1. dynamically-allocated address of the vrings can be communicated 2. vdev statuses can be communicated 3. virtio config space will finally become bi-directional as it should 4. dynamically probed rproc-to-rproc IPC could then take place It's the real deal :) The only problem with this approach is that the resource table isn't reloaded throughout cycles of power up/down, and that is insecure. We'll have to manually reload it somewhere after the rproc is powered down (or before it is powered up again). This change will break existing firmwares, but it looks required and inevitable. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Ohad, >> I realize that we have the same issue with the virtio rings. >> Are there any way we can assign the device address of the virtio rings >> to the resource table in shared memory? > > It's a gap we have today, but it should definitely be fixed. Ok, good. Any thoughts on how to go about to fix this? It does look a more comlex to solve than the carveout, as the vrings are allocated in the first pass of fw parsing, but fw is loaded to device memory in the second pass. Regards, Sjur -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Sjur, On Wed, Aug 8, 2012 at 7:55 PM, Sjur Brændeland wrote: > I realize that we have the same issue with the virtio rings. > Are there any way we can assign the device address of the virtio rings > to the resource table in shared memory? It's a gap we have today, but it should definitely be fixed. > Or do we have to calculate the > virtio ring addresses based on number rings and the number of elements > in the ring? No, that's not the long term intention. It can be used as an interim solution, but I expect we do fix this and start supporting dynamic assignments of the vrings locations at some point. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Sjur, On Wed, Aug 8, 2012 at 7:55 PM, Sjur Brændeland sjurb...@gmail.com wrote: I realize that we have the same issue with the virtio rings. Are there any way we can assign the device address of the virtio rings to the resource table in shared memory? It's a gap we have today, but it should definitely be fixed. Or do we have to calculate the virtio ring addresses based on number rings and the number of elements in the ring? No, that's not the long term intention. It can be used as an interim solution, but I expect we do fix this and start supporting dynamic assignments of the vrings locations at some point. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Ohad, I realize that we have the same issue with the virtio rings. Are there any way we can assign the device address of the virtio rings to the resource table in shared memory? It's a gap we have today, but it should definitely be fixed. Ok, good. Any thoughts on how to go about to fix this? It does look a more comlex to solve than the carveout, as the vrings are allocated in the first pass of fw parsing, but fw is loaded to device memory in the second pass. Regards, Sjur -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Ohad, > Carveout did not set device address when IOMMU is not supported. > Fix this by assigning dma address to device address to carveout > if IOMMU is not supported. I realize that we have the same issue with the virtio rings. Are there any way we can assign the device address of the virtio rings to the resource table in shared memory? Or do we have to calculate the virtio ring addresses based on number rings and the number of elements in the ring? Regards, Sjur -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Ohad, Carveout did not set device address when IOMMU is not supported. Fix this by assigning dma address to device address to carveout if IOMMU is not supported. I realize that we have the same issue with the virtio rings. Are there any way we can assign the device address of the virtio rings to the resource table in shared memory? Or do we have to calculate the virtio ring addresses based on number rings and the number of elements in the ring? Regards, Sjur -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
On Mon, Jul 2, 2012 at 6:14 PM, Ohad Ben-Cohen wrote: > On Mon, Jul 2, 2012 at 6:11 PM, Sjur BRENDELAND > wrote: >>> To simplify things, will the below work for you? >> >> Looks good, feel free to add my Acked-by > > Thanks! I'll queue it up for 3.6. Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
On Mon, Jul 2, 2012 at 6:14 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Mon, Jul 2, 2012 at 6:11 PM, Sjur BRENDELAND sjur.brandel...@stericsson.com wrote: To simplify things, will the below work for you? Looks good, feel free to add my Acked-by Thanks! I'll queue it up for 3.6. Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
