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 <mark.langsd...@calxeda.com> 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
