Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 18/02/2014 14:44, Alex David ha scritto:

Ok, thank you very much for your help then. I'm gonna spend some time on
this.

If qemu-dev / you are interested in what I've done later, I'll send a
new mail.


Yes, if you get the USB-I2C bridge to work, we'd be interested in 
including it in QEMU!


Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

Ok, thank you very much for your help then. I'm gonna spend some time on
this.

If qemu-dev / you are interested in what I've done later, I'll send a new
mail.



2014-02-18 14:05 GMT+01:00 Paolo Bonzini :

> Il 18/02/2014 13:48, Alex David ha scritto:
>
>>
>> 2014-02-17 17:11 GMT+01:00 Paolo Bonzini > >:
>>
>>
>> Il 17/02/2014 16:33, Alex David ha scritto:
>>
>> If you need more than one bus, you need a new device
>> exposing the
>> I2C bus, besides the new sensor devices.  USB-I2C could be
>> one such
>> device.
>>
>> So let me see if I understood well. USB-I2C (host QEMU device)
>> seems a
>> good idea, I could normally do : qemu-system-i386 -device
>> usb-I2c,chardev=foo -device usb-i2c,chardev=bar -chardev
>> socket,path=/tmp/test0,server,__nowait,id=foo -chardev
>> socket,path=/tmp/test1,server,__nowait,id=bar.
>>
>>
>>
>> Almost. For QOM:
>>
>> -device usb-i2c,id=usb-i2c-0
>> -device i2c-my-sensor,address=0x48,__bus=usb-i2c-0.0
>>
>> For chardev:
>>
>> -device usb-i2c,id=usb-i2c-0
>> -chardev socket,path=/tmp/test0,server,__nowait,id=chr-foo-0
>> -device
>> i2c-my-sensor,address=0x48,__bus=usb-i2c-0.0,chardev=chr-__foo-0
>>
>>
>> Repeat for the other buses, replacing -0 with -1 and -2.
>>
>>
>> I need a "USB-I2C guest kernel driver" that would register a bus
>> (i2c-1
>> for chardev foo, i2c-2 for chardev bar etc...), I guess ?
>>
>>
>> It exists already, drivers/i2c/busses/i2c-tiny-usb.c.
>>
>>
>> I'm now trying to write this new USB-I2C device, I look through some of
>> the code (dev-serial, dev-...), I used dev-serial code and removed the
>> code that wanted to declare a chardev (I don't need one to create my
>> bus, right ?).
>>
>> Now I'm wondering, how will be i2c-tiny-usb launched and declare a new
>> /dev/i2c-N, with my device. I found :
>>
>> static struct usb_device_id i2c_tiny_usb_table [] = {
>> { USB_DEVICE(0x0403, 0xc631) },   /* FTDI */
>> { USB_DEVICE(0x1c40, 0x0534) },   /* EZPrototypes */
>> { }   /* Terminating entry */
>> };
>>
>> So I figured my USB-I2C should register using these numbers ?
>>
>> static const USBDesc desc_i2c = {
>> .id = {
>> .idVendor  = 0x0403,
>> .idProduct = 0xc631,
>> .bcdDevice = 0x0400,
>> .iManufacturer = STR_MANUFACTURER,
>> .iProduct  = STR_PRODUCT_I2C,
>> .iSerialNumber = STR_SERIALNUMBER,
>> },
>> .full = &desc_device,
>> .str  = desc_strings,
>> };
>>
>> However, this doesn't work, after a $ qemu-system-i386
>> debian_wheezy_i386_standard.qcow2 -usb -device USB-I2C,id=usb-i2c-0, the
>> driver doesn't seem to be used (/sys/class/i2c-dev/i2c-0/name isn't for
>> it...), even if I modprobe i2c-tiny-usb...
>> The dmesg shows it doesn't go into the "probe" function.
>>
>> What did I miss ?
>>
>
> I honestly don't know, you'll have to debug it.
>
> Paolo
>

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 18/02/2014 13:48, Alex David ha scritto:


2014-02-17 17:11 GMT+01:00 Paolo Bonzini mailto:pbonz...@redhat.com>>:

Il 17/02/2014 16:33, Alex David ha scritto:

If you need more than one bus, you need a new device
exposing the
I2C bus, besides the new sensor devices.  USB-I2C could be
one such
device.

