Re: [Qemu-devel] [PATCH 4/7 v2] KVM regsync: Add register bitmap parameter to do_kvm_cpu_synchronize_state

[Marcelo Tosatti <mtosatti@redhat.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.