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 <p...@cmp.felk.cvut.cz> 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 >
