On 23.03.2017 23:41, Paul Mackerras wrote:
> 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.
Right, it should be enough for debugging to have a way to log this.
Could you dig out your patch, or shall I try to come up with a new one?
Thomas
