On 21/11/12 16:22, Jan Kiszka wrote:
> On 2012-11-21 16:08, Christian Borntraeger wrote:
>> On 21/11/12 16:06, Alexander Graf wrote:
>> [...]
>>>>>>>> +static int cpu_post_load(void *opaque, int version_id)
>>>>>>>> +{
>>>>>>>> + CPUS390XState *env = opaque;
>>>>>>>> + struct kvm_fpu fpu;
>>>>>>>> + int i, r;
>>>>>>>> +
>>>>>>>> + if (!kvm_enabled()) {
>>>>>>>> + return 0;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + for (i = 0; i< 16; i++) {
>>>>>>>> + fpu.fprs[i] = env->fregs[i].ll;
>>>>>>>> + }
>>>>>>>> + fpu.fpc = env->fpc;
>>>>>>>> +
>>>>>>>> + r = kvm_vcpu_ioctl(env, KVM_SET_FPU,&fpu);
>>>>>>>> + assert(r == 0);
>>>>>>>> +
>>>>>>>> + return 0;
>>>>>>>> +}
>>>>>>> The kvm register sync needs to happen in the kvm register sync function
>>>>>>> :)
>>>>>> That would eliminate the whole purpose of sync regs and forces us to
>>>>>> have an
>>>>>> expensive ioctl on lots of exits (again). I would prefer to sync the
>>>>>> registers
>>>>>> that we never need in qemu just here.
>>>>> That's why the register sync has different stages.
>>>> Not the get_register. Which is called on every synchronize_state. Which
>>>> happen quite often
>>>> on s390.
>>>
>>> Sounds like bad design then :).
>>>
>>> Maybe we should explicitly tell the register synchronization which register
>>> sets to sync, so that we don't waste time getting _all_ the state every
>>> time we sync registers?
>>
>> Yes, a level statement for kvm_arch_get_registers would be good.
>>
>
> The challenge is defining those levels generically - as it is also
> generic code that calls cpu_synchronize_state. What levels do you have
> in mind? And where would they be applied?
I think that RUNTIME_STATE and FULL_STATE would be sufficient for the needs
that I have. The registers that I need during runtime can be accessed quite
fast, but for life migration I also need those registers that are accessed
via ONE_REG or other ioctls.
Christian
