Re: [Qemu-devel] [PATCH 4/7] savevm: Add VMSTATE_ helpers for target_phys_addr_t

[David Gibson <dwg@au1.ibm.com>]

On Tue, Oct 09, 2012 at 09:03:21AM +0100, Peter Maydell wrote:
> On 9 October 2012 05:53, David Gibson <david@gibson.dropbear.id.au> wrote:
> > The savevm code contains VMSTATE_ helpers for a number of commonly used
> > types, but not for target_phys_addr_t.  This patch fixes that deficiency
> > implementing VMSTATE_TPA helpers in terms of VMSTATE_UINT32 or
> > VMSTATE_UINT64 helpers as appropriate.
> 
> (This comment is out of date...)

Ah, yes.

> Traditionally we have deliberately not had any vmstate helpers
> for target_phys_addr_t because the meaning of that type is "a
> type wide enough to hold the widest address in use in the system".
> vmstate fields, on the other hand, are for the state of a specific
> device model, and a particular device's registers are always a
> fixed width. Even if a pci card model is plugged into a system
> with 64 bit PCI addresses, if the chip on the card itself only
> has 32 bit wide registers controlling DMA those registers need
> to be uint32_t. So if you think you need to put target_phys_addr_t
> into a vmstate the chances are you don't. I think this logic
> should still hold even now we have made target_phys_addr_t
> 64 bits for every platform.
> 
> What was the problem this patch is trying to fix?

Well, the place I've used this (in patches yet to be posted) is saving
the state of the pseries machine itself.  Specifically, I use
VMSTATE_TPA_EQUAL to sanity check that the restored machine has the
same ram size as the saved machine.  In this case the variable is qemu
internal information and represents a ram size, so I think
target_phys_addr_t is the correct type here.

-- 
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