qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 1/3] e1000: allow command-line selection of c


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] [PATCH v4 1/3] e1000: allow command-line selection of card model
Date: Mon, 2 Jun 2014 12:17:48 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

I was looking over my submission, and have one remaining question:

On Mon, Jun 02, 2014 at 09:33:27AM -0400, Gabriel L. Somlo wrote:
> Allow selection of different card models from the qemu
> command line, to better accomodate a wider range of guests.
> 
> Signed-off-by: Romain Dolbeau <address@hidden>
> Signed-off-by: Gabriel Somlo <address@hidden>
> Reviewed-by: Michael S. Tsirkin <address@hidden>
> Reviewed-by: Peter Crosthwaite <address@hidden>
> ---
>  hw/net/e1000.c      | 120 
> +++++++++++++++++++++++++++++++++++++++++-----------
>  hw/net/e1000_regs.h |   6 +++
>  2 files changed, 102 insertions(+), 24 deletions(-)
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 8387443..1c51be8 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
>
> [...]
>
> @@ -385,6 +390,7 @@ static void e1000_reset(void *opaque)
>      d->mit_ide = 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] = edc->phy_id2;

Should this instead be "cpu_to_le16(edc->phy_id2)" ?

>      memset(d->mac_reg, 0, sizeof d->mac_reg);
>      memmove(d->mac_reg, mac_reg_init, sizeof mac_reg_init);
>      d->rxbuf_min_shift = 1;
> @@ -1440,9 +1446,13 @@ static const VMStateDescription vmstate_e1000 = {
>
>[...]
>
> @@ -1531,6 +1542,7 @@ static int pci_e1000_init(PCIDevice *pci_dev)
>      macaddr = d->conf.macaddr.a;
>      for (i = 0; i < 3; i++)
>          d->eeprom_data[i] = (macaddr[2*i+1]<<8) | macaddr[2*i];
> +    d->eeprom_data[11] = d->eeprom_data[13] = pdc->device_id;

Same here, use "cpu_to_le16()" ?

If "Yes", then how about the "phy_reg_init[]" table ? It's an array
of uint16_t's with a bunch of statically defined elements, but gets
memove()'d in place during e1000_reset in cpu format, which may not be
appropriate if the host is a big-endian machine.

I'm primarily concerned about the correctness of my own patch set here,
but wondering if e1000.c might need additional work (e.g.  phy_reg_init[]
and friends) ? :)

Thanks much,
--Gabriel



reply via email to

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