[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] target/ppc: Fix truncation of env->hflags
From: |
Richard Henderson |
Subject: |
Re: [PATCH] target/ppc: Fix truncation of env->hflags |
Date: |
Sun, 24 Jan 2021 09:38:04 -1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 1/23/21 6:46 PM, David Gibson wrote:
> On Sat, Jan 23, 2021 at 05:24:22PM -1000, Richard Henderson wrote:
>> Use the cs_base field, because it happens to be the same
>> size as hflags (and MSR, from which hflags is derived).
>>
>> In translate, extract most bits from a local hflags variable.
>> Mark several cases where code generation is *not* derived from
>> data stored within the hashed elements of the TranslationBlock.
>
> My knowledge of TCG isn't great, so I'm pretty much prepared to accept
> this is correct on your say so.
>
> But that commit message feels like it's following on from a
> conversation that's not here, nor linked. It'd be great if it
> explained how said hflags truncation is happening, because it's
> certainly not obvious to someone with only a fair to middling
> understanding of TCG.
Mm, fair.
How about:
The assignment from env->hflags to tb->flags truncates
target_ulong to uint32_t. This loses important bits from
the top of hflags, which results in incorrect tb selection.
Use the cs_base field instead, because it happens to be the
same size as hflags (and MSR fom which hflags is derived).
In translate, extract most bits from a local hflags variable.
All of the checks vs env->flags are redundant with env->msr_mask
in that msr bits cannot be set when the feature is not available.
Mark several cases where code generation is *not* derived from
data stored within hashed elements of the tb.
r~