Re: [Qemu-devel] [PATCH] use an unsigned long for the max_sz parameter in load_image_targphys

["Andreas Färber" <afaerber@suse.de>]

Am 10.03.2012 14:51, schrieb Peter Maydell:
> On 9 March 2012 18:47, Andreas Färber <afaerber@suse.de> wrote:
>> Am 09.03.2012 18:11, schrieb Peter Maydell:
>>> On 9 March 2012 14:28, Andreas Färber <afaerber@suse.de> wrote:
>>>> No, please. We're describing sizes, not addresses. target_phys_addr_t
>>>> thus is semantically wrong here. The RAM size is unsigned long IIRC (it
>>>> is limited by the host's available memory). If you subtract something
>>>> from a size it remains a size. I had therefore suggested size_t before.
>>>> I expect sizeof(size_t) >= sizeof(unsigned long).
>>>
>>> We're discussing target sizes. size_t might be smaller than
>>> target_phys_addr_t, so it's also semantically wrong. We don't
>>> have a target_size_t, though, and I think "use an address
>>> related type for an offset" is less bad than "use a host
>>> sized type for a guest sized value".
>>
>> That is a moot point. There is no such thing as a "target size".
> 
> "Length of a block of memory on the guest" is what I meant.
> What you need is "an integer type large enough to hold the
> difference between two guest pointer values". The size of
> that type should depend only on the guest config, not on the
> host, so 'unsigned long', 'size_t', 'off_t' etc are all wrong.

Your view is very ARM-centric. In the PowerPC domain for instance, we
have a number of usages where we hardcode a size of, e.g., 1 MB. And
Alex should know that. I don't want to use target_phys_addr_t for that
and forcing an end address calculation, as suggested by Alex, would be
possible but is not as convenient as the current API.

Doing a size check as Mark has demonstrated in ARM code (one place!)
seems much simpler to me than hurting all targets just because ARM wants
to pass a possibly stupid value unchecked to the common API.

Compare David's off_t patch from March 8th: We'll never get an image
size larger than off_t's max. Using target_phys_addr_t, uint64_t or
__int128_t for the max are all moot (academic) because we'll never get
to their max if it's larger than off_t. Therefore I've been saying, the
host's limit is the upper realistic limit for image_load_targphys().

ELF may be a different case to consider since it can be sparse.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg