[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PPC64 TCG problem.. MSR[SF] switching.
From: |
Ivan Warren |
Subject: |
PPC64 TCG problem.. MSR[SF] switching. |
Date: |
Sun, 24 Jan 2021 03:03:28 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 |
Hello people,
I have the following issue : I'm using an OS (not linux) on a
qemu-system-ppc64. (in my case a Power8 qemu target with a x86_64 TCG
target)
This OS provides a set of NARROW/WIDE (MSR[SF]) agnostic code snippets
in the 1st 64K of addresses (so they can be called using the PPC 'bla'
instruction). Possibly this is kernel provided code so that it can
provide the best strategy for the current runtime environment depending
on CPU model or whatever the SPAPR Hypervisor says.
One of the routine is 1st being called in NARROW mode, and the TCG
generated code reflects that. For example it (seems) to generate address
folding in the output TCG target code (looking at log out_asm output)
and/or possibly uses the 32 bit soft mmu helper (but can't be sure of
this)..
Later the vCPU is switched to WIDE mode (MSR[SF]==1) and invokes the
code again. No new code is being generated because it is already in the
TCG cache, but that code is still the NARROW mode generated TCG target
code so it fails miserably (address incorrectly truncated to 32 bit
and/or wrong MMU strategy).
The solutions (if my assumptions are correct) I believe is either to
flush the TCG output cache upon MSR[SF] switching (but that could kill
performances if there is a lot of NARROW/WIDE switches... or have 2 TCG
caches (one for narrow code and one for wide code).
It may also affect other architectures that can switch addressing modes
(for example, s390x has 3 possible different modes that can be switched
directly from problem state although it doesn't affect the MMU)..
Ideas ? Comments ?
Thanks,
--Ivan
smime.p7s
Description: S/MIME Cryptographic Signature
- PPC64 TCG problem.. MSR[SF] switching.,
Ivan Warren <=