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
