From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLCBL-0002WA-8z for qemu-devel@nongnu.org; Mon, 18 Jan 2016 10:57:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLCBI-0003nR-2c for qemu-devel@nongnu.org; Mon, 18 Jan 2016 10:57:27 -0500 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:38133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLCBH-0003nD-C0 for qemu-devel@nongnu.org; Mon, 18 Jan 2016 10:57:23 -0500 Received: by mail-wm0-x232.google.com with SMTP id b14so129806886wmb.1 for ; Mon, 18 Jan 2016 07:57:23 -0800 (PST) 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> <1453132530.32741.80.camel@redhat.com> From: Eric Auger Message-ID: <569D0B54.5040203@linaro.org> Date: Mon, 18 Jan 2016 16:57:08 +0100 MIME-Version: 1.0 In-Reply-To: <1453132530.32741.80.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Alex Williamson , Peter Maydell Cc: Christoffer Dall , "eric.auger@st.com" , QEMU Developers , Ashok Kumar On 01/18/2016 04:55 PM, Alex Williamson wrote: > 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? >>> >>> 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... >>> >>>> Alex, how do you manage on x86 platforms with VFIO-PCI NIC? >>> >>> ...but presumably the x86 folks have been here before us >>> and know how this should work :-) > > No, we haven't. vfio-pci devices are opaque on x86, we don't know or > care that they're NICs or HBAs or GPUs or whatever. If you don't want the default NIC, turn it off with -net none. Ah OK. That's perfect then ;-) Thanks Eric Don't want graphics, -nographics. Default QEMU devices may be useful for the commandline, 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: >> >> NET_OPTIONS="-netdev VFIO,id=myeth0 \ >> -device vfio-amd-xgbe,host=e0900000.xgmac,netdev=myeth0" >> >> In the specialized VFIO-Platform device I can easily add a dummy NICConf >> field and add >> >> static Property amd_xgbe_properties[] = { >> DEFINE_NIC_PROPERTIES(VFIOAmdXgbeDevice, conf), >> DEFINE_PROP_END_OF_LIST(), >> }; >> >> But it complexifies the user command line quite a lot and not sure it is >> worth the candle? > > In the general case, I don't see vfio-pci going in this direction. We > do not want to know this much about the device. Thanks, > > Alex >