aboutsummaryrefslogtreecommitdiff
path: root/softmmu/memory_mapping.c
AgeCommit message (Collapse)Author
2023-10-08system: Rename softmmu/ directory as system/Philippe Mathieu-Daudé
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-01-18bulk: Rename TARGET_FMT_plx -> HWADDR_FMT_plxPhilippe Mathieu-Daudé
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-03-21Use g_new() & friends where that makes obvious senseMarkus Armbruster
g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, for two reasons. One, it catches multiplication overflowing size_t. Two, it returns T * rather than void *, which lets the compiler catch more type errors. This commit only touches allocations with size arguments of the form sizeof(T). Patch created mechanically with: $ spatch --in-place --sp-file scripts/coccinelle/use-g_new-etc.cocci \ --macro-file scripts/cocci-macro-file.h FILES... Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20220315144156.1595462-4-armbru@redhat.com> Reviewed-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
2022-03-06sysemu/memory_mapping: Become target-agnosticPhilippe Mathieu-Daudé
target_ulong is target-specific, while vaddr isn't. Remove the unnecessary "exec/cpu-defs.h" target-speficic header from "memory_mapping.h" and use the target-agnostic "hw/core/cpu.h" locally in memory_mapping.c. Remove "exec/memory.h" since MemoryRegion is forward-declared in "qemu/typedefs.h". Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220207075426.81934-6-f4bug@amsat.org>
2021-10-02softmmu/memory_mapping: optimize for RamDiscardManager sectionsDavid Hildenbrand
virtio-mem logically plugs/unplugs memory within a sparse memory region and notifies via the RamDiscardManager interface when parts become plugged (populated) or unplugged (discarded). Currently, we end up (via the two users) 1) zeroing all logically unplugged/discarded memory during TPM resets. 2) reading all logically unplugged/discarded memory when dumping, to figure out the content is zero. 1) is always bad, because we assume unplugged memory stays discarded (and is already implicitly zero). 2) isn't that bad with anonymous memory, we end up reading the zero page (slow and unnecessary, though). However, once we use some file-backed memory (future use case), even reading will populate memory. Let's cut out all parts marked as not-populated (discarded) via the RamDiscardManager. As virtio-mem is the single user, this now means that logically unplugged memory ranges will no longer be included in the dump, which results in smaller dump files and faster dumping. virtio-mem has a minimum granularity of 1 MiB (and the default is usually 2 MiB). Theoretically, we can see quite some fragmentation, in practice we won't have it completely fragmented in 1 MiB pieces. Still, we might end up with many physical ranges. Both, the ELF format and kdump seem to be ready to support many individual ranges (e.g., for ELF it seems to be UINT32_MAX, kdump has a linear bitmap). Reviewed-by: Peter Xu <peterx@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Claudio Fontana <cfontana@suse.de> Cc: Thomas Huth <thuth@redhat.com> Cc: "Alex Bennée" <alex.bennee@linaro.org> Cc: Peter Xu <peterx@redhat.com> Cc: Laurent Vivier <lvivier@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210727082545.17934-5-david@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-02softmmu/memory_mapping: factor out adding physical memory rangesDavid Hildenbrand
Let's factor out adding a MemoryRegionSection to the list, to be reused in RamDiscardManager context next. Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Peter Xu <peterx@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Claudio Fontana <cfontana@suse.de> Cc: Thomas Huth <thuth@redhat.com> Cc: "Alex Bennée" <alex.bennee@linaro.org> Cc: Peter Xu <peterx@redhat.com> Cc: Laurent Vivier <lvivier@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210727082545.17934-4-david@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-02softmmu/memory_mapping: never merge ranges accross memory regionsDavid Hildenbrand
Let's make sure to not merge when different memory regions are involved. Unlikely, but theoretically possible. Acked-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Peter Xu <peterx@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Claudio Fontana <cfontana@suse.de> Cc: Thomas Huth <thuth@redhat.com> Cc: "Alex Bennée" <alex.bennee@linaro.org> Cc: Peter Xu <peterx@redhat.com> Cc: Laurent Vivier <lvivier@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20210727082545.17934-3-david@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-02Do not include cpu.h if it's not really necessaryThomas Huth
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>
2020-07-10softmmu: move softmmu only files from rootClaudio Fontana
move arch_init, balloon, cpus, ioport, memory, memory_mapping, qtest. They are all specific to CONFIG_SOFTMMU. Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20200629093504.3228-2-cfontana@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>