Hi Viresh,

> If you look at i2c_smbus_xfer_emulated(), the command is always sent via
> msgbuf0[0]. Even in the case of I2C_SMBUS_QUICK, where we set msg[0].len = 0, we
> still send the buf. This is really confusing :(
> 
> Do I understand correctly that we always need to send msg[0].buf even when
> msg[0].len is 0 ?

Nope, I think you misinterpreted that. SMBUS_QUICK will not send any
byte. After the address phase (with the RW bit as data), a STOP will
immediately follow. len = 0 will ensure that.

msgbuf0[0] is set to 'command' because every mode except SMBUS_QUICK
will need that. So, it is convenient to always do it. For SMBUS_QUICK
it is superfluous but does not hurt.

> If so, it would be difficult to implement this with the current i2c virtio
> specification, as the msg.len isn't really passed from guest to host, rather it
> is inferred using the length of the buffer itself. And so we can't really pass a
> buffer if length is 0.

And you can't leave out the buffer and assume len = 0 then? Otherwise,
you can't do SMBUS_QUICK and we need to set a struct i2c_adapter_quirks
with I2C_AQ_NO_ZERO_LEN.

Speaking of adapter quirks, currently they are not exported to
userspace. So, you can't inherit any quirks from the bus driver of the
host. It is not too bad, I think. It would mean that the host driver
will return -EOPNOTSUPP for transfers it cannot handle. Otherwise, if
quirks were inherited, we could bail out sooner at guest level, but
well...

Does this help?

Happy hacking,

   Wolfram