On 03.07.2013, at 15:53, Caraman Mihai Claudiu-B02008 wrote:
>>> -#ifdef CONFIG_SPE
>>> case BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL: {
>>> - if (vcpu->arch.shared->msr & MSR_SPE)
>>> - kvmppc_vcpu_enable_spe(vcpu);
>>> - else
>>> - kvmppc_booke_queue_irqprio(vcpu,
>>> -
>> BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL);
>>> + if (kvmppc_supports_spe()) {
>>> + bool enabled = false;
>>> +
>>> +#ifndef CONFIG_KVM_BOOKE_HV
>>> + if (vcpu->arch.shared->msr & MSR_SPE) {
>>> + kvmppc_vcpu_enable_spe(vcpu);
>>> + enabled = true;
>>> + }
>>> +#endif
>>
>> Why the #ifdef? On HV capable systems kvmppc_supports_spe() will just
>> always return false.
>
> AltiVec and SPE unavailable exceptions follows the same path. While
> kvmppc_supports_spe() will always return false kvmppc_supports_altivec()
> may not.
There is no chip that supports SPE and HV at the same time. So we'll never hit this anyway, since kvmppc_supports_spe() always returns false on HV capable systems.
Just add a comment saying so and remove the ifdef :).
Alex
>
>> And I don't really understand why HV would be special in the first place
>> here. Is it because we're accessing shared->msr?
>
> You are right on HV case MSP[SPV] should be always zero when an unavailabe
> exception take place. The distrinction was made because on non HV the guest
> doesn't have direct access to MSR[SPE]. The name of the bit (not the position)
> was changed on HV cores.
>
>>
>>> + if (!enabled)
>>> + kvmppc_booke_queue_irqprio(vcpu,
>>> + BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL);
>>> + } else {
>>> + /*
>>> + * Guest wants SPE, but host kernel doesn't support it.
>>
>> host kernel or hardware
>
> Ok.
>
> -Mike
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
