Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 2月, 2012 1 次提交
  3. 04 2月, 2012 1 次提交
    • A
      qdev: register all types natively through QEMU Object Model · 39bffca2
      由 Anthony Liguori 提交于 
      This was done in a mostly automated fashion.  I did it in three steps and then
rebased it into a single step which avoids repeatedly touching every file in
the tree.

The first step was a sed-based addition of the parent type to the subclass
registration functions.

The second step was another sed-based removal of subclass registration functions
while also adding virtual functions from the base class into a class_init
function as appropriate.

Finally, a python script was used to convert the DeviceInfo structures and
qdev_register_subclass functions to TypeInfo structures, class_init functions,
and type_register_static calls.

We are almost fully converted to QOM after this commit.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      39bffca2
  5. 28 1月, 2012 3 次提交
  7. 27 1月, 2012 1 次提交
  9. 23 1月, 2012 1 次提交
  11. 13 12月, 2011 1 次提交
  13. 02 11月, 2011 1 次提交
  15. 23 9月, 2011 1 次提交
    • D
      e1000: Don't set the Capabilities List bit · dd8e9379
      由 dann frazier 提交于 
      [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>
      dd8e9379
  17. 20 9月, 2011 1 次提交
  19. 22 8月, 2011 1 次提交
    • B
      e1000: use MII status register for link up/down · d4044c2a
      由 Bjørn Mork 提交于 
      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>
      d4044c2a
  21. 08 8月, 2011 2 次提交
  23. 12 6月, 2011 1 次提交
  25. 19 4月, 2011 1 次提交
  27. 04 4月, 2011 1 次提交
  29. 29 3月, 2011 1 次提交
  31. 22 3月, 2011 1 次提交
  33. 20 2月, 2011 3 次提交
  35. 12 12月, 2010 1 次提交
  37. 11 12月, 2010 2 次提交
    • A
      e1000: Make little endian · 32600a30
      由 Alexander Graf 提交于 
      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>
      32600a30
    • A
      Add endianness as io mem parameter · 2507c12a
      由 Alexander Graf 提交于 
      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>
      2507c12a
  39. 22 11月, 2010 1 次提交
  41. 17 11月, 2010 1 次提交
  43. 16 11月, 2010 1 次提交
  45. 14 11月, 2010 1 次提交
  47. 21 9月, 2010 1 次提交
  49. 06 9月, 2010 1 次提交
  51. 22 7月, 2010 1 次提交
    • I
      e1000: Fix wrong microwire EEPROM state initialization · 9651ac55
      由 Izumi Tsutsui 提交于 
      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>
      9651ac55
  53. 19 7月, 2010 2 次提交
  55. 14 6月, 2010 1 次提交
  57. 15 5月, 2010 1 次提交
  59. 09 4月, 2010 1 次提交
  61. 23 12月, 2009 2 次提交
  63. 19 12月, 2009 1 次提交