Re: softmmu 'at' instruction support

[Janne Karhunen]

On Thu, Nov 18, 2021 at 1:41 PM Peter Maydell <peter.maydell@linaro.org> wrote:

> > This looks like a bug to me, please comment if I'm wrong:
>
> Bit hard to say without a reproduce case... You also don't
> say what QEMU version you're using.

6.1-release

We're hacking on our own hypervisor out of which most things are open
source. That code is just this
https://github.com/jkrh/kvms/blob/4c26c786be9971613b3b7f56121c1a1aa3b9585a/core/helpers.h#L74

That hypervisor can be built and run with the qemu from the github
directly, along with everything required, but it's a bit of work.
Easiest would probably be if I'd do something where you can just run
that function to resolve any kernel address with the stock kernel
while sitting in an EL2 breakpoint.


> > 0x0000000100004a3c <at_s12e1r+8>: 80 78 0c d5 at s12e1r, x0
> > 0x0000000100004a40 <at_s12e1r+12>: 01 74 38 d5 mrs x1, par_el1
> >
> > (gdb) info registers x0 x1
> > x0             0x0                 0
> > x1             0x809               2057
> >
> > So that would be translation fault level 0, stage 1 if I'm not mistaken.
>
> If you want to walk through what QEMU does and why it
> returns the fault indication, you can run QEMU under
> a debugger and put a breakpoint at ats_write64().
> That will do the page table walk (in get_phys_addr())
> and you can see where and why we decide that it should
> report a fault to the PAR_EL1.

Thanks, I'll do this and post the results here. I've been walking
around the 'get_phys_addr_lpae' a million times but not via 'at'.

Nice to hear it _should_ work.


--
Janne