qemu-riscv
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL 04/32] target/riscv: Implement riscv_cpu_unassign


From: Palmer Dabbelt
Subject: Re: [Qemu-devel] [PULL 04/32] target/riscv: Implement riscv_cpu_unassigned_access
Date: Fri, 20 Sep 2019 15:40:32 -0700 (PDT)

On Tue, 17 Sep 2019 09:37:47 PDT (-0700), address@hidden wrote:
On Tue, Sep 17, 2019 at 6:56 AM Peter Maydell <address@hidden> wrote:

On Fri, 16 Aug 2019 at 09:57, Peter Maydell <address@hidden> wrote:
>
> On Thu, 15 Aug 2019 at 23:17, Palmer Dabbelt <address@hidden> wrote:
> > You're more than welcome to take them over.  I've got something that boots
> > Linux on my unassigned_access branch (github.com/palmer-dabbelt/qemu), but I
> > haven't sanitized the whole port for physical accesses and I haven't 
convinced
> > myself that my hook implementation is correct.
>
> Rather than doing
>    if (retaddr) {
>        cpu_restore_state(cs, retaddr, true);
>    }
>
> at the start of the hook I think you just want to pass 'retaddr'
> as the final argument to riscv_raise_exception() instead of
> using GETPC(). Other than that I think the hook itself is right.
>
> The 'git grep' regexes in docs/devel/loads-stores.rst are handy
> for finding the places where the target code is doing physical
> accesses. IIRC the only ones I found with a quick scan were the
> PTE loads in get_physical_address() via ldl_phys/ldq_phys, which will
> now return 0 and run into the 'invalid PTE' code path. I don't
> know whether your architecture requires some different behaviour
> for bus errors on page table walk than that (you might want to
> specifically code the error path anyway or comment it even if the
> behaviour is right, to be a bit more explicit that it can happen).

Gentle ping -- would somebody like to have a go at the riscv
do_transaction_failed hook conversion? I think it should be
straightforward, and riscv is now the only architecture still
using the old unassigned_access hook and preventing us from
getting rid of it entirely.

Thanks for the ping Peter, I forgot about this.

@Palmer I have taken your patches, made some changes based on Peter's
comments and rebased them on your PR branch.

I'll double check, but the hook implementation looks correct and I
can't see any other obvious unsanitised physical accesses so it should
be ok. I'll send them out today if I don't find any issues.

Thanks!


Alistair


thanks
-- PMM



reply via email to

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