On Sat, Jul 09, 2011 at 12:29:01AM +0100, Peter Maydell wrote:
On 8 July 2011 19:32, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 8 Jul 2011, Dave Martin wrote:
On Fri, Jul 08, 2011 at 12:21:27AM +0100, David Gilbert wrote:
Nicolas just added; Richard's argument is that if it was actually a VDSO I'd just have linked against a symbol and if the symbol wasn't there then I would have got a fairly normal linker error - I wouldn't have needed any special code; and to be honest I think that would also solve the problem that accessing that wacky address is also a pain for things like qemu because we're going to have to intercept that read.
Note that pre-existing code already calls into the vectors page.
Right, qemu must be intercepting it already. The kernel helpers located at a fixed address in the vector page have been around for more than 6 years.
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?
The value there can be a static feature of QEMU, indicating which kuser helper functions QEMU knows how to emulate.
User processes shouldn't read anything else from the vectors page, at least for now.
Cheers ---Dave