qemu-ppc
[Top][All Lists]
Advanced

[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~



reply via email to

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