Hi Peter, Michael, On Mon, May 6, 2013 at 10:01 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 6 May 2013 10:24, Michael S. Tsirkin <m...@redhat.com> wrote: >> On Mon, May 06, 2013 at 10:08:42AM +0100, Peter Maydell wrote: >>> On 6 May 2013 09:51, Michael S. Tsirkin <m...@redhat.com> wrote: >>> > On Sun, May 05, 2013 at 11:00:24PM +0100, Peter Maydell wrote: >>> >> On 5 May 2013 22:15, Michael S. Tsirkin <m...@redhat.com> 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 >
