On Thu, Feb 26, 2015 at 02:50:38PM +0100, Andrew Jones wrote:
> On Thu, Feb 26, 2015 at 12:34:02PM +0100, Christoffer Dall wrote:
> > On Sun, Feb 01, 2015 at 07:34:28PM +0100, Andrew Jones wrote:
> > > This series extends the kvm-unit-tests/arm[64] framework to support smp.
> > > A break down of the patches is as follows
> > >
> > > 01-02: prepare general framework for smp use
> > > 03-06: arm/arm64 fixups not 100% related to this series,
> > > but need to post some time...
> > > 07-09: add thread_info (for per-thread data) and suck some global
> > > data into it
> > > 10-11: add cpumask support (for per-cpu data) and suck some more
> > > global data in
> > > 12: add arm64 simple spinlock implementation
> > > 13-14: add some PSCI support
> > > 15-16: further prep for smp_boot_secondary
> > > 17: finally add smp_boot_secondary
> > > 18: as usual, add a selftest to make sure it all works
> > >
> > > These patches are also available here:
> > > https://github.com/rhdrjones/kvm-unit-tests/tree/arm/smp
> > >
> > I've tested these patches on Juno and they seem to run fine, however,
> > since we don't support big.LITTLE yet, you have to run them under
> > 'taskset <mask>', but the config script uses $(getconf
> > _NPROCESSORS_CONF), which returns 6, and QEMU fails. The interesting
>
> Should I try to read the number of host cpus from some other source?
> If you know something I can read that also works on big.LITTLE, then
> I can change it now.
>
I have no idea what the right scripting fix would be. But we should
really fix big.LITTLE support in KVM. Hmmm.
> > bit is that the unit-tests still report 'PASS' - not sure why.
>
> Ah, this is due to the weird way qemu's debugexit device sets its exit
> code
>
> hw/misc/debugexit.c:debug_exit_write()
> {
> exit((val << 1) | 1);
> }
>
> To be consistent with that we made chr-testdev do the same thing (see
> backends/testdev.c:testdev_eat_packet():case 'q'). Now, the
> kvm-unit-tests run_tests.sh script knows about that, so it has
>
> eval $cmdline >> test.log
> if [ $? -le 1 ]; then
> echo -e "\e[32mPASS\e[0m $1"
> else
> echo -e "\e[31mFAIL\e[0m $1"
> fi
>
> Yes, this sucks, as we can't tell the difference between qemu failing
> to run the test, and exiting with 1 vs. the test running, passing -
> exiting with (0 << 1) | 1. It's too bad debugexit didn't set a higher
> bit (like 5 or 6) to flag a "debug exit". Maybe it's not too late to
> change it? Paolo?
>
This would be really good to address somehow, because we don't want
to report that everything is happy when the test harness broke, that
really goes against the whole idea of this work.
Thanks,
-Christoffer
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
