- 11 3月, 2019 1 次提交
-
-
由 Wei Yang 提交于
flatview_add_to_dispatch() registers page based on the condition of *section*, which may looks like this: |s|PPPPPPP|s| where s stands for subpage and P for page. The procedure of this function could be described as: - register first subpage - register page - register last subpage This means the procedure could be simplified into these three steps instead of a loop iteration. This patch refactors the function into three corresponding steps and adds some comment to clarify it. Signed-off-by: NWei Yang <richardw.yang@linux.intel.com> Message-Id: <20190311054252.6094-1-richardw.yang@linux.intel.com> [Paolo: move exit before adjustment of remain.offset_within_*, otherwise int128_get64 fails when a region is 2^64 bytes long] Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 06 3月, 2019 2 次提交
-
-
由 Yury Kotov 提交于
If ignore-shared capability is set then skip shared RAMBlocks during the RAM migration. Also, move qemu_ram_foreach_migratable_block (and rename) to the migration code, because it requires access to the migration capabilities. Signed-off-by: NYury Kotov <yury-kotov@yandex-team.ru> Message-Id: <20190215174548.2630-4-yury-kotov@yandex-team.ru> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Yury Kotov 提交于
Currently, qemu_ram_foreach_* calls RAMBlockIterFunc with many block-specific arguments. But often iter func needs RAMBlock*. This refactoring is needed for fast access to RAMBlock flags from qemu_ram_foreach_block's callback. The only way to achieve this now is to call qemu_ram_block_from_host (which also enumerates blocks). So, this patch reduces complexity of qemu_ram_foreach_block() -> cb() -> qemu_ram_block_from_host() from O(n^2) to O(n). Fix RAMBlockIterFunc definition and add some functions to read RAMBlock* fields witch were passed. Signed-off-by: NYury Kotov <yury-kotov@yandex-team.ru> Message-Id: <20190215174548.2630-2-yury-kotov@yandex-team.ru> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
- 05 2月, 2019 2 次提交
-
-
由 Murilo Opsfelder Araujo 提交于
The commit 7197fb40 ("util/mmap-alloc: fix hugetlb support on ppc64") fixed Huge TLB mappings on ppc64. However, we still need to consider the underlying huge page size during munmap() because it requires that both address and length be a multiple of the underlying huge page size for Huge TLB mappings. Quote from "Huge page (Huge TLB) mappings" paragraph under NOTES section of the munmap(2) manual: "For munmap(), addr and length must both be a multiple of the underlying huge page size." On ppc64, the munmap() in qemu_ram_munmap() does not work for Huge TLB mappings because the mapped segment can be aligned with the underlying huge page size, not aligned with the native system page size, as returned by getpagesize(). This has the side effect of not releasing huge pages back to the pool after a hugetlbfs file-backed memory device is hot-unplugged. This patch fixes the situation in qemu_ram_mmap() and qemu_ram_munmap() by considering the underlying page size on ppc64. After this patch, memory hot-unplug releases huge pages back to the pool. Fixes: 7197fb40Signed-off-by: NMurilo Opsfelder Araujo <muriloo@linux.ibm.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 Li Zhijian 提交于
Some address/memory APIs have different type between 'hwaddr/target_ulong addr' and 'int len'. It is very unsafe, especially some APIs will be passed a non-int len by caller which might cause overflow quietly. Below is an potential overflow case: dma_memory_read(uint32_t len) -> dma_memory_rw(uint32_t len) -> dma_memory_rw_relaxed(uint32_t len) -> address_space_rw(int len) # len overflow CC: Paolo Bonzini <pbonzini@redhat.com> CC: Peter Crosthwaite <crosthwaite.peter@gmail.com> CC: Richard Henderson <rth@twiddle.net> CC: Peter Maydell <peter.maydell@linaro.org> CC: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NStefano Garzarella <sgarzare@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 04 2月, 2019 1 次提交
-
-
由 Murilo Opsfelder Araujo 提交于
The commit 7197fb40 ("util/mmap-alloc: fix hugetlb support on ppc64") fixed Huge TLB mappings on ppc64. However, we still need to consider the underlying huge page size during munmap() because it requires that both address and length be a multiple of the underlying huge page size for Huge TLB mappings. Quote from "Huge page (Huge TLB) mappings" paragraph under NOTES section of the munmap(2) manual: "For munmap(), addr and length must both be a multiple of the underlying huge page size." On ppc64, the munmap() in qemu_ram_munmap() does not work for Huge TLB mappings because the mapped segment can be aligned with the underlying huge page size, not aligned with the native system page size, as returned by getpagesize(). This has the side effect of not releasing huge pages back to the pool after a hugetlbfs file-backed memory device is hot-unplugged. This patch fixes the situation in qemu_ram_mmap() and qemu_ram_munmap() by considering the underlying page size on ppc64. After this patch, memory hot-unplug releases huge pages back to the pool. Fixes: 7197fb40Signed-off-by: NMurilo Opsfelder Araujo <muriloo@linux.ibm.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 01 2月, 2019 1 次提交
-
-
由 Peter Maydell 提交于
The tcg_register_iommu_notifier() code has a GArray of TCGIOMMUNotifier structs which it has registered by passing memory_region_register_iommu_notifier() a pointer to the embedded IOMMUNotifier field. Unfortunately, if we need to enlarge the array via g_array_set_size() this can cause a realloc(), which invalidates the pointer that memory_region_register_iommu_notifier() put into the MemoryRegion's iommu_notify list. This can result in segfaults. Switch the GArray to holding pointers to the TCGIOMMUNotifier structs, so that we can individually allocate and free them. Cc: qemu-stable@nongnu.org Fixes: 1f871c5e ("exec.c: Handle IOMMUs in address_space_translate_for_iotlb()") Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190128174241.5860-1-peter.maydell@linaro.org
-
- 29 1月, 2019 2 次提交
-
-
由 Stefan Hajnoczi 提交于
ROM devices go via MemoryRegionOps->write() callbacks for write operations and do not dirty/invalidate that memory. Device emulation must be able to mark memory ranges that have been modified internally (e.g. using memory_region_get_ram_ptr()). Introduce the memory_region_flush_rom_device() API for this purpose. Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Message-id: 20190123212234.32068-2-stefanha@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> [PMM: fix block comment style] Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
In the softmmu version of cpu_memory_rw_debug(), we ask the CPU for the attributes to use for the virtual memory access, and we correctly use those to identify the address space index. However, we were not passing them in to the address_space_write_rom() and address_space_rw() functions. The effect of this was that a memory access from the gdbstub to a device which had behaviour that was sensitive to the memory attributes (such as some ARMv8M NVIC registers) was incorrectly always performed as if non-secure, rather than using the right security state for the CPU's current state. Fixes: https://bugs.launchpad.net/qemu/+bug/1812091Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NStefano Garzarella <sgarzare@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190117133834.7480-1-peter.maydell@linaro.org
-
- 11 1月, 2019 2 次提交
-
-
由 Paolo Bonzini 提交于
This will be needed when we change the QTAILQ head and elem structs to unions. However, it is also consistent with the usage elsewhere in QEMU for other list head structs (see for example FsMountList). Note that most QTAILQs only need their name in order to do backwards walks. Those do not break with the struct->union change, and anyway the change will also remove the need to name heads when doing backwards walks, so those are not touched here. Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Most list head structs need not be given a name. In most cases the name is given just in case one is going to use QTAILQ_LAST, QTAILQ_PREV or reverse iteration, but this does not apply to lists of other kinds, and even for QTAILQ in practice this is only rarely needed. In addition, we will soon reimplement those macros completely so that they do not need a name for the head struct. So clean up everything, not giving a name except in the rare case where it is necessary. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 14 12月, 2018 2 次提交
-
-
由 Peter Maydell 提交于
The API of cpu_physical_memory_write_rom() is odd, because it takes an AddressSpace, unlike all the other cpu_physical_memory_* access functions. Rename it to address_space_write_rom(), and bring its API into line with address_space_write(). Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Message-id: 20181122133507.30950-3-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Rename cpu_physical_memory_write_rom_internal() to address_space_write_rom_internal(), and make it take MemTxAttrs and return a MemTxResult. This brings its API into line with address_space_write(). This is an internal function to exec.c; fixing its API will allow us to change the global function cpu_physical_memory_write_rom(). Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Message-id: 20181122133507.30950-2-peter.maydell@linaro.org
-
- 19 10月, 2018 1 次提交
-
-
由 Emilio G. Cota 提交于
Paves the way for the addition of a per-TLB lock. Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Signed-off-by: NEmilio G. Cota <cota@braap.org> Message-Id: <20181009174557.16125-4-cota@braap.org> Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
-
- 17 10月, 2018 1 次提交
-
-
由 Thomas Huth 提交于
We've got three places already that provide a prototype for this function in a .c file - that's ugly. Let's provide a proper prototype in a header instead, with a proper description why this function should not be used in most cases. Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Signed-off-by: NThomas Huth <thuth@redhat.com>
-
- 03 10月, 2018 1 次提交
-
-
由 Hikaru Nishida 提交于
Before this change, memory-backend-file object is valid for Linux hosts only because hostmem-file.c is compiled only on Linux hosts. However, other POSIX-based hosts (such as macOS) can support memory-backend-file object in the same way as on Linux hosts. This patch makes hostmem-file.c and related functions to be compiled on all POSIX-based hosts to make available memory-backend-file on them. Signed-off-by: NHikaru Nishida <hikarupsp@gmail.com> Message-Id: <20180924123205.29651-1-hikarupsp@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 15 8月, 2018 1 次提交
-
-
由 Peter Maydell 提交于
We set up TLB entries in tlb_set_page_with_attrs(), where we have some logic for determining whether the TLB entry is considered to be RAM-backed, and thus has a valid addend field. When we look at the TLB entry in get_page_addr_code(), we use different logic for determining whether to treat the page as RAM-backed and use the addend field. This is confusing, and in fact buggy, because the code in tlb_set_page_with_attrs() correctly decides that rom_device memory regions not in romd mode are not RAM-backed, but the code in get_page_addr_code() thinks they are RAM-backed. This typically results in "Bad ram pointer" assertion if the guest tries to execute from such a memory region. Fix this by making get_page_addr_code() just look at the TLB_MMIO bit in the code_address field of the TLB, which tlb_set_page_with_attrs() sets if and only if the addend field is not valid for code execution. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180713150945.12348-1-peter.maydell@linaro.org
-
- 10 8月, 2018 3 次提交
-
-
由 Junyan He 提交于
When QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it needs to know whether the backend storage is a real persistent memory, in order to decide whether special operations should be performed to ensure the data persistence. This boolean option 'pmem' allows users to specify whether the backend storage of memory-backend-file is a real persistent memory. If 'pmem=on', QEMU will set the flag RAM_PMEM in the RAM block of the corresponding memory region. If 'pmem' is set while lack of libpmem support, a error is generated. Signed-off-by: NJunyan He <junyan.he@intel.com> Signed-off-by: NHaozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Junyan He 提交于
As more flag parameters besides the existing 'share' are going to be added to following functions memory_region_init_ram_from_file qemu_ram_alloc_from_fd qemu_ram_alloc_from_file let's switch them to use the 'flags' parameters so as to ease future flag additions. The existing 'share' flag is converted to the RAM_SHARED bit in ram_flags, and other flag bits are ignored by above functions right now. Signed-off-by: NJunyan He <junyan.he@intel.com> Signed-off-by: NHaozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
-
由 Junyan He 提交于
We need to use these flags in other files rather than just in exec.c, For example, RAM_SHARED should be used when create a ram block from file. We expose them the exec/memory.h Signed-off-by: NJunyan He <junyan.he@intel.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 02 7月, 2018 2 次提交
-
-
由 Paolo Bonzini 提交于
There is no need for a stub, since tb_invalidate_phys_addr can be excised altogether when TCG is disabled. This is a bit cleaner since it avoids using code that is clearly specific to user-mode emulation (it calls mmap_lock/unlock) for the !CONFIG_TCG case. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Philippe Mathieu-Daudé 提交于
Fix the --disable-tcg breakage introduced by 8bca9a03: $ configure --disable-tcg [...] $ make -C i386-softmmu exec.o make: Entering directory 'i386-softmmu' CC exec.o In file included from source/qemu/exec.c:62:0: source/qemu/include/exec/ram_addr.h:96:6: error: conflicting types for ‘tb_invalidate_phys_range’ void tb_invalidate_phys_range(ram_addr_t start, ram_addr_t end); ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from source/qemu/exec.c:24:0: source/qemu/include/exec/exec-all.h:309:6: note: previous declaration of ‘tb_invalidate_phys_range’ was here void tb_invalidate_phys_range(target_ulong start, target_ulong end); ^~~~~~~~~~~~~~~~~~~~~~~~ source/qemu/exec.c:1043:6: error: conflicting types for ‘tb_invalidate_phys_addr’ void tb_invalidate_phys_addr(AddressSpace *as, hwaddr addr, MemTxAttrs attrs) ^~~~~~~~~~~~~~~~~~~~~~~ In file included from source/qemu/exec.c:24:0: source/qemu/include/exec/exec-all.h:308:6: note: previous declaration of ‘tb_invalidate_phys_addr’ was here void tb_invalidate_phys_addr(target_ulong addr); ^~~~~~~~~~~~~~~~~~~~~~~ make: *** [source/qemu/rules.mak:69: exec.o] Error 1 make: Leaving directory 'i386-softmmu' Tested to build x86_64-softmmu and i386-softmmu targets. Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180629200710.27626-1-f4bug@amsat.org Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 29 6月, 2018 3 次提交
-
-
由 David Hildenbrand 提交于
Right now we can crash QEMU using e.g. qemu-system-x86_64 -m 256M,maxmem=20G,slots=2 \ -object memory-backend-file,id=mem0,size=12288,mem-path=/dev/zero,align=12288 \ -device pc-dimm,id=dimm1,memdev=mem0 qemu-system-x86_64: util/mmap-alloc.c:115: qemu_ram_mmap: Assertion `is_power_of_2(align)' failed Fix this by adding a proper check. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180607154705.6316-3-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Place them in exec.c, exec-all.h and ram_addr.h. This removes knowledge of translate-all.h (which is an internal header) from several files outside accel/tcg and removes knowledge of AddressSpace from translate-all.c (as it only operates on ram_addr_t). Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Eric Auger 提交于
When an IOMMUMemoryRegion is in front of a virtio device, address_space_cache_init does not set cache->ptr as the memory region is not RAM. However when the device performs an access, we end up in glue() which performs the translation and then uses MAP_RAM. This latter uses the unset ptr and returns a wrong value which leads to a SIGSEV in address_space_lduw_internal_cached_slow, for instance. In slow path cache->ptr is NULL and MAP_RAM must redirect to qemu_map_ram_ptr((mr)->ram_block, ofs). As MAP_RAM, IS_DIRECT and INVALIDATE are the same in _cached_slow and non cached mode, let's remove those macros. This fixes the use cases featuring vIOMMU (Intel and ARM SMMU) which lead to a SIGSEV. Fixes: 48564041 (exec: reintroduce MemoryRegion caching) Signed-off-by: NEric Auger <eric.auger@redhat.com> Message-Id: <1528895946-28677-1-git-send-email-eric.auger@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 27 6月, 2018 1 次提交
-
-
由 David Hildenbrand 提交于
Not needed. Don't expose last_ram_page(). Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180620202736.21399-1-david@redhat.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
- 23 6月, 2018 1 次提交
-
-
由 Emilio G. Cota 提交于
Fix the --disable-tcg breakage introduced by tb_lock's removal by relying on the fact that tcg_enabled() is set to 0 at compile-time under --disable-tcg. While at it, add further asserts to fix builds that enable both --disable-tcg and --enable-debug, which were broken even before tb_lock's removal. Tested to build x86_64-softmmu and i386-softmmu targets. Reported-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NEmilio G. Cota <cota@braap.org> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 16 6月, 2018 1 次提交
-
-
由 Emilio G. Cota 提交于
Use mmap_lock in user-mode to protect TCG state and the page descriptors. In !user-mode, each vCPU has its own TCG state, so no locks needed. Per-page locks are used to protect the page descriptors. Per-TB locks are used in both modes to protect TB jumps. Some notes: - tb_lock is removed from notdirty_mem_write by passing a locked page_collection to tb_invalidate_phys_page_fast. - tcg_tb_lookup/remove/insert/etc have their own internal lock(s), so there is no need to further serialize access to them. - do_tb_flush is run in a safe async context, meaning no other vCPU threads are running. Therefore acquiring mmap_lock there is just to please tools such as thread sanitizer. - Not visible in the diff, but tb_invalidate_phys_page already has an assert_memory_lock. - cpu_io_recompile is !user-only, so no mmap_lock there. - Added mmap_unlock()'s before all siglongjmp's that could be called in user-mode while mmap_lock is held. + Added an assert for !have_mmap_lock() after returning from the longjmp in cpu_exec, just like we do in cpu_exec_step_atomic. Performance numbers before/after: Host: AMD Opteron(tm) Processor 6376 ubuntu 17.04 ppc64 bootup+shutdown time 700 +-+--+----+------+------------+-----------+------------*--+-+ | + + + + + *B | | before ***B*** ** * | |tb lock removal ###D### *** | 600 +-+ *** +-+ | ** # | | *B* #D | | *** * ## | 500 +-+ *** ### +-+ | * *** ### | | *B* # ## | | ** * #D# | 400 +-+ ** ## +-+ | ** ### | | ** ## | | ** # ## | 300 +-+ * B* #D# +-+ | B *** ### | | * ** #### | | * *** ### | 200 +-+ B *B #D# +-+ | #B* * ## # | | #* ## | | + D##D# + + + + | 100 +-+--+----+------+------------+-----------+------------+--+-+ 1 8 16 Guest CPUs 48 64 png: https://imgur.com/HwmBHXe debian jessie aarch64 bootup+shutdown time 90 +-+--+-----+-----+------------+------------+------------+--+-+ | + + + + + + | | before ***B*** B | 80 +tb lock removal ###D### **D +-+ | **### | | **## | 70 +-+ ** # +-+ | ** ## | | ** # | 60 +-+ *B ## +-+ | ** ## | | *** #D | 50 +-+ *** ## +-+ | * ** ### | | **B* ### | 40 +-+ **** # ## +-+ | **** #D# | | ***B** ### | 30 +-+ B***B** #### +-+ | B * * # ### | | B ###D# | 20 +-+ D ##D## +-+ | D# | | + + + + + + | 10 +-+--+-----+-----+------------+------------+------------+--+-+ 1 8 16 Guest CPUs 48 64 png: https://imgur.com/iGpGFtv The gains are high for 4-8 CPUs. Beyond that point, however, unrelated lock contention significantly hurts scalability. Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Signed-off-by: NEmilio G. Cota <cota@braap.org> Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
-
- 15 6月, 2018 5 次提交
-
-
由 Peter Maydell 提交于
Currently we don't support board configurations that put an IOMMU in the path of the CPU's memory transactions, and instead just assert() if the memory region fonud in address_space_translate_for_iotlb() is an IOMMUMemoryRegion. Remove this limitation by having the function handle IOMMUs. This is mostly straightforward, but we must make sure we have a notifier registered for every IOMMU that a transaction has passed through, so that we can flush the TLB appropriately when any of the IOMMUs change their mappings. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Message-id: 20180604152941.20374-5-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Add an IOMMU index argument to the translate method of IOMMUs. Since all of our current IOMMU implementations support only a single IOMMU index, this has no effect on the behaviour. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Message-id: 20180604152941.20374-4-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Now we have stn_p() and ldn_p() we can use them in various functions in exec.c that used to have their own switch-on-size code. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180611171007.4165-4-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
In subpage_read() we perform a load of the data into a local buffer which we then access using ldub_p(), lduw_p(), ldl_p() or ldq_p() depending on its size, storing the result into the uint64_t *data. Since ldl_p() returns an 'int', this means that for the 4-byte case we will sign-extend the data, whereas for 1 and 2 byte reads we zero-extend it. This ought not to matter since the caller will likely ignore values in the high bytes of the data, but add a cast so that we're consistent. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180611171007.4165-3-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
The API for cpu_transaction_failed() says that it takes the physical address for the failed transaction. However we were actually passing it the offset within the target MemoryRegion. We don't currently have any target CPU implementations of this hook that require the physical address; fix this bug so we don't get confused if we ever do add one. Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180611125633.32755-3-peter.maydell@linaro.org
-
- 04 6月, 2018 1 次提交
-
-
由 Cédric Le Goater 提交于
On the POWER9 processor, the XIVE interrupt controller can control interrupt sources using MMIO to trigger events, to EOI or to turn off the sources. Priority management and interrupt acknowledgment is also controlled by MMIO in the presenter sub-engine. These MMIO regions are exposed to guests in QEMU with a set of 'ram device' memory mappings, similarly to VFIO, and the VMAs are populated dynamically with the appropriate pages using a fault handler. But, these regions are an issue for migration. We need to discard the associated RAMBlocks from the RAM state on the source VM and let the destination VM rebuild the memory mappings on the new host in the post_load() operation just before resuming the system. To achieve this goal, the following introduces a new RAMBlock flag RAM_MIGRATABLE which is updated in the vmstate_register_ram() and vmstate_unregister_ram() routines. This flag is then used by the migration to identify RAMBlocks to discard on the source. Some checks are also performed on the destination to make sure nothing invalid was sent. This change impacts the boston, malta and jazz mips boards for which migration compatibility is broken. Signed-off-by: NCédric Le Goater <clg@kaod.org> Reviewed-by: NJuan Quintela <quintela@redhat.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
- 01 6月, 2018 1 次提交
-
-
由 Peter Maydell 提交于
Coverity points out that in the user-only version of cpu_abort() we call sigaction() with a partially initialized struct sigaction (CID 1005351). Correct the omission. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Message-Id: <20180515182700.31736-1-peter.maydell@linaro.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 31 5月, 2018 5 次提交
-
-
由 Peter Maydell 提交于
As part of plumbing MemTxAttrs down to the IOMMU translate method, add MemTxAttrs as an argument to address_space_translate_iommu(). Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180521140402.23318-14-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
As part of plumbing MemTxAttrs down to the IOMMU translate method, add MemTxAttrs as an argument to flatview_do_translate(). Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180521140402.23318-13-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
As part of plumbing MemTxAttrs down to the IOMMU translate method, add MemTxAttrs as an argument to address_space_get_iotlb_entry(). Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180521140402.23318-12-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
As part of plumbing MemTxAttrs down to the IOMMU translate method, add MemTxAttrs as an argument to flatview_translate(); all its callers now have attrs available. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180521140402.23318-11-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
As part of plumbing MemTxAttrs down to the IOMMU translate method, add MemTxAttrs as an argument to flatview_access_valid(). Its callers now all have an attrs value to hand, so we can correct our earlier temporary use of MEMTXATTRS_UNSPECIFIED. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20180521140402.23318-10-peter.maydell@linaro.org
-