This page contains problems that may be encountered when using QEMU, and their solutions.

If you encounter problems you don't see solutions for on this page, navigate to the Xilinx Developer Forums for additional help.

QEMU CPU stall messages

When running Linux on top of QEMU, Linux can warn about CPU stalls. These stalls can be caused by:

• vCPU in QEMU has hung.
  This is a bug in QEMU, please report it to your Xilinx representative if you encounter this.
• vCPU in QEMU has not been scheduled for enough time and Linux thinks it has hung, when in fact it has not:
  This may be caused by multiple reasons related to vCPUs not getting scheduled to run. For example, due to an overloaded host, or low priority scheduling assignments to QEMU.

Solution

If possible, avoid running QEMU in a Linux VM like Virtualbox. VMs are subject to CPU scheduling by the host (for example Windows).
This adds more scheduling latency, increasing the probability of a vCPU stall.

QEMU failed to connect socket

When running QEMU for a multi-arch environment (for example Zynq UltraScale+ MPSoC or Versal Adaptive SoC), two instances of QEMU are needed and memory needs to be shared between them.
This message can be caused by:

• QEMU being unable to create the socket
  In this case, QEMU will fail to boot.
• QEMU waiting for connection on the socket
  In this case, there should be another message that said "QEMU waiting for connection on: /tmp/socket/path".

Solution

Make sure QEMU has access to the path specified by the -machine-path parameter.

When running a Versal Adaptive SoC machine, QEMU says the machine cannot be found

This typically happens when building QEMU from source and occurs shortly after the guest starts.

In this case, it's usually because QEMU was compiled to use a different encryption library than libgcrypt.

Solution

Reconfigure QEMU with the --enable-gcrypt parameter passed in.

If libgcrypt is not installed, install it and then reconfigure QEMU.

When booting with U-Boot, it boots using an image used in a previous emulation.

When running QEMU for a multi-arch environment, the -machine-path directory keeps a cache of certain things.
In this instance, it caches U-Boot data and it will boot with the previous U-Boot image.

Solution

If using U-Boot, clear the contents in the -machine-path directory between each emulation.

When booting QEMU, the command fails and says "-hw-dtb: invalid option"

This happens when trying to run Xilinx QEMU commands (for example, commands copied when using QEMU with PetaLinux tools) on a different version of QEMU, such as mainline QEMU.
Some options, such as -hw-dtb, are only supported in Xilinx QEMU.

Solution

Use Xilinx QEMU when developing for Xilinx hardware.

When building libsystemctlm-cosim-demo, I see linker errors

Assuming the libsystemctlm-cosim-demo repository and submodules are up-to-date, and the SystemCTLM library source code is configured correctly, this can be caused by a mismatch between C++ versions.

Solution

Make sure the C++ version specified in the SystemCTLM library source code and libsystemctlm-cosim-demo repository are the same.

For example, in the SystemCTLM library source code, do export CXX="g++ -std=c++14" instead of export CXX=g++.

In your .config.mk file in your libsystemctlm-cosim-demo repository, add -std=c++14 to your CXXFLAGS.

QEMU VCK190/VMK180: Increase memory to 16GB via adding 8GB on DDR CH2

By default, QEMU doesn't map the DDR CH2 region@600_0000_0000

Solution

Edit the QEMU VCK190 DTB to add 8GB on DDR CH2, edit here:

https://github.com/Xilinx/qemu-devicetrees/blob/master/board-versal-ps-vck190.dts#L40

Add the following:

MEM_REGION64(ddr_3_ch2, MM_TOP_DDR_CH2_H, MM_TOP_DDR_CH2_L, MM_TOP_DDR_CH2,
			 0x2, 0x0, &ddr_3_mem) // 8 GB

Save the file and rebuild the device-tree's using:

make