On 12 April 2015 at 09:34, Alexander Graf <ag...@suse.de> wrote:
>
>
>> Am 11.04.2015 um 23:46 schrieb Andreas Färber <afaer...@suse.de>:
>>
>>> Am 11.04.2015 um 23:33 schrieb Peter Maydell:
>>>> On 11 April 2015 at 21:28, Andreas Färber <afaer...@suse.de> 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
