target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
reserved) and its purpose doesn't match the name (most target_phys_addr_t
addresses are not target specific).  Replace it with a finger-friendly,
standards conformant hwaddr.

Outstanding patchsets can be fixed up with the command

  git rebase -i --exec 'find -name "*.[ch]"
                        | xargs s/target_phys_addr_t/hwaddr/g' origin
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This makes it possible for QEMU to use transparent huge pages (THP)
when transparent_hugepage/enabled=madvise. Otherwise THP is only
used when it's enabled system wide.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Since address spaces can be created dynamically by device hotplug, they
can also be destroyed dynamically.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Currently we use a global radix tree to dispatch memory access.  This only
works with a single address space; to support multiple address spaces we
make the radix tree a member of AddressSpace (via an intermediate structure
AddressSpaceDispatch to avoid exposing too many internals).

A side effect is that address_space_io also gains a dispatch table.  When
we remove all the pre-memory-API I/O registrations, we can use that for
dispatching I/O and get rid of the original I/O dispatch.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Using the AddressSpace type reduces confusion, as you can't accidentally
supply the MemoryRegion you're interested in.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

We plan to make the core listener listen to all address spaces; this
will cause many more flushes than necessary.  Prepare for that by
moving the flush into a tcg-specific listener.

Later we can avoid registering the listener if tcg is disabled.
Signed-off-by: NAvi Kivity <avi@redhat.com>

With this change, memory.c no longer knows anything about special address
spaces, so it is prepared for AddressSpace based DMA.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

Instead of calling a global function on coalesced mmio changes, which
routes the call to kvm if enabled, add coalesced mmio hooks to
MemoryListener and make kvm use that instead.

The motivation is support for multiple address spaces (which means we
we need to filter the call on the right address space) but the result
is cleaner as well.
Signed-off-by: NAvi Kivity <avi@redhat.com>

It is used nowhere else, and the corresponding MAX_CODE_GEN_BUFFER_SIZE
also lives there.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

We had a hack for arm and sparc, allocating code_gen_prologue to a
special section.  Which, honestly does no good under certain cases.
We've already got limits on code_gen_buffer_size to ensure that all
TBs can use direct branches between themselves; reuse this limit to
ensure the prologue is also reachable.

As a bonus, we get to avoid marking a page of the main executable's
data segment as executable.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

The hard-coded addresses inside alloc_code_gen_buffer only make sense
if we're building an executable that will actually run at the address
we've put into the linker scripts.

When we're building with -fpie, the executable will run at some
random location chosen by the kernel.  We get better placement for
the code_gen_buffer if we allow the kernel to place the memory,
as it will tend to to place it near the executable, based on the
PROT_EXEC bit.

Since code_gen_prologue is always inside the executable, this effect
is easily seen at the end of most TB, with the exit_tb opcode, and
with any calls to helper functions.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

For ARM we cap the buffer size to 16MB.  Do not allocate 32MB in that case.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

It now consists of:

A macro definition of MAX_CODE_GEN_BUFFER_SIZE with host-specific values,

A function size_code_gen_buffer that applies most of the reasoning for
choosing a buffer size,

Three variations of a function alloc_code_gen_buffer that contain all
of the logic for allocating executable memory via a given allocation
mechanism.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Is the only way of knowing the RAM size.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>

Removes quite a bit of useless code.
Signed-off-by: NAvi Kivity <avi@redhat.com>

exec-obsolete.h used to hold pre-memory-API functions that were used from
device code prior to the transition to the memory API.  Now that the
transition is complete, the name no longer describes the file.  The
functions still need to be merged better into the memory core, but there's
no danger of anyone using them.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

Move the DUMP_FPU and DUMP_CCOP flags for cpu_dump_state() from being
x86-specific flags to being generic ones. This allows us to drop some
TARGET_I386 ifdefs in various places, and means that we can (potentially)
be more consistent across architectures about which monitor commands or
debug abort printouts include FPU register contents and info about
QEMU's condition-code optimisations.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

This patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Reviewed-by: NAvi Kivity <avi@redhat.com>

This new helper/hook is used in the next patch to add an extra call in a single
place.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Reviewed-by: NAvi Kivity <avi@redhat.com>

Current code doesn't actually work in 32-bit mode at all.  Since
no one really noticed, drop the complication of v7 and v8 cpus.
Eliminate the --sparc_cpu configure option and standardize macro
testing on TCG_TARGET_REG_BITS / HOST_LONG_BITS
Signed-off-by: NRichard Henderson <rth@twiddle.net>

The address we pick in sparc64.ld is also 0x60000000, so doing a fixed map
on top of that is guaranteed to blow up.  Choosing 0x40000000 is exactly
right for the max of code_gen_buffer_size set below.

No need to ever use MAP_FIXED.  While getting our desired address helps
optimize the generated code, we won't fail if we don't get it.
Signed-off-by: NRichard Henderson <rth@twiddle.net>

cpu_physical_memory_write_rom(), despite the name, can also be used to
write images into RAM - and will often be used that way if the machine
uses load_image_targphys() into RAM addresses.

However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
doesn't invalidate any cached TBs which might be affected by the region
written.

This was breaking reset (under full emu) on the pseries machine - we loaded
our firmware image into RAM, and while executing it rewrite the code at
the entry point (correctly causing a TB invalidate/refresh).  When we
reset the firmware image was reloaded, but the TB from the rewrite was
still active and caused us to get an illegal instruction trap.

