Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 25 9月, 2014 1 次提交
    • M
      block: Keep DriveInfo alive until BlockDriverState dies · 3ae59580
      由 Markus Armbruster 提交于 
      If the BDS's refcnt > 0, drive_del() destroys the DriveInfo, but not
the BDS.  This can happen in three places:

* Device model destruction during unplug: blockdev_auto_del()

* Xen IDE unplug: pci_piix3_xen_ide_unplug()

* drive_del command when no device model is attached: do_drive_del()

The other callers of drive_del are on error paths where refcnt == 1.

If the user somehow manages to plug in a device model using a BDS that
has gone through drive_del(), the legacy configuration passed in
DriveInfo doesn't reach the device model, and automatic deletion on
unplug doesn't work.  Worse, some device models such as scsi-disk
crash when DriveInfo doesn't exist.

This is theoretical; I didn't research an actual reproducer. The problem
was introduced when we replaced DriveInfo reference counting by BDS
reference counting in commit a94a3fac..fa510ebf.

Fix by keeping DriveInfo alive until its BDS dies.

This affects qemu_drive_opts: now you can't reuse the same ID for new
drive options until the BDS dies.  Before, you could, but since the
code always attempts to create a BDS with the same ID next, the
enclosing operation "create a new drive" failed anyway.  Different
error path, same result.

Unfortunately, the fix involves use of blockdev.c stuff from block.c,
which is a layering violation.  Fortunately, my forthcoming
BlockBackend work will get rid of it again.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NBenoît Canet <benoit.canet@nodalink.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      3ae59580
  3. 19 8月, 2014 1 次提交
  5. 06 8月, 2014 1 次提交
    • P
      backends: Introduce chr-testdev · 5692399f
      由 Paolo Bonzini 提交于 
      From: Paolo Bonzini <pbonzini@redhat.com>

chr-testdev enables a virtio serial channel to be used for guest
initiated qemu exits. hw/misc/debugexit already enables guest
initiated qemu exits, but only for PC targets. chr-testdev supports
any virtio-capable target. kvm-unit-tests/arm is already making use
of this backend.

Currently there is a single command implemented, "q".  It takes a
(prefix) argument for the exit code, thus an exit is implemented by
writing, e.g. "1q", to the virtio-serial port.

It can be used as:
   $QEMU ... \
     -device virtio-serial-device \
     -device virtserialport,chardev=ctd -chardev testdev,id=ctd

or, use:
   $QEMU ... \
     -device virtio-serial-device \
     -device virtconsole,chardev=ctd -chardev testdev,id=ctd

to bind it to virtio-serial port0.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAndrew Jones <drjones@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5692399f
  7. 23 6月, 2014 4 次提交
  9. 19 6月, 2014 3 次提交
  11. 16 6月, 2014 1 次提交
  13. 25 4月, 2014 2 次提交
  15. 14 3月, 2014 2 次提交
  17. 02 3月, 2014 1 次提交
  19. 27 2月, 2014 1 次提交
  21. 17 9月, 2013 1 次提交
  23. 12 9月, 2013 1 次提交
  25. 23 8月, 2013 1 次提交
  27. 08 8月, 2013 1 次提交
    • L
      dump: rebase from host-private RAMBlock offsets to guest-physical addresses · 56c4bfb3
      由 Laszlo Ersek 提交于 
      RAMBlock.offset                   --> GuestPhysBlock.target_start
RAMBlock.offset + RAMBlock.length --> GuestPhysBlock.target_end
RAMBlock.length                   --> GuestPhysBlock.target_end -
                                      GuestPhysBlock.target_start

"GuestPhysBlock.host_addr" is only used when writing the dump contents.

This patch enables "crash" to work with the vmcore by rebasing the vmcore
from the left side of the following diagram to the right side:

host-private
offset
relative
to ram_addr   RAMBlock                  guest-visible paddrs
            0 +-------------------+.....+-------------------+ 0
              |         ^         |     |        ^          |
              |       640 KB      |     |      640 KB       |
              |         v         |     |        v          |
  0x0000a0000 +-------------------+.....+-------------------+ 0x0000a0000
              |         ^         |     |XXXXXXXXXXXXXXXXXXX|
              |       384 KB      |     |XXXXXXXXXXXXXXXXXXX|
              |         v         |     |XXXXXXXXXXXXXXXXXXX|
  0x000100000 +-------------------+.....+-------------------+ 0x000100000
              |         ^         |     |        ^          |
              |       3583 MB     |     |      3583 MB      |
              |         v         |     |        v          |
  0x0e0000000 +-------------------+.....+-------------------+ 0x0e0000000
              |         ^         |.    |XXXXXXXXXXXXXXXXXXX|
              | above_4g_mem_size | .   |XXXX PCI hole XXXXX|
              |         v         |  .  |XXXX          XXXXX|
     ram_size +-------------------+   . |XXXX  512 MB  XXXXX|
                                   .   .|XXXXXXXXXXXXXXXXXXX|
                                    .   +-------------------+ 0x100000000
                                     .  |         ^         |
                                      . | above_4g_mem_size |
                                       .|         v         |
                                        +-------------------+ ram_size
                                                              + 512 MB

Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      56c4bfb3
  29. 27 7月, 2013 1 次提交
  31. 15 7月, 2013 1 次提交
  33. 28 6月, 2013 2 次提交
  35. 12 6月, 2013 1 次提交
    • A
      dump: Drop qmp_dump_guest_memory() stub and build for all targets · 2a78636b
      由 Andreas Färber 提交于 
      qmp_dump_guest_memory() calls dump_init() and returns an Error when
cpu_get_dump_info() returns an error, as done by the stub.
So there is no need to have a stub for qmp_dump_guest_memory().

Enable the documentation of the always-present dump-guest-memory command.

That way we can drop CONFIG_HAVE_CORE_DUMP and leave configure
completely out of the picture for target CPU features.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
      2a78636b
  37. 11 6月, 2013 1 次提交
  39. 01 5月, 2013 1 次提交
  41. 12 3月, 2013 1 次提交
  43. 01 3月, 2013 1 次提交
  45. 22 2月, 2013 1 次提交
    • S
      slirp: switch to GPollFD · 8917c3bd
      由 Stefan Hajnoczi 提交于 
      Slirp uses rfds/wfds/xfds more extensively than other QEMU components.

The rarely-used out-of-band TCP data feature is used.  That means we
need the full table of select(2) to g_poll(3) events:

  rfds -> G_IO_IN | G_IO_HUP | G_IO_ERR
  wfds -> G_IO_OUT | G_IO_ERR
  xfds -> G_IO_PRI

I came up with this table by looking at Linux fs/select.c which maps
select(2) to poll(2) internally.

Another detail to watch out for are the global variables that reference
rfds/wfds/xfds during slirp_select_poll().  sofcantrcvmore() and
sofcantsendmore() use these globals to clear fd_set bits.  When
sofcantrcvmore() is called, the wfds bit is cleared so that the write
handler will no longer be run for this iteration of the event loop.

This actually seems buggy to me since TCP connections can be half-closed
and we'd still want to handle data in half-duplex fashion.  I think the
real intention is to avoid running the read/write handler when the
socket has been fully closed.  This is indicated with the SS_NOFDREF
state bit so we now check for it before invoking the TCP write handler.
Note that UDP/ICMP code paths don't care because they are
connectionless.

Note that slirp/ has a lot of tabs and sometimes mixed tabs with spaces.
I followed the style of the surrounding code.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Message-id: 1361356113-11049-6-git-send-email-stefanha@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      8917c3bd
  47. 13 1月, 2013 1 次提交
  49. 09 1月, 2013 3 次提交
  51. 19 12月, 2012 4 次提交
  53. 19 11月, 2012 1 次提交