Ok, that's what I thought. There is one corner case that I've struggled
with though: Suppose the host has an SMBus-only driver, and the
proposed driver exposes this as an I2C device to the guest, which
makes it available to guest user space (or a guest kernel driver)
using the emulated smbus command set. Is it always possible for
the host user space to turn the I2C transaction back into the
expected SMBus transaction on the host?

If an SMBus commands gets converted to I2C messages, it can be converted
back to an SMBus command. I don't see anything preventing that right
now. However, the mapping-back code does look a bit clumsy, now that I
envision it. Maybe it is better, after all, to support I2C_SMBUS
directly and pass SMBus transactions as is. It should be a tad more
effiecient, too.

Speaking of it, I recall another gory detail: SMBus has transfers named
"read block data" and "block process call". These also need special
support from I2C host controllers before they can be emulated because
the length of the read needs to be adjusted in flight. These commands
are rare and not hard to implement. However, it makes exposing what is
supported a little more difficult.

This is certainly possible, but is independent of the implementation of
the guest driver. It's up to the host to provision the devices that
are actually passed down to the guest, and this could in theory
be any combination of emulated devices with devices connected to
any of the host's physical buses. The host may also decide to remap
the addresses of the devices during passthrough.

That sounds good.