From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eghBq-0008CM-54 for qemu-devel@nongnu.org; Tue, 30 Jan 2018 20:29:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eghBL-0004Rq-SI for qemu-devel@nongnu.org; Tue, 30 Jan 2018 20:27:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34954) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eghBL-0004PE-Fg for qemu-devel@nongnu.org; Tue, 30 Jan 2018 20:27:23 -0500 From: Paolo Bonzini References: <201801252233.45477.pisa@cmp.felk.cvut.cz> <201801302312.59762.pisa@cmp.felk.cvut.cz> <650E61A4-F6BF-46A4-B63D-6D935925F5AE@icloud.com> <099f6d2c-ab19-f590-7b58-f5f2058c8c6b@redhat.com> Message-ID: <86d65bae-506b-b17c-faa3-4b44085879f7@redhat.com> Date: Tue, 30 Jan 2018 20:10:13 -0500 MIME-Version: 1.0 In-Reply-To: <099f6d2c-ab19-f590-7b58-f5f2058c8c6b@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V4 0/7] CAN bus support for QEMU (SJA1000 PCI so far) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Deniz Eren , Pavel Pisa Cc: Marek Vasut , Oliver Hartkopp , Stefan Hajnoczi , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org, Oleksij Rempel , Konrad Frederic , Jan Kiszka , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= 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. U= nfortunately I don=E2=80=99t have too much time to dig through at the mom= ent. >> >> 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=3Dcanbus0,host1=3Dvcan0= ,canbus2=3Dcanbus1,host2=3Dvcan1 -m size=3D2048 -netdev user,id=3Duser.0 = -device e1000,netdev=3Duser.0 -redir tcp:5022::22 -enable-kvm & >=20 > Yep, it's now like this: >=20 > ./qemu-local/bin/qemu-system-i386 \ > -hda sdd2gb-uno1483-16.04-2.0-dev.img -boot d -k en-us \ > -object can-bus,id=3Dcanbus0 \ > -object can-bus,id=3Dcanbus1 \ > -object can-host-socketcan,id=3Dcanhost0,canbus=3Dcanbus0,ifname=3Dvc= an0 \ > -object can-host-socketcan,id=3Dcanhost1,canbus=3Dcanbus1,ifname=3Dvc= an1 \ > -device mioe3680_pci,canbus0=3Dcanbus0,canbus1=3Dcanbus1 \ > -m size=3D2048 -netdev user,id=3Duser.0 -device e1000,netdev=3Duser.0= \ > -redir tcp:5022::22 -enable-kvm Sorry, all "ifname" are "if". Paolo > Thanks, >=20 > Paolo >=20 >> >> >> >> Best regards, >> Deniz >> >> Sent from my iPhone >> >> Deniz Eren >> +61 400 307 762 >> >>> On 31 Jan 2018, at 9:12 am, Pavel Pisa 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 pu= ll >>>> 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=3Dcanbus0 \ >>> -device kvaser_pci,canbus=3Dcanbus0 \ >>> -object can-host-socketcan,if=3Dcan0,canbus=3Dcanbus0,id=3Dcanbu= s0-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=3Dcan0,canbus=3Dca= nbus0: Parameter 'id' is missing >>> >>> If "-object can-bus,id=3Dcanbus0" is missing then next error is repor= ted >>> >>> qemu-system-x86_64: -object can-host-socketcan,if=3Dcan0,canbus=3Dca= nbus0,id=3Dcanbus0-socketcan: Device 'canbus0' not found >>> >>> I have inspected through monitor the state of objects >>> >>> (qemu) qom-list /objects >>> canbus0-socketcan (child) >>> type (string) >>> canbus0 (child) >>> >>> (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) >>> type (string) >>> canbus0 (child) >>> >>> (qemu) qom-list /machine/peripheral-anon/device[1] >>> bus master container[0] (child) >>> canbus (link) >>> rombar (uint32) >>> hotpluggable (bool) >>> x-pcie-lnksta-dllla (bool) >>> kvaser_pci-sja[0] (child) >>> multifunction (bool) >>> hotplugged (bool) >>> parent_bus (link) >>> romfile (str) >>> kvaser_pci-s5920[0] (child) >>> x-pcie-extcap-init (bool) >>> command_serr_enable (bool) >>> addr (int32) >>> type (string) >>> legacy-addr (str) >>> kvaser_pci-xilinx[0] (child) >>> realized (bool) >>> bus master[0] (child) >>> >>> 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 >=20