Re: [Qemu-devel] [PATCH 1/3] net/vmxnet3: return 1 on device activation failure

[Dmitry Fleytman]

> On 22 Dec 2015, at 11:26 AM, Miao Yan <address@hidden> wrote:
> 
> 2015-12-22 17:06 GMT+08:00 P J P <address@hidden>:
>> +-- On Tue, 22 Dec 2015, Miao Yan wrote --+
>> | > If '1' indicates the error, the 'default:' case in the same switch needs 
>> to be
>> | > updated too.
>> |
>> | '1' indicates an error on device activation. Not sure about the 'unknown
>> | command' case.
>> 
>>  Ideally it should be same, inconsistent return codes wouldn't be helpful.
> 
> ESXi returns 0 on 'unknown command', I thought we should follow here.

Agree. This is the idea of the emulation.

> 
> 
>> 
>> | Linux driver uses VXMNET3_READ_BAR1_REG() which calls readl().
>> | That should be an indication that the driver expects 32bit values.
>> 
>>  Right.
>> 
>> | But the prototype in MemoryRegionOps requires uint64_t.
>> 
>>  That is odd. It does not seem right to use uint64_t for 32bit values, and
>> then return a negative(-1) value.
> 
> I've already sent v2 patch to change this to 0. But 'read' in MemoryRegionOps
> does require a uint64_t return type, to which vmxnet3_io_bar1_read()
> connects. Seems 'read' handles memory access of any size.

This is how QEMU device API looks like.
This doesn’t matter BTW because 64 bit value will be properly stripped to 32 
bits for 4 bytes reads.

> 
>> 
>> 
>> @Dmitry...?
>> --
>> Prasad J Pandit / Red Hat Product Security Team
>> 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F