All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Christoffer Dall <christoffer.dall@linaro.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	"eric.auger@st.com" <eric.auger@st.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Ashok Kumar <ashoks@broadcom.com>
Subject: Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
Date: Mon, 18 Jan 2016 15:54:05 +0100	[thread overview]
Message-ID: <569CFC8D.6050206@linaro.org> (raw)
In-Reply-To: <CAFEAcA9e7KJaXNTk-9Y6t9m5PGdA=_-=tctdH6c1HnScfi1crQ@mail.gmail.com>

On 01/18/2016 03:14 PM, Peter Maydell wrote:
> On 18 January 2016 at 13:57, Eric Auger <eric.auger@linaro.org> 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 :-)

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?

Thanks

Eric


> 
> thanks
> -- PMM
> 

  reply	other threads:[~2016-01-18 14:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-11 14:34 [Qemu-devel] [PULL 0/5] target-arm queue Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 1/5] i.MX: move i.MX31 CCM object to register array Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 2/5] hw/dma/xilinx_axidma: remove dead code Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 3/5] xlnx-zynqmp: Add support for high DDR memory regions Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax Peter Maydell
2016-01-18 13:29   ` Eric Auger
2016-01-18 13:34     ` Peter Maydell
2016-01-18 13:57       ` Eric Auger
2016-01-18 14:14         ` Peter Maydell
2016-01-18 14:54           ` Eric Auger [this message]
2016-01-18 15:55             ` Alex Williamson
2016-01-18 15:57               ` Eric Auger
2016-01-18 16:00               ` Peter Maydell
2016-01-18 16:29                 ` Markus Armbruster
2016-01-18 16:32                 ` Alex Williamson
2016-01-11 16:11 ` [Qemu-devel] [PULL 0/5] target-arm queue Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=569CFC8D.6050206@linaro.org \
    --to=eric.auger@linaro.org \
    --cc=alex.williamson@redhat.com \
    --cc=ashoks@broadcom.com \
    --cc=christoffer.dall@linaro.org \
    --cc=eric.auger@st.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.