[PATCH 1/4] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register

Alexander Graf agraf at suse.de
Fri Jun 6 08:36:12 EST 2014


On 06.06.14 00:32, Alexander Graf wrote:
>
> On 05.06.14 19:33, Aneesh Kumar K.V wrote:
>> Alexander Graf <agraf at suse.de> writes:
>>
>>> On 05.06.14 17:50, Aneesh Kumar K.V wrote:
>>>> Alexander Graf <agraf at suse.de> writes:
>>>>
>>>>> On 05.06.14 14:08, Aneesh Kumar K.V wrote:
>>>>>> virtual time base register is a per VM, per cpu register that needs
>>>>>> to be saved and restored on vm exit and entry. Writing to VTB is not
>>>>>> allowed in the privileged mode.
>>>>>>
>>>>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>
>> .......
>>
>>>>>>                 break;
>>>>>> diff --git a/arch/powerpc/kvm/book3s_emulate.c 
>>>>>> b/arch/powerpc/kvm/book3s_emulate.c
>>>>>> index 3565e775b61b..1bb16a59dcbc 100644
>>>>>> --- a/arch/powerpc/kvm/book3s_emulate.c
>>>>>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>>>>>> @@ -577,6 +577,9 @@ int kvmppc_core_emulate_mfspr_pr(struct 
>>>>>> kvm_vcpu *vcpu, int sprn, ulong *spr_val
>>>>>>              */
>>>>>>             *spr_val = vcpu->arch.spurr;
>>>>>>             break;
>>>>>> +    case SPRN_VTB:
>>>>>> +        *spr_val = vcpu->arch.vtb;
>>>>> Doesn't this mean that vtb can be the same 2 when the guest reads 
>>>>> it 2
>>>>> times in a row without getting preempted?
>>>> But a mfspr will result in VM exit and that would make sure we
>>>> update vcpu->arch.vtb with the correct value.
>>> We only call kvmppc_core_vcpu_put_pr() when we context switch away from
>>> KVM, so it won't be updated, no?
>>>
>>>
>> kvmppc_copy_from_svcpu is also called from VM exit path 
>> (book3s_interrupt.S)
>
> ... where it will run into this code path:
>
>         /*
>          * Maybe we were already preempted and synced the svcpu from
>          * our preempt notifiers. Don't bother touching this svcpu then.
>          */
>         if (!svcpu->in_use)
>                 goto out;

Scratch that. We're always calling this on entry/exit, so you're right.


Alex



More information about the Linuxppc-dev mailing list