Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 18 12月, 2015 4 次提交
  3. 17 12月, 2015 2 次提交
    • E
      exec: Remove unnecessary RAM_FILE flag · 2f3a2bb1
      由 Eduardo Habkost 提交于 
      The only code that sets RAMBlock.fd is file_ram_alloc(), and the only
code that calls file_ram_alloc() sets the RAM_FILE flag. That means the
flag is always set when RAMBlock.fd >= 0, and the munmap() call at
reclaim_ramblock() is dead code that never runs.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <1446847881-9385-1-git-send-email-ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2f3a2bb1
    • E
      exec: Eliminate qemu_ram_free_from_ptr() · a29ac166
      由 Eduardo Habkost 提交于 
      Replace qemu_ram_free_from_ptr() with qemu_ram_free().

The only difference between qemu_ram_free_from_ptr() and
qemu_ram_free() is that g_free_rcu() is used instead of
call_rcu(reclaim_ramblock). We can safely replace it because:

* RAM blocks allocated by qemu_ram_alloc_from_ptr() always have
  RAM_PREALLOC set;
* reclaim_ramblock(block) will do nothing except g_free(block)
  if RAM_PREALLOC is set at block->flags.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <1446844805-14492-2-git-send-email-ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      a29ac166
  5. 02 12月, 2015 1 次提交
    • D
      exec: Stop using memory after free · 55b4e80b
      由 Don Slutz 提交于 
      memory_region_unref(mr) can free memory.

For example I got:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f43280d4700 (LWP 4462)]
0x00007f43323283c0 in phys_section_destroy (mr=0x7f43259468b0)
    at /home/don/xen/tools/qemu-xen-dir/exec.c:1023
