From: David Gibson <dwg@au1.ibm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: blauwirbel@gmail.com, aliguori@us.ibm.com, qemu-devel@nongnu.org,
quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH 4/7] savevm: Add VMSTATE_ helpers for target_phys_addr_t
Date: Fri, 12 Oct 2012 10:35:06 +1000 [thread overview]
Message-ID: <20121012003506.GR25270@truffula.fritz.box> (raw)
In-Reply-To: <CAFEAcA-X+SKG5FWzLuymjMc_e0zkR9xrPpu0aNaacw228OgsjA@mail.gmail.com>
On Thu, Oct 11, 2012 at 04:07:24PM +0100, Peter Maydell wrote:
> On 11 October 2012 02:57, David Gibson <dwg@au1.ibm.com> wrote:
> > Actually, turns out I had another use of these helpers. That was to
> > store the real page address from the ppcmeb_tlb_t structure. That
> > structure is used to represent TLB entries on a number of different
> > embedded chips, which don't all have the same physical bus width. So
> > target_phys_addr_t does seem like the correct type there.
>
> > Obviously I could change the type to a fixed uint64_t, but I'm not
> > sure if that's a better idea than bringing in the VMSTATE_TPA
> > helpers. Advice?
>
> PPC has had 64 bit target_phys_addr_t even before the recent change.
> Either these various CPUs all actually have physical hardware
> TLB configs which hold the full 64 bits (use uint64_t) or they
> have physical configs which vary between them (in which case
> you're presumably mismodelling some of them) and you need to
> use different types or alternatively always use uint64_t and
> do masking on writes to the fields or something.
Masking will be done in the handling of the instructions that access
the TLB. They do have different physical configs, but they also have
different access methods, the data type as it is is sufficient for
both of them.
> If you're happy to continue to bake the assumption into your
> code that target_phys_addr_t is 64 bits, you can just use
> VMSTATE_UINT64 which (I think) should work OK when t_p_a_t
> really is 64 bits, and will give a helpful compile failure
> if the assumption is ever untrue...
>
> Basically I think that to the extent that we contemplate
> t_p_a_t as distinct from "64 bit uint" it's a bad idea to put
> it into vmstate because it means potential migration
> compatibility breaks if it changes.
Hm, yeah, that I'll grant you. Ok, I'll remove it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2012-10-12 0:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-09 4:53 [Qemu-devel] [0/7] vmstate extensions David Gibson
2012-10-09 4:53 ` [Qemu-devel] [PATCH 1/7] savevm: Add VMSTATE_UINT64_EQUAL helpers David Gibson
2012-10-09 4:53 ` [Qemu-devel] [PATCH 2/7] savevm: Add VMSTATE_UINTTL_EQUAL helper David Gibson
2012-10-09 4:53 ` [Qemu-devel] [PATCH 3/7] savevm: Add VMSTATE_FLOAT64 helpers David Gibson
2012-10-09 4:53 ` [Qemu-devel] [PATCH 4/7] savevm: Add VMSTATE_ helpers for target_phys_addr_t David Gibson
2012-10-09 8:03 ` Peter Maydell
2012-10-09 12:53 ` David Gibson
2012-10-09 16:24 ` Peter Maydell
2012-10-10 0:17 ` David Gibson
2012-10-11 1:57 ` David Gibson
2012-10-11 15:07 ` Peter Maydell
2012-10-12 0:35 ` David Gibson [this message]
2012-10-09 4:53 ` [Qemu-devel] [PATCH 5/7] savevm: Add VMSTATE_STRUCT_VARRAY_POINTER_UINT32 David Gibson
2012-10-09 4:53 ` [Qemu-devel] [PATCH 6/7] savevm: Fix bugs in the VMSTATE_VBUFFER_MULTIPLY definition David Gibson
2012-10-09 4:53 ` [Qemu-devel] [PATCH 7/7] savevm: Implement VMS_DIVIDE flag David Gibson
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=20121012003506.GR25270@truffula.fritz.box \
--to=dwg@au1.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=blauwirbel@gmail.com \
--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 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).