On 18.03.2016 11:18, Laurent Vivier wrote:
>
>
> On 18/03/2016 11:06, Thomas Huth wrote:
>> On 18.03.2016 11:01, Laurent Vivier wrote:
> ...
>>>>> + /* doc says it is invalid, real proc stops when it comes to
>>>>> + * overwrite the register.
>>>>> + * In all the cases, the register must stay untouched
>>>>> + */
>>>>> + report("Don't overwrite Rb", regs[1] == (uint64_t)addr);
>>>>
>>>> Huh, how can this KVM unit test ever finish successfully if real
>>>> processor stops? Should this last test maybe be optional and only be
>>>> triggered if this kvm-unit-test is run with certain parameters?
>>>
>>> Well, my bad, I've not been accurate: the processor doesn't stop, but
>>> the processing of the instruction is stopped. Only registers until Rb
>>> (not included) are updated, and then the processor continue with the
>>> next instruction. So we have just to test Rb is not modified. I'll
>>> update the comment.
>>
>> Ok, now I've got it, I think. Maybe you should also check the
>> "is_invalid" variable here? And it would also be interesting to see
>> whether regs[0] (i.e. r31) has been changed or not?
>
> In fact, I've tested this with kvm PR and HV, on POWER8 and ppc970, and
> there is never an illegal exception. It's why I don't check that.
>
> Checking regs[1] is correct in the case of the doc (illegal instruction)
> and of the real processor (it doesn't update it).
>
> Checking regs[0] can be tricky: in the case of the doc (illegal) it
> should not be updated, in the case of the real processor it is updated.
>
> I'd like this test checks only if TCG behaves like a real processor,
> it's why I prefer to check this result against the result of a real
> processor than against the result described in the doc.
Ah, ok ... I just saw that there is even a comment in the QEMU sources
about this in front of the helper_lswx() function ... then better keep
the unit test code in its current shape!
Thomas
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
