On 2020-03-03 18:53, Naresh Kamboju wrote:
On Tue, 3 Mar 2020 at 21:32, Alexandru Elisei alexandru.elisei@arm.com wrote:
Hi,
On 2/25/20 8:20 AM, Naresh Kamboju wrote:
Hi Alexandru,
On Mon, 24 Feb 2020 at 23:14, Naresh Kamboju naresh.kamboju@linaro.org wrote:
I think this is because you are running it on one physical CPU (it's exactly the same message I am getting when I use taskset to run the tests). Can you try and run it without taskset and see if it solves your issue?
We have a new problem when running [1] without taskset on Juno-r2. None of the test got pass [2] when running without taskset on Juno-r2.
I think I have an explanation for why all the tests fail. qemu creates a vcpu to match the host cpu in kvm_arm_create_scratch_host_vcpu and it sets the target to whatever the result of the KVM_ARM_PREFERRED_TARGET ioctl is. If it's run on the little core, the target will be KVM_ARM_TARGET_CORTEX_A53. If it's run on the big core, the target will be KVM_ARM_TARGET_GENERIC_V8. I tried it a few times, and for me it has always been the big core.
The vcpu is created from a different thread by doing a KVM_ARM_VCPU_INIT ioctl and KVM makes sure that the vcpu target matches the target corresponding to the physical CPU the thread is running on. What is happening is that the vcpu thread is run on a little core, so the target as far as KVM is concerned should be KVM_ARM_TARGET_CORTEX_A53, but qemu (correctly) set it to KVM_ARM_TARGET_GENERIC_V8. The ioctl return -EINVAL (-22) and qemu dies.
To get around this, I ran the tests either only on the big cores or on the little cores.
Thanks for explaining in details. I have seen this scenario and defined my test to run only on CPU 0. The CPU 0 on my Juno-r2 devices found to be LITTLE CPU.
big-little? Just say no.
To be clear: this isn't a workaround. big-little is a fundamentally broken paradigm when it comes to virtualization. If you let vcpus roam of different u-archs, you will end-up with unpredictable results. So QEMU does the right thing, and refuses to start a VM in these conditions.
I suggest you drop your Juno at the nearest museum, department of Bad Ideas, and get yourself a sensible machine. Even a RPi4 (cough!) is marginally better.
I also managed to reliably trigger the PMU failures that you are seeing. They only happen when kvm-unit-tests is run on the little cores (ran them 10 times in a loop). When run on the big cores, everything is fine (also ran them 10 times in a loop). Log output when it fails:
Thanks for reproducing this PMU failure.
This one is slightly more convoluted: Nothing in the KVM PMU code expects *two* independent PMUs. What we need is a way to tie a physical PMU to the virtual PMU that gets emulated with perf on the host. I'm working on something similar for SPE, so maybe we can come up with a common approach.
Thanks,
M.