[Sound-open-firmware] DSP VM to x86 VM communication in QEMU
I'm looking into implementing a feature to allow mapping shared memory in a VM host into a guest for audio playback.
I've seen there's some related work in SoF's qemu repo for communicating between an x86 VM and a DSP VM, and I was wondering if anyone had more context/documentation on those features?
Thanks, Fletcher
On Tue, 2019-04-09 at 10:15 -0600, Fletcher Woodruff wrote:
I'm looking into implementing a feature to allow mapping shared memory in a VM host into a guest for audio playback.
I've seen there's some related work in SoF's qemu repo for communicating between an x86 VM and a DSP VM, and I was wondering if anyone had more context/documentation on those features?
Hi Fletcher,
Documentation for SOF QEMU is quite sparse or probably even non- existent.
If you'd like to get a jump start, I'd recommend looking into the qemu- check.sh script in the SOF repo. It has some instructions on how to start the qemu, load the FW and check for boot success.
Thanks, Ranjani
Thanks, Fletcher _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Wed, 2019-04-10 at 14:43 -0700, Ranjani Sridharan wrote:
On Tue, 2019-04-09 at 10:15 -0600, Fletcher Woodruff wrote:
I'm looking into implementing a feature to allow mapping shared memory in a VM host into a guest for audio playback.
I've seen there's some related work in SoF's qemu repo for communicating between an x86 VM and a DSP VM, and I was wondering if anyone had more context/documentation on those features?
Hi Fletcher,
Documentation for SOF QEMU is quite sparse or probably even non- existent.
If you'd like to get a jump start, I'd recommend looking into the qemu- check.sh script in the SOF repo. It has some instructions on how to start the qemu, load the FW and check for boot success.
The old qemu instructions from alsa-project have not yet been carried over to sof-project. I need to do this alongside other doc updates. Old instructions are here:-
https://www.alsa-project.org/main/index.php/Firmware#Using_the_Qemu_DSP_emul...
These instructions are out of date, so you may find that other qemu dependencies are needed to build. Host (x86) side is not yet supported for SKL on wards atm (needs code to hook into qemu HDA core), but xtensa DSP is supported on all platforms.
Liam
Hi,
On Mon, 15 Apr 2019, Liam Girdwood wrote:
https://www.alsa-project.org/main/index.php/Firmware#Using_the_Qemu_DSP_emul...
These instructions are out of date, so you may find that other qemu dependencies are needed to build. Host (x86) side is not yet supported for SKL on wards atm (needs code to hook into qemu HDA core), but xtensa DSP is supported on all platforms.
I can verify the DSP side is functional and I could set up an environment following the wiki and run latest and greatest FW from SOF mainline.
There is some regression with host side though, even when trying to use older targets than SKL. I reverted the SOF qemu branch to v1.2 level and ta-daa, I got both sides working (with latest driver and fw, BYT target).
I'll next bisect the commits since v1.2 to see where it broke down.
Br, Kai
On Tue, Apr 16, 2019 at 8:25 AM Kai Vehmanen kai.vehmanen@linux.intel.com wrote:
Hi,
On Mon, 15 Apr 2019, Liam Girdwood wrote:
https://www.alsa-project.org/main/index.php/Firmware#Using_the_Qemu_DSP_emul...
These instructions are out of date, so you may find that other qemu dependencies are needed to build. Host (x86) side is not yet supported for SKL on wards atm (needs code to hook into qemu HDA core), but xtensa DSP is supported on all platforms.
I can verify the DSP side is functional and I could set up an environment following the wiki and run latest and greatest FW from SOF mainline.
There is some regression with host side though, even when trying to use older targets than SKL. I reverted the SOF qemu branch to v1.2 level and ta-daa, I got both sides working (with latest driver and fw, BYT target).
I'll next bisect the commits since v1.2 to see where it broke down.
Thanks Kai,
For context, the Chrome OS team is evaluating reusing the interface from the DSP side to improve audio latency and capability for our guest VMs.
Cheers,
Dylan
On Tue, 2019-04-16 at 11:48 -0700, Dylan Reid wrote:
On Tue, Apr 16, 2019 at 8:25 AM Kai Vehmanen kai.vehmanen@linux.intel.com wrote:
Hi,
On Mon, 15 Apr 2019, Liam Girdwood wrote:
https://www.alsa-project.org/main/index.php/Firmware#Using_the_Qemu_DSP_emul...
These instructions are out of date, so you may find that other qemu dependencies are needed to build. Host (x86) side is not yet supported for SKL on wards atm (needs code to hook into qemu HDA core), but xtensa DSP is supported on all platforms.
I can verify the DSP side is functional and I could set up an environment following the wiki and run latest and greatest FW from SOF mainline.
There is some regression with host side though, even when trying to use older targets than SKL. I reverted the SOF qemu branch to v1.2 level and ta-daa, I got both sides working (with latest driver and fw, BYT target).
I'll next bisect the commits since v1.2 to see where it broke down.
Thanks Kai,
For context, the Chrome OS team is evaluating reusing the interface from the DSP side to improve audio latency and capability for our guest VMs.
Hi Dylan,
We're working on getting the topology loaded on the QEMU DSP at the moment. Not sure if it is needed for your purpose but if you want to measure audio latency, I suppose it might be. I will post the patches as soon as the work is complete.
Thanks, Ranjani
Cheers,
Dylan _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Tue, 2019-04-16 at 18:26 +0300, Kai Vehmanen wrote:
Hi,
On Mon, 15 Apr 2019, Liam Girdwood wrote:
https://www.alsa-project.org/main/index.php/Firmware#Using_the_Qemu_DSP_emul...
These instructions are out of date, so you may find that other qemu dependencies are needed to build. Host (x86) side is not yet supported for SKL on wards atm (needs code to hook into qemu HDA core), but xtensa DSP is supported on all platforms.
I can verify the DSP side is functional and I could set up an environment following the wiki and run latest and greatest FW from SOF mainline.
There is some regression with host side though, even when trying to use older targets than SKL. I reverted the SOF qemu branch to v1.2 level and ta-daa, I got both sides working (with latest driver and fw, BYT target).
I'll next bisect the commits since v1.2 to see where it broke down.
Fwiw, Ranjani and I have also found that some of the Posix IPC e.g. threads, SHM, message queues (not FW IPC) between the qemu VMs may not been following the correct close/shutdown programming flow. This means subsequent qemu invocations were not always working. This was found as part of the FW IPC fuzzer work.
Btw, if interested in fuzzer, see lrg/topic/fuzzer branch on sof git for WIP fuzzer code.
Liam
On Wed, 2019-04-17 at 10:21 +0100, Liam Girdwood wrote:
On Tue, 2019-04-16 at 18:26 +0300, Kai Vehmanen wrote:
Hi,
On Mon, 15 Apr 2019, Liam Girdwood wrote:
https://www.alsa-project.org/main/index.php/Firmware#Using_the_Qemu_DSP_emul...
These instructions are out of date, so you may find that other qemu dependencies are needed to build. Host (x86) side is not yet supported for SKL on wards atm (needs code to hook into qemu HDA core), but xtensa DSP is supported on all platforms.
I can verify the DSP side is functional and I could set up an environment following the wiki and run latest and greatest FW from SOF mainline.
There is some regression with host side though, even when trying to use older targets than SKL. I reverted the SOF qemu branch to v1.2 level and ta-daa, I got both sides working (with latest driver and fw, BYT target).
I'll next bisect the commits since v1.2 to see where it broke down.
Fwiw, Ranjani and I have also found that some of the Posix IPC e.g. threads, SHM, message queues (not FW IPC) between the qemu VMs may not been following the correct close/shutdown programming flow. This means subsequent qemu invocations were not always working. This was found as part of the FW IPC fuzzer work.
Btw, if interested in fuzzer, see lrg/topic/fuzzer branch on sof git for WIP fuzzer code.
Just a quick clarification that the "fuzzing" part is not there on the branch yet but we're actively working on it and will be pushed soon.
Thanks, Ranjani
Liam
participants (5)
-
Dylan Reid -
Fletcher Woodruff -
Kai Vehmanen -
Liam Girdwood -
Ranjani Sridharan