[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: softmmu 'at' instruction support

From: Janne Karhunen
Subject: Re: softmmu 'at' instruction support
Date: Thu, 18 Nov 2021 13:53:09 +0200

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.


We're hacking on our own hypervisor out of which most things are open
source. That code is just this

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]