qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V4 0/7] CAN bus support for QEMU (SJA1000 PCI so


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH V4 0/7] CAN bus support for QEMU (SJA1000 PCI so far)
Date: Tue, 30 Jan 2018 20:10:13 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 30/01/2018 20:08, Paolo Bonzini wrote:
> On 30/01/2018 19:13, Deniz Eren wrote:
>> Hi Pavel, Paolo,
>>
>> I tried to rerun my environment to test however it seems the interface has 
>> changed a little and my standard program options cause complaints. 
>> Unfortunately I don’t have too much time to dig through at the moment.
>>
>> My standard startup command is:
>>
>> $ ./qemu-local/bin/qemu-system-i386 -hda sdd2gb-uno1483-16.04-2.0-dev.img 
>> -boot d -k en-us -device 
>> mioe3680_pci,canbus1=canbus0,host1=vcan0,canbus2=canbus1,host2=vcan1 -m 
>> size=2048 -netdev user,id=user.0 -device e1000,netdev=user.0 -redir 
>> tcp:5022::22 -enable-kvm &
> 
> Yep, it's now like this:
> 
> ./qemu-local/bin/qemu-system-i386 \
>   -hda sdd2gb-uno1483-16.04-2.0-dev.img -boot d -k en-us \
>   -object can-bus,id=canbus0 \
>   -object can-bus,id=canbus1 \
>   -object can-host-socketcan,id=canhost0,canbus=canbus0,ifname=vcan0 \
>   -object can-host-socketcan,id=canhost1,canbus=canbus1,ifname=vcan1 \
>   -device mioe3680_pci,canbus0=canbus0,canbus1=canbus1 \
>   -m size=2048 -netdev user,id=user.0 -device e1000,netdev=user.0 \
>   -redir tcp:5022::22 -enable-kvm

Sorry, all "ifname" are "if".

Paolo

> Thanks,
> 
> Paolo
> 
>>
>>
>>
>> Best regards,
>> Deniz
>>
>> Sent from my iPhone
>>
>> Deniz Eren
>> +61 400 307 762
>>
>>> On 31 Jan 2018, at 9:12 am, Pavel Pisa <address@hidden> wrote:
>>>
>>> Hello Paolo,
>>>
>>> thanks much for conversion to acceptable QOM model.
>>>
>>>> On Tuesday 30 of January 2018 15:15:22 Paolo Bonzini wrote:
>>>>> On 25/01/2018 22:33, Pavel Pisa wrote:
>>>>> Hello Paolo,
>>>>>
>>>>> thanks for suggestions. I understand and fully agree with your
>>>>> request to switch to QOM. I have succeed with that for CAN devices
>>>>> some time ago. It worth to be done for the rest of the objects
>>>>> but I fear that I do not find time to complete QOMification
>>>>> in reasonable future. Contributions/suggestions from other
>>>>> are welcomed. I can look for students for GSoC at our university
>>>>> or under other funding.
>>>>
>>>> Please take a look at branch can-pci-qom of github.com/bonzini/qemu.git.
>>>> Apart from QOMification of the backend include, I simplified the IRQ
>>>> handling in can_kvaser_pci (fixing bugs too I think), and removed an
>>>> unnecessary mutex.  I also moved the files to net/can and hw/net/can so
>>>> that in the future Jason (networking maintainer) can take care of pull
>>>> requests.
>>>>
>>>> I might have broken something, and the top commit in particular is
>>>> completely untested.
>>>
>>> I have run basic test with Linux kernel on both sides
>>> for one kavser_pci card on guest side and vcan (no real interface)
>>> on host side.
>>>
>>> Mesages exchange tests passed and looks OK.
>>>
>>> I have used next parameters
>>>
>>>      -object can-bus,id=canbus0 \
>>>      -device kvaser_pci,canbus=canbus0 \
>>>      -object can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan
>>>
>>> The id parameter is required for "can-host-socketcan" object.
>>> Else next error is printed
>>>
>>>  qemu-system-x86_64: -object can-host-socketcan,if=can0,canbus=canbus0: 
>>> Parameter 'id' is missing
>>>
>>> If "-object can-bus,id=canbus0" is missing then next error is reported
>>>
>>>  qemu-system-x86_64: -object 
>>> can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan: Device 
>>> 'canbus0' not found
>>>
>>> I have inspected through monitor the state of objects
>>>
>>>  (qemu) qom-list /objects
>>>  canbus0-socketcan (child<can-host-socketcan>)
>>>  type (string)
>>>  canbus0 (child<can-bus>)
>>>
>>>  (qemu) info qom-tree
>>>  /machine (pc-i440fx-2.12-machine)
>>>    ...
>>>    /peripheral-anon (container)
>>>      /device[1] (kvaser_pci)
>>>        /bus master[0] (qemu:memory-region)
>>>        /kvaser_pci-xilinx[0] (qemu:memory-region)
>>>        /kvaser_pci-s5920[0] (qemu:memory-region)
>>>        /kvaser_pci-sja[0] (qemu:memory-region)
>>>        /bus master container[0] (qemu:memory-region)
>>>    ...
>>>
>>>
>>>  (qemu) qom-list /objects
>>>  canbus0-socketcan (child<can-host-socketcan>)
>>>  type (string)
>>>  canbus0 (child<can-bus>)
>>>
>>>  (qemu) qom-list /machine/peripheral-anon/device[1]
>>>  bus master container[0] (child<qemu:memory-region>)
>>>  canbus (link<can-bus>)
>>>  rombar (uint32)
>>>  hotpluggable (bool)
>>>  x-pcie-lnksta-dllla (bool)
>>>  kvaser_pci-sja[0] (child<qemu:memory-region>)
>>>  multifunction (bool)
>>>  hotplugged (bool)
>>>  parent_bus (link<bus>)
>>>  romfile (str)
>>>  kvaser_pci-s5920[0] (child<qemu:memory-region>)
>>>  x-pcie-extcap-init (bool)
>>>  command_serr_enable (bool)
>>>  addr (int32)
>>>  type (string)
>>>  legacy-addr (str)
>>>  kvaser_pci-xilinx[0] (child<qemu:memory-region>)
>>>  realized (bool)
>>>  bus master[0] (child<qemu:memory-region>)
>>>
>>> From the user point of view, it would be nice if "can-bus"
>>> can be populated when required automatically.
>>>
>>> I am not sure, but may it be that it would worth to
>>> push can-bus objects under some category/specific
>>> container. The path /objects is quite wide.
>>> Into something like /object/can-bus or /net/can.
>>>
>>> But generally thanks much, the progress you have made
>>> in one day is really great. I hope that others check
>>> your branch. I have pushed your unmodified version into
>>> "can-pci-qom" branch of my repo
>>>
>>>  https://gitlab.fel.cvut.cz/canbus/qemu-canbus/tree/can-pci-qom
>>>
>>> It would be great if others can check that everything
>>> works in their setup. I think that then it can be pushed
>>> into mainline and some usability improvements can be
>>> done/experiment with later.
>>>
>>> Thanks much,
>>>
>>>
>>>                Pavel Pisa
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]