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

[Miao Yan]

2015-12-22 2:15 GMT+08:00 P J P <address@hidden>:
> +-- On Mon, 21 Dec 2015, Miao Yan wrote --+
> | So return 1 on device activation failure instead of -1;
> |
> | Signed-off-by: Miao Yan <address@hidden>
> | ---
> |  hw/net/vmxnet3.c | 2 +-
> |  1 file changed, 1 insertion(+), 1 deletion(-)
> |
> | diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
> | index e168285..9185408 100644
> | --- a/hw/net/vmxnet3.c
> | +++ b/hw/net/vmxnet3.c
> | @@ -1652,7 +1652,7 @@ static uint64_t 
> vmxnet3_get_command_status(VMXNET3State *s)
> |
> |      switch (s->last_command) {
> |      case VMXNET3_CMD_ACTIVATE_DEV:
> | -        ret = (s->device_active) ? 0 : -1;
> | +        ret = (s->device_active) ? 0 : 1;
> |          VMW_CFPRN("Device active: %" PRIx64, ret);
> |          break;
>
>   It seems okay. Considering that the function returns 'uint64_t', -1 would
> become an extremely large value. I wonder if that is intended.
>
> 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.


>
>   default:
>         VMW_WRPRN("Received request for unknown command: %x", 
> s->last_command);
>         ret = -1;
>         break;
>
>
> Why does the function return 'uint64_t' type? All return values from other
> cases seem to be within uint32_t type.

Linux driver uses VXMNET3_READ_BAR1_REG() which calls readl().
That should be an indication that the driver expects 32bit values.
But the prototype in MemoryRegionOps requires uint64_t.


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