Re: [Xen-devel] Re: [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Mon, Jul 18, 2011 at 15:46, Anthony PERARD <anthony.perard@xxxxxxxxxx> wrote:
> On Mon, Jul 18, 2011 at 13:30, Alexander Graf <agraf@xxxxxxx> wrote:
>>
>> On 15.07.2011, at 16:32, Anthony Perard wrote:
>>
>>> In Xen case, memory can be bigger than the host memory. that mean a
>>> 32bits host (and QEMU) should be able to handle a RAM address of 64bits.
>>>
>>> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>> ---
>>> cpu-common.h | Â Â8 ++++++++
>>> exec.c    |  Â9 +++++----
>>> xen-all.c  Â|  Â2 +-
>>> 3 files changed, 14 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/cpu-common.h b/cpu-common.h
>>> index e4fcded..e1b40fe 100644
>>> --- a/cpu-common.h
>>> +++ b/cpu-common.h
>>> @@ -27,7 +27,15 @@ enum device_endian {
>>> };
>>>
>>> /* address in the RAM (different from a physical address) */
>>> +#ifndef CONFIG_XEN_BACKEND
>>> typedef unsigned long ram_addr_t;
>>
>> Do we really want to depend this on _BACKEND? ram_addr_t is target 
>> dependent, no?
>
> :(, indeed, it's seams to be target dependent, I did not check that
> carefully enough. So CONFIG_XEN is enough.

Actually, this does not work because it is used in libhw64 (like
target_phys_addr_t).

So I am thinking about eithier introduce a new config variable in
./configure (ram_addr_bits), or just have
#if defined(CONFIG_XEN_BACKEND) && TARGET_PHYS_ADDR_BITS == 64

So, libhw64 with xen activated will be compiled with a ram_addr of
64b, and the libhw32 will stay with a "unsigned long".

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel