Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 02 4月, 2015 3 次提交
    • M
      hw: Mark device misusing nd_table[] FIXME · 19f33f16
      由 Markus Armbruster 提交于 
      NICs defined with -net nic are for board initialization to wire up.
Board code examines nd_table[] to find them, and creates devices with
their qdev NIC properties set accordingly.

Except "allwinner-a10" goes on a fishing expedition for NIC
configuration instead of exposing the usual NIC properties for board
code to set: it uses nd_table[0] in its instance_init() method.

Picking up the first -net nic option's configuration that way works
when the device is created by board code.  But it's inappropriate for
-device and device_add.  Not only is it inconsistent with how the
other block device models work (they get their configuration from
properties "mac", "vlan", "netdev"), it breaks when nd_table[0] has
been picked up by the board or a previous -device / device_add
already.

Example:

    $ qemu-system-arm -S -M cubieboard -device allwinner-a10
    qemu-system-arm: -device allwinner-a10: Property 'allwinner-emac.netdev' can't take value 'hub0port0', it's in use
    Aborted (core dumped)

It also breaks in other entertaining ways:

    $ qemu-system-arm -M highbank -device allwinner-a10
    qemu-system-arm: -device allwinner-a10: Unsupported NIC model: xgmac
    $ qemu-system-arm -M highbank -net nic,model=allwinner-emac -device allwinner-a10
    qemu-system-arm: Unsupported NIC model: allwinner-emac

Mark the mistake with a FIXME comment.

Cc: Li Guang <lig.fnst@cn.fujitsu.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      19f33f16
    • M
      hw: Mark devices picking up char backends actively FIXME · d71b22bb
      由 Markus Armbruster 提交于 
      Character devices defined with -serial and -parallel are for board
initialization to wire up.  Board code examines serial_hds[] and
parallel_hds[] to find them, and creates devices with their qdev
chardev properties set accordingly.

Except a few devices go on a fishing expedition for a suitable backend
instead of exposing a chardev property for board code to set: they use
serial_hds[] (often via qemu_char_get_next_serial()) or parallel_hds[]
in their realize() or init() method to connect to a backend.

Picking up backends that way works when the devices are created by
board code.  But it's inappropriate for -device or device_add.  Not
only is it inconsistent with how the other characrer device models
work (they connect to a backend explicitly identified by a "chardev"
property), it breaks when the backend has been picked up by the board
or a previous -device / device_add already.

Example:

    $ qemu-system-ppc64 -M bamboo -S -device i82378 -device pc87312 -device pc87312
    qemu-system-ppc64: -device pc87312: Property 'isa-parallel.chardev' can't take value 'parallel0', it's in use

Mark them with suitable FIXME comments.

Cc: Li Guang <lig.fnst@cn.fujitsu.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Antony Pavlov <antonynpavlov@gmail.com>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: "Andreas Färber" <andreas.faerber@web.de>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      d71b22bb
    • M
      hw: Mark devices picking up block backends actively FIXME · af9e40aa
      由 Markus Armbruster 提交于 
      Drives defined with if!=none are for board initialization to wire up.
Board code calls drive_get() or similar to find them, and creates
devices with their qdev drive properties set accordingly.

Except a few devices go on a fishing expedition for a suitable backend
instead of exposing a drive property for board code to set: they call
driver_get() or drive_get_next() in their realize() or init() method
to implicitly connect to the "next" backend with a certain interface
type.

Picking up backends that way works when the devices are created by
board code.  But it's inappropriate for -device or device_add.  Not
only is this inconsistent with how the other block device models work
(they connect to a backend explicitly identified by a "drive"
property), it breaks when the "next" backend has been picked up by the
board already.

Example:

    $ qemu-system-arm -S -M connex -pflash flash.img -device ssi-sd
    Aborted (core dumped)

Mark them with suitable FIXME comments.

Cc: Andrzej Zaborowski <balrogg@gmail.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: "Andreas Färber" <andreas.faerber@web.de>
Cc: Michael Walle <michael@walle.cc>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      af9e40aa
  3. 01 4月, 2015 6 次提交
  5. 31 3月, 2015 9 次提交
  7. 30 3月, 2015 5 次提交
  9. 28 3月, 2015 3 次提交
    • P
      Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging · 627f91b1
      由 Peter Maydell 提交于 
      # gpg: Signature made Fri Mar 27 22:19:31 2015 GMT using RSA key ID AAFC390E
# gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: FAEB 9711 A12C F475 812F  18F2 88A9 064D 1835 61EB
#      Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76  CBD0 7DEF 8106 AAFC 390E

* remotes/jnsnow/tags/ide-pull-request:
  AHCI: Protect cmd register
  AHCI: Do not (re)map FB/CLB buffers while not running
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      627f91b1
    • J
      AHCI: Protect cmd register · fc3d8e11
      由 John Snow 提交于 
      Many bits in the CMD register are supposed to be strictly read-only.
We should not be deleting them on every write.

As a side-effect: pay explicit attention to when a guest marks off
the FIS Receive or Start bits, and disable the status bits ourselves,
instead of letting them implicitly fall off.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-id: 1426283454-15590-3-git-send-email-jsnow@redhat.com
      fc3d8e11
    • J
      AHCI: Do not (re)map FB/CLB buffers while not running · a13ab5a3
      由 John Snow 提交于 
      The FIS Receive Buffer and Command List Buffer pointers
should not be edited while the FIS receive engine or
Command Receive engines are running.

Currently, we attempt to re-map the buffers every time they
are adjusted, but while the AHCI engines are off, these registers
may contain stale values, so we should not attempt to re-map these
values until the engines are reactivated.
Reported-by: NJordan Hargrave <jharg93@gmail.com>
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-id: 1426283454-15590-2-git-send-email-jsnow@redhat.com
      a13ab5a3
  11. 27 3月, 2015 11 次提交
  13. 26 3月, 2015 3 次提交