On 8/5/19 5:29 PM, David Hildenbrand wrote:
> Let's select the ASC before calling the function and use MMU_DATA_LOAD.
> This is a preparation to:
> - Remove the ASC magic depending on the access mode from mmu_translate
> - Implement IEP support, where we could run into access exceptions
> trying to fetch instructions
>
> Signed-off-by: David Hildenbrand <da...@redhat.com>
> ---
> target/s390x/helper.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
> index 13ae9909ad..08166558a0 100644
> --- a/target/s390x/helper.c
> +++ b/target/s390x/helper.c
> @@ -58,7 +58,15 @@ hwaddr s390_cpu_get_phys_page_debug(CPUState *cs, vaddr
> vaddr)
> vaddr &= 0x7fffffff;
> }
>
> - if (mmu_translate(env, vaddr, MMU_INST_FETCH, asc, &raddr, &prot,
> false)) {
> + /*
> + * We want to read the code, however, not run into access exceptions
Is this really a safe assumption here that we always use this to
translate code addresses and not data addresses? ... I don't think so.
For example with the "gva2gpa" HMP command, I'd rather expect that it
also works with the secondary space mode...?
So maybe we need a proper MemTxAttrs bit or something similar for
distinguishing instruction accesses from data accesses here?
Thomas
