Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We already have a QOM interface for this so let's use it.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Right now, DeviceInfo acts as the class for qdev.  In order to switch to a
proper ObjectClass derivative, we need to ween all of the callers off of
interacting directly with the info pointer.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

A device reset does not affect the link state, only set_link does.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Otherwise we can write beyond the buffer and corrupt memory.  This is tracked
as CVE-2012-0029.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This patch removes some unnecessary casts in the e1000 device,
introduced by commit 62ecbd35 'e1000:
Use PCI DMA stub functions'.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This updates the e1000 device emulation to use the explicit PCI DMA
functions, instead of directly calling physical memory access functions.
Signed-off-by: NEduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

[Originally sent to qemu-kvm list, but I was redirected here]

The Capabilities Pointer is NULL, so this bit shouldn't be set. The state of
this bit doesn't appear to change any behavior on Linux/Windows versions we've
tested, but it does cause Windows' PCI/PCI Express Compliance Test to balk.

I happen to have a physical 82540EM controller, and it also sets the
Capabilities Bit, but it actually has items on the capabilities list to go
with it :)
Signed-off-by: Ndann frazier <dann.frazier@canonical.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Fix up some erroneous comments in code:
interrupt pins are named A-D, the
interrupt pin register is always readonly
and isn't zeroed out on reset.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Some guests will use the standard MII status register
to verify link state.  They will not notice link changes
unless this register is updated.

Verified with Linux 3.0 and Windows XP guests.

Without this patch, ethtool will report speed and duplex as
unknown when the link is down, but still report the link as
up.  This is because the Linux e1000 driver checks the
mac_reg[STATUS] register link state before it checks speed
and duplex, but uses the phy_reg[PHY_STATUS] register for
the actual link state check.  Fix by updating both registers
on link state changes.

Linux guest before:

 (qemu) set_link e1000.0 off

 kvm-sid:~# ethtool eth0
 Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: umbg
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

 (qemu) set_link e1000.0 on

Linux guest after:

 (qemu) set_link e1000.0 off
 [   63.384221] e1000: eth0 NIC Link is Down

 kvm-sid:~# ethtool eth0
 Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: umbg
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: no

 (qemu) set_link e1000.0 on
 [   84.304582] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Reviewed-by: NRichard Henderson <rth@twiddle.net>
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Reviewed-by: NRichard Henderson <rth@twiddle.net>
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

use PCIDeviceInfo to initialize ids.
Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

And add missing ROMs to tarbin build target.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>

Rx and Tx descriptors are 16 byte aligned, so the lower bits are
ignored by real hardware. In fact, they always read back as zero on real
hardware, but probably nobody relies on that.
Signed-off-by: NKevin Wolf <mail@kevin-wolf.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Reduce spurious packet drops on RX ring empty
by verifying that we have at least 1 buffer
ahead of the time.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The PCI/PCI-X Family of Gigabit Ethernet Controllers Software
Developer’s Manual states the following about the POPTS field:

  Provides a number of options which control the handling of this
  packet.  This field is ignored except on the first data descriptor of
  a packet.

The current implementation always loads the field and its checksum
offload flags.  This patch uses only the first descriptor's POPTS field
in order to comply with the specification.

When Solaris sends multi-descriptor packets it fills in POPTS for the
first descriptor only.  Therefore this patch is necessary in order to
perform checksum offload correctly for multi-descriptor packets.
Reported-by: NDaniel Pecka <dpecka@techniservit.cz>
Reported-by: NGabriele A. Trombetti <gabriele.trombetti@itb.cnr.it>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

The spec says: Any descriptor with a non-zero status byte has been
processed by the hardware, and is ready to be handled by the software.

Thus, once we change a descriptor status to non-zero we should
never move the head backwards and try to reuse this
descriptor from hardware.

This actually happened with a multibuffer packet
that arrives when we don't have enough buffers.

Fix by checking that we have enough buffers upfront
so we never need to discard the packet midway through.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

The e1000 spec says: if software statically allocates
buffers, and uses memory read to check for completed descriptors, it
simply has to zero the status byte in the descriptor to make it ready
for reuse by hardware. This is not a hardware requirement (moving the
hardware tail pointer is), but is necessary for performing an in–memory
scan.

Thus the guest does not have to clear the status byte.  In case it
doesn't we need to clear EOP for all descriptors
except the last.  While I don't know of any such guests,
it's probably a good idea to stick to the spec.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reported-by: NJuan Quintela <quintela@redhat.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

e1000 supports multi-buffer packets larger than rxbuf_size.

This fixes the following (on linux):
- in guest: ifconfig eth1 mtu 16110
- in host: ifconfig tap0 mtu 16110
           ping -s 16082 <guest-ip>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

