From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TvZVW-00078S-FS for qemu-devel@nongnu.org; Wed, 16 Jan 2013 15:22:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TvZVV-0007W5-3L for qemu-devel@nongnu.org; Wed, 16 Jan 2013 15:22:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TvZVU-0007VE-Rs for qemu-devel@nongnu.org; Wed, 16 Jan 2013 15:22:45 -0500 Date: Wed, 16 Jan 2013 18:21:42 -0200 From: Marcelo Tosatti Message-ID: <20130116202142.GB1413@amt.cnet> References: <1357831744-3950-1-git-send-email-jjherne@us.ibm.com> <20130116160533.GA8541@amt.cnet> <50F70788.5020607@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F70788.5020607@de.ibm.com> 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: Christian Borntraeger Cc: agraf@suse.de, aliguori@us.ibm.com, jan.kiszka@siemens.com, qemu-devel@nongnu.org, "Jason J. Herne" , R65777@freescale.com 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). Accessors for reading/writing shared (between userspace and kernel) registers in CPUState is one option.