From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLC9Y-0007nU-0A for qemu-devel@nongnu.org; Mon, 18 Jan 2016 10:55:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLC9U-0002wN-Pz for qemu-devel@nongnu.org; Mon, 18 Jan 2016 10:55:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55865) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLC9U-0002wI-78 for qemu-devel@nongnu.org; Mon, 18 Jan 2016 10:55:32 -0500 Message-ID: <1453132530.32741.80.camel@redhat.com> From: Alex Williamson Date: Mon, 18 Jan 2016 08:55:30 -0700 In-Reply-To: <569CFC8D.6050206@linaro.org> References: <1452522868-25550-1-git-send-email-peter.maydell@linaro.org> <1452522868-25550-5-git-send-email-peter.maydell@linaro.org> <569CE8AC.8010105@linaro.org> <569CEF51.3070203@linaro.org> <569CFC8D.6050206@linaro.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Auger , Peter Maydell Cc: Christoffer Dall , "eric.auger@st.com" , QEMU Developers , Ashok Kumar On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote: > On 01/18/2016 03:14 PM, Peter Maydell wrote: > > On 18 January 2016 at 13:57, Eric Auger > > wrote: > > > Hi Peter, > > > On 01/18/2016 02:34 PM, Peter Maydell wrote: > > > > Hmm, I guess this is changing things in that we now will have a > > > > virtio PCI device appearing if you use the default (-net nic > > > > -net user) > > > > settings. But I don't see why that would particularly interfere > > > > with VFIO passthrough, except in as much as the guest now has > > > > two network cards in it and might be preferring one as eth0 > > > > rather than the other... > > > Yes that's what currently happens I think. I get the slirp thing > > > on eth0 > > > and my passthrough'ed device on eth1. That's not very > > > straightforward > > > for the end-user to get those 2 NIC's now. In case I passthrough > > > some > > > NIC's I would have expected this default NIC not be instantiated? > >=20 > > The QEMU networking layer only knows about networking controlled > > by the -net or -netdev options (and in those cases it does disable > > the default network device). Because the back-end for passthrough > > NICs is completely unknown to QEMU (it is all done in hardware), > > I'm not sure we have any way to know that the thing you've passed > > through > > is a NIC and not some other random PCI device... > >=20 > > > Alex, how do you manage on x86 platforms with VFIO-PCI NIC? > >=20 > > ...but presumably the x86 folks have been here before us > > and know how this should work :-) No, we haven't. =C2=A0vfio-pci devices are opaque on x86, we don't know o= r care that they're NICs or HBAs or GPUs or whatever. =C2=A0If you don't wa= nt the default NIC, turn it off with -net none. =C2=A0Don't want graphics= , -nographics. =C2=A0Default QEMU devices may be useful for the commandli= ne, but do they really matter in practical use? > Yes. maybe we could create a new network backend VFIO and use that kind > of cmd line: >=20 > NET_OPTIONS=3D"-netdev VFIO,id=3Dmyeth0 \ > -device vfio-amd-xgbe,host=3De0900000.xgmac,netdev=3Dmyeth0" >=20 > In the specialized VFIO-Platform device I can easily add a dummy NICCon= f > field and add >=20 > static Property amd_xgbe_properties[] =3D { > =C2=A0=C2=A0=C2=A0=C2=A0DEFINE_NIC_PROPERTIES(VFIOAmdXgbeDevice, conf), > =C2=A0=C2=A0=C2=A0=C2=A0DEFINE_PROP_END_OF_LIST(), > }; >=20 > But it complexifies the user command line quite a lot and not sure it i= s > worth the candle? In the general case, I don't see vfio-pci going in this direction. =C2=A0= We do not want to know this much about the device. =C2=A0Thanks, Alex