All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: "Jörg Sommer" <joerg@alea.gnuu.de>
Cc: Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	kvm list <kvm@vger.kernel.org>,
	kvm-ppc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Current kernel fails to compile with KVM on PowerPC
Date: Mon, 27 Feb 2012 00:54:44 +0100	[thread overview]
Message-ID: <B4D3CBBA-2863-4735-A655-563840992518@suse.de> (raw)
In-Reply-To: <20120226000630.GC22460@alea.gnuu.de>


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


WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: "Jörg Sommer" <joerg@alea.gnuu.de>
Cc: Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	kvm list <kvm@vger.kernel.org>,
	kvm-ppc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Current kernel fails to compile with KVM on PowerPC
Date: Sun, 26 Feb 2012 23:54:44 +0000	[thread overview]
Message-ID: <B4D3CBBA-2863-4735-A655-563840992518@suse.de> (raw)
In-Reply-To: <20120226000630.GC22460@alea.gnuu.de>


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


  reply	other threads:[~2012-02-26 23:54 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07 19:48 Current kernel fails to compile with KVM on PowerPC Jörg Sommer
2011-11-07 19:48 ` Jörg Sommer
2011-11-07 20:16 ` Avi Kivity
2011-11-07 20:16   ` Avi Kivity
2011-11-07 20:43   ` Alexander Graf
2011-11-07 20:43     ` Alexander Graf
2011-11-22 20:04 ` Jörg Sommer
2011-11-22 20:04   ` Jörg Sommer
2011-11-22 21:29   ` Alexander Graf
2011-11-22 21:29     ` Alexander Graf
2011-12-11 15:16     ` Jörg Sommer
2011-12-11 15:16       ` Jörg Sommer
2011-12-12  7:26       ` Alexander Graf
2011-12-12  7:26         ` Alexander Graf
2012-02-20 17:38     ` Jörg Sommer
2012-02-20 17:38       ` Jörg Sommer
2012-02-20 21:27       ` Alexander Graf
2012-02-20 21:27         ` Alexander Graf
2012-02-21  8:32         ` Jörg Sommer
2012-02-21  8:32           ` Jörg Sommer
2012-02-25 14:51           ` Jörg Sommer
2012-02-25 14:51             ` Jörg Sommer
2012-02-26  0:06             ` Jörg Sommer
2012-02-26  0:06               ` Jörg Sommer
2012-02-26 23:54               ` Alexander Graf [this message]
2012-02-26 23:54                 ` Alexander Graf
2012-02-26 11:43             ` Alexander Graf
2012-02-26 11:43               ` Alexander Graf
2012-02-27  0:08               ` Jörg Sommer
2012-02-27  0:08                 ` Jörg Sommer
2012-02-27  0:30                 ` Alexander Graf
2012-02-27  0:30                   ` Alexander Graf
2012-02-27 11:31                   ` Jörg Sommer
2012-02-27 11:31                     ` Jörg Sommer
2011-12-20 20:27 ` Jörg Sommer
2011-12-20 20:27   ` Jörg Sommer
2011-12-23 13:50   ` Alexander Graf
2011-12-23 13:50     ` Alexander Graf
2011-12-24 10:31     ` Jörg Sommer
2011-12-24 10:31       ` Jörg Sommer
2011-12-24 11:13       ` Jörg Sommer
2011-12-24 11:13         ` Jörg Sommer
2011-12-24 17:05         ` Alexander Graf
2011-12-24 17:05           ` Alexander Graf
2011-12-25  9:38           ` Avi Kivity
2011-12-25  9:38             ` Avi Kivity
2011-12-25 11:01           ` Jörg Sommer
2011-12-25 11:01             ` Jörg Sommer
2011-12-26 14:18             ` Alexander Graf
2011-12-26 14:18               ` Alexander Graf
2011-12-24 10:59     ` Jörg Sommer
2011-12-24 10:59       ` Jörg Sommer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B4D3CBBA-2863-4735-A655-563840992518@suse.de \
    --to=agraf@suse.de \
    --cc=avi@redhat.com \
    --cc=joerg@alea.gnuu.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.