Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 14 8月, 2013 3 次提交
    • A
      mips_malta: do not raise exceptions when accessing invalid memory · cc413a39
      由 Aurelien Jarno 提交于 
      Since commit c658b94f, MIPS raises
exceptions when accessing invalid memory. This is not the correct
behaviour for MIPS Malta Core LV, as the GT-64120A system controller
just ignore undecoded access. This feature is used by the Linux kernel
to probe for some devices.

Emulate the correct behaviour in QEMU by adding an empty slot covering
the entire memory space decoded by the GT-64120A.
Tested-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      cc413a39
    • M
      block: Dont ignore previously set bdrv_flags · 8b7a5415
      由 M. Mohan Kumar 提交于 
      bdrv_flags is set by bdrv_parse_discard_flags(), but later it is reset
to zero.
Signed-off-by: NM. Mohan Kumar <mohan@in.ibm.com>
Message-id: 1376483201-13466-1-git-send-email-mohan@in.ibm.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      8b7a5415
    • J
      qemu-char: fix infinite recursion connecting to monitor pty · 3a3567d3
      由 James Hogan 提交于 
      Since commit bd5c51ee (qemu-char: don't issue CHR_EVENT_OPEN in a BH), an
infinite recursion occurs when putting the monitor on a pty (-monitor
pty) and connecting a terminal to the slave port.

This is because of the qemu_chr_be_event(s, CHR_EVENT_OPENED) added to
qemu_chr_be_generic_open(). This event is captured by monitor_event()
which prints a welcome message to the character device. The flush of
that welcome message retriggers another open event in pty_chr_state()
because it checks s->connected, but only sets it to 1 after calling
qemu_chr_be_generic_open().

I've fixed this by setting s->connected = 1 before the call to
qemu_chr_be_generic_open() instead of after, so that the recursive
pty_chr_state() doesn't call it again.

An example snippet of repeating backtrace:
 ...
 #107486 0x007aec58 in monitor_flush (mon=0xf418b0) at qemu/monitor.c:288
 #107487 0x007aee7c in monitor_puts (mon=0xf418b0, str=0x1176d07 "") at qemu/monitor.c:322
 #107488 0x007aef20 in monitor_vprintf (mon=0xf418b0, fmt=0x8d4820 "QEMU %s monitor - type 'help' for more information\n",
     ap=0x7f432be0) at qemu/monitor.c:339
 #107489 0x007aefac in monitor_printf (mon=0xf418b0, fmt=0x8d4820 "QEMU %s monitor - type 'help' for more information\n")
     at qemu/monitor.c:347
 #107490 0x007ba4bc in monitor_event (opaque=0xf418b0, event=2) at qemu/monitor.c:4699
 #107491 0x00684c28 in qemu_chr_be_event (s=0xf37788, event=2) at qemu/qemu-char.c:108
 #107492 0x00684c70 in qemu_chr_be_generic_open (s=0xf37788) at qemu/qemu-char.c:113
 #107493 0x006880a4 in pty_chr_state (chr=0xf37788, connected=1) at qemu/qemu-char.c:1145
 #107494 0x00687fa4 in pty_chr_update_read_handler (chr=0xf37788) at qemu/qemu-char.c:1121
 #107495 0x00687c9c in pty_chr_write (chr=0xf37788, buf=0x70b3c008 <Address 0x70b3c008 out of bounds>, len=538720)
     at qemu/qemu-char.c:1063
 #107496 0x00684cc4 in qemu_chr_fe_write (s=0xf37788, buf=0x70b3c008 <Address 0x70b3c008 out of bounds>, len=538720)
     at qemu/qemu-char.c:118
 ...
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Tested-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Message-id: 1375960178-10882-1-git-send-email-james.hogan@imgtec.com
Cc: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      3a3567d3
  3. 13 8月, 2013 6 次提交
  5. 12 8月, 2013 25 次提交
  7. 10 8月, 2013 1 次提交
  9. 09 8月, 2013 3 次提交
  11. 08 8月, 2013 2 次提交
    • 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
    • L
      dump: populate guest_phys_blocks · c5d7f60f
      由 Laszlo Ersek 提交于 
      While the machine is paused, in guest_phys_blocks_append() we register a
one-shot MemoryListener, solely for the initial collection of the valid
guest-physical memory ranges that happens at listener registration time.

For each range that is reported to guest_phys_blocks_region_add(), we
attempt to merge the range with the preceding one.

Ranges can only be joined if they are contiguous in both guest-physical
address space, and contiguous in host virtual address space.

The "maximal" ranges that remain in the end constitute the guest-physical
memory map that the dump will be based on.

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>
      c5d7f60f