* Re: [RFC PATCH v3 5/6] kvm/ppc/mpic: in-kernel MPIC emulation
[not found] <1365026850.25627.16@snotra>
@ 2013-04-03 23:23 ` Scott Wood
0 siblings, 0 replies; only message in thread
From: Scott Wood @ 2013-04-03 23:23 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev, <paulus@samba.org>, Alexander Graf,
<kvm-ppc@vger.kernel.org>, <kvm@vger.kernel.org>
On 04/03/2013 05:07:30 PM, Scott Wood wrote:
> On 04/03/2013 04:58:56 PM, Alexander Graf wrote:
>>=20
>>=20
>> Am 03.04.2013 um 23:38 schrieb Scott Wood <scottwood@freescale.com>:
>>=20
>> > On 04/03/2013 11:19:42 AM, Alexander Graf wrote:
>> >> On 03.04.2013, at 03:57, Scott Wood wrote:
>> >> > + switch (attr->group) {
>> >> > + case KVM_DEV_MPIC_GRP_MISC:
>> >> > + switch (attr->attr) {
>> >> > + case KVM_DEV_MPIC_BASE_ADDR:
>> >> > + mutex_lock(&opp->kvm->slots_lock);
>> >> > + attr64 =3D opp->reg_base;
>> >> > + mutex_unlock(&opp->kvm->slots_lock);
>> >> > +
>> >> > + if (copy_to_user((u64 __user *)(long)attr->addr,
>> >> > + &attr64, sizeof(u64)))
>> >> u64 is tricky with put_user on 32bit hosts, so here copy_to_user =20
>> makes sense
>> >
>> > What are the issues with put_user? It looks like it's supported =20
>> with a pair of "stw" instructions.
>>=20
>> Oh? Last time I tried to use get/put_user for one_reg it failed on =20
>> ppc32. So maybe the u64 support is new?
>=20
> Not new according to git -- though I haven't tried to use it yet; =20
> maybe it's broken.
Yeah, it's broken. :-P
__get_user_size() looks OK, but __get_user_check/nocheck() goes through =20
an intermediary "unsigned long __gu_val".
There's a separate __get_user64_nocheck() that uses "long long", but no =20
"check" variant, no "put", and it's only available in 32-bit builds. =20
And it's not used anywhere (barring ungreppable token-pasting magic). =20
Sigh.
-Scott=
^ permalink raw reply [flat|nested] only message in thread