Re: [Qemu-devel] [PATCH 1/3] s390/migration: Provide a cpu save for initial life migration work

[Jan Kiszka]

On 2012-11-21 16:27, Christian Borntraeger wrote:
> 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.

OK, if all existing synchronization points remain FULL_STATE and only
s390-specific points become RUNTIME_STATE, I'm fine with it. Other archs
could then do their optimizations as the like (and actually need) to.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux