On 04.12.2012, at 03:42, David Gibson wrote: > The hwaddr type is somewhat vaguely defined as being able to contain bus > addresses on the widest possible bus in the system. For that reason it's > discouraged for representing specific pieces of persistent hardware state, > which should instead use an explicit width type that matches the bits > available in real hardware. In particular, because of the possibility that > the size of hwaddr might change if different buses are added to the target > in future, it's not suitable for use in vm state descriptions for savevm > and migration. > > This patch purges such unwise uses of hwaddr from the ppc target code, > which turns out to be just one. The ppcemb_tlb_t struct, used on a number > of embedded ppc models to represent a TLB entry contains a hwaddr for the > real address field. This patch changes it to be a fixed uint64_t which is > suitable enough for all machine types which use this structure. > > Other uses of hwaddr in CPUPPCState turn out not to be problematic: > htab_base and htab_mask are just used for the convenience of the TCG code; > the underlying machine state is the SDR1 register, which is stored with > a suitable type already. Likewise the mpic_cpu_base field is only used > internally and does not represent fundamental hardware state which needs to > be saved. > > Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
Thanks, applied to ppc-next. Alex
