From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyH98-0001ct-Fo for qemu-devel@nongnu.org; Tue, 09 Dec 2014 04:32:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyH90-000115-HF for qemu-devel@nongnu.org; Tue, 09 Dec 2014 04:31:54 -0500 Received: from s16892447.onlinehome-server.info ([82.165.15.123]:51641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyH90-0000wP-AO for qemu-devel@nongnu.org; Tue, 09 Dec 2014 04:31:46 -0500 Message-ID: <5486C15F.3000101@ilande.co.uk> Date: Tue, 09 Dec 2014 09:31:11 +0000 From: Mark Cave-Ayland MIME-Version: 1.0 References: <5485BD18.1050303@yandex.ru> <548696D3.90003@yandex.ru> In-Reply-To: <548696D3.90003@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Redundant VDE network List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dmitry Antipov , Stefan Hajnoczi Cc: qemu-devel On 09/12/14 06:29, Dmitry Antipov wrote: > On 12/08/2014 08:53 PM, Stefan Hajnoczi wrote: > >> Try: >> >> qemu-system-sparc -m 256 \ >> -netdev vde,sock=/tmp/vde0,id=vde0 \ >> -device ne2k_pci,netdev=vde0 \ >> -netdev vde,sock=/tmp/vde1,id=vde1 \ >> -device ne2k_pci,netdev=vde1 \ >> -hda vm0.img > > This works just fine for qemu-system-x86, but not for SPARC with lance NIC: > > qemu-system-sparc -m 256 \ > -netdev vde,sock=/tmp/vde0,id=vde0 -device lance,netdev=vde0 \ > -netdev vde,sock=/tmp/vde1,id=vde1 -device lance,netdev=vde1 \ > -hda vm0.img > > qemu-system-sparc: -device lance,netdev=vde0: Parameter 'driver' expects > pluggable device type > > It looks like PCI/sysbus emulation is incomplete/broken on SPARC. > Assuming that x86 is OK, what SPARC-specific stuff should I check? It's not that the emulation is broken (it's actually working as expected), it's due to the way in which the BIOS probes sbus devices. On real hardware, the device tree is generated by running bytecode within the ROM contained upon each card by probing a known offset within each slot, which is exactly how the cg3 and tcx cards are detected upon boot. However the since the lance device is on-board, it is hard-coded at a fixed address in both Sun's OBP and OpenBIOS rather than being probed via execution of an external ROM. It should be a fairly trivial exercise to tweak QEMU and OpenBIOS to add a second lance instance at a spare sbus slot address, but as you can see it would require some extra smarts to dynamically patch a compiled ROM within QEMU to insert the relevant properties from the device tree when trying to add another network card via -device. ATB, Mark.