aboutsummaryrefslogtreecommitdiff
path: root/memory.c
AgeCommit message (Collapse)Author
2013-08-02memory.c: drop kvm.h dependencyMichael S. Tsirkin
memory.c does not use any kvm specific interfaces, don't include kvm.h Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2013-07-29memory: add tracepoints for MMIO reads/writesPaolo Bonzini
This is quite handy to debug softmmu targets. Reviewed-by: Andreas Faerber <afaerber@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 1375016242-32651-1-git-send-email-pbonzini@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-25memory: check memory region endianness, not target'sPaolo Bonzini
When combining multiple accesses into a single value, we need to do so in the device's desired endianness. The target endianness does not have any influence. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Message-id: 1374501278-31549-28-git-send-email-pbonzini@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-25memory: pass MemoryRegion to access_with_adjusted_sizePaolo Bonzini
The accessors all use a MemoryRegion opaque value. Avoid going uselessly through void*. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Message-id: 1374501278-31549-27-git-send-email-pbonzini@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-25memory: move functions aroundPaolo Bonzini
Prepare for next patch, no semantic change. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Message-id: 1374501278-31549-26-git-send-email-pbonzini@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-22memory: Fix zero-sized memory region printAlex Williamson
if mr->size == 0, then int128_get64(int128_sub(mr->size, int128_make64(1))) => assert(!a.hi) Also, use int128_one(). Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20130719184124.15864.20803.stgit@bling.home Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-07-18memory: Return -1 again on reads from unsigned regionsJan Kiszka
This restore the behavior prior to b018ddf633 which accidentally changed the return code to 0. Specifically guests probing for register existence were affected by this. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-18memory: actually set the ownerPaolo Bonzini
Brown paper bag for me. Originally commit 803c0816 came before commit 2c9b15c. When the order was inverted, I left in the NULL initialization of mr->owner. Reviewed-by: Hu Tao <hutao@cn.fujitsu.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-09cpu: Replace cpu_single_env with CPUState current_cpuAndreas Färber
Move it to qom/cpu.h. Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-07-04memory: add reference counting to FlatViewPaolo Bonzini
With this change, a FlatView can be used even after a concurrent update has replaced it. Because we do not yet have RCU, we use a mutex to protect the small critical sections that read/write the as->current_map pointer. Accesses to the FlatView can be done outside the mutex. If a MemoryRegion will be used after the FlatView is unref-ed (or after a MemoryListener callback is returned), a reference has to be added to that MemoryRegion. memory_region_find already does it for the region that it returns. The same will be done for address_space_translate as soon as the dispatch tree is also converted to RCU-style. Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04memory: use a new FlatView pointer on every topology updatePaolo Bonzini
This is the first step towards converting as->current_map to RCU-style updates, where the FlatView updates run concurrently with uses of an old FlatView. Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04memory: access FlatView from a local variablePaolo Bonzini
We will soon require accesses to as->current_map to be placed under a lock (with reference counting so as to keep the critical section small). To simplify this change, always fetch as->current_map into a local variable and access it through that variable. Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04memory: add ref/unref callsPaolo Bonzini
Add ref/unref calls at the following places: - places where memory regions are stashed by a listener and used outside the BQL (including in Xen or KVM). - memory_region_find callsites - creation of aliases and containers (only the aliased/contained region gets a reference to avoid loops) - around calls to del_subregion/add_subregion, where the region could disappear after the first call Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04memory: introduce memory_region_presentPaolo Bonzini
This new API will avoid having too many memory_region_ref/unref in paths that currently use memory_region_find. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04memory: add ref/unrefPaolo Bonzini
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04memory: add getter for ownerPaolo Bonzini
Whenever memory regions are accessed outside the BQL, they need to be preserved against hot-unplug. MemoryRegions actually do not have their own reference count; they piggyback on a QOM object, their "owner". The owner is set at creation time, and there is a function to retrieve the owner. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04memory: add owner argument to initialization functionsPaolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04ioport: Switch dispatching to memory core layerJan Kiszka
The current ioport dispatcher is a complex beast, mostly due to the need to deal with old portio interface users. But we can overcome it without converting all portio users by embedding the required base address of a MemoryRegionPortio access into that data structure. That removes the need to have the additional MemoryRegionIORange structure in the loop on every access. To handle old portio memory ops, we simply install dispatching handlers for portio memory regions when registering them with the memory core. This removes the need for the old_portio field. We can drop the additional aliasing of ioport regions and also the special address space listener. cpu_in and cpu_out now simply call address_space_read/write. And we can concentrate portio handling in a single source file. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-28cpu: Turn cpu_unassigned_access() into a CPUState hookAndreas Färber
Use it for all targets, but be careful not to pass invalid CPUState. cpu_single_env can be NULL, e.g. on Xen. Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-06-20memory: render_memory_region: factor out fr constant settersPeter Crosthwaite
These 4 replicated lines set properties of fr that are constant over the course of the function. Factor out their repeated setting (and also guards against them being set multiple times in the loop below). Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20memory: as_update_topology_pass: Improve commentsPeter Crosthwaite
These comments were a little difficult to read. First one had incorrect parenthesis. The part about attributes changing is really applicable to the region being 'in both' rather than 'in new' Second comment has an obscure parenthetic about 'Logging may have changed'. Made clearer, as this if is supposed to handle the case where the memory region is unchanged (with the notable exception re logging). Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20memory: Fix comment typoPeter Crosthwaite
s/ajacent/adjacent Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20memory: give name to every AddressSpaceAlexey Kardashevskiy
The "info mtree" command in QEMU console prints only "memory" and "I/O" address spaces while there are actually a lot more other AddressSpace structs created by PCI and VIO devices. Those devices do not normally have names and therefore not present in "info mtree" output. The patch fixes this. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20memory: Add iommu map/unmap notifiersDavid Gibson
This patch adds a NotifierList to MemoryRegions which represent IOMMUs allowing other parts of the code to register interest in mappings or unmappings from the IOMMU. All IOMMU implementations will need to call memory_region_notify_iommu() to inform those waiting on the notifier list, whenever an IOMMU mapping is made or removed. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20memory: iommu supportAvi Kivity
Add a new memory region type that translates addresses it is given, then forwards them to a target address space. This is similar to an alias, except that the mapping is more flexible than a linear translation and trucation, and also less efficient since the translation happens at runtime. The implementation uses an AddressSpace mapping the target region to avoid hierarchical dispatch all the way to the resolved region; only iommu regions are looked up dynamically. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Avi Kivity <avi.kivity@gmail.com> [Modified to put translation in address_space_translate; assume IOMMUs are not reachable from TCG. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20memory: make section size a 128-bit integerPaolo Bonzini
So far, the size of all regions passed to listeners could fit in 64 bits, because artificial regions (containers and aliases) are eliminated by the memory core, leaving only device regions which have reasonable sizes An IOMMU however cannot be eliminated by the memory core, and may have an artificial size, hence we may need 65 bits to represent its size. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29memory: propagate errors on I/O dispatchPaolo Bonzini
Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29memory: correctly handle endian-swapped 64-bit accessesPaolo Bonzini
Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29memory: split accesses even when the old MMIO callbacks are usedPaolo Bonzini
This is useful for 64-bit memory accesses. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29memory: add big endian support to access_with_adjusted_sizePaolo Bonzini
This will be used to split 8-byte access down to two four-byte accesses. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29memory: accept mismatching sizes in memory_region_access_validPaolo Bonzini
The memory API is able to use smaller/wider accesses than requested, match that in memory_region_access_valid. Of course, the accepts callback is still free to reject those accesses. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29memory: export memory_region_access_valid to exec.cPaolo Bonzini
We'll use it to implement address_space_access_valid. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29memory: assign MemoryRegionOps to all regionsPaolo Bonzini
This allows to remove the checks on section->readonly. Simply, write accesses to ROM will not be considered "direct" and will go through mr->ops without any special intervention. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29memory: move unassigned_mem_ops to memory.cPaolo Bonzini
reservation_ops is already doing the same thing. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29memory: dispatch unassigned accesses based on .valid.acceptsPaolo Bonzini
This provides the basics for detecting accesses to unassigned memory as soon as they happen, and also for a simple implementation of address_space_access_valid. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24memory: populate FlatView for new address spacesPaolo Bonzini
Even a new address space might have a non-empty FlatView. In order to initialize it properly, address_space_init should (a) call memory_region_transaction_commit after the address space is inserted into the list; (b) force memory_region_transaction_commit to do something. This bug was latent so far because all address spaces started empty, including the PCI address space where the bus master region is initially disabled. However, the target address space of an IOMMU is usually rooted at get_system_memory(), which might not be empty at the time the IOMMU is created. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24memory: fix address space initialization/destructionAvi Kivity
A couple of fields were left uninitialized. This was not observed earlier because all address spaces were statically allocated. Also free allocation for those fields. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Avi Kivity <avi.kivity@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24memory: make memory_global_sync_dirty_bitmap take an AddressSpacePaolo Bonzini
Since this is a MemoryListener operation, it only makes sense on an AddressSpace granularity. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24memory: do not duplicate memory_region_destructor_nonePaolo Bonzini
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24memory: Rename readable flag to romd_modeJan Kiszka
"Readable" is a very unfortunate name for this flag because even a rom_device region will always be readable from the guest POV. What differs is the mapping, just like the comments had to explain already. Also, readable could currently be understood as being a generic region flag, but it only applies to rom_device regions. So rename the flag and the function to modify it after the original term "ROMD" which could also be interpreted as "ROM direct", i.e. ROM mode with direct access. In any case, the scope of the flag is clearer now. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24memory: allow memory_region_find() to run on non-root memory regionsPaolo Bonzini
memory_region_find() is similar to registering a MemoryListener and checking for the MemoryRegionSections that come from a particular region. There is no reason for this to be limited to a root memory region. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-03-22memory: fix a bug of detection of memory region collisionHu Tao
The collision reports before and after this patch are: before: warning: subregion collision cfc/4 (pci-conf-data) vs cf8/4 (pci-conf-idx) warning: subregion collision 8000000/f8000000 (pci-hole) vs 0/8000000 (ram-below-4g) warning: subregion collision 100000000/4000000000000000 (pci-hole64) vs 8000000/f8000000 (pci-hole) warning: subregion collision 4d1/1 (kvm-elcr) vs 4d0/1 (kvm-elcr) warning: subregion collision fec00000/1000 (kvm-ioapic) vs 8000000/f8000000 (pci-hole) warning: subregion collision 80/1 (ioport80) vs 7e/2 (kvmvapic) warning: subregion collision fed00000/400 (hpet) vs 8000000/f8000000 (pci-hole) warning: subregion collision 81/3 (dma-page) vs 80/1 (ioport80) warning: subregion collision 8/8 (dma-cont) vs 0/8 (dma-chan) warning: subregion collision d0/10 (dma-cont) vs c0/10 (dma-chan) warning: subregion collision 0/80 (ich9-pm) vs 8/8 (dma-cont) warning: subregion collision 0/80 (ich9-pm) vs 0/8 (dma-chan) warning: subregion collision 0/80 (ich9-pm) vs 64/1 (i8042-cmd) warning: subregion collision 0/80 (ich9-pm) vs 60/1 (i8042-data) warning: subregion collision 0/80 (ich9-pm) vs 61/1 (elcr) warning: subregion collision 0/80 (ich9-pm) vs 40/4 (kvm-pit) warning: subregion collision 0/80 (ich9-pm) vs 70/2 (rtc) warning: subregion collision 0/80 (ich9-pm) vs 20/2 (kvm-pic) warning: subregion collision 0/80 (ich9-pm) vs 7e/2 (kvmvapic) warning: subregion collision 4/2 (acpi-cnt) vs 0/4 (acpi-evt) warning: subregion collision 30/8 (apci-smi) vs 20/10 (apci-gpe0) warning: subregion collision b0000000/10000000 (pcie-mmcfg) vs 8000000/f8000000 (pci-hole) after: warning: subregion collision fec00000/1000 (kvm-ioapic) vs 8000000/f8000000 (pci-hole) warning: subregion collision fed00000/400 (hpet) vs 8000000/f8000000 (pci-hole) warning: subregion collision 0/80 (ich9-pm) vs 8/8 (dma-cont) warning: subregion collision 0/80 (ich9-pm) vs 0/8 (dma-chan) warning: subregion collision 0/80 (ich9-pm) vs 64/1 (i8042-cmd) warning: subregion collision 0/80 (ich9-pm) vs 60/1 (i8042-data) warning: subregion collision 0/80 (ich9-pm) vs 61/1 (elcr) warning: subregion collision 0/80 (ich9-pm) vs 40/4 (kvm-pit) warning: subregion collision 0/80 (ich9-pm) vs 70/2 (rtc) warning: subregion collision 0/80 (ich9-pm) vs 20/2 (kvm-pic) warning: subregion collision 0/80 (ich9-pm) vs 7e/2 (kvmvapic) warning: subregion collision b0000000/10000000 (pcie-mmcfg) vs 8000000/f8000000 (pci-hole) Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-02-16memory: Use non-bitops ctzlRichard Henderson
A memory size of zero is invalid, and so that edge condition does not occur. Signed-off-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2013-02-02bitops: unify bitops_ffsl with the one in host-utils.h, call it bitops_ctzlPaolo Bonzini
We had two copies of a ffs function for longs with subtly different semantics and, for the one in bitops.h, a confusing name: the result was off-by-one compared to the library function ffsl. Unify the functions into one, and solve the name problem by calling the 0-based functions "bitops_ctzl" and "bitops_ctol" respectively. This also fixes the build on platforms with ffsl, including Mac OS X and Windows. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Andreas Färber <afaerber@suse.de> Tested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2012-12-20memory: introduce memory_region_test_and_clear_dirtyJuan Quintela
This function avoids having to do two calls, one to test the dirty bit, and other to reset it. Signed-off-by: Juan Quintela <quintela@redhat.com>
2012-12-19softmmu: move include files to include/sysemu/Paolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19misc: move include files to include/qemu/Paolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19exec: move include files to include/exec/Paolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-11-10memory: Don't dump disabled regionsJan Kiszka
This makes "info mtree" output readable again. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2012-11-10memory: Reintroduce dirty flag to optimize changes on disabled regionsJan Kiszka
Cirrus is triggering this, e.g. during Win2k boot: Changes only on disabled regions require no topology update when transaction depth drops to 0 again. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>