1. 06 11月, 2015 2 次提交
  2. 04 11月, 2015 2 次提交
  3. 02 11月, 2015 1 次提交
  4. 21 10月, 2015 1 次提交
  5. 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
  6. 01 10月, 2015 1 次提交
  7. 16 9月, 2015 4 次提交
  8. 09 9月, 2015 1 次提交
  9. 07 9月, 2015 1 次提交
  10. 15 8月, 2015 1 次提交
  11. 23 7月, 2015 1 次提交
  12. 09 7月, 2015 7 次提交
  13. 07 7月, 2015 1 次提交
  14. 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
  15. 01 7月, 2015 2 次提交
  16. 19 6月, 2015 2 次提交
  17. 12 6月, 2015 2 次提交
  18. 05 6月, 2015 7 次提交
  19. 30 4月, 2015 1 次提交