On Thu, 3 Sep 2020 at 09:19, Jie Deng <jie.deng@xxxxxxxxx> wrote: > > > On 2020/9/3 14:12, Jason Wang wrote: > > > > On 2020/9/3 下午1:34, Jie Deng wrote: > >> Add an I2C bus driver for virtio para-virtualization. > >> > >> The controller can be emulated by the backend driver in > >> any device model software by following the virtio protocol. > >> > >> This driver communicates with the backend driver through a > >> virtio I2C message structure which includes following parts: > >> > >> - Header: i2c_msg addr, flags, len. > >> - Data buffer: the pointer to the i2c msg data. > >> - Status: the processing result from the backend. > >> > >> People may implement different backend drivers to emulate > >> different controllers according to their needs. A backend > >> example can be found in the device model of the open source > >> project ACRN. For more information, please refer to > >> https://projectacrn.org. > > > > > > May I know the reason why don't you use i2c or virtio directly? > > > We don't want to add virtio drivers for every I2C devices in the guests. > This bus driver is designed to provide a way to flexibly expose the > physical > I2C slave devices to the guest without adding or changing the drivers of > the > I2C slave devices in the guest OS. So AFAIU, what you're trying to do here is "I2C slave passthrough over para-virtualized I2C bus"? While not totally crazy, that looks a bit weird since a straightforward way would be to directly assign the I2C bus controller as a passthrough device (vfio?), though I assume your goal is also having per slave VM assignment control (and not exposing the whole bus)... > > > > > >> > >> The virtio device ID 34 is used for this I2C adpter since IDs > >> before 34 have been reserved by other virtio devices. > > > > > > Is there a link to the spec patch? > > > > Thanks > > > I haven't submitted the patch to reserve the ID in spec yet. > I write the ID here because I want to see your opinions first. > > Thanks > > Regards, Loic