This patch fixes the bug by duplicating the tb invalidate code from
cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

It allows to disable memory merge support (KSM on Linux), which is
enabled by default otherwise.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Add a new '[,dump-guest-core=on|off]' option to the '-machine' option. When
'dump-guest-core=off' is specified, guest memory is omitted from the core dump.
The default behavior continues to be to include guest memory when a core dump is
triggered. In my testing, this brought the core dump size down from 384MB to 6MB
on a 2GB guest.

Is anything additional required to preserve this setting for migration or
savevm? I don't believe so.

Changelog:
v3:
    Eliminate globals as per Anthony's suggestion
    set no dump from qemu_ram_remap() as well
v2:
    move the option from -m to -machine, rename option dump -> dump-guest-core
Signed-off-by: NJason Baron <jbaron@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

For each newly created RAM block, dirty bitmap is reallocated with g_realloc, which doesn't
make any promises on initial content of new extra data in returned buffer. In theory,
we initialize this new data with cpu_physical_memory_set_dirty_range() call. The
problem is, cpu_physical_memory_set_dirty_range() has a side effect of incrementing
ram_list.dirty_pages variable, but only for pages which are not already dirty. And
page "cleanliness" is determined using the same not yet uninitialized dirty bitmap
we've just reallocated. This results in inconsistency between real dirty page number
and value in ram_list.dirty_pages variable, which in turn could (and will) result
in errors during VM migration.
Zero initialize new dirty bitmap bytes to fix this problem.
Signed-off-by: NIgor Mitsyanko <i.mitsyanko@samsung.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Remove an out of date comment: this comment used to be attached to
cpu_register_physical_memory_log(), before commit 0f0cb164 accidentally
inserted a couple of other functions between the comment and its function.
It is in any case obsolete since (a) the function arguments it refers
to have been replaced with a single MemoryRegionSection* argument and
(b) the inability to handle regions whose offset_within_address_space
and offset_within_region aren't equally aligned was fixed as part of
the rewrite of this code.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Registering a multi-page memory region that is non-page-aligned results
in a subpage from the start to the page boundary, some number of full
pages, and possibly another subpage from the last page boundary to the
end. The full pages will have a value for offset_within_region that is
not a multiple of TARGET_PAGE_SIZE. Accesses through softmmu are unable
to handle this and will segfault.

Handling full pages through subpages is not optimal, but only
non-page-aligned mappings take the penalty.
Signed-off-by: NTyler Hall <tylerwhall@gmail.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

subpage_register() expects "end" to be the last byte in the mapping.
Registering a non-page-aligned memory region that extends up to or
beyond a page boundary causes subpage_register() to silently fail
through the (end >= PAGE_SIZE) check.

This bug does not cause noticeable problems for mappings that do not
extend to a page boundary, though they do register an extra byte.
Signed-off-by: NTyler Hall <tylerwhall@gmail.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Under Win32, EventNotifiers will not have event_notifier_get_fd, so we
cannot call it in common code such as hw/virtio-pci.c.  Pass a pointer to
the notifier, and only retrieve the file descriptor in kvm-specific code.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

By default qemu will use MAP_PRIVATE for guest pages. This will write
protect pages and thus break on s390 systems that dont support this feature.
Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED
has other problems (no dirty pages tracking, a lot more swap overhead etc.)
Newer systems allow the distinction via KVM_CAP_S390_COW. With this feature
qemu can use the standard qemu alloc if available, otherwise it will use
the old s390 hack.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NJens Freimann <jfrei@linux.vnet.ibm.com>
Acked-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Always use accessors to read/set the dirty bitmap.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Refactor the code that is only needed for tcg to an static function.
Call that only when tcg is enabled.  We can't refactor to a dummy
function in the kvm case, as qemu can be compiled at the same time
with tcg and kvm.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Move logging functions from exec.c to qemu-log.c,
compile it only once.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This makes it easier to remove it from BusInfo.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
[AF: Drop now unnecessary NULL initialization in scsibus_get_dev_path()]
Signed-off-by: NAndreas Färber <afaerber@suse.de>

tb_invalidate_phys_addr has to be called with the exact physical address of
the breakpoint we add/remove, not just the page's base address.
Otherwise we easily fail to flush the right TB.

This breakage was introduced by the commit f3705d53 "memory: make
phys_page_find() return an unadjusted".

This appeared to work for some guest architectures because their
cpu_get_phys_page_debug implementation returns full translated physical
address, not just the base of the TARGET_PAGE_SIZE-sized page.
Reported-by: NTeLeMan <geleman@gmail.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

They could suggest that all TBs of the page containing the range would
be invalidated.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

This API will be used in the following patch.
Signed-off-by: NWen Congyang <wency@cn.fujitsu.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

If we execute linux-user code that does the following:

  * A = mmap()
  * execute code in A
  * munmap(A)
  * B = mmap(), but mmap returns the same address as A
  * execute code in B

we end up executing a stale cached tb that contains translated code
from A, while we want new code from B.

This patch adds a TB flush for mmap'ed regions, before we return them,
avoiding the whole issue. It also adds a flush for munmap, so that we
don't execute stale TBs instead of getting a segfault.
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Acked-by: NRiku Voipio <riku.voipio@linaro.org>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Fold is_ram_rom and is_ram_rom_romd() into callers.

Change is_romd() and section_addr() to take MemoryRegion
instead of MemoryRegionSection for consistency and
use memory_region_ prefix.
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>