Re: [Qemu-devel] [PATCH v2 1/4] Add i.MX FEC Ethernet driver

[Peter Crosthwaite]

Hi Peter, Michael,

On Mon, May 6, 2013 at 10:01 PM, Peter Maydell <address@hidden> wrote:
> On 6 May 2013 10:24, Michael S. Tsirkin <address@hidden> wrote:
>> On Mon, May 06, 2013 at 10:08:42AM +0100, Peter Maydell wrote:
>>> On 6 May 2013 09:51, Michael S. Tsirkin <address@hidden> wrote:
>>> > On Sun, May 05, 2013 at 11:00:24PM +0100, Peter Maydell wrote:
>>> >> On 5 May 2013 22:15, Michael S. Tsirkin <address@hidden> wrote:
>>> >> > On Sun, May 05, 2013 at 07:01:34PM +0100, Peter Maydell wrote:
>
>>> > Can't board code look for instanciated controllers
>>> > and wire them up?
>>>
>>> I don't think this will work, because -device does both
>>> 'instance_init' and 'realize', and some of the things the
>>> board needs to set and wire up must be done before 'realize'.
>>
>> Well let's add a flag that tells QM to delay realize then?
>> It's not "abstract" but maybe "embedded" type?
>

This seems fundamentally flawed to me. -device should create a new
device to the users specification, whereas this flow will create a new
device to user specification but then let a machine model modify as it
sees fit.

> This still requires users to know what their board's NIC
> happens to be,

Which is ugly detail the user should not have to care about.

> and how do you match up the half-finished
> thing created with -device to the device that the board
> creates later?
>

There may also be cases where machine model want to create a NIC
regardless of whether its used or not. Relevant for sysbus NICs as we
don't have the luxury of a PCI probe process so a generic guest (e.g.
a kernel and its pre-canned dtb) may assume a NIC exists and crash if
the sysbus device is not there. I'm half tempted to pull out the
nb_nics conditionals on Zynqs NIC creation for this very reason.
Bottom line is we shouldn't have to rely on a -device or -net arg at
all to get a NIC.

>>> >> There's probably a nasty workaround involving '-global', but:
>>> >>  * that requires the user to know the device name for the
>>> >>    onboard NIC for the board, which is a regression from
>>> >>    the -net situation
>>> >>  * it's not clear how it works if the board has two NICs
>>> >>    of the same type
>>> >
>>> > How does it work now?
>>> > I am guessing each -net nic gets mapped to a random device.
>>> > At some level that's worse than documenting about internal names,
>>> > we are teaching users to learn order of initialization
>>> > by trial and error and then rely on this.
>>>
>>> Well, it gets mapped to a specific device (hopefully we pick
>>> the same order as the kernel so first nic is eth0, second
>>> is eth1, and so on). This isn't a question of initialization
>>> order, because you can happily initialize the NIC corresponding
>>> to nd_table[1] before the one for nd_table[0] if you like.
>>> It's just a matter of picking which bit of hardware we call
>>> the "first" ethernet device, in the same way that we pick
>>> one of two serial ports to call the "first" serial port.
>
>> In other words, it's an undocumented hack :(
>> Scary as it sounds, for this case I like documenting
>> internal names better.

+1 and give machine-model created NICs a reasonable naming scheme.
Could we also expose the names to the monitor somehow so they can be
looked up easily?

>
> How does that work when both internal NICs are the same kind
> of device?
>

Sanitize the naming scheme:

candence_gem.0 and cadence_gem.1 or something for Zynqs two NICs.

Regards,
Peter

> -- PMM
>