aboutsummaryrefslogtreecommitdiff
path: root/memory.c
AgeCommit message (Collapse)Author
2016-10-31memory: Don't use memcpy for ram_device regionsAlex Williamson
With a vfio assigned device we lay down a base MemoryRegion registered as an IO region, giving us read & write accessors. If the region supports mmap, we lay down a higher priority sub-region MemoryRegion on top of the base layer initialized as a RAM device pointer to the mmap. Finally, if we have any quirks for the device (ie. address ranges that need additional virtualization support), we put another IO sub-region on top of the mmap MemoryRegion. When this is flattened, we now potentially have sub-page mmap MemoryRegions exposed which cannot be directly mapped through KVM. This is as expected, but a subtle detail of this is that we end up with two different access mechanisms through QEMU. If we disable the mmap MemoryRegion, we make use of the IO MemoryRegion and service accesses using pread and pwrite to the vfio device file descriptor. If the mmap MemoryRegion is enabled and results in one of these sub-page gaps, QEMU handles the access as RAM, using memcpy to the mmap. Using either pread/pwrite or the mmap directly should be correct, but using memcpy causes us problems. I expect that not only does memcpy not necessarily honor the original width and alignment in performing a copy, but it potentially also uses processor instructions not intended for MMIO spaces. It turns out that this has been a problem for Realtek NIC assignment, which has such a quirk that creates a sub-page mmap MemoryRegion access. To resolve this, we disable memory_access_is_direct() for ram_device regions since QEMU assumes that it can use memcpy for those regions. Instead we access through MemoryRegionOps, which replaces the memcpy with simple de-references of standard sizes to the host memory. With this patch we attempt to provide unrestricted access to the RAM device, allowing byte through qword access as well as unaligned access. The assumption here is that accesses initiated by the VM are driven by a device specific driver, which knows the device capabilities. If unaligned accesses are not supported by the device, we don't want them to work in a VM by performing multiple aligned accesses to compose the unaligned access. A down-side of this philosophy is that the xp command from the monitor attempts to use the largest available access weidth, unaware of the underlying device. Using memcpy had this same restriction, but at least now an operator can dump individual registers, even if blocks of device memory may result in access widths beyond the capabilities of a given device (RTL NICs only support up to dword). Reported-by: Thorsten Kohfeldt <thorsten.kohfeldt@gmx.de> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
2016-10-31memory: Replace skip_dump flag with "ram_device"Alex Williamson
Setting skip_dump on a MemoryRegion allows us to modify one specific code path, but the restriction we're trying to address encompasses more than that. If we have a RAM MemoryRegion backed by a physical device, it not only restricts our ability to dump that region, but also affects how we should manipulate it. Here we recognize that MemoryRegions do not change to sometimes allow dumps and other times not, so we replace setting the skip_dump flag with a new initializer so that we know exactly the type of region to which we're applying this behavior. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
2016-10-24memory: optimize memory_region_sync_dirty_bitmapPaolo Bonzini
Avoid walking the FlatView of all address spaces. Most of the address spaces will have no log_sync callback on their listeners. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-10-24memory: optimize memory_global_dirty_log_syncPaolo Bonzini
Only return a nonzero dirty_log_mask for RAM/ROM memory regions. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-10-24memory: add a per-AddressSpace list of listenersPaolo Bonzini
This speeds up MEMORY_LISTENER_CALL noticeably. Right now, with many PCI devices you have N regions added to M AddressSpaces (M = # PCI devices with bus-master enabled) and each call looks up the whole listener list, with at least M listeners in it. Because most of the regions in N are BARs, which are also roughly proportional to M, the whole thing is O(M^3). This changes it to O(M^2), which is the best we can do without rewriting the whole thing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-10-24memory: eliminate global MemoryListenersPaolo Bonzini
There is none, so just drop the code. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-27migration: sync all address spacesPaolo Bonzini
Migrating a VM during reboot sometimes results in differences between the source and destination in the SMRAM area. This is because migration_bitmap_sync() only fetches from KVM the dirty log of address_space_memory. SMRAM memory slots are ignored and the modifications to SMRAM are not sent to the destination. Reported-by: He Rongguang <herongguang.he@huawei.com> Reviewed-by: He Rongguang <herongguang.he@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-27memory: introduce IOMMUOps.notify_flag_changedPeter Xu
The new interface can be used to replace the old notify_started() and notify_stopped(). Meanwhile it provides explicit flags so that IOMMUs can know what kind of notifications it is requested for. Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1474606948-14391-3-git-send-email-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-27memory: introduce IOMMUNotifier and its capsPeter Xu
IOMMU Notifier list is used for notifying IO address mapping changes. Currently VFIO is the only user. However it is possible that future consumer like vhost would like to only listen to part of its notifications (e.g., cache invalidations). This patch introduced IOMMUNotifier and IOMMUNotfierFlag bits for a finer grained control of it. IOMMUNotifier contains a bitfield for the notify consumer describing what kind of notification it is interested in. Currently two kinds of notifications are defined: - IOMMU_NOTIFIER_MAP: for newly mapped entries (additions) - IOMMU_NOTIFIER_UNMAP: for entries to be removed (cache invalidates) When registering the IOMMU notifier, we need to specify one or multiple types of messages to listen to. When notifications are triggered, its type will be checked against the notifier's type bits, and only notifiers with registered bits will be notified. (For any IOMMU implementation, an in-place mapping change should be notified with an UNMAP followed by a MAP.) Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1474606948-14391-2-git-send-email-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-14memory: remove memory_region_destructor_rom_devicePaolo Bonzini
It is equivalent to memory_region_destructor_ram, use that one. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-07-04memory: Assert that memory_region_init_rom_device() ops aren't NULLPeter Maydell
It doesn't make sense to pass a NULL ops argument to memory_region_init_rom_device(), because the effect will be that if the guest tries to write to the memory region then QEMU will segfault. Catch the bug earlier by sanity checking the arguments to this function, and remove the misleading documentation that suggests that passing NULL might be sensible. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1467122287-24974-4-git-send-email-peter.maydell@linaro.org
2016-07-04memory: Provide memory_region_init_rom()Peter Maydell
Provide a new helper function memory_region_init_rom() for memory regions which are read-only (and unlike those created by memory_region_init_rom_device() don't have special behaviour for writes). This has the same behaviour as calling memory_region_init_ram() and then memory_region_set_readonly() (which is what we do today in boards with pure ROMs) but is a more easily discoverable API for the purpose. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1467122287-24974-2-git-send-email-peter.maydell@linaro.org
2016-06-30memory: Add MemoryRegionIOMMUOps.notify_started/stopped callbacksAlexey Kardashevskiy
The IOMMU driver may change behavior depending on whether a notifier client is present. In the case of POWER, this represents a change in the visibility of the IOTLB, for other drivers such as intel-iommu and future AMD-Vi emulation, notifier support is not yet enabled and this provides the opportunity to flag that incompatibility. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Peter Xu <peterx@redhat.com> Tested-by: Peter Xu <peterx@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> [new log & extracted from [PATCH qemu v17 12/12] spapr_iommu, vfio, memory: Notify IOMMU about starting/stopping listening] Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-06-22memory: Add reporting of supported page sizesAlexey Kardashevskiy
Every IOMMU has some granularity which MemoryRegionIOMMUOps::translate uses when translating, however this information is not available outside the translate context for various checks. This adds a get_min_page_size callback to MemoryRegionIOMMUOps and a wrapper for it so IOMMU users (such as VFIO) can know the minimum actual page size supported by an IOMMU. As IOMMU MR represents a guest IOMMU, this uses TARGET_PAGE_SIZE as fallback. This removes vfio_container_granularity() and uses new helper in memory_region_iommu_replay() when replaying IOMMU mappings on added IOMMU memory region. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Alex Williamson <alex.williamson@redhat.com> [dwg: Removed an unnecessary calculation] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-05-29exec: hide mr->ram_addr from qemu_get_ram_ptr usersPaolo Bonzini
Let users of qemu_get_ram_ptr and qemu_ram_ptr_length pass in an address that is relative to the MemoryRegion. This basically means what address_space_translate returns. Because the semantics of the second parameter change, rename the function to qemu_map_ram_ptr. Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-05-29memory: split memory_region_from_host from qemu_ram_addr_from_hostPaolo Bonzini
Move the old qemu_ram_addr_from_host to memory_region_from_host and make it return an offset within the region. For qemu_ram_addr_from_host return the ram_addr_t directly, similar to what it was before commit 1b5ec23 ("memory: return MemoryRegion from qemu_ram_addr_from_host", 2013-07-04). Reviewed-by: Marc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-05-29memory: remove qemu_get_ram_fd, qemu_set_ram_fd, qemu_ram_block_host_ptrPaolo Bonzini
Remove direct uses of ram_addr_t and optimize memory_region_{get,set}_fd now that a MemoryRegion knows its RAMBlock directly. Reviewed-by: Marc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-05-29Revert "memory: Drop FlatRange.romd_mode"Paolo Bonzini
This reverts commit 5b5660adf1fdb61db14ec681b10463b8cba633f1, as it breaks the UEFI guest firmware (known as ArmVirtPkg or AAVMF) running in the "virt" machine type of "qemu-system-aarch64": Contrary to the commit message, (a->mr == b->mr) does *not* imply that (a->romd_mode == b->romd_mode): the pflash device model calls memory_region_rom_device_set_romd() -- for switching between the above modes --, and that function changes mr->romd_mode but the current AddressSpaceDispatch's FlatRange keeps the old value. Therefore region_del/region_add are not called on the KVM MemoryListener. Reported-by: Drew Jones <drjones@redhat.com> Tested-by: Drew Jones <drjones@redhat.com> Analyzed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-05-23memory: remove unnecessary masking of MemoryRegion ram_addrPaolo Bonzini
mr->ram_block->offset is already aligned to both host and target size (see qemu_ram_alloc_internal). Remove further masking as it is unnecessary. Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-05-23memory: Drop FlatRange.romd_modeFam Zheng
Its value is alway set to mr->romd_mode, so the removed comparisons are fully superseded by "a->mr == b->mr". Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <1458900629-2334-3-git-send-email-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-05-23memory: Remove code for mr->may_overlapFam Zheng
The collision check does nothing and hasn't been used. Remove the variable together with related code. Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <1458900629-2334-2-git-send-email-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-05-23memory: drop find_ram_block()Gonglei
On the one hand, we have already qemu_get_ram_block() whose function is similar. On the other hand, we can directly use mr->ram_block but searching RAMblock by ram_addr which is a kind of waste. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-Id: <1462845901-89716-2-git-send-email-arei.gonglei@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-05-19qemu-common: push cpu.h inclusion out of qemu-common.hPaolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-22include/qemu/osdep.h: Don't include qapi/error.hMarkus Armbruster
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the Error typedef. Since then, we've moved to include qemu/osdep.h everywhere. Its file comment explains: "To avoid getting into possible circular include dependencies, this file should not include any other QEMU headers, with the exceptions of config-host.h, compiler.h, os-posix.h and os-win32.h, all of which are doing a similar job to this file and are under similar constraints." qapi/error.h doesn't do a similar job, and it doesn't adhere to similar constraints: it includes qapi-types.h. That's in excess of 100KiB of crap most .c files don't actually need. Add the typedef to qemu/typedefs.h, and include that instead of qapi/error.h. Include qapi/error.h in .c files that need it and don't get it now. Include qapi-types.h in qom/object.h for uint16List. Update scripts/clean-includes accordingly. Update it further to match reality: replace config.h by config-target.h, add sysemu/os-posix.h, sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h comment quoted above similarly. This reduces the number of objects depending on qapi/error.h from "all of them" to less than a third. Unfortunately, the number depending on qapi-types.h shrinks only a little. More work is needed for that one. Signed-off-by: Markus Armbruster <armbru@redhat.com> [Fix compilation without the spice devel packages. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14trace: separate MMIO tracepoints from TB-access tracepointsHollis Blanchard
Memory accesses to code which has previously been translated into a TB show up in the MMIO path, so that they may invalidate the TB. It's extremely confusing to mix those in with device MMIOs, so split them into their own tracepoint. Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 1456949575-1633-2-git-send-email-hollis_blanchard@mentor.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-03-14trace: include CPU index in trace_memory_region_*()Hollis Blanchard
Knowing which CPU performed an action is essential for understanding SMP guest behavior. However, cpu_physical_memory_rw() may be executed by a machine init function, before any VCPUs are running, when there is no CPU running ('current_cpu' is NULL). In this case, store -1 in the trace record as the CPU index. Trace analysis tools may need to be aware of this special case. Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> Message-id: 1456949575-1633-1-git-send-email-hollis_blanchard@mentor.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-03-07exec: Pass RAMBlock pointer to qemu_ram_freeFam Zheng
The only caller now knows exactly which RAMBlock to free, so it's not necessary to do the lookup. Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <1456813104-25902-6-git-send-email-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-07memory: Drop MemoryRegion.ram_addrFam Zheng
All references to mr->ram_addr are replaced by memory_region_get_ram_addr(mr) (except for a few assertions that are replaced with mr->ram_block). Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <1456813104-25902-5-git-send-email-famz@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-07memory: Implement memory_region_get_ram_addr with mr->ram_blockFam Zheng
Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <1456813104-25902-4-git-send-email-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-07memory: Move assignment to ram_block to memory_region_init_*Fam Zheng
We don't force "const" qualifiers with pointers in QEMU, but it's still good to keep a clean function interface. Assigning to mr->ram_block is in this sense ugly - one initializer mutating its owning object's state. Move it to memory_region_init_*, where mr->ram_addr is assigned. Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <1456813104-25902-3-git-send-email-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-07exec: Return RAMBlock pointer from allocating functionsFam Zheng
Previously we return RAMBlock.offset; now return the pointer to the whole structure. ram_block_add returns void now, error is completely passed with errp. Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <1456813104-25902-2-git-send-email-famz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-01trace: use addresses instead of offsets in memory tracepointsHollis Blanchard
When memory_region_ops tracepoints are enabled, calculate and record the absolute address being accessed. Otherwise, we only get offsets into the memory region instead of addresses. [Fixed "offset" -> "addr" in trace event format strings. --Stefan] Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> Message-id: 1454976185-30095-3-git-send-email-hollis_blanchard@mentor.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-03-01trace: split subpage MMIOs into their own trace events.Hollis Blanchard
Previously, a single MMIO could trigger the memory_region_ops tracepoint twice: once on its way into subpage ops, then later on its way into the model's ops. Also, the fields previously called "addr" are actually offsets into the memory region. Rename them to "offset" while we're editing the tracepoint definitions. Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> Message-id: 1454976185-30095-2-git-send-email-hollis_blanchard@mentor.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-02-25memory: optimize qemu_get_ram_ptr and qemu_ram_ptr_lengthGonglei
these two functions consume too much cpu overhead to find the RAMBlock by ram address. After this patch, we can pass the RAMBlock pointer to them so that they don't need to find the RAMBlock anymore most of the time. We can get better performance in address translation processing. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Message-Id: <1455935721-8804-3-git-send-email-arei.gonglei@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-02-25exec: store RAMBlock pointer into memory regionGonglei
Each RAM memory region has a unique corresponding RAMBlock. In the current realization, the memory region only stored the ram_addr which means the offset of RAM address space, We need to qurey the global ram.list to find the ram block by ram_addr if we want to get the ram block, which is very expensive. Now, we store the RAMBlock pointer into memory region structure. So, if we know the mr, we can easily get the RAMBlock. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Message-Id: <1456130097-4208-2-git-send-email-arei.gonglei@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-02-08qom: Swap 'name' next to visitor in ObjectPropertyAccessorEric Blake
Similar to the previous patch, it's nice to have all functions in the tree that involve a visitor and a name for conversion to or from QAPI to consistently stick the 'name' parameter next to the Visitor parameter. Done by manually changing include/qom/object.h and qom/object.c, then running this Coccinelle script and touching up the fallout (Coccinelle insisted on adding some trailing whitespace). @ rule1 @ identifier fn; typedef Object, Visitor, Error; identifier obj, v, opaque, name, errp; @@ void fn - (Object *obj, Visitor *v, void *opaque, const char *name, + (Object *obj, Visitor *v, const char *name, void *opaque, Error **errp) { ... } @@ identifier rule1.fn; expression obj, v, opaque, name, errp; @@ fn(obj, v, - opaque, name, + name, opaque, errp) Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1454075341-13658-20-git-send-email-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-02-08qapi: Swap visit_* arguments for consistent 'name' placementEric Blake
JSON uses "name":value, but many of our visitor interfaces were called with visit_type_FOO(v, &value, name, errp). This can be a bit confusing to have to mentally swap the parameter order to match JSON order. It's particularly bad for visit_start_struct(), where the 'name' parameter is smack in the middle of the otherwise-related group of 'obj, kind, size' parameters! It's time to do a global swap of the parameter ordering, so that the 'name' parameter is always immediately after the Visitor argument. Additional reason in favor of the swap: the existing include/qjson.h prefers listing 'name' first in json_prop_*(), and I have plans to unify that file with the qapi visitors; listing 'name' first in qapi will minimize churn to the (admittedly few) qjson.h clients. Later patches will then fix docs, object.h, visitor-impl.h, and those clients to match. Done by first patching scripts/qapi*.py by hand to make generated files do what I want, then by running the following Coccinelle script to affect the rest of the code base: $ spatch --sp-file script `git grep -l '\bvisit_' -- '**/*.[ch]'` I then had to apply some touchups (Coccinelle insisted on TAB indentation in visitor.h, and botched the signature of visit_type_enum() by rewriting 'const char *const strings[]' to the syntactically invalid 'const char*const[] strings'). The movement of parameters is sufficient to provoke compiler errors if any callers were missed. // Part 1: Swap declaration order @@ type TV, TErr, TObj, T1, T2; identifier OBJ, ARG1, ARG2; @@ void visit_start_struct -(TV v, TObj OBJ, T1 ARG1, const char *name, T2 ARG2, TErr errp) +(TV v, const char *name, TObj OBJ, T1 ARG1, T2 ARG2, TErr errp) { ... } @@ type bool, TV, T1; identifier ARG1; @@ bool visit_optional -(TV v, T1 ARG1, const char *name) +(TV v, const char *name, T1 ARG1) { ... } @@ type TV, TErr, TObj, T1; identifier OBJ, ARG1; @@ void visit_get_next_type -(TV v, TObj OBJ, T1 ARG1, const char *name, TErr errp) +(TV v, const char *name, TObj OBJ, T1 ARG1, TErr errp) { ... } @@ type TV, TErr, TObj, T1, T2; identifier OBJ, ARG1, ARG2; @@ void visit_type_enum -(TV v, TObj OBJ, T1 ARG1, T2 ARG2, const char *name, TErr errp) +(TV v, const char *name, TObj OBJ, T1 ARG1, T2 ARG2, TErr errp) { ... } @@ type TV, TErr, TObj; identifier OBJ; identifier VISIT_TYPE =~ "^visit_type_"; @@ void VISIT_TYPE -(TV v, TObj OBJ, const char *name, TErr errp) +(TV v, const char *name, TObj OBJ, TErr errp) { ... } // Part 2: swap caller order @@ expression V, NAME, OBJ, ARG1, ARG2, ERR; identifier VISIT_TYPE =~ "^visit_type_"; @@ ( -visit_start_struct(V, OBJ, ARG1, NAME, ARG2, ERR) +visit_start_struct(V, NAME, OBJ, ARG1, ARG2, ERR) | -visit_optional(V, ARG1, NAME) +visit_optional(V, NAME, ARG1) | -visit_get_next_type(V, OBJ, ARG1, NAME, ERR) +visit_get_next_type(V, NAME, OBJ, ARG1, ERR) | -visit_type_enum(V, OBJ, ARG1, ARG2, NAME, ERR) +visit_type_enum(V, NAME, OBJ, ARG1, ARG2, ERR) | -VISIT_TYPE(V, OBJ, NAME, ERR) +VISIT_TYPE(V, NAME, OBJ, ERR) ) Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1454075341-13658-19-git-send-email-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-02-04all: Clean up includesPeter Maydell
Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1454089805-5470-16-git-send-email-peter.maydell@linaro.org
2016-01-21memory: Add address_space_init_shareable()Peter Crosthwaite
This will either create a new AS or return a pointer to an already existing equivalent one, if we have already created an AS for the specified root memory region. The motivation is to reuse address spaces as much as possible. It's going to be quite common that bus masters out in device land have pointers to the same memory region for their mastering yet each will need to create its own address space. Let the memory API implement sharing for them. Aside from the perf optimisations, this should reduce the amount of redundant output on info mtree as well. Thee returned value will be malloced, but the malloc will be automatically freed when the AS runs out of refs. Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> [PMM: dropped check for NULL root as unused; added doc-comment; squashed Peter C's reference-counting patch into this one; don't compare name string when deciding if we can share ASes; read as->malloced before the unref of as->root to avoid possible read-after-free if as->root was the owner of as] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
2015-12-17memory: inline a few small accessorsPaolo Bonzini
These are used in the address_space_* fast paths. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-12-17memory: avoid unnecessary object_ref/unrefPaolo Bonzini
For the common case of DMA into non-hotplugged RAM, it is unnecessary but expensive to do object_ref/unref. Add back an owner field to MemoryRegion, so that these memory regions can skip the reference counting. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-12-17exec: always call qemu_get_ram_ptr within rcu_read_lockPaolo Bonzini
Simplify the code and document the assumption. The only caller that is not within rcu_read_lock is memory_region_get_ram_ptr. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-12-17memory: emulate ioeventfdPavel Fedin
The ioeventfd mechanism is used by vhost, dataplane, and virtio-pci to turn guest MMIO/PIO writes into eventfd file descriptor events. This allows arbitrary threads to be notified when the guest writes to a specific MMIO/PIO address. qtest and TCG do not support ioeventfd because memory writes are not checked against registered ioeventfds in QEMU. This patch implements this in memory_region_dispatch_write() so qtest can use ioeventfd. Also this patch fixes vhost aborting on some misconfigured old kernels like 3.18.0 on ARM. It is possible to explicitly enable CONFIG_EVENTFD in expert settings, while MMIO binding support in KVM will still be missing. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Pavel Fedin <p.fedin@samsung.com> Message-Id: <006e01d12377$0b9c2d40$22d487c0$@samsung.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-12-17memory: Eliminate memory_region_destructor_ram_from_ptr()Eduardo Habkost
The function is equivalent to memory_region_destructor_ram(), so it's not needed anymore. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1446844805-14492-3-git-send-email-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-12-17exec: Eliminate qemu_ram_free_from_ptr()Eduardo Habkost
Replace qemu_ram_free_from_ptr() with qemu_ram_free(). The only difference between qemu_ram_free_from_ptr() and qemu_ram_free() is that g_free_rcu() is used instead of call_rcu(reclaim_ramblock). We can safely replace it because: * RAM blocks allocated by qemu_ram_alloc_from_ptr() always have RAM_PREALLOC set; * reclaim_ramblock(block) will do nothing except g_free(block) if RAM_PREALLOC is set at block->flags. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1446844805-14492-2-git-send-email-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-11-12memory: don't try to adjust endianness for zero length eventfdJason Wang
There's no need to adjust endianness for zero length eventfd since the data wrote was actually ignored by kernel. So skip the adjust in this case to fix a possible crash when trying to use wildcard mmio eventfd in ppc. Cc: Greg Kurz <gkurz@linux.vnet.ibm.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2015-11-04memory: call begin, log_start and commit when registering a new listenerPaolo Bonzini
This ensures that cpu_reload_memory_map() is called as soon as tcg_cpu_address_space_init() is called, and before cpu->memory_dispatch is used. qemu-system-s390x never changes the address spaces after tcg_cpu_address_space_init() is called, and thus tcg_commit() is never called. This causes a SIGSEGV. Because memory_map_init() will now call mem_commit(), we have to initialize io_mem_* before address_space_memory and friends. Reported-by: Philipp Kern <pkern@debian.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Fixes: 0a1c71cec63e95f9b8d0dc96d049d2daa00c5210 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-10-09memory: allow destroying a non-empty MemoryRegionPaolo Bonzini
This is legal; the MemoryRegion will simply unreference all the existing subregions and possibly bring them down with it as well. However, it requires a bit of care to avoid an infinite loop. Finalizing a memory region cannot trigger an address space update, but memory_region_del_subregion errs on the side of caution and might trigger a spurious update: avoid that by resetting mr->enabled first. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1443689999-12182-2-git-send-email-armbru@redhat.com>
2015-10-05memory: Allow replay of IOMMU mapping notificationsDavid Gibson
When we have guest visible IOMMUs, we allow notifiers to be registered which will be informed of all changes to IOMMU mappings. This is used by vfio to keep the host IOMMU mappings in sync with guest IOMMU mappings. However, unlike with a memory region listener, an iommu notifier won't be told about any mappings which already exist in the (guest) IOMMU at the time it is registered. This can cause problems if hotplugging a VFIO device onto a guest bus which had existing guest IOMMU mappings, but didn't previously have an VFIO devices (and hence no host IOMMU mappings). This adds a memory_region_iommu_replay() function to handle this case. It replays any existing mappings in an IOMMU memory region to a specified notifier. Because the IOMMU memory region doesn't internally remember the granularity of the guest IOMMU it has a small hack where the caller must specify a granularity at which to replay mappings. If there are finer mappings in the guest IOMMU these will be reported in the iotlb structures passed to the notifier which it must handle (probably causing it to flag an error). This isn't new - the VFIO iommu notifier must already handle notifications about guest IOMMU mappings too short for it to represent in the host IOMMU. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2015-09-18memory: Fix bad error handling in memory_region_init_ram_ptr()Markus Armbruster
Commit ef701d7 screwed up handling of out-of-memory conditions. Before the commit, we report the error and exit(1), in one place. The commit lifts the error handling up the call chain some, to three places. Fine. Except it uses &error_abort in these places, changing the behavior from exit(1) to abort(), and thus undoing the work of commit 3922825 "exec: Don't abort when we can't allocate guest memory". The previous two commits fixed one of the three places, another one was fixed in commit 33e0eb5. This commit fixes the third one. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1441983105-26376-5-git-send-email-armbru@redhat.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>