Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 23 12月, 2014 1 次提交
  3. 21 12月, 2014 1 次提交
    • P
      exec: change default exception_index value for migration to -1 · adee6424
      由 Paolo Bonzini 提交于 
      In QEMU 2.2 the exception_index value was added to the migration stream
through a subsection.  The default was set to 0, which is wrong and
should have been -1.

However, 2.2 does not have commit e511b4d7 (cpu-exec: reset exception_index
correctly, 2014-11-26), hence in 2.2 the exception_index is never used
and is set to -1 on the next call to cpu_exec.  So we can change the
migration stream to make the default -1.  The effects are:

- 2.2.1 -> 2.2.0: cpu->exception_index set incorrectly to 0 if it
were -1 on the source; then reset to -1 in cpu_exec.  This is TCG
only; KVM does not use exception_index.

- 2.2.0 -> 2.2.1: cpu->exception_index set incorrectly to -1 if it
were 0 on the source; but it would be reset to -1 in cpu_exec anyway.
This is TCG only; KVM does not use exception_index.

- 2.2.1 -> 2.1: two bugs fixed: 1) can migrate backwards if
cpu->exception_index is set to -1; 2) should not migrate backwards
(but 2.2.0 allows it) if cpu->exception_index is set to 0

- 2.2.0 -> 2.3.0: 2.2.0 will send the subsection unnecessarily if
exception_index is -1, but that is not a problem.  2.3.0 will set
cpu->exception_index to -1 if it is 0 on the source, but this would
be anyway a problem for 2.2.0 -> 2.2.x migration (due to lack of
commit e511b4d7 in 2.2.x) so we can ignore it

- 2.2.1 -> 2.3.0: everything works.

In addition, play it safe and never send the subsection unless TCG
is in use.  KVM does not use exception_index (PPC KVM stores values
in it for use in the subsequent call to ppc_cpu_do_interrupt, but
does not need it as soon as kvm_handle_debug returns).  Xen and
qtest do not run any code for the CPU at all.
Reported-by: NIgor Mammedov <imammedo@redhat.com>
Tested-by: NLaurent Desnogues <laurent.desnogues@gmail.com>
Tested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1418989994-17244-3-git-send-email-pbonzini@redhat.com
Cc: qemu-stable@nongnu.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      adee6424
  5. 16 12月, 2014 1 次提交
  7. 23 11月, 2014 1 次提交
  9. 18 11月, 2014 1 次提交
    • P
      exec: Handle multipage ranges in invalidate_and_set_dirty() · f874bf90
      由 Peter Maydell 提交于 
      The code in invalidate_and_set_dirty() needs to handle addr/length
combinations which cross guest physical page boundaries. This can happen,
for example, when disk I/O reads large blocks into guest RAM which previously
held code that we have cached translations for. Unfortunately we were only
checking the clean/dirty status of the first page in the range, and then
were calling a tb_invalidate function which only handles ranges that don't
cross page boundaries. Fix the function to deal with multipage ranges.

The symptoms of this bug were that guest code would misbehave (eg segfault),
in particular after a guest reboot but potentially any time the guest
reused a page of its physical RAM for new code.

Cc: qemu-stable@nongnu.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1416167061-13203-1-git-send-email-peter.maydell@linaro.org
      f874bf90
  11. 20 9月, 2014 1 次提交
  13. 12 9月, 2014 4 次提交
  15. 09 9月, 2014 3 次提交
  17. 05 9月, 2014 1 次提交
  19. 29 8月, 2014 1 次提交
  21. 18 8月, 2014 1 次提交
  23. 22 7月, 2014 1 次提交
    • P
      exec: fix migration with devices that use address_space_rw · 6886867e
      由 Paolo Bonzini 提交于 
      Devices that use address_space_rw to write large areas to memory
(as opposed to address_space_map/unmap) were broken with respect
to migration since fe680d0d (exec: Limit translation limiting in
address_space_translate to xen, 2014-05-07).  Such devices include
IDE CD-ROMs.

The reason is that invalidate_and_set_dirty (called by address_space_rw
but not address_space_map/unmap) was only setting the dirty bit for
the first page in the translation.

To fix this, introduce cpu_physical_memory_set_dirty_range_nocode that
is the same as cpu_physical_memory_set_dirty_range except it does not
muck with the DIRTY_MEMORY_CODE bitmap.  This function can be used if
the caller invalidates translations with tb_invalidate_phys_page_range.

There is another difference between cpu_physical_memory_set_dirty_range
and cpu_physical_memory_set_dirty_flag; the former includes a call
to xen_modified_memory.  This is handled separately in
invalidate_and_set_dirty, and is not needed in other callers of
cpu_physical_memory_set_dirty_range_nocode, so leave it alone.

Just one nit: now that invalidate_and_set_dirty takes care of handling
multiple pages, there is no need for address_space_unmap to wrap it
in a loop.  In fact that loop would now be O(n^2).
Reported-by: NDave Gilbert <dgilbert@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Tested-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6886867e
  25. 01 7月, 2014 2 次提交
  27. 30 6月, 2014 2 次提交
    • G
      exec: introduce target_words_bigendian() helper · 98ed8ecf
      由 Greg Kurz 提交于 
      We currently have a virtio_is_big_endian() helper that provides the target
endianness to the virtio code. As of today, the helper returns a fixed
compile-time value. Of course, this will have to change if we want to
support target endianness changes at run-time.

Let's move the TARGET_WORDS_BIGENDIAN bits out to a new helper and have
virtio_is_big_endian() implemented on top of it.

This patch doesn't change any functionality.
Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      98ed8ecf
    • D
      vhost-user: fix regions provied with VHOST_USER_SET_MEM_TABLE message · 3fd74b84
      由 Damjan Marion 提交于 
      Old code was affected by memory gaps which resulted in buffer pointers
pointing to address outside of the mapped regions.

Here we are introducing following changes:
 - new function qemu_get_ram_block_host_ptr() returns host pointer
   to the ram block, it is needed to calculate offset of specific
   region in the host memory
 - new field mmap_offset is added to the VhostUserMemoryRegion. It
   contains offset where specific region starts in the mapped memory.
   As there is stil no wider adoption of vhost-user agreement was made
   that we will not bump version number due to this change
 - other fileds in VhostUserMemoryRegion struct are not changed, as
   they are all needed for usermode app implementation
 - region data is not taken from ram_list.blocks anymore, instead we
   use region data which is alredy calculated for use in vhost-net
 - Now multiple regions can have same FD and user applicaton can call
   mmap() multiple times with the same FD but with different offset
   (user needs to take care for offset page alignment)
Signed-off-by: NDamjan Marion <damarion@cisco.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDamjan Marion <damarion@cisco.com>
      3fd74b84
  29. 23 6月, 2014 1 次提交
  31. 19 6月, 2014 7 次提交
  33. 17 6月, 2014 2 次提交
  35. 14 5月, 2014 1 次提交
  37. 08 5月, 2014 1 次提交
  39. 20 3月, 2014 1 次提交
  41. 14 3月, 2014 6 次提交