From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TvZoB-00071h-Ha for qemu-devel@nongnu.org; Wed, 16 Jan 2013 15:42:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TvZoA-0004kh-1L for qemu-devel@nongnu.org; Wed, 16 Jan 2013 15:42:03 -0500 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:59068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TvZo9-0004kL-Op for qemu-devel@nongnu.org; Wed, 16 Jan 2013 15:42:01 -0500 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 Jan 2013 20:41:04 -0000 Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0GKfmhd17563754 for ; Wed, 16 Jan 2013 20:41:48 GMT Received: from d06av09.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0GKfuP7030263 for ; Wed, 16 Jan 2013 13:41:56 -0700 Message-ID: <50F71092.6020309@de.ibm.com> Date: Wed, 16 Jan 2013 21:41:54 +0100 From: Christian Borntraeger MIME-Version: 1.0 References: <1357831744-3950-1-git-send-email-jjherne@us.ibm.com> <20130116160533.GA8541@amt.cnet> <50F70788.5020607@de.ibm.com> <20130116202142.GB1413@amt.cnet> In-Reply-To: <20130116202142.GB1413@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/7 v2] KVM regsync: Add register bitmap parameter to do_kvm_cpu_synchronize_state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: agraf@suse.de, aliguori@us.ibm.com, jan.kiszka@siemens.com, qemu-devel@nongnu.org, "Jason J. Herne" , R65777@freescale.com On 16/01/13 21:21, Marcelo Tosatti wrote: > On Wed, Jan 16, 2013 at 09:03:20PM +0100, Christian Borntraeger wrote: >> On 16/01/13 17:05, Marcelo Tosatti wrote: >> >>> The S/390 problem, from >>> http://lists.nongnu.org/archive/html/qemu-devel/2012-11/msg02213.html: >>> >>> ">>> 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." >>> >>> But wait: on these S/390 codepaths, you do GET_REGS already, via >>> cpu_synchronize_state. >>> >>> So on S/390 >>> >>> - cpu_synchronize_state(env) >>> - read any register from env >>> >>> Is not valid? This is what generic code assumes. >> >> TO recap the motiviation: >> >> cpu_synchronize_state on s390 currently updates any register in env that is >> used by qemu (general purpose, prefix, psw, control and access) in the normal >> runtime. it turns out we have all of these regs in kvm_run, so we can do >> synchronize states without doing an additional ioctl call. >> Now, for life migration and dump we need some additional registers (which are >> only accessable via onereg interface). So synchronize_state would need to >> do 3 or 4 additional system calls on the hot path, only to take care of >> something that is not on the hot path at all. >> For historic reasons, we have one exit code for almost all exits. Therefore, >> we need to call synchronize_states almost always. >> We could now start to have a poor mans synchronize_state in arch code, but >> that would collide with common code synchronize_state if done at the wrong >> time. Thus we want to make common code capable of having only a subset of >> the register synched - by making it possible to sync the other regs later >> on if needed without wiping the former sync. >> >> Makes sense? >> >> Christian > > Yes. As noted in the last email on the thread, runtime/reset/full are to > serapate sets of registers when writing _to_ kernel. When reading _from_ > kernel, reset and full distinctions are not appropriate (any register > can change, as far as knowledge goes). Hmm, I probably did not understood your point, so I will try to explain mine and see what you respond :-) The point of the patch set, is to allow this distinction when reading. In other words it allows code to state: I am only interested in regxy and dont care if the other regs in env are out of sync. If a full sync is necessary later on the other regs are synched as well. If a full sync was already done before a partial get becomes a no-op. Why should that be not possible. Christian