[Vm-dev] oops to zero

David T. Lewis lewis at mail.msen.com
Tue Oct 9 22:31:33 UTC 2007

On Tue, Oct 09, 2007 at 10:26:42PM +0200, Bert Freudenberg wrote:
> On Oct 6, 2007, at 15:08 , David T. Lewis wrote:
> >Actually the Unix VM already does use mmap() on /dev/zero to obtain  
> >the
> >base address, so it is easy to request a specific base address. Ian  
> >pointed
> >this out to me when I was doing the "32bit clean" patches, and that is
> >how I was able to test those changes.
> >
> >The attached diff shows where to make the change in sqUnixMemory.c.
> >
> >Note that mmap() will assign its own address if it does not agree with
> >the one that you requested. You will need to pick an address that  
> >works
> >on various versions of the kernel, and on both 32 bit and 64 bit  
> >systems
> >(or perhaps provide a list of addresses, and let the VM find one that
> >works on that particular platform).  The value 0x4000000 seems  
> >reasonable
> >on a 64 bit AMD Linux 2.6 system, but I did not check to see if it  
> >works
> >on a 32 bit system, so you may need to experiment a bit.
> >
> >The OLPC platform has well defined hardware and OS, so it would be  
> >good
> >to pick a number that works on OLPC and make that the default.
> Interesting - I also found that on Linux I can modify the executable  
> to disable randomization using the -R flag of setarch:
> http://www.linuxcommand.org/man_pages/setarch8.html
> Have not tested this yet. And does the image loading logic actually  
> check if a remap is necessary?

I don't think there will be any need to use setarch. The VM justs asks
for a big bunch of memory, and uses mmap() to do this. If you do not
request a specific address to use in your process virtual memory, it
will assign one for you. And if you do ask for an address, it will try
to honor your request if it can. That's probably sufficient for our
purposes as long as we can pick a reasonable address to request. If it
turns out that there are lots of differences across platforms, it
could be handled by configure (but hopefully that's not necessary).


More information about the Vm-dev mailing list