On 11 July 2011 09:42, David Gilbert <david.gilb...@linaro.org> wrote: > On 11 July 2011 09:36, Dave Martin <dave.mar...@linaro.org> wrote: >> On Sat, Jul 09, 2011 at 12:29:01AM +0100, Peter Maydell wrote: >>> QEMU supports calls into the fixed vector page (it just special cases >>> attempts to execute at addresses >= 0xffff0000 and emits code to do >>> "cause special purpose exception" so we get control back at runtime). >>> What it doesn't support is attempts to do a load from the vector page, >>> because so far nobody has had a need to probe the vector page for what >>> it supports. >> >> To solve that particular problem, can you just map a page in RAM with the >> right content for __kernel_helper_version? > > We could, but that's dependent on the target system letting us do that. > (for that matter if the target system decided to map another page there > it won't fault access to it and then we're going to get who knows what).
To clarify, that's the system we're running on (usually x86, more often called the "host system"). This is because in linux-user emulation mode QEMU doesn't completely manage the guest address space, but just exposes a contiguous chunk of the host QEMU process' address space to the target. So if the host kernel has mapped something in the area corresponding to where the guest vector page is supposed to be then you're stuck. (This implementation has other problems, eg https://bugs.launchpad.net/qemu-linaro/+bug/806873 but has the advantage of being fast... In the long term I quite like the idea suggested by rth on qemu-devel of making the linux-user mode use qemu's softmmu so we actually control the guest process address space completely; however that's a fairly substantial bit of rework.) -- PMM _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
