kernel bug in "Drop WIMG in favour of new constants"?

[Aneesh Kumar K.V]

Benjamin Herrenschmidt <benh at au1.ibm.com> writes:

> 	
>  <1466054627.5400.5.camel at ellerman.id.au>
> 	
> 	
>  <20160616055746.GC22590 at birch.djwong.org>
> 	
> 	
>  <8737oda1lt.fsf at skywalker.in.ibm.com>
> 	
> 	 <87ziql8l93.fsf at skywalker.in.ibm.com>
> 	 <87wplp8kxh.fsf at skywalker.in.ibm.com>
> Organization: IBM Australia
> Content-Type: text/plain; charset="UTF-8"
> X-Mailer: Evolution 3.20.3 (3.20.3-1.fc24) 
> Mime-Version: 1.0
> Content-Transfer-Encoding: 8bit
>
> On Thu, 2016-06-16 at 16:22 +0530, Aneesh Kumar K.V wrote:
>> Hmm Qemu  does
>> 
>>         /* Looks like an IO address */
>>         /* FIXME: What WIMG combinations could be sensible for IO?
>>          * For now we allow WIMG=010x, but are there others? */
>>         /* FIXME: Should we check against registered IO addresses? */
>>         if ((ptel & (HPTE64_R_W | HPTE64_R_I | HPTE64_R_M)) != HPTE64_R_I) {
>>             return H_PARAMETER;
>>         }
>> 
>> -aneesh
>
> And what do we get ? M ? I think we might be OR'ing it
> unconditionaly...
>

Yes we do. We did that for a long time. But we had special case handing
for the lpar case. I already sent a patch to update that. But I am not
sure whether to fix this in the kernel or in Qemu.

-aneesh