So let me see if I understood well. USB-I2C (host QEMU device)
seems a
good idea, I could normally do : qemu-system-i386 -device
usb-I2c,chardev=foo -device usb-i2c,chardev=bar -chardev
socket,path=/tmp/test0,server,__nowait,id=foo -chardev
socket,path=/tmp/test1,server,__nowait,id=bar.


Almost. For QOM:

-device usb-i2c,id=usb-i2c-0
-device i2c-my-sensor,address=0x48,__bus=usb-i2c-0.0

For chardev:

-device usb-i2c,id=usb-i2c-0
-chardev socket,path=/tmp/test0,server,__nowait,id=chr-foo-0
-device
i2c-my-sensor,address=0x48,__bus=usb-i2c-0.0,chardev=chr-__foo-0

Repeat for the other buses, replacing -0 with -1 and -2.


I need a "USB-I2C guest kernel driver" that would register a bus
(i2c-1
for chardev foo, i2c-2 for chardev bar etc...), I guess ?


It exists already, drivers/i2c/busses/i2c-tiny-usb.c.


I'm now trying to write this new USB-I2C device, I look through some of
the code (dev-serial, dev-...), I used dev-serial code and removed the
code that wanted to declare a chardev (I don't need one to create my
bus, right ?).

Now I'm wondering, how will be i2c-tiny-usb launched and declare a new
/dev/i2c-N, with my device. I found :

static struct usb_device_id i2c_tiny_usb_table [] = {
{ USB_DEVICE(0x0403, 0xc631) },   /* FTDI */
{ USB_DEVICE(0x1c40, 0x0534) },   /* EZPrototypes */
{ }   /* Terminating entry */
};

So I figured my USB-I2C should register using these numbers ?

static const USBDesc desc_i2c = {
.id = {
.idVendor  = 0x0403,
.idProduct = 0xc631,
.bcdDevice = 0x0400,
.iManufacturer = STR_MANUFACTURER,
.iProduct  = STR_PRODUCT_I2C,
.iSerialNumber = STR_SERIALNUMBER,
},
.full = &desc_device,
.str  = desc_strings,
};

However, this doesn't work, after a $ qemu-system-i386
debian_wheezy_i386_standard.qcow2 -usb -device USB-I2C,id=usb-i2c-0, the
driver doesn't seem to be used (/sys/class/i2c-dev/i2c-0/name isn't for
it...), even if I modprobe i2c-tiny-usb...
The dmesg shows it doesn't go into the "probe" function.

What did I miss ?


I honestly don't know, you'll have to debug it.

Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

2014-02-17 17:11 GMT+01:00 Paolo Bonzini :

> Il 17/02/2014 16:33, Alex David ha scritto:
>
>  If you need more than one bus, you need a new device exposing the
>> I2C bus, besides the new sensor devices.  USB-I2C could be one such
>> device.
>>
>> So let me see if I understood well. USB-I2C (host QEMU device) seems a
>> good idea, I could normally do : qemu-system-i386 -device
>> usb-I2c,chardev=foo -device usb-i2c,chardev=bar -chardev
>> socket,path=/tmp/test0,server,nowait,id=foo -chardev
>> socket,path=/tmp/test1,server,nowait,id=bar.
>>
>
> Almost. For QOM:
>
> -device usb-i2c,id=usb-i2c-0
> -device i2c-my-sensor,address=0x48,bus=usb-i2c-0.0
>
> For chardev:
>
> -device usb-i2c,id=usb-i2c-0
> -chardev socket,path=/tmp/test0,server,nowait,id=chr-foo-0
> -device i2c-my-sensor,address=0x48,bus=usb-i2c-0.0,chardev=chr-foo-0
>
> Repeat for the other buses, replacing -0 with -1 and -2.
>
>
>  I need a "USB-I2C guest kernel driver" that would register a bus (i2c-1
>> for chardev foo, i2c-2 for chardev bar etc...), I guess ?
>>
>
> It exists already, drivers/i2c/busses/i2c-tiny-usb.c.
>

I'm now trying to write this new USB-I2C device, I look through some of the
code (dev-serial, dev-...), I used dev-serial code and removed the code
that wanted to declare a chardev (I don't need one to create my bus, right
?).

Now I'm wondering, how will be i2c-tiny-usb launched and declare a new
/dev/i2c-N, with my device. I found :

