qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] xtensa: Avoid calling get_page_addr_code()


From: Max Filippov
Subject: Re: [Qemu-devel] [RFC PATCH] xtensa: Avoid calling get_page_addr_code() from helper function
Date: Sat, 30 Jun 2018 11:55:28 -0700

On Fri, Jun 22, 2018 at 6:58 AM, Peter Maydell <address@hidden> wrote:
> The xtensa frontend calls get_page_addr_code() from its
> itlb_hit_test helper function. This function is really part
> of the TCG core's internals, and calling it from a target
> helper makes it awkward to make changes to that core code.
> It also means that we don't pass the correct retaddr to
> tlb_fill(), so we won't correctly handle the case where
> an exception is generated.
>
> The helper is used for the instructions IHI, IHU and IPFL.
>
> Change it to call cpu_ldb_code_ra() instead.
>
> Signed-off-by: Peter Maydell <address@hidden>
> ---
> This retains the current behaviour that all these insns
> may cause exceptions both for MMU permissions checks
> failures and also for "resulting physaddr doesn't point
> at memory".
>
> My reading of the ISA manual is that this isn't strictly
> correct for IHI and IHU, which ought to only cause MMU
> exceptions but not actually do a memory access. If we
> wanted to fix that, the right thing would be to split
> them into their own helper function, which could then
> just do a tlb_fill().
>
> Tagged as RFC because I don't have any xtensa test images.
>
> My motivation here is that at some point I'd like us to
> support execution from arbitrary MMIO/small MPU regions/etc,
> for which purpose get_page_addr_code() will change to return
> -1 to mean "this isn't RAM, load a single insn into a
> throwaway TB and execute it"...

I'm taking this patch, thank you. This test is not worse than
what is done for the data cache. And if it causes problem it'd
be easy to spot, because an exception code for accessing
nonexistent physical memory is very unusual.

-- 
Thanks.
-- Max



reply via email to

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