[SLOF] [PATCH v1 17/27] virtio: make virtio_{get, read}_config 1.0 aware

Nikunj A Dadhania nikunj at linux.vnet.ibm.com
Mon Jan 18 16:41:34 AEDT 2016


Alexey Kardashevskiy <aik at ozlabs.ru> writes:

> On 01/18/2016 03:52 PM, Nikunj A Dadhania wrote:
>> Alexey Kardashevskiy <aik at ozlabs.ru> writes:
>>>>>
>>>>>> +		if (dev->is_modern)
>>>>>> +			val = (uint64_t)le32_to_cpu(hi) << 32 | le32_to_cpu(lo);
>>>>>> +		else
>>>>>> +			val = (uint64_t)hi << 32 | lo;
>>>>>
>>>>>
>>>>> Instead of changing the entite "case 8", you could do:
>>>>>
>>>>> 	if (dev->is_modern)
>>>>> 		val = le64_to_cpu(val);
>>>>>
>>>>>
>>>>> and that's it, is not it?
>>>>
>>>> ditto.
>>>
>>> Ditto what? I am suggesting keeping original couple of ci_read_32's (i.e.
>>> not adding lo/hi) and only do byteswap when is_modern.
>>
>> This is the complete diff:
>>
>>   +	case 8:
>>       /* We don't support 8 bytes PIO accesses
>>        * in qemu and this is all PIO
>>        */
>>   -		val = ci_read_32(confbase+offset);
>>   -		val <<= 32;
>>   -		val |= ci_read_32(confbase+offset+4);
>>
>> The legacy too has hi/lo 32bits.
>>
>>
>>   +		lo = ci_read_32(confbase+offset);
>>   +		hi = ci_read_32(confbase+offset+4);
>>   +		if (dev->is_modern)
>>   +			val = (uint64_t)le32_to_cpu(hi) << 32 | le32_to_cpu(lo);
>>   +		else
>>   +			val = (uint64_t)hi << 32 | lo;
>>
>> This is correct change.
>
>
> This change is bigger than the one I suggested and I cannot see how it is 
> functionally different, just may be unmeasurable slower. Or I am missing 
> something again?

Yes. 64-bit are represented as two different registers: lo and hi, in
case of legacy, i dont need byte-swapping. In case of 1.0, both the regs
are le, needs to be byteswapped before combining them.

In the below code, you assume that its a 64-bit value and doing a
le64_to_cpu.

      >>>> 	if (dev->is_modern)
      >>>> 		val = le64_to_cpu(val);

So (le32_to_cpu(hi) << 32 | le32_to_cpu(lo)) is not the same as
le64_to_cpu(val)

Regards
Nikunj



More information about the SLOF mailing list