On 2020-03-03 18:53, Naresh Kamboju wrote:
On Tue, 3 Mar 2020 at 21:32, Alexandru Elisei
<alexandru.elisei@xxxxxxx> 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@xxxxxxxxxx> 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.
--
Jazz is not dead. It just smells funny...