If bootindex is specified on command line a string that describes device
in firmware readable way is added into sorted list. Later this list will
be passed into firmware to control boot order.
Signed-off-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

The e1000 has compatibility code to handle big endianness which makes it
mandatory to be recompiled on different targets.

With the generic mmio endianness solution, there's no need for that anymore.
We just declare all mmio to be little endian and call it a day.

Because we don't depend on the target endianness anymore, we can also
move the driver over to Makefile.objs.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

As stated before, devices can be little, big or native endian. The
target endianness is not of their concern, so we need to push things
down a level.

This patch adds a parameter to cpu_register_io_memory that allows a
device to choose its endianness. For now, all devices simply choose
native endian, because that's the same behavior as before.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

There is no need for these type casts (as other existing
code shows). So re-write the first argument without
type cast (and remove a related TODO comment).

Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This patch adds missing braces around if/else statements that call
macros which are likely to result in errors if the macro is
changed. It also makes the code comply better with CODING_STYLE.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When adding the length to the pseudo header, we're not properly
accounting for overflow.

From: Mark Wu <dwu@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

When adding the length to the pseudo header, we're not properly
accounting for overflow.

From: Mark Wu <dwu@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The OpenIndiana (Solaris) e1000g driver drops frames that are too long
or too short.  It expects to receive frames of at least the Ethernet
minimum size.  ARP requests in particular are small and will be dropped
if they are not padded appropriately, preventing a Solaris VM from
becoming visible on the network.
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Patch b0b90007 made
TOR valuer incorrect: the spec says it should always
include the CRC field.
No one seems to use this field, but better to stick to spec.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This change fixes initialization of e1000's microwire EEPROM internal
state values so that qemu's e1000 emulation works on NetBSD,
which doesn't use Intel's em driver but has its own wm driver
for the Intel i8254x Gigabit Ethernet.

Previously set_eecd() function in e1000.c clears EEPROM internal state
values on SK rising edge during CS==L, but according to FM93C06 EEPROM
(which is MicroWire compatible) data sheet, EEPROM internal status
should be cleared on CS rise edge regardless of SK input:
 "... a rising edge on this (CS) signal is required to reset the internal
  state-machine to accept a new cycle .."
and nothing should be changed during CS (chip select) is inactive.

Intel's em driver seems to explicitly raise SK output after CS is negated
in em_standby_eeprom() so many other OSes that use Intel's driver
don't have this problem even on the previous e1000.c implementation,
but I can't find any articles that say the MICROWIRE or EEPROM spec
requires such sequence, and actually hardware works fine without it
(i.e. real i82540EM has been working on NetBSD).

This fix also changes initialization to clear each state value in
struct eecd_state individually rather than using memset() against
the whole structre. The old_eecd member stores the last SK and CS
signal levels and it should be preserved even after reset of internal
EEPROM state to detect next signal edges for proper EEPROM emulation.
Signed-off-by: NIzumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Add support for secrc field. Reportedly needed by old RHEL guests.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

We do range check for size, and get size as buffer,
but copy size + 4 bytes (4 is for FCS).
Let's copy size bytes but put size + 4 in length.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Change #define DEBUG to #define E1000_DEBUG in hw/e1000.c to make
it possible to build QEMU with -DDEBUG
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

There was a pointer cast warning on Ubuntu since _FORTIFY_SOURCE has been reenabled.

_FORTIFY_SOURCE had been disabled by 4a244704
and reenabled by 84958305.
Signed-off-by: NThomas Monjalon <thomas@monjalon.net>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Link to data sheet at intel.com so people can find it.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

No functional changes. I verified that the generated
object binary does not change.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NJuan Quintela <quintela@redhat.com>
Acked-by: NGlauber Costa <glommer@gmail.com>

Otherwise, the driver does not work in Linux after the INT_DISABLE changes in
PCI.

Michael Tsirkin had a patch to do this, I'm not sure what happened to it.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This patch adds a romfile property to the pci bus.  It allows to specify
a romfile to load into the rom bar of the pci device.  The default value
comes from a new field in PCIDeviceInfo.  The property allows to change
the file and also to disable the rom loading using an empty string.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Currently, we preload option roms into the option rom space in memory.  This
prevents DDIM from functioning correctly which severely limits the number
of roms we can support.

This patch introduces a pci_add_option_rom() which registers the
PCI_ROM_ADDRESS bar which points to our option rom.  It also converts over
the cirrus vga adapter, the rtl8139, virtio, and the e1000 to use this
new mechanism.

The result is that PXE boot functions even with three unique types of cards.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>