On 13 November 2014 10:46, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 13 November 2014 16:26, Tim Sander <t...@krieglstein.org> wrote:
> > This is the gcc inline assembly syntax from my kernel module written in
> c:
> > asm("mrc p15, 0, %0, c12, c0, 0" : "=r"(vbar) : : "cc");
> > asm("mrc p15, 0, %0, c12, c0, 1" : "=r"(mvbar) : : "cc"); <- not
> implemented?
> > asm("mrc p15, 4, %0, c12, c0, 0" : "=r"(hvbar) : : "cc"); <- not
> implemented?
> >
> > It seems as if neither mvbar nor hvbar are implemented and that vbar
> returns
> > zero !? I also have a problem with the addresses:
> > The fiq handler lies at 0xffff1240 but the vectors_page in Linux points
> to
> > 0xbfffe000? You where talking about the fact that the security extensions
> > where not implemented. I was not aware that the different vbar's where
> > already part of the security stuff?
>
> MVBAR is part of the Security extensions. HVBAR is part of the
> Virtualization extensions. In mainline QEMU we implement neither
> of those extensions, and so don't implement the associated
> registers. (Strictly speaking, VBAR is also only in the
> Security extensions, but we provide it as a workaround for
> guests that assume our CPUs should implement it.)
>
Peter beat me to it. None of the VBAR registers should matter in your case
which coincides with the use of hivecs.
It may be worthwhile to put a kernel breakpoint in handle_fiq_as_nmi() just
to see where it goes. If CONFIG_ARM_GIC is enabled it should take you to
your handler I suspect. Plus, if you get there then we have likely proven
that QEMU is getting the kernel to the right place. I set a BP in this
routine on my A9 run and appear to be hitting it correctly.
Let me know how I can help in debugging the QEMU side of things.
>
> -- PMM
>
