qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 4/7] savevm: Add VMSTATE_ helpers for target_phys_addr_t
Date: Thu, 11 Oct 2012 16:07:24 +0100

On 11 October 2012 02:57, David Gibson <address@hidden> 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.

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.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]