1023        if (mr->subpage) {
(gdb) bt
    at /home/don/xen/tools/qemu-xen-dir/exec.c:1023
    at /home/don/xen/tools/qemu-xen-dir/exec.c:1034
    at /home/don/xen/tools/qemu-xen-dir/exec.c:2205
(gdb) p mr
$1 = (MemoryRegion *) 0x7f43259468b0

And this change prevents this.
Signed-off-by: NDon Slutz <Don.Slutz@Gmail.com>
Message-Id: <1448921464-21845-1-git-send-email-Don.Slutz@Gmail.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      55b4e80b
  7. 26 11月, 2015 2 次提交
    • D
      exec: remove warning about mempath and hugetlbfs · bfc2a1a1
      由 Daniel P. Berrange 提交于 
      The gethugepagesize() method in exec.c printed a warning if
the file path for "-mem-path" or "-object memory-backend-file"
was not on a hugetlbfs filesystem. This warning is bogus, because
QEMU functions perfectly well with the path on a regular tmpfs
filesystem. Use of hugetlbfs vs tmpfs is a choice for the management
application or end user to make as best fits their needs. As such it
is inappropriate for QEMU to have an opinion on whether the user's
choice is right or wrong in this case.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1448448749-1332-3-git-send-email-berrange@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      bfc2a1a1
    • D
      Revert "exec: silence hugetlbfs warning under qtest" · 2c189a4e
      由 Daniel P. Berrange 提交于 
      This reverts commit 1c7ba94a.

That commit changed QEMU initialization order from

 - object-initial, chardev, qtest, object-late

to

 - chardev, qtest, object-initial, object-late

This breaks chardev setups which need to rely on objects
having been created. For example, when chardevs use TLS
encryption in the future, they need to have tls credential
objects created first.

This revert, restores the ordering introduced in

  commit f08f9271
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Wed May 13 17:14:04 2015 +0100

    vl: Create (most) objects before creating chardev backends
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1448448749-1332-2-git-send-email-berrange@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2c189a4e
  9. 19 11月, 2015 1 次提交
  11. 10 11月, 2015 4 次提交
  13. 06 11月, 2015 2 次提交
  15. 04 11月, 2015 2 次提交
  17. 02 11月, 2015 1 次提交
  19. 21 10月, 2015 1 次提交
  21. 13 10月, 2015 2 次提交
    • P
      exec.c: Collect AddressSpace related fields into a CPUAddressSpace struct · 32857f4d
      由 Peter Maydell 提交于 
      Gather up all the fields currently in CPUState which deal with the CPU's
AddressSpace into a separate CPUAddressSpace struct. This paves the way
for allowing the CPU to know about more than one AddressSpace.

The rearrangement also allows us to make the MemoryListener a directly
embedded object in the CPUAddressSpace (it could not be embedded in
CPUState because 'struct MemoryListener' isn't defined for the user-only
builds). This allows us to resolve the FIXME in tcg_commit() by going
directly from the MemoryListener to the CPUAddressSpace.

This patch extracts the actual update of the cached dispatch pointer
from cpu_reload_memory_map() (which is renamed accordingly to
cpu_reloading_memory_map() as it is only responsible for breaking
cpu-exec.c's RCU critical section now). This lets us keep the definition
of the CPUAddressSpace struct private to exec.c.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-Id: <1443709790-25180-4-git-send-email-peter.maydell@linaro.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      32857f4d
    • P
      exec.c: Don't call cpu_reload_memory_map() from cpu_exec_init() · 0a1c71ce
      由 Peter Maydell 提交于 
      Currently we call cpu_reload_memory_map() from cpu_exec_init(),
but this is not necessary:
 * KVM doesn't use the data structures maintained by
   cpu_reload_memory_map() (the TLB and cpu->memory_dispatch)
 * for TCG, we will call this function via tcg_commit() either
   as soon as tcg_cpu_address_space_init() registers the listener,
   or when the first MemoryRegion is added to the AddressSpace
   if the AS is empty when we register the listener

The unnecessary call is awkward for adding support for multiple
address spaces per CPU, so drop it.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>
Message-Id: <1443709790-25180-2-git-send-email-peter.maydell@linaro.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0a1c71ce
  23. 01 10月, 2015 1 次提交
  25. 16 9月, 2015 4 次提交
  27. 09 9月, 2015 1 次提交
  29. 07 9月, 2015 1 次提交
  31. 15 8月, 2015 1 次提交
  33. 23 7月, 2015 1 次提交
  35. 09 7月, 2015 7 次提交
  37. 07 7月, 2015 1 次提交
  39. 06 7月, 2015 1 次提交
    • P
      exec: skip MMIO regions correctly in cpu_physical_memory_write_rom_internal · b242e0e0
      由 Paolo Bonzini 提交于 
      Loading the BIOS in the mac99 machine is interesting, because there is a
PROM in the middle of the BIOS region (from 16K to 32K).  Before memory
region accesses were clamped, when QEMU was asked to load a BIOS from
0xfff00000 to 0xffffffff it would put even those 16K from the BIOS file
into the region.  This is weird because those 16K were not actually
visible between 0xfff04000 and 0xfff07fff.  However, it worked.

After clamping was added, this also worked.  In this case, the
cpu_physical_memory_write_rom_internal function split the write in
three parts: the first 16K were copied, the PROM area (second 16K) were
ignored, then the rest was copied.

Problems then started with commit 965eb2fc (exec: do not clamp accesses
to MMIO regions, 2015-06-17).  Clamping accesses is not done for MMIO
regions because they can overlap wildly, and MMIO registers can be
expected to perform full-width accesses based only on their address
(with no respect for adjacent registers that could decode to completely
different MemoryRegions).  However, this lack of clamping also applied
to the PROM area!  cpu_physical_memory_write_rom_internal thus failed
to copy the third range above, i.e. only copied the first 16K of the BIOS.

In effect, address_space_translate is expecting _something else_ to do
the clamping for MMIO regions if the incoming length is large.  This
"something else" is memory_access_size in the case of address_space_rw,
so use the same logic in cpu_physical_memory_write_rom_internal.
Reported-by: NAlexander Graf <agraf@redhat.com>
Reviewed-by: NLaurent Vivier <lvivier@redhat.com>
Tested-by: NLaurent Vivier <lvivier@redhat.com>
Fixes: 965eb2fcSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b242e0e0