qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: fix 32 bit build break i


From: Alexander Graf
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: fix 32 bit build break in the page table lookup code
Date: Fri, 14 Feb 2014 10:25:29 +0100

On 13.02.2014, at 17:54, Greg Kurz <address@hidden> wrote:

> On Thu, 13 Feb 2014 15:53:16 +0100
> Alexander Graf <address@hidden> wrote:
>> 
>> On 13.02.2014, at 04:00, Aneesh Kumar K.V
>> <address@hidden> wrote:
>> 
>>> Greg Kurz <address@hidden> writes:
>>> 
>>>> The 396bb9874 commit reworked page table lookup to support kvm.
>>>> Unfortunately this breaks 32 bit build:
>>>> 
>>>> target-ppc/mmu-hash64.h: In function ‘ppc_hash64_load_hpte0’:
>>>> target-ppc/mmu-hash64.h:90:23: error: cast to pointer from integer of
>>>> different size
>>>> 
>>>> target-ppc/mmu-hash64.h: In function ‘ppc_hash64_load_hpte1’:
>>>> target-ppc/mmu-hash64.h:101:23: error: cast to pointer from integer of
>>>> different size
>>>> 
>>>> The problem is that we have two cases to handle here:
>>>> - the HTAB is external and it is accessed with a pointer
>>>> - the HTAB is emulated and it is accessed with a hwaddr
>>>> 
>>>> Depending on the way the HTAB is controlled, we should use the
>>>> appropriate type:
>>>> - controlled by kvm, it is copied to an allocated buffer (pointer)
>>>> - controlled by qemu with an allocated buffer (pointer)
>>>> - controlled by qemu with soft mmu (hwaddr)
>>>> 
>>>> This patch introduces an explicit distinction between the two cases in
>>>> the new page table lookup code.
>>> 
>>> Reviewed-by: Aneesh Kumar K.V <address@hidden>
>> 
>> I wouldn't mind something slightly lighter weight. How about this one
>> instead? If you guys think it's better to have an actual type for the
>> token I'd pull in this patch as is though.
>> 
>> 
>> Alex
>> 
> 
> I confess... I consider castings evil and favor explicit typing. :)

Heh - I dislike unions :).

> On the other hand, I have no strong opinions against your patch. The "token"
> code is quite simple and risks of confusion are low, we can live with it.
> 
> Please add:
> 
> Reviewed-by: Greg Kurz <address@hidden>
> 
> Thanks for your time.

I've folded my patch into the offending patch in my queue. That way we ensure 
bisectability of the tree.


Alex




reply via email to

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