aboutsummaryrefslogtreecommitdiff
path: root/softmmu/memory.c
AgeCommit message (Collapse)AuthorFilesLines
2023-10-08system: Rename softmmu/ directory as system/Philippe Mathieu-Daudé1-3683/+0
The softmmu/ directory contains files specific to system emulation. Rename it as system/. Update meson rules, the MAINTAINERS file and all the documentation and comments. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231004090629.37473-14-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-07fuzz: Correct invalid mentions of 'softmmu' by 'system'Philippe Mathieu-Daudé1-1/+1
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Message-ID: <20231004090629.37473-5-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-29softmmu/memory: Clean up local variable shadowingPhilippe Mathieu-Daudé1-1/+0
Fix: softmmu/memory.c: In function ‘mtree_print_mr’: softmmu/memory.c:3236:27: warning: declaration of ‘ml’ shadows a previous local [-Wshadow=compatible-local] 3236 | MemoryRegionList *ml; | ^~ softmmu/memory.c:3213:32: note: shadowed declaration is here 3213 | MemoryRegionList *new_ml, *ml, *next_ml; | ^~ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230904161235.84651-22-philmd@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2023-09-19memory: avoid updating ioeventfds for some address_spacehongmianquan1-0/+12
When updating ioeventfds, we need to iterate all address spaces, but some address spaces do not register eventfd_add|del call when memory_listener_register() and they do nothing when updating ioeventfds. So we can skip these AS in address_space_update_ioeventfds(). The overhead of memory_region_transaction_commit() can be significantly reduced. For example, a VM with 8 vhost net devices and each one has 64 vectors, can reduce the time spent on memory_region_transaction_commit by 20%. Message-ID: <20230830032906.12488-1-hongmianquan@bytedance.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: hongmianquan <hongmianquan@bytedance.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-09-19softmmu/physmem: Distinguish between file access mode and mmap protectionDavid Hildenbrand1-4/+4
There is a difference between how we open a file and how we mmap it, and we want to support writable private mappings of readonly files. Let's define RAM_READONLY and RAM_READONLY_FD flags, to replace the single "readonly" parameter for file-related functions. In memory_region_init_ram_from_fd() and memory_region_init_ram_from_file(), initialize mr->readonly based on the new RAM_READONLY flag. While at it, add some RAM_* flags we missed to add to the list of accepted flags in the documentation of some functions. No change in functionality intended. We'll make use of both flags next and start setting them independently for memory-backend-file. Message-ID: <20230906120503.359863-3-david@redhat.com> Acked-by: Peter Xu <peterx@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-05-23hostmem-file: add offset optionAlexander Graf1-1/+2
Add an option for hostmem-file to start the memory object at an offset into the target file. This is useful if multiple memory objects reside inside the same target file, such as a device node. In particular, it's useful to map guest memory directly into /dev/mem for experimentation. To make this work consistently, also fix up all places in QEMU that expect fd offsets to be 0. Signed-off-by: Alexander Graf <graf@amazon.com> Message-Id: <20230403221421.60877-1-graf@amazon.com> Acked-by: Markus Armbruster <armbru@redhat.com> Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
2023-05-22memory: stricter checks prior to unsetting engaged_in_ioAlexander Bulekov1-1/+3
engaged_in_io could be unset by an MR with re-entrancy checks disabled. Ensure that only MRs that can set the engaged_in_io flag can unset it. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20230516084002.3813836-1-alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-05-18migration: Add last stage indicator to global dirty logGavin Shan1-5/+5
The global dirty log synchronization is used when KVM and dirty ring are enabled. There is a particularity for ARM64 where the backup bitmap is used to track dirty pages in non-running-vcpu situations. It means the dirty ring works with the combination of ring buffer and backup bitmap. The dirty bits in the backup bitmap needs to collected in the last stage of live migration. In order to identify the last stage of live migration and pass it down, an extra parameter is added to the relevant functions and callbacks. This last stage indicator isn't used until the dirty ring is enabled in the subsequent patches. No functional change intended. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Tested-by: Zhenyu Zhang <zhenyzha@redhat.com> Message-Id: <20230509022122.20888-2-gshan@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-04-28memory: prevent dma-reentracy issuesAlexander Bulekov1-0/+16
Add a flag to the DeviceState, when a device is engaged in PIO/MMIO/DMA. This flag is set/checked prior to calling a device's MemoryRegion handlers, and set when device code initiates DMA. The purpose of this flag is to prevent two types of DMA-based reentrancy issues: 1.) mmio -> dma -> mmio case 2.) bh -> dma write -> mmio case These issues have led to problems such as stack-exhaustion and use-after-frees. Summary of the problem from Peter Maydell: https://lore.kernel.org/qemu-devel/CAFEAcA_23vc7hE3iaM-JVA6W38LK4hJoWae5KcknhPRD5fPBZA@mail.gmail.com Resolves: https://gitlab.com/qemu-project/qemu/-/issues/62 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/540 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/541 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/556 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/557 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/827 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1282 Resolves: CVE-2023-0330 Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230427211013.2994127-2-alxndr@bu.edu> [thuth: Replace warn_report() with warn_report_once()] Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-04-05Revert "memory: Optimize replay of guest mapping"Peter Maydell1-2/+2
This reverts commit 6da24341866fa940fd7d575788a2319514941c77 ("memory: Optimize replay of guest mapping"). This change breaks the mps3-an547 board under TCG (and probably other TCG boards using an IOMMU), which now assert: $ ./build/x86/qemu-system-arm --machine mps3-an547 -serial stdio -kernel /tmp/an547-mwe/build/test.elf qemu-system-arm: ../../softmmu/memory.c:1903: memory_region_register_iommu_notifier: Assertion `n->end <= memory_region_size(mr)' failed. This is because tcg_register_iommu_notifier() registers an IOMMU notifier which covers the entire address space, so the assertion added in this commit is not correct. For the 8.0 release, just revert this commit as it is only an optimization. Fixes: 6da24341866f ("memory: Optimize replay of guest mapping") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 917c1c552b2d1b732f9a86c6a90684c3a5e4cada.1680640587.git.mst@redhat.com
2023-03-16exec/memory: Fix kernel-doc warningBernhard Beschow1-4/+4
During build the kernel-doc script complains about the following issue: src/docs/../include/exec/memory.h:1741: warning: Function parameter or member 'n' not described in 'memory_region_unmap_iommu_notifier_range' src/docs/../include/exec/memory.h:1741: warning: Excess function parameter 'notifier' description in 'memory_region_unmap_iommu_notifier_range' Settle on "notifier" for consistency with other memory functions. Fixes: 7caebbf9ea53 ("memory: introduce memory_region_unmap_iommu_notifier_range()") Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230315072552.47117-1-shentey@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2023-03-02memory: introduce memory_region_unmap_iommu_notifier_range()Jason Wang1-0/+13
This patch introduces a new helper to unmap the range of a specific IOMMU notifier. Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230223065924.42503-4-jasowang@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-03-02memory: Optimize replay of guest mappingZhenzhong Duan1-2/+2
On x86, there are two notifiers registered due to vtd-ir memory region splitting the whole address space. During replay of the address space for each notifier, the whole address space is scanned which is unnecessory. We only need to scan the space belong to notifier montiored space. Assert when notifier is used to monitor beyond iommu memory region's address space. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20230215065238.713041-1-zhenzhong.duan@intel.com> Acked-by: Peter Xu <peterx@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-01-18bulk: Rename TARGET_FMT_plx -> HWADDR_FMT_plxPhilippe Mathieu-Daudé1-9/+9
The 'hwaddr' type is defined in "exec/hwaddr.h" as: hwaddr is the type of a physical address (its size can be different from 'target_ulong'). All definitions use the 'HWADDR_' prefix, except TARGET_FMT_plx: $ fgrep define include/exec/hwaddr.h #define HWADDR_H #define HWADDR_BITS 64 #define HWADDR_MAX UINT64_MAX #define TARGET_FMT_plx "%016" PRIx64 ^^^^^^ #define HWADDR_PRId PRId64 #define HWADDR_PRIi PRIi64 #define HWADDR_PRIo PRIo64 #define HWADDR_PRIu PRIu64 #define HWADDR_PRIx PRIx64 #define HWADDR_PRIX PRIX64 Since hwaddr's size can be *different* from target_ulong, it is very confusing to read one of its format using the 'TARGET_FMT_' prefix, normally used for the target_long / target_ulong types: $ fgrep TARGET_FMT_ include/exec/cpu-defs.h #define TARGET_FMT_lx "%08x" #define TARGET_FMT_ld "%d" #define TARGET_FMT_lu "%u" #define TARGET_FMT_lx "%016" PRIx64 #define TARGET_FMT_ld "%" PRId64 #define TARGET_FMT_lu "%" PRIu64 Apparently this format was missed during commit a8170e5e97 ("Rename target_phys_addr_t to hwaddr"), so complete it by doing a bulk-rename with: $ sed -i -e s/TARGET_FMT_plx/HWADDR_FMT_plx/g $(git grep -l TARGET_FMT_plx) Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230110212947.34557-1-philmd@linaro.org> [thuth: Fix some warnings from checkpatch.pl along the way] Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-12-14cleanup: Tweak and re-run return_directly.cocciMarkus Armbruster1-9/+2
Tweak the semantic patch to drop redundant parenthesis around the return expression. Coccinelle drops a comment in hw/rdma/vmw/pvrdma_cmd.c; restored manually. Coccinelle messes up vmdk_co_create(), not sure why. Change dropped, will be done manually in the next commit. Line breaks in target/avr/cpu.h and hw/rdma/vmw/pvrdma_cmd.c tidied up manually. Whitespace in tools/virtiofsd/fuse_lowlevel.c tidied up manually. checkpatch.pl complains "return of an errno should typically be -ve" two times for hw/9pfs/9p-synth.c. Preexisting, the patch merely makes it visible to checkpatch.pl. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221122134917.1217307-2-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2022-11-07vfio: move implement of vfio_get_xlat_addr() to memory.cCindy Lu1-0/+72
- Move the implement vfio_get_xlat_addr to softmmu/memory.c, and change the name to memory_get_xlat_addr(). So we can use this function on other devices, such as vDPA device. - Add a new function vfio_get_xlat_addr in vfio/common.c, and it will check whether the memory is backed by a discard manager. then device can have its own warning. Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20221031031020.1405111-2-lulu@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-06Replace TARGET_WORDS_BIGENDIANMarc-André Lureau1-1/+1
Convert the TARGET_WORDS_BIGENDIAN macro, similarly to what was done with HOST_BIG_ENDIAN. The new TARGET_BIG_ENDIAN macro is either 0 or 1, and thus should always be defined to prevent misuse. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Suggested-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220323155743.1585078-8-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-29memory: Make memory_region_readd_subregion() properly handle mapped aliasesDavid Hildenbrand1-2/+1
memory_region_readd_subregion() wants to readd a region by first removing it and then readding it. For readding, it doesn't use one of the memory_region_add_*() variants, which is why fail to re-increment the mr->mapped_via_alias counters, resulting in the assert(alias->mapped_via_alias >= 0) in memory_region_del_subregion() triggering the next time we call memory_region_readd_subregion(). Fix it by using memory_region_add_subregion_common() for readding the region. Reported-by: Niek Linnenbank <nieklinnenbank@gmail.com> Fixes: 5ead62185d23 ("memory: Make memory_region_is_mapped() succeed when mapped via an alias") Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Xu <peterx@redhat.com> Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20220201100940.47788-1-david@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-02-16memory: Fix qemu crash on starting dirty log twice with stopped VMPeter Xu1-16/+45
QEMU can now easily crash with two continuous migration carried out: (qemu) migrate -d exec:cat>out (qemu) migrate_cancel (qemu) migrate -d exec:cat>out [crash] ../softmmu/memory.c:2782: memory_global_dirty_log_start: Assertion `!(global_dirty_tracking & flags)' failed. It's because memory API provides a way to postpone dirty log stop if the VM is stopped, and that'll be re-done until the next VM start. It was added in 2017 with commit 1931076077 ("migration: optimize the downtime", 2017-08-01). However the recent work on allowing dirty tracking to be bitmask broke it, which is commit 63b41db4bc ("memory: make global_dirty_tracking a bitmask", 2021-11-01). The fix proposed in this patch contains two things: (1) Instead of passing over the flags to postpone stop dirty track, we add a global variable (along with current vmstate_change variable) to record what flags to stop dirty tracking. (2) When start dirty tracking, instead if remove the vmstate hook directly, we also execute the postponed stop process so that we make sure all the starts and stops will be paired. This procedure is overlooked in the bitmask-ify work in 2021. Cc: Hyman Huang <huangy81@chinatelecom.cn> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2044818 Fixes: 63b41db4bc ("memory: make global_dirty_tracking a bitmask") Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20220207123019.27223-1-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-01-18memory: Fix incorrect calls of log_global_start/stopPeter Xu1-13/+14
We should only call the log_global_start/stop when the global dirty track bitmask changes from zero<->non-zero. No real issue reported for this yet probably because no immediate user to enable both dirty rate measurement and migration at the same time. However it'll be good to be prepared for it. Fixes: 63b41db4bc ("memory: make global_dirty_tracking a bitmask") Cc: qemu-stable@nongnu.org Cc: Hyman Huang <huangy81@chinatelecom.cn> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Cc: David Hildenbrand <david@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20211130080028.6474-1-peterx@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-01-18memory: Make memory_region_is_mapped() succeed when mapped via an aliasDavid Hildenbrand1-1/+12
memory_region_is_mapped() currently does not return "true" when a memory region is mapped via an alias. Assuming we have: alias (A0) -> alias (A1) -> region (R0) Mapping A0 would currently only make memory_region_is_mapped() succeed on A0, but not on A1 and R0. Let's fix that by adding a "mapped_via_alias" counter to memory regions and updating it accordingly when an alias gets (un)mapped. I am not aware of actual issues, this is rather a cleanup to make it consistent. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20211102164317.45658-3-david@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-01-18memory: Have 'info mtree' remove duplicated Address Space informationPhilippe Mathieu-Daudé1-3/+60
Per Peter Maydell [*]: 'info mtree' monitor command was designed on the assumption that there's really only one or two interesting address spaces, and with more recent developments that's just not the case any more. Similarly about how the FlatView are sorted using a GHashTable, sort the AddressSpace objects to remove the duplications (AS using the same root MemoryRegion). This drastically reduces the output of 'info mtree' on some boards. Before: $ (echo info mtree; echo q) \ | qemu-system-aarch64 -S -monitor stdio -M raspi3b \ | wc -l 423 After: $ (echo info mtree; echo q) \ | qemu-system-aarch64 -S -monitor stdio -M raspi3b \ | wc -l 106 (qemu) info mtree address-space: I/O 0000000000000000-000000000000ffff (prio 0, i/o): io address-space: cpu-memory-0 address-space: cpu-memory-1 address-space: cpu-memory-2 address-space: cpu-memory-3 address-space: cpu-secure-memory-0 address-space: cpu-secure-memory-1 address-space: cpu-secure-memory-2 address-space: cpu-secure-memory-3 address-space: memory 0000000000000000-ffffffffffffffff (prio 0, i/o): system 0000000000000000-000000003fffffff (prio 0, ram): ram 000000003f000000-000000003fffffff (prio 1, i/o): bcm2835-peripherals 000000003f003000-000000003f00301f (prio 0, i/o): bcm2835-sys-timer 000000003f004000-000000003f004fff (prio -1000, i/o): bcm2835-txp 000000003f006000-000000003f006fff (prio 0, i/o): mphi 000000003f007000-000000003f007fff (prio 0, i/o): bcm2835-dma 000000003f00b200-000000003f00b3ff (prio 0, i/o): bcm2835-ic 000000003f00b400-000000003f00b43f (prio -1000, i/o): bcm2835-sp804 000000003f00b800-000000003f00bbff (prio 0, i/o): bcm2835-mbox 000000003f100000-000000003f1001ff (prio 0, i/o): bcm2835-powermgt 000000003f101000-000000003f102fff (prio 0, i/o): bcm2835-cprman 000000003f104000-000000003f10400f (prio 0, i/o): bcm2835-rng 000000003f200000-000000003f200fff (prio 0, i/o): bcm2835_gpio 000000003f201000-000000003f201fff (prio 0, i/o): pl011 000000003f202000-000000003f202fff (prio 0, i/o): bcm2835-sdhost 000000003f203000-000000003f2030ff (prio -1000, i/o): bcm2835-i2s 000000003f204000-000000003f20401f (prio -1000, i/o): bcm2835-spi0 000000003f205000-000000003f20501f (prio -1000, i/o): bcm2835-i2c0 000000003f20f000-000000003f20f07f (prio -1000, i/o): bcm2835-otp 000000003f212000-000000003f212007 (prio 0, i/o): bcm2835-thermal 000000003f214000-000000003f2140ff (prio -1000, i/o): bcm2835-spis 000000003f215000-000000003f2150ff (prio 0, i/o): bcm2835-aux 000000003f300000-000000003f3000ff (prio 0, i/o): sdhci 000000003f600000-000000003f6000ff (prio -1000, i/o): bcm2835-smi 000000003f804000-000000003f80401f (prio -1000, i/o): bcm2835-i2c1 000000003f805000-000000003f80501f (prio -1000, i/o): bcm2835-i2c2 000000003f900000-000000003f907fff (prio -1000, i/o): bcm2835-dbus 000000003f910000-000000003f917fff (prio -1000, i/o): bcm2835-ave0 000000003f980000-000000003f990fff (prio 0, i/o): dwc2 000000003f980000-000000003f980fff (prio 0, i/o): dwc2-io 000000003f981000-000000003f990fff (prio 0, i/o): dwc2-fifo 000000003fc00000-000000003fc00fff (prio -1000, i/o): bcm2835-v3d 000000003fe00000-000000003fe000ff (prio -1000, i/o): bcm2835-sdramc 000000003fe05000-000000003fe050ff (prio 0, i/o): bcm2835-dma-chan15 0000000040000000-00000000400000ff (prio 0, i/o): bcm2836-control address-space: bcm2835-dma-memory address-space: bcm2835-fb-memory address-space: bcm2835-property-memory address-space: dwc2 0000000000000000-00000000ffffffff (prio 0, i/o): bcm2835-gpu 0000000000000000-000000003fffffff (prio 0, ram): alias bcm2835-gpu-ram-alias[*] @ram 0000000000000000-000000003fffffff 0000000040000000-000000007fffffff (prio 0, ram): alias bcm2835-gpu-ram-alias[*] @ram 0000000000000000-000000003fffffff 000000007e000000-000000007effffff (prio 1, i/o): alias bcm2835-peripherals @bcm2835-peripherals 0000000000000000-0000000000ffffff 0000000080000000-00000000bfffffff (prio 0, ram): alias bcm2835-gpu-ram-alias[*] @ram 0000000000000000-000000003fffffff 00000000c0000000-00000000ffffffff (prio 0, ram): alias bcm2835-gpu-ram-alias[*] @ram 0000000000000000-000000003fffffff address-space: bcm2835-mbox-memory 0000000000000000-000000000000008f (prio 0, i/o): bcm2835-mbox 0000000000000010-000000000000001f (prio 0, i/o): bcm2835-fb 0000000000000080-000000000000008f (prio 0, i/o): bcm2835-property memory-region: ram 0000000000000000-000000003fffffff (prio 0, ram): ram memory-region: bcm2835-peripherals 000000003f000000-000000003fffffff (prio 1, i/o): bcm2835-peripherals 000000003f003000-000000003f00301f (prio 0, i/o): bcm2835-sys-timer 000000003f004000-000000003f004fff (prio -1000, i/o): bcm2835-txp 000000003f006000-000000003f006fff (prio 0, i/o): mphi 000000003f007000-000000003f007fff (prio 0, i/o): bcm2835-dma 000000003f00b200-000000003f00b3ff (prio 0, i/o): bcm2835-ic 000000003f00b400-000000003f00b43f (prio -1000, i/o): bcm2835-sp804 000000003f00b800-000000003f00bbff (prio 0, i/o): bcm2835-mbox 000000003f100000-000000003f1001ff (prio 0, i/o): bcm2835-powermgt 000000003f101000-000000003f102fff (prio 0, i/o): bcm2835-cprman 000000003f104000-000000003f10400f (prio 0, i/o): bcm2835-rng 000000003f200000-000000003f200fff (prio 0, i/o): bcm2835_gpio 000000003f201000-000000003f201fff (prio 0, i/o): pl011 000000003f202000-000000003f202fff (prio 0, i/o): bcm2835-sdhost 000000003f203000-000000003f2030ff (prio -1000, i/o): bcm2835-i2s 000000003f204000-000000003f20401f (prio -1000, i/o): bcm2835-spi0 000000003f205000-000000003f20501f (prio -1000, i/o): bcm2835-i2c0 000000003f20f000-000000003f20f07f (prio -1000, i/o): bcm2835-otp 000000003f212000-000000003f212007 (prio 0, i/o): bcm2835-thermal 000000003f214000-000000003f2140ff (prio -1000, i/o): bcm2835-spis 000000003f215000-000000003f2150ff (prio 0, i/o): bcm2835-aux 000000003f300000-000000003f3000ff (prio 0, i/o): sdhci 000000003f600000-000000003f6000ff (prio -1000, i/o): bcm2835-smi 000000003f804000-000000003f80401f (prio -1000, i/o): bcm2835-i2c1 000000003f805000-000000003f80501f (prio -1000, i/o): bcm2835-i2c2 000000003f900000-000000003f907fff (prio -1000, i/o): bcm2835-dbus 000000003f910000-000000003f917fff (prio -1000, i/o): bcm2835-ave0 000000003f980000-000000003f990fff (prio 0, i/o): dwc2 000000003f980000-000000003f980fff (prio 0, i/o): dwc2-io 000000003f981000-000000003f990fff (prio 0, i/o): dwc2-fifo 000000003fc00000-000000003fc00fff (prio -1000, i/o): bcm2835-v3d 000000003fe00000-000000003fe000ff (prio -1000, i/o): bcm2835-sdramc 000000003fe05000-000000003fe050ff (prio 0, i/o): bcm2835-dma-chan15 (qemu) q [*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg829821.html Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210904231101.1071929-2-philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-01-18memory: Split mtree_info() as mtree_info_flatview() + mtree_info_as()Philippe Mathieu-Daudé1-34/+43
While mtree_info() handles both ASes and flatviews cases, the two cases share basically no code. Split mtree_info() as mtree_info_flatview() + mtree_info_as() to simplify. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210904231101.1071929-2-philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-01-18memory: Directly dispatch alias accesses on origin memory regionPhilippe Mathieu-Daudé1-0/+10
Since commit 2cdfcf272d ("memory: assign MemoryRegionOps to all regions"), all newly created regions are assigned with unassigned_mem_ops (which might be then overwritten). When using aliased container regions, and there is no region mapped at address 0 in the container, the memory_region_dispatch_read() and memory_region_dispatch_write() calls incorrectly return the container unassigned_mem_ops, because the alias offset is not used. Consider the following setup: +--------------------+ < - - - - - - - - - - - + | Container | mr | (unassigned_mem) | | | | | | | | | alias_offset + + <- - - - - - +----------+---------+ | +----------------+ | | | | | MemoryRegion0 | | | | | +----------------+ | | Alias | addr1 | | MemoryRegion1 | | <~ ~ ~ ~ ~ | | <~~~~~~ | +----------------+ | | | | | +--------------------+ | | | | | | | | | +----------------+ | | | MemoryRegionX | | | +----------------+ | | | MemoryRegionY | | | +----------------+ | | | MemoryRegionZ | | | +----------------+ | +--------------------+ The memory_region_init_alias() flow is: memory_region_init_alias() -> memory_region_init() -> object_initialize(TYPE_MEMORY_REGION) -> memory_region_initfn() -> mr->ops = &unassigned_mem_ops; Later when accessing offset=addr1 via the alias, we expect to hit MemoryRegion1. The memory_region_dispatch_read() flow is: memory_region_dispatch_read(addr1) -> memory_region_access_valid(mr) <- addr1 offset is ignored -> mr->ops->valid.accepts() -> unassigned_mem_accepts() <- false <- false <- MEMTX_DECODE_ERROR The caller gets a MEMTX_DECODE_ERROR while the access is OK. Fix by dispatching aliases recursively, accessing its origin region after adding the alias offset. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20210418055708.820980-1-f4bug@amsat.org>
2021-11-01memory: Introduce replay_discarded callback for RamDiscardManagerDavid Hildenbrand1-0/+11
Introduce replay_discarded callback similar to our existing replay_populated callback, to be used my migration code to never migrate discarded memory. Acked-by: Peter Xu <peterx@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2021-11-01memory: make global_dirty_tracking a bitmaskHyman Huang(黄勇)1-11/+21
since dirty ring has been introduced, there are two methods to track dirty pages of vm. it seems that "logging" has a hint on the method, so rename the global_dirty_log to global_dirty_tracking would make description more accurate. dirty rate measurement may start or stop dirty tracking during calculation. this conflict with migration because stop dirty tracking make migration leave dirty pages out then that'll be a problem. make global_dirty_tracking a bitmask can let both migration and dirty rate measurement work fine. introduce GLOBAL_DIRTY_MIGRATION and GLOBAL_DIRTY_DIRTY_RATE to distinguish what current dirty tracking aims for, migration or dirty rate. Signed-off-by: Hyman Huang(黄勇) <huangy81@chinatelecom.cn> Message-Id: <9c9388657cfa0301bd2c1cfa36e7cf6da4aeca19.1624040308.git.huangy81@chinatelecom.cn> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2021-10-13memory: Log access direction for invalid accessesBALATON Zoltan1-10/+10
In memory_region_access_valid() invalid accesses are logged to help debugging but the log message does not say if it was a read or write. Log that too to better identify the access causing the problem. Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20211011173616.F1DE0756022@zero.eik.bme.hu> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-09-30memory: Add tracepoint for dirty syncPeter Xu1-0/+2
Trace at memory_region_sync_dirty_bitmap() for log_sync() or global_log_sync() on memory regions. One trace line should suffice when it finishes, so as to estimate the time used for each log sync process. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20210817013706.30986-1-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30memory: Add RAM_PROTECTED flag to skip IOMMU mappingsSean Christopherson1-0/+5
Add a new RAMBlock flag to denote "protected" memory, i.e. memory that looks and acts like RAM but is inaccessible via normal mechanisms, including DMA. Use the flag to skip protected memory regions when mapping RAM for DMA in VFIO. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Yang Zhong <yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-11Merge remote-tracking branch ↵Peter Maydell1-4/+8
'remotes/vivier2/tags/trivial-branch-for-6.1-pull-request' into staging Trivial patches pull request 20210709 # gpg: Signature made Fri 09 Jul 2021 21:26:52 BST # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier2/tags/trivial-branch-for-6.1-pull-request: util/guest-random: Fix size arg to tail memcpy migration: fix typo in mig_throttle_guest_down comment target/xtensa/xtensa-semi: Fix compilation problem on Haiku hw/virtio: Document *_should_notify() are called within rcu_read_lock() misc: Remove redundant new line in perror() virtiofsd: Add missing newline in error message misc: Fix "havn't" typo memory: Display MemoryRegion name in read/write ops trace events qemu-option: Drop dead assertion Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-09memory: Display MemoryRegion name in read/write ops trace eventsPhilippe Mathieu-Daudé1-4/+8
MemoryRegion names is cached on first call to memory_region_name(), so displaying the name is trace events is cheap. Add it for read / write ops. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210307074833.143106-1-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-08memory: Helpers to copy/free a MemoryRegionSectionDavid Hildenbrand1-0/+27
In case one wants to create a permanent copy of a MemoryRegionSections, one needs access to flatview_ref()/flatview_unref(). Instead of exposing these, let's just add helpers to copy/free a MemoryRegionSection and properly adjust references. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-3-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-08memory: Introduce RamDiscardManager for RAM memory regionsDavid Hildenbrand1-0/+71
We have some special RAM memory regions (managed by virtio-mem), whereby the guest agreed to only use selected memory ranges. "unused" parts are discarded so they won't consume memory - to logically unplug these memory ranges. Before the VM is allowed to use such logically unplugged memory again, coordination with the hypervisor is required. This results in "sparse" mmaps/RAMBlocks/memory regions, whereby only coordinated parts are valid to be used/accessed by the VM. In most cases, we don't care about that - e.g., in KVM, we simply have a single KVM memory slot. However, in case of vfio, registering the whole region with the kernel results in all pages getting pinned, and therefore an unexpected high memory consumption - discarding of RAM in that context is broken. Let's introduce a way to coordinate discarding/populating memory within a RAM memory region with such special consumers of RAM memory regions: they can register as listeners and get updates on memory getting discarded and populated. Using this machinery, vfio will be able to map only the currently populated parts, resulting in discarded parts not getting pinned and not consuming memory. A RamDiscardManager has to be set for a memory region before it is getting mapped, and cannot change while the memory region is mapped. Note: At some point, we might want to let RAMBlock users (esp. vfio used for nvme://) consume this interface as well. We'll need RAMBlock notifier calls when a RAMBlock is getting mapped/unmapped (via the corresponding memory region), so we can properly register a listener there as well. Reviewed-by: Pankaj Gupta <pankaj.gupta@cloud.ionos.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Auger Eric <eric.auger@redhat.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Cc: teawater <teawaterz@linux.alibaba.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210413095531.25603-2-david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-06-15softmmu/memory: Pass ram_flags to qemu_ram_alloc() and qemu_ram_alloc_internal()David Hildenbrand1-2/+2
Let's pass ram_flags to qemu_ram_alloc() and qemu_ram_alloc_internal(), preparing for passing additional flags. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> for memory backend and machine core Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210510114328.21835-7-david@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-15softmmu/memory: Pass ram_flags to memory_region_init_ram_shared_nomigrate()David Hildenbrand1-9/+9
Let's forward ram_flags instead, renaming memory_region_init_ram_shared_nomigrate() into memory_region_init_ram_flags_nomigrate(). Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> for memory backend and machine core Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210510114328.21835-6-david@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-15softmmu/memory: Pass ram_flags to qemu_ram_alloc_from_fd()David Hildenbrand1-4/+3
Let's pass in ram flags just like we do with qemu_ram_alloc_from_file(), to clean up and prepare for more flags. Simplify the documentation of passed ram flags: Looking at our documentation of RAM_SHARED and RAM_PMEM is sufficient, no need to be repetitive. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> for memory backend and machine core Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210510114328.21835-5-david@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-26memory: Introduce log_sync_global() to memory listenerPeter Xu1-10/+23
Some of the memory listener may want to do log synchronization without being able to specify a range of memory to sync but always globally. Such a memory listener should provide this new method instead of the log_sync() method. Obviously we can also achieve similar thing when we put the global sync logic into a log_sync() handler. However that's not efficient enough because otherwise memory_global_dirty_log_sync() may do the global sync N times, where N is the number of flat ranges in the address space. Make this new method be exclusive to log_sync(). Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20210506160549.130416-2-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-02Do not include exec/address-spaces.h if it's not really necessaryThomas Huth1-1/+0
Stop including exec/address-spaces.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-5-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02Do not include cpu.h if it's not really necessaryThomas Huth1-1/+0
Stop including cpu.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-4-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-03-23memory: Add offset_in_region to flatview_cb argumentsPeter Maydell1-1/+3
The function flatview_for_each_range() calls a callback for each range in a FlatView. Currently the callback gets the start and length of the range and the MemoryRegion involved, but not the offset within the MemoryRegion. Add this to the callback's arguments; we're going to want it for a new use in the next commit. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210318174823.18066-4-peter.maydell@linaro.org
2021-03-16fuzz: move some DMA hooksAlexander Bulekov1-1/+0
For the sparse-mem device, we want the fuzzer to populate entire DMA reads from sparse-mem, rather than hooking into the individual MMIO memory_region_dispatch_read operations. Otherwise, the fuzzer will treat each sequential read separately (and populate it with a separate pattern). Work around this by rearranging some DMA hooks. Since the fuzzer has it's own logic to skip accidentally writing to MMIO regions, we can call the DMA cb, outside the flatview_translate loop. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-03-09sysemu: Let VMChangeStateHandler take boolean 'running' argumentPhilippe Mathieu-Daudé1-1/+1
The 'running' argument from VMChangeStateHandler does not require other value than 0 / 1. Make it a plain boolean. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210111152020.1422021-3-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-03-09exec/memory: Use struct Object typedefPhilippe Mathieu-Daudé1-6/+6
We forward-declare Object typedef in "qemu/typedefs.h" since commit ca27b5eb7cd ("qom/object: Move Object typedef to 'qemu/typedefs.h'"). Use it everywhere to make the code simpler. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210225182003.3629342-1-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-02-09memory: alloc RAM from file at offsetJagannathan Raman1-1/+2
Allow RAM MemoryRegion to be created from an offset in a file, instead of allocating at offset of 0 by default. This is needed to synchronize RAM between QEMU & remote process. Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 609996697ad8617e3b01df38accc5c208c24d74e.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-02-08fuzz: ignore address_space_map is_write flagAlexander Bulekov1-3/+2
We passed an is_write flag to the fuzz_dma_read_cb function to differentiate between the mapped DMA regions that need to be populated with fuzzed data, and those that don't. We simply passed through the address_space_map is_write parameter. The goal was to cut down on unnecessarily populating mapped DMA regions, when they are not read from. Unfortunately, nothing precludes code from reading from regions mapped with is_write=true. For example, see: https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04729.html This patch removes the is_write parameter to fuzz_dma_read_cb. As a result, we will fill all mapped DMA regions with fuzzed data, ignoring the specified transfer direction. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20210120060255.558535-1-alxndr@bu.edu>
2021-02-05accel: extend AccelState and AccelClass to user-modeClaudio Fontana1-1/+1
Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> [claudio: rebased on Richard's splitwx work] Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210204163931.7358-17-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-01memory: add readonly support to memory_region_init_ram_from_file()Stefan Hajnoczi1-2/+5
There is currently no way to open(O_RDONLY) and mmap(PROT_READ) when creating a memory region from a file. This functionality is needed since the underlying host file may not allow writing. Add a bool readonly argument to memory_region_init_ram_from_file() and the APIs it calls. Extend memory_region_init_ram_from_file() rather than introducing a memory_region_init_rom_from_file() API so that callers can easily make a choice between read/write and read-only at runtime without calling different APIs. No new RAMBlock flag is introduced for read-only because it's unclear whether RAMBlocks need to know that they are read-only. Pass a bool readonly argument instead. Both of these design decisions can be changed in the future. It just seemed like the simplest approach to me. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20210104171320.575838-2-stefanha@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-12-15memory: allow creating MemoryRegions before acceleratorsPaolo Bonzini1-6/+6
Compute the DIRTY_MEMORY_CODE bit in memory_region_get_dirty_log_mask instead of memory_region_init_*. This makes it possible to allocate memory backend objects at any time. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-08memory: Skip bad range assertion if notifier is DEVIOTLB_UNMAP typeEugenio Pérez1-2/+9
Device IOTLB invalidations can unmap arbitrary ranges, eiter outside of the memory region or even [0, ~0ULL] for all the space. The assertion could be hit by a guest, and rhel7 guest effectively hit it. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20201116165506.31315-6-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-12-08memory: Add IOMMUTLBEventEugenio Pérez1-11/+9
This way we can tell between regular IOMMUTLBEntry (entry of IOMMU hardware) and notifications. In the notifications, we set explicitly if it is a MAPs or an UNMAP, instead of trusting in entry permissions to differentiate them. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20201116165506.31315-3-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: David Gibson <david@gibson.dropbear.id.au>
generated by cgit v1.1 at 2024-07-19 22:17:22 +0000