qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 03/10] target-ppc: Rework ppc_store_slb


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH 03/10] target-ppc: Rework ppc_store_slb
Date: Wed, 27 Jan 2016 08:32:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 27.01.2016 01:04, David Gibson wrote:
> On Mon, Jan 25, 2016 at 08:22:51PM +0100, Alexander Graf wrote:
>>
>>
>> On 01/25/2016 06:15 AM, David Gibson wrote:
>>> ppc_store_slb updates the SLB for PPC cpus with 64-bit hash MMUs.
>>> Currently it takes two parameters, which contain values encoded as the
>>> register arguments to the slbmte instruction, one register contains the
>>> ESID portion of the SLBE and also the slot number, the other contains the
>>> VSID portion of the SLBE.
>>>
>>> We're shortly going to want to do some SLB updates from other code where
>>> it is more convenient to supply the slot number and ESID separately, so
>>> rework this function and its callers to work this way.
>>>
>>> As a bonus, this slightly simplifies the emulation of segment registers for
>>> when running a 32-bit OS on a 64-bit CPU.
>>>
>>> Signed-off-by: David Gibson <address@hidden>
>>> ---
>>>  target-ppc/kvm.c        |  2 +-
>>>  target-ppc/mmu-hash64.c | 24 +++++++++++++-----------
>>>  target-ppc/mmu-hash64.h |  3 ++-
>>>  target-ppc/mmu_helper.c | 14 +++++---------
>>>  4 files changed, 21 insertions(+), 22 deletions(-)
...
>>> @@ -196,7 +198,7 @@ void helper_store_slb(CPUPPCState *env, target_ulong 
>>> rb, target_ulong rs)
>>>  {
>>>      PowerPCCPU *cpu = ppc_env_get_cpu(env);
>>> -    if (ppc_store_slb(cpu, rb, rs) < 0) {
>>> +    if (ppc_store_slb(cpu, rb & 0xfff, rb & ~0xfff, rs) < 0) {
>>
>> This might truncate the esid to 32bits on 32bits hosts, no? Should be
>> 0xfffULL instead.
> 
> Good point, nice catch.

Are you sure that it is really needed? If I run the following test
program on my 64-bit system:

int main()
{
        unsigned long long ll = -1ULL;
        printf("%llx %llx\n", ll, ll & ~0xfff);
        return 0;
}

Then I get this output:

ffffffffffffffff fffffffffffff000

So it sounds like the value is sign-extended when it is cast to 64-bit.

However, if you respin this patch series anyway, then maybe better add
the ULL for clarity.

 Thomas


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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