Re: [Qemu-devel] [PATCH for-2.3? 7/7] tests/tcg: Enable runcom test by default

[Peter Maydell]

On 12 April 2015 at 09:34, Alexander Graf <address@hidden> wrote:
>
>
>> Am 11.04.2015 um 23:46 schrieb Andreas Färber <address@hidden>:
>>
>>> Am 11.04.2015 um 23:33 schrieb Peter Maydell:
>>>> On 11 April 2015 at 21:28, Andreas Färber <address@hidden> wrote:
>>>> Are you sure that QEMU / runcom / pi_10.com still try to map to that
>>>> address zero?
>>>
>>> It's the first thing runcom.c's main() does after checking you've
>>> passed it enough command line arguments.
>>
>> This?
>>
>>    vm86_mem = mmap((void *)0x00000000, 0x110000,
>>                    PROT_WRITE | PROT_READ | PROT_EXEC,
>>                    MAP_FIXED | MAP_ANON | MAP_PRIVATE, -1, 0);
>>    if (vm86_mem == MAP_FAILED) {
>>        perror("mmap");
>>        exit(1);
>>    }
>>
>> For whatever reason it does not take the MAP_FAILED path here...
>
> Wasn't a NULL argument for the address a hint saying "map wherever
> you please"?

Only if you don't also say MAP_FIXED.

That aside, I've now looked more carefully at the makefile,
and we're not running 'runcom' directly, we're running it
within QEMU's user-mode. So a guest allocation at vaddr 0
isn't going to turn into a host mmap at vaddr 0 (we actually
query the host mmap_min_addr parameter in linux-user/main.c).

So I think the issue noted in the comment on the makefile
(back in 2010) would have been a bug which we've presumably
fixed in the meantime by adding support for guest_base and
making sure it works correctly. (Looking at the revision
log suggests that guest_base should in theory have already
supported adjustment based on mmap_min_addr at the point
when runcom was taken out of the makefile, but presumably
there was a bug.)

-- PMM