On Wed, Mar 22, 2017 at 06:27:20PM +0100, Thomas Huth wrote:
> On 22.03.2017 16:20, Laurent Vivier wrote:
> > On 22/03/2017 09:28, Thomas Huth wrote:
> >> Here's a KVM-unit-test to check the persistency of SPRs during migration.
> >> First patch adds a helper script for doing migration tests in the
> >> kvm-unit-test framework, and the second patch contains the SPR tester.
> >>
> >> v4:
> >> - Fix the error paths in run_migration() - use "exit 2" instead of "exit 1"
> >> to avoid trouble with the return code magic in the powerpc/run script
> >> and make sure to terminate the two QEMU instances in case of migration
> >> failure.
> >>
> >> v3:
> >> - Migration shell script code has been moved to a helper function in
> >> arch-run.bash, so that this now also works with the standalone tests.
> >> - Introduced the helper function migration_cmd there, too, so that other
> >> architectures can use this, too.
> >> - Use "$@" instead of $* when calling QEMU.
> >>
> >> v2:
> >> - Addressed review feedback from v1
> >> - Now using cpu_relax() instead of asm volatile ("nop")
> >>
> >> Thomas Huth (2):
> >> Add the possibility to do simple migration tests
> >> powerpc: Add Special Purpose Register persistency test
> >>
> >> powerpc/Makefile.common | 3 +-
> >> powerpc/cstart64.S | 2 +
> >> powerpc/run | 2 +-
> >> powerpc/sprs.c | 304 ++++++++++++++++++++++++++++++++++++++++++++++++
> >> powerpc/unittests.cfg | 5 +
> >> scripts/arch-run.bash | 63 ++++++++++
> >> scripts/runtime.bash | 3 +
> >> 7 files changed, 380 insertions(+), 2 deletions(-)
> >> create mode 100644 powerpc/sprs.c
> >>
> >
> > Really nice work.
> >
> > I've tested with TCG and KVM HV and it works fine.
> >
> > It hangs with KVM PR, but I have an "emulation at f60 failed (00000000)"
> > in kernel logs, did you see that?
>
> Yes, it's because KVM-PR does not support some of the SPRs yet and
> apparently always injects a program exception in that case. So there is
> something left to do for KVM-PR here...
>
> I think KVM-PR should not inject a program interrupt here, since
> according to the PowerISA (v2.07), the mtspr/mfspr should be treated as
> no-op for unknown SPRs when the CPU is not running in PRoblem state...
I agree, let's fix it.
I did try to fix it some time ago, but at that stage Alex Graf didn't
want to change the behaviour (I think because he thought the existing
behaviour was better for debugging). However, we could have the
architecturally correct behaviour but still have a way to log the
unimplemented SPR accesses for debugging.
Paul.
