qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/16] Add a -netdev option


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH 00/16] Add a -netdev option
Date: Thu, 08 Oct 2009 22:29:13 +0200
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)

Mark McLoughlin schrieb:
> Hi,
>         Here's a series of patches which gets the ball rolling on adding
> a -netdev option.
>
>         The idea is to de-emphasise the vlan support, and instead make
> a nic directly connected to a host backend the default and recommended
> configuration. We want this because it is only with this configuration
> that we feasibly add optimizations like GSO support or vhost-net.
>
>         Where we're going is that rather '-net user -net nic' being the
> default, it would instead be:
>
>   -netdev user,id=default_slirp -device e1000,netdev=default_slirp
>
>         This patch series has a lot of this done, but there's still a
> significant TODO list including:
>
>   * qdev-ify the NICs so that we can use -device rather than '-net nic'
>     which Gerd has started looking at
>
>   * add hotplug equivalent to netdev - we should probably add a 'nic='
>     argument to -netdev for this to allow changing the backend without
>     changing the frontend
>
>   * 'info network' should list netdevs
>
>   * merging in GSO support from qemu-kvm.git, substantially cleaned up
>
>   * VLAN support should be implemented as just another network client,
>     but one which is connected to multiple backends and frontends
>
>   * re-naming e.g. VLANClientState to NetClient
>
>   * killing off NICInfo
>
>   * ...
>
>         I've given this series significant testing including building
> with all targets (really!), mingw, --disable-slirp, --enable-vde,
> without TUNSETSNDBUF and running with various nic models, backends,
> with both -net and -netdev, some different guests, hotplug, ... No
> doubt I've still managed to screw something up.
>
> Cheers,
> Mark.

Hi Mark,

today, qemu's ethernet devices are a fixed combination of
MAC (Media Access Controller) and PHY (Physical Layer).

Real hardware is different: the controllers provide a MAC,
and many provide a PHY, too, but all controllers allow
one or even several external PHY(s).

Most (or all?) controllers use the same standard interface
to address their PHY (internal or external), something
which is completely missing today in qemu.

A better solution would use separate code for MAC and
PHY, so the controllers could share common code for the
PHY.

Configuration of a different PHY should be possible,
so users can run a system emulation of different
MAC-PHY combinations.

In addition to the PHY type, a PHY needs attributes
(link speed and link status).

Maybe you can address these requirements in your
redesign.

Regards,
Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]