qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: agraf@suse.de, aliguori@us.ibm.com, jan.kiszka@siemens.com,
	qemu-devel@nongnu.org, "Jason J. Herne" <jjherne@us.ibm.com>,
	R65777@freescale.com
Subject: Re: [Qemu-devel] [PATCH 4/7 v2] KVM regsync: Add register bitmap parameter to do_kvm_cpu_synchronize_state
Date: Wed, 16 Jan 2013 21:03:20 +0100	[thread overview]
Message-ID: <50F70788.5020607@de.ibm.com> (raw)
In-Reply-To: <20130116160533.GA8541@amt.cnet>

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

  parent reply	other threads:[~2013-01-16 20:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10 15:29 [Qemu-devel] [PATCH 4/7 v2] KVM regsync: Add register bitmap parameter to do_kvm_cpu_synchronize_state Jason J. Herne
2013-01-12 11:08 ` Blue Swirl
2013-01-14 11:32 ` Bhushan Bharat-R65777
2013-01-16 16:05 ` Marcelo Tosatti
2013-01-16 16:12   ` Marcelo Tosatti
2013-01-16 17:00   ` Bhushan Bharat-R65777
2013-01-16 17:23     ` Marcelo Tosatti
2013-01-16 20:09     ` Marcelo Tosatti
2013-01-16 20:03   ` Christian Borntraeger [this message]
2013-01-16 20:21     ` Marcelo Tosatti
2013-01-16 20:41       ` Christian Borntraeger
2013-01-16 23:01         ` Marcelo Tosatti
     [not found]           ` <9F9185C2-DDA5-4242-9BF2-664F4E0329F9@suse.de>
2013-02-01 15:47             ` Jason J. Herne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50F70788.5020607@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=R65777@freescale.com \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jjherne@us.ibm.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).