Re: [Qemu-devel] [PATCH] arm highbank: force ramsize to INT_MAX when loading

[Alexander Graf]

On 09.03.2012, at 20:03, Andreas Färber wrote:

> Am 09.03.2012 19:22, schrieb Alexander Graf:
>> 
>> On 09.03.2012, at 17:40, Mark Langsdorf wrote:
>> 
>>> On 03/09/2012 10:13 AM, Peter Maydell wrote:
>>>> On 9 March 2012 15:57, Mark Langsdorf <address@hidden> wrote:
>>>>> Since the ram_size field of arm_boot_info is only an int, don't set
>>>>> that field to more than INT_MAX. Signed vs unsigned comparison
>>>>> overruns are possible otherwise.
>>>> 
>>>> Can't we just make arm_boot_info.ram_size a uint32_t (propagating through
>>>> signedness fixes as required) ?
>>>> 
>>>> Actually it should probably be a target_phys_addr_t, thinking ahead
>>>> to adding LPAE support.
>>> 
>>> It really should be a size_t, per the upthread discussion with Andreas
>>> Faerber.
>> 
>> No, Andreas is wrong. Host data types have nothing to do in target ram 
>> fiddling code. The type you're searching for is "the size of physical 
>> address space the guest can handle" and that's target_phys_addr_t. Period.
> 
> That is exactly where we disagree: It's not "target ram fiddling code".
> 
> It's the host loading binaries from disk to host RAM.

No, it's an offset into guest RAM.

Right now the interface is using

  target_phys_addr_t addr
  int size

what if instead if would be using

  target_phys_addr_t start
  target_phys_addr_t end

It would still be the same thing semantically. We have a start address and an 
end address that we can put data in. The fact that the image is backed by some 
POSIX layers in the background is a minor detail. It could just as well go 
through the block layer and be read via libcurl from http.

The semantic of size is

  addr + size = end


Alex