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.

> 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?

> 
> I'm fine with merging these and fixing anything up as we go along - this
> is a test harness after all and I don't have time for an in-depth review
> of these patches right now, sorry.

Thanks!
drew
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to