static struct usb_device_id i2c_tiny_usb_table [] = {
{ USB_DEVICE(0x0403, 0xc631) },   /* FTDI */
{ USB_DEVICE(0x1c40, 0x0534) },   /* EZPrototypes */
{ }   /* Terminating entry */
};

So I figured my USB-I2C should register using these numbers ?

static const USBDesc desc_i2c = {
.id = {
.idVendor  = 0x0403,
.idProduct = 0xc631,
.bcdDevice = 0x0400,
.iManufacturer = STR_MANUFACTURER,
.iProduct  = STR_PRODUCT_I2C,
.iSerialNumber = STR_SERIALNUMBER,
},
.full = &desc_device,
.str  = desc_strings,
};

However, this doesn't work, after a $ qemu-system-i386
debian_wheezy_i386_standard.qcow2 -usb -device USB-I2C,id=usb-i2c-0, the
driver doesn't seem to be used (/sys/class/i2c-dev/i2c-0/name isn't for
it...), even if I modprobe i2c-tiny-usb...
The dmesg shows it doesn't go into the "probe" function.

What did I miss ?

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 16:33, Alex David ha scritto:

If you need more than one bus, you need a new device exposing the
I2C bus, besides the new sensor devices.  USB-I2C could be one such
device.

So let me see if I understood well. USB-I2C (host QEMU device) seems a
good idea, I could normally do : qemu-system-i386 -device
usb-I2c,chardev=foo -device usb-i2c,chardev=bar -chardev
socket,path=/tmp/test0,server,nowait,id=foo -chardev
socket,path=/tmp/test1,server,nowait,id=bar.


Almost. For QOM:

-device usb-i2c,id=usb-i2c-0
-device i2c-my-sensor,address=0x48,bus=usb-i2c-0.0

For chardev:

-device usb-i2c,id=usb-i2c-0
-chardev socket,path=/tmp/test0,server,nowait,id=chr-foo-0
-device i2c-my-sensor,address=0x48,bus=usb-i2c-0.0,chardev=chr-foo-0

Repeat for the other buses, replacing -0 with -1 and -2.


I need a "USB-I2C guest kernel driver" that would register a bus (i2c-1
for chardev foo, i2c-2 for chardev bar etc...), I guess ?


It exists already, drivers/i2c/busses/i2c-tiny-usb.c.

Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

2014-02-17 15:30 GMT+01:00 Paolo Bonzini :

> So you cannot configure the three devices on the same bus, with three
> different addresses?


