Re: [RFC PATCH v3 5/6] kvm/ppc/mpic: in-kernel MPIC emulation

Re: [RFC PATCH v3 5/6] kvm/ppc/mpic: in-kernel MPIC emulation

[Scott Wood]

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=