linux-kernel - Re: Current kernel fails to compile with KVM on PowerPC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 Feb 2012 00:54:44 +0100
From:	Alexander Graf <agraf@...e.de>
To:	Jörg Sommer <joerg@...a.gnuu.de>
Cc:	Avi Kivity <avi@...hat.com>, Marcelo Tosatti <mtosatti@...hat.com>,
	kvm list <kvm@...r.kernel.org>, kvm-ppc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Current kernel fails to compile with KVM on PowerPC


On 26.02.2012, at 01:06, Jörg Sommer wrote:

> Jörg Sommer hat am Sat 25. Feb, 15:51 (+0100) geschrieben:
>> Jörg Sommer hat am Tue 21. Feb, 09:32 (+0100) geschrieben:
>>> Alexander Graf hat am Mon 20. Feb, 22:27 (+0100) geschrieben:
>>>> On 20.02.2012, at 18:38, Jörg Sommer wrote:
>>>>> Alexander Graf hat am Tue 22. Nov, 22:29 (+0100) geschrieben:
>>>>>> On 22.11.2011, at 21:04, Jörg Sommer wrote:
>>>>>>> [1] »kernel BUG at include/linux/kvm_host.h:603!«
>>>>>>> http://www.mail-archive.com/kvm@vger.kernel.org/msg61433.html
>>>>>> 
>>>>>> This is unfortunately still there. It's because of preemption being
>>>>>> enabled. Please just use CONFIG_PREEMPT_NONE for the time being
>>>>> 
>>>>> This doesn't help. I've build with CONFIG_PREEMPT_NONE, but I'm getting
>>>>> this Oops, when I start qemu.
>>>> 
>>>> Could you please try git://git.kernel.org/pub/scm/virt/kvm/kvm.git? I
>>>> fixed a bunch of things with preemption since then and it definitely
>>>> worked for me. If it still fails in that tree, I can try again to
>>>> reproduce it :).
>>> 
>>> This kernel (e9badff4b38a3f8b2c20aa8a30db210caf85a497) fails to build:
>>> 
>>>  CC [M]  arch/powerpc/kvm/book3s_pr.o
>>> arch/powerpc/kvm/book3s_pr.c: In function ‘kvm_vcpu_ioctl_get_one_reg’:
>>> arch/powerpc/kvm/book3s_pr.c:883:45: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>>> arch/powerpc/kvm/book3s_pr.c:883:80: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>>> arch/powerpc/kvm/book3s_pr.c:883:284: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>>> arch/powerpc/kvm/book3s_pr.c:883:327: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>>> arch/powerpc/kvm/book3s_pr.c:883:459: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>>> arch/powerpc/kvm/book3s_pr.c:883:748: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>>> arch/powerpc/kvm/book3s_pr.c:883:1112: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>>> arch/powerpc/kvm/book3s_pr.c:883:1476: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>>> arch/powerpc/kvm/book3s_pr.c:883:1867: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
> 
>> @@ -652,6 +653,11 @@ static int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
>>        int r = -EINVAL;
>> 
>>        switch (reg->id) {
>> +#ifdef CONFIG_PPC_BOOK3S
>> +       case KVM_REG_PPC_HIOR:
>> +               r = put_user(to_book3s(vcpu)->hior, (u64 __user *)reg->addr);
>> +               break;
>> +#endif
>>        default:
>>                break;
>>        }
> 
> Is this the right fix for this code?

The idea of the put/get_user is to access memory that is at the address "reg->addr". The code works as expected on book3s_64 for me too, where sizeof(u64) == sizeof(ulong). On book3s_32 however, sizeof(ulong) is 4, which is not the same as the size of reg->addr, which is u64, thus 8.

So we need to tell the compiler to cut off the high 32 bits (because we can't access them anyways) and instead take the lower 32 bits as the pointer at which address we want to access things. That's basically what the patch I sent out earlier today did :).


Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/