Each sensor is different on the original hardware, they are connected on
different busses. As my guest apps are calling i2c-1, i2c-2,  ,i2c-N
(and I can't change them), I will need to create those busses...


> If you need more than one bus, you need a new device exposing the I2C bus,
> besides the new sensor devices.  USB-I2C could be one such device.
>

So let me see if I understood well. USB-I2C (host QEMU device) seems a good
idea, I could normally do : qemu-system-i386 -device usb-I2c,chardev=foo
-device usb-i2c,chardev=bar -chardev
socket,path=/tmp/test0,server,nowait,id=foo -chardev
socket,path=/tmp/test1,server,nowait,id=bar.

I need a "USB-I2C guest kernel driver" that would register a bus (i2c-1 for
chardev foo, i2c-2 for chardev bar etc...), I guess ?

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 14:32, Alex David ha scritto:


But that leaves me with another problem as I now understand how I2C
works on linux... I, in fact, need at least 3 busses (for my at least 3
devices) - so i2c-0, i2c-1, i2c-2


So you cannot configure the three devices on the same bus, with three 
different addresses?



... There are applications I can't
change on the guest and opening / writing / reading on i2c-0, i2c-1 etc...

Can I just declare these busses using i2c-dev ?


If you need more than one bus, you need a new device exposing the I2C 
bus, besides the new sensor devices.  USB-I2C could be one such device.


Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

2014-02-17 14:19 GMT+01:00 Paolo Bonzini :

> Il 17/02/2014 14:11, Alex David ha scritto:
>
>  I've tried using tmp105. As my linux isn't 64bits, i'm using
>> qemu-system-i386... It crashes my computer when I use it with my linux
>> image (it's a debian .qcow2..., easy to do some tests...).
>>
>
> You mean crashes your host?
>

Yes, my host crashes... I need to hard-reboot my computer.


>
>  I will most probably need a chardev anyways, I will need to read/write
>> data when I want to.
>>
>
> Depends on how much data.  If it's just one or two ints, like tmp105, QOM
> would work too.  qmp-shell talks to QEMU via a simple JSON protocol, and it
> has simple Python bindings too.
>
>
>  static const TypeInfo mydevice_i2c_type_info = {
>> .name= TYPE_MYDEVICE_I2C,
>> .parent= TYPE_I2C_SLAVE,
>> .instance_size= sizeof(MYDEVICEI2CState),
>> .instance_init= MYDEVICE_i2c_init,
>> .class_init= mydevice_i2c_class_init,
>> };
>>
>> I will be able to add a chardev using the properties, right ?
>>
>
> Yes, using dc->props.
>
>
>  Does this seems ok for you ? So far, I understood the "props" are needed
>> for when I'm gonna declare the device at QEMU launch.
>> I am not sure if it's needed (my i2c-0 should be created anyways), but
>> in that case, how do I "plug" it on my socket on the host ?
>>
>
> Your device is not i2c-0.  i2c-0 is provided by the PC board.  Your device
> will get one address, e.g. 0x42, on the i2c bus.  You'll be able to access
> it with i2cget and i2cset using "0" as the bus address (for i2c-0) and 0x42
> as the device address on bus 0.
>
> So you'll indeed have to do something like "-chardev socket,id=foo -device
> myi2c,address=0x42,chr=foo" if you go for sockets, or just "-device
> myi2c,address=0x42" if you go for QOM.  The "chr" property should go into
> dc->props, while "address" is provided by the abstract class TYPE_I2C_SLAVE.
>
> Paolo
>


That seems fairly easy.

But that leaves me with another problem as I now understand how I2C works
on linux... I, in fact, need at least 3 busses (for my at least 3 devices)
- so i2c-0, i2c-1, i2c-2 ... There are applications I can't change on the
guest and opening / writing / reading on i2c-0, i2c-1 etc...

Can I just declare these busses using i2c-dev ?

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 14:11, Alex David ha scritto:

I've tried using tmp105. As my linux isn't 64bits, i'm using
qemu-system-i386... It crashes my computer when I use it with my linux
image (it's a debian .qcow2..., easy to do some tests...).


You mean crashes your host?


I will most probably need a chardev anyways, I will need to read/write
data when I want to.


Depends on how much data.  If it's just one or two ints, like tmp105, 
QOM would work too.  qmp-shell talks to QEMU via a simple JSON protocol, 
and it has simple Python bindings too.



static const TypeInfo mydevice_i2c_type_info = {
.name= TYPE_MYDEVICE_I2C,
.parent= TYPE_I2C_SLAVE,
.instance_size= sizeof(MYDEVICEI2CState),
.instance_init= MYDEVICE_i2c_init,
.class_init= mydevice_i2c_class_init,
};

I will be able to add a chardev using the properties, right ?


Yes, using dc->props.


Does this seems ok for you ? So far, I understood the "props" are needed
for when I'm gonna declare the device at QEMU launch.
I am not sure if it's needed (my i2c-0 should be created anyways), but
in that case, how do I "plug" it on my socket on the host ?


Your device is not i2c-0.  i2c-0 is provided by the PC board.  Your 
device will get one address, e.g. 0x42, on the i2c bus.  You'll be able 
to access it with i2cget and i2cset using "0" as the bus address (for 
i2c-0) and 0x42 as the device address on bus 0.


So you'll indeed have to do something like "-chardev socket,id=foo 
-device myi2c,address=0x42,chr=foo" if you go for sockets, or just 
"-device myi2c,address=0x42" if you go for QOM.  The "chr" property 
should go into dc->props, while "address" is provided by the abstract 
class TYPE_I2C_SLAVE.


Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

>
>
>
>>
>>  I'm emulating a bunch of sensors/actuators.
>>>
>>> If I virtualize my sensors and attach them to the i2c-dev with -device,
>>> how do I get those data on the host then ?
>>>
>>
>> It depends on your use case.
>>
>> It could be that you can make them return a constant value.
>>
>> Otherwise, you may want to use a chardev for that purpose, or finally a
>> QOM (QEMU Object Model) property.  For example, add
>>
>> CONFIG_TMP105=y
>>
>> to default-configs/x86_64-softmmu.mak before building QEMU, then do the
>> following (indented = in the guest):
>>
>> $ x86_64-softmmu/qemu-system-x86_64 --enable-kvm ~/test2.img  -m 256 \
>>-device tmp105,id=sensor,address=0x50 \
>>-qmp unix:$HOME/qmp.sock,server,nowait
>> $ qmp/qom-list -s ~/qmp.sock /machine/peripheral/sensor
>> temperature
>> @parent_bus/
>> address
>> hotpluggable
>> realized
>> type
>> $ scripts/qmp/qmp-shell ~/qmp.sock
>> (QEMU) qom-get path=/machine/peripheral/sensor property=temperature
>> {u'return': 0}
>> (QEMU) qom-get path=sensor property=address
>> {u'return': 80}
>>
>> # modprobe i2c-dev
>> # i2cget -y 0 0x50 0 w
>> 0x
>>
>> (QEMU) qom-set path=sensor property=temperature value=2
>> {u'return': {}}
>>
>> # i2cget -y 0 0x50 0 w
>> 0x0014
>>
>> For this particular sensor, you have to swap the two bytes and the result
>> is 8.8 fixed-point.
>>
>> Paolo
>>
>>
>>  Thanks for your help. As you may see, I'm not that experienced in
>>> QEMU/Linux kernel.
>>>
>>
>>
> Ok, I'm gonna try these things. I might try to use a chardev also. Thanks
> for your help !
>


I've tried using tmp105. As my linux isn't 64bits, i'm using
qemu-system-i386... It crashes my computer when I use it with my linux
image (it's a debian .qcow2..., easy to do some tests...).

I will most probably need a chardev anyways, I will need to read/write data
when I want to. I'm gonna be annoying and ask another basic question : I
wrote this in my i2c_device_test.c (QEMU device) :

static const TypeInfo mydevice_i2c_type_info = {
.name= TYPE_MYDEVICE_I2C,
.parent= TYPE_I2C_SLAVE,
.instance_size= sizeof(MYDEVICEI2CState),
.instance_init= MYDEVICE_i2c_init,
.class_init= mydevice_i2c_class_init,
};

I will be able to add a chardev using the properties, right ?

static void mydevice_i2c_class_init(ObjectClass *klass, void *data)
{
printf("Test init2\n");

I2CSlaveClass *sc = I2C_SLAVE_CLASS(klass);
DeviceClass *dc = DEVICE_CLASS(klass);

sc->init = mydevice_i2c_init;
sc->event = mydevice_i2c_event;
sc->recv = mydevice_i2c_recv;
sc->send = mydevice_i2c_send;

dc->vmsd = &mydevice_i2c_vmstate;
dc->props = mydevice_i2c_properties;
dc->realize = mydevice_i2c_realize;
}

Does this seems ok for you ? So far, I understood the "props" are needed
for when I'm gonna declare the device at QEMU launch.
I am not sure if it's needed (my i2c-0 should be created anyways), but in
that case, how do I "plug" it on my socket on the host ?

Thanks !

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

2014-02-17 11:38 GMT+01:00 Paolo Bonzini :

> Il 17/02/2014 11:01, Alex David ha scritto:
>
>  I indeed don't use paravirtualization.
>>
>
> Virtio _is_ paravirtualization. :)
>
>
Ok, now that seems much more understandable... I missed that point ha.



>
>  I'm emulating a bunch of sensors/actuators.
>>
>> If I virtualize my sensors and attach them to the i2c-dev with -device,
>> how do I get those data on the host then ?
>>
>
> It depends on your use case.
>
> It could be that you can make them return a constant value.
>
> Otherwise, you may want to use a chardev for that purpose, or finally a
> QOM (QEMU Object Model) property.  For example, add
>
> CONFIG_TMP105=y
>
> to default-configs/x86_64-softmmu.mak before building QEMU, then do the
> following (indented = in the guest):
>
> $ x86_64-softmmu/qemu-system-x86_64 --enable-kvm ~/test2.img  -m 256 \
>-device tmp105,id=sensor,address=0x50 \
>-qmp unix:$HOME/qmp.sock,server,nowait
> $ qmp/qom-list -s ~/qmp.sock /machine/peripheral/sensor
> temperature
> @parent_bus/
> address
> hotpluggable
> realized
> type
> $ scripts/qmp/qmp-shell ~/qmp.sock
> (QEMU) qom-get path=/machine/peripheral/sensor property=temperature
> {u'return': 0}
> (QEMU) qom-get path=sensor property=address
> {u'return': 80}
>
> # modprobe i2c-dev
> # i2cget -y 0 0x50 0 w
> 0x
>
> (QEMU) qom-set path=sensor property=temperature value=2
> {u'return': {}}
>
> # i2cget -y 0 0x50 0 w
> 0x0014
>
> For this particular sensor, you have to swap the two bytes and the result
> is 8.8 fixed-point.
>
> Paolo
>
>
>  Thanks for your help. As you may see, I'm not that experienced in
>> QEMU/Linux kernel.
>>
>
>
Ok, I'm gonna try these things. I might try to use a chardev also. Thanks
for your help !

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 11:01, Alex David ha scritto:

I indeed don't use paravirtualization.


Virtio _is_ paravirtualization. :)


I'm emulating a bunch of sensors/actuators.

If I virtualize my sensors and attach them to the i2c-dev with -device,
how do I get those data on the host then ?


It depends on your use case.

It could be that you can make them return a constant value.

Otherwise, you may want to use a chardev for that purpose, or finally a 
QOM (QEMU Object Model) property.  For example, add


CONFIG_TMP105=y

to default-configs/x86_64-softmmu.mak before building QEMU, then do the 
following (indented = in the guest):


$ x86_64-softmmu/qemu-system-x86_64 --enable-kvm ~/test2.img  -m 256 \
   -device tmp105,id=sensor,address=0x50 \
   -qmp unix:$HOME/qmp.sock,server,nowait
$ qmp/qom-list -s ~/qmp.sock /machine/peripheral/sensor
temperature
@parent_bus/
address
hotpluggable
realized
type
$ scripts/qmp/qmp-shell ~/qmp.sock
(QEMU) qom-get path=/machine/peripheral/sensor property=temperature
{u'return': 0}
(QEMU) qom-get path=sensor property=address
{u'return': 80}

# modprobe i2c-dev
# i2cget -y 0 0x50 0 w
0x

(QEMU) qom-set path=sensor property=temperature value=2
{u'return': {}}

# i2cget -y 0 0x50 0 w
0x0014

For this particular sensor, you have to swap the two bytes and the 
result is 8.8 fixed-point.


Paolo


Thanks for your help. As you may see, I'm not that experienced in
QEMU/Linux kernel.

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 10:38, Alex David ha scritto:


From an upstream point of view, a host passthrough device pair (one
object talking to /dev/i2c-N on the host, and one device per sensor
talking to the other object) would be the best.


i2c-N is on the guest, that's why I want to virtualize an i2c hardware
on QEMU. My idea was getting the data on a socket on the host => read
these data from my daemon. That's why virtio-serial seemed like a good
thing to use / adapt as i2c.

I'll look on the parallel solution, I don't think there's a
virtio-parallel, right ?


You do not need to use virtio at all costs.  Paravirtualization is just 
where existing hardware doesn't have the required performance or feature 
set.  If you don't use paravirtualization, you have the big advantage of 
not having to write a guest driver!


You have not answered my question.  Are you emulating a bunch of 
sensors/actuators?  Or do the sensors/actuators physically exist in the 
host?  So far I assumed the latter.


If that is not correct, and you just need to emulate a temperature 
sensor or something like that, there is already an I2C bus in the guest. 
 If you do "modprobe i2c-dev" in the guest you'll see it.  Just use 
"-device" and QEMU will attach the emulated sensor to that bus.


Something like USB-I2C is only needed if you need more than one I2C bus 
(e.g. because of two devices with the same address).  And parallel port 
I2C is probably useless for anything except passing through a host 
/dev/i2c-N to the guest.


Paolo

[Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

2014-02-17 10:19 GMT+01:00 Paolo Bonzini :

> Il 17/02/2014 09:35, Alex David ha scritto:
>
>  - Are there solutions that seems more adapted to my case ? Like using
>> USB-I2C bridge ?
>>
>
> From an upstream point of view, a host passthrough device pair (one object
> talking to /dev/i2c-N on the host, and one device per sensor talking to the
> other object) would be the best.
>

i2c-N is on the guest, that's why I want to virtualize an i2c hardware on
QEMU. My idea was getting the data on a socket on the host => read these
data from my daemon. That's why virtio-serial seemed like a good thing to
use / adapt as i2c.

I'll look on the parallel solution, I don't think there's a
virtio-parallel, right ?