From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn2TX-0004lA-3T for qemu-devel@nongnu.org; Wed, 21 May 2014 05:06:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wn2TQ-0008C1-SU for qemu-devel@nongnu.org; Wed, 21 May 2014 05:06:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn2TQ-0008BC-Gh for qemu-devel@nongnu.org; Wed, 21 May 2014 05:06:08 -0400 Date: Wed, 21 May 2014 12:04:57 +0300 From: "Michael S. Tsirkin" Message-ID: <20140521090456.GC19109@redhat.com> References: <20140520150510.GH1657@ERROL.INI.CMU.EDU> <537C6696.9000509@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <537C6696.9000509@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] e1000: allow command-line selection of card model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: romain@dolbeau.org, qemu-devel@nongnu.org, agraf@suse.de, "Gabriel L. Somlo" , stefanha@redhat.com, pbonzini@redhat.com On Wed, May 21, 2014 at 10:40:54AM +0200, Andreas F=E4rber wrote: > Hi, >=20 > Am 20.05.2014 17:05, schrieb Gabriel L. Somlo: > > Allow selection of different card models from the qemu > > command line, to better accomodate a wider range of guests. > >=20 > > Based-on-patch-by: Romain Dolbeau >=20 > If that patch carried a Signed-off-by line, you should retain it. Actually I think that would be confusing. Romain didn't sign off on *this* patch, he signed off on a previous one. A signature by Gabriel indicates Developer's Certificate of Origin 1.1 which has an option to incorporate other's work - it does not seem to require signatures by these others. > Your > From: line already indicates that it has been rewritten since. >=20 > > Signed-off-by: Gabriel Somlo > > --- > >=20 > > Based on the conversation in [2,3,4], and given that I would still li= ke > > OS X to work as close to "out of the box" as possible, I took a stab > > at isolating just the bits that allow command-line selection of the > > specific e1000 device model from Romain's patch set [1]. Hope that's > > OK with everyone :) > >=20 > > Beyond a few small style improvements, I'm still not 100% familiar wi= th > > QOM, so I wonder if there isn't a cleaner way to offer "e1000" as som= e > > sort of "alias" to the default 82540EM, instead of listing two differ= ent > > devices (e1000 and 82540EM) with otherwise 100% identical properties. > > However, if the patch is acceptable as-is, I'm happy to leave it be..= . :) > >=20 > > I tested this on Windows 7 (where the default e1000 continues to work > > as before), Linux (F20, which is fine with either model), and OS X > > (10.9 requires E1000_DEV_ID_82545EM_COPPER, which also works with pri= or > > versions starting at 10.6; and the default e1000 works on versions <=3D= 10.8). > >=20 > > Comments, suggestions, (or even a straight-forward upstream acceptanc= e > > of the patch) much appreciated ! :) > >=20 > > Thanks, > > Gabriel > >=20 > > [1] http://lists.nongnu.org/archive/html/qemu-devel/2014-03/msg01397.= html > > [2] http://lists.nongnu.org/archive/html/qemu-devel/2014-03/msg01831.= html > > [3] http://lists.nongnu.org/archive/html/qemu-devel/2014-03/msg01841.= html > > [4] http://lists.nongnu.org/archive/html/qemu-devel/2014-03/msg03669.= html > >=20 > > hw/net/e1000.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++= ---------- > > 1 file changed, 80 insertions(+), 17 deletions(-) > >=20 > > diff --git a/hw/net/e1000.c b/hw/net/e1000.c > > index 8387443..92323a3 100644 > > --- a/hw/net/e1000.c > > +++ b/hw/net/e1000.c > > @@ -69,23 +69,29 @@ static int debugflags =3D DBGBIT(TXERR) | DBGBIT(= GENERAL); > > =20 > > /* > > * HW models: > > - * E1000_DEV_ID_82540EM works with Windows and Linux > > + * E1000_DEV_ID_82540EM works with Windows, Linux, and OS X <=3D 10= .8 > > * E1000_DEV_ID_82573L OK with windoze and Linux 2.6.22, > > * appears to perform better than 82540EM, but breaks with Linux 2.6= .18 > > * E1000_DEV_ID_82544GC_COPPER appears to work; not well tested > > + * E1000_DEV_ID_82545EM_COPPER works with Linux and OS X >=3D 10.6 > > * Others never tested > > */ > > -enum { E1000_DEVID =3D E1000_DEV_ID_82540EM }; > > =20 > > /* > > * May need to specify additional MAC-to-PHY entries -- > > * Intel's Windows driver refuses to initialize unless they match > > */ > > -enum { > > - PHY_ID2_INIT =3D E1000_DEVID =3D=3D E1000_DEV_ID_82573L ? 0xcc2= : > > - E1000_DEVID =3D=3D E1000_DEV_ID_82544GC_COPPER ? = 0xc30 : > > - /* default to E1000_DEV_ID_82540EM */ 0xc20 > > -}; > > +static uint16_t >=20 > static inline uint16_t maybe? inline in c file is an optimization hint for a compiler, so really useless without a benchmark. It's useful in headers since some compilers warn about unused non-inline static functions. > > +e1000_phy_id2_init(uint16_t dev_id) { > > + switch(dev_id) { >=20 > switch (dev_id) { >=20 > > + case E1000_DEV_ID_82573L: > > + return 0xcc2; > > + case E1000_DEV_ID_82544GC_COPPER: > > + return 0xc30; > > + default: > > + return 0xc20; /* default for 82540EM and others */ > > + } > > +} > > =20 > > typedef struct E1000State_st { > > /*< private >*/ > > @@ -151,7 +157,7 @@ typedef struct E1000State_st { > > uint32_t compat_flags; > > } E1000State; > > =20 > > -#define TYPE_E1000 "e1000" > > +#define TYPE_E1000 "e1000-base" > > =20 > > #define E1000(obj) \ > > OBJECT_CHECK(E1000State, (obj), TYPE_E1000) > > @@ -235,7 +241,7 @@ static const char phy_regcap[0x20] =3D { > > static const uint16_t phy_reg_init[] =3D { > > [PHY_CTRL] =3D 0x1140, > > [PHY_STATUS] =3D 0x794d, /* link initially up with not completed= autoneg */ > > - [PHY_ID1] =3D 0x141, [PHY_ID2] =3D PHY_ID2_INIT, > > + [PHY_ID1] =3D 0x141, /* [PHY_ID2] configured per DevId, from e10= 00_reset() */ > > [PHY_1000T_CTRL] =3D 0x0e00, [M88E1000_PHY_SPEC_CTRL] =3D 0x36= 0, > > [M88E1000_EXT_PHY_SPEC_CTRL] =3D 0x0d60, [PHY_AUTONEG_ADV] =3D 0= xde1, > > [PHY_LP_ABILITY] =3D 0x1e0, [PHY_1000T_STATUS] =3D 0x3c00, > > @@ -271,8 +277,9 @@ set_interrupt_cause(E1000State *s, int index, uin= t32_t val) > > PCIDevice *d =3D PCI_DEVICE(s); >=20 > PCIDeviceClass *pdc =3D PCI_DEVICE_GET_CLASS(s); // note: not d >=20 > > uint32_t pending_ints; > > uint32_t mit_delay; > > + uint16_t dev_id =3D PCI_DEVICE_GET_CLASS(d)->device_id; >=20 > uint16_t dev_id =3D pdc->device_id; >=20 > By convention, don't use these macros inline in FOO(bar)->baz style > expressions, use a variable. > Applies elsewhere as well. > > =20 > > - if (val && (E1000_DEVID >=3D E1000_DEV_ID_82547EI_MOBILE)) { > > + if (val && (dev_id >=3D E1000_DEV_ID_82547EI_MOBILE)) { > > /* Only for 8257x */ I think above is an old bug: E1000_DEV_ID_82547EI_MOBILE is not 8257x, is it? Also ICH8 is not a 8257x either. so I think a flag in E1000State would be cleaner: bool is_8257x. in init, do a switch statement on device ID and set of 8257x ones. avoiding QOM on data path is also a good idea. > > val |=3D E1000_ICR_INT_ASSERTED; > > } > > @@ -377,6 +384,7 @@ static void e1000_reset(void *opaque) > > E1000State *d =3D opaque; > > uint8_t *macaddr =3D d->conf.macaddr.a; > > int i; > > + uint16_t dev_id =3D PCI_DEVICE_GET_CLASS(d)->device_id; > > =20 > > timer_del(d->autoneg_timer); > > timer_del(d->mit_timer); > > @@ -385,6 +393,7 @@ static void e1000_reset(void *opaque) > > d->mit_ide =3D 0; > > memset(d->phy_reg, 0, sizeof d->phy_reg); > > memmove(d->phy_reg, phy_reg_init, sizeof phy_reg_init); > > + d->phy_reg[PHY_ID2] =3D e1000_phy_id2_init(dev_id); I would just pass E1000State to e1000_phy_id2_init. > > memset(d->mac_reg, 0, sizeof d->mac_reg); > > memmove(d->mac_reg, mac_reg_init, sizeof mac_reg_init); > > d->rxbuf_min_shift =3D 1; > > @@ -1440,9 +1449,13 @@ static const VMStateDescription vmstate_e1000 = =3D { > > } > > }; > > =20 > > +/* > > + * EEPROM contents documented in Tables 5-2 and 5-3, pp. 98-102. > > + * Note: A valid DevId will be inserted during pci_e1000_init(). > > + */ > > static const uint16_t e1000_eeprom_template[64] =3D { > > 0x0000, 0x0000, 0x0000, 0x0000, 0xffff, 0x0000, 0x0000= , 0x0000, > > - 0x3000, 0x1000, 0x6403, E1000_DEVID, 0x8086, E1000_DEVID, 0x8086= , 0x3040, > > + 0x3000, 0x1000, 0x6403, 0 /*DevId*/, 0x8086, 0 /*DevId*/, 0x8086= , 0x3040, > > 0x0008, 0x2000, 0x7e14, 0x0048, 0x1000, 0x00d8, 0x0000= , 0x2700, > > 0x6cc9, 0x3150, 0x0722, 0x040b, 0x0984, 0x0000, 0xc000= , 0x0706, > > 0x1008, 0x0000, 0x0f04, 0x7fff, 0x4d01, 0xffff, 0xffff= , 0xffff, > > @@ -1511,6 +1524,7 @@ static int pci_e1000_init(PCIDevice *pci_dev) > > uint16_t checksum =3D 0; > > int i; > > uint8_t *macaddr; > > + uint16_t dev_id =3D PCI_DEVICE_GET_CLASS(pci_dev)->device_id; > > =20 > > pci_conf =3D pci_dev->config; > > =20 > > @@ -1531,6 +1545,7 @@ static int pci_e1000_init(PCIDevice *pci_dev) > > macaddr =3D d->conf.macaddr.a; > > for (i =3D 0; i < 3; i++) > > d->eeprom_data[i] =3D (macaddr[2*i+1]<<8) | macaddr[2*i]; > > + d->eeprom_data[11] =3D d->eeprom_data[13] =3D dev_id; > > for (i =3D 0; i < EEPROM_CHECKSUM_REG; i++) > > checksum +=3D d->eeprom_data[i]; > > checksum =3D (uint16_t) EEPROM_SUM - checksum; > > @@ -1564,17 +1579,25 @@ static Property e1000_properties[] =3D { > > DEFINE_PROP_END_OF_LIST(), > > }; > > =20 > > +typedef struct E1000Info_st { > > + const char *name; > > + uint16_t vendor_id; > > + uint16_t device_id; > > + uint8_t revision; > > +} E1000Info; > > + > > static void e1000_class_init(ObjectClass *klass, void *data) > > { > > DeviceClass *dc =3D DEVICE_CLASS(klass); > > PCIDeviceClass *k =3D PCI_DEVICE_CLASS(klass); > > + const E1000Info *info =3D data; > > =20 > > k->init =3D pci_e1000_init; > > k->exit =3D pci_e1000_uninit; > > k->romfile =3D "efi-e1000.rom"; > > - k->vendor_id =3D PCI_VENDOR_ID_INTEL; > > - k->device_id =3D E1000_DEVID; > > - k->revision =3D 0x03; > > + k->vendor_id =3D info->vendor_id; > > + k->device_id =3D info->device_id; > > + k->revision =3D info->revision; > > k->class_id =3D PCI_CLASS_NETWORK_ETHERNET; > > set_bit(DEVICE_CATEGORY_NETWORK, dc->categories); > > dc->desc =3D "Intel Gigabit Ethernet"; > > @@ -1583,16 +1606,56 @@ static void e1000_class_init(ObjectClass *kla= ss, void *data) > > dc->props =3D e1000_properties; > > } > > =20 > > -static const TypeInfo e1000_info =3D { > > +static const TypeInfo e1000_base_info =3D { > > .name =3D TYPE_E1000, > > .parent =3D TYPE_PCI_DEVICE, > > .instance_size =3D sizeof(E1000State), > > - .class_init =3D e1000_class_init, > > + .abstract =3D true, > > +}; > > + > > +static const E1000Info e1000_devices[] =3D { > > + { > > + .name =3D "e1000", /* default "alias" for 82540EM */ > > + .vendor_id =3D PCI_VENDOR_ID_INTEL, > > + .device_id =3D E1000_DEV_ID_82540EM, > > + .revision =3D 0x03, > > + }, > > + { > > + .name =3D "82540EM", > > + .vendor_id =3D PCI_VENDOR_ID_INTEL, > > + .device_id =3D E1000_DEV_ID_82540EM, > > + .revision =3D 0x03, > > + }, > > + { > > + .name =3D "82544GC", > > + .vendor_id =3D PCI_VENDOR_ID_INTEL, > > + .device_id =3D E1000_DEV_ID_82544GC_COPPER, > > + .revision =3D 0x03, > > + }, > > + { > > + .name =3D "82545EM", > > + .vendor_id =3D PCI_VENDOR_ID_INTEL, > > + .device_id =3D E1000_DEV_ID_82545EM_COPPER, > > + .revision =3D 0x03, > > + }, How about prefixing "e1000-" to the name? Will make it a bit more friendly to users. > > }; > > =20 > > static void e1000_register_types(void) > > { > > - type_register_static(&e1000_info); > > + int i; > > + > > + type_register_static(&e1000_base_info); > > + for (i =3D 0; i < ARRAY_SIZE(e1000_devices); i++) { > > + const E1000Info *info =3D &e1000_devices[i]; > > + TypeInfo type_info =3D {}; > > + > > + type_info.name =3D info->name; > > + type_info.parent =3D TYPE_E1000; > > + type_info.class_data =3D (void *)info; > > + type_info.class_init =3D e1000_class_init; > > + > > + type_register(&type_info); > > + } > > } > > =20 > > type_init(e1000_register_types) >=20 > The QOM modeling looks right, and I can't think of a better way to > handle "e1000" type name compatibility reliably. >=20 > What's missing is an update to tests/e1000-test.c to test those three > new devices as part of "make check" as well. May involve moving > qtest_start()/qtest_end() from main() to what is now the nop() test > function and calling qtest_add_func() four times. >=20 > Regards, > Andreas >=20 > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg