From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:33541)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1TbC8S-0003tI-7V
	for qemu-devel@nongnu.org; Wed, 21 Nov 2012 10:22:45 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1TbC8M-0005SR-AT
	for qemu-devel@nongnu.org; Wed, 21 Nov 2012 10:22:44 -0500
Received: from thoth.sbs.de ([192.35.17.2]:30228)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1TbC8M-0005SE-0b
	for qemu-devel@nongnu.org; Wed, 21 Nov 2012 10:22:38 -0500
Message-ID: <50ACF1B1.6050904@siemens.com>
Date: Wed, 21 Nov 2012 16:22:25 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <1353509165-26865-1-git-send-email-borntraeger@de.ibm.com>
	<1353509165-26865-2-git-send-email-borntraeger@de.ibm.com>
	<50ACEB95.7090300@suse.de> <50ACEC4F.4050109@de.ibm.com>
	<50ACECE9.4000004@suse.de> <50ACED48.3050308@de.ibm.com>
	<50ACEE12.4000800@suse.de> <50ACEE8A.8050302@de.ibm.com>
In-Reply-To: <50ACEE8A.8050302@de.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 1/3] s390/migration: Provide a cpu save for
 initial life migration work
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Jens Freimann <jfrei@linux.vnet.ibm.com>, Heinz Graalfs <graalfs@linux.vnet.ibm.com>, "Jason J. herne" <jjherne@us.ibm.com>, Alexander Graf <agraf@suse.de>, qemu-devel <qemu-devel@nongnu.org>

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?

Jan

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