On Thu, Nov 07, 2013 at 10:49:50AM +0000, Peter Maydell wrote: > On 7 November 2013 10:41, Marcel Apfelbaum <marce...@redhat.com> wrote: > > The page table logic in exec.c assumes > > that memory addresses are at most TARGET_PHYS_ADDR_SPACE_BITS. > > Use TARGET_PHYS_ADDR_SPACE_MAX as max size for memory regions > > rendered by exec. > > > > Signed-off-by: Marcel Apfelbaum <marce...@redhat.com> > > --- > > include/exec/address-spaces.h | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/include/exec/address-spaces.h b/include/exec/address-spaces.h > > index 3d12cdd..174cc05 100644 > > --- a/include/exec/address-spaces.h > > +++ b/include/exec/address-spaces.h > > @@ -23,6 +23,10 @@ > > > > #ifndef CONFIG_USER_ONLY > > > > +#define TARGET_PHYS_ADDR_SPACE_MAX \ > > + (TARGET_PHYS_ADDR_SPACE_BITS == 64 ? \ > > + UINT64_MAX : (0x1ULL << TARGET_PHYS_ADDR_SPACE_BITS)) > > + > > I think it's worth adding a comment that this is a > size intended for use in memory_region_init() calls and > so follows the odd convention used by that API that > it is a size in bytes with the exception that UINT64_MAX > represents 2^64. > > (it follows from this that using the #define anywhere > except in a memory_region_init() call is probably a bug) > > -- PMM
BTW how about we change the API to pass in int128? Not for 1.7 of course. This will help make sure it's only used for MRs. -- MST
