All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>,
	kvmarm@lists.cs.columbia.edu, patches@linaro.org
Subject: Re: [Qemu-devel] [PATCH 3/7] target-arm: mark up cpregs for no-migrate or raw access
Date: Thu, 30 May 2013 15:38:19 -0700	[thread overview]
Message-ID: <20130530223819.GA1553@ubuntu> (raw)
In-Reply-To: <CAFEAcA8EaYvAPLZ6sQFGMx_6V=O7O7u1ch2Sb3=FJxVLArLUuw@mail.gmail.com>

On Thu, May 30, 2013 at 11:27:01PM +0100, Peter Maydell wrote:
> On 30 May 2013 23:13, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> > What happens with registers which don't have the raw_write function set
> > (even though the write function imposes some access checks or has side
> > effects) and also is not marked as ARM_CP_NO_MIGRATE,
> 
> In the general case what happens is that we probably don't
> sync (or migrate, for TCG) the register properly, because
> we'll use the standard write function and get whatever it
> does. (Note that mistakes in annotation don't affect KVM
> migration because we always trust the kernel's register
> list and values and work with them directly; we don't indirect
> through the TCG CPUState structures to migrate the data.)
> 
> The alternative would seem to be to require a raw_read/write
> function to be explicitly specified if there's a read/write
> function (even if it's specified to be the same thing), but
> that seemed to me like it would add a lot of boilerplate for
> most register descriptions. Do you think it would be better
> anyway, or do you have a better idea?

Depends on how many places you add the raw functions.  I was thinking
about whether the absence of such a function could substitute the need
for the NO_MIGRATE flag, but, eh, there's probably other uses for having
that flag so it's not really preferred.

You probably did the best thing.

> 
> > CONTEXTIDR seems to be such an example. ?
> 
> In this specific case I decided it was safe to let the non-raw
> write function do a tlb_flush(). Looking again that is kinda
> expensive though, so we should probably mark these registers
> up with raw_write functions.
> 

Migration is sort of an expensive operation, so not sure if it's worth
it.

I am mostly worries about the case where we would miss raw read/write
functions and that could be hard to track down in the case where
migration fails, but I don't really have great suggestions on how to
ensure this.

-Christoffer

  reply	other threads:[~2013-05-30 22:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-17 13:23 [Qemu-devel] [PATCH 0/7] target-arm: cpregs list for migration, kvm reset Peter Maydell
2013-05-17 13:23 ` [Qemu-devel] [PATCH 1/7] target-arm: Allow special cpregs to have flags set Peter Maydell
2013-05-17 13:23 ` [Qemu-devel] [PATCH 2/7] target-arm: Add raw_readfn and raw_writefn to ARMCPRegInfo Peter Maydell
2013-05-17 13:23 ` [Qemu-devel] [PATCH 3/7] target-arm: mark up cpregs for no-migrate or raw access Peter Maydell
2013-05-30 22:13   ` Christoffer Dall
2013-05-30 22:27     ` Peter Maydell
2013-05-30 22:38       ` Christoffer Dall [this message]
2013-05-30 22:42         ` Peter Maydell
2013-05-17 13:23 ` [Qemu-devel] [PATCH 4/7] target-arm: Convert TCG to using (index, value) list for cp migration Peter Maydell
2013-05-31  0:09   ` Christoffer Dall
2013-05-17 13:23 ` [Qemu-devel] [PATCH 5/7] target-arm: Initialize cpreg list from KVM when using KVM Peter Maydell
2013-05-20 12:25   ` Peter Maydell
2013-05-17 13:23 ` [Qemu-devel] [PATCH 6/7] target-arm: Reinitialize all KVM VCPU registers on reset Peter Maydell
2013-05-17 13:23 ` [Qemu-devel] [PATCH 7/7] target-arm: Use tuple list to sync cp regs with KVM Peter Maydell
2013-05-31  0:11 ` [Qemu-devel] [PATCH 0/7] target-arm: cpregs list for migration, kvm reset Christoffer Dall

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=20130530223819.GA1553@ubuntu \
    --to=christoffer.dall@linaro.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.