Thanks for all your answers. I understand that what I want to achieve seemed pretty confused. I will try to clarify :
On real hardware, I have an I2C device used to get temperatures, pressure etc... and it works on x86 and there were no QEMU virtualized hardware corresponding. I don't really need to simulate the I2C hardware in QEMU. Indeed, there are few of them just sending regular i2c data. For some tests, I want to be able to send/receive these ones from my daemon on the host. After some researches, what I was thinking about was : 1) Use virtio-serial and write an I2C driver (guest kernel) that would give/take data to/from i2c-1 and read/write to vportp0... Seemed a bit ugly, so I wanted to try something else. 2) Write virtio-i2c (using i2c-driver and virtio kernel basics) that would register, for example, i2c-1 and get/send data from my guest app, and use virtio to send these data to host. What I have done for now : I used virtio-serial / virtio-console in linux kernel and inspired from virtio-pci to try to registers these "vport0pX" as i2c-1, i2c-2 etc... and as i2c devices. I also wrote a virtio-i2c QEMU-side to register as this hardware using virtio-i2c drivers. I think my understanding of the architecture is probably not complete, as it seems that this QEMU device doesn't automatically registers as a "virtio-i2c" hardware that would launch my guest kernel driver. My printk's in the "probe" are not printed. My driver is then never used. My questions were then : - My solution might be a bit complicated assuming I don't have that much knowledge in the architecture (however I'm interested into learning...) - Are there solutions that seems more adapted to my case ? Like using USB-I2C bridge ? 2014-02-14 17:45 GMT+01:00 Paolo Bonzini <pbonz...@redhat.com>: > Il 14/02/2014 17:31, Andreas Färber ha scritto: > > While that is certainly possible in case host passthrough was desired, >> maybe virtio was mixed up with VFIO? >> > > I don't think so, VFIO is mostly about IOMMUs and protecting from DMA. > > Paolo >
